Chet Haase's Blog

August 2007 Archives

Code Complete Nonsense: More Language Proposals

There's been a lot of talk recently about the various language proposals that people have made, or debated, or agree with, or detest more than their mother using spit to wipe something off their mouth when they were kids. But I think that some very important language features have been under-represented in all of the discussion, and I'd like to make sure that they make it into the language change death match.

Here are my pet language proposals. You may recognize some of these as features from other languages whose absence from Java has long been a mystery.

Line Numbers

How many times have you wanted to refer to a line or block of code, in a presentation or a review, or just a conversation in a bar (otherwise known as a "pickup line"), and you end up saying something like: "in the line that starts with "if (ventedCelebrium == MAX_VENTAL_SIZE)" or "in the for() loop ... no, the other for() loop ... no, the one before that, right after the call to the creakleFrantic() method"?

Isn't it time that we had line numbers in Java? Then you could simply say, "On line 42" or "in lines 8709-8752" and be done with it.

Obviously, time has moved on since line numbers were first used in other computer languages, back in the 16th century or so, and we're all a lot smarter now. So I would like to propose a small tweak to this proposal and demand that the line numbers be in floating-point units. Besides having all of the additional power of floating-point processing over the more typical, and therefore much dumber, integers, think of the utility of being able to insert code without changing the surrounding line numbers.  Imagine:

Original:

1    for (int i = 0; i < 100; ++i) {
2 	 System.out.println("fart");
3    }

Improved:

1    for (int i = 0; i < 100; ++i) {
2        System.out.println("fart");
2.5      System.out.println("Oops!      Excuse me!"); 
3    }

An alternate proposal on the table is to allow imaginary numbers as well, but I find that idea irrational.

Goto considered harmless

Once we have line numbers, it's an obvious step to go ahead and shovel in the keyword "goto", which has been waiting in the wings lo these many years, like the scrawny, bespectacled youth waiting to be picked for a kickball team. After all, wouldn't we goto justification;

justification:

  love to have teleportation in our own lives?  Why should we deny our code that very capability when it's just lying there like a goto metaphor;

metaphor:

  Twinkie under the bleachers, waiting for us to pick it up and cram it in our mouths? goto end;

end:

Line Spacing

Whatever happened to that great capability in older languages of having meaning embedded in the spaces? You couldn't just type code willy-nilly wherever you wanted, but instead had to start the code in certain columns. Sure, we get this fantastic capability from Makefiles, but today's make systems are hidden behind IDE interfaces, and we rarely get to work directly with the beauty and elegance of Makefile directly.

Isn't the significance of space just a metaphor for life (at least when you're brain is chemically altered) where it's really the space and silence that count the most?  It's the silence in scary movies that really build the suspense. It's the quiet times that you spend with your kids that make you forget the screaming matches. It's the geographical space between relatives that makes family relationships function at all. And it's the space characters in code that really give the code meaning and quality.

I would like to introduce column significance into Java, and make us all think more about where we put our code. I've had enough of the code style wars of indentation amounts, tabs-vs-spaces, and wide-vs-narrow line lengths. Let's start enforcing code style by making the compiler puke when it finds code in the wrong place.

Capital Idea

Have you ever noticed when you get an email from someone in ALL CAPITAL LETTERS that the case actually changes the way you interpret the information? For one thing, you feel confident that the sender is an idiot who isn't aware of the caps-lock key. But more importantly, you feel as though they are SHOUTING AT YOU through the computer (a real need in society which has since been addressed by Skype).

I think that the code that we write is cool enough, powerful enough, and significant enough that it should be screaming itself at the readers. How else will they understand how awesome the code is?  Did Martin Luther King just casually mention "Oh, by the way, I have a dream" to whoever happened to be nearby? No: he used a microphone to proclaim this great speech to as wide an audience as possible. Did Black Sabbath speak their lyrics to the audience, like a folk singing group in a coffee shop? Of course not: they screamed them out through bat entrails to an audience so deaf from the amplifiers that nothing less than an ear-splitting banshee wail would penetrate the din. Did Prince Charles proclaim his love for Camilla in a quiet manner, over a private telephone call? Actually, yes: it was the press that illegally tapped the call and then relayed the sordid content through huge headlines, in a way that only the British tabloids could do.

Of course, we are free use capital letters in our code today. But this approach is mixed at best, with various keywords expected in lower case and a lack of convention and consistency defeating the system overall. We need compiler-enforced capitalization to make sure that our code intention comes through LOUD AND CLEAR.

break;

There are many more classic language features out there, dying to resurface in a modern language. They worked well for previous generations of programmers, I'm sure they would work for us too. Ignoring all of these features would be a sin tax.

Another Chetcast

JavaWorld just posted it's first Java Technology Insider podcast with yours truly.

Daniel Steinberg sat down with me at OSCON and we talked about Swing, 2D, and the present and future of Java Desktop technologies. The book may possibly have come up too, I can't quite recall.

By the way, after the discussion in the comments about podcasts on an earlier blog posting, I decided that, in fact, podcasts in the gym completely rock. It's a good way to hear something that you might not otherwise have time to squeeze into that busy day. (I'll let you decide whether this podcast suits you; I aim for other, more intellectual podcasts, like "Wait, Wait, Don't Tell Me" and "The Onion Radio News.")

Done? Done. It's Here

We're finally, actually done. The book exists, in hardcopy form. Romain and I received our advance copies yesterday. The rest will arrive in the warehouse in the next few days, so Amazon's August 17th date is probably pretty accurate.

I thought it would be useful to compare the book to other books that readers might know. Comparing it in text or concept would be way too time-consuming and tedious. Besides, it's a graphics book. So I took a picture:

We can see, from the picture, how Filthy Rich Clients compares to other important books. For example, the book is much smaller and less significant than Edward Gorey's Amphigorey Too anthology, yet it offers far more than the classic Beyond the Far Side. It is somewhat less weighty than some of my favorite graphics books, Computer Graphics: Principles and Practice" and Graphics Gems II, but is of a similar height to the last Harry Potter book. It is quite close in height to Effective Java, although considerably longer and therefore deeper (Josh obviously needed more screenshots in his book). Finally, it is significantly larger and more weighty than the series of classic child and adult novels toward the right.

Hopefully this gives you a good sense for whether the book will suit your needs.

This work is licensed under a Creative Commons License.