3 ms·

I've heard this "mass productivity" claim from Lisp fans multiple times before, and am skeptical. Lisp has been around for about 60-ish years, yet no software h

by tabtab 7y ago

I've heard this "mass productivity" claim from Lisp fans multiple times before, and am skeptical. Lisp has been around for about 60-ish years, yet no software house has been able to conquer the software market using it. It doesn't seem to scale to bigger teams and long-term maintenance. Developers can easily create abstractions that fit their own head, but not necessarily other heads. They blame the problems on the other readers rather than their spaghetti mind map. If I could make my own language and stack, I too would be mega-productive. However, others likely wouldn't like it and be confused by it, even though it's dirt obvious to me. Roll-your-own has limits. Sometimes 2 or 3 like-minded Lisp developers connect and roll for a while, but over time they will find it a lucky match-up that the real-world can't repeatedly recreate. Lightning in a bottle evaporates easily. The bottleneck of "paycheck" programming productivity is communicating between human beings, who may shift over time. Cranking out compact code fast is secondary to this. Program for people, not machines and not cleverness graders.

lispm 7y ago
Actually quite a bunch of 20 year or older Lisp software is developed in teams. Cyc is developed by a team since the early 80s. Reduce since the mid 70s. The SBCL and CMUCL Lisp implementations come out of the early 80s. Maxima has its roots in the late 60s/early 70s. The commercial Lisp systems from Franz and LispWorks are developed since the mid/end 80s. ACL2 (a theorem prover used in the chip business) comes from the early 90s. ITA (now Google) started mid 90s. GNU Emacs is from the early 80s. Autocd/Autolisp comes from the early 80s. PTC's Lisp-based CAD system (with a few million lines of Lisp code) must have been originally 2000 or earlier...
- tabtab 7y ago
  I don't dispute it has niches where it does well, or at least "works". The implication often given is general purpose productivity superiority.
  - Goladus 7y ago
    > The implication often given is general purpose productivity superiority. The post you responded to specifically used Java as an example, though. Clojure specifically is clearly targeted as an alternative to writing raw Java. A number of other languages rushed in to compete for that space, and while Scala and Kotlin seem to be more popular than Clojure, I have to admit the only JVM app I actually rely on now, uses Clojure. Puppetdb, specifically. Puppet is a ruby project, but the database component is written in Clojure. I dislike Puppet for many reasons (syntax, coupling, architecture), but not because of its database backend.
  - lispm 7y ago
    Well, you claimed that Lisp programmers can not work in software teams over a long period of time, because they don't understand each others code. I gave a few examples. There are also a bunch of examples where Lisp was used to prototype or for rapid application development. This enables exploring ideas or conquering early markets. Later iterations may then reimplement the thing... That's another model and is also fine - though there are projects which had not much experience and were not able to get the thing off the ground. For example the first version of the Postgres database was written in a mix of some Lisp implementation and C. This did not work well for them and they switched early away from Lisp. Similar the first version of Reddit was written in Lisp, but it did not really work that well for them and they switched to Python. > The implication often given is general purpose productivity superiority I don't think that claim makes sense in general. Much of the productivity in modern software development does not come from the programming language. Much more important nowadays is the general eco-system. For example it makes very little sense to develop apps for iOS in Clojure, since there is zero support for it from Apple. Thus most iOS applications are written in Objective-C and/or Swift. An assumed 'general productivity superiority' doesn't help at all to compensate the total lack of platform support from the platform provider.
    - tabtab 7y ago
      Re: you claimed that Lisp programmers can not work in software teams over a long period I meant for "general" programming. I apologize for not wording it clearer earlier. Re: There are also a bunch of examples where Lisp was used to prototype or for rapid application development. Yes, this is a niche it often does well in. It's partly how Paul Graham beat competitors in the store app arena.

by tabtab 7y ago

lispm 7y ago

Actually quite a bunch of 20 year or older Lisp software is developed in teams. Cyc is developed by a team since the early 80s. Reduce since the mid 70s. The SBCL and CMUCL Lisp implementations come out of the early 80s. Maxima has its roots in the late 60s/early 70s. The commercial Lisp systems from Franz and LispWorks are developed since the mid/end 80s. ACL2 (a theorem prover used in the chip business) comes from the early 90s. ITA (now Google) started mid 90s. GNU Emacs is from the early 80s. Autocd/Autolisp comes from the early 80s. PTC's Lisp-based CAD system (with a few million lines of Lisp code) must have been originally 2000 or earlier...

tabtab 7y ago
I don't dispute it has niches where it does well, or at least "works". The implication often given is general purpose productivity superiority.
- Goladus 7y ago
  > The implication often given is general purpose productivity superiority. The post you responded to specifically used Java as an example, though. Clojure specifically is clearly targeted as an alternative to writing raw Java. A number of other languages rushed in to compete for that space, and while Scala and Kotlin seem to be more popular than Clojure, I have to admit the only JVM app I actually rely on now, uses Clojure. Puppetdb, specifically. Puppet is a ruby project, but the database component is written in Clojure. I dislike Puppet for many reasons (syntax, coupling, architecture), but not because of its database backend.
- lispm 7y ago
  Well, you claimed that Lisp programmers can not work in software teams over a long period of time, because they don't understand each others code. I gave a few examples. There are also a bunch of examples where Lisp was used to prototype or for rapid application development. This enables exploring ideas or conquering early markets. Later iterations may then reimplement the thing... That's another model and is also fine - though there are projects which had not much experience and were not able to get the thing off the ground. For example the first version of the Postgres database was written in a mix of some Lisp implementation and C. This did not work well for them and they switched early away from Lisp. Similar the first version of Reddit was written in Lisp, but it did not really work that well for them and they switched to Python. > The implication often given is general purpose productivity superiority I don't think that claim makes sense in general. Much of the productivity in modern software development does not come from the programming language. Much more important nowadays is the general eco-system. For example it makes very little sense to develop apps for iOS in Clojure, since there is zero support for it from Apple. Thus most iOS applications are written in Objective-C and/or Swift. An assumed 'general productivity superiority' doesn't help at all to compensate the total lack of platform support from the platform provider.
  - tabtab 7y ago
    Re: you claimed that Lisp programmers can not work in software teams over a long period I meant for "general" programming. I apologize for not wording it clearer earlier. Re: There are also a bunch of examples where Lisp was used to prototype or for rapid application development. Yes, this is a niche it often does well in. It's partly how Paul Graham beat competitors in the store app arena.