Saturday, 8 November 2008

Sales of F# books

The book publisher O'Reilly wrote an interesting blog post entitled "State of the computer book market" which included a breakdown of programming books by programming language. We criticized their study before because it does not count books like OCaml for Scientists, which has been the world's best-selling book about OCaml since its publication, and also because they consider only units sold and not cost.

Wiley have gathered sales information about our book F# for Scientists and it is interesting to see how well F# is doing compared to the figures for general programming book sales last year that were quoted by O'Reilly.

A direct comparison shows that the 1,225 copies of F# for Scientists sold in Q3 2008 immediately places the F# programming language a long way ahead of all of the conventional functional languages (i.e. excluding C# and Javascript). The best selling conventional functional language in Q1 2007 was Lisp with only 557 books sold. Moreover, the Amazon sales rank of the book Expert F# is consistently slightly higher than F# for Scientists. So the total number of F# books being sold is likely to be at least 2,500 per quarter.

According to these results, the F# programming language is already far more popular than Ada, OCaml, C, Haskell, Scheme, Lisp and Groovy.


Steve Lianoglou said...

This is only tangentially related to your post because you mention F# and scientific computing ...

I'm curious what you think about this post regarding the performance of large matrix computations on the JVM:

Being that F# is hosted on the CLR, I'm curious if it has the same issues as languages hosted on the JVM (I reckon it must), and how you deal with it.


Flying Frog Consultancy Ltd. said...

Excellent question, Steve.

I believe that computations pushing the limits of a machine's capabilities will always need to be written in a lower-level language like C or Fortran where you have closer control over specifics like memory layout. However, even then, vendor tuned libraries like Intel's MKL will always be a better choice when they are available and when they fit (i.e. they happen to implement exactly what you need). So, in a sense, I would say that these tasks are not very relevant to managed systems like Java and .NET because they are immediately the wrong tool for the job.

However, in scientific computing (which I take to mean "what scientists compute") for every program that pushes the memory limits of the machine there are a thousand that do not. The vast majority of these programs are solving higher-level problems using techniques not already implemented elsewhere, presenting GUIs and web services and so forth. Low-level languages are obviously an awful choice for such tasks and the lure of single-language projects is powerful, even with a common language run-time. So JVM- and .NET-based tools have carved themselves a substantial part of the market between HPC in Fortran and really high-level but hugely inefficient tools like Mathematica.

Finally, a lot of scientific apps want to compute a huge number of medium-sized computations. In those cases, the trade-off is complicated by the overhead of calling out from a managed environment (pinning, invocation etc.). Consequently, purely managed solutions can given competitive performance in such scenarios.

So you're right that these problems exist, both on the CLR and the JVM, but I believe that will have a relatively small effect on the uptake of F# in science because F#'s buy-in is that it makes lots of practically-important problems easy to solve with adequate efficiency.