Skip to main content

The IDE is the language

Posted by evanx on January 7, 2008 at 7:53 AM PST

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.

typewriter-crop.png
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.

pig1-200.png
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?

Comments

Some would argue that Java is a system programming language...

I think it resides in the middle of the spectrum. It is both a system AND an application programming language. But because of that, if it tries to be too good in one of them, the other will suffer. If it tries to be too good in both, it will just be too complex to be good for either.

So, new features are certainly welcome, but with extreme care...

And, if the IDE is the language, and IDEs' evolution aren't tied to the long and tiring process of JCP-like committees, why couldn't they add new (syntax-sugar) features to the language, since it could just translate it all to plain-old Java underneath? (sarcasm intended)

I believe java is the only programming language to learn and use for programming. That said, I will only fully accept my belief when someone writes the equivalent of Unreal Touranment 3 in java. I would NOT go that far. You should learn a bunch of languages, including Haskell and Scheme and other different sorts of languages. The belief in a single language to learn is what creates dinosaurs!!

A responsible professional is always looking into the latest and greatest.. whether he uses it professionally or not. Note that some of the greatest concepts in programming languages today come from languages such as Smalltalk and Lisp. If you didn't know that you might think there's been a bunch of innovation in recent years. Sadly the reality is innovation has slowed down since about 1980 or so. (Haskell seems interesting though.. maybe one day languages will be more like it.. though I don't know if I like such a future)

The biggest reason Java is going to stay around is because of the ENOURMOUS amount of libraries and other tools around that support it.

I'm starting a new project and we're wondering what language to use (I'm fairly open about switching). Java has SOOOO many more tools/libraries/frameworks available to it than Ruby or C# that it just seems like the best bet. Especially since we're not interested in reinventing the wheel.

Java is a proven platform.. the others aren't ready yet for primetime. I wish they were.. but they aren't.

Sorry to be repetitive, but again the Dynamic Proxies is again the wrong example IMO. The _complexity_ of a Dynamic Proxy is much superior to statically generated stubs. It's just that you don't see it.

I believe java is the only programming language to learn and use for programming. That said, I will only fully accept my belief when someone writes the equivalent of Unreal Touranment 3 in java.

I would be careful with your IDE argument. Tool support has been misused to justify overly complex designs quite often in the short history of Java.

EJB deployment descriptors, anybody? None of the IDEs ever managed to provide proper support, and people were desperately looking other solutions (XDoclet and friends). Finally the API designers were forced to fix the problem. The solution was found in a new language feature (annotations).

Another example: Remember early RMI's rmic for generating stubs? Not really major problem, but an annoyance. Dynamic proxies turned out to be a superior solution. The JAX-WS designers did not learn this lesson, and once again we have to fiddle around with wsgen and hope that the IDE provides some more or less painless support.

Fix the problem, not the symptom!

(tons of typos above, but it should be clear - the day that they improve the user interface of this blog won't ever be too late)

"Using the IDE as a caterpillar to shovel piles of code around cannot be the solution. We humans are supposed to still be in control and to actually understand what we are doing"

Having the IDE doing some automated things doesn't imply that we always lose control (of course, it depends on what you're doing). The point is that some things are pretty damned simple for a conceptual point of view, but they are repetitive and thus requires lot of boilerplate. Let's just think on the JavaBeans (I mean the full fledged ones, with listener property support, as Cay mentioned). The concept is very simple: for each property, you have a setter/getter, the setter fires up a certain event when the property changes, you can attach/detach listeners. Pretty coincise. It requires tenths of lines of Java code to be done. Now you can:
  1. Do it with a language enhancement
  2. Do it with Aspect programming or bytecode manipulation
  3. Do it with code auto-generated by the IDE
My preference is for the latter two, the IDE above all, but this is not the point. In the end, all of the three methods will produce more or less the same bytecode, that is the same complexity is generated out of the same terse specifications. The only difference is that with the IDE you're seeing an intermediate artifact (the generated code), which in any case you should just pretend not to be there (and the IDE can actually hide it). But, I repeat, the complexity is still there: if you think that there is too much generated code by the IDE approach, well, it will be the same for the other two, and the conclusion seems to be that you should always code property event by hand. If this reasoning proved sound, then we should also give up to the garbage collector (which is something whose implementation is MUCH more complex than the property thing, but - again - the specification is pretty simple).

Funny thing, just this morning I stumbled over this article:

http://www.stsc.hill.af.mil/CrossTalk/2008/01/0801DewarSchonberg.html

As for the "Java is the new COBOL" statement: Well, it's true, isn't it? It's the same enterprises that relied heavily on COBOL that are now relying heavily on Java. I still don't see any Java applications on my or anybody else's private desktop; at least none that are 'pure' Java. Cocoa-Java apps I've seen one or two, and then there is the game 'Tribal Trouble'. No, Java's domain still are the server and big corporation desktop apps.

Using the IDE as a language is a very dangerous and scary idea. Java certainly does NOT need any new features, librariers or frameworks. It actually needs to have a lot LESS. The complexity of the Java ecosystem is intimidating and it would not surprise me if it is already driving people away from the platform than attracting them to it. There just is too much stuff to learn -- and 'abstracting' this to the IDE level will only make things worse. I am completely with Bruce Eckel and others here. Using the IDE as a caterpillar to shovel piles of code around cannot be the solution. We humans are supposed to still be in control and to actually understand what we are doing. Having a tool do most of the job for us is just wrong. And adding perspectives to an IDE is not really helpful either.

Remove the complexity. Cut the language and the platform down to something comprehensible that is still powerful. Does anybody remember the first law of design? 'A good design is when there is nothing left to take away, not when there is nothing left to add.'

P.S.: Sure you can introduce new language features afterwards, but what happens to the API? Will you add another 50 ways to do the same stuff the old API already does or will you just add a language feature and only use it for additional functionality within the platform? And what would that mean to the old stuff? A lot of Java's current API is outdated already, other stuff is just not very well thought and other stuff is missing. In a fast paced time the mantra of the old players seem to be "bloat is all around". Apple had success with a clean cut with Mac OS X, I don't see why it shouldn't work for Sun with Java (language and API) as well.

i do believe in that dijkstraian law of design, together with "Systems Thinking." Adding some simple stuff to the language might mean we can take a helluva lot of code and complexity out of the libraries and our apps, and improve readability, reliability, simplicy, toolability and a few other 'abilities, of the system as a whole? Like supporting properties properly. Like everything Bill Joy et al really wanted for Java 1.0 but marketing and business pressures (and not technical) didn't permit at that time? For Swing we need first-class properties and EDT thread programming to be simple and natural - if closures help with that, then great. Failing that, we carry on as we are. However, that is not human nature to accept that which we can change for the better. When i say "better" i mean simpler, on whole.

I gave Scala a brief look, same with Python and Ruby. I have similar problems in setting myself in motion learning new languages with different syntax. But I also think that this is something you should do from time to time, at least to be able to get a glimpse of different concepts. Maybe those let you think of what you're doing in Java and how you're doing it in a different way. Otherwise we may find out someday we have missed the train... Interoperability with Java through Scala, JRuby, Jython, Groovy (, ...) has its charme. You can reuse existing code and migrate step by step. But what about deployment? I always found web development in Java being a pita and therefore stuck with server side scripting and used Java mainly for development of desktop applications. Time will tell what becomes of the Java language, the API and JVM. Surely it will be around for another long time one way or the other, just because of the immense codebase.

I have long suggested the IDE approach as a way out of the operator overloading war. Methods could be annotated as 'operators' and suitable IDE's could display tham as such, while regular IDEs saw the underlying method syntax.

I've been thinking around programming 'languages' and trying out a few new ones (ruby et al) recently (having done my share of pascal C/C++ etc). I found my problem is high expectation: none of the languages relieve me of the basic grind of coding like marking blocks of code with different characters (}, END etc) and generally repeating myself by typing the same variable name every time I want to use it (I'm easily irritable). IDEs go a fair way to alleviate this in cludgy ways - code completion and templates; its nice, but missing the point. What I want from a new language is: 1. No source code (when you think about it, source code is soo 20th century). Why not code directly to bytecode? Thats pretty much what is happening when you use eclipse (indulge me). 2. Use graphics to demarcate code blocks, a nice wire frame or something less intrusive would work for me. 3. Similarly we can get rid of keywords, this is a bit more difficult as we would need some kind of shortcut syntax for creating for loops etc - though again, most IDEs support this in a way already. 4. Variable names could be seen as tokens rather than text (sorry the next bit is going to be rushed, aperitif is awaiting), no more imports (the full namespace will be used but hidden from normal via), you should only type the variable name when creating it, else you are selecting it from a known list, or something. Of course, creating the language spec would mean stipulating the L&F to an extent, but I don't see that as a problem. Anyway, thats the germ of the idea I'd be interested in comment on this. Evan, if you are back in town give me a call. Brian