This post originated from an RSS feed registered with Agile Buzz by Laurent Bossavit. Original Post: Cobol is to Java as Java is to what ? Feed Title: Incipient(thoughts) Feed URL: http://bossavit.com/thoughts/index.rdf Feed Description: You're in a maze of twisty little decisions, all alike. You're in a maze of twisty little decisions, all different. Latest Agile Buzz Posts Latest Agile Buzz Posts by Laurent Bossavit Latest Posts From Incipient(thoughts)

I mentioned earlier I've been teaching Java to people steeped in Cobol, mainframes, batch processes, and procedural programming. Just how steeped is an interesting question. The first two days of the training project are over, I've made the acquaintance of the group, not one "slow" person in the lot; I expect they've been keeping up with other technology, even from afar.

An interesting aspect of such a project is figuring out how to present, so that they make sense, aspects of the Java language that would strike no one as particularly "novel", that so many developers take for granted - but that nevertheless represent a sizeable gap with respect to Cobol.

For instance, based on previous experience with students who had a similar background, I knew I might need to explain how the call stack worked, before introducing heap allocation as a further complication. I showed the slide with a picture of the stack and asked if that was familiar. People nodded. I wrote, in near-Java, a recursive implementation of "factorial" on the flip chart - and asked if that would work. One student said, "Not it won't - you'd need an extra static variable, wouldn't you ?"

So I walked through one specific call to factorial, showing how stack frames were allocated, where intermediate values of the parameter would be go, where intermediate results would go, and so on. Some of the students knew this stuff from CS classes, some of them even remembered parts of it - but I needed these notions, and the visual representations that go with them, to be in the "active" part of their memory while we'd be looking at more specifically OO notions, such as object construction (which involves dynamic allocation, which involves contrasting the stack and the heap, and which also raises the question of the difference Java draws between "primitive" and "object" types).

None of this is strictly necessary. You can implement recursive algorithms in Cobol by emulating the stack; it "just" makes programs look tidier to have the mechanisms embedded in the language. The same could be said of many "features" of programming languages that Java programmers are quite happy to do without in general, and emulate when they need them; closures, first-class functions, and so on.

Then there's this idea that Java is the new Cobol. So, not for the first time, I'm wondering which language features of Java will come, in a few decades' time, to seem as antiquated as Cobol's static memory and lack of recursion now look. And, on the other hand, which "novel" features will slowly become accepted to the point where everyone takes them for granted. And on the gripping hand, perhaps every important feature a programming language could have has already been invented, and the best we can hope for is that we'll eventually converge on a particularly effective combination, or a few particularly effective combinations.