We’re still punching holes in things to make programs. Yes, we are. All these fancy editors and we’re still baking code in clay. Most code is syntax on wax tablets, dead bits about as accessible to your average program as heiroglyphics sunk under the sand. Such a waste, it doesn’t have to be this way.
Steve Yegge has an interesting (if long) bit on what the Next Big Language is going to be. Go ahead and read it (don’t miss the first few comments). I’ll wait.
He’s absolutely correct about both the difficulty of parsing a “modern” language, and the requirement that any Next Big Language is going to have to support more or less the same syntax because people are used to it. But parsing C is hard, and parsing C++ is hell-on-roller-skates. That’s why people pay through the nose for competent tools that work with these languages; the barrier to get any kind of meta-tool working at the semantic level (what I mean is: above the level of grep) is really high. When you add vendor-specific extensions (e.g., “The Frobozz Quality Suite works great for Linux, the Mac and Windows, but we need it to run on stuff written for the Xbox-360 and the Playstation 3”) you’re basically just doomed.
My opinion: The Next Big Language needs to be essentially a DOM. Call it reflection that you can use to write code with, call it a parse tree with semantic contracts and a run-time, call it whatever you want, but having programs easily able to read and write other programs is just too powerful a paradigm to keep ignoring.
I hardly care if the language is LALR(N), reverse polish, prefix, Unicode-based or has continuation characters in column 6. As long as I have an editor that can speak to a capable abstraction that in turn *writes* in that language, I honest don’t give a damn what the language looks like; I’ll make it look like whatever I’m comfortable with at the moment. Why should there be only one way to look at an entire hunk of source code?
So when we standardize the print-rep of a language, what are we really doing? Simply making it easier to publish textbooks about the language? Making it so that we can still write programs with strips of paper and an awl? Why do we bother with a text-rep of a language any more? Let the audience decide where to put the semicolons for a change. Let’s get out of the Emacs and vi ghettos and actually use these bitmap displays for something other than fancy keypunching. (Remember, however, the cautionary tale of the UCSD Pascal editor of the early 80s, which forced you into syntax and basically sucked dead exploding goats).
I’m begging some important questions, namely all the semantics (though if you stray too far from C you’re in trouble on bare-metal platforms and other places where cycles matter), and what the heck do we do with compilation units (which are, after all, a reflection on compiler technology, the miserable state of our disk I/O bandwidth, and our seeming inability to make efficient use of main memory that is running $100 a gigabyte these days, about an hour’s salary for a good engineer). What if the floor for a dev box was 64G of RAM and $5000 worth of really good hard disk array? (Or better yet, a decent build system in the basement?)
More nattering later…
[Yes, C# has a not very nice code DOM, maybe improved since the last time I looked. LISP has had something like this forever, as long as you like LISP. With the JVM and CLR you can pick your own language rep as long as you like assembly language, which is not very interesting.]