Doddery Fodder: Going Over the Limit

By Frank Wales

Does the study of the psychology of programming encompass the psychological burdens of being a programmer? I ask, because the other day I came across what a Java compiler blithely calls an "implementation restriction" which was so unexpected, and so dumb, that I could gleefully have strangled whoever was responsible for taking the decisions that led to it. And I'm quite a restrained person; ask anyone I haven't strangled yet.

The thing that annoyed me was the discovery that Java identifiers and the object code for methods have something in common, namely that both are restricted to about 65,536 bytes in length. Now, this is jolly long for an identifier, and good enough for me. But 65,536 bytes as the maximum length of a method's object code? Even Bill Gates's famous underestimate of the amount of memory a PC would ever need was ten times more than that.

Note, by the way, that the restriction is in the standardised file format for Java classes, and not inherent in the language itself, which is why it's more of a surprise when you encounter it, and also why you can't just work around it by diddling with compiler options. Given that these restrictions were imposed well into the Age of Bloatware, it's hard to know what their devisors were thinking, other than not ahead.
java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#88659

Still, supposedly a committee somewhere is pondering how to deal with this long-standing problem, especially as it affects people like me who aren't directly writing the offending Java, but instead are working in other languages that generate the Java that then can't be compiled. In the meantime, I'm stuck with making apparently nonsensical changes to my code so that the underlying Java generator creates output that the compiler can, in its turn, compile into something that can then be saved into the aforementioned overly-restrictive file format, so that it can eventually be loaded and run.

Running backwards?

Trying to find a workaround for this sent me on a hunt for Java tools, where I came across RetroVue, lauded by father of Java James Gosling as: "a strong opportunity to dramatically improve the software development process."
www.visicomp.com

This tool claims to let you run the clock backwards on your Java application, retracing its steps from "Why did it do that?" to "Oops, looks like we shouldn't have invoked the system.haltAndCatchFire() method."

I'll be interested to see if there is any empirical research on the merits of doing this, especially as a similar feature in a debugger that I worked on in the 1980s was rejected by its users, partly because of the feature's impact on execution speed, and partly because it was so unlike any other tool they had.

Back in the monotonically increasing world, the desire to remove the cruft from software development has produced the Agile Alliance, whose motto seems to be: "lead, follow, or get out of the way."
www.agilealliance.com/home

No doubt their lack of enthusiasm for processes, tools, planning, documentation and contracts will scare the pants off some members of the audience.

Simpler days

My run-in with papered-over Java also had me yearning for the Simpler Days when I didn't have n loosely-coupled technologies between me and the actual computer, where n is too large, and quite possibly fractal. You know, the days when digital watches still had Nixie tube displays:
www.amug.org/~jthomas/watch.html

Apparently, I'm not the only one who thinks this way, and there are still languages being devised that are trying to either reorganise all this surprising complexity, or even side-step it completely:

  • colorForth is a stand-alone redesign of that old favourite minimalist language, Forth, and appears to be an attempt to see how much can be thrown out from programming languages and operating systems while still being able to get anything done:
    www.colorforth.com/cf.html
  • Joy claims to be a pure functional cousin of Forth, and seems to do without such fripperies as named formal parameters to functions, named variables, and infix notation:
    www.latrobe.edu.au/philosophy/phimvt/joy.html
  • And Cow disposes of the programmer in favour of a cow, which is probably going a little too far, at least as far as I'm concerned.
    www.bigzaphod.org/cow

In its favour, Cow's implementation of the stereotypical Fibonacci number generator is quite small:

MoO moO MoO mOo MOO OOM MMM moO moO MMM mOo mOo moO MMM mOo MMM moO moO MOO MOo mOo MoO moO moo mOo mOo moo

Cow probably also sounds better on the radio than the source code to the Linux kernel, presently being broadcast on Free Radio Linux:
radioqualia.va.com.au/freeradiolinux/

If they want to attract non-geeky listeners, I think they need to include fewer network drivers and more racing car drivers. But that's just my taste.

ED: I wonder whether there will be a textbook for Joy called The Joy of Joy.

Getting serious

Still, serious problems need serious languages, and D looks like a serious attempt to take all the good bits from C, C++ and other languages, while leaving out at least some of the horrible nightmares. The approach is driven from experience in writing compilers, and selects or omits features based on what is practical to implement efficiently and correctly, rather than what theoreticians think is neat:
www.digitalmars.com/d

If all this talk of new languages has made you want to remind yourself of the merits of functional programming or the lambda calculus, you'll be pleased to know that the classic MIT textbook Structure and Interpretation of Computer Programs is now available entirely online:
mitpress.mit.edu/sicp/full-text/book/book.html

And if you can't cope with all that LISPy code, you could always consider using Don Knuth's latest pedagogical language, MMIX:
www-cs-faculty.stanford.edu/~knuth/mmix.html

Don explains more about its design here:
technetcast.ddj.com/tnc_program.html?program_id=71

He defends his continuing use of an assembly-level language in The Art of Computer Programming, saying: "People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird."

Finally, if you want to get up to date with trendy application development for the web, look no further than Creating Applications with Mozilla, which is also available entirely online:
books.mozdev.org

Seeking counsel

Until more certified accountants barge their way into the field, meta-level compilation seems like a good way to find bugs in systems that are, quite frankly, too boring for many programmers to look for:
metacomp.stanford.edu

An offshoot from this project is now starting to correllate what might be called sloppy or accidental code features with real defects. It identifies such things as unused variables and code, irrelevant conditionals and other code that pointlessly repeats itself, and finds an increase in the likelihood that bugs are lurking nearby. The premise, which on the face of it seems reasonable, is that these features show that the last person to change the code either didn't understand it well enough to be tidy, or didn't care enough to be:
www.stanford.edu/~engler/p401-xie.ps [.ps]

Of course, optimising compilers have been handling this kind of poor code for a while, but perhaps now instead of Band-aiding the code, the compilers will be stopping and saying: "Oi! Programmer! You clearly don't understand the consequences of what you're doing here!" And the quality of code in the world might be increased by a notch, especially if intermediate code-generators have to output code that is at least average in quality.

If only there were a way to apply such principles to design specifications. If only there were a way to run the clock backwards to when such specifications were being written, for the purposes of strategic strangling. If only there were a computer that doubled as a drinks cabinet. Oh, wait, there is:
www.lpl.arizona.edu/~vance/www/vaxbar.html

Until I'm able to seek counsel for my frustrations from a psychologist for programmers, I guess some beers will have to do.

Frank Wales
frank@limov.com
www.limov.com


Acknowledgements

Many thanks go to Frank Wales for the assistance he has given during the production of this newsletter.

Recent comments

No comments available.