Why do people put up with the Lisp syntax? I get that it's super simple for computers to parse, but it's definitely not pleasant for humans to parse, and humans are the ones reading/writing code.
I would have thought some very simple syntactic sugar would make it a lot nicer to work with. Has anyone done that?
People don’t put up with Lisp syntax, we actively enjoy it. Some of us find it very pleasant to read.
Most folks probably had a fair amount of difficulty as children associating letter shapes with sounds, and then with words. Languages such as English have all sorts of historical cruft in their orthography, syntax and grammar, and yet we write poetry in it anyway.
Syntaxes that are hard for computers to parse are also hard for humans to parse.
But, nobody literally parses Lisp syntax: you rely on indentation, just like when you're writing C, Java, shell scripts.
People working in Lisp like Lisp syntax; it's really easy to edit, very readable, very consistent.
Anything new in the language, whether coming from a new release of your dialect or someone's new project, is a list with a new keyword, and predictable syntax! Syntax that works with your editor, tooling, and readability intuitions.
If you work involves a lot of numerical formulas, the Lisp way of writing math isn't always the best. You might have documents for the code which use conventional math and someone going back and forth between the doc and the code may have to deal with the translation.
Most software isn't math formulas. The language features that need ergonomics are those which address program organization.
There are ways to get infix math if you really want it in that code.
> Has anyone done that?
Over and over again, starting in the 1960's.
1. 1960's: Defunct "Lisp 2" project run by John MacCarthy himself. Algol-like syntax generating Lisp code under the hood.
2. 1970s': CGOL by Vaughan Pratt (of Pratt Parser fame).
3. Others:
- Sweet Expressions by David A. Wheeler (for Scheme, appearing as a SRFI).
- Dylan
- infix.cl module for Common Lisp
- Racket language and its numerous #lang modules.
The common thread in "syntactic skins" for Lisp is two fold: they all either died, or turned into separate languages which distanced themselves from Lisp.
None of the above skins I mentioned received wide spread use and are defunct, except maybe Racket's various #lang things.
However, Lisp has inspired languages with non-Lisp syntax: some of them with actual Lisp internals. For instance the language R known for statistical capabilities is built on a Lisp core. It has symbols, and cons-cell based lists terminated by NIL, which are used for creating expressions. The cons cells have CAR and CDR fields!
The language Julia is boostrapped out of something called Femtolisp, which is still buried in there.
> Syntaxes that are hard for computers to parse are also hard for humans to parse.
This is obviously untrue. People aren't computers. Obviously there's some relationship, but it's clearly not 1:1.
> it's really easy to edit
Is it? Kind of looks like a formatting nightmare to me, though presumably auto-formatters are pretty much a requirement (and I guess trivial to implement).
If you remove the syntactic sugar like operators (which includes assignment and curly braces - it all desugars into function calls!), R is basically a lazily evaluated Lisp with S-expressions written as C-style function calls. By "lazily evaluated" here I mean that each argument is actually passed as the underlying S-expr + environment in which it was created, so it can either be evaluated when its value is needed, or parsed if the function actually wants to look at the syntax tree instead (which covers a lot of the same ground as macros).
So the existence of R is evidence that Lisp's syntax is a serious problem. If a language providing syntactic sugar has a significantly increased adoption rate, that suggests that the bitter pill of your syntax is a problem :-).
Language adoption is a complicated story. Many Lispers won't agree with me anyway. But I do think the poor uptake of Lisp demands an explanation. Its capabilities are strong, so that's not it. Its lack of syntactic sugar is, to me, the obvious primary cause.
R isn't simply syntactic sugar over a Lisp-like runtime, to make it acceptable, but an implementation of an earlier language S, using Lisp techniques under the hood.
In fact, I recommend to newbies that their Lisp syntax highlighting shades the parentheses close to your background color. You get the best of both worlds: they fade away, but you can use Structural Editing.
I read these articles with Go or Rust code examples and just tune out because I don't use either of those languages so don't know enough to extract the wheat from the chaff, as they say.
Hell, I don't even know scheme enough to read/write code without having to look up the syntax and I've been hacking on a scheme interpreter off and on for years.
Something about different strokes for different folks...
I've written a lot of Lisp in my past. I'm used to reading Lisp. Still hate it. For example, everyone else has figured out that mathematical notation uses infix. Stock Lisp's inability to handle infix notation means most software developers will not consider using it seriously. Obviously not all will agree with me :-).
I will give my answer, noting that not everyone will agree with me :-).
The vast majority of software developers do not put up with Lisp syntax. The vast majority of software developers use a different programming language with a much better syntax, and never consider using Lisp for anything serious. For example, for most developers, a programming language is a laughable nonstarter if it cannot use infix notation for basic arithmetic, as that is the standard notation for mathematics worldwide and is taught to everyone.
As evidence, look at TIOBE:
https://www.tiobe.com/tiobe-index/
... you'll see "Lisp" is #26, lower than Classic Visual Basic, Kotlin, Ada, and SAS. Scheme and Clojure aren't even in the top 50, so adding them wouldn't change much. Lisps will never break the top 10 with their current syntax.
There is a reason for Lisp's syntax: it's homoiconic, enabling powerful macros. Lisp macros are incredibly powerful, because you can manipulate programs as data. Other macro systems generally don't hold a candle to Lisp's. The vast majority of "simple syntactic sugar" systems for Lisp lose homoiconicity, ruining Lisps's macros. This was even the problem for the M-expressions created by Lisp's original developer. Most of those syntactic improvements also tend to NOT be backwards-compatible.
There is a solution. I developed curly-infix expressions, SRFI-105 https://srfi.schemers.org/srfi-105/ Curly infix enables infix notation WITHOUT losing homoiconicity or requiring a specific meaning for symbols. On top of that I developed sweet-expressions
SRFI-110 https://srfi.schemers.org/srfi-110/ . These are backwards-compatible (easing transition) and homoiconic (so macros keep working). There are no doubt other approaches, too.
In general getting anything accepted and used is hard.
Here's my personal take, though: Almost all programmers abandoned Lisps decades ago, in large part due to its terrible syntax. The few who still use Lisp tend to like its notation (otherwise they wouldn't be using Lisp). Since they like Lisp syntax, they don't see the problem. Cue the "this is fine" cartoon dog in a fire. This means that Lisps will never be seriously considered by most software developers today, due to their user-hostile syntax. Some will learn them, as a fun toy, but not use them seriously.
I think that is a terrible shame. Lisps have a lot going for them. For certain kinds of problems they can be an excellent tool.
I realize most people who seriously use Lisp will disagree with me. That's fine, you're entitled to your own opinion! But as long as Lisp has terrible syntax (according to most developers), it will continue to be relegated to a (relative) backwater. It will continue to be learned, but primarily as an "elegant weapon" from a bygone "civilized age" https://www.explainxkcd.com/wiki/index.php/297:_Lisp_Cycles
Even MIT's 6.001 (Structure and Interpretation of Computer Programs), which once taught powerful concepts using Scheme, has been replaced by a course using Python. Reason: "starting off with python makes an undergraduate’s initial experiences maximally productive in the current environment". Scheme did not help them be maximally productive. See: https://cemerick.com/blog/2009/03/24/why-mit-now-uses-python...
I like Lisp. I don't like Lisp syntax. Since most Lispers don't want to fix Lisp syntax, or don't believe it's a problem, the vast majority of software developers have decided to use a different programming language that has a syntax they prefer to use. The numbers from TIOBE make it clear Lisp isn't a common choice.
You'll no doubt get different views in the comments. :-)
I don't think it's necessarily infix math. Most code is not math heavy. But code bases tend to be heavily loaded with those language features that drive program organization, like object-orientation.
Common Lisp's "problem" isn't so much (* x (y + z)) but rather (fun (slot-value foo 'bar) (slot-value (slot-value xyzzy 'bag) 'element)).
The with-slots macro is not really an answer. It's an extra blurb you have to write, for something simple that just looks like fun(foo.bar, xyzzy.bag.element) in another language. Slot readers and accessors help. If the class you're using hasn't defined them, should you?
I have a suspicion that newcomers to Lisp who are able to get past the way arithmetic is written balk when they see how object oriented-glue code looks.
In the back of my mind I'm wondering whether regular parentheses couldn't incorporate the curly infix syntax.
In particular, a Lisp-2 helps here. Suppose we have (x + y). If that is interpreted as arguments + y passed to function x, it makes no sense. There is no such function, and + has no variable binding. So we can take the second interpretation: swap the first two positions.
Even in a Lisp-1, we can simply have a rule that if the second position of a funcion call is the member of a set of math operators (which could be by symbol identity, without caring about the binding), we do the swap.
The users then just can't use + as a variable name in the second position of a function call.
This swap can be done during the macro-expanding code walk, so the interpreter or compiler only see (+ x y), just like with brace expressions.
I would have thought some very simple syntactic sugar would make it a lot nicer to work with. Has anyone done that?