Skip to main content

Wrapped Up In Books

Posted by editor on February 22, 2008 at 7:30 AM PST

Do you have more comments than code? Should you?

There was a time when I would code by writing method signatures and writing an exhaustive javadoc comment for the method, before committing a line of actual code. It seemed like the "proper" way to do things, and sometimes it really felt like it was, particularly when I was basically doing my design in the form of comments, changing the design when the descriptions revealed holes or flaws in my thinking.

So, why don't I do this anymore?

Popular blogger and Google developer Steve Yegge argues that this kind of behavior is actually a defensive mechanism instinctively employed by intermediate programmers who are afraid of getting in over their head. He makes this case in a new blog, Portrait of a N00b, in which he compares this behavior to the temporal narratives told by young children, like the 2-year-old Emily featured in Malcolm Gladwell's The Tipping Point:

If you look back at the comments in my hypothetical code from 20 years ago, you'll see that I was doing exactly what Emily does: making up a temporal narrative in an attempt to carve out a mental picture of the computation for myself. These stories I told myself were a critical part of my mental development as a programmer. I was a child trying to make sense of a big, scary new world.

Most programmers go through this phase. It's perfectly normal.

So if preemptive commentary is the refuge of newbies, what does the seasoned pro do?

But when I write code in other languages these days, even in Java, it looks a lot more like this Emacs Lisp fragment than like the n00b code I was writing 20 years ago. It's denser: there's less whitespace and far less commenting. Most of the commenting is in the form of doc-comments for automated API-doc extraction. On the whole, my code today is much more compressed.

Steve calls the extraneous commentary metadata, and says that static types and data modeling are all the same thing. They may help organize the code during its creation, but are literally thrown away by runtime.

So what's with the "even in Java" crack? Steve argues that one reason Java is successful is that it is suitable for both the secure and the insecure programmer:

So you can write Java code that's object-oriented but C-like using arrays, vectors, linked lists, hashtables, and a minimal sprinkling of classes. Or you can spend years creating mountains of class hierarchies and volumes of UML in a heroic effort to tell people stories about all the great code you're going to write someday.

So if it sounds like a Java bash, it isn't, at least not necessarily. He ultimately gets to the fact that a large project in Java will ultimately both verbose and terse programmers working on the same code base. What do you do when half the programmers want to slam down code, and the others want to model until the cows come home? Steve argues for a middle way through the madness: developing a sense of when you need static typing, modeling, and commentary, and when you don't.

So, what kind of programmer are you? What would you like to be?

In Java Today,
the Aquarium reports on an Updated OpenDS Roadmap: "Ludo just posted an
OpenDS Roadmap
to the USERS alias.
The latest OpenDS 1.0 builds
b11, etc)
are looking very good, so the plan is for a Milestone 1 within the next few days,
a M2 in a month, and an official 1.0 release in May 2008 -
which, by a coincidence, is also when J1 2008 happens." Recent OpenDS activity includes continued progress on documentation, performance improvements, and more.

Continuing its series of interviews with Java Champions, the SDN has posted an interview with a prominent blogger Cay Horstmann: From Java Platform Improvements to Better Teaching: A Conversation With Java Champion Cay Horstmann. In a wide ranging discussion, he talks about optimization, testing, teaching, JSF, BlueJ, Java 7, and his reservations about the proliferation of scripting languages.

The latest Poll asks "Have you tried Scala?" Cast your vote on the front page, then visit the results page for current tallies and discussion.

Today's Weblogs begins with Terrence Barr's
Report from Barcelona
I did a brief trip to Barcelona, Spain, last week to attend a couple of events: 1. Mobile World Congress (MWC), 2. Mobile Monday Peer Awards, 3. Mobile Jam Session. Considering I was only there for a little more than 48 hours that is probably a packed agenda.

Eamonn McManus answers the question
Do I really need all those jars in my classpath?
"Big applications have a tendency to accumulate enormous classpaths. Looking at such a classpath, you might be hard put to know whether any given jar is really needed. Perhaps it was needed at the time it was added, but that need has long since evaporated. How can you tell? Kyrill Alyoshin has an elegant solution..."

Billy Newport clarifies XTP in
Is XTP about memory based replication? No, and here is why.
"An XTP platform isn't really about accelerating single box throughput, it's about organizing a set of boxes to work together to allow the power of all boxes to be harnessed to collectively run the XTP application."

In today's Forums,
ouq77 reports a growing performance problem in
MIDlet optimization [help needed].
"I'm learning Java and have recently started developing a J2ME project using NetBeans 6.0 with Mobility Pack. My project have been running well on both my phone (Nokia N73) and using the WTK 2.5.2 emulator. The bigger it got, the slower it ran on the phone though. In the emulator, it still runs perfectly. After doing some, what I tought of as, optimization of the code, it now does not want to run on my phone at all. In the emulator, however, it runs perfectly. The reason for this, in my opinion, is that the memory requirements is to big for the phone. I tested it this morning on the Nokia Development site using their Remote Device Access feature and managed to install and run it perfectly on a Nokia N95 8gb, which obviously has tons of RAM available for application excecution."

peppeme wants Toplink not to log exceptions automatically, as explained in
Toplink OptimisticLockException.
"I implement an entity with @Version field in order to abilitate Optimistic Lock. It works, So I can catch OptimisticLockException when it occurs on EntityManager.flush() call. But, the problem is that toplink print into Server Log (Glassfish) Local Stack Exception. I don't want it, because I catch and manage the exception myself. Can I disable this printing, only for OptimistcLockException?"

Sahoo explains an EE classloading concern in
Re: Glassfish classloaders.
"The Java EE spec does *not* mandate class loading isolation among modules of a single ear. The behavior can be different from one appserver to another. So, if you want to be portable, then don't rely on any specific behavior of any appsever. If you want GlassFish to load two copies of the class from two different wars, then try using "class loading delegation feature" in sun-web.xml. The attribute is defined like this..."

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href="">events submission form.
All submissions go through an editorial review before being posted to the

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of it will be
archived along with other past issues in the href=""> Archive.

Do you have more comments than code? Should you?