Tuesday, 15 May 2007

Who wants F#?

We've been looking at data submitted by readers registering interest in the F#.NET Journal:


The two most popular languages cited are C# and C++. No surprise there, perhaps. The C++ programmers are probably interested in learning something higher-level, with garbage collection and so forth. The C# programmers might be interested in leveraging F# for its integral support for interactivity, built-in numerical types, type inference and (more recently) beautiful support for asynchronous programming.

However, the next most popular language for people wanting to learn F# is Lisp. We found that quite surprising, for one because we didn't realise so many people knew Lisp. These guys are probably yearning for pattern matching, better performance, .NET interoperability and the elimination of run-time errors.

Of the submissions, around half cited performance critical applications as their domain. Compilation to native code is a major benefit here but F# also provides easy interoperability with native-code libraries like LAPACK and FFTW, some superb numerical libraries for .NET like the Extreme Optimization library from Numeric Edge as well as some wierd and wonderful options like compilation of F# to GPU using Accelerator.

Overall, the stage looks set for F# to make a serious impact on the way scientific computing is done, with a bewildering array of exciting projects in all of the major disciplines of science and engineering. Sounds like everyone wants F#.


Anonymous said...

What happens when MS sues somebody who uses F# to write an open source application?

Jon Harrop said...

You are free to write both open and closed source applications in F#.

Anonymous said...
This comment has been removed by a blog administrator.
Anonymous said...

"These guys are probably yearning for pattern matching, better performance, .NET interoperability and the elimination of run-time errors."

Have you EVER used Lisp?
1) The most popular Lisp implementations include regexp, or you can get libraries.
2) Are you kidding me? Modern Lisp environments compile Lisp code to native instructions. On average good Lisp code runs as fast as Java code. I bet you that a slower than C# language is no match.
3) Could be, but there is Lsharp.
4) I don't even know what you mean with this. Any software can have run-time errors, whether written with a static or dynamic language.
I would mostly attribute F# interest to the fact that it like Lisp is a functional language.

Anonymous said...

I've used C++, Lisp, OCAML and F#.

I would say that people generally interested in programming languages will learn Lisp and come to greatly appreciate the productivity boost from coding in Lisp. Going back to C++ is painful.

For me, OCAML (and to a certain extent, F#) strikes a good balance between productivity and performance. In particular:
a) Type inference is wonderful. I always hated writing the optional type declarations in Lisp to get better performance.
b) Structures/modules are easier to use than Lisp packages.
c) Since it is a strongly typed language, code written in OCAML/F# also feels more robust than Lisp code.

It's a bit unfortunate that .NET memory management is a bit of a performance bottleneck (as noted by others in F# community). Nonetheless, F# is a language that I'm going to be following with greater interest.

Anonymous said...

To the Lisp disciple:

I know it has been a while since the posting and the poster is unlikely to see any response but the inaccuracy of the post shouldn’t go unchallenged.

As far as the “Have you ever used Lisp” comment… pot meet kettle!

Pattern matching in F#/OCAML/Haskell have nothing to do with regular expressions. Pattern matching is a language construct (not a library) that allows for different actions (e.g. execution paths, bindings) based on the structure of values.

F# runs as fast as C# when run on the .NET platform, plus F# can be cross compiled using an OCAML compiler producing native code which runs faster than C++ (and in some cases as fast as C). Quoting Han Solo “She's fast enough for you, old man.”

Any code can have run time errors, however, statically typed languages eliminate a class of errors (or rather catch them at compile time) and therefore, all other things equal, have fewer runtime errors.