21 ms·

Why is Common Lisp not the most popular programming language?

• edflsafoiewq 3y ago
  Essentially all the Lisp features except for s-expression syntax and attendant macros have been adopted by popular mainstream languages. CL has already given everything it had to give.
  • patrickmay 3y ago
    The Common Lisp condition system is far superior to any alternative in any other language.
    • agumonkey 3y ago
      wait a few years and some web language will "rediscover" it :p
    • edflsafoiewq 3y ago
      Not sure about that, but it's true it hasn't been adopted. There's also some CLOS stuff you can't find in modern languages.
  • pjlegato 3y ago
    Those cases are well served by Clojure, which gives you the macros + a modern, professional, battle-tested standard library (via Java).
  • vindarel 3y ago
    not true, sorry! And if some languages took features, the combination of them is unique in CL. Image-based REPL interactivity, condition system, interactive debugger, restarts, compile-time computing, compile-time checks, incremental typing, speed, a different object system, stability, single-file binaries, connecting to a remote system… Here we restart a buggy program from a single point in the stack: https://www.youtube.com/watch?v=jBBS4FeY7XM https://www.youtube.com/watch?v=jBBS4FeY7XM so we don't re-run everything from zero.
• brlewis 3y ago
  The same reason as why Esperanto is not the most popular spoken language. It's historical reasons and network effects.
  • bottlepalm 3y ago
    No, it's difficult to read and understand. It's a parenthesis circus. For example - https://github.com/dimitri/pgloader/blob/master/src/pgsql/pgsql-schema.lisp https://github.com/dimitri/pgloader/blob/master/src/pgsql/pg...
    • samatman 3y ago
      I clicked thinking I was going to see some gnarly Lisp code. It's out there! This, on the other hand, is perfectly legible if you know the language. I'd say it's even perfectly legible if you don't, but how would I know? There are a couple good examples in there of what I said in another comment, about how, quite aside from getting the hang of reading and writing sexprs, one also has to learn a rather more foreign discipline of building up linked lists in the idiomatic way. Which is a greater barrier than learning to read `(and foo bar)` as `foo && bar`. That part really doesn't take long.
    • brlewis 3y ago
      Esperanto is difficult to read and understand. It's an accent circus. I'm having fun with Typescript these days, but parentheses are what I miss most from my Scheme days. They're objectively better.
    • Nevermark 3y ago
      “Read” the indentation - ignore most of the parentheses.
• BaculumMeumEst 3y ago
  Package management kind of sucks, the ecosystem sucks, other languages continually improve but nobody will ever advance the CL standard. There is nothing compelling about the language to people who aren't already Lisp people.
  • agumonkey 3y ago
    it's paradoxical since lisp people weren't born this way, surely there was some appeal (beyond being influenced by teachings) ;)
    • BaculumMeumEst 3y ago
      I do think there are some traits like curiosity, open mindedness, and patience that make some people more susceptible to infection.
  • floren 3y ago
    Package documentation which seems to mostly consist of a list of variables and function names, possibly with a single sentence describing what the function does. Possibly.
  • siknad 3y ago
    > There is nothing compelling about the language to people who aren't already Lisp people. CL is expression based (like Rust, unlike other mainstream languages I've seen), has a concise macro system (more convenient than Rust's imo), has a GC (simpler to use than languages with manual memory management or RC-only), has a better developed ecosystem then some new languages (ex. automatic ffi generation; while buggy, tremendously helpful compared to writing bindings manually). And it's not pure as in Haskell. And it has type annotations that may be checked at runtime or improve performance. An implementation like SICL could make it viable to use it as a scripting language. Any similar modern languages with better tooling/ecosystem? Perhaps Julia, haven't seen it yet.
  • bsdpufferfish 3y ago
    > nobody will ever advance the CL standard And that’s a good thing.
• pfdietz 3y ago
  Back in the day, it required machines that were more powerful than what C programs could run on. By the time machines caught up and Common Lisp was standardized it was too late.
  • erik_seaberg 3y ago
    Lisp was sort of a testbed for extravagantly expensive features, many of which (not all) became table stakes for newer languages as they got better at writing compilers for much bigger, faster computers.
• kentrado 3y ago
  I love programming in common lisp. It has made programming fun again. I don't know if that makes me a lisp person. I just know it makes programming fun for me.
  • Lyngbakr 3y ago
    I'm curious if you can put your finger on exactly why you find it fun? (While I've never used CL, I do use Clojure and similarly find it huge amounts of fun.)
    • codr7 3y ago
      Clojure is a different beast, not better or worse, just different. CL doesn't have opinions, it's a toolbox.
      • deleted 3y ago
        [deleted]
    • massysett 3y ago
      Because I can eliminate drudgery in a way I can understand. I find that no matter what language I use, I eventually want code that writes code. Other languages have bad tools for this. Sometimes I use an editor, or something else like m4, to generate code. Haskell has Template Haskell, which is icky in a variety of ways, and it has other stuff that I have a hard time figuring out because I’m not a math PhD. In Lisp I just write a macro. Also, I agree strongly with the post below. I like Common Lisp precisely because it is old and unchanging. I like that I can get decades-old used books that are still current. I like that the next compiler version won’t break my code. https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/ https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/
      • samatman 3y ago
        On the strength of your first four paragraphs, I have to plug Julia. It doesn't have the benefit you point to in your fifth paragraph, of having a decades-old standard; stability of the core language is good so long as you aren't comparing it with C or CL. But it has a full-fledged macro system, the kind where you can write an anaphoric if. It doesn't have the Zen of macros in a Lisp, but it has the power, and that's the important part. People have used it to add ML-style pattern matching and Pythonic f-strings, symbolic algebra systems which manipulate the source code, they're genuinely full-featured. It also features multiple dispatch, every function is a multi-method and the type system is designed to support this. The community of practice is quite REPL-focused, although remote REPLs aren't as far along as they are in Lisp world. There are some cases where Revise can't invalidate old code, but most of the time it has the "hit save, use the new program" special sauce. The core language is heavily inspired by Common Lisp, by way of Dylan, and it shows. There might be some other feature of CL which you miss, but it won't be macros.
• johnea 3y ago
  The lack of compatibility in python really is a disaster... It's so great and new that it's not compatible with last week's code...
• commandlinefan 3y ago
  OTOH, I remember reading somewhere that Tanenbaum was happy when Linux came out so that people would stop asking him to make Minix into a real "usable" operating system. There may be something to be said for letting Lisp remain more conceptual/ideal than practical and allowing other functional languages take on the "warts" associated with being used by everybody.
  • deleted 3y ago
    [deleted]
• fooker 3y ago
  It’s more of a toolbox to build languages than a language. So every commonlisp codebase has a different flavor, and anachronistic semantics. No matter how good you are, this is difficult to deal with. Sure, for config files or writing extensions for your favorite piece of software, you’d make the effort. But most software development is not in that category.
  • beanjuiceII 3y ago
    Is it actually that good of a toolbox for building languages? I don't think people really use it much for that either
    • fooker 3y ago
      It's not like you'd often create a named language, it's more like accidentally defining a DSL along with libraries when working on something in a lisp with a decent macro system. As a result, all the client code looks like it's written in a bespoke language. This, while it's a lot of fun, creates write only code.
• samatman 3y ago
  It's the lists. No, not the prefix notation, parenthesis, what have you, although that doesn't help. The lists themselves. In Lisp, code is data, and data is lists. Yes, of course, there are hashmaps, arrays, strings. But idiomatic Lisp code really does use linked lists extensively, it's an entire style of programming. Even if you'd prefer to use different data structures (and again, Common Lisp does support this), you still have to be able to read and reason about the many parts of the language designed for, as the old quip had it, prothething lithts. The "weird looking syntax" does not help, but Lisp hackers are right that you get used to that part, might even appreciate it if macros are something you really care about. Structural editing a la paredit and parinfer are pretty nice too. But when it comes with a weird way of programming, that's a bridge too far for a lot of people. It's harder to learn, read, and reason about, for longer than most languages. I'm glad they mentioned Julia though. Learned everything Dylan had to teach and then some, real treat of a language, and, it turns out, writing macros without cons cells is rather pleasant and powerful. Certainly an acceptable Lisp in my book. Maybe someday they'll add conditions and restarts, that's the one feature CL which gives it an edge on Julia.
  • IshKebab 3y ago
    I disagree. I have no problem with lists obsession in other languages like OCaml. The parentheses are just too much. I get how elegant and unambiguous they are for computers but I am not a computer. It's like RPN. It's elegant and easy for code to parse and unambiguous and all these nice things.... except it isn't easy for me to parse. Compilers are perfectly capable of compiling readable code like Rust so I don't see why I should have to do the tedious work of figuring out all the parentheses manually. Lisp is like a really great IR. But I don't want to program in an IR.
    • JohnFen 3y ago
      > It's like RPN That's genuinely fascinating for me, because I find postfix notation to be more intuitive and easy to parse than infix notation.
      • 3y ago
• iamevn 3y ago
  Personally I'm not especially interested in programming in a language with a separate function namespace. It makes much more sense to me to treat functions more like any other value in the language.
• 2024throwaway 3y ago
  I tried to learn lisp, and this may sound like a trite complaint, but I honestly just could not deal with all the parenthesis. Terrible ergonomics.
  • timbit42 3y ago
    Try an editor that supports Lisps.
    • acdha 3y ago
      This is the kind of answer which drives people away: you just told someone doing one hard thing to do another at the same time, and that also has near certainty that they’ll hit some task which is easy in their default editor but non-trivial in whatever new one you recommended.
  • guenthert 3y ago
    This is so often mentioned, it must be true. Or is it? To put numbers on it, I counted the occurrences of brackets, braces and parenthesis in Frank Busse's Arabesque cellular automata (just a small program for which I had the C version and a Common Lisp translation, which I happened to have looked at recently for no good reason). The C version had 86 of those characters, while the Common Lisp version 196. Yeah, more than twice as many, but can that truly be a chief reason to give up on a language?
    • 2024throwaway 3y ago
      It makes it very hard to, at a glance, parse what is happening.
      • guenthert 3y ago
        I do recall difficulties with this in the beginning (the first few years in my case ;-} And I still find old LISP code (the one where symbols were still capitalized) hard to parse. With modern (say, since the 90s or so), well written style where the depth of the expression is indicated by the indentation, I trust that the editor indented correctly, which allows me to forget about the parentheses. I wouldn't attempt to find a syntax error in a CL program w/o an editor supporting the language. Above might be interpreted as a case for a language with semantic whitespace and w/o excessive parentheses, e.g. like Python, but there I find it all to easy to introduce subtle bugs during refactoring.
• thot_experiment 3y ago
  Because most programming is done by people trying to do a job and it requires broad tooling support and familiarity, LISP is a language that has neither. LISP, (similarly to Haskell) requires you to bend your mind and pay an upfront mental cost in order to access it's benefits, which are that everything is equally easy to describe. No construct in LISP feels like it requires you to bend the language in an awful way because LISP is a fantastically generic tool, some things that are common and easy in other languages are more difficult in LISP, but as you get into the weeds building more complex constructs it will never get in your way. (and since i mentioned it, the benefit of Haskell is that you can make a LOT of statements about your code you know to be true)
  • agumonkey 3y ago
    the upfront mental cost debate is still going, a few people tried teachings lisps as first languages and people didn't struggle i personally cried a few tears when learning java, whereas the weird drscheme class made me all calm and happy programming also blends a few layers into one, and some people are operating at one (line by line modification of data), some want generic infinite freedom[0], you can rapidly see who will enjoy what there [0] one trauma i got during studies is failing an exam because after reviewing ada's manual twice, I couldn't find the page explaining the `object'field` syntax and failed not being able to split a string. i never liked ad-hoc syntax much...
    • quantified 3y ago
      Logo was a great teaching language. If you're not already patterned into C-style programming, it is a great experience.
    • thot_experiment 3y ago
      Yeah that's fair, it also came naturally to me but anecdotally I've found a lot of people struggle with it, especially those who came up through a "get shit done first" type python or java pipeline in a traditional institution or bootcamp rather than having a true CS background.
• pie_flavor 3y ago
  If Racket has what they're looking for and CL doesn't, then that's proof that the assertion is wrong, because Racket is far less popular than CL. The correct answer to the question is the obvious one: the parentheses. Visually, semantically, practically, expressibly, and legibly. And the typelessness, and the ecosystem, and in general the idiosyncrasies, almost none of which add value. All the standard counterarguments have been done to death, none of them are any good, but more importantly, they're not how popularity works.
• 13415 3y ago
  Generally speaking, the best things are not the most popular. There are probably a few exceptions such as classical music, but I've found this rule of thumb to hold in many different domains.
  • Nevermark 3y ago
    People’s ability to process complexity must play into where the peak is. I large culture consisting exclusively of genius composers would no doubt develop styles of music that would relegate our pinnacles of classical music to their “pop”. No doubt there is a bell curve of how easily each of us intuit novel abstraction, vs. benefit from more predictability (i.e. restrictions, enforced patterns). Mainstream languages are going to be more predictable and restrictive or patterned, than programming languages auteurs might prefer.
• taeric 3y ago
  Paraphrasing the point at the end, there is no company that has the financial incentives to promote it. The companies that do have financial interests in CL are ironically not incentivized to promote the free ecosystem around it. For the same reason that commercial C compilers are not really a thing anymore. This is, of course, a simplified view of things. For one, I think Intel still pushes a compiler some. That said, I think it is valid enough, in that Intel isn't pushing the compiler for the sake of the language it compiles, but to push some optimizations that they excel at. There is a question of how explanatory this is. I think it is fairly accurate to say that the marketing and general outreach for many of the successful languages today helped build on their popularity to the point that we know them today. It does not explain the seed of any success, though.
  • znpy 3y ago
    Afaik intel compilers are based on llvm nowadays
    • taeric 3y ago
      Right, I don't know the core details right off, I just meant that it was easy to think of some commercial C vendors that still exist. I think it is fair that there is a difference in having a corporate sponsor, and having a organization chartered to sponsor. (I also have to ack that I don't know of many other C vendors, nowadays?)
• AnimalMuppet 3y ago
  Because despite the enthusiasm of the advocates, it's not actually the most useful programming language. "But I used it for X and it was insanely productive!" Great, but there's a lot of programming that is not X programming. "It's just that the rest of you are not enlightened!" Right... the maharishi's people tell me the same thing. "It perfectly fits the way your mind works!" It perfectly fits the way your mind works. It doesn't perfectly fit the way most of our minds work. Lisp winds up not being the most productive language for the vast majority of programmers. So it's not very widely used.
• assimpleaspossi 3y ago
  I started learning Lisp recently. The text I was reading said people complain about the parentheses and I see a number of people stating that here. But that is not a problem when you have an editor that understands lisp and keeps track of all that for you. Just focus on the code and the editor will take care of the parentheses for you.
  • tmp_eSGPhx 3y ago
    Agreed. At least you can see the parenthesis. and seriously, what is the mental difference between say (print 'hello') and print('hello'), for me the first is easier. They both have the same number of parenthesis, but in the first I can see all the operations that go together. Hating python every time I use it. Python is lies all the way down. "You don't need curly braces or anything to mark your code blocks, only indentation"... until you want a multi-line item, in which case you, well, wrap it in parenthesis. foo = ("a very" "long" "string") is valid python, and so is foo = ("a very", "long", "string") but they give different results. vs (cat "a very" "long" "srtring")
    • Sohcahtoa82 3y ago
      > foo = ("a very" "long" "string") > is valid python, and so is foo = ("a very", "long", "string") > but they give different results. That's because the former creates implicit string concatenation, while the latter is 3 distinct strings. FWIW, while I love Python, I think implicit string concatenation is a huge anti-feature. It is a source of bugs and breaks the Zen of Python which states that explicit is better than implicit. Your first line should by a syntax error, as far as I'm concerned.
• linguae 3y ago
  Common Lisp once had plenty of backing from major companies like Symbolics, Xerox, and Texas Instruments, as well as smaller companies such as Harlequin. Even Apple owned Macintosh Common Lisp at one point, and SK8 (which could be considered a follow-up to HyperCard) was implemented in it. Had Apple not had its problems in the 1990s, one potential alternate version of Apple I could imagine would be some sort of Lisp OS with a Mac interface (true story: the Newton could’ve had a Lisp OS if it weren’t for C++ advocates winning out). Unfortunately, the AI winter of the late 1980s and 1990s severely damaged the Lisp market; companies either abandoned Lisp or went under. The torch of Common Lisp has been carried on by open source and commercial implementations, but there are no major companies actively backing Lisp in the way that Java is backed by Sun/Oracle and that Python is core infrastructure at countless companies, large and small. I didn’t know that conferences could potentially generate a lot of revenue to help fund programming language development. I’m quite intrigued by this idea, actually. Thanks to advocacy of the language, there are probably thousands of Common Lisp developers in the world, many of whom are working on interesting projects. Perhaps a series of profitable Common Lisp conferences will provide the spark needed to come up with a modern Common Lisp foundation that is able to support further development of the language.
  • gumby 3y ago
    > ...one potential alternate version of Apple I could imagine would be some sort of Lisp OS with a Mac interface...Unfortunately, the AI winter of the late 1980s and 1990s severely damaged the Lisp market... Your order is messed up: work on Dylan commenced years after that AI Winter had begun.
    • linguae 3y ago
      Yeah, I should’ve clarified regarding Apple, which wasn’t in the Lisp workstation market. Apple’s departure from Lisp has little to do with the AI winter (though Hacker News commenters lispm and mikelevins may have a lot more insight given their expertise and the fact that the latter worked on Lisp projects at Apple). Rather, I believe Apple’s departure has to do with Steve Jobs’ return. Apple was an unfocused beacon of innovation in the 1990s, with many competing visions for the future of the Mac and the company. When Steve Jobs returned, the vision became unified under him: the technical underpinnings of the Mac were based on NeXT technology, and other competing visions (such as OpenDoc) were discarded.
• lcall 3y ago
  Somebody famous said something like "Lisp makes hard things easy, and easy things hard", which finally, after all these years, clarified it for me. (It was quoted on HN in a previous discussion, and I was impressed with the credentials of the person quoted, but I don't have the reference handy.)
  • dreamcompiler 3y ago
    I've written a great deal of Common Lisp and the only "easy things hard" I've encountered are fast matrix multiplications -- because there are many ways to do this and they each have different tradeoffs, and implementing symmetric crypto algorithms that assume 32-bit word sizes. Because Lisp integers automatically grow when necessary, forcing arithmetic to stay within a 32-but limit is hard do do in pure Common Lisp efficiently. The solution is to write bottleneck routines in assembly, which the Lisp compiler I use (CCL) facilitates.
    • sshine 3y ago
      I haven't written Lisp professionally, but my impression is that one place Lisp comes short is forcing convention: Every program, every module, is potentially its own DSL, so good luck getting programmers to agree on a convention. At least with more rigid languages like Java or Rust, when you open a file, you'll agree what language it is. Haskell has this problem, too. You need things like "Boring Haskell Manifesto" to discourage too much magic. Haskell has "pragmas" that modify the language extensions that turn Haskell into a space language. Pragmas can be enabled on a per-file basis. I like how the Rust toolchain addresses this by letting you gather things like "stable/nightly", "feature flags", "linter suppressions" in a config file at the project root, so that a team can agree on a set of conventions and have the toolchain sync with those decisions made in one place. This isn't strictly speaking programming language, but tooling, but it plays a big role in team governance and cooperation.
      • vindarel 3y ago
        > Every program, every module, is potentially its own DSL it isn't, don't worry. Problem solved ;)
• bigbillheck 3y ago
  Lisp seems to be a language for individualists, which isn't a great way to build a community and beyond.
• hcarvalhoalves 3y ago
  A plausible reason: because no big company is backing it with money. This industry will mostly use whatever Google/Microsoft/Meta sponsors.
  • reikonomusha 3y ago
    Google sponsors Lisp compiler development.
• booleandilemma 3y ago
  For me it's the parentheses. I'm sorry, I know it sounds childish, but it's true. Just look at this picture: https://www.semanticscholar.org/paper/The-programming-language-LISP%3A-Its-operation-and-Monrad-Krohn/087a4409638c408e09062f313aee04ea1007c394/figure/0 https://www.semanticscholar.org/paper/The-programming-langua... We call that "line noise".
  • dreamcompiler 3y ago
    That's code from 1966. It resembles modern Common Lisp the same way "Beowulf" resembles "The Three-Body Problem."
• mypalmike 3y ago
  The vast majority of people who want to create something that executes on a computer are not inclined to write in a language that more closely resembles parse trees than it does human language. To many, Lisp is nearly as inscrutable as an intentionally esoteric language.
  • tim333 3y ago
    It is kind of tricky to read and probably a bit part of Python's success is down to it being maybe the easiest to read, especially for people who are not very techy as it reads kind of like English.
• jll29 3y ago
  C does what I say but not always what I mean. C++ is too complicated to even bother, and looks a completely different language every five years; I have yet to meet anyone that knows its syntax fully (C++ compilers included). Writing C/C++ means spending your time managing memory and then debugging memory management errors rather than thinking about the problem domain. Python is very slow and has horrible package management. Rust compiles slowly and the borrow checker takes a long time getting used to. Java is bloated and Oracle-proprietary. No version of Julia could even compile the example of the Julia book I bought, nor some of its own tutoials. Perl is write-only. ...and CommonLISP? I know important and successful systems have used it in the past, but haven't heard anyone using it for anything I needed recently (but that could be due to my area, search engines, natural language processing and machine learning, where Python libraries - written in C++ to be fast enough - dominate the research frontier). LISPs incl. CommonLISP and esp. Scheme are elegant, minimalist (Scheme in particular) and lack powerful IDEs and library support (at least since LISP machines disappeared), and excess parentheses make for a write-only experience, especially if you have to read the code of others (your own code may make good use of functional abstraction).
  • samatman 3y ago
    > No version of Julia could even compile the example of the Julia book I bought, nor some of its own tutoials. This was either many years ago, or is a skill issue. Post-1.0 Julia backwards compatibility isn't perfect, but it's held to a high standard. Being unable to run its own tutorials is not a thing that actually happens, and the language isn't responsible for bugs in whatever book you were referring to. If this was pre-1.0, sure, that's what a version starting with 0 means. But after? Skill issue.
• jacknews 3y ago
  it's a kitchen sink full of old baggage like car, cdr, caaadr, etc. clojure/cjs/babashka, fennel, janet, racket, etc make more sense to learn.
• readthenotes1 3y ago
  (I once) (worked at a company) (that made (Lisp) machines) and (sold them internally (until the factory managers (wised up) and said (the programmers (are great) (at creating (a functional prototype) but (invariably left for higher pay elsewhere (before completing the job) and (try were always worse off))))
• signaru 3y ago
  I tried before because I read a lot of praise about it. But it seemed to me that there's not much of a standard library or included batteries (at the time, I was looking for something that can open image files or compute FFTs). Perhaps the problems I wanted to solve just weren't a good fit.
• omershapira 3y ago
  * You can't google snippets on stackoverflow * Packages are harder for divergent languages * Momentum Hard to come up with more words to explain it
• bsder 3y ago
  Ecosystem. For example, the Common Lisp ecosystem never converges to a single implementation of any single "thing". Take Rust. You may not like Serde for serialization, but the ecosystem has converged to it. Similarly, Tokio. You use them until you understand why you need something else and then bite the bullet of going against the tide when you can't make them work anymore. Okay, so what serialization has Common Lisp converged to? Uh, yeah, about that ... "Lather, rinse, repeat" this for any value of <X> (serialization, async, objects, concurrency, etc.) and anyone sane quickly reaches the conclusion "Just say no to Common Lisp".
  • bsdpufferfish 3y ago
    That’s also true of c++ and C and doesn’t hold them back.
  • Nevermark 3y ago
    But it is easy to roll your own for your own problem area! —-> Everyone rolls their own! Its an interesting problem.
• harry8 3y ago
  You want to learn programming. Lets get started - how long does that take to bang out 10 exercises? Order the estimated results from quickest to slowest. Here's my estimates (don't like them, show yours! It'll be interesting): - Scratch - python/perl/ruby/javascript - C/Java - Swift/Rust - Anything else running on the jvm - - a whole lot of daylight - - common lisp. And many if not most will fail to get to the first exercise, those that do will start it well after all the rest have completed 10. Land of lisp seemed to be the best learn lisp book and it couldn't even manage to limit itself to one implementation of common lisp that you could use for the entire book. The situation is ridiculous.
  • richardgreeko27 3y ago
    I think had I started with a lisp dialect like Racket and the book The Little Schemer, the speed of getting through those first exercises may have been just as fast or faster than the Ruby and JavaScript I started with. Lisps are hard to switch to but I disagree that they're hard to start with.
    • harry8 3y ago
      Scheme is not common lisp. But you know where you place it on the list. I did sicp w/ racket, a 10 y.o. I know tried simply scheme w/ racket. I'd put it next to anything on the jvm (including clojure) myself. The 10 y.o. puts it way behind python & swift.
  • dadoum 3y ago
    I am curious about the reason you put Swift so low in the list. Like to me it's as easy to output a program in Swift as it is to make one in JavaScript. (except if you count compile times, last time I used it I already thought they were way too slow)
    • harry8 3y ago
      mac only. iirc you have to install xcode too. Compare to perl & python already installed on a mac and relatively easy to set up on windows. But I'd still call it very high on the list relative to common lisp, which is the point.
• mtreis86 3y ago
  Why is Ferrari not the most common automotive manufacturer? Clearly it has something to do with all the pistons.
  • samatman 3y ago
    If Ferrari and Toyota cost the same amount of money, you'd see more Ferrari. SBCL and Python are both free.
• Animats 3y ago
  I've written in Common LISP. Here's my port of the Boyer-Moore theorem prover to CLisp.[1] I've used original INTERLISP. I've used a Symbolics LISP machine. I once did a lot of work in Franz LISP.[2] And I'm partially responsible for AutoCAD going with AutoLISP as a scripting language. I've even taken a class from John McCarthy himself, at Stanford. All that was decades ago. I haven't written a new program in LISP in decades. (In later years Python, Go, Rust, C++, and when forced, JavaScript.) * Early thinking was that programs needed to be able to modify themselves. This turned out to be a niche feature. It was a holdover from the early days of programming, where storing into the code was considered a normal activity. Von Neumann was into that. To index into an array, load instructions were modified in place. Once index registers were invented, that mostly became unnecessary. Languages can be too dynamic. You pay a price for that. Python suffers from the design feature that anything can store into anything at any time. This blocks most compile-time optimizations. * Lists as a primitive are OK, but modifying lists all the time isn't what you really want. Most languages have settled on a useful set of collections today, and their implementations, especially hashes, are highly optimized. Python pretty much got this right, and other languages now use roughly Python's various collection types. * Saving the entire state of the system, instead of having source files, was a really bad idea for anything that had more than one person working on it. * The overly clever macro system makes code hard to maintain. (I tried to port [2] to Common LISP. Got about half way. It has the original Oppen-Nelson simplifier inside, the first of what's now called a SAT solver. Originally written in MACLISP (MIT's Project MAC, not Apple Macintosh), and ported to Franz LISP by Oppen and Nelson, it has too many clever macros that I wasn't able to completely figure out a decade ago.) This is a generic problem with macro systems, of course, which is why C deliberately had a weak macro system. LISP is a blast from the path. It's fun for retro reasons, but things have moved on. [1] https://github.com/John-Nagle/nqthm https://github.com/John-Nagle/nqthm [2] https://github.com/John-Nagle/pasv/tree/master/src/CPC4 https://github.com/John-Nagle/pasv/tree/master/src/CPC4
  • mark_l_watson 3y ago
    Thanks John, you make great points on the advantages of ‘moving on’ from Common Lisp. I still use Common Lisp a fair amount just because it makes me happy to do so. While I need to use Python, using Lisp languages is just a preference. Because I am retired now, I have thought of starting with something bare-bones like Chez Scheme and making a long term hobby of building up my own environment mostly just for myself. The author of Gerbil Scheme started with the excellent Gambit/C Scheme and did this, and now the Gerbil ecosystem is really cool.
• tmtvl 3y ago
  > what we really need is one person who will lead a main CL only conference Well, if you're volunteering... All joking aside, I'm not particularly bothered with the relative lack of popularity CL has, its force-multiplying powers make it easy for a relatively small community to create and maintain a decently sized ecosystem.
• cladopa 3y ago
  A lot have already been said about it: +Lisp Lost the train of microcomputers. They were "toy machines" that needed low level programming like assembly or forth or later C to do anything remotely similar to what Mainframes could do. +Common Lisp is a mess, a compromise, like Deutsch (a language created to take something out of every variant dialect), designed by committee language. Better (opinionated, created by a person) alternative Lisps exist, like Clojure. +Lack of (affordable, easy to use) Visual tools to develop, like Visual Studio. No. Emacs is not easy to use for newbies. Visual structured editing for parenthesis have existed for decades now but those tools were not available for normal PC and even today are very expensive, as the market for them are the companies that bought the expensive Lisp machines in low volume. +Lack of access to the C libraries. Do you want to use anything modern like "dear imgui", iOS libraries or whatever? Bad luck. +Competition catch up. Other languages copied(badly) the Lisp ideas, lambdas and real macros, functional programming. IMHO they did it wrong, but they are good enough for most people, while not having the problems of CL, like being able to use the C libraries as python and Lua can. +Other Lisp are working fine. Clojure for example can use the java libraries or even some versions the C Libraries.
  • siknad 3y ago
    > Lack of access to the C libraries. Isn't CFFI enough for that?
  • Lapel2742 3y ago
    > Lack of access to the C libraries. ??? I recently started learning Common Lisp for fun (and fun it is!) and the ease of accessing C libraries was one of the things that surprised me in a positive way. Using https://github.com/rpav/cl-autowrap https://github.com/rpav/cl-autowrap one can simply write (c-include "file.h") and the API defined in "file.h" is accessible from Lisp. I can't think of a simpler way. Even without cl-autowrap, FFI using https://cffi.common-lisp.dev/ https://cffi.common-lisp.dev/ seems simple enough.
    • panick21_ 3y ago
      I think he was talking about the late 80s and the 90s.
• FpUser 3y ago
  Because languages are created with the purpose in mind and not a single one can tick every box. Also there are factors like user / org preferences, policies etc. etc. There is absolutely no need for one size fits all solution because it will be always wrong. Looks like largely rhetoric question
• zoogeny 3y ago
  I admit that I haven't touched CL in decades and my most recent exposure to Lisp-ish stuff is writing a bit of Scheme and reading a bit of Clojure (maybe some elisp too). I like a lot of the ideas behind Lisp-like languages but I dislike writing in them. Parenthesis, as others mention, start to get unwieldy. I often feel like I'm expressing myself "in reverse", almost like I'm programming in Yoda speak. I mean by that, it often feels like I want to edit/add-to the beginning of a statement rather than the ending of it. Perhaps the discomfort would dissipate with use. But to be honest, I'd rather just grab Python or even Typescript these days for the kind of ease and flexibility where raw performance doesn't matter. And there are other programming languages that excite me more than Lisp (e.g. Elixir, Unison) so my limited free time has plenty of outlets on that front. What surprises me is that Lisp evangelists have this default assumption that their language ought to be entitled to popularity. They have some kind of "if people only knew" mentality, just like in this article, where they assume that the only reason people don't flock to their language is ignorance. Perhaps it doesn't occur to them that people try it out and then leave and never come back.
  • derp38726 3y ago
    >Perhaps it doesn't occur to them that people try it out and then leave and never come back. Once the code is data is code clicks there’s no going back. When you read other languages you just see a lisp DSL, you can’t unsee it because you’ve changed.
    • pests 3y ago
      Isn't this the exact "if people only knew" attitude he mentioned?
      • derp38726 3y ago
        Yes it is. If people stuck with it until crossing ‘the veil of ignorance’ there would be no going back.
        • pests 3y ago
• magpi3 3y ago
  This is still the best explanation IMO: https://www.dreamsongs.com/RiseOfWorseIsBetter.html https://www.dreamsongs.com/RiseOfWorseIsBetter.html
• transfire 3y ago
  “It’s the macros, Stupid!” Seriously. Macros have to be understood a priori to be readable. Macros make the cognitive load of the language very heavy. Contrast that to Ruby which can do rich DSL without macros. It’s much easier to read and figure out even when it gets complicated. Lisp is a beautiful language. But it hits a wall. Macros were made to hop that wall, but ultimately hurt the language. I think this can be fixed with pattern matching and perhaps types, but it will take a very smart programmer to pull it off and it will take Lisp in a direction that old die hards are probably uncomfortable with.
• singularity2001 3y ago
  (((its (the (syntax (especially (due to lacking function overloading and maps)))))))))))))
  • bsdpufferfish 3y ago
    It has both of those features in several forms.
  • dannymi 3y ago
    What's wrong with CLOS generics? Not only does it have function "overloading", it has it on any of the parameters while still being object oriented. (defclass Shape () ()) (defclass Rectangle (Shape) ()) (defclass Ellipse (Shape) ()) (defclass Triangle (Shape) ()) ; Having a defgeneric is not strictly necessary in CLOS. The code would ; work without this definition. However, this is good practice as it gives ; us a natural place to document the generic interface methods are expected ; to implement. It also lets us add a default handler with a meaningful ; error message, if no suitable method was found in some case. (defgeneric intersect (x y) (:documentation "Shape intersection") (:method (x y) (error "Cannot interesect these shapes"))) (defmethod intersect ((r Rectangle) (e Ellipse)) (format t "Rectangle x Ellipse [names r=~a, e=~a]~&" (type-of r) (type-of e))) (defmethod intersect ((r1 Rectangle) (r2 Rectangle)) (format t "Rectangle x Rectangle [names r1=~a, r2=~a]~&" (type-of r1) (type-of r2))) (defmethod intersect ((r Rectangle) (s Shape)) (format t "Rectangle x Shape [names r=~a, s=~a]~&" (type-of r) (type-of s))) >maps make-hash-table
• kazinator 3y ago
  Popularity is a matter of luck. But suppose that the forces that drive luck somehow aligned themselves with promoting Lisp. There are ways Lisp would sabotage the luck being radiated upon it. Programmers who get into CL will hit various silly obstacles: - No standard way to express special characters in string literals. - No standard Unicode support; no \u1234 notation in the standard. I/O with character encodings is implementation-specific. - Weird pathname handling that is simultaneously too abstract, and too nonportable, which is oxymoronic. The pathname abstraction caters to features of operating systems that basically no longer exist. Yet at the same time, two CL implementations on the same modern OS (POSIX or Windows) cannot agree on all the details regarding how a pathname string (the real artifact seen by the OS) parses to a pathname object! - The experience of just firing up a free CL implementation (no Emacs) out of the box and experimenting in its REPL is poor. CLISP has built in history recall and editing; I would recommend that. - Ironically poor REPL experience in the free implementations, given that Lisp gave us that word. Only CLISP has built in editing and history recall out of the box. Telling newbies they have to learn a specific editor and its Lisp integration is poor and adds to the activation energy. - Working with objects can be verbose with syntax like (slot-value point 'x) which is just point.x in many other languages. This can be shortened by defining accessors, but accessors abstract a lot. Given (x point) you no longer know that it's just a simple slot. It's a function call, which could be anything. Another thing is, would you give an accessor a one letter name like x, even if it's in a package? - Newcomers to Lisp do have to learn the list processing. People coming from languages in which lists are collection bags get confused why their list x is not changing after (append x '(1 2)). If you don't use the loop macro and want to collect items into a list, you have to learn the ritual of push-ing items into a stack, and then using nreverse at the end. Guy Steele described a nice procedural list construction API in Common Lisp, The Language, second edition, but it's not in the standard. - Working with multiple values is verbose, with forms like (multiple-value-bind (quotient reminder) (truncate 1 2) ...), and multiple-value-setq, and whatnot. Some pattern matching or binding libraries help with that.
  • dreamcompiler 3y ago
    > Weird pathname handling that is simultaneously too abstract, and too nonportable, which is oxymoronic. The pathname abstraction caters to features of operating systems that basically no longer exist. This times 100. There are only a few places where the ANSI standard got it very wrong, but this is one of them. Logical pathnames were intended to abstract away different file naming conventions but what they actually did was cast in stone some anachronisms that are incompatible with modern Unix file naming (e.g. case-sensitive path names. Whoops! Can't handle that.) The good news is that you can just ignore logical pathnames and use normal native pathnames, or use the illogical-pathnames package which largely fixes the problem.
• charcircuit 3y ago
  This argument seems flawed to me because of the existence of LispWorks. LispWorks makes money from the growth of Common Lisp and people buying their interpreter. It would be in their best interest to grow the language.
• EdwardDiego 3y ago
  Another aspect that perhaps has changed in the years since - when I was playing with Common List many moons ago, the community in comp.lang.lisp was the place to go, but also rather easy to bounce off. I mean, amusing flames, but yeah, asking a genuine question, the fucking manual read beforehand to ensure not already answered in Hyperspec, often led to rather unpleasant replies. Erik Naggum was particularly abrasive.
  • wduquette 3y ago
    I remember Erik Naggum. He was always worth reading, but yeah—incredibly abrasive.
    • NikkiA 3y ago
      He was so often frustratingly right, too.
      • wduquette 3y ago
        I particularly remember an extended rant that Lisp == Common Lisp, and Scheme is not Common Lisp, and therefore Scheme is not Lisp. I’m oversimplifying—Erik gave specific reasons—but that’s what it amounted to. Derailed an entire conversation, IIRC.
        • NikkiA 3y ago
          I think I remember that one, it was something about a Lisp being a Lisp-2 by definition. I shook my head in disagreement at the time, and still do.
          • wduquette 3y ago
            Heh. Yeah, that was part of it.
        • lispm 3y ago
          That's one thing where he was right.
• Snelius 3y ago
  (i)(don't)(know)
• healthdare 3y ago
  Popularity has nothing to do with the tech. WordPress is popular and it's shit. Ms word is popular and there are free substitutes. Success is about a form of politics and coercion with mvp. Emphasis on the "minimal."
• binary132 3y ago
  None of these "programming language evolutionary fitness retrospective" discussions ever manage to address the real heart(s) of the question: - UNIX is C, so C-family languages won. - The network effect is by far the most dominant force in the matter. All of us would like to believe that we operate in a world where technical merit determines memetic fitness, because our jobs seem to depend on it: after all, if we build good things, we immediately see the consequences, and others must also see and appreciate these consequences, right? By doing well at that, we succeed, right? Well, it turns out it's not so much like that actually.
  • NikkiA 3y ago
    MacOS, with a slight help from MS, very, very nearly tipped the balance to Pascal in the 80s. I dare say that without C++ hitting mainstream around 1990, C would have languished.
    • kramerger 3y ago
      Now you are rewriting history :) Turbo Pascal was responsible for the Pascal success. And then came delphi along and somehow lost against Visual Basic.
      • NikkiA 3y ago
        Early Mac Systems were written in pascal, well, Clascal as they called their Object Pascal system in those days, Clascal was developed internally at Apple with Wirth as a consultant. Think Pascal was the primary alternative to MPW until mid System 6 era. MacApp remained Apple's primary API until the mid 90s, and it was 100% written in Object Pascal (formerly Clascal). Some chunks of Windows were also written in Pascal, using Microsoft Pascal which they'd been using since their CP/M days.
        • kramerger 3y ago
          This is very limited to mac, which was really tiny during that period. The rest of the world looked very differently at that time, and compared to mac had much better development environment.
• pipeline_peak 3y ago
  ((I’m(honestly (not (sure,) it’s hard) to believe)))
• rurban 3y ago
  I agree with the conference and foundation part. I've been to many lisp conferences, but they are still extremely weird, compared to other languages conferences. I'm pretty sure it's the people. Lisp is a lone man sports. There's not much community spirit. There's not much github, patches are not accepted. In general. Of course there are many great people around, of the anti-academic background. Who tried to build communities. But the ecosystem lacks a lot still.
  • lispm 3y ago
    > I'm pretty sure it's the people. Glass house?
    • Nevermark 3y ago
      > I'm pretty sure it's the people. > Glass house? A sympathetic reading of that might be: “I’m pretty sure it’s the a-collaborative go-it-alone culture of many of the practitioners”. Lisp’s famous strength at enabling coding styles tailored to every specific domain, may also be its weakness with regard to low friction code sharing & adoption. That, and the distance between Lisp’s high dynamic flexibility vs. more restricted imperative or functional coding styles that are easier to optimize at the low level, may encourage more bespoke development practices.
      • lispm 3y ago
        Is that something you had heard or guessed? Did you attend a Lisp conference and talked to the people, where they were coming from (companies, universities, research labs, ...) and in what domain they were working on? Let's say, ACL2, a theorem prover written in Common Lisp. Unless what Mr. Urban tells you about Lisp users, they have a github repository. They have user/developer meetings. They even presented their stuff at Lisp conferences (I have attended one myself, where I saw a talk about it), wrote books about it, published hundreds of research reports, ... The user group shares > one million lines of Lisp code ( https://github.com/acl2/acl2/tree/master/books https://github.com/acl2/acl2/tree/master/books ), with many more lines of code developed by users. https://github.com/acl2/acl2/ https://github.com/acl2/acl2/ Workshops: https://www.cs.utexas.edu/users/moore/acl2/workshops.html https://www.cs.utexas.edu/users/moore/acl2/workshops.html How does that fit into your theory and what Mr. Urban wants us to believe? Here we have a shared large Lisp code base used at companies like Intel, AMD, ARM, ... where people collaborate over the Internet... how does that fit into your "go-it-alone culture of many of the practitioners" theory?
• hanche 3y ago
  Lissssp – lotss and lotss of ssilly parethesises! We hates it! – Quoted by memory from comp.lang.lisp years ago. (Sorry, can’t remember by who.) Really, I get the parenthesis hating: It is truly terrible to have to deal with them unless you have good editor support and have learned to use it. But then a funny thing happens: The parentheses essentially vanish! You just don’t read parentheses anymore, you read the indentation instead. In my own emacs setup, I have in fact chosen to de-emphasize the parentheses to the point where they are barely visible. It makes the code so much more readable. Good editor support means at least semi-automatic indentation of code. Unindented code is of course unreadable, and wrongly indented code is worse. But that is true of any programming language, isn’t it?
• guenthert 3y ago
  Here are so many responses, I begin to wonder whether CL is actually used less today than it was thirty years ago.
• vindarel 3y ago
  Everyone, if you don't have a clue on how's Common Lisp going these days, I suggest: https://lisp-journey.gitlab.io/blog/these-years-in-common-lisp-2022-in-review/ https://lisp-journey.gitlab.io/blog/these-years-in-common-li... (https://www.reddit.com/r/lisp/comments/107oejk/these_years_in_common_lisp_2022_in_review/ https://www.reddit.com/r/lisp/comments/107oejk/these_years_i...) A curated list of libraries: https://github.com/CodyReichert/awesome-cl https://github.com/CodyReichert/awesome-cl Some companies, the ones we hear about: https://github.com/azzamsa/awesome-lisp-companies/ https://github.com/azzamsa/awesome-lisp-companies/ and oh, some more editors besides Emacs or Vim: https://lispcookbook.github.io/cl-cookbook/editor-support.html https://lispcookbook.github.io/cl-cookbook/editor-support.ht... (Atom/Pulsar support is good, VSCode support less so, Jetbrains one getting good, Lem is a modern Emacsy built in CL, Jupyter notebooks, cl-repl for a terminal REPL, etc)
• cafard 3y ago
  A good deal of my work involves moving data in and out of databases. For the three Ps--Perl, PHP, Python--it is trivial to set up the libraries for the commonly used databases, after one can move on to work. Is that the case for Common Lisp? Another part of my work involves the web. There I can use mod_perl, mod_php, and mod_wsgi. What about Lisp?
• peterhi 3y ago
  It's the learnability of the language. Remember BASIC? You could show someone a FOR ... NEXT loop and they would completely understand. After a couple more 10 line programs and you can safely hand over the keyboard and handle the "how do I?" questions You had to show very little before they understood. Now try Lisp ... M: This is a list S: What can I do with it? M: By itself nothing but trust me it is important. This is how we take the head of a list S: Cool, why would I want to do that? M: We'll get to that later. This is how you take the tail of a list S: ... M: This is how to append to a list S: Is this going anywhere? The number of things you are shown but do not understand keeps piling up before they are supposedly going to magically work together to do something underwhelming (when BASIC did very little it took very little to do it). Add to that the function names were either cryptic, "cddar" anyone - "EQ" and "EQUAL", or insanely long You have too much to learn before you can make sense of anything. Least that was how Lisp was taught to me in the 80s :) I self taught Forth and Prolog because with both once you learn something you can do something
  • titzer 3y ago
    I don't know why you're being downvoted; I completely agree with this. It's hard to put your head into the mindset of a beginner after it's been in the deep end of the pool for so long. Stuff needs to make sense now and in isolation rather than an ever-growing stack of items that will be explained later. It's a matter of putting stakes in the ground and building incrementally. One could argue that lists and heads and tails do make sense on their own and isolation, but they're maybe not the right primitive, because all the things that beginners might want to use "intuitively" have to be first built out of lists. Lisp is a reductionist language, and that's not good for beginners. Readable code needs to be not subtle, low on magic, and self-explanatory. The last one is hard to quantify and make objective, but is imperative in making an approachable language.
  • hajile 3y ago
    (set x (list 1 2 3 4 5)) (for item in x (do stuff to item)) Now try to explain BASIC, but do it by first explaining how to create and manipulate a block of memory. You are conflating language differences with the real argument which is the decades-old debate about whether introductory courses should be practical or rigorous.
• bazoom42 3y ago
  Every successful language have become popular because of a succesful platform or killer app, not on the merits of the language itself.
• duped 3y ago
  Languages that insist on prefix function syntax (`(f 'a)` instead of `('a f)` or `'a.f()`, etc) are always going to be less popular because it reduces the number useful possible suggestions an IDE or REPL can make to a programmer typing a program. You have to know what functions you want to call and the IDE can "fill in the blank" with arguments that are in scope. But you need magic to get the IDE to tell you what functions you can call on an argument. Julia suffers from this too, fwiw. Multimethods in general can be strange but useful beasts, but I don't know of any IDE that handles them well. And sure C does this too. But C isn't exactly the model of useful language that lets a programmer dynamically explore what programs they can compose, is it? Normally, I think most syntactic arguments against languages are bad. But having written in fancy PLs that don't have any kind of postfix/method syntax and those that do, as well as writing language servers and compilers, this is the one syntactic thing I feel very, very strongly about. LISP will always suck for beginners because in Python and C++ and Rust and Swift (etc) they can add "." to the end of a value and the IDE will remind them what methods they can call, or explore what's available. The IDE can even weight which things to suggest. Other people talk about package managers and ecosystem and so on, but this one syntactic choice is something overlooked by many people when talking about how languages grow userbases. Don't overlook it.
• Nevermark 3y ago
  I haven’t used Lisp in a long time. But I used to, and also implemented my own mini Lisp more than once in a panic to get some functionality working in a quick and dirty way. Something I have not seen here is the advantages of type (dynamic or static) for channeling consistent library symbol use. For instance, one of the undersung benefits of class style object oriented code, or any type dispatch, is how it helps enforce the right set of functions to use on some data (i.e. the methods of that object). This cohesiveness between a bucket of symbols related to a data type makes coding and sharing easier. In whatever form this takes, across languages. Lisp’s flexibility doesn’t provide this kind of namespace modularizationthat I recall? Am I out of date or forgetting something? This kind of helpful context sensitive symbol organization is a big factor for simplifying code sharing at the “syntax” level. Reduces mistakes, narrows choices (in a productive way), etc. Without it, adopting a lot of outside code is much harder.
• johnthescott 3y ago
  due to a shortage of parentheses in cambridge? apologies to SKB.