Myths of LISP: Curse That Didnt`Really Happen?

What is the curse of Lisp (and who cares)

One of the most common myths about Lisp is that it's "dead".

Hell no, it's alive (and on top of it, it's cursed you know).

'The Secret Weapon', 'big-idea language', 'Arcane magic', — Lisp was destined to become something steeped in mystery. For example, to be cursed.

Spoiler: We are not adherents of the term 'curse'. Moreover, probably the author of the term has been surprised how canonical (and misunderstood) his linguistic masterpiece became.

LISP (List Processing Language) is the second-oldest programming language (after Fortran). It pioneered functional programming, spawned several dialects, and provided a lot of key concepts that we find across different programming languages today. It took its place and found a lot of apologists among developers. JS, Python, and others inherited a lot from Lisp.

Lisps enable to write large and complex apps, in terms of functionality, using powerful abstractions and elegant coding techniques. And now we come to the most important question: the power of LISP!

"The power of Lisp is its own worst enemy". Here is a counterintuitive property of a powerful programming language. And this is where the 'curse' begins.

Why does this Lisp's power eventually result in lone-wolf tendency, throw-away design, poorly documented and unportable systems, tooling 'entropy', and so on? Is it an inevitability, bad manners of programmers, or something else?

Old school Lispers are the Jacobites of the Computer Age. Their warnings were ignored, so their nightmares came true.

winestock on GitHub

We went through different forums and blogs and found a lot of really witty and pertinent comments regarding the topic. We used them in this article and thank everyone quoted here for their sharp mind, eloquence, and sense of humor.

Well, let's belabor (I love this word regarding the topic) the Lisp Curse one more time to see what is hidden behind it.

So, ladies and gentlemen, what do we complain about?

Curse or blessing? Myths, issues and solutions

The pow­er and expres­sive­ness

Okay, here is our number one. The pow­er and expres­sive­ness. Lisp is a 'programmable programming language' that allows you to be user-extensible beyond the core language set. It lends itself well to explorative programming, rapid prototyping, and creating extensible macros.

The only question is "Are you able to cope with the power of the ring Lisp?"

Lisp gives programmers the ability to pick their favourite parts without some BDFL telling them off for not following the Party line.

no-defun-allowed on GitHub

Lisp is unpopular

Yes, you won't find Lisp language on the top of the charts kind of "the most popular language worldwide". But, firstly, 'ad populum' arguments are even irrelevant. Secondly, pure Lisp is something ancestral and is rarely used directly today. Lisp 'reincarnated' into dialects and blesses other languages with its concepts and ideas, including:

• higher-order functions
• recursion
• dynamic typing
• tree data structures
• prefix notation
• garbage collection
• exception handling

and others

Lisps have powered multiple platforms across different industries from e-commerce to data mining and modeling & simulation. It has been successfully adopted by multiple commercial vendors. Roomba vacuuming robot, Mirai that was used to model the Gollum character for the LOTR movies, Arrival's service platform (a British electric vehicle developer) — we can extend this list but better read about it in our previous blog article. Lone wolf developers and scratch-an-itch model. A lot of things in Lisp programming are up for grabs. Often it results in mul­ti­ple com­pet­ing implementations of lazy evaluation, type inferencing, arrows, pattern matching, etc.

'Because you can be so powerful alone, you work longer alone'. Nothing criminal but it provokes some negative tendencies of individualism, such as reinventing wheels, throw-away design, and lack of documentation. Individual programmers often don't handle related parts of the problem which would make the program more useful to others. A solution to the problem is making collaboration 'easier than individualism (for people who care about thought and beauty)'.

Telling a thinker to be more practical, or an individualist to collaborate, or an elegance junkie to ship something 20% polished, is not simple — it's a lifelong struggle at best. lassic on GitHub

lassic on GitHub

Inability to finish things off properly

Future maintainability and portability are orders of magnitude more important than elegant code. It's a safeguard for commercial projects. Ask yourself 'who will be able to read my code?' and 'is it portable?'. Well-structured repositories of useful libraries attract users, who, in turn, add more libraries, thereby raising the popularity of the language, 'rather than reflecting its theoretical potential'.

Aura of elitism

To fully enjoy Lisp language you should become a Lisper. I like one man's quote "The curse of unique brains is the curse of Lisp". But I would put it a little differently. There is nothing particularly "unique" in Lispers' brains (sorry, guys). I'd better call them 'configured' or 'dedicated'. You should be prepared and motivated. This is enough. Liberté. Égalité. Fraternité.

It's true that all programming languages are an acquired taste, but most programmers only want to acquire one taste. People could also do math in prefix or postfix, but almost nobody does.

lassik on GitHub

Poorly-taught

Lisp programming is still associated with symbolic AI since the AI winter and often programmers are сomplain about the low level of teaching Lisps at university. It's a question about training programs and needs for updating.

Best mentors explain 'intimidating' programming concepts in an encouraging tone. So Lisp enthusiasts have to communicate the benefits clearly enough to motivate others to give it a try.

This was unfortunately also my experience at the university. Lisp got introduced as this weird thing that can be used to solve "AI" problems, but the way it was presented one could conclude it was not useful for practical tasks.

dundalek on GitHub

...and many people are still complaining about the syntax. But polish (prefix) notation and reams of parentheses take some time getting used to. Unfamiliar scares us. But the lion is not so fierce as he is painted.

For the same reasons why Sanskrit writings would not be very easy for me to read, Lisp is not very easy to read to some people. And the reason is unfamiliarity.

iLemming on Hacker News

Clojure vs. LISP: Acquired and inherited traits

And in lighter news: Clojure avoids the Lisp curse by design. But first things first.

Clojure is LISP 1 with some minor modifications. It shares with Lisp the code-as-data philosophy and a powerful macro system and hits the scene as a modern LISP that embraced the JVM. Clojure is able to use the JVM libraries and it has escaped a lot of that 'curse' problem.

But not everyone is fascinated by this. Some Lisp programmers find Clojure uncanonical and call it 'False Lisp', 'antithesis of the Lisp Machine' and the 'most explicit to date abandonment of the age-old Lispers' Dream, "Lisp All The Way Down"'.

I've been coding Clojure professionally for > 4 years, and am not bothered by these existential questions anymore.

divs1210 on GitHub

I like the one more quote, 'behind every Clojure primitive there lurks Black Magic'. Something mystery and even fearsome again, you see? I find this witchcraft atmosphere of the Lisp world really cool! (no sarcasm in my tone).

In the same time, Clojure was called the most joyful programming language and there are many reasons why it rocks.

Our libraries don't do more than they need to, which is a good thing. We don't build in functionality, bite off more than we can chew, and paint ourselves into corners.

Eric Normand about Clojure, LispCast

One of the most mentioned Clojure benefits is its community. And it's really distinct from other Lisp communities. High level of collaboration, users full of enthusiasm, and all the delights of mutual support — this simply cannot leave you indifferent. Here you can check our research dedicated to the topic of Clojure community challenges: Mythbusters: Why Are You Shouldn't Be Afraid About Clojure.

There are enough Clojure conferences, meetups, blog posts, and podcasts. Clojure attracts developers' and businesses' attention. May it be so!

So pour out a drink for the king over the water and for Genera. Curse this present dark age of bureaucrats and Posix. And then MOVE ON. The Clojurists are the first sizable community of Lispers that has done that.

winestock on Hacker News

You'll never walk alone: Lispers insights

We ask our programmers to describe their experience with Lisps and share their thoughts about the Lisp curse.

techniques with external libs, bugfixes in libraries with no delays — you don't depend on bugfixes from library maintainers and don't need to wait until the maintainer releases an updated version.

As for the so-called Lisp curse and reinventing wheels, it's often easier to write your own library than to deal with bugs or to expand functionality in someone else's lib, at least, it seems so for me. It was quite difficult to search for libs that fit all my cases. Although Google coped with it, you have to spend too much time checking GitHub links — some libraries that fit well can be abandoned.

I used existing libraries only for large-scale tasks (sql, webserver, network, rule engine). In other cases, I tended to write my own wrappers. To be honest, I was often too lazy to bring an ad hoc solution for a particular project to a full-fledged library and to publish it on Github. You have to write a lot of things, including API description, examples of use cases, tests, and so on.

Remembering my experience, there were some cool things. For example: how I rewrote half of Korma-SQL library to support automatic joins, or extended Lobos to generate all supporting infrastructure for auto-refreshing materialized views (triggers and views).

I put a lot of effort into it but didn't fully pack and document it. Why? Maybe the reason was my heavy workload, but firstly, it's probably about unclear 'Spent Output/Profit Ratio', when you are not sure if it's worth your time and resources.

Artem Barmin

Co-founder
at Freshcode

If there wasn't such a thing as Lisp — I wouldn't be a programmer anymore.

As for the curse of Lisp, I think it is (or was?) definitely relevant in the context of Common Lisp. But in the case of Clojure, which is purposely a simple pragmatic language to solve real-world problems and hosted on popular platforms with multiple libraries, it doesn't exist anymore, or at least to a lesser extent.

Dmitro Klimov

Clojure developer
at Freshcode

Thanks to the 'SICP' book I met Scheme. At the time I actively developed web applications in Python / Java / JS. I wanted to find LISP-family language to increase my efficiency and productivity.

This is how I came to Clojure and ClojureScript. It was love at first sight. REPL, immutable data structures, simplicity of development. Focusing exclusively on real-world business problems. Plus, there is a real opportunity to share code between a frontend and backend. Simple made easy.

Most of the Clojure libraries are designed as lightweight wrappers for Java / JS libs. Therefore, developers are faced with a choice — to take someone else's wrapper or write their own. And in most cases, they choose their own one.

Early in Clojure history, libs development was concentrated around clojure-contrib. It was a single "batteries included" library prior to Clojure 1.3, such a proving ground for new features conducted under the watchful eyes of the members of Clojure/core (a small brotherhood of enthusiasts who swore allegiance to Clojure and support its ecosystem until today).

In recent years, popular Clojure projects are also developed and supported by the clojuriststogether community. I'm glad to note that documentation and the quality of the code are improving overall.

llshat Sultanov

Clojure developer
at Freshcode

Wrapping up

To play guitar like a Van Halen it's not enough to learn chords and copy his tapping technique. You should understand how are guitar scales formed and truly understand the instrument. Then you can play it without tabs, sighs, and cursings.

To understand Lisp you should become Lisper. Are you ready? :)

Nowadays, just use Clojure or Racket and ignore what I've written.

Rudolf Winestock

Author of "The Curse of Lisp" article

We don't claim that Lisp-like language is the silver bullet. But it is worth trying. Embrace the Power of the Lisp!

Emacs is still being developed, Common Lisp is used around the world, Racket is popular within computer science education and research, and beyond. Clojure is thriving. You'll never walk alone.

Freshcode team is happy to expand horizons with Clojure and its best LISP heritage. We are ready to consult you on how to benefit from Clojure software development — please, fill our contact form.