Comment by rusini | Hacker News Reader

Comment by rusini | Hacker News Reader

I have designed a programming language that borrows an important part of its architecture from Lisp(s) (maybe mostly Scheme, but also Kernel: http://klisp.org). However, I have always opposed to the concrete syntax of S-expressions (being mostly unable to be productive with it).

My arguments are not on the familiarity side (with the infix notation), but on the psychological one:

1. S-expressions are not the most simple, natural, or uniform surface form (as they claim); they do have syntactic sugar (quote, even lists themselves!, etc.), so why not to add some more sugar (but sufficiently abstract of course)?

2. Humans' brain has limited "stack" space (especially when closing parentheses); infix forms may "cascade" and do not consume the stack (equally machine on human, due to possibility of "tail recursion")

3. Lack of diverse "visual clues" for humans (note how most natural languages have 40-60 phonemes, and none less than 15)

4. S-expressions and homoiconicity are related but orthogonal features (so the homoiconicity argument is often not valid)

Having that said, when I finally managed to write a working 50+-lines program in Scheme, with "proper" indentation, I was just proud of it, and I said, "Wow, it looks cool!". But I am still on the side of the above rational arguments! My point is that as my experiment demonstrates, it is probably too easy to get on an emotional side of computer-human interaction once you accomplished something a bit challenging (like speaking in classic S-expressions)?

For me S-expressions feel like the most natural way to program because they compose naturally with zero ambiguity. Infix notation might be slightly clearer for simple expressions but it doesn't compose: As soon as you try to compose infix notation you have to add parens, depend on unstated precedence rules, or both. Lisp's philosophy is to just use parens everywhere, make everything composable, and have no precedence rules.

That said, I would hate to write Lisp code with Notepad. Fortunately nobody does this. In conjunction with a paren-matching, auto-indenting programmer's editor (which is roughly all of them these days), S-expressions are easy. A good editor is vital not just for writing Lisp programs but also for reading them.

I will not claim parentheses are mandatory. I find Haskell just as simple, unambiguous, and composable without (many) parens but that's only because it has automatic currying, and that takes a bit of practice to wrap one's head around.

IMHO, if you need an editor with paren-matching and auto-indenting (and maybe even syntax highlighting) just to make working with your language tolerable, that's a possible design flaw in the language.

I know it's heresy in a Lisp thread to claim that it's possible for a language to have too little syntax, but I can write Javascript, C and C++ just fine in Notepad or Sublime Text if I want.

My one counter argument for 1 and 2 is that with infix, I'm forever trying to remember precedence rules and in my own code, just end up wrapping everything in parentheses anyway, to be sure. In lisp, the ordering is always explicit.

For 3, that's one reason why I like Clojure's syntax: it has just enough extra syntax to break up the code and provide visual cues, at least for me.

Re 4, sure, you can even enable macros without homoiconicity, but with s-expressions, I find it to be mentally much simpler because I can just write a template and fill in the gaps and its natural since my code is in that form already. Overall, though, in all but a few cases, I think macros should be avoided in favour of pure data structures and functions, when possible.

You're right. Lisp syntax makes the totally wrong tradeoff of being slightly easier to parse for the machine, and much harder for the human. An eloquent name for it is that Lisp fails the squint test https://www.teamten.com/lawrence/writings/the_language_squin...

I have to say applying the squint test to language design seems immensely confused to me.

The syntactic structure of both "code" snippets seems equally clear (or maybe "uncertain in the same ways") to me, though my understanding might be a bit off if the author has biased the comparison by following generally accepted use of whitespace with one language and not the other.

This looks like another instance of slapping a pseudo-scientific veneer on top of conclusions driven more by untrained gut feeling in order to pretend one's subjective impressions are firmly grounded in objective reality. It's like the phrenology of programming languages.

I love s expressions, i can now manipulate my code semantically thanks to paredit & co. Learning vim is the first step to being able to properly manipulate code. Paredit is the next and last step ;)

Reply on news.ycombinator.com