It reminds me of the quote "Who knows only hammers as a tool considers every problem a nail".

Also the typical claim that LISP just means "lot of silly parentheses" points out that those critics have never tried to develop in the Lisp way. Ironically, as time goes on and complexity rises, more and more developers appreciate new features which have been available in Lisp for more then 50 years -- lambda expressions, maps, and macros for instance. Lisp was so far ahead of its time that people today still have problems to realize what is so fascinating about Lisp, and why Lisp machines are so awesome. They should take a look at the graphical shell [1] of McCLIM [2] (a revival of the famous CLIM GUI) to see that powerful desktop computing can be very different.

[1] https://common-lisp.net/project/mcclim/static/media/screensh...

[2] https://common-lisp.net/project/mcclim/excite.html

I understand this is hard to believe if you haven't tried it, and it certainly does take some getting used to. Lisp is, in short, an acquired taste. Think of it like very spicy food: many people avoid it, but those of us who like it, like it a lot.

Contrast this with Forth, which I was at one time equally expert at, and where I could rarely read my own code 10 days later.

(From another one-time Forther and more recent Lisper.)

Not just better — it's a leap from editing code as plain sequence of lines of characters to editing code structurally. And lisp syntax enables complete and uniform structural editing across all contexts from simple arithmetic expressions to complex top-level definitions.

Sadly, I assert that this being the main irritation of LISP is one more of fashion than it is of actual applicability. Sad, because I do have pride in our communities to want them to be above fashion. Most people that "hate" LISP have never written a single line of it, ever. Nor will they ever do so.

I remember working the university computer helldesk in the late nineties and repeating such a joke to the smartest white-bearded Unix wizard I've ever met. He rattled off five or six more jokes about lisp, and then proceeded to explain the AI systems he used to work on, and why it was his favorite language.

Having never really coded in lisp myself, I was immediately ashamed of the fact that I had been thoughtlessly making light of a thing that others valued. And years later, I'm atoning by trying to use Racket (sometimes Clojure) whenever I can.

So, I could just be projecting. Likely, I am. I would love to be wrong, at least.

And #5648, but I was a lurker for some time before a friend convinced me to register.

EDIT: but yes, lisp hate meme was probably firmly late 90s

> fact many people believe programs in Lisp syntax are hard to read.

It's not a fact; it's just a couple of trolls, plus people just repeating what they have heard. People who reply to "lisp" with "lots of irritating silly parentheses" haven't necessarily even tried to read any examples of Lisp; they are just repeating a joke they heard.

Just like how people who say "fix it again, Tony" when they hear "Fiat", who have never driven a Fiat, and have no idea about the statistics of Fiat reliability relative to other makes of car.

PS: The Part regarding Fiat is interesting, because we have a similar saying in Germany, namely: "Fehler in allen Teilen", which translates to "Errors in every part".

I have really no idea about the statistics about fiat reliability though, so don't take that as a statement from me^^

As a quick self test stand up a C http server using gnu microhttp, hit it with AB or Wrk.

Next stand up a http server in sbcl (e.g. using wookie) and do the same AB or Wrk load test.

If you are expecting common Lisp to come close to C or even JVM you will be quite disappointed.

I know I was.

I love Lisp but it's a unwise to compare it with C on performance.

I do entirely expect SBCL to come within factor of 2 to C (if you instrument your Lisp code with type declarations properly), and definitely to get JVM performance. And even unoptimized CL code I expect to run faster than Ruby, Python or JS.

Modern CL implementations are good, and the language itself gives you plenty of ways to help the program compile down to efficient native code.

It is not. (Common) Lisp can be made as fast as C if you really need it, by using tricks...

By the way, for a while, the fastest HTTP static server was one written in Lisp, "teepeedee2", 2009. Fastest in the world.

But I don't think syntax alone is enough to explain Lisp's apparent languishing (though only apparent since it seems to be on the rise again), because we have Clojure. Clojure has the same syntax issues as Lisp (ok a bit fewer because of no reader macros and there's an argument that bracket variety is more pleasant to read) yet it's very popular all things considered. And because Clojure has a BDFL, if lacking infix OOTB was really an issue (I don't think it's come up in any of the annual surveys), RH could just include one of the libraries for it out of the box. SBCL could do that for Lisp, but it would be non-standard.

To me there are several stronger drivers for language adoption than anything the language itself offers. Here are three: having a BDFL (Python, Perl, PHP, Clojure... not Lisp), having big corporate backing (Swift, Objective C, C#, Go, arguably Java but driven by more than 1 megacorp... not Lisp), being the lingua franca of a very widespread platform (Javascript (web), PHP (shared web hosts), Bash, C/C++ (unix, windows), Java (android)... not Lisp, maybe if the Lisp Machine had won but it didn't).

https://hanshuebner.github.io/lmman/rdprt.xml#reader

  #⋄x:y+car(a1[i,j])⋄

  (setq x (+ y (car (aref a1 i j))))

I can see how lots of parentheses can look irritating (particularly at the end of expressions). But once you are familiar with it(it's not that hard) you can just read between parens and you don't see them anymore(most lisp code is well-indented). There is also a thing called sweet-exp that is supported by some popular lisps.

I'm forced to use other languages and rarely have the time to do something in Lisp for fun, but when I do, it is the most readable and least eye-straining language that I know.

Python is far more eye-straining in its monotony.

I understand other arguments: I'd like batteries included outside Lispworks/Allegro, larger repositories of examples that reflect best practices, perhaps even an improved Common Lisp.

But readability? I just don't get it.

https://en.m.wikipedia.org/wiki/Dylan_(programming_language)

A bit better. Then, the approach closest to mine of mixing 3GL syntax with LISP was Julia language. It was femtolisp underneath with a syntax more like a traditional language. You get the power without the ugliness. Dylan I havent seen in a long time but Julia is taking off. Look into it if you havent.

https://julialang.org

It's not like the majority* of languages see infix (or prefix, postfix, postcircumfix, etc.) notation as a basic enough concept to allow defined functions to make use of it. Arithmetic always seems to be the special case. No operator overloading, but arithmetic is pre-overloaded. Parentheses of function calls are all you need to keep track of subexpressions, but arithmetic will have an arbitrary and large list of precedences.

*correct me if I'm wrong. I know a fair few languages but mostly deep dives into particular niches. That could bias me.

I believe that most programmers won't have that much problem with (+ (* x x) (* y y)), but even those who don't will balk at cruft like (aref a 3), and (slot-value obj 'foo).

In the TXR Lisp language, I provide a set of well-targeted syntactic sugars for things like this; sugars which do not disturb the surrounding Lisp expressions and don't introduce ambiguities (precedence and associativity).

A trick that did it for me: I started solving SICP exercises using pen and paper. It took few lines of Lisp written with correct indentation style in mind, and my brain internalized the concept, making me no longer consciously count the parens.

But note the use of the "believe" word. As you point out, it's all beliefs. There are also programmers that know Javascript but believe that programming in Python must be hard (true story). Beliefs.

Then there are people, like myself, that once they use Lisp enough, feel that almost any other language would be torture compared to used Lisp. And i love the parentheses.

The problem, and this is a problem in all aspects of programming, is that people like to "believe" things about something they don't know enough to have a reliable opinion of.

So the parent question was something like "if Lisp is so good, why isn't popular?". Are good things always popular? Are popular things always good?

If really really good music must be popular as well, then you would turn on the radio (or MTV, or VH1 on the TV) and all music would be Bach, Beethoven, Debussy, Stravinsky... you get the idea. Or if you are a rock or jazz fan, include in that list the very best of the genre (i.e. John Coltrane, etc.)

If popular music must be good as well then perhaps Justin Bieber and Shakira are masters of music and we should revere them.

In my view, the reason Lisp isn't popular today starts with the Unix becoming popular and mainstream. Unix ran fast on cheap hardware (minicomputers, PDP-x). Little by little C became accepted as a standard for systems programming.

So by early 1980s C becomes mainstream; operating system APIs are then majorly written in C, even more so in the 90s (i.e. Windows API), thus the next popular languages are modeled on C: C++, and then Java which holds the same syntax and is quite influenced by it. Afterwards cue all the other languages made for overcoming some of Java's drawbacks, like C# and others.

Meanwhile Lisp was simply let behind in terms of popularity. But at the same time during the 90s and 00s it was used for important, complex stuff: air travel reservation, aerodynamics simulation, credit card transaction checking, auto-piloting the deep space one spaceship for days...

It wasn't forgotten, since Lisp never stalled from evolution, it has kept evolving since 1958, it has never stopped; the enthusiasts are still creating more good tooling, more libraries, even really nice stuff like Portacle that makes installing a complete Lisp programming environment a one-click operation.

So, it all depends on beliefs of the people versus actual usage. Some of the beliefs and myths held by people, besides the parentheses thing, are for example (my example is biased to Common Lisp)

    1. Lisp is slow

    2. There's no good IDE available

    3. Since there are few users, there is little 
    support (forum topics covering your issues) or manuals or guides.

    4. There aren't enough libraries

    5. Lisp doesn't have static typing.

    6. Lisp doesn't support <insert your favorite programming paradigm>

    7. Lisp produces unreadable, garbled code.

    8. Lisp can't work for complex or large codebases
    since it's so hard to read

-----

Now, something that is true is that Lisp is hard to learn: If you use Lisp, a very powerful language, then you ought to use the full power of Lisp. And for this, you would need to be familiar and handy with all of the most popular programming paradigms (procedural, imperative, functional, OOP, declarative), AND you would also need to understand and know how to take advantage of metaprogramming (macro programming). For many programmers, this represents a challenge. Even if they already know OOP, they don't really know OOP the Lisp way, since the object system (CLOS) is different and more powerful than the typical OOP facilities provided by Java or C++.

But those "pre-requisites" are in fact the "pre-requisites" for any programmer to become a really good programmer, regardless of the language....

Once these "pre-requisites" are met, learning Lisp itself is rather easy, since the syntax is easy and most features are orthogonal to the language.

I wrote one: https://github.com/shawwn/lumen/blob/6aa017cfd90fba381b6ea1d...

https://github.com/shawwn/lumen/blob/6aa017cfd90fba381b6ea1d...

It's an experimental feature, but it seems to work fine with no ambiguities. It also has "x = 42" for implicit local variables, rather than "(let x 42 ...)"

What do you think of it? Is it much more readable? I'm still debating whether to keep it.

I generally work in an OO language (C# specifically) and have long wanted to get into functional programming. I am finally making headway, but after false starts in lisp (racket, clojure) ultimately I am using F#. Partially, admittedly, due to the .NET aspect (its even shipped as part of default dotnet core) but also because of the lack of parenthesis.

One of the reasons to go functional was to get away from the excessive syntax and formality of a C-based language, and replacing every curly bracket with 20 parenthesis (minor hyperbole) doesn't achieve that for me.

It isn't even minor hyperbole, it's just plain false.

It has been my experience that, generally speaking, the combination of curly brackets { }, square brackets [ ], and parens ( ) in languages with C-like syntax is at worst roughly equivalent to the number of parens in most lisp dialects.

Some people freak out because they see a function in a lisp that ends with:

  some-final-expression)))))

          some_statement_or_expression
        }
      }
    }
  }

If the stacks of parens at the end bother you so much, there is nothing in most lisps preventing you from indenting them on lines too:

  some-final-expression
        )
      )
    )
  )

I wouldn't advise it, but you can do it.

I think more than anything, people are just unwilling to accept that lisps look different than the X number of curly-bracket-style languages they are used to. It looks weird to them at first, because of past experience, so to some degree they are looking for a reason to write them off from the beginning.

When I was in college, I had this initial reaction, and didn't even consider anything lisp-like for many years. It was only my frustration with the limitations of C-like langauges that led me to reconsider lisps years later, and man am I ever glad I did.

[EDIT for additional comment]:

and btw, I'm a "day-to-day developer" also.

That's basically how I write functions in Lisp, with indentation levels and every closing parenthesis on a separate line.

The thing is, when you're done writing a (leaf)function in Lisp, you're done: it works. Since you won't need to revisit it (unless the functional design changes), you clean it up for compactness by grouping all closing parenthesis together.

I could be the only one, but I've always found it normal and practical to develop with indentation, and regroup when I'm done.

Besides which my point is more that why have any of this at all? Only the insane write code without tab or space indentation, and if you are doing that anyway then an OCaml-esque language like F# where that serves as your grouping syntax is the saner option.

^ um, and who exactly suggested that? Certainly not me.

And if you think lisp style languages are generally written without tab or space indention, then you clearly haven't read much lisp code.

I thought you said you tried Clojure? Clojure's data literals use curly braces (maps, sets), square brackets (vectors) and parens (lists). I think that's a good thing -- they function like parens but are just distinct enough to make the underlying type more obvious.

Even so, the parens don't get in the way of scheme/lisp programmers. You really do get used to it (usually even like it) after a while (oh and many scheme's use square brackets for function arguments, etc).

"why have any of this at all?"

^ because the parens serve a very important purpose. They group code and data in a very compact, clear, and easily parseable(sp?) way -- a way that allows for extremely powerful manipulation of both. The fact that you don't understand this is evidence that you haven't put in enough effort to appreciate the power of lisp-like languages. I'm not suggesting that you have to like lisp or its syntax, but to suggest that the way it is designed is "insane" is just ridiculous.

Using indentation as grouping is by no means "saner" than using parens. Whitespace is too easy to get wrong or to misinterpret. Heaven help you if you try to implement macros that use whitespace for grouping.

I didn't suggest you implied that lisp isn't written without indentation. Yes I have coded with lisp, and I know they use other syntax than just parens.

Parens serve an important purpose with lisps, just like the semi colon does in c languages. As a C# programmer I can, and have, written long statements on one line; in particular, LINQ statements lend itself to this if you use the method syntax, which I use exclusively over its query syntax form. To make it readable you break it over lines but terminate with a semi colon to finish: it is still run as a single statement. This is powerful.

In F# you can still do this, but it requires that the entire statement start at the appropriate indentation in order for the compiler to infer the closure.

Indentation can cause misinterpretations, but I'd argue, at least for me, that the happy case (i.e. 99% of a given codebase) that using indentation instead of parens, curly braces or similar, is a less clutter free way of writing code. And, since its something that is generally done anyway, it makes curly braces/parens redundant. Note that in F# you can use parens as well to group code, if you need to enforce a closure, which is a good design decision: make them optional. C# would be much better, and I would argue (again at my peril) that if it was optional in a lisp-style language as well, that would be great.

The reason you are getting downvoted is not just because you are criticizing Lisp, it is also because you are posting a bunch of BS without understanding the difference between a context-free and a context-sensitive language. Please learn some basic parsing theory and then you will understand why your suggestion for a white space sensitive syntax for a homoiconic programming language is nonsense.

^ making parens optional in a lisp would IMHO make everything more complicated at best.

Someone else in this thread mentioned SRFI 49. Personally I don't find it's syntax...

  define
   fac x
   if
    = x 0
    1
    * x
      fac
       - x 1

  (define (fac x)
   (if (= x 0)
     1
     (* x 
      (fac (- x 1)))))

I agree with sedachv. Your "mistake" is not that you are criticizing lisp. It's just that those of us here that know lisp don't see your criticism as being valid, and we do not see your suggestions as being something that would make lisp better, but on the contrary would make it much worse.

  let rec fac x =
    if x = 0 then
      1
    x * fac (x - 1)

  let rec fac = match x with
    | 0 -> 1
    | _ -> x * fac (x - 1)

I understand why people prefer the combination of infix expressions and a possible reduction in the number of bracket-like symbols in their programming language (indeed, as I stated before, I originally found lisp syntax to be weird, and originally I didn't like it). When things are different than what you are used to, it is common to not like them.

However, having spent a considerable amount of time programming in lisp-like languages, I find that the benefits of prefix notation and the use of parens as boundaries in the language far outweigh the costs of having them there. Any discomfort with the aesthetics of the code seems to fade with time for most people (if they are willing to spend enough time using the language to get used to them).

Instead of making disparaging remarks about people's mental health, learn some basic parsing theory:

https://en.wikipedia.org/wiki/Context-sensitive_grammar