Download PDF version of this article PDF

To submit a letter, e-mail us at [email protected]

Extensible Programming, Extended Edition

In “Extensible Programming for the 21st Century” (December/January 2004-2005), Gregory V. Wilson considers user-extensible syntax and semantics to be the “next big thing” that is missing from existing programming systems. Done imperfectly, however, unfamiliar extended syntax can interfere with readability, creating a Tower of Babel that makes adding resources to a project expensive. I note that Donn Seeley’s work, “How Not to Write Fortran in Any Language” (December/January 2004-2005), touches on how familiar structure helps us understand code.

Kurt Guntheroth, Seattle, Washington

GREG WILSON RESPONDS: I agree. If misused, syntactic extensibility will make programs harder to read. However, that’s true of every abstraction mechanism—each time we give programmers new ways of doing things, it allows the good ones to do better, but the bad ones to do worse. I also believe that new syntactic forms are no more likely to be unreadable than the mess of nested function calls, conditionals, and so on that they can replace.


I liked Greg Wilson’s article, since I think it addresses an important issue for the future (there already is a Java extender!). But I missed seeing Dylan (object-oriented language originally developed by Apple Computer) mentioned in the article. Dylan has implemented key components (control constructs such as for, while, if, etc.) of the language by means of macros without becoming as bulky as Scheme.

But one thing really worries me about extensibility. In real life, every community invents its own language with specific terms, semantics, acronyms, etc. In the end I am afraid that we will get a new portability issue (between communities) if extension is too easy.

Michael Erdmann, Berlin, Germany

GREG WILSON RESPONDS: I like Dylan too. I’ve always regretted that it didn’t become more widely known. I decided to use Scheme as an example in my article because I thought more people would know about it and because so many ideas about extensibility were first developed in it.

Regarding your worries, I hope that active libraries will lead to exactly the reverse: if everything needed to make XYZ work (the runtime library, its link/load descriptors, associated metadata of the kind needed for Servlet deployment, adapters for various tools, etc.) is bundled in a single format, then portability should be enhanced, not reduced.


First of all, I’d like to thank you for creating a magazine that does not make you drowsy. I really enjoy reading it. It is nice to see the ideas “in the rough”—before they are proven.

I’m writing to you about Gregory V. Wilson’s “Extensible Programming for the 21st Century.” The author suggests that the main presentation of the programming languages will be XML; although this idea is attractive, I think it should apply only to the documentation, specifically to the presentation, and not to the programming code itself. The reason is the right level of abstraction: when the presentation is too elaborate, the real meaning may escape. There is a good reason for ACM Queue itself being a text-based magazine and not a multimedia presentation.

The author did not mention any of the pre-XML extensible languages. I find it fascinating how TCL was started as an extensible language and ended up as yet another scripting tool.

Dmitriy Vasilev, Saratoga, California

GREG WILSON RESPONDS: I agree with your view that “when the presentation is too elaborate, the real meaning may escape.” That’s precisely why I advocate separation of model and view in source code: to present more comprehensible views of programs, we need to break the one-to-one binding between characters in the source file and glyphs on the screen. I mentioned Scheme, which predates XML by almost 20 years, because I feel it is still the most extensible “little language” ever created. Forth would have been another interesting choice.


A Lesson in Self-Healing

I enjoyed reading Michael W. Shapiro’s “Self-Healing in Modern Operating Systems” (December/January 2004-2005), but wondered why he made no mention of the IBM AIX error logger and system resource controller. The AIX error logger provides centralized reporting of hardware errors similar to the “fault manager” described by Shapiro, and can be told to perform different actions for each error. The AIX system resource controller keeps startup information for system daemons and has an associated API to communicate with them. It is clearly a forerunner of the “service manager” described in the article. These features in AIX have been present for 10-15 years, and I missed them sorely when I moved from an AIX shop to a Solaris shop in 1995.

Ed Ravin, Bronx, New York


Fortran Lives

The article “How Not to Write Fortran in Any Language” was arrogant and misleading. Donn Seeley writes, “No one would want to program in Fortran today, since many better alternatives are available. But you can write a usable and maintainable program in Fortran in spite of its many hindrances.” I doubt that Seeley knows anything about Fortran 90 or 95.

Obviously, some people do want to use Fortran, because leading companies such as Fujitsu, Hewlett-Packard, IBM, Intel, and Sun Microsystems sell Fortran 95 compilers, as do several independent vendors. If no new code were being written in Fortran, they would still be selling Fortran 77 compilers.

Fortran 90 fixed most of the defects of Fortran 77, adding free source form, dynamic memory allocation, user-defined types, procedure interface checking at compile time via modules, array operations and sections similar to Matlab, and other features. Fortran 95 added features for parallel programming from the High Performance Fortran language, such as pure functions and the forall construct. The recently approved Fortran 2003 standard is a major revision, adding object-oriented programming, IEEE arithmetic, interoperability with C, and other features, as described in a recent book by Michael Metcalf, John Reid, and Malcolm Cohen (Fortran 95/2003 Explained, Oxford University Press, 2004).

Fortran was too slow to incorporate some important language features, but the decision about whether to use it today should be based on the features of Fortran 95 that are currently available and those of Fortran 2003 that soon will be. I hope that future issues of ACM Queue will not contain such ill-informed bashing of unfashionable programming languages.

Vivek Rao, Narberth, Pennsylvania

We edit letters for content, style, and length.


Originally published in Queue vol. 3, no. 2
see this item in the ACM Digital Library


© ACM, Inc. All Rights Reserved.