Live data from Hacker News

Why is Common Lisp not the most popular programming language?

daninus14.github.io

201–210 of 339 posts

Re: Why is Common Lisp not the most popular programming language?

#201
post #37

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.)

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…

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.

Re: Why is Common Lisp not the most popular programming language?

#202
post #160

Earlier quoted context omitted.

Isn't this the exact "if people only knew" attitude he mentioned?

Yes it is. If people stuck with it until crossing ‘the veil of ignorance’ there would be no going back.

Just gotta double down eh?

Re: Why is Common Lisp not the most popular programming language?

#203
post #107

Earlier quoted context omitted.

I didn't see mentioned in the thread (maybe missed it) the #1 reason, IMO, that Lisp can't be popular in companies. Everyone should take the time to learn Lisp and do a handful of personal projects with it. It'll help your growth as a software engineer. Just do it! But that doesn't make it a great corporate language. Lips is infinitely flexible, you can mutate it to be what you want. That's cool and feels awesome. Al…

> Also: a maintenance nightmare as soon as you have more than ~1 person working on the codebase! Lisp isn't any harder to maintain than any other language. The Lisp codebases I've worked on, even professionally, were originally written by talented, experienced engineers and were in fact wonderful to maintain. > Now imagine something like Lisp where every developer & team morphs it in a different way and you have a pr…

> I think you might be on to something. Symbolics was very much in danger of making large software projects possible by one person or a small team of people. It seems as if the corporate world has responded to the proliferation of more powerful software development tools -- not only in Lisp, but certainly Lisp and Smalltalk had an outsized influence -- by lowering the skill ceiling to make devs more fungible, and creating more and more process to hobble their productivity so as to justify larger teams of devs and dev-adjacent personnel: PMs, POs, scrum masters, etc.

This is a ridiculous LISP conspiracy theory that really needs to die. What world are you living in that corporations actively want their employees to work slowly or to have too many employees? Who does that benefit?

If lisp were genuinely powerful, corporations would be able to make bigger projects faster.

Re: Why is Common Lisp not the most popular programming language?

#204
post #86

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 p…

> 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 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://…

I think he was talking about the late 80s and the 90s.

Re: Why is Common Lisp not the most popular programming language?

#205

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…

I remember Erik Naggum. He was always worth reading, but yeah—incredibly abrasive.

He was so often frustratingly right, too.

Re: Why is Common Lisp not the most popular programming language?

#206

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.

> nobody will ever advance the CL standard And that’s a good thing.

I suppose, if you are happy with the state of things and the size of the current userbase.

Re: Why is Common Lisp not the most popular programming language?

#207
post #7

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 ),…

> It's the lists.

That is one of the defining differences between Clojure and older Lisps. Clojure has list, vectors, maps, and sets as equally well supported data structures in the syntax and standard library. Classical Lisps often miss proper abstractions over different data structures. Clojure has those as well.

Re: Why is Common Lisp not the most popular programming language?

#208

(((its (the (syntax (especially (due to lacking function overloading and maps)))))))))))))

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

Re: Why is Common Lisp not the most popular programming language?

#209
post #105

Earlier quoted context omitted.

> But idiomatic Lisp code really does use linked lists extensively, Idiomatic python code uses lists extensively. In my (somewhat limited) experience, they're the default data structure to use for a lot of algorithms. Slightly more accurately, a lot of stuff in python uses sequences extensively, which are implemented by a number of types - but the default sequence is a list. And strings are lists. Yeah, if a list doe…

I like python significantly more than lisp. There are so many ways to express yourself in python that are troublesome in lisp. I actually think list manipulation is easier in python than lisp. I don't know, is there a lisp dialect that makes common data structures available in a multitude of ways? I seem to be able to manipulate lists quite easily in python, and switch back and forth to sets or hashes. but in lisp yo…

see here: https://lispcookbook.github.io/cl-cookbook/data-structures.h...

Re: Why is Common Lisp not the most popular programming language?

#210
post #7

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 ),…

I'm tackling a significant lisp project right now, and the thing that holds me up right now is that the code is difficult to organize. Python, java, rust, go etc have well-defined patterns to figure out where code lives and where you might expect certain behaviors to occur. With lisp you can really shoot yourself in the foot very easily by using abstractions that are difficult to follow and are spread out across many…

> the code is difficult to organize

we can simply do `(defpackage :mypackage (:use :cl))` then `(in-package :mypackage)`. Since they don't have to follow file hierarchy, we are free.

That's good for the long term, and general flexibility. But it's different, sure. Good luck!

Post reply on HN