def foo(n): lambda i: n += i
Give me two powerful languages with the same features and I'll pick the latter for its syntax.
So no, lisp may be the best right now, but it won't be the best forever, its syntax is its best friend and worst enemy.
Something lispers will never understand. Love is blindness.
I'd like to know, though: is that true? Is an abstract syntax tree the only good way to represent programs as data? Has any other expressive way to do this been invented, or do programs always boil down to an AST after the syntax has been stripped away?
I say "expressive" because I can think of at least one other code-as-data representation: binary. But that isn't suitable for programming. If there is another representation that is suitable, but isn't isomorphic to a parse tree, then presumably one could derive from it an analog to Lisp that doesn't simply reduce to Lisp. Until then, though, I think the point that PG made semi-jokingly in the essay, that any language as powerful as Lisp will be a variant of Lisp, has to hold true.
Some day I'd like to research this question (or better, someone on HN could just tell me the answer). If other meaningful representations are possible, surely some must have been invented by now. And if they aren't, then the AST is a considerably more remarkable discovery than people realize.
What would really interest me would be exploring that if human logic fundamentally reduces to a parse tree because of something to do with the language faculty of the mind, and the programming languages that we create tend towards that just because programming languages are built out of the same logical faculty.
That is actually an excellent question.
Now, say I fork lisp and change one little thing:
(defun foo (n) (lambda (i) (incf n i)))
to this:
[defun foo [n] [lambda [i] [incf n i]]]
or even this:
{defun foo {n} {lambda {i} {incf n i}}}
or how about this?
<defun foo <n> <lambda <i> <incf n i>>>
Hmm, trees are powerful, no matter how they are expressed huh?
What if we can represent the same trees using colons and commas as delimiters?
:defun foo:n, :lambda:i, :incf n i.
Maybe spice it up a bit using periods as recursive closing delimiter.
See? still powerful trees!
Between common lisp and colon lisp, I still use the latter.
Love is blindness.
Ergonomics win.
I don't see what you're trying to claim. Initially you seemed to be saying that you preferred conventional sytax to sexprs. I pointed out that this meant you had to give up macros. You reply that you could use other characters to delimit sexprs. Sure, but so what?
The syntax in that first example you quote isn't arbitrary. It's essentially the only notation that exists for representing the structure of a program explicitly in language. Is that valuable? Uh, yeah. It's incredibly valuable. It's worth a lot more than syntax in many cases.
By contrast, the syntax in the second example is arbitrary: the delimiters and operators could just as easily be organized differently. Perhaps this particular organization makes certain programs clearer, but it loses the ability to represent programs in general.
If that doesn't make sense, think of the fairy tale of the goose that lays golden eggs. Everybody's obsessed with their particular golden egg. Lisp - precisely because of the difference visible in those two examples - is the goose.
There's nothing in this that PG didn't already express in his comment. But what you wrote deserves more than one protest :)