4 ms·

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 major

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/ 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/ 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/ 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 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-instead-of-scheme-for-its-undergraduate-cs-program.html 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. :-)

rootnod3 2y ago
What makes you so sure that the placement in the TIOBE index is due to its syntax? That sounds like a weird argument to me. By that logic, Lua, Scala and Elixir have even weirder syntax that people despise.
kazinator 2y ago
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.
kazinator 2y ago
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. The focus on infix may be misplaced.

rootnod3 2y ago

What makes you so sure that the placement in the TIOBE index is due to its syntax? That sounds like a weird argument to me. By that logic, Lua, Scala and Elixir have even weirder syntax that people despise.

kazinator 2y ago

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.

kazinator 2y ago

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. The focus on infix may be misplaced.