
Lisp Comes of Age (1980) - lproven
https://microship.com/lisp-comes-of-age/
======
dreamcompiler
There's a Star Trek TOS episode "Errand of Mercy" where the simple primitive
inhabitants of Organia are caught in the middle of a war between the
Federation and the Klingons. Kirk is baffled because the Organians refuse his
help to defend them against the Klingons. Finally when the Organians have had
enough they simply make all the guns disappear, revealing themselves to be a
much more advanced species than either of the fighting races.

Lisp reminds me of the Organians. It seems simple and kind of boring until you
try something you know is impossible and it just works. It spoils you for
other languages.

~~~
DannyB2
Impossible might not be the right word. When I was much younger, I would
describe it as seeing things done easily in Lisp that I had no idea how to do
at all.

Lisp could easily express ideas that I didn't know how to express in other
languages. Just as Pascal had made it possible for me to express ideas that I
had no idea how to express in BASIC.

Lisp gave me new tools. Just as earlier Pascal had given me new tools.

The Organians told Kirk and the Klingons that they would one day be friends.
And rise to their level. Ironically, languages in the 90's and 2000's borrowed
more and more from Lisp. Starting with most languages of the last quarter
century having Garbage Collection.

------
slifin
Something they don't tell you when you start learning lisp is the sense of
calm it brings

It's such a elegant thing, it ruins me for doing "professional" programming

~~~
agumonkey
few other good languages have had that said about them:

ml

prolog

apl

forth

they all 'ruin' your life by showing you everything's wrong about daily
realities.

oh, and smalltalk

PS: if I missed some, tell me

~~~
pjmlp
If you want to see your life ruined, watch this deep dive into Mesa/Cedar
environment. :)

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

One of the first workstation OSes written in a memory safe systems programming
languages, early 80's at Xerox PARC.

~~~
TurboHaskal
Can we go back in time and kill UNIX?

~~~
pjmlp
No need to kill it per se, it would have been enough to allow Bell Labs to
sell it at the same price as VMS, OS/360 and other competing mainframe OSes,
instead of distributing its source code for symbolic price.

~~~
maire
The most that would have happened is Bell Labs would have shut down the
clones. There were already Unix clones in 1979. I worked on Cromix at Cromemco
before I worked on Mesa/XDE at Xerox.

If I remember correctly nobody outside Xerox used Mesa or Cedar or any of the
other amazing things at Xerox because Xerox never sold them. You must have
worked at Xerox.

I went to Apple after Xerox and programmed in C++ using a pretty bad
development environment. I certainly missed Mesa's exception handling and
development environment. Mesa was missing garbage collection as did C++ at the
time.

~~~
pjmlp
Yeah, garbage collection came into Mesa via Cedar, with reference counting
alongside a cycle collector, hence Mesa/Cedar, the replacement for XDE.

Had UNIX been a commercial product from day one, there wouldn't be any clones
to start with, as they were mostly bootstrapped by the free beer source code
that was taken via backup tapes from Bell Labs into a couple of collaborating
universities.

~~~
AnimalMuppet
I'm not sure about that. What you describe was enough to bootstrap university
interest. That didn't lead Sun, Apollo, SGI, et al to decide that Unix was the
right OS for making workstations, though. It didn't lead Sperry to decide that
they needed to have a UNIX available on their mainframes (!) back in the
mid-80s. And those were commercial licenses, not university bootlegs.

~~~
pjmlp
For a symbolic price, nowhere the same as something like VMS or OS/360 would
cost.

Hence why AT&T went after BSD afterwards, when the the context changed and
they were allowed to sell UNIX at market prices.

~~~
AnimalMuppet
What are you trying to say? Are you saying that the commercial Unix licenses
(to Sun et al) were only for a nominal price? Or are you saying that they were
_not_ for a nominal price, hence the BSD suit?

I agree that "the context changed" \- IIRC, when the AT&T consent decree
expired. That was 1982. Sun Microsystems was also founded in 1982. It was
based on BSD, which had to go through the lawsuit to be proclaimed,
essentially, a cleanroom Unix.

When Sun licensed from AT&T, (early 90s?) it was (I presume) at market price.

All that detail doesn't change my point: People cloned Unix _because they
wanted Unix_. There wasn't a Berkeley VMS, not just because VMS was expensive,
but because nobody wanted VMS that badly. (Why clone the thing you're getting
for close to free, anyway? Doesn't it make more economic sense to clone the
thing that you can't afford (VMS or OS/360), and pay the nominal price for the
almost-free thing?)

People _cared_ about Unix in a way that nobody cared about VMS or OS/360\.
Perhaps the ability to see the source code was part of that. But the story
you're telling seems far too simplistic.

~~~
pjmlp
To clone UNIX, in whatever form they had to have had access to it in first
place.

Which was with the tapes that flown out of Bell Labs into several universities
and the commercial licenses that were almost gratis, given the price
difference to other OSes.

[https://www.bell-labs.com/usr/dmr/www/licenses.html](https://www.bell-
labs.com/usr/dmr/www/licenses.html)

People keep reinventing history as if UNIX won based on merit, when it was
licensing that made all the difference.

Like the fairy tale that before C no one ever did a high level systems
programming language.

~~~
maire
From personal experience Cromix was written in 6502 assembly language. The
comments were all in C but personal computers were not fast enough to run a C
OS in 1979. I doubt it was licensed since they reverse engineered the API
(which is legal). I actually learned C by reading the comments.

Small piece of history - Cromix was written single handedly by Roy Harrington
who left Cromemco to found Informix.

Having said that - Mesa/XDE was awesome. I am sure Mesa/Cedar was even better.

------
smabie
"APL has been compared to a diamond, which cannot be made into a larger
diamond by the addition of a second one. LISP, in this context, is a ball of
clay."

I couldn't have said it better myself. I've come to think that APL and Lisp
represents two diametrically opposing philosophies about structuring programs.
Right now I'm leaning toward the opinion that the ball of clay approach has
run its course and is no longer (or maybe never way) viable. The thousands of
layers of abstraction is no longer viable, for both performance and
productivity reasons.

~~~
zdkl
Your conclusion may well be correct but I must reject your reasons : 1) we
have more (cheap!) hardware capacity than we can shake a stick at so sub-
optimal performance is very tolerable and 2) depending on how you measure
productivity, i'd argue high level/many layers of indirection languages let
you deliver features and value faster than non ball-of-clay languages at the
cost of weaker confidence in the code. Which can be mitigated to some extent
by more clay :) Personnaly, give me mud over diamonds any day.

------
timonoko
Lisp-programmer does not count brackets, but visualizes the linked list world
in some other way. My world consists of brown and red LEGO-bricks. They are
clued together in pairs and brown bricks are things and red bricks abstract
links. These greasy fake bricks were only playthings we had in the cheap-ass
post-war daycare center 1957.

Anyways it would interesting to see 3D-environment where this Lego-paradigm is
implemented. I sometimes think about it, but do not find really beautiful way
to name things, except tags with letters on them.

------
jascii
Throughout the years, it has always been an inspiration to read up on Stephen
K Roberts adventures! If you haven't yet, I strongly recommend exploring the
rest of his website: [https://microship.com/](https://microship.com/)

------
_bxg1
I've only written a little bit of it, but it brings me anxiety.

Any language without static types brings me a certain degree of anxiety,
thinking at all times about all the ways a given piece of code might be
misused and go terribly wrong.

But in Lisp you add another layer: that anything looking like a function call
could actually be a macro, further blowing open the door of possibilities for
what an unfamiliar piece of code might do.

Of course, _parsing_ Lisp is an exercise in tranquility ;)

It's all about the programmer's personality, I think. Graydon Hoare expressed
my feelings: "Basically I've an anxious, pessimist personality; most systems I
try to build are a reflection of how terrifying software-as-it-is-made feels
to me. I'm seeking peace and security amid a nightmare of chaos."

~~~
ninkendo
I’ve never written in lisp, and my lack of knowledge of it always makes me
feel a bit of respect towards people who do. Like maybe it’s this amazing
thing that if I was smart enough to understand, I would achieve transcendence,
or something.

But the biggest thing I look for in a programming language, is “how many bugs
can it stop me from writing”, and a lack of any compile time checking is what
keeps me from even bothering to look at it.

I’ve spent many years programming in perl, then ruby, before finally using Go
and then Java and then Typescript and now Swift, and I feel like the period of
time where I would tolerate a lack compile-time type checks is gone. It’s just
table stakes at this point.

Maybe lisp is the end game for non-type-checked languages and it’s the best a
dynamic language can hope to be. But I just don’t care at this point, because
that whole category of languages seems to be a broken idea to me at this
point.

~~~
flavio81
>and a lack of any compile time checking is what keeps me from even bothering
to look at it.

Common Lisp more than compensates due to some key features:

1\. any bug can be corrected at runtime without having to stop the program

2\. the type system is completely strong, not weak

3\. it actually has a pretty nice type system.

4\. the conditions-restart exception handling system is world-class

~~~
_bxg1
> it actually has a pretty nice type system

Not by default. And herein lies the core social problem with Lisp:

[new/non-lisp programmers]: Lisp doesn't have X!

[lisp programmers]: Just make your own X! Lisp is extensible! Or pick from the
twelve implementations already out there!

Here's the thing: probably all of those implementations are going to be half-
baked. And good luck finding editor support for the one you end up going with
when there's no standard to rally around. And have fun re-learning the nuances
of basic language features every time you join a new team.

A simple core language does not mean simple code:

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

~~~
vindarel
> > it actually has a pretty nice type system

> Not by default

> Or pick from the twelve implementations already out there!

Just pick SBCL!

------
invalidOrTaken
Lisp is very good at teaching you that you're not as good a programmer as you
think you are, and that you don't understand the domain as well as you think
you do.

These sound like negatives, but it's better to learn these things up front.

------
ncmncm
Most instructive would be to identify how reality turned out to be so
different from the breathless ideal presented, and how to recognize when the
next breathless ideal turns out to be similarly unable to be realized.

------
walkingolof
When reading these old computer-related articles, it's like reading about a
parallel universe, slightly different, but very recognizable.

------
ph2082
What app someone should build in 2020 to find and show it's true prowess?

~~~
dig1
I'd say any app that will do any kind of (more than simple) data manipulation.
If you plan to support more and more data formats, things will get
exponentially worse.

One domain where I'd go with Lisp/Clojure/Scheme any day are banking/financial
switches - software used to communicate between banks, card providers, POS
devices, even ATMs. These programs usually has to support tons of weird binary
protocols (among other things), designed in 70-ties and 80-ties. To make
matter worse, bigger banks adds own "juice" to those protocols, making hybrid
monstrosities. And usually, you can't find documentation about those
protocols, unless you are deeply in banking business.

~~~
nikofeyn
i would think elixir and erlang suit that better. they both have beautiful
binary pattern matching built in, and are perfect to wrap up disparate pieces
that talk to each other. they also share some commonality with common lisp
that a lisper should like.

------
thrw34234
Erm.. I think it's a bit overrated TBH. Don't get me wrong - lisp is quite
simply magical (and very ahead of the curve). However, when you look back at
code, those written in Python just seem much nicer. The AIMA/PAIP code in
Common Lisp, for instance, are ugly as hell, while that in Python (for AIMA)
is far far elegant. No doubt this stems, in part, from CL's legacy, but I
haven't found things to be much better in Scheme land either.

~~~
flavio81
>those written in Python just seem much nicer

>The AIMA/PAIP code in Common Lisp, for instance, are ugly as hell

perhaps it just means you are familiar with python, not lisp.

I have 3 years of experience with both and let me tell you, there is nothing
elegant in Python: there's nothing elegant in having to deal with one-line
lambdas, global interpreter lock, 30x-50x longer execution times than Lisp,
distinction between statements vs expressions, mutability everywhere, a
flaccid OOP system, no interactive development features, and horribly written
libraries.

