[nickbauman]

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]

Could you explain or give examples of what you mean by no or little syntax?

[nickbauman]

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]

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]

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

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

[nickbauman]

Yes. I mean less syntax (you call it "syntactic forms", sure). I can think in this language because it's only the semantics that I have to remember, because there is no syntax to also remember. Any syntax you come up with will be inferior to data. But I think it could be a worthy challenge to teach kids Lisp. For instance, you know, you can make named parameters in your functions to help kids really easily in Lisp. It's, what, at most a 15 minute task to add that to any function.

[nickbauman]

Read that link. Concatenative programming sounds like an interesting subset of Functional programming. You could easily write such a language in Lisp, too.