Extensible Programming Slashdotted (Unfortunately)
My ACM Queue article on extensible programming systems just got slashdotted. Once again, it’s clear that most of the posters haven’t bothered to read the article: even the headliner seems to think that I believe programmers will all be typing XML tags five years from now.
The article’s real point is that the next revolution in programming will not come from aspect-oriented languages or new ways of expressing concurrency; it will come from extensible languages—syntactically and semantically extensible, just like Common Lisp and Scheme. These languages will require us to turn programming tools into extensible frameworks, which will in turn finally force us to adopt the model/view separation that we’ve been telling the rest of the world to use for the last twenty years. For historical and marketing reasons, those models will probably be stored as XML, but programmers won’t look at the tags any more often than they look at assembly code.
Lots of people are already working on systems of this kind; just this week, for example, I came across the Proxima editor, a generic presentation-oriented editor for structured documents which does many of the things I think the next generation of general-purpose editors will have to do. Who knows? Maybe the Slashdot article will turn up a few more like this… And maybe Toronto will win the Stanley Cup this year.
Postscript: I was very pleased to see Jon Udell include a mention of the article in his blog. Some of the links from his post look very interesting; looks like I’ve got some more reading to to…
Not only is the proposal itself fascinating (extensible languages) but the reaction on Slashdot as well. I’ve heard Greg talk about this a few times already in various places (studygroup, etc.) so I have an idea of what it involves. But the replies on Slashdot had *nothing* to do with the core concept _whatsoever_. They all latched onto the “XML is ugly and typing tags are evil” thing and kept flogging that particular dead horse (actually, one person near the bottom of the page had the right idea).
This really puts most of the other Slashdot articles and responses in perspective. I wonder, what is the demographic markup of the Slashdot response posters anyway? Is it because these particularly-minded people will tend to congregate in such areas, or simply that posting a reply anonymously to an article by a person you’ve probably never met allows your ego free rein?
Is a prototype system in the works?
Just a few of concerns about your article:
1. I don’t see how it solves the problem of having to look at machine generated XML code when something goes wrong. You say that this is a major problem of many systems. For example, if I was to write a languag extension in an extensible programming language, and due to some error in my code it translates to something that doesn’t make sense in the language/mode I view my programs in, how do I debug it without looking at the generated XML? Such an error might be caused by a macro generating XML that violates the schema that the system stores its programs in.
2. A related point: how are we to write such macros? Are they written in whatever way we like to view our programs, or do we need to use a special transformer language? (e.g. Scheme’s hygienic macros not being normal scheme code. (BTW, your Scheme example is not of hygienic macros as you seem to imply.)) As far as I can tell, macro code would have to both consume and produce the underlying XML code in order to be independent of the programers’ choice of language representation. A language handy for such manipulations would invariably come out to be lispy, IMO.
3. And now to contradict myself: Is it really so bad that programmers should look at their programs as a tree structure (whether it’s in s-expressions or XML)? Sure, it’s strange and unpopular, but it does have its advantages. The reason Lisp is so powerful is that its programs and macros are written in the same language as the data they operate on and it’s primitives are handy for doing so. In the system you describe, there seems to be a disconnect between the way a normal program works and looks and the way macros work and look. I think that the underlying program representation (XML data) will always be in some way more powerful than the programmer’s specific view of the program.
IIRC, I read on Paul Graham’s website that there was once an early Lisp system that was supposed to have a syntax built on top of it that was more like the languages that programmers were acustomed to at the time. However, no one got around to making it because all the programmers got hooked on writing s-expressions, finding it to be better.
4. You say that using XML will make it popular amoung programmers. If the irrational reaction on slashdot means anything, I think it means that this point is not true. I think it is more popular with PHBs, managers, and marketers than with programmers. It gets overused so much, that there is a backlash against “XML everything”. I do see the advantage of XML, namely the huge number of tools already in existance that help use it, but how many of these would be really useful in writing programs, rather than munging loads of uniform data? Perhaps one could invent a data format that is in some way superior to both XML and s-expressions that people would not mind looking at directly.
It’s quite an interesting proposal and I would like to see what comes from it.