
This Old Lisp - lispm
http://thisoldlisp.com/talks/els-2018/
======
ilovecaching
God, Lisp is beautiful. You look at some of the older languages of yore and
think, my god, how did people survive? Then you see a Lisp program in all it's
homoiconic glory, and it looks just as good in 2018 as it did in the 1960s.

A true testament to the expressiveness and generality of expression based
programming and the lambda calculus.

~~~
gnulinux
This 1960 program is much better looking than pretty much all 2018 programs I
saw. There definitely are some exceptions, but it's _hard_ to get lisp wrong
whereas it's too damn easy to get most 2018 languages wrong.

~~~
jorams
> it's hard to get lisp wrong

That's not actually true, Lisp offers endless possibilities to work yourself
into a hole. The average 1960s program was just written by someone a bit more
knowledgeable and caring, who took a lot more time to get things right, than
the vast majority of modern programming work.

~~~
sevensor
And the average 1960s program was written on a blackboard first. Computer time
was expensive! I think being forced to confront the cost of the program ahead
of time sharpened programmers' wits.

~~~
pfdietz
My first Lisp program was entered via punch cards. This was the early 1970s.

------
znpy
I know I am going to write an unpopular opinion and get downvoted for it, but
here it goes...

I am still not convinced by the general "we don't need to upgrade the Common
Lisp specification" attitude.

It surely is remarkable as a specification, encompassing so many aspects of
the language, yet it leaves so many other aspects to the particular
implementation. Multi-threading for example is supported by most major
implementations yet their syntax (and often, semantics) are very different
from each other. Same goes for cooperative multitasking (corutines etc).
Someone else could come up with other examples.

In my opinion a new committee should be formed, to standardize the syntax and
semantics of these so common functionalities.

In this sense, the various C++ language working groups are doing a remarkable
job. I wish something similar would happen in the Common Lisp world.

~~~
blue1
a large part of the CL community treats the spec a bit like a sacred text, in
the sense that it is both very good and impossible to change. The most
important reason apparently is that there are no more the resources to do it.
Maybe also the struggling commercial vendors do not want to standardize their
offer to become too similar to open source implementations?

~~~
junke
> a large part of the CL community treats the spec a bit like a sacred text

That's not my experience. I'd say that people know what the CL spec currently
is, love its stability, and might fear what it could become after an
"upgrade".

Anybody can write something like CL21, for example, with one's own style and
notations. That's why it is frowned upon to do so and to claim that "this"
library is how "the" new Lisp should be. Part of growing in Lisp (and
programming) is to learn how to work with a language, not against it, and
avoid fixing what is not broken.

However, I trust Common Lisp compiler developers and vendors to know how to
make backward-compatible, useful changes: current common lisp environments
have way more facilities and building blocks than the bare minimum required.
They also know the pain points that currently exist in the standard in a way
that goes beyond aesthetic things.

~~~
blue1
It seems to me that this is a case of making a virtue of necessity: since the
language does not evolve, many have learned to love the fact that it does not.
To me it looks a lot like a form of Stockholm Syndrome.

I find interesting your remark that "anybody can write something like CL21".
(Though, not _all_ problems can be solved with a library, but let's stick to
this side). In most language, you can't do this kind of customization. In Lisp
you can, but anyone else can too, and the result is that after 25 years there
is still no standard way to write a hash literal, for example, or to
concatenate strings in a non-verbose way. It is difficult to claim that these
are good things.

~~~
Jach
It's a curious situation for sure. QBasic shares the property that you can run
decades old code unmodified, but we don't celebrate that language. I think a
certain amount of resistance to updating it must also come from looking at
other languages that have no spec whatsoever (not even an old one) and are
doing or have done just fine. Then you look at the various problems that would
be addressed by an ANSI update, and see that so many of them _are_ resolved
with libraries that work across implementations, some bundled OOTB with
implementations, and easy to get via quicklisp if not. And as you bring up,
though there's not a standard for hash literals, which aesthetically sucks,
you still have a gorillion choices you can import including writing your own
in a few lines to fit your aesthetics if you can't stand the alists. Lisp is
powerful enough to support such flexible choices without a headache.

A serious effort would probably benefit from talking to the C++ people. Since
my knowledge of C++ is basically stuck at C++98 + a few Boost utils, my
outside perspective is that C++0x and eventually C++11-C++17 were just
standardizing what were already halfway de-facto standards in Boost (halfway
because you could get a _lot_ of questionable looks for including Boost from
some parts of the community, and the limitations of C++ meant some things
didn't look or debug as nice as if there were compiler support). Still, with
the standard the syntax has grown quite a bit and some of it can be more
pleasing than the Boost macros. Did it break anyone? Probably, but at least
compilers let them compile with old standards. It'd be a good conversation
with C++ committee people especially to see what it took to finally update
such an old spec. A CL update would surely need a similar feature of running
under the old spec, since e.g. if you're adding literal hash table support
you're almost surely going to break someone who was using that syntax choice
for something else.

------
lerax
Nice transcript. I would love if more often people did it.

------
cblum
That moment when you happen to know the person linked, but in a totally
unrelated context (our kids are friends).

Now I've gotta find some time to watch or read this :)

------
moron4hire
I've never done work with CL, but I've done quite a bit of Racket. What does
CL offer that Racket doesn't? I've found Racket to be fairly complete, and the
areas where it's not are usually quite simple to fill in (thus seem pretty
clearly intentionally left open-ended).

~~~
peatmoss
As a Racket dabbler, I’d say there are a couple things:

\- performant implementations (SBCL in particular is a standout). I mean,
Racket’s pretty good, and will typically blow the doors off Python, but SBCL
is in a different league.

\- multiple implementations conforming more or less to a standard. This can
also be a distraction, but is on balance a nice thing to have, particularly if
you wanted, for example, an implementation that ran on the JVM (ABCL).

\- different set of libraries. Racket’s library situation is pretty good, but
sometimes CL will have something that Racket doesn’t (and sometimes the other
way around)

~~~
sigzero
Racket should be becoming more performant once the Chez integration is done.

~~~
dleslie
I wouldn't hold your breath; Racket isn't that much slower than Chez, and both
are slower than sbcl.

[https://ecraven.github.io/r7rs-benchmarks/](https://ecraven.github.io/r7rs-
benchmarks/)

[https://benchmarksgame-
team.pages.debian.net/benchmarksgame/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/which-programs-are-fast.html)

------
hguhghuff
One of the things that really put me off Lua was lack of a strong central
control and organization for the language, resulting in fragmentation.

How does lisp stand in this regard?

~~~
jorams
It's interesting that you say that about Lua, because it actually _does_ have
a strong central control and organization for the language itself. The
"problem" is that it doesn't go further than the language, large parts of the
community disagree with their choices, and they tend to not care about
backwards compatibility too much.

Lisp is very different in that area. I think that is because the language
standard is large and doesn't change. As long as people want to conform to
that standard, splitting up too much doesn't really make sense.

------
shntx
Awesome. Two-Bit History's latest essay is also a fascinating dive into Lisp.

[https://twobithistory.org/2018/10/14/lisp.html](https://twobithistory.org/2018/10/14/lisp.html)

------
winter_blue
After 20 years of programming[1], I’ve gotten to a point in my life where an
advanced type system (with strong _static_ types, no nulls — optionals
instead, type inference, type refinement, etc) is absolutely mandatory for any
language I’ll pick (when I have the freedom to choose). I’ve heard that there
are libraries that tack types onto LISP — but how good are they?

LISP code I’ve seen anywhere has always been without types (ie dynamically
typed). No LISP dialect that I’m aware of has prioritized or talked about or
emphasized type checking. Is this something that’s even big on the radar of
the LISP implementors and the LISP community at large?

I’ve been burned too many times working on large (100k+ LOC) dynamically typed
codebases that I really never want to work with such a codebase again.

A sincere question: Besides its homoiconic syntax and probably the best
implementation of macros — what does LISP offer over a modern programming
language with a sophisticated type system – even, for instance, a language as
old as OCaml?

Peter Norvig has web page called “ _Is Lisp Still Unique? Or at Least
Different?_ ” that was last updated _back in 2002_ where he talks about the
unique features LISP offers, and how other languages are catching up:
[http://norvig.com/Lisp-retro.html](http://norvig.com/Lisp-retro.html) Modern
languages of today offer the features that made LISP unique and superior _in
its heyday_ , and languages with powerful type systems offer a huge advantage
that LISP never has had.

[1] I started programming in 1998, when I was 8 years old. I’ve developed
software professionally for a far shorter period.

~~~
VogonWorkEthic
I've heard racket is the way to go with types in lisp.

[https://racket-lang.org/](https://racket-lang.org/)

Just passing along what I heard though, I personally don't use types and think
things like clojure spec do a much better job fitting the bill.

~~~
peatmoss
I think some are bristling that Racket is _the_ way to go, but Typed Racket is
certainly _a_ good way to go. [https://docs.racket-lang.org/ts-
guide/](https://docs.racket-lang.org/ts-guide/)

You can start without types and later convert parts of your code to typed
without too much headache.

But, as the GP has mentioned, SBCL allows you to add type annotations which is
similar in spirit to the idea of progressively adding types.

Even as a Racket fan (and Racket’s performance is pretty good), I covet the
blazing performance of SBCL, so the calculus is not cut and dry.

~~~
sevensor
Interesting stuff is happening performance-wise. I have my eye on both Racket-
on-Chez and pycket.

~~~
peatmoss
Racket-on-Chez may eventually result in a better performing Racket, but SBCL
is still going to be a hard target to match.

That said, Racket on Chez means more of Racket is getting written in Racket.
In turn, I suppose Racket-on-SBCL is not outside the realm of possibility. In
general, it would be cool if Racket ran in more places.

------
jacquesm
If the author is reading this: typo in the first sentence, the year reads
'2108' right now.

~~~
lkuty
It's due to the fact that Lisp is ahead of its time :-)

