03/03/2013 07:49:59 AM EST

Much of what you say 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 uninitialzed variables, the correctness afforded by an immutability as a default, corner cases caught by the pattern matching and 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 work colleauges are struggling with a problem that could easily be solved using discriminated unions and pattern matching and then seeing the final result being 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 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 realise is that using a functional first programming language like F# involves a lot more than just lambda functions, with features like immutability by default, elimination of null-reference exceptions, elimination of unitialized 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 conjuction with C# or VB.Net in an enterprise setting would lift the overall reliabilty and robustness of the software produced by a large margin.

AustraliaPatrick