Much of what you say (in “Code Watch: Risky languages”) depends on the technology in question. For instance, having used F# for the last couple of years, and having written almost as much code with it as I have using C# at work, I would have no hesitation in deploying it to a production environment. Just think: no null-reference exceptions; no uninitialized variables; the correctness afforded by immutability as a default; corner cases caught by pattern matching; the list goes on.
I do a lot of C# and F# coding, and C# feels very restrictive and primitive in comparison. It can often be frustrating to overhear conversations where colleagues are struggling with a problem that could easily be solved using discriminated unions and pattern matching, and then seeing the final result be overly complicated, prone to null-reference exceptions, and needing too much testing because not enough static guarantees via the type system could be made using C#.
One of the problems in getting F# adopted in a largely C# or VB.NET environment is the general delusion held by many developers that just because the language has lambda functions and LINQ, it means they are already doing functional programming, so there is no need to look further. What they don’t realize is that using a functional programming language like F# involves a lot more than just lambda functions; it also has features like immutability by default, elimination of null-reference exceptions, elimination of uninitialized member variables, discriminated unions, pattern matching, units of measure, and many other features that would be a huge benefit to enterprise software.
The fact of the matter is that using F# in conjunction with C# or VB.NET in an enterprise setting would lift the overall reliability and robustness of the software produced by a large margin.
Patrick
Australia
