[TweedHeads]

(defun foo (n) (lambda (i) (incf n i)))

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.

[pg]

In this case it's more that ignorance is blindness. That syntax is a feature. The fact that Lisp code is expressed in Lisp data structures makes it easy to write programs that write programs.

[wheels]

Even not as a real lisp guy that's one of the things that I appreciate about lisp and the only time that I've done anything particularly powerful with it: the fact that it's basically a parse tree makes it really interesting for genetic programming.

[gruseom]

It seems that the fact that Lisp is a parse tree is what makes it a limiting case. That is, if there's only one canonical structure for representing programs, and Lisp makes it explicit, then any other language that makes it explicit is going to be isomorphic to Lisp.

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.

[wheels]

I don't think that a parse tree is intrinsic -- it's just something that maps well to the languages that we actually use: of course you could translate everything to a turing machine's tape, but that wouldn't be particularly useful.

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.

[gruseom]

Yeah, that's the point. Other representations are possible (binary), but only one has proven suitable for programming. This is presumably because of the way the human mind works. It would be remarkable if it were the only good representation for this. It would also be the reason why Lisp is the limiting case among programming languages, at least when it comes to metaprogramming. But I repeat myself :)

[jacquesm]

> 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?

That is actually an excellent question.

[gruseom]

I was thinking Rebol might be a good place to look.

http://news.ycombinator.com/item?id=780853

[TweedHeads]

Dear Paul, when I say its syntax is its best friend, that's exactly what I'm talking about.

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.

[pg]

Sure, trees are powerful no matter how you delimit them. Most Lisp hackers would be fine with using {}, [], or <> if they had to. What Lisp hackers like is programming in lists, not parens per se.

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?

[TweedHeads]

Taking a closer look at my macbook keyboard, of all the lisp forks, I'd go with squared brackets [lisp] for convenience.

Ergonomics win.

[Kw2987]

If that's the only thing stopping you, just tweak your editor's keymappings.

[gruseom]

You're assuming your conclusion: that the languages are equivalent in power and differ only in syntax. If that were true, then sure, one would simply make an arbitrary choice based on taste. But it isn't true. It's profoundly untrue.

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 :)

[abecedarius]

That Python code shouldn't work. It needs a 'return', assignments aren't expressions, and assigning to a nonlocal variable in the absence of a declaration just creates a local. (Might be nice if Python did look more like that, though!)