How the Curse of Lisp impacts your business (even if you don't use Lisp)

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

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?

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.

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?

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.

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.

> people who use Lisp tend to do that instead of reusing third-party dependencies

Is there any actual evidence for this?

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.

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 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?

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

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.