Language is an abstraction and its based in symbols. The word rock has literally nothing to do with what a rock is, other than it is the sound we use to refer to rocks. And the concept of rocks is an abstraction, rocks certainly have many similar properties but no single rock is the same as any other rock, they all have differing numbers of atoms, and shapes. But generally speaking rocks are similar enough at the level we work with them at, that you can say things like, big rock, and small rock and there is a general understanding of what is meant. This is a ridiculous example, but its important.
I think what you are looking for here is composition. Let me explain. Java has a TON of natural language, but its much derided for its "verbosity" and boiler-plate centric coding style. But if you sit down and read Java code, its very hard to "miss the point." Classes lend themselves to natural language, and a User object almost certainly contains information like username and password, and first_name, last_name type stuff. It doesn't break the expectations of how we imagine things are grouped together. So in that regard Java is very "natural" but Java is not very composable.
fold add [1,2,3] is a great simple example of composition.
so is
map reverse (zip array_of_arrays)
Natural language, and composable, and the results are fairly easy to guess.
So I get what you are saying, natural language is really nice, but what you are probably advocating is composition. Which is where things like generics stand out.
Writing fold add list is better than. fold add_float list_of_floats and fold add_integer list_of_ints, ideally things which use the + operator should be composable with +, if not it really just makes the whole affair not very fun. Having to basically do taxonomy on your functions, to write the same use of the same operator.
In fact I'd argue this is where a lot of languages really fall on their face where composition is concerned. They have static types, and they might even allow operator overloading, but they don't support generics in a way that allows you to avoid telling the compiler that "yes its really okay to use the operator the way its already been described to be used as".
I'm not even really sure what you are advocating, we all already use libraries, and helper functions, and understand data types, and use generics to map the same function name to multiple types. Fold/reduce are words that are in our vocabulary and if you want to fold a list, array, vector, the result is very well understood by most people. If you want to fold a tree, while conceptually its still the same, the actual "twiddly bits" are very different. And that's not something all of us want or even need abstracted away. It really depends on what level you are working on.
If I'm writing a rest api, abstractions just make everything simpler, but sometimes I'm working with something new or I'm doing something custom and those abstractions are actually bad. I need to talk to the computer not the compiler.
Additionally not everyone thinks about programming the same way, I prefer whole word function names, I know guys that they could care less what things are called, they know what the code does all the same, they might be better developers than me, I'm not sure, but I know that their way of understanding a code base has very few corollaries to my way of understanding it.
Vocabulary about an abstraction is still an abstraction, and abstractions can be immensely useful in certain contexts, but they aren't always useful.
Anecdotal Comment: No matter how magical someone has made a library, I have never worked on a project that did not find an oversight, or some weird edge case where the abstraction dies in a horrible fire and you end up having to understand all the of the libraries internals anyway. Its just kind of the nature of programming in the end.
I'd much rather understand how to write a fold than to "know what it is." There is always something that just has to be done "the hard way."
I have found it mostly has to do with the care letters are written with. An e-mail is like talking in real life, in many cases someone responds to it right away and if there is any misunderstanding you can correct it right there with another e-mail. In many cases a letter is much more formal, you have to take a little bit of care to make sure the message is getting across right the first time.
Language is an abstraction and its based in symbols. The word rock has literally nothing to do with what a rock is, other than it is the sound we use to refer to rocks. And the concept of rocks is an abstraction, rocks certainly have many similar properties but no single rock is the same as any other rock, they all have differing numbers of atoms, and shapes. But generally speaking rocks are similar enough at the level we work with them at, that you can say things like, big rock, and small rock and there is a general understanding of what is meant. This is a ridiculous example, but its important.
I think what you are looking for here is composition. Let me explain. Java has a TON of natural language, but its much derided for its "verbosity" and boiler-plate centric coding style. But if you sit down and read Java code, its very hard to "miss the point." Classes lend themselves to natural language, and a User object almost certainly contains information like username and password, and first_name, last_name type stuff. It doesn't break the expectations of how we imagine things are grouped together. So in that regard Java is very "natural" but Java is not very composable.
fold add [1,2,3] is a great simple example of composition.
so is
map reverse (zip array_of_arrays)
Natural language, and composable, and the results are fairly easy to guess.
So I get what you are saying, natural language is really nice, but what you are probably advocating is composition. Which is where things like generics stand out.
Writing fold add list is better than. fold add_float list_of_floats and fold add_integer list_of_ints, ideally things which use the + operator should be composable with +, if not it really just makes the whole affair not very fun. Having to basically do taxonomy on your functions, to write the same use of the same operator.
In fact I'd argue this is where a lot of languages really fall on their face where composition is concerned. They have static types, and they might even allow operator overloading, but they don't support generics in a way that allows you to avoid telling the compiler that "yes its really okay to use the operator the way its already been described to be used as".