The pitch line goes like this: "F# was supposed to free us of the unchecked null. Alas not only does it not do that, it introduces several more kinds of null." Or so Mr. Jonathan Allen says.
Whaaaa... WTF? This was something my own evaluation of F# did not turn up. Since this is the first written piece of its kind, I take it that this is a fairly original discovery. Jonathan Allen explains that in F# you can have a:
- NullReferenceException
- A Nullable Structure which will throw an InvalidOperationException if you hit it
- If you use an OptionType to handle problem one, you get two possible exceptions. Passing None to the OptionType will once again throw the InvalidOperationException later. If you pass Some(null) to the OptionType, you will get a NullReferenceExpcetion. Ergo this is not a way out. You only defer the error to a later moment.
- You can nest OptionTypes within OptionTypes. Ergo there is not the possibility of a tripple null exception condition. You won't like that.
Allen indicates that this does not happen often when you use native (exclusive and specific) F# types. These are the OCaml baggage types I mentioned in a previous blog. These problems are specific to CLR/CLS/CTS datatypes.
Jonathan does not go on to spell out the implications. He presumes that you can grasp that for yourself, if you are a competent programmer. He doesn't want to say its big because some Schill will come along and say he is being childish and lazy. "Of course this is easy to handle..." or so they say.
You not only have to write the same old code to handle all scenarios, you must write new handlers to handle more scenarios. BANG! I said it.
Folks, the implications are staggering. This means F# is poorly adapted for life in the .NET ecosystem. Its very nature and structure make more and new types of problems possible which did not exit before. Use F# types and you are fine. Interop with CTS types, and now you have more possible errors.
I am still sure you can make use of F#. I am now sure it is extra work with extra gotchas. This extra effort with extra problems at the core CTS level almost automatically relegates F# to life as a niche language, used only when you have to use it. It will not be used as a general purpose replacement for C# or VB.NET. Just a few little potholes in the road of full CTS compatibility constitutes a pretty nasty fly in the ointment. Now we have to start thinking about using the dreaded Interop word.
I am interested in hearing a rebuttal from Don Syme. Perhaps there is an easy pattern function that can be called all the time to deal with these issues. Perhaps that won't be a performance shredder. Perhaps it can be dealt with.
I dunno. It seems that Mr. Allen has discovered one of those bad welding points we have been speculating about for two years now. For about two years now, experts on the .NET platform have been wondering how Microsoft planned to graft a Functional language into the OOPS ecosystem of .NET. We have known that the Functional paradigm is extremely different from the OOPs paradigm. We have suspected that it was going to be difficult to make oil and water mix.
Others have tried. There was a Haskell.NET once upon a time. Others have failed. Haskell.NET is basically a dead letter. Microsoft insisted that OCaml was the proper catalyst agent that would allow .NET OOPs and Functionalism to mix smoothly. As I stated once before, I am not all that impressed by the OOPs of OCaml. I suspected there would have to be some significant adjustments.
Many types of Null is not a good idea. As a certain Italian C# architect has said in many video PodCasts "There is something unpleasing about this code." Luca is currently at work on an Agent framework for F#.
You see... I told you so. Scala has the upper hand. It seems to me that Dr. Odersky has found a much more perfect blend of OOPS and Functionalism than OCaml. Odersky was honest when he said he would be using OCaml himself if he thought it was the perfect blend of OOPs and Functionalism. There are imperfections in the OOPS model of OCaml. The adjustments made to OCaml in the F# language were not quite adequate to make for perfectly smooth blending with the .NET CLR/CLS/CTS.
This is not good news for Microsoft. I hate to tell my buddies this--and I do have buddies in Redmond--but the way you start is the way you'll finished. When F# goes gold in Visual Studio 2010, that first experience with F# 2010 will be most programmers' golden first impression of the language. A few potholes with the CTS, just a few violations of expectation, and they will say "Ah screw it! I'll play with this toy some other day. It's not something I can use."
This is how things get relegated to the waste bin of history.
On the other hand, Scala does blend perfectly with the JEE... as far as I can tell. So far I have read no published complaints.
