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.
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?
The runtime environments are widely different. Some of the core libraries are implemented in a different way. There is the idea of a Common Lisp which implement the standard in a straight forward way and implementations which implement the standard with extensions and, for example, using CLOS. Different are threading implementations, extended character support, foreign code interfaces, streams in CLOS or not, error handling in CLOS or not, support for the Meta-Object Protocol or not. Interpreter or not. Compiler or not. Various compilation targets: C, native code, byte-code, JVM byte-code, ... Then there are different tradeoffs: cross-platform, Windows-based, MacOS-based, JVM-based, Unix-based, small footprint, highly-optimizing, ...
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 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?
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.
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.