.Net was Microsoft’s answer to Java. Java promised a single language that could target multiple platforms. .Net offered multiple languages that targeted Windows. Back then that meant C#, VB.Net and C++/CLI,
Things have moved on for both VMs, the JVM now has a plethora of languages like Groovy, Clojure and Scala. Meanwhile .Net code has become cross platform via Mono, in fact C# and F# now have arguably offer a better story for iOS than Java. For iOS, Xamarin compiles C# and F# code to native ARM binaries.
Both VMs have been hugely successful and have seen a wealth of libraries and frameworks built on them, allowing them to interoperate with a vast array of software and devices. This makes languages built on these VMs compelling as you don’t need throw away existing enterprise investments and build everything again from scratch.
Progress on the Java programming language has been slow, which has in part helped accelerate the adoption of new functional-first languages like Clojure and Scala. Java will be the last mainstream programming language to add lambdas when Java 8 is released potentially in March 2014.
Question marks have also been hanging over Java’s open source credentials since Oracle’s acquisition of Sun. Back in March 2012, Thoughtworks put the Future of Java in the Assess ring of their Technology Radar.
That said in London at least the Java community seems to be strong in numbers with over 3,500 members in the LJC meetup compared to just over 400 for the London .Net meetup.
C#, VB.Net and C++/CLI all share similar features and so the vast majority of developers have converged over time on the C# programming language.
The dynamic CLR languages IronPython and IronRuby have lost much of their momentum and Nemerle seems to have been subsumed by JetBrains for N2.
That really just leaves F# under active development, built-in to both Visual Studio and Xamarin Studio, it uses the same compiler as F# is open source under Apache 2.0.
On .Net, the C# programming language has seen a little more innovation than Java, adding rudimentary functional programming constructs in C# 3 for LINQ like lambdas and extension methods for expressing higher-order functions.
Progress in C# 4 and 5 has been lacklustre since Microsoft departed on a rewrite of the compiler in C#, a closed source project called Rosyln, which is yet to surface.
In C# 4 the focus was on dynamic support, where the main new feature in C# 5 was async, a feature introduced in F# in 2007.
In the enterprise one of the biggest threats to .Net code bases is migration to Linux, for which outside of Mono there is no .Net story. Xamarin, key contributors to Mono, are overwhelmingly focused on mobile. Recent improvements in Mono, particularly in garbage collection, I feel make it a viable server-side platform, but it currently lacks the support and investment seen on the JVM.
As large enterprises continue to look for cost savings, I suspect more .Net share could be lost to switches to Linux. Lower operating costs combined with the promise of higher productivity with powerful functional-first languages like Clojure and Scala, are hard for IT managers to ignore. Nowadays many finance companies use the JVM on the server-side and reserve .Net, specifically WPF, solely for their front-end applications.
I’d like to see Microsoft join forces with Xamarin to deliver a well supported server-side platform with Mono for C# and F# on Linux, to compete directly with Clojure and Scala. That also means .Net open source authors should be supporting Mono deployments too.
The promise of polyglot programming on .Net, where you pick appropriate languages for specific tasks, now rests primarily with familiar C# and functional-first F#.
As C# and F# are statically typed languages on .Net, interop between them is seamless. Both languages also offer bridges to external libraries via C APIs with P/Invoke. F# also offers rich interop to data sources and programming languages on other platforms via Type Providers.
With F# Type Providers you can interact with languages like R, MATLAB and TypeScript and their rich libraries with intellisense support in your editor. Type Providers are a real enabler for true polyglot programming.
The combination of C# with it’s familiar syntax and object-oriented constructs with F# and it’s functional-first constructs and type providers, in my opinion, offers arguably the most powerful and productive programming environment currently available.
In the same Thoughtworks Technlogy Radar that questions the Future of Java, they had this to say on F# and C#:
F# is excellent at concisely expressing business and domain logic. Developers trying to achieve explicit business logic within an application
may opt to express their domain in F# with the majority of plumbing code in C#.
I’m seeing more and more .Net shops adopt F# alongside C#, take for example Kaggle a data science consultancy based in San Francisco:
At Kaggle we initially chose F# for our core data analysis algorithms because of its expressiveness. We’ve been so happy with the choice that we’ve found ourselves moving more and more of our application out of C# and into F#. The F# code is consistently shorter, easier to read, easier to refactor, and, because of the strong typing, contains far fewer bugs.
As our data analysis tools have developed, we’ve seen domain-specific constructs emerge very naturally; as our codebase gets larger, we become more productive.
The fact that F# targets the CLR was also critical - even though we have a large existing code base in C#, getting started with F# was an easy decision because we knew we could use new modules right away.
The point here is not to throw the baby out with the bath water and rewrite your entire solution in a new language, instead leverage your existing investments and use the right tool for the job on new features.
Functional programming has permeated the majority of mainstream programming languages, and is gaining increasing mind share. Here’s a nice slide from Grant Crafton’s recent session on functional programming at DDD North:
It’s clear to me that many of the original protagonists of object-oriented programming are migrating towards functional. Recently I met Eric Evans, author of Domain Driven Design, in New York who spoke at length on how he’d gone all-in on functional.
At conferences like Strangeloop, I’d go as far as saying this is a done deal, very few people are talking about OOP anymore.
There’s been quite a lot of FUD around functional programming being hard to learn. In general people encounter two initial speed bumps:
- Unfamiliar syntax
Neither of these speed bumps are insurmountable, otherwise there wouldn’t be such a large number of developers turning to functional languages.
Lack of familiarity with syntax can be overcome with just a few hours of immersion. For F# I’d recommend the F# Koans to guide you through the language syntax step-by-step and a Cheat Sheet to lookup common operations as you code. F#’s syntax is based on the ML programming language, once you’ve got the hang of it you’ll be able to read a host of other ML based languages like Erlang and Haskell.
Unlearning tends to take longer than learning, so unfortunately if you’ve been programming in an imperative or object-oriented style for a long time, it will be slightly harder to pick up functional programming. That it to say learning functional programming is not inherently hard, just that thinking differently can take some time. I’d recommend tackling short programming exercises like Code Katas or Project Euler problems to break the back of it.
Be patient, once you’re over the hump you could find the experience fun and rewarding: