Evan Summers's Blog: January 2008 Archive

A few years ago, as Linux was gaining traction, I asserted to a colleague, "C is the new assembler, woohoo!" Some people have said that Java is the new COBOL. Ooo, I hope not! ;) Others have suggested that Java should become the new C. What they mean is, forget about the Java language, it's the JVM that's important, because we should move on to JRuby, JPython, Scala or something more sexy and more productive than Java.

Firstly, i consider productivity highly related to the IDE, rather than the compactness of the language's syntax per se. And readability to be more important than code brevity in itself. Also, i don't want to use a language that has a syntax wildly dissimilar to C and Java which i know and love. That means that C# is an option, but one i hope i'll never take, so forget i even said that just now!

The point is, i'm not going to switch to Scala ever, even when it has top-level support in my IDE ie. on a par with Java. Because the language syntax is so butt-ugly foreign to me. After 10 years of C, i switched to Java 'cos it was nice and familiar, and now after 10 years of Java, and latterly with Java IDE's, i'm staying put here forever, end of story.

So we navigate, view, edit and refactor our Java code using an IDE. Yes, there are those out there that use vi or emacs. But let's face it, they are clearly a lunatic fringe, so let's pretend they don't exist for all intent and purposes ;)

So we program on the IDE, and behind the scenes, our IDE creates and modifies Java source files on disk, and invokes the compiler to convert those to bytecode. (Maybe bytecode is the new C, and the Java is the new COBOL, but ssh ssh, lemme continue.) Typically, the view provided by the IDE is identical to the Java source code, sans code-folds. But that doesn't have to be the case. Besides the typical folded/unfolded code views, we have other views eg. lists of attributes, methods, bean property value initialisations, event mappings, graphical component tree, visual layout designer, UML diagram, et cetera.

Now for argument's sake, say i'm very keen on some new language feature eg. first-class properties. Practically speaking, all i see and care about, is the view of the code as presented and portrayed to me by the IDE i use. So actually, if my IDE had a "first-class properties language module" that presented properties neatly for me, that's all i care about, isn't it!? If my IDE generates and hides the boilerplate of getters and setters, going beyond simple code-folding into observability and what-not, and cleverly presents and supports completion and refactoring of property literals for me, i'd surely be as deliriously happy and as blissfully ignorant as a pig in strawberries, wouldn't i!? Tangentially, my personal philosophy is that being deliriously happy is circumferential to being blissfully ignorant. Hey, I don't even know what that means, and that's what i dig about it, man!

My point is, the IDE's view of the language, is the language, for all my intent and purposes. At least in terms of personal coding practicalities, if not literature, code snippets and what-not. Really, the selfish reason why i would want something new introduced in the language itself eg. first-class property support, is then that would guarantee such support in my IDE. But second prize would be an alternative view i want presented and tooled by my IDE. That would circumvent the controversy and possible impossibility of a language change. All that is required is for me or someone more better, to write such a Netbeans module, that i would choose to use to enhance my personal programming experience and productivity.

An addendum is that JSRs and their APIs cannot necessarily exploit such custom conveniences, eg. standardised Beans Binding would never be designed to work with some imaginary custom IDE module. Therefore such IDE modules would have to come with a complementary framework which exploits its conveniences.

Having espoused all the above nonsense, my final epistle to my apostles is, software should continously improve, forever. Generics, annotations, properties, closures et al, would have been great for Java 1.0, but failing that, why shouldn't they be introduced later on the roadmap? By and large, software evolves or dies. OK, C will always live on as is in the OS eg. Linux kernel et al, and C++ for many native libraries and apps eg. KDE, JVM et al. But the higher level languages such as Python, Ruby, Java and C# are evolving, so as not go the way of COBOL.

The number of programmers and amount of software written using high-level languages, across the intranets and internets, is umpteen orders of magnitude more than that of system C/C++ programming. And the competition for mindshare amongst these new high-level languages is fierce. So naturally that's where the evolutionary and revolutionary efforts are focussed. One cannot put a brake on competitive innovation. 'Cos that's what makes the world go forward, isn't it?

Powered by
Movable Type 3.01D

java.net RSS Feeds