
Common Lisp: The Untold Story - lispm
http://www.nhplace.com/kent/Papers/cl-untold-story.html
======
sophacles
Great article. At first I thought "What a nice read for my morning coffee".
But it certainly has gotten me thinking about my own experience with standards
and committees and working groups. I should note now, I've never been a big
player in any of these, but have participated - so my experiences are a bit
different than Kent Pitman's, but related.

I think a big takeaway from this should be: if you are interested in a subject
and get involved, you can influence it in unexpected ways. My name is not on
any major specs or standards, but some of my ideas or suggestions are there.
Not because I am all that important or super smart, but because I was involved
and therefore able to influence and help decisions. Simple things like asking
questions about ambiguity can have unexpected influence. One time I asked a
question about a line and it turned out half the people involved thought it
was one way, and the other half thought the opposite. Clarification ensued,
but what a mess it would have been if no one had asked!

Another thing that I find to be a useful lesson in this article is that
sometimes the dog wags the tail, and sometimes the tail wags the dog.
Frequently you see people on committees arguing over some detail that matters,
but not as much as you might think. Frequently the decision comes down to
someone just implementing it one way in a pre-release. Those implementations
will become either a great example of why the other option is better, or of
why the choice taken is better (or at least that the choice wasn't that big of
a deal after all). Committees take on a life of their own, and exist in a bit
of echo chamber, so sometimes scoping of issues gets disproportionately wrong.

A final personal observation that doesn't come through in this article, but I
think is important. If you do research or cutting edge work, just hanging out
at these types of meetings provides tons of fodder for exploration and
research. Ideas are usually just floating through the air in the form of "if
$THING works we could $X, but if it doesn't we would have to $Y". Every time
you hear that, there is a paper to be written. Other times you hear great
ideas for companies - "The $PROBLEM is a major source of concern", but it
turns out $PROBLEM isn't really a problem, it has been solved in a different
corner of the world nicely. Porting $SOLUTION from one domain to another is a
starting path to profitable companies.

There is a downside though, is that there is a bit of self-hyping that needs
to be done in these processes. If you have been paying attention, writing
papers, doing exploration, sometimes your contribution gets lost into the
general idea space. People will start talking about the concepts of your work
as if they came from nowhere. This isn't intentional, ideas seem to have a
life of their own like this, but if you wrote a paper, and someone is now
touting the concept as something that just came to them (even in changed
form), you need to gently point them at your work, so you can get some credit.
Basically it's personal branding, and a bit uncouth, but necessary
unfortunately.

------
rogerbinns
What has never been clear to me about Lisp is how these implementations
differ. The syntax is so simple it doesn't seem to be that, so that would
leave builtins and libraries. Surely builtins can be emulated and libraries
can be ported.

So why doesn't there exist some macro (Lispers always brag about them) that
could transmogrify code written for one set of builtins and libraries to
another?

~~~
Someone
That is not so easy to do if the differences can be as huge as
[http://en.wikipedia.org/wiki/Scope_(computer_science)#Lexica...](http://en.wikipedia.org/wiki/Scope_\(computer_science\)#Lexical_scoping_and_dynamic_scoping).

It becomes a nightmare if your are trying to transmogrify code that itself
already transmogrifies code. Such code will make assumptions about how the
lisp it runs on behaves.

~~~
rogerbinns
I still don't see how the scoping is difficult. Since macros can see the whole
structure and usage of symbols why can't it rename or insert/remove necessary
declarations (eg local or set)?

I can understand how each level of transmogrification makes things harder to
grok but in general wouldn't there only be one level. eg if code was written
for LispA and you are running LispB then you just need one level to fix that.
(Sure if you are running LispC then you might need A -> B -> C but there
aren't that many different Lisps listed!)

My question still remains - what was it that made these Lisps so incompatible
and couldn't be addressed using the existing much vaunted facilities already
in the language?

------
angersock
There is an interesting bit (section 6.2, "ANSI and Copyright") in which the
author relates a phonecall that involved the copyright issue for who owns a
spec. It's an interesting read.

