Syntax Matters...?

Alan Kay has been studying how children take to programming and many of the ideas from Smalltalk come from these studies.

When designing for children, every part of the user interface, including the syntax of the programming language, matters a lot. For example, he writes, "If we take functional relationships as an example, it has been shown that children readily understand them but have considerable difficulty with variables, and much more difficulty with parameters. The standard math syntax for functions with parameters requires some extra trained chunks to associated dummy names with actual parameters. Some computer languages allow conventions for prefixing the actual parameters with the dummy names. This is good. For younger children, it's likely that making these into complete assignment statements is an even better idea. An object oriented language can use instance variables for a long time before introducing the idea of passing parameters in a method, etc. Having really good trace and single-step visualizations is critical." http://www.donhopkins.com/drupal/node/140

Children have different cognitive needs than adult programmers (and different needs from each other depending on age). But cognitive needs matter in designing programming languages for adults too. I personally take the optimistic (or cynical?) view that we have a lot of room to improve our programming interfaces (not just languages, but the entire programming experience viewed holistically).

Average Haskell is probably less readable than average Python, because the Haskell community places less emphasis on readability, unfortunately.

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

Or approach from the concatenative side, http://evincarofautumn.blogspot.com/2012/02/why-concatenativ...