Print

Code Watch: Risky languages



Larry O Brien
Email
February 19, 2013 —  (Page 1 of 3)
In recent columns, I've been talking about language and paradigm selection from the standpoint of the developer. I've pointed out that functional programming techniques are already more widespread than generally acknowledged and predicted that FP will grow in influence. I've also tried to argue that FP has some major drawbacks, such as a lack of great communicators and a willingness to promote silver-bullet thinking, which might keep functional languages from "crossing the chasm" and doom them to remain what they are now: a highly influential niche.

This developer-centric discussion might lead some readers to think that I'm recommending that development teams embrace Haskell, Scala or F#. And while it's true that I think that many developers would enjoy and benefit from learning a more “pure" functional language, and that the benefits (and shortcomings) of a language often only become apparent when solving real-world problems, what's good for an individual developer is not necessarily good for the organization. At the organizational level, I think it's still quite rare for a functional language to be appropriate for core development.

While "write a project using F#, commit it to version control, ask forgiveness" may be an acceptable approach for a few scripts relating to DevOps or system administration, it's most certainly not an appropriate way to approach choosing a programming language for an enterprise system.

Generally, selecting a programming language is one of the riskiest choices that a program manager makes, as it binds the team to a technology environment: vendors, libraries, conferences, educational resources, etc. Selecting a programming paradigm is even more dramatic.

Putting aside for this column the technical and conceptual pluses and minuses, I want to concentrate on the risk aspect. It's been said that the job of software project management is the job of risk management. That goes a little too far, but it has far more than a grain of truth to it. The current vogue in technical project management, driven by Apple's dazzling decade of innovation, elevates vision and execution above all else, and the Devil takes the hindmost. (Or, as Ricky Bobby so eloquently put it, "If you ain't first, you're last.")



Related Search Term(s): DevOps, Haskell, paradigms

Pages 1 2 3 


Share this link: http://sdt.bz/39412
 


Comments


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


close
NEXT ARTICLE
What’s the deal with DevOps?
It’s two worlds joined together, but even though they look the same, they don’t quite mesh without communication Read More...
 
 
 




News on Monday  more>>
Android Developer News  more>>
SharePoint Tech Report  more>>
Big Data TechReport  more>>

   
 
 

 


Download Current Issue
APRIL 2014 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?