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

In programming language design, one trope that comes up is the Curse of Lisp. What does it refer to? 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.

“But hold on,” you might say, “zero dependencies is often held up as an ideal to strive toward in software. Shouldn’t the lack of external dependencies be a good thing? Why then is it a curse rather than a blessing?”

Well as usual, real life is a little more complicated, and to cut to the chase, zero dependencies is a lie. When there are zero external dependencies in a project, this implies there are instead some internally-maintained pieces of code doing what an external dependency could have done. So “zero dependencies” really means “some dependencies, but they’re internal.”

1. When you have an internally-maintained piece of code, it does not benefit from the incoming bugfixes that an external dependency might enjoy.
2. It also remains confined to its narrow use-case, while an external dependency might cover more territory.
3. Some say that every internal library supports 80% of the problem domain it tries to solve, but each different internal library across the world solves a slightly different 80% from each other.

Diagram of what happens when we create multiple solutions for the same problem

Additionally, this curse means the incoming applicants to join a business have no familiarity with the internal implementation. However, the Curse of Lisp is actually not specific to Lisps. (Anyone who’s contributed to an open-source C program will probably have seen a memory allocator or memory pool implemented, for instance.) Indeed, this problem is fractal and occurs at every level of a business. Sometimes, the businesses become self-aware of this tendency toward building on internal dependencies instead of external ones, and it is usually then dubbed “Not Invented Here” (NIH) syndrome.

But the connection to Lisp reminds us that sometimes, making it too easy to do something can backfire. And just because something is easy or fun, doesn’t mean it’s right. When designing systems, we need to take into account outcomes in addition to how they are tied to human behavior.

Intentionally making things not as easy as possible does however create tension with the desire to empower employees to do anything they feel they need to.

What tips do you have for avoiding “Not Invented Here?” I would be curious to know your thoughts in the comments below.

References

The Lisp Curse (Rudolph Winestock): http://www.winestockwebdesign.com/Essays/Lisp_Curse.html