
Whoever does not understand Lisp is doomed to reinvent it (2007) - rlander
http://lambda-the-ultimate.org/node/2352
======
maxpert
I don't get it. If LISP is such an EPIC language why are there no major pushes
from LISP community, or just showcase a piece of software that proves it. I
have been looking on internet about what makes LISP cool it's ideas about code
is data, powerful macros and hell lot of bragging about being able to define
your own syntactic sugar but can't find a single MUST HAVE piece of code that
makes me say "I have to learn this". It's a ML age now and developers around
the world are looking for such gems, but I don't see LISP picking up momentum
(I did notice Erlang picking up momentum upto the point people feeling crappy
about syntax invented Elixir).

~~~
incepted
> If LISP is such an EPIC language why are there no major pushes from LISP
> community,

The main reason is that the LISP community is just not paying attention to the
modern world.

Back in its days, LISP was revolutionary and ahead of its time. It gathered a
bunch of followers who could reasonably be justified in thinking their
language of choice had something unique about it.

And then, they made a major mistake: they stopped paying attention.

The tech world moved on and passed them. And they ignored it, confident that
nothing new or interesting could ever be invented after Lisp.

It's the ultimate hubris: thinking that programming language science can ever
reach an end.

~~~
TeMPOraL
> _And then, they made a major mistake: they stopped paying attention._

Nah, the funding just dried up after Cold War ended and symbolic-based AI
turned out to be a failure.

> _Back in its days, LISP was revolutionary and ahead of its time. It gathered
> a bunch of followers who could reasonably be justified in thinking their
> language of choice had something unique about it._

Those "bunch of followers" actually invented half of the programming you use
today, and also there were _quite_ a lot of them during the Cold War. The
history of computing is not like what C/Java books would like you to believe.

> _The tech world moved on and passed them. And they ignored it, confident
> that nothing new or interesting could ever be invented after Lisp._

Maybe a bit, but for a good reason too. The tech world made a huge step
backwards with introduction of Unix and C, and we're only slowly recovering
and beginning to pay attention to the things people did before.

> _It 's the ultimate hubris: thinking that programming language science can
> ever reach an end._

I agree. But it's also hubris to believe it can not take steps in the wrong
direction and enter blind alleys.

~~~
pjmlp
> The tech world made a huge step backwards with introduction of Unix and C,
> and we're only slowly recovering and beginning to pay attention to the
> things people did before.

When I discovered UNIX via Xenix, I already had ZX Spectrum (48K, 128+2A,
128+3), SAM Coupé, Amiga 500, Windows 3.x experience, so the world of UNIX OS
architecture seemed quite interesting.

When I got to learn C, that experience already had showed me there were other
means to make use of all computer capabilities.

So the time spent on UNIX land, meant I was initially one of those renegades
trying to use C++ instead of C like everyone else.

Eventually the introduction to Smaltalk and Native Oberon spiked my interest
to delve into their history, as I was specializing in compiler design.

That showed me a world much more interesting that what AT&T has ever produced.

A saner mentality regarding what computer safety and developer productivity
should actually be like, but sadly failed in the market, because UNIX was
initially available for free.

I would dare to say that the OS architectures and development stacks from
Apple, Google and Microsoft are much closer to those ideas than whatever
exists in the pure UNIX world.

------
jfoutz
(2007)

lisp (imho) pushed the limits of what it was possible for a language to do. It
pushed in many directions. eval, macros, gc, the comments suggest many things.
As computers got faster, it became worthwhile to incorporate more and more of
those expensive ideas. Heck, go is billed as a systems language and it's
GC'ed! That would be crazy 20 years ago. Perhaps still a little crazy today,
but far more feasible.

Lisp is like the Simpsons. Lisp did it. (maybe not first, but lisp did it) Of
course later languages are going to pull some of that wonderful functionality.
Other stuff, like reader macros gets left behind. it's even possible to do
pretty explicit typing in lisp, but it never felt as natural as an
ML/Miranda/Haskell kind of typing.

The C# observation is amusing, the original garbage collector was written in
lisp. [1]

[1]
[https://blogs.msdn.microsoft.com/patrick_dussud/2006/11/21/h...](https://blogs.msdn.microsoft.com/patrick_dussud/2006/11/21/how-
it-all-startedaka-the-birth-of-the-clr/)

~~~
spriggan3
> go is billed as a systems language

When people say "system" they mean "back end" servers and tools. They don't
mean kernel programming.

~~~
nilved
Not true. Ruby is not a systems language. I would say a systems language is
characterized by static compilation, static typing and fast performance with
low latency. Of course, someone will quickly suggest a counterexample like
this comment.

~~~
olalonde
I've most often seen "systems software" used to designate software whose
primary users are other programmers or systems as opposed to end users (e.g.
databases, message queues, monitoring tools, etc.).

Ruby is typically used for writing business web applications and while those
applications run on the back end, their primary users are business/end users.

Of course, there doesn't seem to be a clear consensus on how those terms are
used and the line is often blurry between the categories.

------
ryanackley
I only programmed in LISP for a semester of grad school for an AI class. My
impression: it's a programming language with a unique perspective. Did I find
it to be the programming language of the gods? No.

Sometimes I find myself with a problem where I find myself wishing I was
programming in LISP. Does this happen every day, every week, every month? No.
More like once every couple of years.

------
todd8
Okay, well "What about homoiconicity?" you say? Well, I think it's a totally
cool sounding word that all hipster programmers need to have ready to pull
out, but it isn't a game changer for Lisp. Or I should say, that yes it has
kept Lisp in the game, because without it Lisp would be like FORTRAN IV, a
language that didn't have enough useful stuff (fixed size arrays of numbers
was pretty much all there was to program with in early FORTRAN), but it
doesn't make Lisp "better" than more modern languages.

Homoiconicity means that the the abstract syntax of the language can be
represented easily in the programming language itself. Just the fact that
Python is written in text and can easily represent and manipulate text doesn't
count. Because of homoiconicity Lisp can do amazing things to itself, see [1]
and [2]. Python programs aren't commonly producing another python program to
feed to the python interpreter.

However, Python makes the the AST available as a python construct. Go does
something similar. So yes, python and go could support the Metaobject protocol
if they wanted to. The important thing observation is that Python and Go
programmers don't want to and don't need to. These languages already provide
powerful enough abstractions to support 99% of a programmer's needs: object,
classes, interfaces, lambdas and so forth.

"Well, yeah, but ithout homoiconicity how do you construct a good DSL?" I
presume that you mean how can you implement something like CLOS? Really? I
don't want to implement CLOS and I also don't want to write the Boost library
for C++. Both are complex exercises in programming to extend the capabilities
of the underlying language. Why wallow in macros (again see [2]) or templates
(see Boost source)? I understand that C++ templates solve an essential problem
that the language has: original compatibility with C and a desire to be able
to operate as close to the metal as C. Likewise, Lisp originally lacked even a
decent set of control constructs. High powered macros (and call/cc for Scheme)
allowed the languages to build there own extensions just as templates have for
C++.

Other language just start with a good set of abstractions, control
abstractions (like Java's enhanced for loop), data abstractions like
interfaces, concurrency abstractions like go's channels.

"Yeah, well like man, how can you anticipate exactly what the program needs?".
Well, I've found higher level programming with functional languages and object
oriented languages to provide almost all my needs.

"Well, DSLs make programming so obvious. You end up programming so much closer
to the problem domain?" Yes, that's true. I find that DSL's and even macros
helpful in configuration files, for example in a 3000 line Emacs configuration
file. I use John Wiggle's use-package macro extensively to simplify my Emacs
init.el file. My problems with macros as a fundamental organizational
abstraction for programming-in-the-large are worth a separate post (it has to
do with hidden semantics and the difficulty in even informally reasoning about
the correctness of programs written using macros).

[1]
[https://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Prot...](https://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Protocol)

[2] [http://letoverlambda.com](http://letoverlambda.com)

------
preordained
I know Haskell pretty well, having spent a cozy two or three years with it as
my main squeeze for hobbyist programming. Now I'm doing more Prolog. I like
stuff that makes me think differently. Anyhow...is there something I'm missing
from Lisp? I've never Lisp'd, but people talk like it turns you into Neo in
the matrix.

~~~
ACow_Adonis
The "Neo in the matrix" thing, i think, is the "lisp enlightenment experience"
under another name.

Trying not to be some smug lisp weenie about it, I'm going to try to put my
own experience into normal english. It happened for me somewhere around the
6-12 month mark of daily lisp study/coding.

You usually start out learning lisp like other languages: you're just trying
to learn the syntax of various commands and the quirks of how everything fits
together of the concepts (if you've learnt another language) that you probably
already know. And a big part of this is laying the foundation of a deep
understanding of linked lists, cons cells, cars and cdrs. And after that, you
start learning about the identation style available to you as well. And right
now, its just another language.

Then one day, you wake up, and you look at code, and some switch you weren't
even aware of has flicked in your brain, and it all looks different. Mature
lispers read/structure code subconsciously using both symbols and the
indentation style to convey real information about the structure of a program,
which is why you can really mess with their heads if you mess yours up too
much. But there's a difference between being told you can do it this way, and
the practice that actually makes you do it, because its not a conscious thing.

Anyway, the reason lispers "think they're neo in the matrix" is because the
mental effect this has on you is not unlike that scene towards the end of the
matrix where Neo looks down the hallway and his perception of the thing he's
been interacting with this entire time just fundamentally changes. Its no
longer writing code, that is to say, strings of text. Its interacting with and
perceiving the very structure of the programs themselves.

And it is a real psychological phenomenon. It makes you really happy, and its
why lispers talk about it. It makes you want to go and shake your neighbour
and be all like "Oh my god, I get it, do you see this!"...and of course they
don't. They see scribbles on the screen.

The funny thing is, they always say they're Neo in the matrix, which i
understand is cooler, partly because that final scene captures the phenomenon
of what it feels like, but its arguably summed up in a more lackadaisical way
by the character Cypher in one of his quotes from the same movie:

"You get used to it, though. Your brain does the translating. I don't even see
the code. All I see is blonde, brunette, redhead. Hey uh, you want a drink?"

~~~
MichaelGG
But what are the practical implications? What things can lisps do that nothing
else can? Macros seem to be the biggest thing mentioned; pg says that was what
let him write features so much faster than competitors. On the next hand he
says he can't imagine not having different types of items in a list.

And like Cypher, if you reach some higher enlightenment, then can't use it
(practical constraints) it just makes you want to go back. E.g. a friend that
recently picked up F# now laments so much about having to work in C#; it's now
painful. Whereas a couple months ago, C# was pretty nice.

1: Though I'd like to see which features really made much of a difference.

~~~
calibraxis
One is possibly absorbing other paradigms, like you can do language design
too, even if you're "just" a user. Take Clojure for recent examples:
core.logic, core.async (which gives you Go-like channels). These are
distributed as libraries.

For many non-Lisp languages, something so small as a new "for" loop often
requires you to wait for language implementors. In Lisp, you want pattern
matching? Or some Erlang-like semantics? [1] Maybe it's possible! In an
accessible way, because you can customize your language's user interface. You
are not just a consumer.

[1] [http://blog.paralleluniverse.co/2013/05/02/quasar-
pulsar/](http://blog.paralleluniverse.co/2013/05/02/quasar-pulsar/)

------
jdmichal
See also the Lisp Curse:

[http://www.winestockwebdesign.com/Essays/Lisp_Curse.html](http://www.winestockwebdesign.com/Essays/Lisp_Curse.html)

[https://news.ycombinator.com/item?id=11174946](https://news.ycombinator.com/item?id=11174946)

------
hacker_9
It doesn't matter what you say about Lisp, there will always be people on HN
who vigorously defend it to their last dying breathe it seems. The idea of a
language not being (one(definition(after(another)))) seems foreign to these
people, as if making everything a function call solves all problems (or maybe,
that is what the HN crowd really believe?).

If only programming problems could be solved by lots of functions calls!! The
truth is the difficulty exists in the solving of problems, not how many
functions you define. If someone thinks you re-invented Lisp at some point,
then either they do not understand the problem or they fail to understand the
solution.. or of course; they do not care what you have written and instead
think you have not used enough parenthesis.

~~~
NotRustAgain
There are several things you could take away from Lisp. I don't think you
caught the good parts yet though.

My idiot instructor for comparative programming languages set me back years in
understanding the cool parts of Lisp. He focused on "List Processing", which
seemed pointless to me because lots of languages have lists... (I work with
him now, so I'm allowed to call him an idiot)

You seem to think it's about the function calls. Maybe you had a bad
instructor too, and he focused on "functional programming", which is all the
rage for the last decade. I dunno, maybe you came to that conclusion on your
own.

The thing I now think is wonderful about Lisp (Scheme for me), is that you can
write your program however you want. If you want to use switch statements, and
your language doesn't have one (Python), just make your own:

    
    
        (switch foo
            (case bar -> (do whatever you want))
            (case hmm -> (do something else)))
    

Some languages have backtracking:

    
    
        (backtrack
            (keep trying)
            (different things)
            (until it works))
    

You just can't add those kinds of features to most languages because most
languages are not programmable...

------
awt
I implore everyone here to read Naggum:
[http://xach.com/naggum/articles/](http://xach.com/naggum/articles/)

Also read Stanislav Datskovskiy:
[http://xach.com/naggum/articles/](http://xach.com/naggum/articles/)

Also consider that the x86 hardware platform is terminally busted. For god's
sake why isn't gc in hardware already?

------
todd8
The "Lisp" programming language covers a large territory, and often one needs
to embed some sort of interpreter or language is a complex system. (Even our
text editors contain sophisticated interpreters because we desire to customize
them to such an extent.) Furthermore, a Lisp model is one of the simplest ways
to build a powerful interpreter.

Consider the problem of being locked in a room that has a computer and all the
manuals you need to program it...in machine language. How would you build a
system of any significance? Could you escape the evil genie that won't release
you until you write a program that solves Sudoku puzzles?

I know that I would escape the genie. I'd build a simple macro system and key
it into the machine in binary (I've had to patch a machine's boot loader more
than once from a panel of switches). Then I'd build a simple assembler from
the macro system. After that, I'd build a simple lisp-like system because
that's about the simplest language one can implement that does anything
interesting, including writing a sudoku solver.

So yes, I'd be reinventing Lisp. However, I don't want to spend my life
programming in some shitty pathetic system I wrote to escape from an evil
genie. Why does it matter that Lisp is so easy to implement that undergrads
often build Lisp systems as programming assignments? That doesn't make it some
language of the future invented in the past; it just a simple to implement
language invented in the past.

A thread I've seen here before is "well Algol 68 was a great language and we
are not using it because ...<insert some conspiratorial reason>..." Well,
Algol 68 _is_ a great language from the past, but it's great not because it's
a great language to program in--it's great because it manifested some of the
earliest thinking about what features ought to drive the design of programming
languages.

Today, people aren't locked up and given terrible programming assignments with
no real programming language to use (well...maybe I should say this doesn't
happen all that often). So why not just embed Lua. Places that I would have
used Lisp 40 years ago are now the places I'd use Python or Ruby.

But what about the meta-object protocol? What about programs that need to
write other programs? What about DSL's? Well, that's another subject. But the
short answer is so what? These step up the power of the language one programs
in, but not essentially the limits to what a program in your language is
capable of doing. Yes, writing complex data structures in old FORTRAN is a big
pain, but we aren't in that arena anymore. Writing complex data structures in
C++ or Java or Go or Rust isn't a big pain anymore.

------
zaro
My feeling when using lisp is I am writing an AST . And since most languages
rely on generating AST it kind of makes sense to reinvent it.

------
dkarapetyan
One of the comments nails it on the head (paraphrasing a little bit): lisp is
the executable implementation of lambda calculus. So of course you will re-
invent it. As much as any domain at some point takes on a computational flavor
the closer it gets to having primitives that can be used to build a turing
machine the closer it gets to being a lisp. That and having your computation
being representable as a data structure comes in handy pretty frequently so
you end up emulating lisp even if you didn't intend to because the
data/computation duality is ever-present. None of this is an endorsement of
lisp though since there is a very deep and fundamental reason that it keeps
being re-invented. Lisp is the manifestation of the primordial soup of
computation.

------
tempodox
Reminds me of Greenspun's Tenth Rule Of Programming:

 _Any sufficiently complicated C or Fortran program contains an ad-hoc,
informally-specified, bug-ridden, slow implementation of half of CommonLisp._

~~~
mamon
Reverse is also true: Any sufficiently complicated Lisp program will contain
an ad-hoc, bug-ridden and slow implementation of half of mainstream
programming languages and their standard libraries.

------
lucidguppy
I think lisp adds mental overhead for figuring out the precedence of
operations - while other languages have a default that people understand.

Perhaps if a lisp editor was 3d instead of just parenthetically topographic
(not just color coded) it may help people understand what is happening.

~~~
ldjb
It's perhaps a little confusing when first learning Lisp, but once you've got
the hang of things, working out the precedence of operations is really easy.

In most programming languages with infix operators, the precedence often
depends on the operators themselves. For example, with:

    
    
      5 + 3 * 10
    

...You'd need to know that * has higher precedence than + to figure out the
value of this expression is 35, not 80.

But with the following Lisp expression:

    
    
      (+ 5 (* 3 10))
    

...The syntax itself tells you the precedence, so there's no ambiguity. Even
if you didn't know anything about the functions involved:

    
    
      (bar 5 (foo 3 10))
    

...You don't need to worry about whether foo has precedence over bar or the
other way round -- there's only one way to evaulate the expression.

------
KayEss
And the rest of us are doomed to keep re-implementing it.

------
wrong_variable
\-- This is prolly the most arrogant opinion I have --

I think if every programmer started using LISP we would have a massive
unemployment crisis - since many software engineers would lose their jobs - as
most are forced ( due to the nature of capitalism ) to sell snake-oil
solutions to problems already solved 50-60 years ago.

\--

I am not a Lisp programmer , so no accusation on smugness pls. I just ended up
using Lisp concepts daily when programming terrible languages since that is
what the market wants :) # Resume Driven Development

~~~
ZenoArrow
Lisp has some good traits, but it isn't the 'ultimate' language. There are a
number of issues with Lisp, for example I've heard debugging Lisp macros can
be quite hard, I'd also say optional types is a weakness. Even Sussman, one of
the creators of Scheme, classes Haskell as the best programming language we
currently have, or in his words "the most advanced of the primitive
languages.".

[http://limist.com/coding/talk-notes-we-really-dont-know-
how-...](http://limist.com/coding/talk-notes-we-really-dont-know-how-to-
compute-gerald-sussman-2011.html)

That's not to say Lisp doesn't have merit, because it does, it's easy to pick
up, very flexible, and in the right hands can lead to impressive results, but
we've still got plenty of work to do to improve the state of the art.

~~~
madmax96
I disagree with your assessment, and I guess with Sussman's appraisal as well.

I believe that you are mistaken in your belief that Lisp isn't the most
advanced language. The submitted thread contains many comments that state that
Lisp is basically a pure implementation of the untyped lambda calculus. I
don't think this is correct -- Lisp is itself a unique model of computing, and
it generally unifies Turing's and Church's computational model in a relatively
unbiased manner IMO. For that reason, I regard Lisp as the most flexible
languages of all "multi-paradigmed" languages. The Lisp machine's software was
basically exclusively implemented in Lisp; the fact that developers could
comfortably accomplish that testifies to Lisp's flexibility.

In Lisp, entire linguistic constructs can be dynamically created to
iteratively solve a problem. That's basically a bunch of buzzwords, but I
think the statement holds significance. I've read comments elsewhere regarding
Lisp as the "Maxwell's equations" of PLT. I agree with that. If you're not
familiar with the meta-circular evaluator, I encourage you to read up on it,
as it justifies this statement.

That being said, Haskell's type system is really fantastic. I'd love an
implementation of a Lisp with a Hindley Milner-esque type system.

Basically, I think Lisp is the most advanced language because it captures what
a language is perfectly. This makes it free to involve and embrace new ideas,
and has contributed to its continual success and long life.

~~~
jpt4
> I'd love an implementation of a Lisp with a Hindley Milner-esque type
> system.

I am not certain of whether it is more Hindley-Milner or more "esque", but you
may find something of interest in Shen [0].

[0] [http://shenlanguage.org/](http://shenlanguage.org/)

Edit: I submitted this reply an hour or so after opening the tab, during which
interval several others mentioned Shen (which is good, as it deserves a bit of
exposure).

~~~
emidln
Shen (in particular its type system) is an executable Sequent Calculus system
[0] written with a small portable lisp. This derives from a propositional
logic system, not H-M over typed lambda calculus.

[0] - [http://www.shenlanguage.org/learn-
shen/types/types_sequent_c...](http://www.shenlanguage.org/learn-
shen/types/types_sequent_calculus.html)

~~~
jpt4
Thank you for clarifying. Can you comment on the relative expressive power of
Shen's type system versus e.g. Haskell? I understand that the former can
accept as well-typed terms the other can't; in what way is this a consequence
of modeling Shen's type system using the Sequent Calculus versus Hindley-
Milner deduction?

------
hasenj
There's one thing severely lacking in lisp: compile time type checking!

IMO Haskell has the best typing system I've seen in a language so far.

TypeScript is probably a close second (it kinda has to be as flexible and
powerful as possible, to accommodate as much existing javascript code as
possible).

~~~
Jach
Common Lisp supports compile time type checking:
[https://news.ycombinator.com/item?id=11529039](https://news.ycombinator.com/item?id=11529039)

Have you seen Shen? [http://shenlanguage.org/](http://shenlanguage.org/)

------
dschiptsov
Everything has been said by Richard Gabriel long ago - Lisp is too good, and
"packers" don't need or even appreciate refinement and excellence, like most
of folks don't appreciate beauty of DNA and related machinery.

For them PHP or Java are tools for getting shit done. There are huge piles
they have produced, like Hadoop or whatever it is.

The last great Lisp was ZetaLisp from Symbolics (just read the docs!). Common
Lisp is already a bloatware suffered from the kitchen sink syndrome,
nevertheless it is way better than anything else (multi-paradigm, mostly
functional, strongly-typed (type-safe enough) meta-language that compiles to
native code with pattern-matching, OO and other fancies as DSLs).

But who cares if one is satisfied with writing

    
    
       RepetitiveStupidityFactory myStupidityFactory = new RepetiriveStupidityFactory;
    

for living.

~~~
incepted
> RepetitiveStupidityFactory myStupidityFactory = new
> RepetiriveStupidityFactory;

Yeah because

    
    
        (let v (make-instance 'RepetitiveStupidFactory))
    

is so obviously superior, right?

~~~
dschiptsov
Obviously. Less repetitive, less verbose. And, most importantly, one could
hide all the irrelevant details inside a macro which is equivalent to
extending a language with a new control structure.

~~~
incepted
The Lisp version is less verbose because it's dynamically typed (in other
words, it's less verbose because it contains less information that would allow
this code to be proven correct).

By the way, these days, we write things like

    
    
        val l = ArrayList<String>()
    

If verbosity is your number one criterion to write your code, just skip all
error checking and your code will become super concise.

------
MrBra
Cut me some slack!

