Linkstew

Now don't get me wrong: Java's stack traces are really useful, and I'd far rather see something like

Exception in thread "main" java.lang.NullPointerException
        at Shuffles.main(Shuffles.java:18)

than see something like

Segmentation Fault (core dumped)

But it's just the "Segmentation Fault" half that sucks. The "core dumped" half, on the other hand, is something I really wish java would do. Just finding a stack trace in the logs tells me where something went wrong, but when you have innumerable combinations of clicks and data, "where" isn't always good enough. Without some extra information about what data caused the exception, sometimes it can be really damn hard to fix.

Ideally, java would be able to print a stack trace and dump core. If the problem the stack trace pointed at wasn't glaringly obvious (which it is, most of the time), then I could load up the core and figure out what exactly about the data was bad, and attempt to determine if it was just some transient error (which it seems to be, more often than not). It seems like java's reflection or serialization abilities are powerful enough that it could dump a lot of state information (and call it "core") and allow you to poke at it later. But it just doesn't seem like something anyone realizes they could use.

I can't even put into words how crazy it makes me that java doesn't require { }'s around its control blocks.

if ( bool )
     if ( bool2) 
          something();
     else 
          somethingelse();
else
     shootme();

That's completely valid and perfectly awful in java. I'm regularly looking at a lot of new java code at work, and every time I come across that it takes me a few extra seconds to read it. And the people who wrote the code seem awfully fond of that six-character saving construction. They also don't always indent it usefully, so I frequently find myself reading the wrong else at first glance. Also, without the { }'s, how is my editor supposed to highlight the matching curly to help me see where a block is?

While I completely understand the argument that control structures take a single statement, and a single statement can either be a semicolon terminated line or a block containing multiple statements, that doesn't make it right. Look how much easier this is to read:

if ( bool ) {
     if ( bool2) {
          something();
     } else { 
          somethingelse();
     }
} else { 
     shootme();
}

Arguably, the problem I'm having is actually that people just didn't indent their code well, and not that they didn't use curlies. Python doesn't require curlies, and its control structures tend to be reasonable readable thanks to forced indentation. While Java never could have gotten away with adding forced indentation (very few C programmers ever would have tried java in the first place, then), it probably could have gotten away with requiring curlies, and that would have helped enforce a little extra readability.

I'm so glad perl requires { }'s in that context. Perl's something() if bool; construction is also pretty kickass, and much better thanks to its lack of an "else." But then again, perl also has elsif, which is a fairly questionable design decision in the control structure domain.

Since I've been using java at work, I've been having some serious problems with semicolons; I'm pretty sure I've had more errors thanks to unterminated statements than anything else.

Hans's Top Ten JSP Tips

In particular, the first sentence of item 7 and the first sentence of the third paragraph of point 9 are particularly salient for me, because those are exactly what I've been dealing with lately.

But JSP aside, "Don't put SQL in the scrip / modularize all of your database calls" seems so obvious to me that it might as well be Databases 101. Sigh.

Only if your time is free...

Possibly being faced with the very issue of potentially having to buy my own IDE when my one month IDEA trial expires, I found this meta-article short on useful information, but close to home none-the-less.

Productive [Java development] Environments

Having just started a new java programming job, I found this pretty handy, even if I didn't end up using the author's preferred Eclipse. Instead, I find IDEA to be an IDE much more to my liking.

Java theory and practice: Urban performance legends

Yes, this is yet another slashdot repost, but I liked the premise of this article. It makes me wonder what urban performance legends other programming languages suffer from.

I just read this article about New Language Features for Ease of Development in the Java 2 Platform (which I found through Slashdot), and it sounds like they're addressing many of the things that drive me crazy when I have to crawl out of my perl shell and use java. In particular, the enhanced for loop and the autoboxing/unboxing sound pretty fantastic. Actually, it looks like the generics are going to cut out quite a lot of monotony, too.

Then again, now that I finally taught myself some Objective C/Cocoa last night, hopefully I'll be programming with that a lot more. I've already written one little app that still needs some work, but I might release it soon.

As I write this, it's 0610 on Saturday morning. I've been up for the last 6 hours. Before that, I slept for 6 hours, and was up for a significant amount of time. For the last three days, I've been awake to see the sunrise. My sleeping schedule is so skewed right now that it'll take me a couple of days to get it back where it should be, but at least that pesky 61b project is done.

Once I got past the first couple of hurdles in this project, I found it to be neat, and I will probably make the source available on the page after the semester is over. The program itself is an Appointment Manager, which means there are a lot of little details involving mainly Dates that have to be addressed, but there were a lot of other details, too. I had to write a file parser for a file that may or may not be in the correct form, which is something I got some practice doing with blackbox, but which was still painful. I had to sort Appointments, I had to iterate over everything imaginable, and I had to code incredibly fast. I banged out around 2000 lines of code in less than 48 hours, which all worked, and which has no major bugs that I've found.

However, I'm sick of Java's Enumeration Interface. Don't get me wrong, I love Enumerations and they make all kinds of otherwise complicated code very simple, but I wrote so many blocks of code like :

   Enumeration en = myVector.elements();
   while ( en.hasMoreElements() )
   {
      SomeObject sobj = (SomeObject)en.nextElement();
      sobj.process();
   }

for this project and Project 3 that I'm sick of typing hasMoreElements() and nextElement(). Eh, it's a minor complaint, I know, but it's still one of those things you end up loving to hate.