Friday, 28 December 2007

Java: The Closures Controversy

Joshua Bloch, one of the Principal Engineers at Google and author of the book Effective Java, gave a lecture that was published on Parleys.com recently about the forthcoming support for closures in Java.

Near the beginner of the lecture, Joshua explains how Java was designed from the ground up to be a practical language with a job to do rather than an academic exercise in language design and stresses that this remains an important goal for Java's evolution. In particular, he uses the phrase "Don't fix it until it chafes" to emphasize that a practical problem must be severe before changes to the Java language itself will even be considered.

The last major change to Java was generics, or parametric polymorphism as it is referred to in functional languages. Joshua states that Java is "not doing too well" in the face of the complexity that was introduced by generics, citing an example from Angelika Langer's 427-page Java generics FAQ.

In essence, Joshua explains why he thinks the proposed designs for Java's closures are too grand and should be reduced to only two special cases with absolutely minimal changes to the Java language. In particular, he gives the example of a trivial curry combinator written using the proposed style for Java's new closures:

static  { A1 => { A2 => R } } curry({ A1, A2 => R } fn) {
return { A1 a1 => { A2 a2 => fn.invoke(a1, a2) } };
}

For comparison, here is that function written in the statically-typed functional programming language OCaml:

let curry f a1 a2 = f(a1, a2)

Note the complete lack of types in the OCaml source code thanks to the language's powerful type inference.

Type inference is an essential component of statically-typed functional programming languages like OCaml, Haskell and F# and the lack of type inference in Java means that closures quickly become prohibitively complicated in all but the most trivial cases. Joshua's point is, quite correctly, that burdening Java with the complexity of full-blown closures when they are crippled by the absence of other language features is not constructive.

Joshua goes on to explain that closures are a general solution to some practically important problems in Java programming. Specifically, he cites fine-grained concurrency and resource management. The former refers to passing snippets of code to another thread for execution and the latter refers to using a combinator to encapsulate the undoing of state (e.g. closing a file handle)· He gives the following code as an example of this current deficiency in Java:

static void copy(String src, String dest) throws IOException {
InputStream in = null;
OutputStream out = null;
try {
in = new FileInputStream(src);
out = new FileOutputStream(dest);
byte[] buf = new byte[1024];
int n;
while ((n = in.read(buf)) >= 0)
out.write(buf, 0, n);
} finally {
closeIgnoringException(in);
closeIgnoringException(in);
}
}

private static void closeIgnoringException(Closeable c) {
if (c != null) {
try { c.close(); } catch (IOException ex) { // ignore }
}
}

In the statically typed functional programming language F#, this is just:

let copy infile outfile =
use outstream = new StreamReader(File.OpenWrite outfile)
use instream = new StreamReader(File.OpenRead infile)
while not instream.EndOfStream do
instream.ReadByte() |> outstream.WriteByte

Note how F#'s use binding automates the closing of the stream at the end of its scope using .NET's uniform IDisposable interface.

Overall this lecture does a beautiful job of elucidating some simple practical problems that Java still struggles with. Joshua's concludes that the Java language should not be drastically altered but a new language should be created that addresses these problems. Joshua even cites the Scala programming language as one of the promising new languages for the JVM.

However, the Scala programming language is very much a research prototype and not a language for industry with a job to do. We were actually hoping that Joshua was going to announce a newer and more modern language for the JVM developed by Google that was designed and built for industrial use. Microsoft are already a long way down this road with their F# programming language and it seems a great shame that the Java platform remains so far behind. If Sun fixed some of the problems with the JVM itself, such as the lack of tail calls, and implemented a better language for the JVM we would surely be among the first adopters. Until then, we shall continue to use languages like OCaml and F# for our commercial work and not Java and the JVM.


Monday, 24 December 2007

Immutable stacks in OCaml/F# and Scala

The Scala programming language diverges from the ML family of languages (including OCaml and F#) in many respects and some of these can be seen in the simple immutable stack implementation given in the book "Programming in Scala".

The following implements a simple immutable stack in Scala 2.6:

sealed abstract class Stack[+a] {
def push[b >: a](x: b): Stack[b] = new NonEmptyStack(x, this)
def isEmpty: boolean
def top: a
def pop: Stack[a]
}
object EmptyStack extends Stack[Nothing] {
def isEmpty = true
def top = throw new Error("EmptyStack.top")
def pop = throw new Error("EmptyStack.pop")
}
class NonEmptyStack[+a](elem: a, rest: Stack[a]) extends Stack[a] {
def isEmpty = false
def top = elem
def pop = rest
}

The following is an equivalent implementation in OCaml or F#:

module Stack = struct
type +'a t = Empty | NonEmpty of 'a * 'a t
let is_empty = (=) Empty
let push h t = NonEmpty(h, t)
let top = function
Empty -> raise Not_found
| NonEmpty(h, _) -> h
let pop = function
Empty -> raise Not_found
| NonEmpty(_, t) -> t
end

The idiomatic ML solution is clearly substantially more concise. There are several reasons for this:

  1. OCaml and F# infer all types in this (and most other) cases whereas the argument and return types of the functions and parameters of parent classes are all specified explicitly in the Scala.
  2. Covariance is automated by OCaml and F# but Scala requires covariance to be introduced explicitly in the definition of the abstract class and repeated in all derived classes, and then handled explicitly in the definitions of member functions such as push.
  3. OCaml and F# automate the hoisting of immutable expressions like the empty stack whereas Scala requires the distinction to be added explicitly by declaring NonEmptyStack as a derived class but EmptyStack as an individual object.
  4. The type of the empty stack must be given explicitly in Scala but the type is polymorphic so Scala introduces the identifier Nothing to denote this unknown type. This is inferred automatically by OCaml and F#.
  5. The module system allows all definitions (type and function) to be encapsulated in a single module called Stack in the OCaml and F#. In contrast, the Scala gives three different object/class definitions that redundantly contain Stack as a substring in their names.

These characteristics of Scala make it more verbose than OCaml and F# in this case. Comparisons between Scala and other modern functional programming languages are surprisingly rare: the Scala community typically compare Scala to other JVM languages. Thus we shall endeavour to describe the similarities between Scala and other languages in future posts.

Saturday, 24 November 2007

Low-Level Virtual Machine

LLVM is a compiler infrastructure designed to make it easier to write native code compilers by providing a RISC-like intermediate assembler and the potential for high-level features like garbage collection and free exception handling.

We are very interested in the idea of building a new virtual machine designed ideally suited to statically-typed functional programming languages. LLVM looks like the ideal starting point for such a project. The examples even include a complete Scheme implementation with working garbage collector in only 1,000 lines of code!

Thursday, 15 November 2007

Most popular functional languages on Linux

The Linux operating system is unique in providing a wide variety of tools for developers. In particular, Linux offers an incredible variety of programming languages. This post describes our attempt to measure the popularity of functional programming languages on Linux.

There are many language popularity comparisons out there. The TIOBE programming community index is a famous one based upon the number of search hits indicated by various search engines. Like every comparison, the TIOBE results are flawed in various different ways. Some of the most important problems with this particular measure are:

  • Legacy: older languages have more out-of-date web pages.
  • Unpopularity: this metric is an equally good measure of the unpopularity of a language.
  • Subjectivity: the estimated number of search results returned by search engines is highly dependent upon unrelated factors like Google's algorithm du jour.

We are going to try to measure language popularity on Linux using a more objective metric: the results of the Debian and Ubuntu package popularity contests. Amongst other things, the results allow us to determine how many installations there are for core development tools for each language. Summing the number of installations gives a much more accurate estimate of the number of people actually developing in each language.

Before we go into detail, let's consider some of the flaws in this approach. Firstly, the absolute number of installations is not equivalent to the number of users. Many users will have their favorite language installed on several different systems. Secondly, programmers using languages with multiple different implementations are likely to have several different compilers for that language on each machine. This will bias the results in favor of languages with multiple implementations (such as GHC and Hugs for Haskell). Finally, these results only apply to Ubuntu and Debian users who elected to contribute to the popularity contests. We are assuming that other Linux distributions will give similar results and we can test this to some extent by comparing the results between Debian and Ubuntu.

The results were compiled by summing the contributions from the following major development packages for each language:

  • Erlang: erlang-base
  • OCaml: ocaml-nox
  • Haskell: ghc6 and hugs
  • Lisp: clisp, sbcl, gcl and cmucl
  • Scheme: mzscheme, mit-scheme, bigloo, scheme48 and stalin
  • Standard ML: smlnj, mosml and mlton
  • Eiffel: smarteiffel
  • Mercury: mercury
  • Oz: mozart

The results are illustrated in the graph above. Sure enough, the number of installations is similar between Debian and Ubuntu and, therefore, it seems likely that these results will reflect the trend for most Linux users.

We found the results surprising for several reasons:

  • Lisp is often cited as the world's most popular functional programming language yet it comes 4th after OCaml, Haskell and Erlang in our results.
  • There is no clear preference for a most popular functional programming language. Instead, we find that OCaml, Haskell and Erlang are all equally popular.
  • Despite the bias against OCaml because it is unified by a single implementation, this language still appears to be among the most popular functional programming languages on Linux. This is even more surprising because there are few OCaml books.

Following Microsoft's productization of their OCaml derivative F#, it seems likely that OCaml will continue to grow in popularity on the Linux platform.


Popularity of the Haskell programming language is likely to increase soon following substantial performance improvements thanks to the new 6.8 release of the Glasgow Haskell Compiler (ghc).

Monday, 29 October 2007

Western Digital "click of death": nVidia's fault?!

After our nVidia chipset graphics card exploded a few weeks ago, we just suffered three live hard-drive failures. One was an old laptop drive and the other two were both 250Gb Western Digital Caviars in two separate machines (one Linux and one Windows) both hosted by nVidia nForce chipsets on Asus A8N-SLI S939 Premium motherboards.

Hard drive problems are always terrifying. In this case, we had several theories about what might have gone wrong. The symptoms in both cases were the drives starting to click. This problem is lovingly referred to as the "click of death", after the famous ZIP disk problem. The death of the HD in the Windows box gave us a heads-up about the imminent demise of the identical HD in the Linux box so we at least managed to get a totally fresh backup from that box. Of course, the major pain is actually reinstalling Windows and all of your software rather than getting the data copied off a backup (even if you do lose a couple of days work!). As my glass is half full, I see blitzing the Windows XP Professional install as an opportunity to address its utterly shameful reliability, which had gradually deteriorated over the period of 14 months to an average unladen up-time of only 3 hours compared to a laden up-time of 9 months for our identical Linux box!

Researching the hard-drive problem turned up several interesting leads. Like all HD manufacturers, Western Digital have a brand tarred by tales of doom. Interestingly, the IBM Deskstar series (since taken over by Hitachi) acquired such a bad reputation that it is referred to as the "Deathstar" series. In fact, we have reverted to using two old Deskstar drives here and both have worked much more reliably than the Western Digital, which makes me lean towards buying a Deskstar from Hitachi as a replacement and lean away from believing the negative reviews about them. Like any highly-competitive market, search results are inundated with suspicious reviews by "Bob" who gives one manufacturer five stars and all others only one.

Perhaps the most interesting lead turned up by our research is the fact that nVidia's SATA support for their nForce chipsets has remained broken since the nForce 3, rendering drives inoperable and even silently corrupting data, both under Linux and under Windows and on a variety of hard-drives from (at least) Western Digital, Maxtor and Hitachi. Coupled with the fact that their nForce chipset is temperature intolerant and their GeForce graphics chipset is cooking Asus' fanless nForce chipset on our motherboards, you've got yourself cause for concern. Even if we had opted for the higher-specification "Deluxe" model than includes a chipset fan, apparently these are notoriously unreliable.

So, after the failure of two identical Western Digital hard-drives in different machines, we find ourselves more disgruntled with nVidia than anyone else!

Saturday, 13 October 2007

First Impressions of Eclipse

Our move into the Scala market must begin with a survey of the existing tools used by Java programmers that Scala programmers can exploit. Eclipse is unquestionably one of the most highly ranked tools among Java programmers, so our journey starts there. This is a beast of an integrated development environment (IDE) that IBM allegedly spent $40M creating.

Under a Unix environment with apt (such as Debian, Ubuntu or Mac OS X), Eclipse and all of its dependencies may be installed from the command line with:

$ sudo apt-get install eclipse

However, the resulting install on our Debian Linux box was extremely unstable, with Eclipse often dying from null pointer exceptions. After much Googling, it transpires that the cause is that Eclipse is being executed in the default Java installation of this system which is GNU Java rather than Sun's JVM.

For Eclipse to run reliably, you must change the default Java to Sun's Java. The official solution is to run the following:

$ sudo update-alternatives --config java

and select Sun's Java. Now you have a working Eclipse installation under Unix.

We are also developing under Windows. On this platform, you download the Windows version of Eclipse, unpack the archive and run the eclipse.exe file that was inside it. There does not appear to be a Windows installer.

Eclipse has a 30 second startup time on these machines (dual core 2.2GHz 64-bit machines), after which you see an introductory page offering "Overview", "What's new", "Workbench", "Samples" and "Tutorials".

Installing Scala and its Eclipse plugin under Debian Linux is easy using apt and the software update feature of Eclipse. Under Windows, the software update feature fails due to dependencies.

As a brief test of Eclipse, we tried to write a few simple programs:

  1. Command-line "Hello World".
  2. GUI "Hello World".
  3. Minimal OpenGL program using JOGL.

The Java programming language is infamously verbose and it is interesting to note that the boiler-plate code required by the Java language is augmented by a lot of "boiler plate" mouse clicking with Eclipse.

Getting a command-line "Hello World" program working is quite easy, although much more laborious than using the command line. Finding a GUI "Hello World" program is harder that expected. The HelloWorldSWT program given in Eclipse's own tutorials requires libraries to be manually downloaded and installed. In fact, Googling turned up several Swing-based "Hello World" programs and, although many of them are no longer valid due to library and namespace changes, the following program currently works:

import javax.swing.JFrame;
import javax.swing.JLabel;

public class HelloWorld {
/**
* @param args
*/
public static void main(String[] args) {
JFrame frame = new JFrame("HelloWorldSwing");
final JLabel label = new JLabel("Hello World");
frame.getContentPane().add(label);

frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.pack();
frame.setVisible(true);
}
}

At the time of writing, we have been unable to build any OpenGL programs in Eclipse. So the first impressions of Eclipse are that it is cumbersome to install and use, both under Linux and under Windows. This is a surprising result given that an IDE is intended to simplify development but shall focus on using command-line tools in future simply because they are at least as easy to use.

Monday, 1 October 2007

Exploding Gainward graphics cards

Despite the excellent work by XenSource, here at Flying Frog Consultancy we still perceive virtualization as a technology for girly men. As a consequence, we have two main development machines with identical hardware, one running Linux and the other running Windows XP Pro with a button that switches a monitor between the two. This may seem archaic but it actually turned out to be quite useful when the Gainward 7900GT 512Mb PCI-E graphics card in the Windows machine exploded spectacularly on Saturday. Thankfully the rest of the machine is fine and we were able to test it by swapping the graphics card with one from the sister Linux box. When we bought them, those were cheap 512Mb nVidia cards at £280 from Dabs. We only use nVidia here because of their solid reputation for Linux drivers.

Unfortunately for us, the exploded card is 1 month out of warranty. Looking for a replacement, we were pleased to find a BFG 7900GT 256Mb OC card on the shelf in PC World for only £110. Timing was critical in this case because we just landed a source deal for our .NET FFT code and had to get the latest sources tidied up and off that machine.

We were tempted to opt for an nVidia 8 series card but we're not going to develop any DirectX 10 software this year and the nVidia 9 series are apparently scheduled for this Christmas, which will knock down the price of the 8 series. Next year, we'll be examining several different avenues of research including the use of F# in games programming for the XBox using XNA and, consequently, we may well invest in a top-notch 9 series.

Naturally, it was essential that the new graphics card be tested using tools such as Quake 4. Sure enough, the new BFG card kicks ass with high quality 1900x1200 running at 80fps. On a more serious note, the FSAA capabilities of this card are already enough to provide high-fidelity animations from our Smoke Vector Graphics and F# for Visualization libraries.

Looking at the two cards, the new BFG is clearly better built than the old Gainward. In particular, the cooling system on the gainward was a rather inefficient centripetal fan with a heatsink that only had a copper base. In contrast, the BFG has a slimmer cooling unit with no gaps around the fan and a solid copper heatsink. This is reflected in the GPU temperature readings, which showed the Gainward card equilibrating at 80C and the BFG card settling at under 50C.

I think we'll go straight for the BFG next time...

Review: Hewlett Packard Color LaserJet 3800dn

Following our damning review of the Lexmark C530dn duplex color laser printer, we're going back to our original view that Hewlett Packard offer far and away the best printers in this range. PC World kindly gave us a refund on our awful Lexmark machine because it was blatantly not fit for purpose of sale (it failed to reach most of the specifications claimed by Lexmark). We then chose to invest in an HP Color LaserJet 3800dn instead.

Now that we've printed 25,000 pages with it, we can review its performance: this HP printer is simply awesome!

In contrast with the Lexmark, the HP is smaller, quieter, produces higher-quality prints, is more reliable and running costs are vastly lower. That last point has become particularly important for us thanks to record sales of the OCaml for Scientists book.

Lexmark claimed their black toner cartridges did 4,000 pages when, in fact, they only did 3,000 pages. As it happens, Hewlett Packard claim that their cartridges all do 6,000 pages when, in fact, their color cartridges are doing 13,000 pages! By our reckoning, a copy of OCaml for Scientists was costing around £30 to print with the Lexmark but only £8.52 with the HP.

Better yet, the Lexmark only had rudimentary support for Linux whereas the HP Color LaserJet works flawlessly from both Linux and Windows XP via its own LAN connection. In fact, the printer was easier to setup in Linux than in Windows XP.

So if you're looking for a good mid-range color laser printer with low running costs, look no further than the Hewett Packard Color LaserJet 3800 series!

Friday, 28 September 2007

Ray tracer language comparison ported to Scala

Derek Young has kindly ported the first Java implementation of our ray tracer language comparison to two alternative languages that both also target the JVM.

  • Scala: a statically-typed functional programming language.
  • Groovy: a dynamic programming language.

Interestingly, the Scala translation is not only shorter than the equivalent Java but also slightly faster. The same correlation is seen on .NET, where F# is often slightly faster than C# because it can perform valuable high-level optimizations not exposed by lower-level languages like C#, e.g. optimizing pattern matches.

Interest in Scala continues to grow and we are considering writing a Scala for Scientists book, following our OCaml for Scientists and F# for Scientists books. If you would like to learn about technical computing using Scala then please show your support by commenting on this blog post.

Wednesday, 19 September 2007

Functional programming in industry

Microsoft's recent decision to make F# one of its mainstream programming languages for Visual Studio will increase the acceptance of modern functional programming languages for ordinary industrial development. In the mean time, it is interesting to see where functional programming languages are already being used in industry.

Perhaps the most common functional programming language in industry is JavaScript, used to power many of the world's websites.

Flying Frog Consultancy are a consultancy, book and software company specializing in the ML family of languages, primarily OCaml and F#. We have product lines including books and on-line magazines teaching OCaml and F# as well as software written in or for these languages.

Microsoft have a considerable investment in the CAML family of functional programming languages. Specifically the OCaml language and Microsoft's own CAML-derivative for .NET called F#. Microsoft's driver verification software is written in OCaml. Microsoft trust the $2bn advertising market on MSN Live to F# code. Microsoft's XBox group write F# programs to analyze the statistics of on-line XBox Live players. Many Microsoft Research projects are written in OCaml and F#, such as the Stochastic Pi Machine (SPiM).

Intel use high-level modelling and verification tools called reFLect written in OCaml for the hardware verification of their integrated circuits, part of their Forte environment.

IBM sell a Migration Toolkit written in OCaml. This is designed to help with the static analysis and conversion of databases.

MATLAB from The MathWorks uses the FFTW library to provide its FFT implementation. FFTW is written in OCaml.

XenSource's value-add over the free edition of Xen is largely a distributed, cross-platform, multi-programming-language management tool stack written in OCaml. XenSource recently sold to Citrix for $500M.

Jane St. Capital have over 20 functional programmers working in offices around the world on finance using OCaml. They recently expanded with a new office in London. Several other financial houses use functional programming languages extensively. Outside ML, Haskell is also popular in the financial sector following a seminal paper by Simon Peyton-Jones.

LexiFi use OCaml extensively for the modeling of financial products (swaps, options etc). Their solution includes software for modeling the life cycle of a product, as well as pricing them. It is closely related to the solution described in the paper by Jean-Marc Eber and Simon Peyton-Jones.

Dassault Systemes sell a computer-aided manufacturing environment called Delmia that contains a domain-specific language implemented in OCaml called CellControl for programming assembly-line automata and robots.

Astree is a static analyzer to remove large classes of important bugs from mission critical code used by Airbus.

Coherent Graphics Ltd. distribute libraries, tools and services for manipulating PDF documents, written in OCaml.

Wink Technologies provide a people search engine written largely in OCaml.

SkyDeck create products for the mobile phone industry using software written in OCaml.

Credit Suisse First Boston use Haskell in finance.

Linspire is a commercial Linux distribution written partly in Haskell.

Erlang is used extensively by Ericsson for handling telecoms and has recently become trendy in industry.

The future is bright for functional programming

Given the recent surge in interest, several companies have expressed a desire to create product lines centered around various functional programming languages. Although there are still a relatively small number of companies generating revenue from functional programming, we have found it remarkably easy to create successful products in this area. Naturally, Flying Frog have many fingers in many pies and we find it very encouraging that the functional pies have turned out to be the most efficient at creating money time after time.

OCaml remains our most profitable functional programming language, with our book OCaml for Scientists and The OCaml Journal currently accounting for 67% of our revenue from product sales.

F# is our second most profitable language, with sales of The F#.NET Journal and F# for Visualization accounting for 28% of our current sales.

However, the growth of functional programming languages is most interesting. Following a four-fold increase in sales of all OCaml-related products over the year to April 2007, we are now seeing a plateau. Although development of the OCaml language itself has slowed, we believe this will not deter industry from continuing to adopt the OCaml programming language. Indeed, XenSource are one of the largest commercial users of OCaml and the company recently sold for $500M.

Interest in F# is now exploding. Our F#-related products are all new so we cannot derive long-term trends from sales but we have seen a four fold increase in search engine referrals from searches for F# over the past six months alone. We believe that interest in F# will grow even faster because we are predicting the imminent productization of this language by Microsoft.

Overall, functional programming in industry is clearly going from strength to strength. The oft-cited advantages of functional languages no doubt underpin this but the advent of multicore computing is an unquestionable driving force that tips the balance for many talented startups wanting to create future-proof solutions for their customers.

The future is bright for functional programming languages on all platforms. We shall certainly continue work related to OCaml and F# and may even diversify into other functional languages such as Scala or Haskell.

Thursday, 2 August 2007

Special Offer: 25% off all brain food

If you're looking to seriously expand your mind, you'll be interested in our special offer:

For a limited time only, we're giving 25% off when you buy OCaml for Scientists and full subscriptions to the OCaml Journal and F#.NET Journal.

OCaml for Scientists is our best selling book and has received universally-glowing reviews. This book guides you through all of the core topics required to get you writing high-performance OCaml programs with OpenGL-based visualization in this state-of-the-art cross-platform functional programming language.

The OCaml Journal provides up-to-the-minute articles on the state of the OCaml world, including reviews of third party tools such as data structures, build-tools, IDEs, parsers, graphics libraries and notes on how the unique features of this language are best leveraged by developers.

The F#.NET Journal teaches you everything you need to know to get developing in this modern functional programming language on the Windows platform using the .NET framework. Journal articles include a complete introduction to the core features of the language, interoperability with existing .NET libraries, products and services available for F# developers and reviews of all F# related goodies.

Thursday, 26 July 2007

Haskell on the ray tracer language comparison

We just updated our famous ray tracer language comparison with four progressively-optimized Haskell implementations of the ray tracer.

The first implementation is idiomatic Haskell: entirely lazy.

The other three implementations use eager evaluation extensively in an attempt to achieve competitive performance.

Monday, 2 July 2007

Concurrency

After years of reading articles complaining about the lack of concurrency in the OCaml programming language and speculation that the language would die as a consequence when multi-core computers became ubiquitous, we were pleasantly surprised to find that OCaml programs can exploit our dual-core machine easily and efficiently.

As a test, we augmented the OCaml implementation of our ray tracer benchmark with a parallel higher-order map to exploit this embarassingly parallel algorithm. This is around 20 lines of extra code. The results were quite surprising: the concurrent OCaml implementation both outperforms and scales better than the concurrent F# implementation!

These results led us to study concurrency in more detail and we were surprised to find that such a fundamental problem has no clear solution. The best proven track record of any technology is probably Erlang, used to handle massive concurrency on telephone networks, which cleanly separates concurrent threads and gives each thread its own garbage collector. This is done deliberately to make each concurrent thread as independent as possible.

Surprisingly, the two big concurrent languages for applications programming (Java and .NET) both opted for a different approach using concurrent garbage collection. A concurrent garbage collector consists of at least one extra concurrent thread that traverses the heap and deallocates unreferenced values. This has several advantages:
  • Concurrent threads can share memory.
  • Communication between concurrent threads is cheap.
  • Single-threaded applications exploit two cores because the garbage collector runs concurrently with the main thread.
However, concurrent garbage collection also has disadvantages:
  • Allocation is slowed by synchronization.
  • Concurrent programs relying upon shared memory cannot be distributed, e.g. across a network or between CPU and GPU.
These distinctions are particularly interesting in the context of functional programming languages because of their unusual properties:
  • High allocation rates for small, short-lived values.
  • Large immutable data structures.
Idiomatic functional code is typically several times slower in Java or on .NET because of the overhead imposed by a concurrent GC.

The third approach to concurrency, used by OCaml and JoCaml, is to fork the process and run two processes concurrently. Forking creates a mirror of the heap but it is lazily copied (copy-on-write), so the large immutable data structures found in functional programs do actually get shared, even though explicit shared memory is not supported. This makes message passing much slower but allows an individual process to run at full speed.

So OCaml's fork-based approach to concurrency is preferable for computationally-intensive problems that parallelize easily (like our ray tracer) but the Java and .NET approaches are preferable when there will be a lot of communication.

Interestingly, the F# programming language will soon add support for asynchronous programming using a monadic style derived from the research done on Haskell. This will provide a robust, high-level approach to concurrency that should alleviate the most important problems encountered when trying to write reliable concurrent programs.

Sunday, 10 June 2007

New product: The OCaml Journal

Combining the success of our book OCaml for Scientists and The F#.NET Journal, we just released the OCaml Journal.

The first issue of this journal will be an introduction to the OCaml programming languages. Later articles will cover more advanced and exciting topics like OpenGL and concurrency.

Friday, 18 May 2007

O'Reilly's Book sales

As we write and publish books on programming, we were very interested to read Tim O'Reilly's recent article about the demographics of books sales with respect to programming languages:

http://radar.oreilly.com/archives/2007/05/state_of_the_co_10.html

Although this obviously took quite a bit of analysis, it is interesting that the article only counts cheap books and disregards profits.

If you recount in terms of profits and include books for professionals like OCaml for Scientists then the results are completely different. Looking at OCaml books, the inclusion of Flying Frog Consultancy doubles the sales figures quoted by O'Reilly and increases profits ten fold.

This is a very interesting result for authors because it indicates that mainstream publishers like O'Reilly are not suitable for books covering non-mainstream programming languages like OCaml. We would advise authors to seek more specialist publishers like APress, or found their own publishing house as we did.

Moreover, books are often used as an advertising medium by authors wanting to promote themselves and their other products. In this case, it is worth noting that the readership of journals, magazines and newspapers is vastly higher than the top-selling O'Reilly books. So writing a few magazine articles is not only easier but is also a more effective way to increase visibility.

Wednesday, 16 May 2007

F# for Visualization moved into beta release

With our current push to provide better visualization libraries for scientists on the .NET platform, we have moved our library into commercial beta release:

http://www.ffconsultancy.com/products/fsharp_for_visualization/

As the demos on that page show, the library already allows real-time interactive visualization of static 3D scenes. We'll be uploading our first dynamic demo later today and we hope to showcase our hardware-accelerated LaTeX/MathML and 2D vector graphics engine by the end of next week. Then we can start on Silverlight integration.

The F# programming language is allowing us to develop at a tremendous speed.

Saturday, 5 May 2007

Don't buy Lexmark!

As we publish most of the books that we write and we make maximal use of graphic design and color, we need high-quality printers that can create our books reliably on demand. Consequently, we invested great time and effort into looking at the manufacturers specifications for the latest batch of color laser printers when our main workhorse started to show her age.

We made the mistake of buying a Lexmark printer and our error cost us around $5,000 in wasted materials and time. Specifically, we bought their C530dn color laser printer. Although the speed is good, the quality is awful, the reliability is awful and, of course, the support is non-existent. In the month that we had the printer, it printed 5,000 pages and fewer than 500 were good enough to sell.

Contrary to the manufacturers claims, Lexmark toner costs four times as much as HP toner. The Lexmark cartridges were visibly poorly made whereas the HP cartridges are almost always of excellent quality (about 1% are half empty!).

One of the main problems with the C530dn printer is that (we believe) it overheats after only 400 pages, causing a powerful internal fan to startup which serves to blow the toner around inside the printer. In only one month, the inside of the printer was filthy and every page it printed had a murky brown background.

We ended up forking out an extra £500 for a Hewlett Package CLJ 3800dn and so far so good. No problems with reliability, despite record book sales, and the quality is fantastic. This printer is also quieter and smaller!

So if you want a decent printer, don't buy Lexmark!

F# for Visualization

The F# programming language from Microsoft Research provides an excellent basis for a modern technical computing environment:

http://research.microsoft.com/fsharp/

Specifically, the core language is wonderfully elegant and, as a .NET language, interoperability with existing libraries couldn't be simpler.

We intend to boost the functionality of F# by providing add-on libraries for numerical computing, visualization and symbolic mathematics. In fact, work has already begun on a graphics library that combines lightning-fast access to DirectX with the simplicity of BASIC programming.

For a limited time only, a beta release of this software is freely available on our site, with three demo programs (complete with Visual Studio projects) and even a tutorial video!

http://www.ffconsultancy.com/products/fsharp_for_visualization/

Fast Fourier Transform (FFT) for .NET

We recently reviewed the current state-of-the-art in technical software for the .NET platform and were surprised to discover several gaps in important numerical algorithms.

The Fast Fourier Transform (FFT) is ubiquitous in signal analysis because it underpins most spectral methods. Surprisingly, we found no reliable free implementations and the expensive commercial solutions were too slow.

So we wrote our own implementation for use in our future products and we are making it available to you in DLL form:

http://www.ffconsultancy.com/products/signal_processing_net/

In the future, we shall offer complete signal processing and analysis tools as standalone applications with built-in visualization, based upon this library.

New blog!

Welcome to the company blog of Flying Frog Consultancy.

http://www.ffconsultancy.com/

We are a consultancy, software and book firm based in Cambridge, UK. In particular, we are keenly promoting the adoption of modern functional programming languages in industry, including the OCaml and F# languages.

If you're looking for resources on any of the above topics, please let us know.