4 ms·

This is complete nonsense. After finally making it to the end of the article, it became clear that the author is simply advocating for a top-down programming st

This is complete nonsense. After finally making it to the end of the article, it became clear that the author is simply advocating for a top-down programming style. However, this fact is completely hidden by some very fundamental misunderstandings about how any of the referenced languages work. "Fold" is not a "keyword" in Haskell, not by a long shot. The author doesn't seem to understand how the programmer can himself implement functions such as fold.

hzhou321 12y ago
Thanks for reading to the end; I appreciate it. I quoted "fold" because it is essentially a vocabulary word (which is the whole reason I quote it), it only feels like a language keyword because it is designed and programmer typically learned it.
- belovedeagle 12y ago
  Sorry, still nonsense. All functions are "designed" and "learned"—that's the whole point of a function, a unit of code reuse. You're positing magic, uh, how did you call them... "elite programmers" in the sky who bestow upon us all the magic functions. Now, I understand that when you first see packages such as Kmett's lens package, it can certainly feel that way, but there's no real truth to the idea. There's no difference between what you call "vocabulary" and library-supplied functions like fold. > A vocabulary based programming need give ordinary user the ability to create new words and the ability to expand its usage That's just called implementing a new function, or maybe writing a new API.
  - bendersalt 12y ago
    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."
    - hzhou321 12y ago
      I understand, and this is kind of today's programming wisdom. But I think we can change it, unless you take the "hard way" as benefit. In English, I say "go to school", there will be some oversight that end up the kid stray to a game parlor. So in practice, we still do our due diligence to make sure the kid do what we meant. But the important aspect is we do not change "go to school". "go to school" retain its independent meaning even when the implementation is not clear. Similarly, in programming, the abstract vocabulary will not predict how the actual code will do, but my point is that the implementation is a separate layer from the vocabulary. If the implementation did not do what we meant with the vocabulary (which can be context dependent), we fix the implementation, until to the point that we build the trust (putting into a trust-able library). Just like we as individual all maintain our own dictionary and trust database, I advocate we each maintain our own macro library (which does not exclude importing from trusted source, sort of like `git`). By library, I am actually referring to meta(macro) library, (like slang dictionary). Today's binary library does not define the meaning of their names (function/class names), they define the meaning by code, which end up the only way to get the meaning is the hard way. For the macro library, the meaning comes first, (even when the implementation are ambiguous at the time), and therefore it can retain its meaning and further grow its meaning. It may sound too complicated or too abstract, but in practice, it is just like when we say the kid "goes to school". It is a more of ad hoc practice and, well, natural. To summarize, current way of programming is more or less code comes first, a vocabulary based programming would be meaning comes first. And for a casual practice, it will provide opportunity for common programmers to only program at the meaning level while trusting the meta-layer (with evolved intelligence) do the right thing, ... until we got feedback otherwise (what? The kid is not at the school? ...)
      - bendersalt 12y ago
        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.
  - hzhou321 12y ago
    > Sorry, still nonsense. No apology necessary. Unfortunately, sense is individual context dependent.
it_learnses 12y ago
I agree. I don't see how the author is doing anything differently than the current programming languages.

hzhou321 12y ago

Thanks for reading to the end; I appreciate it. I quoted "fold" because it is essentially a vocabulary word (which is the whole reason I quote it), it only feels like a language keyword because it is designed and programmer typically learned it.

belovedeagle 12y ago
Sorry, still nonsense. All functions are "designed" and "learned"—that's the whole point of a function, a unit of code reuse. You're positing magic, uh, how did you call them... "elite programmers" in the sky who bestow upon us all the magic functions. Now, I understand that when you first see packages such as Kmett's lens package, it can certainly feel that way, but there's no real truth to the idea. There's no difference between what you call "vocabulary" and library-supplied functions like fold. > A vocabulary based programming need give ordinary user the ability to create new words and the ability to expand its usage That's just called implementing a new function, or maybe writing a new API.
- bendersalt 12y ago
  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."
  - hzhou321 12y ago
    I understand, and this is kind of today's programming wisdom. But I think we can change it, unless you take the "hard way" as benefit. In English, I say "go to school", there will be some oversight that end up the kid stray to a game parlor. So in practice, we still do our due diligence to make sure the kid do what we meant. But the important aspect is we do not change "go to school". "go to school" retain its independent meaning even when the implementation is not clear. Similarly, in programming, the abstract vocabulary will not predict how the actual code will do, but my point is that the implementation is a separate layer from the vocabulary. If the implementation did not do what we meant with the vocabulary (which can be context dependent), we fix the implementation, until to the point that we build the trust (putting into a trust-able library). Just like we as individual all maintain our own dictionary and trust database, I advocate we each maintain our own macro library (which does not exclude importing from trusted source, sort of like `git`). By library, I am actually referring to meta(macro) library, (like slang dictionary). Today's binary library does not define the meaning of their names (function/class names), they define the meaning by code, which end up the only way to get the meaning is the hard way. For the macro library, the meaning comes first, (even when the implementation are ambiguous at the time), and therefore it can retain its meaning and further grow its meaning. It may sound too complicated or too abstract, but in practice, it is just like when we say the kid "goes to school". It is a more of ad hoc practice and, well, natural. To summarize, current way of programming is more or less code comes first, a vocabulary based programming would be meaning comes first. And for a casual practice, it will provide opportunity for common programmers to only program at the meaning level while trusting the meta-layer (with evolved intelligence) do the right thing, ... until we got feedback otherwise (what? The kid is not at the school? ...)
    - bendersalt 12y ago
      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.
- hzhou321 12y ago
  > Sorry, still nonsense. No apology necessary. Unfortunately, sense is individual context dependent.

it_learnses 12y ago

I agree. I don't see how the author is doing anything differently than the current programming languages.