Lisp syntaxes aren't really buying you anything

It should be noted that the practical difference between using a lisp syntax and using a normal syntax is small, so every argument I make in favour of the normal syntax is going to sound trivial, because all disagreements about syntax are inherently trivial.



But we still have to have them.







Lisp's ease of parsing

Lisp syntaxes make it easy to write parsers and add new syntax fast.



For 98% of the duration of the development of the language, this does nothing for you. You aren't touching the parser and you aren't routinely adding new syntaxes. It makes it easier to start a language project, but do we need it to be easy to start a language project? Is fast-solution startup language design something the world needs more of?



Lispish syntaxes are better for doing procedural macros, but not by much

Procedural macros are alienating. There is nothing that makes it harder for new entrants to contribute to your codebase than a frivolous extension of the language. You're literally not speaking the same language any more, you're speaking a different language, that you just made up, for this. DSLs can be very helpful and powerful in some cases, but you shouldn't be writing them every day.



Edit (2022): I'm a lot more open, these days, to the possibility that you should be writing them every day, or if not every day, at least every week (while using them every day). This has swayed me towards lisps by quite a bit. In this frame, the paren has to be fundamental, for demarcating changes in parsing context. To nest languages, parens always have to be properly balanced in every language level. I'm now less certain.



In the rare cases that extending the language is really a good thing to do, Lisp syntaxes make it easier by giving you an extremely intuitive API for reading and generating ASTs. This is nice to have, but not huge. Any language can provide quasiquoting (allows you to write normal code and produce an AST object), and once you have that, you don't even really need to see any documentation of the AST types, figuring out how to generate the ASTs you need is trivial.



There are other difficulties in procedural macros- name sanitization- which lisp syntax does nothing to address. On balance, it seems only slightly ahead.



Lisp itself

I've heard there's a lisp curse. I can imagine why that might be. You have a sort of annoying syntax that makes it easy to do certain things that you shouldn't really do very often, that sets a tone, people try to do those things much more than they should.





Okay but what's wrong with it

So, that's why I don't think Lispish syntaxes are all that good. I'm now going to go through a couple of common code constructs and talk about why the lispish syntax for them is really just kind of bad.



conditionals

Even in a nakedlist language like Termpose or Scopeslang, the following very ordinary conditional syntax... doesn't really work right



if condition  do
  things
else
  doing
  other_things



After parsing, this would translate to two expressions.



(if condition do things)(else doing other_things)



To support this syntax, you'd have to violate one of the premises of lisp syntaxes and join those lists into a new AST node, something like



(if condition (then do_things) (else do_other_things))



That's what Scopes does, because Leonard grew up with reasonable syntaxes and wanted to support them. Traditional lisps, instead, frequently favor a syntax like

(if condition
  (
    do
    things )
  (
    doing
    other_things ))



Which often has more newlines or indentation than anyone wants. You could do this:


(if condition
( do
  things )
( doing
  other_things ))



And while that is quite aesthetically pleasing, it's a bit irregular, isn't it?



invocations

The lispish syntax for invoking a function is

(f a b)

A more normal syntax for invoking a function is

f(a b)



It's one character shorter, a bit more familiar to some (from mathematics), and more immediately distinguishable from any other structure as an invocation (though I suppose syntax highlighting would help the lispish syntax in that respect)





operators

I don't really love infix operators, but you have to have them. We're trained in school to read math with infix operators, we aren't going to learn another in the course of a few rare encounters with it in code. Lisp does nothing for infix operators. They're another reason a modern lispish parser would need to violate the lispish structure.



Most lispish syntaxes opt to avoid infix operators completely by using a prefix syntax even for arithmetic operations. Despite being a bit more verbose (more parens) and unfamiliar, it makes it trivial to define new operators. Since they use the same invocation syntax as any other invocation, they don't have to be known to the parser.



I never want to see any of you define a new operator.



It's an awful thing to do.



Words are easier to guess the meaning of, googlable, and frequently easier to type (letters are on the home row)







I wont talk about any other constructs that you need to depart from lispish purity to have an ideal syntax for, because modern lispish languages have already been doing that and that makes the point more strongly than I could.



I don't think there's anything left to say.