
Why Lisp? 3 answers - fogus
http://www.mattknox.com/whylisp.html
======
hvs
These are terrible answers to the question "Why Lisp?" (to which the most
obvious answer would be "For what?").

1) Good ideas? Yes, it did, but many modern languages implement them so it is
no longer a reason to use Lisp. Macros? There are numerous arguments on both
sides about whether those are good or bad. Needless to say, not enough to
justify using Lisp.

2) Your "extension to the language" is my "wtf is this developer doing here?"
Consistent syntax is part of what makes a language intelligible to many
different people. I don't want to be a human parser to understand code.

3) Thrust/weight... ?. OK, I think your point is that there is little syntax
to understand. Unfortunately, that means that context needs to be parsed by
the developer because there are few "road signs" that tell me what is going on
without reading the whole chunk of code in detail.

Finally, I'm not sure what this is in response to (other than it being the
eternal question that burns in the hearts of all men) but if it is an argument
for using Lisp on a project, it would be better directed at what Lisp has that
makes it good for production work in a modern environment. However, in that
way, I don't think it is much better than many of the other languages today.

~~~
chimeracoder
> Macros? There are numerous arguments on both sides about whether those are
> good or bad.

Every argument I've ever heard about macros falls into one of two categories:

1\. Concerns about overuse, which says nothing about _correctly_ used macros -
any tool can be overused or used incorrectly.

2\. Complaints about macro systems from heteroiconic languages like C++ -
these two concepts are similar in name only. Lisp macros have nothing to do
with macros in any other language, and they provide freedom that is literally
unavailable in any other[1], as explained well in this description:
[http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.h...](http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.html)

[1] Yes, yes, Turing-completeness, so nothing is stopping you from writing
your own parser from scratch. But the whole point is that Lisp _doesn't_
require you to go through all of that - and secondarily, even if you did,
parsing sexprs is so easy, you've finished before you've even started.

~~~
hvs
1\. True. My concern after years of development both in and out of corporate
environments is that any tool available will be misused if given the chance.
The goal is to minimize the damage as much as possible. If I could be
surrounded by the cream of the crop at all times, that'd be great, but I'm not
and most developers aren't.

2\. I'm aware of this as well. I developed in Lisp for two years. Lisp macros
are not comparable to C macros. I also didn't say they were all bad, just that
there are arguments to be had about their utility. For example, OOP in Lisp
has been described many times as a "leaky abstraction". In my opinion, it just
plain sucks. It gets the job done, but I always feel dirty afterwards. It
shows the power of macros and Lisp, but it also shows the limitations of not
changing your language to support a little syntactic sugar.

BTW, I know it's not apparent from my post, but I actually like Lisp, I just
don't think it is the answer to any question that is being posed right now.

------
mattknox
Note to any potential readers: I was barely a vertebrate when I wrote this
(edit: that must have been 6-8 years ago). I did so because I had selected
TinyScheme for a project that I was doing at work and a bunch of people who
had never heard of scheme or lisp wanted to know why. I briefly got tired of
talking about it (which is rather unusual, to those who know me), and wrote
this.

I still think that lisp is a great language to learn (although forth is even
lighter-weight and about equally powerful), and like clojure a lot for
practical work nowadays.

------
brudgers
_"Sadly, something essentially killed lisp innovation around the time Common
Lisp got standardized"_

I think it was timing, more than anything else.

The movement to create Common Lisp came right on the cusp of several important
shifts in computing. The first was from specialized hardware to standardized
platforms. Lisp bet heavily on the former as embodied in Lisp machines at the
very time that ISA and x86 machines proliferated.

The second shift was from command lines to GUI's and the Common Lisp standard
lacks facilities for windows and other GUI elements. There is no equivalent of
Swing in Common Lisp.

At the time it was standardized, Common Lisp just missed the explosion of the
commercial internet and the distribution advantages it afforded Java just a
few years later.

Finally, the way in which the Lisp community tended (and still tends) to shun
Microsoft Windows, probably played an important role in limiting its general
adoption. After the demise of Lisp machines, the remaining segment of the Lisp
community tended toward FOSS partisanship - somewhat unsurprising since RMS
emerged from the Lisp community and it was closed source Lisp code which first
led him to action.

In short, Lisp was both unlucky and placed bad bets relative to the current
state of affairs. The ultimate effect of a bias toward FOSS remains
undetermined.

~~~
betterunix
It was not just "timing" that killed Lisp (if one can even say that Lisp is
dead -- I use it in my day-to-day work, and I am not alone). While the world's
Lisp hackers were working on lofty AI dreams, the world's Unix hackers were
spreading C to every college, university, and business out there. Had an open,
portable, low-end OS like Unix been written in Lisp, I suspect the programming
world would be a much different place today.

~~~
pjmlp
That is what I tend to think.

Although this is a bit off-topic rant, I really enjoyed using Turbo Pascal,
before C took over in the PC world as well.

So thanks to UNIX/C being spread the way they were, better languages got a
hard time being accepted in the mainstream.

And we are still paying with security exploits C's success.

At least static analysis of C code seems to be becoming a common trend...

------
dbecker
I was excited about Lisp for a while, primarily based on all the claims of
increased productivity.

I started going to Lisp and Clojure meetups while learning, and I was struck
how much LESS productive the supposed gurus at the meetups were in Lisp than I
am in Python.

Maybe that reflects on the language. Maybe these people were posers. But the
claims I hear seemed inconsistent with what I saw.

~~~
rayiner
How much does your problem domain leverage Python's available standard
library? I'm pretty familiar with both, and the former is what I use to write
stuff when I don't have a library available that does the work for me. The
latter is what I use when I don't really have to do much work to leverage
something someone else has already built.

~~~
dbecker
Personally, my programming involves heavy use of the scientific computing
libraries. But my comparison was for general programming that doesn't use
these libraries, and which don't rely especially heavily on the standard
library.

------
mratzloff
For personal use, sure. For anything else, language choice requires bottom-up
campaigning or top-down mandates--Lisp never even enters the conversation, at
least in any serious way. Language choice is also heavily dependent on mature
third-party libraries, which are in abundance in many languages but not as
much with Lisp dialects (unfortunately).

Ruby and JavaScript have adopted enough Lisp concepts and in a lot of
organizations enjoy enough support that pushing for real Lisp is a touch
quixotic.

~~~
kyllo
I get the impression that Clojure is at least entering the conversation in
some places. Some companies that need concurrency control capabilities that
they find difficult to implement in Java are starting to use Clojure, or at
least considering using Clojure to make certain Java business applications
threadsafe. The fact that Clojure runs on the JVM and can be called from
inside a Java application makes this easy to do, but in a bottom-up
campaigning situation the hard part is convincing management to sign off on
your use of the language as an "approved tool."

~~~
mattknox
We use Clojure at twitter and I believe that google supports CL as part of the
after-effects of buying ITA. At the time I wrote this, clojure didn't exist
and ITA was not particularly well-known.

------
lispm
There were a lot of good ideas explored in Lisp - but not always they were
first developed in Lisp (for example OOP came from Simula and Smalltalk to
Lisp and merged their with Lisp approaches). Many ideas developed in Lisp have
not even been reused now. It is buried in computer science reports from 60-90
(which no one reads anymore) and code which has been lost (or is not
accessible). Example: Lisp 1.5 from the 60s had a bitmap used for marking
objects during GC - Ruby 2.0 just now implemented this thing. One could have
read old Lisp implementations from the last 50 years - but this is not how
people work. Few people study old stuff and harvest it.

The flexibility of Lisp to change the language in multiple dimensions is still
valid. There are few languages which provide it in a seamless and built-in
way. That's why some people still use Lisp. It's also a thing which limits
Lisp: it is more difficult to understand and goes against the coding standards
in 'enterprise software development'.

------
nnq
> you can even make your own syntactic extensions, so if infix math is
> necessary, then you can have it

...in what Lisp and how can one do this?

~~~
fusiongyro
Any Lisp, but it turns out to reveal a bunch of Lisp warts. The most obvious
one being that no Lisp out there ships with a built-in macro to do this. The
subtle truth, though, is that most people who use Lisp start out wanting this
and then either give up before they become proficient enough to implement it,
or else get acclimated to prefix math and once they are proficient, they don't
care anymore.

If you were to set out to do this, the first thing you'd have to accept is
that the macro is going to look a little weird. For instance:

    
    
        (infixmath 2 + 3 * 4 * (2 + 1))
    

You're going to want to put spaces between all the terms, every time, because
you'd rather have separate atoms for numbers and functions. The next problem
you're going to run into is that Lisp doesn't ship with any context-free
grammar support akin to Parsec or Yacc. This is the corollary to the point
above, that once Lispers become proficient enough to do this they don't want
to anymore. Once you're fully enamored with prefix notation, you never find
yourself wishing for the kinds of grammar that necessitate this kind of work.
(This has a lot to do with why most Lispers hate _loop_ and _format_ too). In
other words, you'll be writing your own recursive descent parser from scratch.

Once you've written your recursive descent parser to handle infix math, you'll
face the next challenge: what to do with the parse tree. The simplest thing to
do is just evaluate it. If you were really clever you might be building a Lisp
prefix expression as you went and you can just let Lisp evaluate that directly
with eval. A part of you will wonder if you should instead generate a compiled
function, but then you have to capture the variables properly and it will be a
lot more work, but it could become more efficient, since the Lisp compiler
would have access to that information and could do better things with it...

Anyway, my point is that this is sort of a will-o-the-wisp or mermaid example,
because it's intended to capture the imaginations of non-Lispers, but actual
Lispers have never actually gotten serious enough about it to make a robust
implementation and ship it with the system, because the mindset that values
infix math is incompatible with the mindset that produces good Lisp
programmers.

~~~
betterunix
The macro will not necessarily look weird, nor will you necessarily need to
put spaces between the terms; in Common Lisp you have reader macros, and you
can make this as simple as using [] to delimit regions of infix notations.

As for why you do not see it done in practice, I would say it is mainly
because it is not terribly useful in practice. Infix notation is just what
most people are comfortable with, because they learned it in school; it has no
real technical advantage, and the need for precedence rules is something of a
disadvantage (though not a terribly major issue).

~~~
fusiongyro
How many projects do you see promoting reader macros? The only package I ever
used that came with one was CL-SQL, and it was really unpleasant to get
everything working. Reader macros are another example of a feature that
Lispers haul out when discussing the benefits of Lisp but never use in
practice, because they're almost always more trouble than they're worth.

The reason you perceive this as not terribly useful in practice is my overall
point: once you're good enough with Lisp to develop this, you think in terms
of s-exps and don't see the point. The primary technical advantage of infix
notation is that the book you're getting the formula from used it, so it's
easier to see if you transcribed it correctly. A secondary advantage is that
it's what you use in your head and on paper. If the advantages of Lisp syntax
outweigh the advantages of a lifetime of schooling and compatibility with the
world at large, you are, at last, a Lisper. :)

~~~
betterunix
Actually I stopped seeing the point of infix notation long before I started
programming in Lisp; infix notation stopped seeming like the cat's meow when I
had to actually spend time thinking about how to parse it. I have yet to
encounter a good argument for infix notation; all anyone seems to offer is,
"Well it's what everyone knows and what we teach in schools!" I am not even
sure that infix notation being taught in schools should be pointed to as a
positive thing, given that "Please Excuse My Dear Aunt Sally" does nothing to
improve anyone's understanding of math (when was the last time you saw PEMDAS
written in a proof?). I'm sure there would be endless complaints from parents
who were unable to help their children with their arithmetic homework if we
suddenly switched to postfix notation in elementary school.

I don't think mindlessly transcribing formulas from textbooks is a strong
argument for infix notation, and it is definitely not a technical advantage. I
am not entirely sure that infix is what people naturally use internally,
either, as it is not unusual to hear people say things like, "subtract 3 from
x" or "divide the sum of the numbers by the count" -- those look more like
something you would see in Lisp than infix notation to me.

~~~
nnq
I hope you mean _prefix_ not postfix. Postfix (or Reverse Polish Notation
<http://en.wikipedia.org/wiki/Reverse_Polish_notation>) is completely
"unintuitive" for both mathematicians and laymen, and I wouldn't wanna see it
in any school... maybe for speakers of RTL languages like arabic it looks more
natural, but... no

~~~
tverlinden
Try telling that to a Forth programmer. ;)

But seriously, now. Reverse Polish notation is plenty intuitive as long as you
don't get too crazy with what you put on the stack.

For example,

    
    
      (7**3 + 9*7) / 2
    

might be rendered:

    
    
      7 3 ** 9 7 * + 2 /
    

That is, "Take 7 and 3 and exponentiate, take 9 and 7 and multiply, then add
the two numbers, take the answer and 2 and divide." Parentheses or extra
spacing could easily be used to increase readability (though parentheses are
never required in RPN; they're purely aesthetic), if that's too much to
swallow:

    
    
      (((7 3 **) (9 7 *) +) 2 /)
    

...But really it's just a matter of what you're used to.

P.S. You'll notice that with parentheses RPN looked remarkably Lisp-like. This
isn't a coincidence. The core difference between prefix notation as used by
Lisp and RPN is that operators in RPN may only take two arguments (it's more
complicated in languages like Forth, but since we're talking about arithmetic
here we can safely make this assertion). This is the tradeoff RPN makes:
losing the ability to have _n_ number of arguments per operator, for the
ability to ditch those parentheses for good.

It should also be clear that one could easily have a Lisp-like syntax similar
in appearance to the RPN with parentheses above (though with Lisp's ability to
have more than two arguments), but just happening to put operators at the end.
Conversely, one could have an RPN where operators are at the front, which is
actually the concept behind Polish notation, where RPN stems from:
<http://en.wikipedia.org/wiki/Polish_notation>

On a final note, since RPN is read from left-to-right exclusively, a speaker
of an RTL language would actually be worse off. The perceived unintuitiveness
is more because English is a subject-verb-object language, whereas RPN is
subject-object-verb.

~~~
nnq
never had experience with Forth or anyth similar, so thanks for clearing.

and the fact that fixed arity for an operator or function makes parentheses
unnecessary is cool... never thought of that before :)

------
duaneb
I'm usually sceptical about "Why Lisp?" "Practical Common Lisp" offers the
confident (and subjective) "You'll get more done, faster, using it than you
would using pretty much any other language."

Well, this is much better.

------
jobeirne
"To an unusual degree, someone who codes in lisp is on nearly equal footing
with the implementer."

Working with good developers => kinda cool.

Working with average developers => oh my god why.

------
pdonis
I have used Lisp as a hobbyist but always find myself coming back to the same
issue: not every data structure is a list.

<http://blog.peterdonis.com/rants/why-python-not-lisp.html>

Another way to put it, as I did at the end of that post, is: why should I have
to reprogram my brain to fit the language?

~~~
lispm
If that's a hurdle for you, then you should not use Lisp. Lesson No. 1: Extend
the language. Lesson No. 2: develop taste how to best extend the language.

Here are the five missing lines which made you not use Lisp:

    
    
        (defun init-hash-table (data &key (test #'eql))
          (let ((hash-table (make-hash-table :test test)))
            (loop for (key value) in data
                  do (setf (gethash key hash-table) value))
            hash-table))
    

'why should I have to reprogram my brain to fit the language'

That's wrong. Lisp is for those who want to reprogram the language to enhance
the brain. If you feel uncomfortable with that mode, then Lisp is not for you.

~~~
kls
_That's wrong. Lisp is for those who want to reprogram the language to enhance
the brain. If you feel uncomfortable with that mode, then Lisp is not for
you._

I don't know if I would go so far as to say the poster is wrong for feeling
that way, but you are correct, Lisp is fundamentally different, and one should
really only embark on learning it, if they want to learn how to do something
fundamentally different. If one has the mindset of "why should I change" then
they are probably going to miss the profound ah-ha many of us got when leaning
a Lisp. They are not wrong for feeling that way, but a Lisp is definitely a
bad choice for them and will only frustrate them.

~~~
pdonis
_they are probably going to miss the profound ah-ha many of us got when
leaning a Lisp_

I think I've at least had _some_ sort of "aha" from learning Lisp; it just
doesn't necessarily translate into something that's worth the extra investment
of using Lisp for the practical programming projects I've encountered thus
far. (To be fair, part of that is the relative paucity of good libraries for
Lisp implementations, compared to, for example, Python, with its "batteries
included" philosophy.) But even when I'm using, say, Python, I am still able
to make use of the "aha" in some ways.

------
xradionut
Why Lisp?

It's fun to play with when I need a break from work or projects. In the real
world work environment I need to write mundane code maintainable by coworkers
and clients, so it's not there. In my hobby, C and assembly rule the tight
memory spaces of embedded hardware, so Lisp exists in a shared dream-state
with Smalltalk and Oberon...

------
rayiner
Three answers are all the same: macros, macros, macros.

~~~
nocipher
I agree with this answer, but I suspect that this is also why Lisp isn't often
a first choice. Meta-programming doesn't figure into language choice
discussions as often as it probably should.

I distinctly recall wishing for macros in Java a few months ago while working
on an Android project -- so much boiler plate for doing so little. I came to
the realization that Java uses XML augmented libraries so much simply because
Java boilerplate is such a pain to write. It's often easier to build a mini-
language on top of XML and use Java to parse and compile it than it is to
write the equivalent Java code. I think that alone says something about the
efficacy of Java and the benefit of using a language with a more malleable
AST.

------
javajosh
JavaScript is enough of a Lisp, and it runs everywhere and is attached to a
(more-or-less) standard UI environment that is getting increasingly powerful.
And if you really like Lisp syntax, and believe in enforced immutability,
there's always ClojureScript.

------
klrr
LISP is great for learning, here's a tip though. If SICP is too advanced,
start with Simply Scheme or The Little Schemer instead.

~~~
muraiki
Another good one, although Scheme oriented (like SICP) is How To Design
Programs: <http://www.htdp.org/>

The second edition is a work in progress, but it gets you going pretty quickly
with graphical programs, so it's a bit less cerebral (and arguably more
interesting for many beginning programmers):
<http://www.ccs.neu.edu/home/matthias/HtDP2e/>

------
ianstallings
The only reason this site loves LISP is because PG said it was special. What a
joke. Sorry to be terse but this whole place is either insane or plain stupid
when it goes on about LISP.

------
laureny
These must have been awesome answers in the late 80's.

