Bad news about F#

Just came across an article on InfoQ.com which I found disturbing. InfoQ.com is one of the very best sites on the web for programmers... any kind of programmer. They don't always get it right, and there are exotic opinions here and there, but they are usually pretty damn good and informative. Ergo, I take this negative piece seriously.

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:

1. NullReferenceException
2. A Nullable Structure which will throw an InvalidOperationException if you hit it
3. 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.
4. 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.

C is going the way of Assembler

http://stackoverflow.com/questions/783238/why-windows-7-isnt-written-in-c-closed

So, a kid just popped up on StackOverflow.com and asked the question “Why isn’t Windows-7 written in C#?” All of the C/C++ programmers on the form blanched at the thought of it. Many others posted about project Singularity, which is a research project inside Microsoft aimed at producing a full operating system in managed code. The comments from the C/C++ guys clearly indicate that they hate the entire idea of Singularity.

The question was closed by one of the forum moderators as “Not a real question”. If he had been honest, he would have said he was shutting down a potential flame war. The question is too politically hot right now.

This is a further evidence that the C/C++ programmers are getting pretty edgy about the incursion of .NET and managed code into sacred ground reserved for them, and them only. They have already lost nearly all of their Windows application turf to .NET, and they are still smoldering about that. Like American Indians on shrinking reservations, they are under presure, and they feel it. They are feeling some real job security stress right now. Every time these questions come up, they C/C++ programmers on the site get pretty dang edgy.

Let’s face it folks: C is going the way of Assembler. It is the expressed wish of the supreme management at Microsoft and SUSE to write as much of their operating system in managed code as possible. Inteface widgets, control pannel utils, little apps, system services, you name it: If there isn't compelling reason to go C, it should be done in C#. C/C++ are increasingly seen as costly and yeilding no real substantive benefits anymore.