That's an excellent observation; I hadn't made the connection before but adapting the stories to the medium is particularly *appropriate* to Tolkien's work.

Sun's been a possible target for takeovers for a while, so I suspect that a big reason for GPL'ed Java and accoutrements was to poison the possibility of just such a move by MS.

Sure, but this is a flaw in the modularity of awt - image processing libraries should not be intertwined with GUI libraries. Instead, the GUI library should depend upon the image processing library, and not vice versa.

The central problem is that Sun has not gone far enough in creating limited profiles of Java - by properly modularizing the core libraries. There is no reason why awt and swing should be part of the minimal core of Java. The same thing can be said for System and perhaps even the threading and socket APIs. If the core of Java was sufficiently modular, then there would be no issues with Google specifying a subset of modules that are supported within their environment.

With any luck, this is something that Project Jigsaw will address - though I dearly wish that Sun had opted to adopt OSGI within the jvm instead of developing their own module system.

The combination of static typing, type inference and concise syntax for higher-order functions give you a lot that Groovy and Java just fall short on.

In Java's case, it's the simple fact that you can't reasonably implement HOF's like filter, map, etc. without using anonymous inner classes. If you use anonymous inner classes, you end up with a ratio of like 8:1 of boilerplate:relvant expressions. Believe me, I've tried it. If you want to see just how baroque it gets, take a look at functionaljava.org.

Groovy has HOF, but it's interpreted and it doesn't have real static types. So it's slower and you don't have nearly as much ability to do compile-time type checking.

Scala rocks. I've been using it for several months now building a $50M/year transaction processing system and I never want to go back to writing regular old Java again.

The problem with allowing null values to propagate into null pointer exceptions is that the exceptions can be unrelated to the point of failure. Say that I have a method that returns a File, or null if that file is not found. If I take the results of that method and store it in an object (or worse, an anonymous inner class closure) that isn't used until later, the resulting NPE cannot be reliably prevented unless every use of the . If the method returns an Option instead, I have to explicitly deal with the failure case at the point in program flow where the method returns. This is particularly useful when it's possible to specify a reasonable default.

To be clear, it's not that replacing null with an Option allows you to do anything that you couldn't otherwise do by checking for a null return type - it just means that the compiler forces you to think about what the behavior should be if no sensible result is returned. In an ordinary Java program, you're never quite sure which methods might return null, so the only way to be perfectly safe is to check the return value of every method call. This extra boilerplate makes code hideous. If, on the other hand, a library never returns null, then you can safely skip the null check and use the powerful features provided by Option to deal with missing results wherever they might be returned - and the compiler will force you to do so.

The line between when to throw a checked exception and when to return an Option is a bit blurry; in general I use exceptions to indicate unexpected failure, and Option for situations where a missing return value might be expected. A classic example of an appropriate use of Option would be looking up a value from a Map - of course, the Java Map interface specifies a return value of null for when a key isn't found, but a more sophisticated Map interface that returns Option (such as the one in Scala) makes for much cleaner program flow. In the following, assume that baz is a method that may also return no result (null in the first case, Option in the second.) Compare:

//java
Map m = ...
String foo = m.get("bar")
if (foo == null) {
    return "gweep";
}

String bazed = baz(foo);
if (bazed == null) {
    return "gweep";
} else {
    return bazed;
}

//scala
val m : Map[String,String] = ...
return m.get("bar").flatMap(baz(_)).getOrElse("gweep")

Well, at least if I return a type that explicitly requires you to extract the data that you want from it, it is clear that the possibility of not returning data exists. If I simply returned null, there would be no way that the function signature would indicate this, and hence it's much more likely to go unchecked.

Checked exceptions are in my mind a different sort of beast, since they circumvent the normal program flow. If I call a function returning Option, I can immediately bind it to another function returning Option and evaluate the result in one place. As part of this, I can provide sensible default values at any point along the chain. Exception handling is usually not nearly so clean.

I agree that eliminating the use of null altogether would be a great deal better - my original post was simply pointing out a good way to do so in programs that people are writing today, without waiting for the compiler writers to catch up (and without the endless hand-wringing that would occur were they actually to eliminate null.)

If they're not a developer at my company, that's not my problem.

If somebody in my company using my code isn't willing to do their job properly and handle failure cases, that's great. My boss will be happy to fire them and find a replacement, and we'll all be better off as a result.

Hey, yeah! Let's go back to 1970!

I much prefer to write as many parts of my program as pure functions as possible. If null is one language hole that caused a billion errors, mutable variables in places that they shouldn't be (i.e. just about anywhere that's not related to IO) have probably caused 10x that number of problems. Functions that mutate their arguments in-place are EVIL.

If you use a sane class for references that could possibly be null (like Option (aka Maybe in haskell) then your compiler will *force* you to handle the null case.

This is where null went wrong, at least in statically typed languages: it's a hole in the type system that errors fall through into your program. When coding in Java, I make an explicit point to never return null from a method; if I have a situation where no reasonable return value might exist, I use the Option class from functionaljava.org and thus force the client to handle the possibility of the method not returning sensible data. Since Option obeys the monad laws, it's easy to chain together multiple things that might fail (with the bind or flatMap operations.)

And repealing the 17th would be portrayed by the media as a bad thing were such a movement to gain any momentum. That is because the media is now and always has been positively allergic to nuance.

News is important, but I have yet to figure out any model for news delivery under which news organizations do not become despicable.

There's one application where VOIP is significantly preferable to the standard cellular network: international calling. I can use a VOIP app to talk to my cousins in Australia for free; being able to walk around my house or sit at the local coffeeshop while doing so would be nice.

This isn't about style; it's about adding functionality to a nice little piece of hardware. My cell phone's practically an antique at this point, but I have no need to upgrade it because I don't talk on the phone much. My iPod is a great PDA; adding VOIP capability would just be icing on the cake.

Mercurachrome? I remember that stuff. Liquid fire that didn't seem to do a damn thing to help wound healing. I didn't realize it had been banned, though.

Maybe it was the playground lobby that got that through? I know I would have signed on to a ban when I was five.

I live in Colorado, so I'm familiar with the sorts of conditions you're talking about. I guess that I'm used enough to lousy driving conditions and rapid changes in weather that they don't bother me; I keep a lightweight shell with me in case of unpleasantness.

If the weather is so severe as to make travel dangerous, it's usually pretty obvious as it's happening. I'll look at a weather report before I head into the mountains, but that's about it.

Which is obviously critically important, because there's so much that they can do about it.

Honestly, I don't get what the big deal about TV weather reports is. I don't watch TV, so I see what the weather is like when I look out the window in the morning. This has never proved to be a problem.