Sunday, 20 April 2008

Who will use F#?

This post is in response to the comment by Fernando on the previous post. Many of the statements made by Fernando reflect commonly held views but I believe the foundation (e.g. FP vs OO) is too simplistic to be an accurate predictor of what is to come.

I take issue with several of the points that you have raised, Fernando. I'll start with the ones where I can provide objective evidence rather than just opinion.

You say that "F# will be adopted by long-time functional programmers, with LISP/Haskell heritage" but Lisp/Scheme and Haskell programmers account for only 5% of our F#.NET Journal registrants whereas C#/C++/Java programmers account for 53%. The reason is that functional programmers very rarely migrate between functional languages because they are so different (e.g. Lisp vs Haskell is like C++ vs Ruby). People learning any given functional language are always predominantly from mainstream backgrounds. Moreover, the prospect of commercialization makes F# alluring and that is irrelevant for academics happily using Lisp or Haskell. I believe F# will be adopted primarily by startup companies composed of small groups of talented programmers attacking hard problems who realise that the productivity of this language gives them serious advantages over the competition.

Your statements about C# adopting functional features are correct but then you say "Granted, the C# or VB implementations are not as elegant or pure as the F# counterparts, but the features are there". That is very misleading because the features responsible for F#'s awesome productivity are certainly not there in C# and VB. I'm talking about extensive type inference with automatic generalization and pattern matching over algebraic data types, both of which underpin the productivity of all MLs including OCaml and F#. Microsoft have not even begun trying to figure out how to add these features to C# and, until they do, C# will remain in a league below F# in terms of productivity and cost effectiveness.

Now for my subjective opinions. If it were possible to have a "one size fits all" language then I think programming language researchers would already have invented it. After all, they have complete freedom to do so: their results do not even have to be practically useful or adopted. However, I believe the different programming paradigms are at odds by design and, consequently, this is a strictly either-or situation. For example, using overloading undermines type inference. This is why overloading requires type annotations for disambiguation in F#. Many other languages lie at different points along the FP-OO curve. OCaml is closer to FP and Scala is closer to OO, but F# is the only language to have ever brought the productivity of OCaml to a mainstream industrial platform like .NET. Scala does a slightly better job with respect to OO but only at the cost of a catastrophic loss in terms of productivity due to its lack of automatic generalization.

In summary, I think you are overestimating the amount of cross-pollination that will occur between languages and underestimating the amount of programmer migration that will occur.

6 comments:

fernandoronci said...

Thanks !

You're far better prepared than me to make an educated opinion on these things. I really appreciate your reply.

As a matter of fact I'd love to have the time to learn F#, but I don't have it. So I'll stick with C# and learn Functional concepts in slow motion for the time being. I'm not even done learning C#, btw.

I sense cross-pollination is happening at a fast rate. To put it very succinctly, it seems as if the developer division at Microsoft has meticulously categorized the good, the bad, the ugly/obscure/painful characteristics of every programming paradigm throughout the last decades and started porting only "the good" to C# and VB.NET. But that's only my perception. Of course, decisions will have to be made in the process (like your point on leaning on the FP or the OOP side - OCaml vs. Scala). Community feedback will be key, I think.

Thanks,
Fernando

S9 said...

I tend to agree with your blog. However historically companies never stick with the 'one size' fits all approach.

Especially company's that use both Unix and Windows systems daily in their development and production systems.

devonianfarm said...

Personally I'm excited about F#.

I've wanted to use oCaml for some years now, but every time I start a project, I realize that libraries don't exist in oCaml to do the stuff I have to do.

oCaml might speed up writing the 'meat' of my code, but i'd spend times that reimplementing simple library functions that I take for granted in PHP, Perl, Java or C#.

F# has access to all the stuff in the .net framework, plus all the classes people have written for .net, so it just might take functional programming mainstream.

Chris Vaughan said...

I'm pretty new to functional programming, and so far I don't see anything to make me believe it's more productive than C# or even C++.

I could see how a small shop (1 or 2 developers) could turn out more code quicker using this language, but surely when you factor in the full SDLC, the amount of time saved by not needing to specify types is minor. In addition, while I see the advantage on the front end, I shudder to think of the cost of maintaining this codebase. Maintenance is our single biggest expense as a shop, and I'm sure that's not a unique experience.

Wouldn't the cryptic nature of F# encourage the production of more obtuse code? In my opinion, that can't be seen as a good thing.

Am I wrong?

Curt Sampson said...

I have extensive experience with Java and Ruby. We've been building a fairly major project (an automated options trading system) in Haskell over the last year, and it's certainly been more productive for us, particularly when it comes to maintenance. The main reason for this is that we produce a lot less code: it takes hundreds of lines of Java to do what I can do in a few dozen lines of Haskell.

That you find F# code "cryptic" is almost certainly just due to lack of experience; spend more time reading and writing it and you'll come to find it quite comfortable and clean. It's just something very different that you're not yet used to.

I still find good Lisp or Scheme code "cryptic," myself; it takes me a long time (relative to how quickly I can read Haskell) to understand exactly what it's doing. But that's because I've done little Lisp or Scheme programming beyond working through _The Little Schemer_, not because the code is inherently cryptic.

Flying Frog Consultancy Ltd. said...

@Chris

Is F# more productive than C#? Yes, absolutely. For example, our F# for Numerics product just translated 10,000 lines of numerical code written in C# into only 100 lines of F# code that is faster. In that case, the reason was that F# provides structurally-typed inlined higher-order functions that can be used to heavily factor code without sacrificing any performance at all. Now we have 100× less code to maintain which, of course, makes us vastly more productive.

Also, F# is far from "cryptic". Indeed, the fact that F# is so much more concise really highlights the fact that it is much easier to assimilate a small amount of F# code than the vast amount of equivalent C# code.

By my estimates, F# is around 10× more cost effective than C# on average in the context of numerical and graphical applications.