
The Lisp Curse (2011) - felipelalli
http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
======
jandrese
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.

~~~
gaze
what gui library? The only production-ready one is part of Lispworks :(

~~~
pjmlp
Allegro Lisp also has GUI support.

~~~
lispm
A lot of very GUI demanding programs have been written in Allegro CL,
including CAD systems, 3d design system, ...

It came very early with a form-based GUI designer.

Allegro CL addresses with their GUI facilities explicitly MS Windows and
Unix/Linux environments.

------
tabtab
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
Clojure seems to do pretty well in that regard

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

~~~
jimbokun
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.)

~~~
pjmlp
C and UNIX

C++ and Mac OS, OS/2, Windows, now games and GPGPU shaders

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

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

~~~
mumblemumble
The author seems to be well aware, given that, a couple paragraphs later, Brad
Cox's efforts become one of the key features of his argument:

> Once again, consider the C programming language in that thought experiment.
> Due to the difficulty of making C object oriented, only two serious attempts
> at the problem have made any traction: C++ and Objective-C. Objective-C is
> most popular on the Macintosh, while C++ rules everywhere else. That means
> that, for a given platform, the question of which object-oriented extension
> of C to use has already been answered definitively.

The point isn't that you can't do it. It's that, for a language like C, it's a
big enough effort that it's only really happened a couple times, and nobody
strays much away from those two options because the effort required to do so
would be immense.

Whereas, I think that the difficulty of doing so in Scheme is overrated. We
had to implement a fairly decent version as a Scheme homework assignment
during my very first semester of my very first year as an undergraduate. It's
so easy in Scheme that it's plausibly faster to write your own than it is to
choose and then read the documentation of an off-the-shelf option.

~~~
aoeu512
If you build your own you'll have to debug it. If you get it from off-the-
shelf and its built well, it'll be readable and small.

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

~~~
closeparen
Learning curve is a weird reason for such an important and well compensated
profession to be wielding subpar tools towards subpar outcomes. “Yeah,
medicine seems really powerful, but med school is hard and I’ve got patients
to treat.”

Seems more likely that the grass is not actually greener on the other side. If
it were, we’d see small teams of the rare few who _are_ willing to surmount
the learning curve outcompeting the rest of the tech industry.

~~~
mattnewport
This occurs in medicine too. One of the primary problems we're trying to help
solve for our customers is that they introduce medical devices (for orthopedic
surgery) which in theory have many benefits over older devices but which have
a learning curve for surgeons. Surgeons often don't feel they have the time to
invest in learning the new device when they already have experience with an
older device and are confident in their use of it, even if they are sold on
the potential benefits of the newer device once they get past the learning
curve.

~~~
kamaal
Perfectly an acceptable reason as long as you know how to use the older
devices well.

Here we are talking about people refusing to move beyond beginner phase.

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

------
xvilka
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/Porti...](https://www.gnu.org/software/emacs/manual/html_node/cl/Porting-
Common-Lisp.html)

[2]
[https://www.emacswiki.org/emacs/GuileEmacs](https://www.emacswiki.org/emacs/GuileEmacs)

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

------
stcredzero
_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-
Po...](http://www.giantitp.com/forums/showthread.php?238385-quot-Power-is-
Power-quot)

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

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

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

------
B1FF_PSUVM
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)

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

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

------
kgwxd
"We found no items matching the lisp curse"

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

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

~~~
iLemming
Please stop spreading nonsense. The syntax that may be a bit unfamiliar to
uninitiated stops being an issue within literally hours. It takes a few days
to completely become comfortable with it. I have seen people learning Clojure
as their first language, I've seen people coming from other languages. But I
have never met anyone who actually wrote Clojure for a few months and still
couldn't get used to the syntax. Only people who are completely unfamiliar
with the language do sometimes complain about the syntax. Because again - to
uninitiated it doesn't look very familiar. Just like indo-arabian numerals
looked strange to Europeans in 13th century.

~~~
username90
The syntax of lisp is objectively bad from a UX perspective since it doesn't
properly separate different kinds of objects. Our brains are very good at
parsing symbols and very bad at parsing text, and lisp forces you to parse
text to understand the structure of the code. That is great for computers to
parse and generate since the structure is uniform, which makes lisp great for
meta-programming, but it also makes it a horrible language for humans.

Any language which PL enthusiasts considers elegant since you can do so much
with few abstractions will be a really bad language in practice since humans
prefers different kinds of code to have different syntax and look different.

~~~
iLemming
>The syntax of lisp is objectively bad from a UX perspective since it doesn't
properly separate different kinds of objects.

I still don't understand what kind of objects you're talking about and why
they need to be separated? Why pencil.writeOn(paper) is a good UX and
(pencil.write-on paper) is a bad UX?

> Our brains are very good at parsing symbols

Are you saying we should be all using APL? Point me to a single academic
source where it says "from neuroscientific point Lisp syntax is not so good
for humans". 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. But does that mean that written Sanskrit is a bad UX or it
can't convey information or used effectively as a language? I will state
again: I have never met a single person who after writing Clojure for a few
months would still complain about its syntax. Not saying they don't exist, I
just have never met any. Besides - after writing Lisp for a few years I find
it a bit difficult for myself to read code in other languages - Python,
Javascript, C, Rust, etc. And I have been programming in non-lispy languages
for over twenty years. I also personally know a few programmers who started
with Clojure as their very first PL and then later tried to learn another,
more traditional language and they all have struggled. It took time for them
to adjust to new, unfamiliar syntax. ALL of them said that they prefer Clojure
syntax.

> and lisp forces you to parse text to understand the structure of the code

How is Python, Javascript or even SQL are different? You still have to
mentally parse the text to understand structure of the code

> Any language which PL enthusiasts considers elegant since you can do so much
> with few abstractions will be a really bad language in practice

That is why Lisp refuses to die? When Fortran is forgotten, COBOL completely
dead, C replaced with Rust and Java with Scala and Kotlin, PHP gone and Ruby
becomes unpopular, there still will be at least a few dialects of Lisp still
very much alive and thriving.

Take Emacs for example. For decades different IDEs and Text editors been
trying to "kill" Emacs, yet it still thriving and still being used and
packages written in emacs-lisp are in abundance and new ones being developed
all the time. Check Github stats for different languages - you will be
surprised of how much emacs-lisp is published on Github alone.

"Really bad language in practice" turns out to be very pragmatic choice,
otherwise how would you explain that Clojure been successfully used at
companies like Apple and Walmart, at NASA and many other
[https://clojure.org/community/success_stories](https://clojure.org/community/success_stories).
There are multinational companies like Funding Circle that have built their
businesses on Clojure.

Many seasoned CS veterans repeat over and over: "Learn Lisp if you want to
master the art of programming".

So if you don't get Lisp syntax - it's just you. You aren't used to it, it's
unfamiliar, that's all. But there's nothing inherently "bad" about it.

