
Where Lisp Fits - Adrock
http://adereth.github.io/blog/2014/02/03/where-lisp-fits/
======
todd8
I've heard all of these arguments in support of Lisp for many years, but I'm
still not convinced. Indisputably, Lisp is remarkable and holds a special
place in the pantheon of programming languages. Every argument in it's favor
makes sense, a lot of sense. Reading these arguments in favor of Lisp is not
like reading a blog touting the benefits of Javascript where even the positive
points don't really sound so positive. The arguments made for Lisp are
persuasive.

Lisp is different. It's really quite unique; it has an elegant simplicity
underlying its implementation and a deep connection to the foundations of
computation. Think of this, Gregor Kiczales's book Art of the Metaobject
Protocol was published 23 years ago! I learned to program in Lisp 40 years
ago. What other languages did I use back in those days? Assembly language (IBM
360, CDC 6600, IBM 1130, etc), PL/1, Fortran, APL, COBOL. Nobody, argues today
that we should be trying out PL/1 or we should give COBOL a try. (Are there
any projects on Github using these languages from our hazy, distant past?)
Lisp's beauty and power have kept it alive and vital all these years. But,
there's something wrong with this story.

If Lisp is really so great, why hasn't it triumphed? I use Lisp all the time:
my editor needs it during periodic tune ups. However, I can't think of when
I've reached for it first when I've had a choice. Python is just easier to get
things done in. If my programs don't run fast enough I don't think of Lisp, I
think of C or C++. Haskell is where it's at as far as programming language
research goes, not Lisp.

The important observation is that it's not just me. Lisp has had time to prove
itself. It made it to the finals, and it deserves the lifetime achievement
award. We can honor it's beauty, it's longevity, it's power, and even it's
fantastic reincarnations (Clojure), but this isn't enough. If Lisp really was
the language that we should be programming in, it would have demonstrated it
by now.

~~~
beat
As I often say, LISP is the language of the future, and it's been the language
of the future since before I was born (in 1965!). It will always be the
language of the future. If it hasn't become the dominant language in 50 years
of computing, it probably won't happen. On the other hand, it hasn't died in
50 years of computing either. The only other language that has shown that kind
of longevity is C, which came into being less than a decade after LISP.

Frankly, I think a lot of the problem is social. LISP proponents have a
historical condescension that really doesn't sit well with all the programmers
that they think are idiots for not using LISP. Less stick and more carrot
would go a long way. Consider the thread elsewhere in this discussion that
whines about how Clojure even got mentioned! Clojure is exactly the sort of
carrot that will bring current programmers into the functional paradigm.
Bashing it because it's not pure enough is lunacy if you ever want your
language of choice to be dominant, and not merely feel smug and superior to
the lazy corporate sods who use crap languages. I see these attacks and
remember the attacks on Scheme long ago - same issues.

I firmly believe large social things happen for a reason other than "people
are stupid". If LISP holds only a tiny corner of the programming world while
some genuinely dreadful languages (PHP!) rule the roost, there's probably more
to the story. It would do the LISP community some good to meditate on that for
a while.

~~~
hga
"LISP proponents have a historical condescension"

I think this is a recent phenomena, which probably developed after the late
'80s AI Winter et. al. crash. When Lisp was ascendant in the early '80s, the
attitude, at least in the MIT community, was that everyone could and if they
so desired should learn Lisp.

Bernie Greenberg, among many other things the author of Multics Emacs, which
used Maclisp as one of its implementation languages and of course as its
extension language, was immensely proud about MIT secretaries using it to turn
keyboard macros into real extensions.

Although, he was a major evangelist at the time, author of a great intro I've
been trying to find a copy of, the guy who said "Cons is an object which
cares. It cares about its car and cdr", etc. etc. But he was fully supported
by everyone I knew in the MIT Lisp community.

And I think Scheme escaped some of this, or at least it didn't suffer like CL
did since it retained its place as a teaching language for quite some time,
only falling in this century (e.g. MIT panicked after the dot com crash
resulted in EECS enrollment dropping more than by half, Berkeley recently
retired its SICP class when professor Brian Harvey retired, etc.) ADDED: and
unless things have changed very recently, has retained its place in computer
language development. Heck, while not the same thing, Javascript is basically
a Scheme with a prototype-based object system and C style syntax.

Clojure as far as I can tell has escaped this, then again it's being quite
successful currently and per my guess above that would help a lot.

As for the "people are stupid" thesis, our host has interesting commentary in
that direction with his Blub language hypothesis:
[http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html)

BTW, as I understand it, FORTRAN, the first computer language (Lisp is the 2nd
oldest _survivor_ ) still is very big in number crunching.

~~~
beat
"Recent" in this case is still before many current programmers were even born.
25 years ago isn't really recent anymore.

As for FORTRAN, there are a couple of reasons. First, the ability to skip a
pointer dereference on large tables for performance, and second, the existence
of fine and ancient libraries for well-known problem spaces. I used to work
with some old Cray guys, and they would rant about how FORTRAN was the best
language ever on purely performance grounds.

~~~
hga
Indeed for "recent", but then again we're discussing a language which first
appeared in 1958, 3 decades before the cause I posit for the mainline/CL
community becoming ... not so nice. Note that I don't really know, I left it
for Scheme by the middle of the '80s.

Is no one writing large bodies of new FORTRAN code? Or is it mostly in COBOL
style maintenance mode, and e.g. called a lot by Python, which I gather is
getting a lot of attention in the scientific community (I started with IBM
1130 punched card FORTRAN "IV" in 1977 in a academic year long class, but
stopped after that, it wasn't an answer for the sorts of problems I was
interested in, C and Lisp are).

~~~
emkemp
Fortran is very heavily used for development in numerical weather prediction.
For example, the WRF model
([http://www.mmm.ucar.edu/wrf/users](http://www.mmm.ucar.edu/wrf/users))
includes hundreds of thousands of lines of code and has been under continuous
development since the late 1990's.

And Fortran has evolved significantly in the last two decades, absorbing many
features (and lessons learned) from other languages. Structures, modules,
encapsulation, argument checking, pointers, allocatable arrays, classes,
inheritance, function overloading, pure functions.... Wikipedia has a decent
summary
([http://en.wikipedia.org/wiki/Fortran](http://en.wikipedia.org/wiki/Fortran)).

------
tlarkworthy
An interesting next step to Turning machines I read about recently was
Kolmogorov-Uspensky machines. They allow pointers and are nearer to real
machines we use. Whilst they still recognising the same languages in
polynomial time as Turing machines, for some things they can compute and order
of complexity class faster. Turing machines often end up traversing up and
down the tape, linearising binary tree lookups for instance, whereas KU can do
binary tree lookups in O(log(n)). Both machines do the lookups in P, but KU's
particular P can be provably lower.

[1]
[http://esolangs.org/wiki/Kolmogorov_machine](http://esolangs.org/wiki/Kolmogorov_machine)

------
mrottenkolber
Have to say by now I am tired of clicking on a Lisp titled article and having
to read about Clojure. Please stop hyping Clojure. It's not LISP and its not
Lisp either. We have a Lisp, it's called Common Lisp, its perfectly fine, far
superior to Clojure and will prevail Clojure by decades.

To underline how awfully skiddish Clojure is from a lispers perspective, the
first thing he mentions is the "thrush macro":
[http://clojuredocs.org/clojure_core/clojure.core/-%3E](http://clojuredocs.org/clojure_core/clojure.core/-%3E)
Which is needlessy to say a typical example of the skiddish culture of
Clojure. The brain train goes like this: "Oh we have grown this ugly zombie
breed between a ruby and a java, how to we make it look intentional? Oh that's
easy just put on a little of this completely pointless macro cream to make it
look hip!"

Worst: The article isn't even about Clojure. Please in the future label
Clojure as what it is (an experiment in STM), and do not forget to mention
that we have a great standardized language with great implementations which
make the whole industry look bad. And we have that because engineers worked on
it for decades.

Edit: Thank you kind power-user for going through the whole thread and
downvoting every comment I made, that's the kind of cargo-cult marketing I was
talking about. I think downvoting shouldn't exist, makes it unpleasant to
comment on topics where you don't share the mafias opinion. Yay HN!

~~~
swannodette
Nothing against Common Lisp but CL is not _the_ lisp and it never will be. CL
is _a_ lisp same as Clojure -
[http://www.islisp.info/faq.html](http://www.islisp.info/faq.html). Also you
seem to have no problems critiquing a language which you obviously have no
significant experience with - "Clojure is an experiment in STM". Guffaw.

~~~
lispm
Clojure is a new language.

Everything in Clojure had to be implemented new. There is zero compatibility
and zero code sharing to/with Common Lisp, Emacs Lisp, Autolisp, ISLisp,
Standard Lisp, Maclisp, Lisp Machine Lisp, ...

~~~
hga
Which are all examples of mainline LISP.

What about Scheme? Sure, it was bootstrapped in Maclisp, but not too long
after had pretty much " _zero compatibility and zero code sharing_ " with
mainline LISPs. But is it not a LISP?

~~~
lispm
There are different types of Lisps.

1) the Lisps: they carry the name and share basics: Lisp 1.5 ... Common Lisp,
...

2) the derived dialects with some compatibility: Scheme, Interlisp, ...

3) the derived^2 dialects: Logo, MDL, Dylan, Racket, Clojure, ...

4) the derived^3 dialects: ML, ...

The Lisps is category one were and are able to share code. Emacs Lisp
implements some of Common Lisp. Something complex like the LOOP macro was once
a single source file for Maclisp, Lisp Machine Lisp and Common Lisp.

Clojure shares no source code with any other Lisp. It renames basic vocabulary
('atom') and lacks some older concepts. It's basically a new language.

------
roywiggins
No mention of lambda calculus? Lisp is to Lambda Calculus as Pascal is to
Turing Machines. More or less.

Oh, beaten to the punch in the article's comments. Carry on.

~~~
Adrock
OP here... here's my reply from the comments:

Yep, I'm aware of the Church-Turing thesis and the relationship between TM and
the Lambda Calculus. I originally had a mention of it, but I removed it
because I was really more focused on the RegEx -> CFG -> ? chain and I
couldn't find anything that made that connection with the Lambda Calculus. Any
sources that make _that_ connection would be appreciated!

~~~
roywiggins
You might like Thue; it operates solely on replacement rules and is trivially
an unrestricted grammar:

[http://esolangs.org/wiki/Thue](http://esolangs.org/wiki/Thue)

------
Zigurd
TFA doesn't actually say where Lisp fits. I rather wish some contender for The
Next Mobile OS would make a "Lisp Android" \- An ART-like Lisp runtime with a
zygote-like fast start for processes and copy-on-write to crunch down memory
use from multiple instances of the runtime.

That's where I think Lisp would really fit. But it would take a lot of
unconventional thinking about Lisp implementation and APIs.

------
calroc
Backus' paper on Functional Programming might be of interest; click on: "ACM
Turing Award Lecture"
[http://amturing.acm.org/award_winners/backus_0703524.cfm](http://amturing.acm.org/award_winners/backus_0703524.cfm)

------
grdvnl
nitpick: Here is the link that describes why Clojure's threading macro is not
really a pure thrush operator.

[http://blog.fogus.me/2010/09/28/thrush-in-clojure-
redux/](http://blog.fogus.me/2010/09/28/thrush-in-clojure-redux/)

