[hzhou321]

I think your comments are focused at learning side: we learn about the syntax, we learn about the library, we learn about "fold/reduce". At the learning side, abstraction do feel like just one more layer to penetrate, unless, the abstraction is based on your existing experience, which in current programming culture is not really the case.

To understand what I am advocating, think on the writing side, think about when you want to write a program when there is no library and no syntax. What will you have? You'll start with abstract word with meanings based on your past experience. And that abstract word will be able to communicate with your fellow as they often share some of your experience. That is what I mean vocabulary based programming. I guess it is the word "abstraction" confuses. I did not use the word "abstraction" although people with experience in learning tend to see abstraction. Think about how you sort a deck of card, does the word such as pick, find, insert appear abstraction to you? They are the first natural units of meaning, and they appear in our head before any detail implementations. So if we refer abstractions as the steps for our mind to get to, then those vocabulary are not abstractions, the actual implementations are. Anyway, I know I am confusing the hell out of even myself -- natural language and how our mind works are strange :). In the end, I would like you to forget about abstraction or even vocabulary, just go to the most natural way of thinking: whatever comes first should come first in writing (code), and often that is how the most natural way to read as well.

[bendersalt]

I think you misunderstood me.

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".

[hzhou321]

Generics as in current C++ and Java are still tied to the low level data types. They merely extended from single data type to a collection of data types (that fits certain strict condition).

Now look at our natural language, "eat" for example, you can suddenly say "the sky dog eats the sun" out of the blue and people will start to make that sentence work (which is the ancient Chinese referring to eclipse). Here the vocabulary word "eat" can be defined at any time of history, but not being confined by the definition at any time. The use of words leads definition rather than the other way around.

Let's look at the word "fold", which works on list. Now I have an array or a hash or a matrix, and I am thinking that I need some kind of operation similar to "fold" on a list. Do you just write "fold add array|hash|matrix" then work out the detail implementation (probably at a much later stage)? If you do, you are treating fold as a vocabulary word and you are doing vocabulary lead programing.

Yes, in the case of "fold", it describes a composition type of meaning. How about "pick", "find" or "eat"?

I guess what I am trying to differentiate is meaning and implementation. Larry Wall's favorite idiom is there is more than one way to do it, I think it fits what I mean. it is the meaning, and way is the implementation. In current programming practice, most people only focuses on how it is done, but neglects the meaning. I actually heard many complaints from programmers against Perl exactly because of this "there's more than one way to do it" attitude, how about you?

[belovedeagle]

This is a problem already solved by typeclasses in Haskell; http://hackage.haskell.org/package/base-4.8.0.0/docs/Data-Fo...

You can write your own instances of Foldable to add implementations of the "vocabulary" word fold.

How is this different from what you're proposing? It sounds almost like you want the compiler to figure out an instance of Foldable (or, say, Edible) for you, but computers simply don't work that way (then again, GHC can derive Foldable sometimes!).