Common Lisp: The Untold Story (2012)

http://www.nhplace.com/kent/Papers/cl-untold-story.html

by tosh • 7 years ago

100 30 7 years ago

taeric• 7 years ago

I'd be curious to see more on the advantages of using raw TeX instead of LaTeX. Feels like that should be backwards, but didn't surprise me, either.

jimhefferon• 7 years ago

I thought he was working at a time when there was no Latex. (Of course, some people do like Plain TeX more.)

Syzygies• 7 years ago

I'm an '82 PhD mathematician who has used TeX and LaTeX since near their beginnings, to typeset math papers. There was a long period when TeX was essentially instantaneous, while LaTeX was plodding. Also, if one pried into various LaTeX packages, there was a general tone "User won't do this for themselves or even know we're doing this, so let's also clean up this related situation" that felt like coming home to find a team of house cleaners crawling up your chimney with toothbrushes. Directing mathematicians is like herding wolves; this didn't sit well with everyone.

Struggling to agree on TeX vs LaTeX for collaborative projects, I ended up writing a few pages "begin.tex" that at least managed automatic theorem numbering and reference handling, and a few other basics, so we could live without LaTeX. This too was essentially instantaneous, and spread from collaborator to collaborator for a few years until machines got faster.

Speed matters: Look at the Vim / Neovim split. Some found the Vim delays acceptable, while others had a vision of the future that required far more sophisticated evolutions to not impose user delays. Vim was forced to catch up.

mark_l_watson• 7 years ago

Interesting to hear an insiders perspective of the ‘Lisp Wars’.

My outsider’s perspective, at the time, was disappointment. I really liked InterLisp-D on my Xerox 1108 Lisp Machine. That said, Xerox provided a Common Lisp implementation that still had the UI wonderfulness and I think they still supported DWIM. I now have about 35 years of frequent Common Lisp use/experience, and my latest project/product is written in Common Lisp (http://kgcreator.com).

dang• 7 years ago

2016: https://news.ycombinator.com/item?id=11789288

2012: https://news.ycombinator.com/item?id=3918032

PaulHoule• 7 years ago

I think it is strange.

LISP people hated Common LISP circa 1990 for various reasons. Most users were still stuck on 16-bit micros on which LISP was tough to fit, and Common LISP didn't make it any easier.

LISP people look back at Common LISP with nostalgia now since it was so much better than Blub languages like Java, Python, Haskell, Go, Rust, ...

dreamcompiler• 7 years ago

I hated it at first because it had lexical scoping by default and I was used to dynamic extent. I don't want to be unkind to my former self (MFS), but MFS was pretty stupid.

timonoko• 7 years ago

That was it. I made my own Eval in Symbolics, just because I truely did not understand the scoping issue.

kazinator2• 7 years ago

I suspect that some people disliked Common Lisp because they worked at institutions where they were able to develop and support their own Lisps, and ANSI CL was foisted on them: "party is over, make it compatible with this honkin' document".

lispm5• 7 years ago

Also internationally, since CL was a most US effort and Europe/Japan were trying to have independent or international implementations/standards of Lisp.

kristianp2• 7 years ago

"In 1992, Symbolics Inc. was doing poorly financially because it was continuing to sell hardware and its computers were not hitting the price point demanded by the market. A last-minute effort was underway to produce a software-only emulator of the architecture".

The emulator they built Open Genera was for the Alpha, and after Symbolics the defuncted ported to Linux 64bit: https://static.loomcom.com/genera/genera-install.html

varjag• 7 years ago

There's a Docker recipe for it too: https://github.com/sethm/docker-vlm

kristianp2• 7 years ago

That repo is 3 years old. Does it work with more recent versions of Docker? (I'm on windows right now, so can't check, as it requires NFS on the host).

pfdietz5• 7 years ago

At that point it had been figured out how to safely and efficiently implement Common Lisp on 32 bit stock hardware (workstations, then PCs), which of course was going to economically destroy specialized machines.

What standardization of CL also has done is restrain the commercial lisp implementation vendors, since they compete against standard-compliant free implementations.

rurban3• 7 years ago

Interesting that he didn't add the aftermath inside of his own mistakes in the standard. He was the best person to write it down and defend it later publicly. but he also added a chapter by himself, the nes (new error system), the new conditioning system, which was by far the worst part of the standard. Almost nobody uses it, way too overarchitectured. All the rest is very solid, people only complain that threads and ffi are missing from the standard.

rauhl• 7 years ago

I think that the condition system is one of the better parts of Lisp, and miss it in every language where the libraries I use unwind the stack to provide me an error.

It’s true that it’s not used too much in small programs, because small programs don’t need it. But in large systems, it’s invaluable.

rurban3• 7 years ago

Conditions are invaluable, but not Ken's. It faces the same problems as my stderror AutoLISP library: overarchitectured. Slim and small, not so big and fragile. CLOS is small and easy compared to the conditions.

scheme did it right

pfdietz5• 7 years ago

All the rest is very solid

Logical pathnames are very solid?

Let's also talk about the complex types and their operations. Their specification has a big internal inconsistency.

Oh, and read strictly, the subtype relationship is undecidable, which makes array element upgrading impossible to implement in a fully conforming way.

There are also all those places where the standard does not define what happens. Why are some operations required to signal errors in safe code when argument type constraints are violated, but not others? This lack of specificity is the opposite of "solid".

rurban3• 7 years ago

OK, logical pathnames are not solid. Agreed.

Types and subtypes were a very late decision and not in CLtL2 I believe.

Those lack of exact error descriptions is also in most other standards, and many are implementation defined. CL set the first standard there with its strict formalization even for the most mundane forms. Still very solid to me. I'm still fighting daily with the C standards which should know better by now.

lispm5• 7 years ago

but he also added a chapter by himself

He was chair of the ANSI CL subcommittee for error handling.

far the worst part of the standard

That's a very very rarely heard complaint.

tosh• 7 years ago

Change was happening to MACLISP very rapidly in the late 1970’s and early 1980’s. It was common for MACLISP users to read their mail only to find that some critical semantics in the language had changed and that it was time to update programs they had already written to accommodate the new meaning.
Jokes were made about the frequent and extreme nature of the changes.

Common Lisp: The Untold Story (2012)

Related Stories