9 ms·

Asbestos suit on. There are many positive things you can say about Lisp. However, many day-to-day developers, and their managers, believe that Lisp's syntax c

Asbestos suit on. There are many positive things you can say about Lisp. However, many day-to-day developers, and their managers, believe that Lisp's syntax creates nigh-unreadable programs. For example, there's no built-in infix syntax, as opposed to practically all other programming languages, and many modern programmers today expect infix as minimum table stakes for a language. Lisp syntax is extremely simple, but that doesn't mean the resulting code is easily read. Very smart people will disagree with that opinion - especially a number of people on Hacker News!! However, just look up phrases like "lots of irritating silly parentheses" and you'll see that this opinion is extremely widespread. Many people here will disagree with the sentiment, and that's fine, but it's a fact many people believe programs in Lisp syntax are hard to read. A lot of people will reply that Lisp's syntax is simple, that real programs have been written in Lisp, that it has a kind of simplicity/elegance, and that Lisp syntax enables powerful facilities like Lisp macro processing. All of that is absolutely true. Lisp is quite powerful. But trying to convince people that Lisp is "advanced", even though it doesn't support basic capabilities like infix out of the box, is a losing battle. Forth is one of the few other languages that has an odd syntax and lacks support for infix, and it is also rarely used today. Feel free to reply, but thoughtful responses preferred :-).

howlgram 9y ago
I will agree that lisp syntax is hard to read and write, not because it's hard to come up and figure out in what order the parenthesis should be set (or because it uses prefix notation, that's the easiest to get used to), but because it's nigh imposssible to keep track of the parenthesis mentally and visually. Writing lisp involves too much parenthesis-checking to be anywhere near fun. It's not hard to understand, but when it comes to writing complex functions it just spills out of proportion, or maybe I'm just bad at diluting functions into small enough parts. Either way, some large function in C is much simpler to get a grasp of the general control flow. Love the idea, hate actually using it.
- throwanem 9y ago
  If you have to cope with parens and indentation by hand, then sure. A proper editor deals with those for you, and provides facilities for semantic traversal and editing besides.
- TeMPOraL 9y ago
  I disagree. Keeping track of parenthesis is learnable very quickly, and you do it pretty much subconsciously. 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.
  - deleted 9y ago
    [deleted]
jhbadger 9y ago
The thing is most people who say things like "Lots of irritating silly parentheses" or think it is hard to read are generally people who have never used it, or at best had a couple of weeks of Lisp/Scheme in a programming language survey course. Lisp doesn't look like just another ALGOL-like language and so it looks "weird" if you don't know it. It's like somebody who only knows closely related Romance languages like Spanish and Italian thinking English is weird because it isn't just a variation of something they know.
flavio81 9y ago
>However, many day-to-day developers (...) believe that Lisp's syntax creates nigh-unreadable programs (...) Very smart people will disagree with that opinion (...) it's a fact many people believe (...) trying to convince people that Lisp is "advanced", even though it doesn't support basic capabilities like infix out of the box, is a losing battle. 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 -> Lisp is generally at the same speed level as Java on current Oracle JVM, and can be done, with tricks, to perform in the same speed as C or Fortran. In any case it is still 10x to 100x faster than most other popular languages out there like Ruby or Python. 2. There's no good IDE available -> You will find that many Lispers love using SLIME on Emacs for hacking on Lisp. It provides high productivity. 3. Since there are few users, there is little support (forum topics covering your issues) or manuals or guides. -> There are a ton of books on Lisp and most of them are very good, some of them outstandingly good. The reference documentation (CLHS) is really well written. Since this is a language that has endured for decades, the amount of articles or posts written about doing X in Lisp is enormous. 4. There aren't enough libraries -> Not many libraries if we compare with say, Java libs; however so far I've found everything i need for my purposes. And while i wouldn't bother to dive into a Java or C++ library to modify it or understand how it works, usually Lisp libraries (actually "systems" made of "packages") are easy to understand and modify at your will. It also helps that usually Lisp requires few lines of code for achieving something, compared to C++ or Java. 5. Lisp doesn't have static typing. It does have it. But it is optional and depends on the implementation. However the most popular implementation, SBCL, has very good support by it. On the other hand, many Lispers use it for performance reasons rather than safety reasons. Lisp is a very strongly typed language. 6. Lisp doesn't support <insert your favorite programming paradigm> In theory, Lisp can support any programming paradigm, and in practice it supports most programming paradigms out there. 7. Lisp produces unreadable, garbled code. Some of the cleanest code i've seen in my whole 20+ years of programming was Lisp libraries. 8. Lisp can't work for complex or large codebases since it's so hard to read As pointed out, very complex, millions-of-LOC Lisp systems have been created successfully, some of them used today (like aero simulation software). ----- 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.
hood_syntax 9y ago
I understand where you're coming from and agree to a large extent, but I think your hypothetical person's characterization of infix as a "basic capability" is a bit off. It's antithetical to Lisp's design to make use of infix notation. As far as Forth goes, I would say the same thing.
- mclehman 9y ago
  Agreed. Straightforward arithmetic is the capability, in Lisps represented in such a way as to fit with the philosophy of the language. 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.
taeric 9y ago
I don't even disagree on the infix math point, really. I do find it awkward that it makes up a small fraction of what you actually do in most programs. Seems odd that such a minorly applicable point holds such high regard. 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.
- deleted 9y ago
  [deleted]
- peatmoss 9y ago
  On lisp hate: back in the mid-/late-90s on Slashdot it was en vogue to make jokes about lisp. I'm fairly certain it originated in the spirit of the Unix haters handbook, in that it was in-group therapy for the initiated. But then I think it just became a thing that won karma points, and thus was repeated as a truism. 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.
  - taeric 9y ago
    I should be clear that I think I fell victim to that. Specifically, I recall I used to at least laugh at those jokes. Can't remember making them, but I also don't remember really understanding them. So, I could just be projecting. Likely, I am. I would love to be wrong, at least.
  - kazinator 9y ago
    There was no mid-90's Slashdot. It started in late 1997. I should know, I'm user #1484. :)
AdeptusAquinas 9y ago
As a day-to-day developer, but one who wants to learn as much as I can outside of my domain, you are spot on. 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.
- nocman 9y ago
  "replacing every curly bracket with 20 parenthesis (minor hyperbole)" 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))))) But they think that it is totally fine when a C-like langauge ends with: 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.
  - AdeptusAquinas 9y ago
    You might be right in aggregate counts, but the difference is that in a C-style language you have different types of fluff: curly braces, parenthesis, semi colons etc. So the count of any one type is not overwhelming (unless you let your cyclomatic complexity get away from you). In Lisp its almost all parenthesis, so yes it is more. 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.
shawn 9y ago
For example, lisp has no built-in infix syntax I wrote one: https://github.com/shawwn/lumen/blob/6aa017cfd90fba381b6ea1dd23136f6b88c8fdbc/runtime.l#L56-L68 https://github.com/shawwn/lumen/blob/6aa017cfd90fba381b6ea1d... https://github.com/shawwn/lumen/blob/6aa017cfd90fba381b6ea1dd23136f6b88c8fdbc/main.l#L16-L35 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.
kazinator 9y ago
If we randomly sample no-longer-used languages, I suspect we will see infix support more often than not. Infix won't save a language. > 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.
- peatmoss 9y ago
  Some things stay "true" even long after they are not. Lisp is also unbearably slow... as compared to C on 1979 microcomputers.
  - jasonm23 9y ago
    Lisp is pretty slow in comparison to C, that's acceptable. 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.
    - TeMPOraL 9y ago
      What. 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.
    - flavio81 9y ago
      > Lisp is pretty slow in comparison to C, that's acceptable. 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.
progman 9y ago
Your perception confirms my previous post that mediocre developers have a hard time to think in different ways, even to code in non-infix notation. Linux suffers a similar problem. Many people are so used to Windows desktops that they have a hard time to think in different ways, and to appreciate the Linux way which provides not one common desktop but many ones which can freely be chosen. 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/screenshots/listener1.jpg https://common-lisp.net/project/mcclim/static/media/screensh... [2] https://common-lisp.net/project/mcclim/excite.html https://common-lisp.net/project/mcclim/excite.html
- TeMPOraL 9y ago
  I think the best cure for the "lots of silly parentheses" argument is to ask someone to count the amount of (, ), [, ], {, }, < and > characters in their code. Java, for example, is easily on par with Lisp here.
  - pjmlp 9y ago
    My approch is always to start with a normal language example and then start moving parenthesis to the left.
avodonosov 9y ago
You just haven't tried.
ynx10 9y ago
Undoubtedly many people think like this, but I've never been able to understand it. 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.
Jach 9y ago
Lacking infix syntax out of the box is a problem, though not hard to add as a sibling mentioned; for those curious I like linking to this gem dating back to '93 since it's part of quicklisp now https://github.com/rigetticomputing/cmu-infix https://github.com/rigetticomputing/cmu-infix The rest of the syntax being somewhat alien-ish is also a problem, but it goes away with practice. (https://www.thejach.com/imgs/lisp_parens.png https://www.thejach.com/imgs/lisp_parens.png) 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).
- lispm 9y ago
  The Lisp Machine manual documents their infix reader macro: https://hanshuebner.github.io/lmman/rdprt.xml#reader https://hanshuebner.github.io/lmman/rdprt.xml#reader #⋄x:y+car(a1[i,j])⋄ which gets read into something like (setq x (+ y (car (aref a1 i j))))
- deleted 9y ago
  [deleted]
xfer 9y ago
No infix operators is an advantage. I don't like memorizing precedence tables; most of the time people use parens just to be on safe-side anyways. It's even considered good practice in most cases. 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.
ScottBurson 9y ago
The odd thing about the fully parenthesized syntax is that it's offputting at first, but once you've been doing it for a little while, in an editor that does parenthesis matching and auto-indentation, it gets to be just as easy and pleasant to work with as more common languages, or even more so. (Packages like Emacs 'paredit' make it even better. (I haven't tried 'parinfer'.)) 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.
- dreamcompiler 9y ago
  Completely agree. Lisp code I wrote 10 years ago is still very readable to me. It makes perfect sense once you're "over the hump" but you gotta make that investment. 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.
  - abecedarius 9y ago
    The biggest reasons for this are local variables vs. stack ops and parenthesized expressions vs. having to know the arities of the words called. You can add local variables to Forth, but afaik nobody did during its heyday; and "phrasing" your code with whitespace can help some on the latter issue, but it's admittedly not as explicit as parens. (From another one-time Forther and more recent Lisper.)
    - dreamcompiler 9y ago
      Mach 2 Forth for the Mac in the late 80s had local variables and when I wrote a Forth compiler for the TI 34010 I included local variables. They helped a lot, but they still don't make Forth as readable as Lisp.
- Fice 9y ago
  > Packages like Emacs 'paredit' make it even better. 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.
kazinator 9y ago
Here is the thing about infix: the lack of infix probably does hurt, but not lack of the arithmetic infix. There is various syntactic sugar used in programming languages that is front-and-centre, expressing program and data structure, used everywhere. 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).
- TeMPOraL 9y ago
  That's funny because all the popular languages are mostly prefix too. (foo bar baz) is prefix, but so is foo(bar baz).
nickpsecurity 9y ago
The fact that huge number of people couldnt get past the syntax is why I liked efforts such as Dylan: https://en.m.wikipedia.org/wiki/Dylan_(programming_language) 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 https://julialang.org

howlgram 9y ago

I will agree that lisp syntax is hard to read and write, not because it's hard to come up and figure out in what order the parenthesis should be set (or because it uses prefix notation, that's the easiest to get used to), but because it's nigh imposssible to keep track of the parenthesis mentally and visually. Writing lisp involves too much parenthesis-checking to be anywhere near fun. It's not hard to understand, but when it comes to writing complex functions it just spills out of proportion, or maybe I'm just bad at diluting functions into small enough parts. Either way, some large function in C is much simpler to get a grasp of the general control flow. Love the idea, hate actually using it.

throwanem 9y ago
If you have to cope with parens and indentation by hand, then sure. A proper editor deals with those for you, and provides facilities for semantic traversal and editing besides.
TeMPOraL 9y ago
I disagree. Keeping track of parenthesis is learnable very quickly, and you do it pretty much subconsciously. 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.
- deleted 9y ago
  [deleted]

jhbadger 9y ago

The thing is most people who say things like "Lots of irritating silly parentheses" or think it is hard to read are generally people who have never used it, or at best had a couple of weeks of Lisp/Scheme in a programming language survey course. Lisp doesn't look like just another ALGOL-like language and so it looks "weird" if you don't know it. It's like somebody who only knows closely related Romance languages like Spanish and Italian thinking English is weird because it isn't just a variation of something they know.

flavio81 9y ago

>However, many day-to-day developers (...) believe that Lisp's syntax creates nigh-unreadable programs (...) Very smart people will disagree with that opinion (...) it's a fact many people believe (...) trying to convince people that Lisp is "advanced", even though it doesn't support basic capabilities like infix out of the box, is a losing battle. 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 -> Lisp is generally at the same speed level as Java on current Oracle JVM, and can be done, with tricks, to perform in the same speed as C or Fortran. In any case it is still 10x to 100x faster than most other popular languages out there like Ruby or Python. 2. There's no good IDE available -> You will find that many Lispers love using SLIME on Emacs for hacking on Lisp. It provides high productivity. 3. Since there are few users, there is little support (forum topics covering your issues) or manuals or guides. -> There are a ton of books on Lisp and most of them are very good, some of them outstandingly good. The reference documentation (CLHS) is really well written. Since this is a language that has endured for decades, the amount of articles or posts written about doing X in Lisp is enormous. 4. There aren't enough libraries -> Not many libraries if we compare with say, Java libs; however so far I've found everything i need for my purposes. And while i wouldn't bother to dive into a Java or C++ library to modify it or understand how it works, usually Lisp libraries (actually "systems" made of "packages") are easy to understand and modify at your will. It also helps that usually Lisp requires few lines of code for achieving something, compared to C++ or Java. 5. Lisp doesn't have static typing. It does have it. But it is optional and depends on the implementation. However the most popular implementation, SBCL, has very good support by it. On the other hand, many Lispers use it for performance reasons rather than safety reasons. Lisp is a very strongly typed language. 6. Lisp doesn't support <insert your favorite programming paradigm> In theory, Lisp can support any programming paradigm, and in practice it supports most programming paradigms out there. 7. Lisp produces unreadable, garbled code. Some of the cleanest code i've seen in my whole 20+ years of programming was Lisp libraries. 8. Lisp can't work for complex or large codebases since it's so hard to read As pointed out, very complex, millions-of-LOC Lisp systems have been created successfully, some of them used today (like aero simulation software). ----- 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.

hood_syntax 9y ago

I understand where you're coming from and agree to a large extent, but I think your hypothetical person's characterization of infix as a "basic capability" is a bit off. It's antithetical to Lisp's design to make use of infix notation. As far as Forth goes, I would say the same thing.

mclehman 9y ago
Agreed. Straightforward arithmetic is the capability, in Lisps represented in such a way as to fit with the philosophy of the language. 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.

taeric 9y ago

I don't even disagree on the infix math point, really. I do find it awkward that it makes up a small fraction of what you actually do in most programs. Seems odd that such a minorly applicable point holds such high regard. 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.

deleted 9y ago
[deleted]
peatmoss 9y ago
On lisp hate: back in the mid-/late-90s on Slashdot it was en vogue to make jokes about lisp. I'm fairly certain it originated in the spirit of the Unix haters handbook, in that it was in-group therapy for the initiated. But then I think it just became a thing that won karma points, and thus was repeated as a truism. 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.
- taeric 9y ago
  I should be clear that I think I fell victim to that. Specifically, I recall I used to at least laugh at those jokes. Can't remember making them, but I also don't remember really understanding them. So, I could just be projecting. Likely, I am. I would love to be wrong, at least.
- kazinator 9y ago
  There was no mid-90's Slashdot. It started in late 1997. I should know, I'm user #1484. :)

AdeptusAquinas 9y ago

As a day-to-day developer, but one who wants to learn as much as I can outside of my domain, you are spot on. 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.

nocman 9y ago
"replacing every curly bracket with 20 parenthesis (minor hyperbole)" 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))))) But they think that it is totally fine when a C-like langauge ends with: 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.
- AdeptusAquinas 9y ago
  You might be right in aggregate counts, but the difference is that in a C-style language you have different types of fluff: curly braces, parenthesis, semi colons etc. So the count of any one type is not overwhelming (unless you let your cyclomatic complexity get away from you). In Lisp its almost all parenthesis, so yes it is more. 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.

shawn 9y ago

For example, lisp has no built-in infix syntax I wrote one: https://github.com/shawwn/lumen/blob/6aa017cfd90fba381b6ea1dd23136f6b88c8fdbc/runtime.l#L56-L68 https://github.com/shawwn/lumen/blob/6aa017cfd90fba381b6ea1d... https://github.com/shawwn/lumen/blob/6aa017cfd90fba381b6ea1dd23136f6b88c8fdbc/main.l#L16-L35 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.

kazinator 9y ago

If we randomly sample no-longer-used languages, I suspect we will see infix support more often than not. Infix won't save a language. > 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.

peatmoss 9y ago
Some things stay "true" even long after they are not. Lisp is also unbearably slow... as compared to C on 1979 microcomputers.
- jasonm23 9y ago
  Lisp is pretty slow in comparison to C, that's acceptable. 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.
  - TeMPOraL 9y ago
    What. 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.
  - flavio81 9y ago
    > Lisp is pretty slow in comparison to C, that's acceptable. 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.

progman 9y ago

Your perception confirms my previous post that mediocre developers have a hard time to think in different ways, even to code in non-infix notation. Linux suffers a similar problem. Many people are so used to Windows desktops that they have a hard time to think in different ways, and to appreciate the Linux way which provides not one common desktop but many ones which can freely be chosen. 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/screenshots/listener1.jpg https://common-lisp.net/project/mcclim/static/media/screensh... [2] https://common-lisp.net/project/mcclim/excite.html https://common-lisp.net/project/mcclim/excite.html

TeMPOraL 9y ago
I think the best cure for the "lots of silly parentheses" argument is to ask someone to count the amount of (, ), [, ], {, }, < and > characters in their code. Java, for example, is easily on par with Lisp here.
- pjmlp 9y ago
  My approch is always to start with a normal language example and then start moving parenthesis to the left.

avodonosov 9y ago

You just haven't tried.

ynx10 9y ago

Undoubtedly many people think like this, but I've never been able to understand it. 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.

Jach 9y ago

Lacking infix syntax out of the box is a problem, though not hard to add as a sibling mentioned; for those curious I like linking to this gem dating back to '93 since it's part of quicklisp now https://github.com/rigetticomputing/cmu-infix https://github.com/rigetticomputing/cmu-infix The rest of the syntax being somewhat alien-ish is also a problem, but it goes away with practice. (https://www.thejach.com/imgs/lisp_parens.png https://www.thejach.com/imgs/lisp_parens.png) 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).

lispm 9y ago
The Lisp Machine manual documents their infix reader macro: https://hanshuebner.github.io/lmman/rdprt.xml#reader https://hanshuebner.github.io/lmman/rdprt.xml#reader #⋄x:y+car(a1[i,j])⋄ which gets read into something like (setq x (+ y (car (aref a1 i j))))
deleted 9y ago
[deleted]

xfer 9y ago

No infix operators is an advantage. I don't like memorizing precedence tables; most of the time people use parens just to be on safe-side anyways. It's even considered good practice in most cases. 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.

ScottBurson 9y ago

The odd thing about the fully parenthesized syntax is that it's offputting at first, but once you've been doing it for a little while, in an editor that does parenthesis matching and auto-indentation, it gets to be just as easy and pleasant to work with as more common languages, or even more so. (Packages like Emacs 'paredit' make it even better. (I haven't tried 'parinfer'.)) 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.

dreamcompiler 9y ago
Completely agree. Lisp code I wrote 10 years ago is still very readable to me. It makes perfect sense once you're "over the hump" but you gotta make that investment. 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.
- abecedarius 9y ago
  The biggest reasons for this are local variables vs. stack ops and parenthesized expressions vs. having to know the arities of the words called. You can add local variables to Forth, but afaik nobody did during its heyday; and "phrasing" your code with whitespace can help some on the latter issue, but it's admittedly not as explicit as parens. (From another one-time Forther and more recent Lisper.)
  - dreamcompiler 9y ago
    Mach 2 Forth for the Mac in the late 80s had local variables and when I wrote a Forth compiler for the TI 34010 I included local variables. They helped a lot, but they still don't make Forth as readable as Lisp.
Fice 9y ago
> Packages like Emacs 'paredit' make it even better. 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.

kazinator 9y ago

Here is the thing about infix: the lack of infix probably does hurt, but not lack of the arithmetic infix. There is various syntactic sugar used in programming languages that is front-and-centre, expressing program and data structure, used everywhere. 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).

TeMPOraL 9y ago
That's funny because all the popular languages are mostly prefix too. (foo bar baz) is prefix, but so is foo(bar baz).

nickpsecurity 9y ago

The fact that huge number of people couldnt get past the syntax is why I liked efforts such as Dylan: https://en.m.wikipedia.org/wiki/Dylan_(programming_language) 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 https://julialang.org