Longer timeouts

The August CACM contains an article “Understanding email interaction increase organizational productivity” (not online) which finds that it takes about a minute to resume work after being interrupted by an email notification. Which is kind of problematic if you set your email to check for new mail every five minutes! So I’ve set my email checking to once every 45 minutes and, even more importantly, I’ve slowed down my news aggregator to… once every six hours. I don’t know if I can handle the information isolation, but I’m going to give it a shot.

J# Skepticism

I’m skeptical about J#. via [Eric.Weblog()]

I’m not. As I say in the current SD Times, the thing about J# is that it serves two very real niches: the bet-hedgers and the Java “pragmatic believers.” Bet-hedgers are those people who have decided not to jump to .NET, but who wish to keep their options open in case the market suddenly shift or if a particular opportunity arises. For those people, the key is maximizing their understanding of the .NET Framework per minute spent and even though it’s only a matter of days for a Java programmer to learn C#, it’s a better option for those people not to learn anything about languages, and just maintain a “bet hedging” knowledge of .NET.

When I say “pragmatic believers” I’m referring to those who fall short of reflexive loathing of all things Redmondian, but who believe that particular Java language features (say, checked exceptions) are important. Those people might eventually move towards a non-Java language, but if it’s not a great burden on MS to support them, why force them to make a decision?

The big challenge is that as the Java language evolves, how much effort will Redmond expend to keep J# in synchrony? Many of the features in the upcoming “Tiger” release of Java are already in C#, so those will be easy. The big question is generics — both C# “Whidbey” and Java “Tiger” will have a C++-derived syntax for generics (Collection<Type>), but early indications are that the underlying implementations will be hugely different. Given how ubiquitous generics will become the instant they become available, this may very well be the spot where J# and Java become eternally incompatible.