
What Made Lisp Different (2002) - montrose
http://www.paulgraham.com/diff.html
======
cbrozefsky
I've done two successful startups with lisp variants in my career, and
continue to do clojure development at Cisco. The advantages of using lisps are
real, if you stay focused on the problem domain and stay close to the customer
-- you have great agility and flexibility. Woe to those who are tool jockeys
and get too infatuated with their tools and code base, because there is a lot
of rope to hang yourself and your teammates with.

The first was a Common Lisp web app for resource management, that was recently
sold. Not a giant payout, but over it's entire life, starting in 2000, it paid
peoples mortgages and put kids thru schools.

The second was a clojure based malware analysis engine, which we sold to Cisco
about 3.5 years ago. That was a more conventional startup exit. We have scaled
that into a global product. Additionally, we are developing even more clojure
products within Cisco, and hiring...

I know from hiring clojure devs for the last 6 years that there are alot of
companies, big and small, using it.

~~~
malloryerik
"Woe to those who are tool jockeys and get too infatuated with their tools and
code base, because there is a lot of rope to hang yourself and your teammates
with."

Could you expand a bit on this? I'm not entirely sure what you mean, but sense
some good advice.

~~~
kornish
Not the grandparent poster, but stepping in.

Lisp, due to its easy metaprogramming, gives abstraction enthusiasts rather
more rope to hang themselves than languages which make abstraction
inconvenient (e.g. Go, which has a simple type system, or Java, which is very
verbose). So, if one isn't careful, it's possible to write a very clean, very
nice Lisp DSL which is totally incomprehensible to anybody but the author, and
thus hell to maintain over time.

Relevant quote, from [https://www.joelonsoftware.com/2000/07/22/microsoft-
goes-bon...](https://www.joelonsoftware.com/2000/07/22/microsoft-goes-
bonkers/) –

> When great thinkers think about problems, they start to see patterns. They
> look at the problem of people sending each other word-processor files, and
> then they look at the problem of people sending each other spreadsheets, and
> they realize that there's a general pattern: sending files. That's one level
> of abstraction already. Then they go up one more level: people send files,
> but web browsers also "send" requests for web pages. Those are both sending
> operations, so our clever thinker invents a new, higher, broader abstraction
> called messaging, but now it's getting really vague and nobody really knows
> what they're talking about any more.

> And if you go too far up, abstraction-wise, you run out of oxygen. Sometimes
> smart thinkers just don't know when to stop, and they create these absurd,
> all-encompassing, high-level pictures of the universe that are all good and
> fine, but don't actually mean anything at all.

More here:
[http://wiki.c2.com/?TooMuchAbstraction](http://wiki.c2.com/?TooMuchAbstraction)

~~~
flavio81
> _So, if one isn 't careful, it's possible to write a very clean, very nice
> Lisp DSL which is totally incomprehensible to anybody but the author, and
> thus hell to maintain over time._

This is a myth. DSLs in Lisp are almost always done in Lisp syntax, no
surprises. The idea of having a higher abstraction is to make the problem
domain map more clearly to the code.

 _> totally incomprehensible to anybody but the author_

Now, what people who like to repeat this myth forget to say, is that when
using an OOP language, say, Java, and using another's person code, one also
needs to learn the classes that this person has created, the methods and how
they interact. And this can be "totally incomprehensible to anybody but the
author".

> _Relevant quote_

No, not relevant. Joel Spolsky is talking about device abstractions.

~~~
dustingetz
professional clojure programmer here, not a myth, DSLs often abstract _in the
wrong direction_ and by departing from a language of values and function
composition (eg by introducing macros) a bad dsl in fact becomes a barrier to
good abstraction. Consider any DSL for html generation that predates React.js;
react isn’t even a DSL at all, react is values and functions, so there’s all
this good innovation happening around React that was all dead ends on 100% of
pre-React DSLs.

~~~
flavio81
>and by departing from a language of values and function composition (eg by
introducing macros)

You are assuming that a DSL is done by using macros; which is incorrect; in
Lisp you can easily create your own DSL using plain functions as well.

~~~
kornish
Sounds like maybe we're talking past each other. Would you mind clarifying how
you're defining a DSL?

------
reikonomusha
Rigetti Quantum Computing is a relatively recent YC startup that happens to
use Common Lisp for building out their quantum programming language, compiler,
and simulator stack. For those tasks, it has been an excellent choice,
especially given the hugely exploratory and rapidly evolving space.

Rigetti hosted one of the Lisp meetups to talk about their use of Lisp and it
was recorded in a talk "Lisp at the Frontier of Computation" [0].

[0]
[https://www.youtube.com/watch?v=f9vRcSAneiw](https://www.youtube.com/watch?v=f9vRcSAneiw)

(Disclaimer: I'm the speaker in the video.)

~~~
jgalt212
Whether you a pro lisp, anti lisp or agnostic, I think most HNers will find
watching this talk time well spent.

I have no relationship with Lisp, YC, or Rigetti.

------
dimatura
I absolutely love lisp. It's crazy how it's one of the oldest language around,
yet it still has more features than many other newer mainstream languages.

At the same time, one of the reasons I don't like it too much for daily work,
is how it encourages cleverness. This sounds silly, I know. But sometimes when
there's opportunities for cleverness -- such as with C++ (meta) template
programming -- I become too tempted to make my own code more clever instead
of, you know, making it do whatever it's supposed to do. That makes me
appreciate the relative dumbness of say, Go and Python (not that you can't be
clever with Python, but it's not encouraged).

~~~
zabuni
My biggest issue as well. People seem to be drawn to creating a DSL for their
problem set, and then programming in that. I've thought of Go as the Anti
Lisp, in that there will be NONE OF THOSE SHENANIGANS LIKE THAT HERE. I think
that's why Go draws so much vehemence. It's the "No fun allowed" of computer
languages.

~~~
aerique
I recently had to use Go for the first time at work, while generally Common
Lisp is my go-to language.

I kinda liked it for a systems language. It has conveniences trickled down
from higher level languages[1] that are missing from C & C++ and which make
them such a chore to use

[1] for example: garbage collection and being able to print an object without
have to import vast libraries

~~~
DonaldFisk
These are things that Lisp programmers take for granted, but it's difficult to
convince most C/C++ programmers of the advantages of garbage collection, as if
they wanted it they wouldn't be using C/C++.

~~~
flavio81
>advantages of garbage collection, as if they wanted it they wouldn't be using
C/C++.

There are garbage collection libs for C++ and they are used by C++ programmers
whenever necessary.

------
nnq
Lisps are like tiling window managers... Some have a taste for them. Most,
don't.

Unfortunately some of the Lisp cool features are hard to implement without its
simple syntax. Maybe the lesson is that _we should find a f way to have
syntax-independent programming languages!_ Just as we expect any successful
language to have at least a couple implementations before being taken
seriously, maybe we should expect a language to have at least a couple
different alternative syntaxes and instant perfect translation between them
(with comments and code style preserved), so I can use syntaxA and work on
same codebase with my colleague using syntaxB. Than we'll be sure any
metaprogramming or code intelligence tools don't suck because they'll be _damn
forced_ to not use the program text but the AST (that will _have to_ be
standardized) as they should instead...

Lisps would not even seem so cool anymore if we could get our s together and
build languages with (a) standardized AST representations and (b) multiple
syntaxes... we've like already imported most lisp features into modern
languages anyway, and standardized ASTs would make macros both trivial and
manageable...

~~~
Buttons840
Imagine something like Go and APL compile down to the same AST, and imagine
two programmers working on the same project with different syntaxes as you
describe. The Go user one day finds a function called "life" that contains
several hundred lines of code, which is clearly bad style and should be broken
up, so he goes to talk to his APL using coworker who wrote the function. His
coworker seems confused, "it doesn't seem too long to me" he says as he shows
the APL function on his screen:

    
    
      life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}
    

I think what you proposed is a good idea, but it's just an idea. We'd need
some new innovation to make it work I think.

~~~
dang
Your thought experiment shows how hard it would be. If we could do that, we
could translate machine code into readable high-level programs.

To put it the other way around, it reveals something about how choice of
programming language affects not only how we write a program, but what we
write, and even how we think about the problem.

~~~
Buttons840
I thought about it some more and I think it would go the other way too. APL
has a lot of very terse array operations, but in Go you might find a mix of
loops and if-statements. Translating those arbitrary combinations of loops and
if-statements into APL might be very very ugly, or even impossible.

Consider assembly or basic, which use a lot of goto-statements. It can get
very ugly trying to fit some arbitrary goto's into the more structured loops
and if-statements we're accustomed to.

~~~
dang
Exactly. There's a kind of entropic arrow from higher-level to lower. Moreover
the different high-level languages occupy different places in that same space.
It isn't just that you can't easily translate between them. It's that they
lead to different classes of system being created in the first place.

~~~
fiddlerwoaroof
What should be possible, though, would be to distinguish a surface-syntax from
the underlying code: e.g. a language that can transparently convert to/from
c-style curly brace blocks, Pascal-style begin/end and s-expressions. possibly
implemented as a bunch of git hooks that transforms to a normalized
representation (as, e.g. prettier does for JS) on push and transforms to the
programmer's preferred representation on pull.

~~~
dang
I suspect you'd find that what look like surface differences actually go
deeper into the meanings of programs, like a plant whose roots go deeper than
one would expect.

~~~
le-mark
There's a special level of Hell that involves streaming xml processing and
cobol. Since cobol lacks dynamic memory allocation (speaking of cobol 85 here)
and you don't generally build things like linked lists or trees, there's a
limited number of things you can conveniently do with streaming xml data. Many
cobol programmers are left with a feeling of despair, I wager.

The Sapir-Whorf hypothesis is certainly real in programming languages[1].

[1] [http://wiki.c2.com/?BlubParadox](http://wiki.c2.com/?BlubParadox)

------
oblio
I’d take advantage of this opportunity to start a discussion about a somewhat
related article, the famed Blub article:

[http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html)

> The more of an IT flavor the job descriptions had, the less dangerous the
> company was. The safest kind were the ones that wanted Oracle experience.
> You never had to worry about those. You were also safe if they said they
> wanted C++ or Java developers. If they wanted Perl or Python programmers,
> that would be a bit frightening-- that's starting to sound like a company
> where the technical side, at least, is run by real hackers. If I had ever
> seen a job posting looking for Lisp hackers, I would have been really
> worried.

17 years later and I still don’t see all those Lisp startups :)

I’d argue that 8) will never happen because the gap between human parsing and
computer parsing is too big. Except for a minority of human compilers that
enjoy Lisp, most people don’t, so this notation will always be a niche for
mainstream programming.

~~~
coldtea
> _17 years later and I still don’t see all those Lisp startups :)_

Just survivorship bias from PG side (lots of Lisp based companies just gone
nowhere) and gross extrapolation of the sole example his one Lisp company as
some universal truth (and even for his company, it was more the idea, timing,
skills, execution and luck, than Lisp of course).

------
lisper
If you want a good (IMHO) example of how Lisp can be made to "meet the
problem" so to speak, take a look at this:

[http://www.flownet.com/ron/lisp/djbec.lisp](http://www.flownet.com/ron/lisp/djbec.lisp)

and take a look at the functions xpt-add and xpt-double. The details don't
really matter. What matters is that what is going on here is a whole bunch of
modular arithmetic. The details are described here:

[http://www.hyperelliptic.org/EFD/g1p/auto-twisted-
extended-1...](http://www.hyperelliptic.org/EFD/g1p/auto-twisted-
extended-1.html)

Notice how the Lisp code is virtually cut-and-pasted from that page, despite
the fact that it's not Lispy syntax, and the mathematical operators are NOT
traditional addition, multiplication, etc. These are operations on modular
integers and elliptic curve points. And yet the code looks just like the
source material from which it was derived.

To make all this magic happen required less than 500 LOC.

------
protomyth
As much as I like Lisp or Smalltalk, I cannot help but wonder if they are
really great in the large. Smalltalk has a pattern called Double Dispatch that
makes sense but seems to tightly couple the classes. I keep looking at, of all
things, the VBX market in the 90's and wonder why we don't have those type of
components with current languages. I think something based on agents that
create loosely coupled systems where it easier to expand and replace parts
would be a better place to look for a future programming language.

~~~
mark_l_watson
I wonder if there is a future for Pharo Smalltalk as a user interface and
coding environment that uses backend services written in other languages. Last
week I saw Python matplotlib bindings for Pharo and as I played with this, I
thought of interfaces to TensorFlow, ML services at AWS, GCP, and Azure, etc.
This idea probably does not make sense, but the idea hit me.

EDIT: like a replacement for Jupyter, but more capable.

~~~
scroot
Amber [1] is a Smalltalk that you use to develop in a Web Browser, but which
will compile for you to JS on the back end.

[1] [http://www.amber-lang.net/](http://www.amber-lang.net/)

------
Keyframe
There are two languages (families) I fell in love with that I can't use. Lisp
and variants (Scheme) and Ada. Joy to work with, joy to write in, yet...
whenever I try to write something more elaborate I hunt the web for libraries
or toolchain is lacking this and that. Meh. I still haven't given up, but in
the meantime I have come to terms that I am a C programmer and always will be.
I enjoy C as well (yeah). Next step would probably be to write core 'modules'
in C and glue (think in level above) that in Lisp or Ada. There's also this
thing I never quite understood, but it intrigues me, is that some people
apparently write Lisp which emits C out, or even assembly.

------
pasabagi
Reading the article, I'm a little bit curious - I've heard a lot that more
productive languages become less productive over a certain team size, since
productivity typically comes from a lesser degree of strictness. Does lisp
have similar problems?

~~~
rerx
Paul Graham's Viaweb was rewritten in C++ and Perl after the aquisition by
Yahoo. I can imagine that this was easier to deal with for a large team than
the original implementation in Lisp.

~~~
lispm
That's not unusual, historically some software had prototypes in Lisp. Some
managed to get into production. Some even proved very hard to replace.

But that was at a time when more people learned Lisp, there was less choice in
tools and the eco-systems were smaller. In the 70s/80s one could buy ten years
into the future with the right hardware/software and government/military was
financing.

Take for example the Connection Machine CM 1, an early massive-parallel
computer with 2^16 processors. It was initially developed largely for and with
Lisp. You could program it in *Lisp from a Lisp Machine - one of the most
expensive co-processors. Fortran and C was added then for certain commercial
users. Very expensive stuff and at least ten years ahead.

Today the landscape looks different.

~~~
copper_think
The garbage collector for Microsoft's Common Language Runtime (CLR -- the VM
for .NET) was written in Lisp originally and then transpiled into C.

~~~
erikj
Also, Apple's Interface Builder began its life as a Lisp program:
[http://vimeo.com/62618532](http://vimeo.com/62618532)

~~~
lispm
Postgres started as a Lisp program, and turned out to be too difficult to
develop in a mix of C and Lisp.

The Objectstore database was developed by former Lispers, who wrote an earlier
object-oriented database in Lisp.

------
didibus
As much as I like Lisp, I don't think your choice of language will make or
break your startup.

~~~
cobbzilla
sure, within reason. I wouldn't try to build a product in a language where the
available labor pool is tiny given the problem domain. For example, don't
build an enterprise SaaS platform in pure x86 assembly; don't write device
drivers in Delphi.

~~~
FeepingCreature
Eeeh. Having a small but not tiny labor pool can be beneficial in that the
programmers you get are probably better than average, since average people
don't tend to learn off-path languages.

~~~
cobbzilla
Rare skills tend towards the expensive, either in money or time-to-recruit, or
both. It can sometimes be worth it for specialist tasks, but I'd be cautious.

------
agumonkey
Lisp is everywhere these days. Look at destructuring, higher order functions
.. this is just the tip of the iceberg. These genes stood the test of time and
spread all over.

~~~
erikj
I'd rather use the whole thing rather than scattered bits here and there.

~~~
agumonkey
I think it's a "natural" thing. Contextually only ideas can be efficient, not
the whole, so islands (languages, companies) grab what they can in gradual
chunks.

------
gyrgtyn
do any of the lisps have a package system like npm with tiny, nano libraries?

~~~
Keyframe
Roswell for lisps themselves and quicklisp for 'libraries', and then there's
ASDF as well.

~~~
Annatar
ASDF appears to have been deprecated in favor of Quicklisp, or rather,
Quicklisp appears to be the next generation of ASDF, since I saw asdf
functions inside of Quicklisp.

~~~
kbp
> ASDF appears to have been deprecated in favor of Quicklisp

No, ASDF and Quicklisp do different things. ASDF handles compiling and loading
systems, whereas Quicklisp handles downloading systems and their dependencies.
ASDF is kind of like make, and Quicklisp is kind of like a package manager.

------
quadcore
I wonder if ITA software still use lisp.

------
alsadi
So if we go back in 1977 we should pick lisp instead of fortran because they
invited if statement first.

Since we are in 2018, I'll go with python

~~~
Annatar
You still want 1977 tech, because those guys all had one or more PhD’s in
subject matter required to build not just the software, but the hardware to
run it as well. As a result of that, the software they designed is still very
high tech if unorthodox, even by today’s standards. Modern Lisp is like using
a faster than light spaceship with a gravitational distorter (moves by falling
into the projected distortion), compared to getting from point A to point B in
a gasoline automatic car which is leaking oil (Python); If you run into some
‘70’s and ‘60’s tech, take the time to master it so that you could build
antigravitational devices all day long (XKCD Python import.antigravity joke
notwithstanding). Lisp is still cutting edge technology, and it’s from the
‘60’s and the ‘80’s by the way.

------
olskool
LISP - Lots of Irritating Silly Parenthesis

~~~
Annatar
Only if f(x) makes no sense to you in mathematics.

