Comment by skissane | Hacker News Reader

Comment by skissane | Hacker News Reader

Parent Full thread

> Non-human-readable primary representation may be not the best idea though.

What if the AST is persisted as S-expressions, but then you have a different syntax to edit it? Algol-ish, Pascal-ish, C-ish, Python-ish: choose your poison (or even support multiple poisons and let the developer pick the one they prefer?)

This was actually the original plan with Lisp. Lisp was originally supposed to have two syntaxes, S-expressions and M-expressions, with M-expressions being Algol-like. However, the implementation of M-expressions was delayed, and people got so used to using S-expressions directly, they decided M-expressions were unnecessary and they were never implemented in mainstream Lisp. They were implemented in the Lisp 2 project, but that ended up being an evolutionary dead-end; various attempts at the idea have happened since but none of them really took off.

Lisp purists will argue M-expressions are unnecessary and S-expressions are all you need. However, S-expressions can make the language more foreboding to complete beginners, and even among experienced programmers, a decent percentage find them seriously off-putting. Maybe if the M-expression idea had been pursued more seriously, Lisp might be more popular today.

> Lisp purists will argue M-expressions are unnecessary and S-expressions are all you need.

I would argue that S-Expressions turned out to be extremely practical for developing Lisp software. A layer with different syntax makes it more complex to use.

> Maybe if the M-expression idea had been pursued more seriously, Lisp might be more popular today.

Maybe, maybe not. People have discussed it endlessly, but there is no conclusion.

Currently some people in the Racket community try to make Racket more "popular" (widely used, ...) by providing a new syntax.

Not just practical, S-Expressions are a big part of Lisp's superpowers from a UI perspective. You can manipulate code as forms, not text. It's hard to overstate how much of an advantage that brings to a well-configured editor.

When you start thinking of your program as a nested data structure instead of a text document, you start thinking more clearly - you can manipulate this tree representation directly. This makes molding your program significantly faster, closer to the speed of thought. Wholesale refactoring a function might only take a dozen keystrokes to move the forms (not the chars) around.

I have a hard time going back to the syntactic busywork of manually placing ascii characters like a caveman.

S-exp is an interesting idea. Technically they are human readable, and certainly would be processable by text tools, with some effort. Lisp maps to S-exps very well obviously but I wonder if the same amount of synergy can be achieved in the language that is not aimed at that at the start, or it will just become a binary dump with extra steps instead. Definitely would be interesting for somebody to try.

> Lisp maps to S-exps very well obviously but I wonder if the same amount of synergy can be achieved in the language that is not aimed at that at the start

But lisp did not aim for that from the start, as the GP hinted McCarthy intended S-expressions as a data description form, m-expressions were supposed to be the executable language.

Reply on news.ycombinator.com