Print

Code Watch: Here comes functional programming



Larry O Brien
Email
November 11, 2011 —  (Page 1 of 3)
Functional Programming is the Next Big Thing in mainstream development. As I discussed in my previous column, functional programming approaches have slowly become more common in the mainstream, not because programmers have become more interested in Category Theory, but because functional approaches work well with the 21st century's signature advancement in mainstream programming: unit-testing.

But functional programming's further rise is assured by the popularity of C# (whose evolution in recent years has been explicitly influenced by FP); the availability of F# and Scala on the two major VMs; and the prominence of FP in academia (where such mundane questions as syntax, interoperability and learnability are considered "uninteresting"). Functional languages (or, most likely, functional-object hybrid languages) will fill the slot between the browser (where JavaScript is deeply entrenched) and the system (where performance demands and the broad availability of gcc seem to provoke a "better the devil you know" loyalty to C and C++).

In other words, functional programming fits right into the mainstream of corporate development, where legacy codebases are large, programmer productivity must be high across teams with different experience levels, and tooling is important. This is the same place where dynamic languages such as Python and Ruby have been knocking on the door for several years without getting the reception they deserve.

Ruby has certainly crossed the chasm for Web development, and Python has become common in some domains (notably in the field of science), but neither seems to have made deep inroads into general corporate development. One of the major issues in both cases is that neither is native to either .NET's CLR virtual machine or the Java Virtual Machine. While there are ports of the languages onto both the virtual machines, I've become used to hearing library compatibility complaints as an initial response to my questioning if a team has considered them. Whether such compatibility issues would go away with a few hours of configuration tweaking is rarely a conversation that people seem eager to have. F# (in the .NET world) and Scala (on the JVM) don't have to jump through any hoops to use popular libraries. Advantage: native-to-VM languages.



Related Search Term(s): C#, functional programming

Pages 1 2 3 


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


Comments


11/14/2011 09:58:10 PM EST

There is no functional programming bandwagon. Functional programming does sometimes influence mainstream programming. But overall, for more than 50 years, mainstream programmers *always* prefer a non-functional language. If you have tried to write non-academic program in a functional language, you'll know that they present all kinds of hassles when dealing with simple things like files and file systems. These things break the "no side effects" principle of functional programming, a principle that doesn't exist in the real world. Functional programming can be good to simplify really complex problems, such as airline ticket pricing and route planning, but from typical business applications, functional programming is much more difficult than with procedural and object-oriented languages.

United Statesdev danke


11/25/2011 05:51:19 PM EST

"21st century's signature contribution to mainstream prograsmming: unit testing." What? Unit testing has been around forever (or at least for the 40 years I have been in the business).

United StatesMark


12/02/2011 01:41:05 PM EST

@Dev: It seems to me that there _is_ an FP bandwagon: the influence in the .NET world is clear, with LINQ being a prime driver of the evolution of the .NET languages. In the Java world, I feel that there is industry motion towards Scala as the best "next Java." @Mark: Yes, unit-testing has been "around" forever, but it has only become a mainstream development practice in the 00s. In the 90s or before, I would be surprised and happy to find a test-suite embedded in a source-code tarball (especially a _unit_ test suite), today, I would be surprised to check out a new codebase and _not_ find such a suite. The shift in expectations about testing and quality is, to me, the "signature" shift in the programming zeitgeist in the 00s. Unit-testing was downright rare back in the days of statically-linked single-entry-point programs.

United StatesLarry O'Brien


12/02/2011 01:58:00 PM EST

@Dev: As to whether FP is "superior" to OOP when it comes to mainstream enterprise development, or only excels in the algorithmic realms, I think that's a _HUGE_ debate that the industry needs to have. My old construction was "LISP has been touted in academia for 40 years and _everyone_ abandons it when they move into industry. Maybe that has some significance?" But as I've tried to say in these 2 columns, it seems to me that "FP approaches" (state externalized into parameters, functional rather than structural composition, etc.) have become more commonplace for totally pragmatic reasons. I think that has "primed the pump" as it were and I think that FP (an old concept) is about to be discovered anew and everyone's going to shout "silver bullet! silver bullet!" Regrettably, what I can anticipate that if some of us with gray hair say "Well, you know, it's fine, but it's not magic..." we're going to be dismissed as "not getting it."

United StatesLarry O'Brien


close
NEXT ARTICLE
Code Watch: Functional programming: A sequence of FARTS
A new way of looking at functional programming is to break it down into this particular sequence 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?