The Third Bit

http://www.cs.umd.edu/~pugh/IsCodeOptimizationRelevant.pdf

Extensible Programming, Research

A link in Jon Udell’s blog [1] pointed me at Jeffrey Snover’s Monad, a super-shell for the next version of Windows. It contains a lot of very cool ideas; if you’d like to take a look, go to [2], click “Watch It Now”, then go to Section 5 of the video.

[1] http://www.infoworld.com/article/04/10/29/44OPstrategic_1.html

[2] http://www.msdn.microsoft.com/theshow/Episode043/default.asp

Extensible Programming

Over in the java.net community forums, Bruce Chapman suggests that we deprecate javac in the next major Java release. Yup, that’s right: no more javac. Instead, he suggests that we all start using apt, which allows developers to run their own code inside the compiler. As he says, “Do you want a compiler error when you implement an interface and the javadocs say that implementations must have a public default constructor, and yours doesn’t? Well apt [can] do that…”

It’s a pretty cool idea. It’s also a perfect example of the kind of extensible tools that I think are going to dominate programming in the years to come. If I’d read it a week earlier, I would have mentioned it in my extensible programming article, which has just gone off to ACM Queue. Maybe I can throw it in as a late footnote…

Extensible Programming

Jon Udell posted some more comments about E4X today. If you haven’t been following along, it’s a proposal to make XML a native data type in JavaScript, so that programmers can manipulate it as naturally as they do strings or lists.

The most exciting thing for me about E4X (and variants)
is that it provides a path away from the morass of “passive” XML
configuration files that currently plague web development. My
students (hand-picked, all with good GPAs, most with industrial
experience) have had a hard time getting the “standard” Java
web toolset—Eclipse, Ant, JUnit, Hibernate, Tapestry, and Tomcat—up
and running. Most of their grief has stemmed from the fact that
much of what developers care about is in XML config files, for which
there isn’t any kind of break-and-inspect debugger.

RubyOnRails and
other “pure scripting” solutions are easier to use in part because
all of the config glue is in the language the programmer is using,
so she can bring all her programming power tools to bear when something goes
wrong. (Oh, and she doesn’t have to wedge conditionals, loops, and
the like into some hashed-together XML syntax.) From what I’ve seen
so far, JavaScript with embedded XML (and the reverse) would give us
a way to migrate from the existing undebuggable mess toward programmatic configuration.

Extensible Programming