
Why You Do Not Use Lisp -- a survey - fogus
http://kazimirmajorinc.blogspot.com/2009/10/why-you-do-not-use-lisp-results-of-poll.html
======
cousin_it
I mostly do client-side Web development - JavaScript and Flash - and prefer to
write in the native languages of the platform to leave less space for bugs to
hide. (Even MTASC, the very good indie Flash compiler, turned out to contain
obscure bugs after I abused it for a couple years.) And my server-side stuff
is simple enough that Lisp wouldn't be a big win space-wise over the handful
of PHP one-pagers that I tend to write. Lisp also loses to PHP on maturity,
documentation and support - whenever I stumble on some exotic webapp-specific
problem, chances are it's already covered in detail on php.net. It looks like
Perl and Python have ecosystems of similar quality, and some of my friends
swear by the Microsoft tech stack, but unfortunately I can't trust Lisp to the
same degree.

If I ever encounter a problem where cleverness of programming is the limiting
factor, I'll probably use some advanced language (yep, I can handle Lisps,
ML/Haskell or even APL/K passably well). But such problems just aren't very
common. On most projects I spend most of the time figuring out how to solve
_this_ user problem on _that_ programming platform as directly as possible,
not solving mathy type puzzles.

~~~
mahmud
_Lisp also loses to PHP on maturity, documentation and support_

Lisp is 50 years old and standardized for 15 years. Has both an ANSI and ISO
standard, freely available books and manuals written by the best and the
brightest of the Art. There are 4 commercial Lisp companies and a total of 8
standard-compliant implementations.

There is absolutely no comparison, and it's both telling and sad you would
utter them in the same sentence. Take it back.

~~~
frig
PHP.net landing page for string documentation:

<http://www.php.net/manual/en/book.strings.php>

(also available in 7-8 other languages). Note all useful string concepts are
one click away, and the documentation allows user commentary (much of which is
quite helpful).

Common Lisp Hyperspec landing page for Strings:

[http://www.lispworks.com/documentation/HyperSpec/Body/16_.ht...](http://www.lispworks.com/documentation/HyperSpec/Body/16_.htm)

CMUCL string documentation:

[http://common-lisp.net/project/cmucl/doc/cmu-
user/unicode.ht...](http://common-lisp.net/project/cmucl/doc/cmu-
user/unicode.html#toc311)

SBCL's manual has no "table of contents" item that even mentions strings.

Stuff like this matters if you care about accessibility.

It should be trivial to google yourself a well-documented list of a given
language's standard string functions without a lot of work.

~~~
mahmud
In Common Lisp, strings are a subtype of Sequences :-) The PHP String library
you linked to is appalling. It includes a lot of stuff that shouldn't be
squashed together in one "section"; strings, characters, locale management,
i18n, cryptography, sequences, generic formatter, currency parsing and
formatting, uu(en|de)coding, even fuzzy string matching!

Who does this appeal to? no abstraction, no modularity, no visible type
hierarchy or any sense of order.

~~~
ezy
Aaaaaannnd... _this_ is the number two reason Lisp's are not more successful
(number one being the syntax, although that is somewhat related). Instead of
helping to solve your problem, advocates (and the reference documents,
"tutorials") want to engage in academic chest beating exercises.

How hard is it just to acknowledge, just a teeny bit, that PHP is more
successuful than Lisp for real reasons -- not just because everyone but you is
an idiot. That's nice that you think the string library is appalling. Perhaps
it is -- but jesus, how do you even get work done with an attitude like that?
Do you write everything you do from scratch?

Go write a graduate paper on the perfect string library and others can get
real work done.

~~~
mahmud
_Instead of helping to solve your problem_ ..

What problem are you trying to solve? Look at the manual and search Cliki to
find what you need.

<http://www.cliki.net/index>

I really wish programmers would stop acting so helpless and fetch for
themselves.

------
mahmud
A very convenient "have you stopped beating your wife" type poll. Isn't it
funny how one can create a movement from ether by just setting up a loaded
questionnaire online?

Instead of an anonymous and questionable poll setup by someone with an axe to
grind[1] I give you The Road to Lisp. Real names, real people:

<http://wiki.alu.org/The%20Road%20To%20Lisp%20Survey>

\--

[1] The author of that blog is a NewLisp user who made it a habit to troll
comp.lang.lisp and other Lisp fora, demanding people treat NewLisp as an
equal/real Lisp.

------
spitfire
No support for formal proving methods. Some of the software I develop is life-
crtical. "Works here, passes my tests" Isn't good enough.

For offline analysis and general cocking about though, it's the bee's knees.

~~~
wynand
Though I haven't programmed in Qi (which runs atop a Common Lisp environment),
I have read up about its extensible type system. It looks powerful and might
be useful for what you're doing.

~~~
spitfire
You also have to worry about memory usage and runtime determinism - When
restarting an engine at 10,000 feet or on takeoff[1] some things MUST happen
at certain times as quickly as possible. GC isn't an option, and "oops out of
memory" isn't an option either.

It comes down to it that lisp doesn't have the ecosystem behind it for life-
crtical applications. I doubt it ever will.

What it is useful for though is analysis tools - helping keep people out of
those life endangering situations.

1\. See Diamond da-42 takeoff crashes.

~~~
jcromartie
I'm curious now: what do you use? C? ADA?

~~~
alphaBetaGamma
While I have personally never programed life critical stuff, I interacted
closely (on the algorithmic side) with people who did. This was in the
railroad industry.

They used a subset of C (no malloc...) and had a safety certified compiler. If
you crash two trains because of a compiler bug at least you can pass the bunk.
They did not use formal proof methods.

The documentation was massive, substantially longer than the code, to the
extent that doing the actual implementation from the documentation seemed
relatively trivial. Writing and analyzing the documentation on the other
hand... I had the impression that writing documentation to that level of
detail must have taken substantially longer than implementing it directly in
code. And this was probably a good thing as it forced people to think more
about every details.

Once a system was written it had to be certified. Any changes, no matter how
trivial, meant you had to go through the whole certification process again:
slow, painful and expensive.

~~~
gcv
Doesn't the documentation have to then become as rigorous as code ---
effectively a high-level language in its own right? So writing the
documentation becomes, well, just like writing a program without testing it as
you go, without benefit of tests or (if desired) static type checking. If so,
then the development process turns the programmer into a kind of human
compiler: translating the specs into a dialect of C for the safety-certified
compiler.

~~~
spitfire
Actually the formal document languages have type checking and consistency
analysis systems/tools.

Tools like Alloy[1] allow you to write your documentation/definition and check
its consistency. These languages are always limited so you don't get into
Gödel incompleteness problems.

1\. <http://alloy.mit.edu/alloy4/>

------
brown9-2
Shouldn't this survey have a "I never learned it" option?

I can't vote on / use something that I don't know.

------
pilif
(because(as(my(coworker(said:(the(human(brain(is(no(f*ing(pushdown(automata)))))))))))))

SCNR

~~~
dreish
That's the easiest and most superficial rationalization for not bothering to
try a Lisp (any Lisp), but also the least compelling argument against it, and
likely not even the most significant _actual_ reason you haven't bothered to
learn it.

~~~
pilif
I was joking about the syntax and the way how I just can't wrap my brain
around reading lisp and matching parentheses.

I was not joking about the recursive and functional nature of Lisp, both of
which I'm finding very interesting (and my coworker is, in fact, a big fan of
Haskell)

~~~
peregrine
The editor should help you use parens.
[http://code.google.com/p/counterclockwise/wiki/ScreenShots#S...](http://code.google.com/p/counterclockwise/wiki/ScreenShots#Source_code_Editor)

Rainbow parens are really helpful and so is automatic paren matching....

------
huherto
If I wanted to used Lisp, I wouldn't know which version to use. That would be
a problem to me.

~~~
mahmud
You are a programmer: your primary responsibility is problem understanding,
searching the solution-space and evaluating your options.

Even an automaton like the Google algorithm can search data and correlate
them. When I type "Common" it auto-completes "Lisp". You should be able to
search, find, and compare technologies on their own merit.

The entire programming fora are burning with altruistic recommendations for
_free_ Lisp books, some of them classics of the field.

------
JulianMorrison
He dismisses "lack of support for modern programming practice" far, far too
easily. Clojure is modern. CL is not. That lack of modernity is a serious
reason not to use it.

~~~
mquander
I interpret "Lisp" to mean "any Lisp," since none of the reasons he gives are
really related to CL in particular.

~~~
JulianMorrison
Except that the answer would simply be nonsense if applied to Clojure. It
_does too_ have safe, fairly lightweight concurrency, FP and immutable
persistent data, both a standard library with all the trimmings and scads of
add-ons (via Java), yadda yadda, modernity out the wazoo. What's it missing?

(I think the actual answer here is: mindshare. Respondents heard Lisp and
assumed CL, maybe Scheme.)

