Monday, March 31, 2008

C# type inference

While I work mainly in a Java shop, I continue to be impressed by what Anders Hejlsberg, chief architect of C#, brings to the table to a language which in my mind has always represented Java done right. I do wonder however, how come they did not take the concept of type inference just a little bit further.

Local variable type inference
This feature of C# 3.0 basically allows you to omit the declaration which, especially when generics is involved, causes a lot of repetition and long lines of code:



Dictionary<int, IEnumerable<decimal>> myCollection =
new Dictionary<int, IEnumerable<decimal>>();



Which can be reduced to this:


var myCollection = new Dictionary<int, IEnumerable<decimal>>();



No late binding is taking place, the compiler simply infers the actual type and substitutes var with it.

No method return type inference?
Some languages operates with the concept of tuples, a way of returning multiple values without having to wrap them in an array and use casting or a predefined data transfer object. Wouldn't it be nice, if we could use type inference here instead to be able to return multiple values from one invocation - and still be type-safe about the whole thing:


var getInferredType()
{
return new {X = 22, Y = -3};
}

var coordinate = getInferredType();
Console.WriteLine(coordinate.X);
Console.WriteLine(coordinate.Y);



Perhaps this isn't doable for reasons of method signature lookup or polymorphism rules, I don't know. But it strikes me as something that would be very usefull and further reduce the need of temporary housekeeping objects.

Monday, March 10, 2008

Java Puzzler: How low can you go?

Any seasoned Java developer would know of the seminal books Effective Java and Java Puzzlers by Joshua Bloch. The latter covering pitfalls and corner cases of the Java language, listing some 95 different examples of traps to watch out for in your daily work.

Java puzzlers
While a great read for toilet visits, unlike Effective Java, I don't consider Java Puzzlers particularly essential material to know as a developer. Not because there isn't anything to learn, but because there are many other pitfalls of the language not mentioned which you are just as likely to encounter before many of the exotic ones mentioned in the book. I recently ran into another one of this kind, which I will now describe.

How low can you go?
Take a look at the following snippet, which is a more flexible version of Math.max() which tries to find the largest Double in an array:



System.out.println( max(0.0, -1.0, -2.0) );

public static double max(double... candidates)
{
assert(candidates.length > 0);
double knownMaxValue = Double.MIN_VALUE;
for(double candidate : candidates)
if(candidate > knownMaxValue)
knownMaxValue = candidate;
return knownMaxValue;
}



What do you think will be printed to System.out? Hint: No, it doesn't have anything to do with autoboxing this time around. Scroll down to read on...

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Well, I would expect 0.0 to be printed, but instead 4.9E-324 is. That's because Double.MIN_VALUE yields 4.9E-324, the smallest *positive* number. So when we initially assign it to knownMaxValue, thinking it represents the smallest possible value, the net effect is that candidate values less than 0 are not considered at all.
To get the expected behavior, you instead have to initialize with -Double.MAX_VALUE to get the actual smallest number including negative numbers which yields -1.7976931348623157E308.

Justification
You may argue that this is fully specified in the JLS and documented in the JavaDocs, which is true. The JavaDoc for Double states "A constant holding the smallest positive nonzero value of type double". However, I'd consider this to be an extremely easy trap to fall into as it completely defies logic and common sense. Javascript not surprisingly follows the Java definition of Double.MIN_VALUE while more modern languages such as C# defines it the way most people would expect, including negative numbers.

The above puzzler could also have dealt with problems associated with the abnormal signed definition of a java.lang.Byte, or the treacherous scale semantics of a java.math.BigDecimal.equals()or... well you get the idea when I say there are a fair share of puzzlers out there not officially declared so.

Tuesday, March 4, 2008

Gee... Another one?

Hey everyone and no one! Like so many others, I've decided to start my own blog.

Up until now I've just been an avid participant in various forums, blogs and communities with all the problems associated with that. It's my desire with this blog to be able to write my opinions without having to conform to established or expected perspectives which sometimes gets me into trouble.

I will also use the blog as a personal wiki, an institutional memory and a communication medium, which may or may not be of interest to others. The content will probably revolve mostly around software engineering and associated technical issues, but I reserve the right to use it as a venting space for whatever comes to mind.