11 ms·

The Lisp Curse (2011)

59 points by felipelalli 7y ago

tabtab 7y ago
History has shown that if code must be maintained by multiple different people over time, then consistency and predictability overrides abstraction and meta-ability. Legibility by actual readers trumps linguistic or symbolic parsimony. Perhaps a Lisp shop could force consistency, but that seems to fall apart after a while. More on this viewpoint: http://wiki.c2.com/?GreatLispWar http://wiki.c2.com/?GreatLispWar
- phyrex 7y ago
  Clojure seems to do pretty well in that regard
  - tabtab 7y ago
    I don't see it catching on in the "mainstream" yet. It still seems niche-specific. Maybe we'll know for sure in a few more years.
    - commandlinefan 7y ago
      I haven’t had a chance to spend much time with Clojure, but I have spent time learning both Groovy and Scala which are similar. Both have a steep learning curve (which I can’t say I’m entirely over), but I have noticed that, in the nearly 3 decades I’ve been programming, I’ve never seen anything with a steep learning curve really catch on. The things that catch on like wildfire are things like Java, JavaScript, Cobol, VB, C#: things that take a moment to learn but a lifetime to master. The reason seems pretty obvious - you can produce results and feel productive (and demonstrate productivity) quickly even if you’re less productive in the long run. Short term results matter more than long term efficiency.
      - jandrese 7y ago
        This is the primary roadblock to Rust deployment IMHO. It's really hard to get over the hump at the start. You do all of the trivial examples in the manual just fine, but immediately run into issues when you write your own code.
        pjmlp 7y ago
        Specially if one tries to do a GUI or game as the first step after going through the book.
        renox 7y ago
        The GUI is an issue for all the non-platform languages.. It took a lot of effort for Java with average results. Python's Qt wrappers seems to be more successful.
        pjmlp 7y ago
        On Rust it goes beyond that, because borrow checker semantics still aren't productive in typical GUI programming patterns, like self referencial structs from event handlers, leading to Rc<RefCell<>> and clone() calls everywhere. Not saying that it won't improve, just stating the current state. Even with reactive UIs as way to get around those callbacks, relm isn't as easy as Fabulous, SwiftUI, Elm, with the caveat that reactive UIs are heavier on the memory allocator.
      - TheOtherHobbes 7y ago
        This is one reason why "worse is better" happens so often. Most people are in the middle of the bell curve. Smart persistent people are out at the edge of the bell curve. So where should you aim your project? There's cult kudos in being out on the edge, and there may even be real productivity and reliability benefits. But realistically, most people aren't going to go there most of the time.
      - jimbokun 7y ago
        The languages that catch on are the ones tied to the most popular platforms. Objective C and Swift for iOS. Javascript for the Web. Java (and now Kotlin?) for Android. SQL for relational databases. Visual Basic and C# for Windows. Python for scientific programming and machine learning. Developers don't pick a language because it makes them feel productive. They pick a language that allows them to write for the platforms where they want to deliver their programs. Or because it has the best libraries for their problem domain. (Back end web development is somewhat of an exception, as every language can talk HTTP.)
    - iLemming 7y ago
      Clojure is already bigger than Haskell, F#, ReasonML, Elixir and Elm. It has more podcasts and more meetups, there are more than a dozen of books, almost every European country now has its own regular Clojure conference, there are conferences in India, Canada and Brazil. It probably will never become "mainstream" but it is slowly and steadily growing.
  - mechanicum 7y ago
    I can think of three things that may have helped Clojure avoid this issue, at least relative to other Lisps: 1. It shipped with a substantial set of features, either in core from day one or as a function of being hosted on the JVM, that programmers would otherwise have been likely to build themselves in multiple, potentially incompatible ways. 2. The syntax is simple, and Clojure doesn’t allow user-defined reader macros, so libraries can’t introduce new syntax. There may be more than one way to do it, but you should at least know how to read all of them. 3. It’s only ever been under the stewardship of one cautious, opinionated developer. Of course, from another perspective, all of these could be (and I’m sure have been) seen as weaknesses.
- jimbokun 7y ago
  > Perhaps a Lisp shop could force consistency This was one of the main goals of the Common Lisp standard, no?
  - aoeu512 7y ago
    But it was done poorly... Lisp-2, eq vs equal vs = vs equalp , multiple-value-bind, destructuring-bind, remove-if-not, etc... Python's PEP process seems to be a better idea...
kgwxd 7y ago
"We found no items matching the lisp curse"
- felipelalli 7y ago
  Yes! I found this text here: https://srfi-email.schemers.org/srfi-discuss/msg/12129771/ https://srfi-email.schemers.org/srfi-discuss/msg/12129771/ and I have never seen it before. It is brilliant.
- jey 7y ago
  Fixed link: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=the%20lisp%20curse&sort=byPopularity&type=all https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
_bxg1 7y ago
I think a lesser version of the same problem is behind JavaScript's Framework Hell. And JavaScript projects in general: "idiomatic" is an ill-defined term in the context of JavaScript, so you rely a great deal more on conventions within any given organization.
commandlinefan 7y ago
> Lisp allows you to just chuck things off so easily Lisp people (like Paul Graham) say that a lot, but they also admit that there’s a pretty steep learning curve before you get to that point - at least, I’ve never heard anybody say that Lisp is both easy to use and easy learn. I actually do believe them. I used to hear the same thing about vi: it’s quick and powerful, once you get over the learning hump. I actually did take the time to get over the hump and found that I _was_ faster and more productive with it, but it took some time to get there. The time spent was worth it, but it was slow going getting there. I’ve dabbled enough in Lisp and functional programming in general on my own to believe that there’s something very powerful hiding in there… but there’s work to be done and unlike my choice of text editor which only impacts me, I have to work in a language that everybody agrees on, and so far, that’s never been Lisp.
- TurboHaskal 7y ago
  I don't think that's true. Sure you need quite some experience with the language to actually appreciate its strengths, but when optimising for low attention span and focusing on the kind of literature that allows people to jump quickly into solving problems (rather than those texts that start slowly and focus on laying out the foundation), provided existing experience with another language, you can start building things in no time. Lisp is just like any other language. That's why today I simply point people to the cookbook [0]. If they keep the interest, they'll eventually jump to the classics. [0] https://lispcookbook.github.io/cl-cookbook/ https://lispcookbook.github.io/cl-cookbook/
  - iLemming 7y ago
    Even the famous long time Lisp aficionados like Paul Graham today recommend Clojure instead of CL. That seems to be more pragmatic choice.
    - TurboHaskal 7y ago
      I like Clojure, but whether it is a more pragmatic choice (or if it’s even a Lisp) is a bit off topic here. If someone asks me for advice on how to get started with Common Lisp I will point them them to CL resources.
protomyth 7y ago
Imagine adding object orientation to the C and Scheme programming languages. Making Scheme object-oriented is a sophomore homework assignment. On the other hand, adding object orientation to C requires the programming chops of Bjarne Stroustrup. I like to think Brad Cox did a pretty good job and remained compatible with the base language.
- gaze 7y ago
  Ah yes, the speed of smalltalk with the memory protection of C.
  - protomyth 7y ago
    Yeah, but Objective-C spawned NeXTSTEP, and C++ got us Taligent.
    - pjmlp 7y ago
      In a way both are market failures. NeXTSTEP only survives because Apple decided to buy NeXT instead of Be, and they did an inverted acquisition once inside Apple.
      - protomyth 7y ago
        NeXT was making money at the end, and powered OS X for a lot of years. Taligent released a framework and died. I love Be but it wasn't in the same league as NeXTSTEP, and I had both at the time.
        pjmlp 7y ago
        What money were they making? Their agreement with Sun to create the future of Solaris SDK failed, with Sun using their work as genesis of J2EE. And their pivot into OpenSTEP wasn't selling like faster then they were bleeding. My thesis was to port a particle engine from NeXT to Windows, as my department was getting rid of their Cubes. Had Apple not bought them and we would be remembering NeXT just like Amiga, Atari, Be,....
B1FF_PSUVM 7y ago
Speaking of Olin Shivers and reposts ... http://www.ccs.neu.edu/~shivers/autoweapons.html http://www.ccs.neu.edu/~shivers/autoweapons.html (More amusing than a barrel of Lisp macros)
stcredzero 7y ago
Update on October 6, 2017. N.B.: Please stop submitting this to Hacker News! Look at the Hacker News search results for this essay. Oddly enough, I've been here for ages, and I don't remember ever seeing this! The power of Lisp is its own worst enemy. The power of _insert_prog_lang_here_ is its own worst enemy. Applies to Ruby, Smalltalk, C++, Haskell, and probably many others. It even applies to PHP! You see, power comes in many forms. http://www.giantitp.com/forums/showthread.php?238385-quot-Power-is-Power-quot http://www.giantitp.com/forums/showthread.php?238385-quot-Po... 2nd order sociological effects often decide the fate of programming language communities. Unfortunately, many programmers have been less competent at navigating those forces. (This has changed with the effect of the Internet on world culture, of course.)
yummypaint 7y ago
I disagree with the core premise of this article. By this logic, the most developed language ecosystems should be those built from languages which are the most difficult to develop for. Python is a clear counterexample with a comparably low barrier, and tons of existing modules with ~80% capability hacked together by random individuals. In practice, many of those partially complete projects are picked up and improved by others, or serve as direct inspiration for more rigorous implementations. I would argue the language and community are stronger because of this. Lisp has been around for over half a century. It's had plenty of opportunity to demonstrate its worth in helping people solve real world problems in production. I agree with the author there is probably a fundamental reason lisp doesn't see this kind of use (maybe with the exception of clojure), but I seriously doubt that reason is that it's "too powerful."
- jerf 7y ago
  "By this logic, the most developed language ecosystems should be those built from languages which are the most difficult to develop for." It only implies that the relationship between difficulty of development and developed ecosystem is not monotonic. It's actually fairly normal for two parameters to be highly correlated to each other along most of their range & domain, but for the correlation to suddenly fall apart at the extreme. (I think there's a term for this, and I'm wishing I could remember it, so I could to pages I've seen discussing it. If anyone knows, links solicited.) Of course, the real problem is that there's almost certainly a lot of such parameters, and having what may be merely a "just-so" story for Lisp's general failure to set the world on fire and it's excessive power may not be particularly determinative of anything. It does at least fit the facts. Most of the other possible answers have at least had the seed of a solution created (e.g., package manager solutions), and it still hasn't taken off, suggesting that wasn't the problem. (Though we can't eliminate the possibility it needs multiple such things.) The fact that Clojure seems to be settling into a C-list language position after its push also is suggestive of it not being any of the things that it fixed.
- ddragon 7y ago
  On the other hand, a lot of the most popular Python libraries became effectively standard and lots of people agglomerated around them instead of creating competing standards because it would be hard for any smaller team to replicate even their base functionality. Creating a numpy, scipy, sklearn, pandas, tensorflow or pytorch would involve lots of optimized C/C++ code and python wrappers, which is a considerably high barrier. If anyone could make an equally high performance 80% functionality/use cases coverage version of those libraries using high level python in maybe a month, would that cause a fragmentation in a way that we would get a lot of 80% libraries (with different 80%) instead of one 95% library that is supported everywhere?
jandrese 7y ago
Maybe the problem isn't so much that Lisp is too easy, but rather that there's no central repository for Lisp modules? Everybody runs into the "I need a GUI environment" and doesn't have anywhere to search for the 30 other GUIs that have already been written and never published so they write their own. A centralized repository for these could help a lot, especially if it enforces documentation standards before accepting modules. It's a cultural issue with all of the pre-Internet languages. Even titans like C and C++ lack a well defined repository outside of their stuffy standards committee defined standard libraries. CPAN showed how powerful a resource like that can be 25 years ago and almost every language since has shipped with something similar, but old languages never seem to have caught on.
- Jtsummers 7y ago
  Quicklisp exists now and largely addresses this issue. It can still be difficult to discover libraries sometimes, and not everything is in it, but it’s been a major step forward.
- gaze 7y ago
  what gui library? The only production-ready one is part of Lispworks :(
  - _ph_ 7y ago
    I am sure there are several ones. Binding to GTK should be very easy through FFI. Myself, I have written a pretty large enterprise application based on Ltk.
  - TurboHaskal 7y ago
    You can find a listing here https://awesome-cl.com/#gui https://awesome-cl.com/#gui Some of them might be considered production ready, but that would depend on your expectations. They all pale in comparison with CAPI though, which is really good and I'd say one of the main reasons to use Common Lisp today.
  - pjmlp 7y ago
    Allegro Lisp also has GUI support.
cy_hauser 7y ago
The curse of Lisp is not its power, elegance, flexibility, etc. The curse of Lisp is its syntax! Both "all those parentheses" and what they represent is the curse of Lisp. Lisp forces coders to think in terms of infix trees. These trees need to be carried around in the front of the mind. This mental model is very difficult unless your mind is wired to be able to process code this way. For Lisp aficionados this either comes naturally or with coding practice. The "parentheses" fade into the background. For most people this wiring never comes. It remains too difficult to keep the nested trees straight in their heads. To put it colloquially, it's too difficult to juggle all those parenthesis. If you're a Lisper you'll want to believe that with use comes the familiarity to overcome this hurdle. It's not. If you're a Lisper your probably tempted to redactor a sample chunk of code into something really readable to show this isn't the case. However, that only works in the small. It's like code golf. It doesn't carry over into large scale applications. Lisps mental model just won't become second nature to very many coders. Haskell forces you to juggle "math." Forth forces you to juggle "stacks." Lisp forces you to juggle "trees." The popular Algol descendants are popular, in part, because they're closest to the way people think. The curse of unique brains is the curse of Lisp.
- webreac 7y ago
  There are many different ways of thinking.
- jimbokun 7y ago
  > The popular Algol descendants are popular, in part, because they're closest to the way people think. No, those languages not close to "the way people think", unless those people are already experienced programmers using one of those languages. Programming languages are artificial and do not work like human languages. Every programming language requires you to run an internal parser and build partial parse trees in your head to under stand what the program will do. Whether it's Lisp, Java, or anything else. Lisp is not any harder for beginners than any other programming language. > It doesn't carry over into large scale applications. It works far better and more powerfully in large scale applications. Lisp is unmatched in its ability to write large applications, in terms of power and functionality, with fewer developers and fewer lines of code than almost any other language. This is pretty much the whole point of the "Lisp Curse". And no, it's not code golf. It is higher order, more powerful abstractions and coding techniques.
xvilka 7y ago
Emacs is good enough, much more powerful than many "proper" IDEs. But it should be ported to the proper, modern LISP or Scheme, instead of the using its own subset/dialect. And the used dialect is incompatible [1] with everything else. Too bad that GuileEmacs[2] project died, probably because of the same curse though. Porting it to SBCL would be a game changer too. [1] https://www.gnu.org/software/emacs/manual/html_node/cl/Porting-Common-Lisp.html https://www.gnu.org/software/emacs/manual/html_node/cl/Porti... [2] https://www.emacswiki.org/emacs/GuileEmacs https://www.emacswiki.org/emacs/GuileEmacs
- eklitzke 7y ago
  Why should it be ported? What would be a game changer?
  - xvilka 7y ago
    Because you can't use CL libs in EmacsLisp due to the incompatibility. And vice versa.
- iLemming 7y ago
  Emacs is fine. Emacs-lisp is good enough for what it was made for. Every few years someone gets a "brilliant" idea that it should be something else but that gets nowhere. Languages cannot exist in a vacuum. If there's a proposal to make it compatible say with Racket, then you'd have to create a strange hybrid of Elisp-Racket because you can't just make all the existing Emacs packages incompatible.
  - kamaal 7y ago
    >>If there's a proposal to make it compatible say with Racket Racket itself wants to deprecate their entire language, toss every thing and start out with some thing totally new, all over again.
einpoklum 7y ago
> Due to the difficulty of making C object oriented, only two serious attempts at the problem have made any traction: C++ and Objective-C. 1. C++ is not an extension to C. Most C code would quite unacceptable C++, and considered inelegant, unsafe, and overly redundant. 2. C++ is a multi-paradigmatic programming language, not necessarily object-oriented.
dang 7y ago
The submitted title ("The Lisp Curse by Rudolf Winestock (Again, Sorry)") broke the site guidelines by editorializing. Can you please review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and not do that in the future?
PaulAJ 7y ago
Haskell's type checker is not Turing-complete by default. This is a feature, not a bug, because it means that the type checker is guaranteed to terminate. Since this piece was written GHC has been extended so that non-termination can be enabled if you want it. The sideswipe against the supposed venality of managers is unwarranted. Programmers are like mountaineers in a world where the terrain shifts radically and unpredictably. One day you are on top of a mountain, the next day, without having moved, you are in a deep valley. Under these circumstances teams of people in ATVs who can move rapidly across the terrain tend to have a higher average altitude than people with karabiners and ropes.
fithisux 7y ago
Useless talk. If the Lisps were that powerful,every spec would end up with a Lisp implementation. We need better Lisps that make translation from spec to software easier. Lisp can improve. Lisp shall improve.

59 points by felipelalli 7y ago

History has shown that if code must be maintained by multiple different people over time, then consistency and predictability overrides abstraction and meta-ability. Legibility by actual readers trumps linguistic or symbolic parsimony. Perhaps a Lisp shop could force consistency, but that seems to fall apart after a while. More on this viewpoint: http://wiki.c2.com/?GreatLispWar http://wiki.c2.com/?GreatLispWar

phyrex 7y ago
Clojure seems to do pretty well in that regard
- tabtab 7y ago
  I don't see it catching on in the "mainstream" yet. It still seems niche-specific. Maybe we'll know for sure in a few more years.
  - commandlinefan 7y ago
    I haven’t had a chance to spend much time with Clojure, but I have spent time learning both Groovy and Scala which are similar. Both have a steep learning curve (which I can’t say I’m entirely over), but I have noticed that, in the nearly 3 decades I’ve been programming, I’ve never seen anything with a steep learning curve really catch on. The things that catch on like wildfire are things like Java, JavaScript, Cobol, VB, C#: things that take a moment to learn but a lifetime to master. The reason seems pretty obvious - you can produce results and feel productive (and demonstrate productivity) quickly even if you’re less productive in the long run. Short term results matter more than long term efficiency.
    - jandrese 7y ago
      This is the primary roadblock to Rust deployment IMHO. It's really hard to get over the hump at the start. You do all of the trivial examples in the manual just fine, but immediately run into issues when you write your own code.
      - pjmlp 7y ago
        Specially if one tries to do a GUI or game as the first step after going through the book.
        renox 7y ago
        The GUI is an issue for all the non-platform languages.. It took a lot of effort for Java with average results. Python's Qt wrappers seems to be more successful.
        pjmlp 7y ago
        On Rust it goes beyond that, because borrow checker semantics still aren't productive in typical GUI programming patterns, like self referencial structs from event handlers, leading to Rc<RefCell<>> and clone() calls everywhere. Not saying that it won't improve, just stating the current state. Even with reactive UIs as way to get around those callbacks, relm isn't as easy as Fabulous, SwiftUI, Elm, with the caveat that reactive UIs are heavier on the memory allocator.
    - TheOtherHobbes 7y ago
      This is one reason why "worse is better" happens so often. Most people are in the middle of the bell curve. Smart persistent people are out at the edge of the bell curve. So where should you aim your project? There's cult kudos in being out on the edge, and there may even be real productivity and reliability benefits. But realistically, most people aren't going to go there most of the time.
    - jimbokun 7y ago
      The languages that catch on are the ones tied to the most popular platforms. Objective C and Swift for iOS. Javascript for the Web. Java (and now Kotlin?) for Android. SQL for relational databases. Visual Basic and C# for Windows. Python for scientific programming and machine learning. Developers don't pick a language because it makes them feel productive. They pick a language that allows them to write for the platforms where they want to deliver their programs. Or because it has the best libraries for their problem domain. (Back end web development is somewhat of an exception, as every language can talk HTTP.)
  - iLemming 7y ago
    Clojure is already bigger than Haskell, F#, ReasonML, Elixir and Elm. It has more podcasts and more meetups, there are more than a dozen of books, almost every European country now has its own regular Clojure conference, there are conferences in India, Canada and Brazil. It probably will never become "mainstream" but it is slowly and steadily growing.
- mechanicum 7y ago
  I can think of three things that may have helped Clojure avoid this issue, at least relative to other Lisps: 1. It shipped with a substantial set of features, either in core from day one or as a function of being hosted on the JVM, that programmers would otherwise have been likely to build themselves in multiple, potentially incompatible ways. 2. The syntax is simple, and Clojure doesn’t allow user-defined reader macros, so libraries can’t introduce new syntax. There may be more than one way to do it, but you should at least know how to read all of them. 3. It’s only ever been under the stewardship of one cautious, opinionated developer. Of course, from another perspective, all of these could be (and I’m sure have been) seen as weaknesses.
jimbokun 7y ago
> Perhaps a Lisp shop could force consistency This was one of the main goals of the Common Lisp standard, no?
- aoeu512 7y ago
  But it was done poorly... Lisp-2, eq vs equal vs = vs equalp , multiple-value-bind, destructuring-bind, remove-if-not, etc... Python's PEP process seems to be a better idea...

kgwxd 7y ago

"We found no items matching the lisp curse"

felipelalli 7y ago
Yes! I found this text here: https://srfi-email.schemers.org/srfi-discuss/msg/12129771/ https://srfi-email.schemers.org/srfi-discuss/msg/12129771/ and I have never seen it before. It is brilliant.
jey 7y ago
Fixed link: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=the%20lisp%20curse&sort=byPopularity&type=all https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

_bxg1 7y ago

I think a lesser version of the same problem is behind JavaScript's Framework Hell. And JavaScript projects in general: "idiomatic" is an ill-defined term in the context of JavaScript, so you rely a great deal more on conventions within any given organization.

commandlinefan 7y ago

> Lisp allows you to just chuck things off so easily Lisp people (like Paul Graham) say that a lot, but they also admit that there’s a pretty steep learning curve before you get to that point - at least, I’ve never heard anybody say that Lisp is both easy to use and easy learn. I actually do believe them. I used to hear the same thing about vi: it’s quick and powerful, once you get over the learning hump. I actually did take the time to get over the hump and found that I _was_ faster and more productive with it, but it took some time to get there. The time spent was worth it, but it was slow going getting there. I’ve dabbled enough in Lisp and functional programming in general on my own to believe that there’s something very powerful hiding in there… but there’s work to be done and unlike my choice of text editor which only impacts me, I have to work in a language that everybody agrees on, and so far, that’s never been Lisp.

TurboHaskal 7y ago
I don't think that's true. Sure you need quite some experience with the language to actually appreciate its strengths, but when optimising for low attention span and focusing on the kind of literature that allows people to jump quickly into solving problems (rather than those texts that start slowly and focus on laying out the foundation), provided existing experience with another language, you can start building things in no time. Lisp is just like any other language. That's why today I simply point people to the cookbook [0]. If they keep the interest, they'll eventually jump to the classics. [0] https://lispcookbook.github.io/cl-cookbook/ https://lispcookbook.github.io/cl-cookbook/
- iLemming 7y ago
  Even the famous long time Lisp aficionados like Paul Graham today recommend Clojure instead of CL. That seems to be more pragmatic choice.
  - TurboHaskal 7y ago
    I like Clojure, but whether it is a more pragmatic choice (or if it’s even a Lisp) is a bit off topic here. If someone asks me for advice on how to get started with Common Lisp I will point them them to CL resources.

protomyth 7y ago

Imagine adding object orientation to the C and Scheme programming languages. Making Scheme object-oriented is a sophomore homework assignment. On the other hand, adding object orientation to C requires the programming chops of Bjarne Stroustrup. I like to think Brad Cox did a pretty good job and remained compatible with the base language.

gaze 7y ago
Ah yes, the speed of smalltalk with the memory protection of C.
- protomyth 7y ago
  Yeah, but Objective-C spawned NeXTSTEP, and C++ got us Taligent.
  - pjmlp 7y ago
    In a way both are market failures. NeXTSTEP only survives because Apple decided to buy NeXT instead of Be, and they did an inverted acquisition once inside Apple.
    - protomyth 7y ago
      NeXT was making money at the end, and powered OS X for a lot of years. Taligent released a framework and died. I love Be but it wasn't in the same league as NeXTSTEP, and I had both at the time.
      - pjmlp 7y ago
        What money were they making? Their agreement with Sun to create the future of Solaris SDK failed, with Sun using their work as genesis of J2EE. And their pivot into OpenSTEP wasn't selling like faster then they were bleeding. My thesis was to port a particle engine from NeXT to Windows, as my department was getting rid of their Cubes. Had Apple not bought them and we would be remembering NeXT just like Amiga, Atari, Be,....

B1FF_PSUVM 7y ago

Speaking of Olin Shivers and reposts ... http://www.ccs.neu.edu/~shivers/autoweapons.html http://www.ccs.neu.edu/~shivers/autoweapons.html (More amusing than a barrel of Lisp macros)

stcredzero 7y ago

Update on October 6, 2017. N.B.: Please stop submitting this to Hacker News! Look at the Hacker News search results for this essay. Oddly enough, I've been here for ages, and I don't remember ever seeing this! The power of Lisp is its own worst enemy. The power of _insert_prog_lang_here_ is its own worst enemy. Applies to Ruby, Smalltalk, C++, Haskell, and probably many others. It even applies to PHP! You see, power comes in many forms. http://www.giantitp.com/forums/showthread.php?238385-quot-Power-is-Power-quot http://www.giantitp.com/forums/showthread.php?238385-quot-Po... 2nd order sociological effects often decide the fate of programming language communities. Unfortunately, many programmers have been less competent at navigating those forces. (This has changed with the effect of the Internet on world culture, of course.)

yummypaint 7y ago

I disagree with the core premise of this article. By this logic, the most developed language ecosystems should be those built from languages which are the most difficult to develop for. Python is a clear counterexample with a comparably low barrier, and tons of existing modules with ~80% capability hacked together by random individuals. In practice, many of those partially complete projects are picked up and improved by others, or serve as direct inspiration for more rigorous implementations. I would argue the language and community are stronger because of this. Lisp has been around for over half a century. It's had plenty of opportunity to demonstrate its worth in helping people solve real world problems in production. I agree with the author there is probably a fundamental reason lisp doesn't see this kind of use (maybe with the exception of clojure), but I seriously doubt that reason is that it's "too powerful."

jerf 7y ago
"By this logic, the most developed language ecosystems should be those built from languages which are the most difficult to develop for." It only implies that the relationship between difficulty of development and developed ecosystem is not monotonic. It's actually fairly normal for two parameters to be highly correlated to each other along most of their range & domain, but for the correlation to suddenly fall apart at the extreme. (I think there's a term for this, and I'm wishing I could remember it, so I could to pages I've seen discussing it. If anyone knows, links solicited.) Of course, the real problem is that there's almost certainly a lot of such parameters, and having what may be merely a "just-so" story for Lisp's general failure to set the world on fire and it's excessive power may not be particularly determinative of anything. It does at least fit the facts. Most of the other possible answers have at least had the seed of a solution created (e.g., package manager solutions), and it still hasn't taken off, suggesting that wasn't the problem. (Though we can't eliminate the possibility it needs multiple such things.) The fact that Clojure seems to be settling into a C-list language position after its push also is suggestive of it not being any of the things that it fixed.
ddragon 7y ago
On the other hand, a lot of the most popular Python libraries became effectively standard and lots of people agglomerated around them instead of creating competing standards because it would be hard for any smaller team to replicate even their base functionality. Creating a numpy, scipy, sklearn, pandas, tensorflow or pytorch would involve lots of optimized C/C++ code and python wrappers, which is a considerably high barrier. If anyone could make an equally high performance 80% functionality/use cases coverage version of those libraries using high level python in maybe a month, would that cause a fragmentation in a way that we would get a lot of 80% libraries (with different 80%) instead of one 95% library that is supported everywhere?

jandrese 7y ago

Maybe the problem isn't so much that Lisp is too easy, but rather that there's no central repository for Lisp modules? Everybody runs into the "I need a GUI environment" and doesn't have anywhere to search for the 30 other GUIs that have already been written and never published so they write their own. A centralized repository for these could help a lot, especially if it enforces documentation standards before accepting modules. It's a cultural issue with all of the pre-Internet languages. Even titans like C and C++ lack a well defined repository outside of their stuffy standards committee defined standard libraries. CPAN showed how powerful a resource like that can be 25 years ago and almost every language since has shipped with something similar, but old languages never seem to have caught on.

Jtsummers 7y ago
Quicklisp exists now and largely addresses this issue. It can still be difficult to discover libraries sometimes, and not everything is in it, but it’s been a major step forward.
gaze 7y ago
what gui library? The only production-ready one is part of Lispworks :(
- _ph_ 7y ago
  I am sure there are several ones. Binding to GTK should be very easy through FFI. Myself, I have written a pretty large enterprise application based on Ltk.
- TurboHaskal 7y ago
  You can find a listing here https://awesome-cl.com/#gui https://awesome-cl.com/#gui Some of them might be considered production ready, but that would depend on your expectations. They all pale in comparison with CAPI though, which is really good and I'd say one of the main reasons to use Common Lisp today.
- pjmlp 7y ago
  Allegro Lisp also has GUI support.

cy_hauser 7y ago

The curse of Lisp is not its power, elegance, flexibility, etc. The curse of Lisp is its syntax! Both "all those parentheses" and what they represent is the curse of Lisp. Lisp forces coders to think in terms of infix trees. These trees need to be carried around in the front of the mind. This mental model is very difficult unless your mind is wired to be able to process code this way. For Lisp aficionados this either comes naturally or with coding practice. The "parentheses" fade into the background. For most people this wiring never comes. It remains too difficult to keep the nested trees straight in their heads. To put it colloquially, it's too difficult to juggle all those parenthesis. If you're a Lisper you'll want to believe that with use comes the familiarity to overcome this hurdle. It's not. If you're a Lisper your probably tempted to redactor a sample chunk of code into something really readable to show this isn't the case. However, that only works in the small. It's like code golf. It doesn't carry over into large scale applications. Lisps mental model just won't become second nature to very many coders. Haskell forces you to juggle "math." Forth forces you to juggle "stacks." Lisp forces you to juggle "trees." The popular Algol descendants are popular, in part, because they're closest to the way people think. The curse of unique brains is the curse of Lisp.

webreac 7y ago
There are many different ways of thinking.
jimbokun 7y ago
> The popular Algol descendants are popular, in part, because they're closest to the way people think. No, those languages not close to "the way people think", unless those people are already experienced programmers using one of those languages. Programming languages are artificial and do not work like human languages. Every programming language requires you to run an internal parser and build partial parse trees in your head to under stand what the program will do. Whether it's Lisp, Java, or anything else. Lisp is not any harder for beginners than any other programming language. > It doesn't carry over into large scale applications. It works far better and more powerfully in large scale applications. Lisp is unmatched in its ability to write large applications, in terms of power and functionality, with fewer developers and fewer lines of code than almost any other language. This is pretty much the whole point of the "Lisp Curse". And no, it's not code golf. It is higher order, more powerful abstractions and coding techniques.

xvilka 7y ago

Emacs is good enough, much more powerful than many "proper" IDEs. But it should be ported to the proper, modern LISP or Scheme, instead of the using its own subset/dialect. And the used dialect is incompatible [1] with everything else. Too bad that GuileEmacs[2] project died, probably because of the same curse though. Porting it to SBCL would be a game changer too. [1] https://www.gnu.org/software/emacs/manual/html_node/cl/Porting-Common-Lisp.html https://www.gnu.org/software/emacs/manual/html_node/cl/Porti... [2] https://www.emacswiki.org/emacs/GuileEmacs https://www.emacswiki.org/emacs/GuileEmacs

eklitzke 7y ago
Why should it be ported? What would be a game changer?
- xvilka 7y ago
  Because you can't use CL libs in EmacsLisp due to the incompatibility. And vice versa.
iLemming 7y ago
Emacs is fine. Emacs-lisp is good enough for what it was made for. Every few years someone gets a "brilliant" idea that it should be something else but that gets nowhere. Languages cannot exist in a vacuum. If there's a proposal to make it compatible say with Racket, then you'd have to create a strange hybrid of Elisp-Racket because you can't just make all the existing Emacs packages incompatible.
- kamaal 7y ago
  >>If there's a proposal to make it compatible say with Racket Racket itself wants to deprecate their entire language, toss every thing and start out with some thing totally new, all over again.

einpoklum 7y ago

> Due to the difficulty of making C object oriented, only two serious attempts at the problem have made any traction: C++ and Objective-C. 1. C++ is not an extension to C. Most C code would quite unacceptable C++, and considered inelegant, unsafe, and overly redundant. 2. C++ is a multi-paradigmatic programming language, not necessarily object-oriented.

dang 7y ago

The submitted title ("The Lisp Curse by Rudolf Winestock (Again, Sorry)") broke the site guidelines by editorializing. Can you please review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and not do that in the future?

PaulAJ 7y ago

Haskell's type checker is not Turing-complete by default. This is a feature, not a bug, because it means that the type checker is guaranteed to terminate. Since this piece was written GHC has been extended so that non-termination can be enabled if you want it. The sideswipe against the supposed venality of managers is unwarranted. Programmers are like mountaineers in a world where the terrain shifts radically and unpredictably. One day you are on top of a mountain, the next day, without having moved, you are in a deep valley. Under these circumstances teams of people in ATVs who can move rapidly across the terrain tend to have a higher average altitude than people with karabiners and ropes.

fithisux 7y ago

Useless talk. If the Lisps were that powerful,every spec would end up with a Lisp implementation. We need better Lisps that make translation from spec to software easier. Lisp can improve. Lisp shall improve.