Imagine, one time, some writer, writing a short story of laying in bed with their sleeping spouse on a peaceful summer night, wrote wistfully of how they loved that their spouse's hair smelled faintly of citrus at that moment.
And a blogger stumbled upon this piece, and decided there was a widespread problem with people rubbing oranges on their heads, and, further, with the general problem of the author's entire nationality of people, and that this urgently needed to be exposed to the public, in a patient explanatory blog post.
Seeing this blog post, others, realizing that there's been a misunderstanding, but knowing more about that nation (and/or fruits, and/or hair care), than about PR damage control, proceeded to respond, with a flood of various corrections, all over the map.
For example, "I prefer fresh-squeezed lemon, so long as you're careful to avoid traumatic brain injury." And "Those people are not that bad; the many stories of kidnappings are often exaggerations of muggings." In all seriousness.
And anyone observing is thinking "I'm even more confused than before, but those people sure are defensive about whatever the heck ungodly things they're doing with fruits. It might be a nice place to visit, for a day trip, but I wouldn't want to live with those crazy fanatics."
I think if I cared about damage control I would have deleted the article a long time ago as so many people have clearly missed the point of the post.
Again I would never (and didn’t) draw an issue with an entire nationality of people squeezing oranges in their hair, particularly being an orange-squeezer myself. If anything, it would be better if almost everyone would be squeezing citrus in their hair every day, as we would more readily be able to point to the side effects associated with doing so without it seeming like an affront to one group of people.
True, this analogy is confusing, but it’s also great that you created it.
Your main reply to "not invented here" is "okay, invent it here and maintain it here then, buddy".
One of the key skills of a a senior dev is to be able to judge the tradeoff between rolling your own and borrowing someone else's. In your life as a dev you'll be making this choice all the time. The pros and cons are generic: time spent, potential bugs, security, free upgrades, specific vs general solutions, external reliance, and so on. But you will exercise this judgement constantly.
Also not being a LISP guy, is it really so common to roll your own everything? Would you write your own JSON parser, is it that easy in LISP?
It's still somewhat common, but over the past couple of decades we've created package managers like QuickLisp that allow calling external dependencies in Common Lisp as easy as it is in Python (and even systems to allow us to interact with Python to get access to its ecosystem), plus a version of Common Lisp (Armed Bear Common Lisp) that runs on the JVM to get access to that ecosystem (not to mention the Lisp-adjacent language Clojure).
Lisp people are quick to rewrite basic language semantics. As somebody already said, rewriting parsers is more of a Haskell thing to do.
That said, Lisp developers learn to fight their instinct and not redefine the language all the time, just as Haskell developers learn to fight their instinct and not make complex types all the time, and C++ developers learn to fight their instinct and not use STL all the time. But those take some experience.
> Would you write your own JSON parser, is it that easy in LISP?
I only dally with Lisp(s) but probably not, I'd reach for a library in quicklisp.
However, in Janet (https://janet-lang.org/) there's a PEG parser and I wrote a JSON parser for fun in 134 lines that passes most of the test suite by Nicolas Seriot.
So I'd say it's reasonably easy for a better-skilled programmer than I am.
The main reply was to use more things off the shelf, or at least be aware there is a business cost of not doing so.
Ironically this blog post isn’t even targeted at developers but more management types, but it wouldn’t be life without being spectacularly wrong on HN and raked over the coals on it. In short though I agree it’s not like you can just use off the shelf for everything or that that is even a good idea to try as that has its own set of problems.
> Also not being a LISP guy, is it really so common to roll your own everything? Would you write your own JSON parser, is it that easy in LISP?
As someone who has dabbled in lisp: IME, everything is easier - enough so that I more-often _consider_ inventing something that solves my subset of the problem.
I suspect this contributes to the poor library availability situation (I understand that's improved markedly in recent years, but still).
We have a fantastic Common Lisp package ecosystem with Quicklisp and we use other people's libraries all the time. Most of us are savvy enough to share our 80% solutions so that others can add their 20%. I wish more people would realize that the Common Lisp we program in today is not your Grandma's Common Lisp. Lisp usage and culture change over time just like in every other language ecosystem. I never see my Lisp reflected in these tired tropes.
Thanks for the feedback, I have never heard anyone contest the 'Lisp Curse' claim, and mostly the Lisp I've written has been small-time, so this article is not supposed to be about lisps per se, more the business impact of the idea.
But that said, obviously Clojure with deps.edn exists. Looking at Quicklisp's package manager, it looks like the packages are updated on at least a year's interval? That seems quite slow if you are looking to socialize your changes, use someone else's recent bug fix, or to defragment a project.
> I have never heard anyone contest the 'Lisp Curse' claim
You could have asked in the community for opinions.
> This is because Lisp makes it very easy to write your own libraries from scratch;
That's not generally true. Some libraries are maintained for decades, since it would be difficult to reproduce them.
The reasons for writing new libraries, instead of an existing one are more like:
* disagreement with coding styles
* very different underlying platform
* need for a different license
* lack of maintainers for code written decades ago
> people who use Lisp tend to do that instead of reusing third-party dependencies.
I don't think that's the case. There are widely used libraries for a bunch of things and having a stable and standardized language makes it actually easier to write platform independent code and enables code sharing.
There are reasons why people write their own libraries, often because existing libraries were written for different platforms (especially the operating system).
In the free software area of Common Lisp, a system like SBCL is popular because of the network effect in a small niche of Lisp programs. Libraries tend to be better supported in SBCL -> more use for SBCL.
> You could have asked in the community for opinions.
True, and I was focused on making a non-Lisp point so I didn't and apologize for that. I do find the feedback valuable although I wonder how to reconcile what's been posted here with what I've heard from other Lisp coders.
Trying not to beat a dead horse, but I recognize there may be many reasons people come up with for writing a new library instead of reusing one. My point is that it has a business impact to do it that way, because unless that library is open-sourced, the next time it happens it will be an overall loss for the industry due to solving the same problem again and again in slightly different ways.
> Trying not to beat a dead horse, but I recognize there may be many reasons people come up with for writing a new library instead of reusing one. My point is that it has a business impact to do it that way, because unless that library is open-sourced, the next time it happens it will be an overall loss for the industry due to solving the same problem again and again in slightly different ways.
One of the reason to use Lisp was to leapfrog the competition. See for example: https://paulgraham.com/avg.html Applications were written in novel areas by small teams. The commercial Lisp vendors had their development environments bought and be used by these teams, but they could not post success stories, because they were not allowed to mention the customer and its application. Here often substantial and complex software had been written, at the core of some new business venture. The reason this software code could not be used by, then was not that it easy to copy, but that the developers did not want to give their competitive advantage away.
For Lisp libraries -> if any library domain gets complex, there will be only a few ones which actually get used, because it was non-trivial to write. People might try to write simpler or new ones, but the better ones are hard to replicate and Lisp developers will tend to use those. For example the Lisp cookbook recommends one Regular Expression library: https://lispcookbook.github.io/cl-cookbook/regexp.html That's what most developer tend to use - it is widely ported, written in good style, well tested, ...
A strange thing in the Common Lisp world is that new developers stumble of old libraries. They expect libraries with lots of bug fixes and a long maintenance log. But the library hasn't much touched in since some years.
They detect then, that this library is "done". It has reached a state where not much needs to be done. This is also an effect of Common Lisp, where the language is mostly stable for several decades and code can be used for a long time without the need for a new attempt.
It feels like Lisp and Open Source are old enough this should not be a relevant concern anymore. Many newer Lisps exist that have been OSS their whole lives, including the community infrastructure. What remains are the inherent properties of the language instead of any legal artifacts.
That is a great set of responses to the Lisp Curse article. Again I will note that my points are not about Lisp as I'm just taking that article as granted (which it turns out it's not, but still). The point about the pareto principle is also language-agnostic, and an interesting point. It's sort of a proof that the 80% problem is going to persist to some extent even if you do use many dependencies. (Note not to the fullest extent — the 80% problem can at least be mitigated by everyone not reimplementing everything every time.)
The Lisp Curse article was written by a web developer with zero Lisp experience in even a hobby setting, let alone professional. He just made it up, like a hallucinating LLM.
> Looking at Quicklisp's package manager, it looks like the packages are updated on at least a year's interval?
I think it used to be closer to monthly. It has slowed down a lot recently. I've seen talk on IRC about ideas on how to improve the bus factor for that situation.
Also, there are some alternatives to Quicklisp that exist, such as ocicl, which seems to be gaining in mindshare. I haven't used it personally (yet), but so far I've only seen positive feedback from people that have tried it.
If there is some Lisp package that has frequent updates that are not picked up via Quicklisp, and you want to keep up with those, then just put the tree of that thing in your project, and refer to its .asd file from yours.
What about the curse of an entire field that's so systemically incompetent -- starting with how it hires, and therefore, now, how it trains -- that the field is incapable of (for example) building a system that's not riddled with security vulnerabilities, yet the field confidently churns out a flood of blog posts about best practices?
> churns out a flood of blog posts about best practices?
...most of which are cargo-culting carbon-copies of "gurus" and "authorities" (and "Uncle Bob"). No critical thought in sight, but a lot of mental gymnastics to justify conclusions that don't follow from whatever was written above.
The massive influx of poorly prepared junior programmers in the last decade doesn't help. Somehow, beginner programmers tend to overgeneralize from too narrow a perspective, leading to fallacious but firmly held beliefs. This is nothing new and happens to most beginners; the problem is that we're dealing with a massive wave of beginners that seems to be still gaining momentum instead of subsiding. One of the effects is that the experienced, mature programmers' voices are drowned in the noise, save for a few "gurus" who are often better writers than programmers.
The whole field shunning its own history doesn't help either. The culture of moving fast created a misperception that things older than half a year have no value. Similarly, agile and co. made it so we live in perpetual "now," rarely considering the long-term consequences of our work. This leads to resume-driven development and contributes to enshitification of everything, yet nobody seems to realize there even is a problem, much less have any intention of fixing it.
Honestly, I'm struggling to find my place in the field after two decades of coding.
> The massive influx of poorly prepared junior programmers in the last decade
It's been more than a decade. Take a time machine back to 2014, and we're
complaining about religious zealotry among followers of the GoF book,
debating whether SOLID means anything useful at all, and enjoying spicy
rants like "Rails is a Ghetto." I think the problem is not so much that
junior programmers are generally ill-prepared to do professional work --
that much is to be expected -- but that the industry continues to be
unable or unwilling to evaluate competence.
All the things you said about junior developers hold for senior developers too. This field of computer science is over a hundred years old, but we don’t (and can’t) treat it that way. The overgeneralization stems from having strong beliefs. Where do you get the idea we have a massive wall of beginners? Just a week ago was posted, “The End of Jr Engineers.”
I feel like the author is perhaps making a valid criticism of Common Lisp that was only valid in ancient history. In the 1980s I felt like I was all alone sometimes developing on my Lisp Machine - I often would write utilities that I wished I didn’t have to write myself.
With the advent of Quicklisp, many repos on public services like GitHub, etc., it is now easy to find and use good libraries for Common Lisp.
Of course there is a network effect: a language like Python is much more popular so there are many more libraries available. That said Common Lisp, Racket, and other Lisps all have good ecosystems and are fun and productive to use.
> In the 1980s I felt like I was all alone sometimes developing on my Lisp Machine - I often would write utilities that I wished I didn’t have to write myself.
The early .com companies on the Internet were all deeply involved in Lisp/AI companies: Symbolics, BBN, Thinking Machines, MCC, Xerox, SRI, ...). Plus a bunch of universities (MIT had hundreds of networked machines running some Lisp, including Lisp Machines).
Many of the R&D groups were on the Internet. Larger amounts of code were for example shared via tape. For example the Symbolics User Group already shared code. The CMU CL wrote their Lisp implementation as public domain and shared all their implementation code: Lisp, editor, UI, ...
At that time a lot of new stuff was developed, like CLX, the X11 interface for Common Lisp. Every Lisper on X11 was using it. TI developed CLUE and CLIO on top of CLX. LispWorks developed their gui toolkit on top of CLUE and CLX.
Sure, there were lone developers but Lisp in the 80s was widely used in universities and R&D. All were networked. MCC had 200 Lisp Machines in their network, IIRC. MIT more. SRI similar. Xerox. BBN even developed their own Lisp OS + machine. Symbolics had support for DECNET, TCP/IP, IBM Mainframes, ...
The Common Lisp standard, developed in the 1980s was probably the first developed with heavy e-mail support.
The author generously omit the long jurney through the negative side of external dependencies. This is somewhat frivolous and too unbalanced to be reliable this way. The truth must be somewhere inbetween again.
As far as I am concerned, the only (almost) valid point they made is this one:
> When you have an internally-maintained piece of code, it does not benefit from the incoming bugfixes that an external dependency might enjoy.
But, even this one is not always good. Your internal code might not have the bugs that would affect your program, might be less efficient due to doing things that are not relevant to your program, and you might be able to fix the bug more easily in your own program than you would with an external dependency, especially if they do not fix it in time. There is also vulnerabilities, and other stuff. Furthermore, the external dependencies might make the program larger than it should be. There are many good reasons to avoid external dependencies.
Key word is might. Yes, it’s a game of probability, and also a game of “is it, though?” I would posit that something maintained by the wider public is less likely to contain bugs than something maintained by a smaller/less varied group (you or your company).
Yes, you can point to xz-utils as an example of the ineffectiveness of groups at catching attacks, but it’s also famous because it’s exceptionally bad and probably not normal.
Whether or not that is true (and what kind of bugs) might depend on the specific software. Furthermore, sometimes changes to external dependencies may introduce bugs (which might or might not be malicious; both kinds can and do happen), which might be fixed in a later version but that might take some time.
Another alternative is that if the dependency is only one or two files, you can just make your own copy of them and use those instead, and maintain them by yourself, reviewing any changes to the official version and applying them to your own if you consider them necessary; this might also allow you to fix bugs that haven't been corrected and to omit features that you do not need.
Another reason you might wish to avoid external dependencies is if they cannot be packaged together with the software; if they come from a different source, then there is the possibility that the external source may be no longer available (which might or might not be malicious; again, both kinds can and do happen). (If they are not very large and only one or two files, then you can just include it with your software.)
If your software uses external dependencies, you might also specify exact versions by both version numbers and cryptographic hashes. The use of cryptographic hashes will mitigate some types of attacks as well as to potentially allow finding other copies if the source that you got it from is no longer available.
Another issue, depending on the kind of dependencies, may be interfaces with other software (possibly including the operating system), in which case there may potentially be multiple possible implementations, and the system administrator may wish to install their own.
In the package manager for operating system design that I had considered, this is also an issue that I had considered. A package can have multiple identifiers of any kinds. Additionally, there are other features of the operating system which can help many things. Hopefully, these things will be able avoid many kind of problems.
Compare and contrast with “the curse of JavaScript” which is the opposite problem of an explosion of dependencies and the management thereof. The business guys might not like it (“it’s too hard to replace engineers”) but, from a software engineering perspective, a tendency towards fewer dependencies is better for the system.
This gets at an interesting nuance. The under-reliance on dependencies actually poses issues at a system level, not at an individual product level, which makes it hard to sell business types on the existence of the problem.
Is it really hard to replace engineers when you have a lot of dependencies? A lot of dependencies means a lot of things you have to learn. Let's consider the case where every line of code invokes a different dependency. That's clearly insane and not the ideal case, even if they are all well-known dependencies. Everyone on the team will be constantly chasing down documentation for the dependencies they don't know.
The optimal point is somewhere in the middle. I just am pushing for more dependencies because I see it being too far in the "no dependencies" direction.
This feels like an argument against learning how to play an instrument. Why would anyone do that when there are so many other highly skilled players out there?
Learning an instrument is a great thing to do and I can highly recommend it. What I can't recommend is learning an instrument from scratch when you were hired to play that instrument in an orchestra, as you are being paid to play in the orchestra.
> Well, a particular genre of programming languages (Lisps) is essentially immune to the network effect, unlike most other languages. This is because Lisp makes it very easy to write your own libraries from scratch; people who use Lisp tend to do that instead of reusing third-party dependencies.
What? Lisp makes implementing libraries no easier or harder than most other languages. Even the original author afair criticised his own article about the lisp curse some time ago.
Another article by a non-practitioner of Lisp trying to harm Lisp people.
Because we are few in number, it's hard to defend against, and harmful.
It is not easy to write your own libraries in Lisp. You're not going to write your own cryptography, web serving, database access, regular expressions and whatnot, and if so, not to the level of quality of available libraries.
People developing applications in Lisp use libraries.
First, I'm not a non-practitioner of Lisp, I've written a fair amount of it. And more importantly, the article isn't about any programming language. Further, I have heard this phenomenon bolstered by heavy Lisp users IRL and Eric Normand who hosts LispCast. It's insane to me that you would think this is written to harm Lisp users, as I love the community and the languages.
My point is something that applies to every (other) language, and it's a point about fragmentation. If you use packages in your favorite language, that's great, and not who I'm talking to.
How is that the effect? The maximum extent of damage, if any, is referencing an already-widely-referenced text. I'm not attacking anyone, or anything, aside from the concept of dependency avoidance.
Honestly, having a curse named after you makes you cool in my book, at least when you adopt the "no publicity is bad publicity" outlook. Especially when the core critique is that the curse is that the language is too powerful.
> [Wikipedia] Network effects are typically positive feedback systems, resulting in users deriving more and more value from a product as more users join the same network.
> [Your article] (Lisps) is essentially immune to the network effect.
You're making a strong inverse argument of "nobody got fired for using Java" against Lisp specifically.
I don't necessarily disagree with you; merely pointing out that you simultaneously say that you aren't out to dig at Lisp and then reply by sarcastically digging at Lisp.
Can we please refrain from the modern definition of “harm” to mean “I feel bad when people disagree with me”? If you feel harmed when encountering opinions and arguments different from your own, that’s something you need to work on personally, not the responsibility of other people.
What you're saying is well and good. People in online forums should grow thick skins or else stay out and all that.
I'm talking about actual economic harm here, though. Decision makers in organizations being influenced by made up articles that trash-talk Lisp people, resulting in reduced opportunities in that area.
The fact that millions of programs use the exact same code, is what makes exploring that code for vulnerabilities worthwhile.
If there was more original code, it would have less impact when a vulnerability was exploited and much more effort would be needed to attack each application. Luckily LLM can help us create and test that unique code at a lower cost than before. The problem with everyone not rolling their own library code, is that the experts code often contains issues that exist but do not become public knowledge for years, because libary users don't bother to look at it or understand the code, they don't understand how it works or use it correctly.
And a blogger stumbled upon this piece, and decided there was a widespread problem with people rubbing oranges on their heads, and, further, with the general problem of the author's entire nationality of people, and that this urgently needed to be exposed to the public, in a patient explanatory blog post.
Seeing this blog post, others, realizing that there's been a misunderstanding, but knowing more about that nation (and/or fruits, and/or hair care), than about PR damage control, proceeded to respond, with a flood of various corrections, all over the map.
For example, "I prefer fresh-squeezed lemon, so long as you're careful to avoid traumatic brain injury." And "Those people are not that bad; the many stories of kidnappings are often exaggerations of muggings." In all seriousness.
And anyone observing is thinking "I'm even more confused than before, but those people sure are defensive about whatever the heck ungodly things they're doing with fruits. It might be a nice place to visit, for a day trip, but I wouldn't want to live with those crazy fanatics."