Common Lisp: The Untold Story
nhplace.com
nhplace.com
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.
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?
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.
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?