6 ms·

This touches on some really important relationships between programming languages and cognition. Alan Kay has been studying how children take to programming an

• nickbauman 14y ago
  What about languages that have no syntax? Or have very little syntax? In my experience, I find them easier to reason about, therefore easier to read and easier to write. My sense is that children would find this to be true as well.
  • tqs 14y ago
    Could you explain or give examples of what you mean by no or little syntax?
    • nickbauman 14y ago
      Lisp languages have virtually no syntax. Example: Write a function that generates a string of all the numbers in a range from a start and end value. Java (lots of syntax, many tokens): String rangeString(int start, int end) { String oni = ""; for(int i = start; i < (1 + end); i++) { oni += String.valueOf(i); } } Clojure (almost no syntax): (defn [start end] (apply str (range start (inc end))))
      • Peaker 14y ago
        Little lexical/concrete syntax. Quite a bit of abstract syntax. I personally don't think that having less lexical syntax is useful for the things you mention. Lisp has extensible abstract syntax, so overall, it probably has the largest syntax of all.
      • tqs 14y ago
        Ah, okay. So by less syntax you mean fewer syntactic forms (parentheses, curly braces, do notation, etc.) and keywords (class, public, etc.) in the language. I think in general, languages with fewer syntactic forms also have fewer but more powerful abstraction features. Lisps are pretty high up by this measure. They basically only have one abstraction feature: lambda expressions. Other languages have powerful abstraction features but more of them, like Haskell (lambdas, pattern matching, monadic do notation). And others have many but less powerful abstraction features (e.g. Java). On the one hand, I certainly agree with you that more powerful abstractions make it easier to program. Once you've grokked the abstraction, you only need one brain "chunk" to deal with it freeing up your other chunks to work on the problem. If you need to juggle several different abstractions (e.g. wrap up your closure inside an object inside a class), you have fewer chunks to work on your problem. On the other hand, people tend to have difficulty learning these higher abstractions in the first place. Alan Kay, in that quote, points out that young children (I think less than ~8 years old) have difficulty with the abstraction of parameterization. In particular they have trouble with mentally corresponding the placement of a parameter in a list with its role in the function. Named parameters make things a bit better, they help the children keep track of the role. Explicit variable assignment (imperative programming) makes it even easier. Of course, as less powerful abstractions, these styles don't tend to scale as well when working on more complex programs. In general, I think people need help keeping track of specifics while working with higher abstractions until the abstractions become "natural" to them. Programming interfaces, including debugging interfaces, can help with this. It's a bit of a paradox. When you truly understand an abstraction it tremendously improves the clarity of your programming experience. But without this understanding, abstractions can be a major hindrance. You may be interested in further exploring "point-free" abstractions. It's kind of the next level up the abstraction ladder from explicitly assigned variables in imperative code, to lambda abstractions with parameters, to functions without the parameters at all. http://www.haskell.org/haskellwiki/Pointfree http://www.haskell.org/haskellwiki/Pointfree Or approach from the concatenative side, http://evincarofautumn.blogspot.com/2012/02/why-concatenative-programming-matters.html http://evincarofautumn.blogspot.com/2012/02/why-concatenativ...