[Haskell-cafe] "Graphical Haskell"

Jon Harrop jon at ffconsultancy.com
Sat Jun 23 01:22:27 EDT 2007

On Friday 22 June 2007 16:38:18 peterv wrote:
> - Unfortunately this project won't be open source; if my first tests are
> successful, I will try to convince my employer (who wants to develop such a
> graphical language) to use Haskell for building a prototype instead of
> C#/F#/Java. Can Haskell be used for creating commercial projects? When the
> product is released, it *will* be downloadable for free, but the source
> code won't be (most likely).

We are developing both OCaml and F# into graphical platforms for technical 


and are also interested in doing this with Haskell. Our projects are also 
closed source but Smoke is freely available in platform-independent bytecode.

> ...
> - Regarding performance (for real-time simulations, not GUIs), I think the
> garbage collector will get really stressed using FRP because of all those
> infinite lazy streams; my gut feeling says a generational garbage collector
> like Microsoft's .NET could help here (but the gut is often wrong, see
> http://www.youtube.com/watch?v=RF3m3f9iMRc for an laugh ;). Regarding the
> GC, is http://hackage.haskell.org/trac/ghc/wiki/GarbageCollectorNotes still
> up-to-date?

To the best of my knowledge, OCaml is head and shoulders above the 
alternatives in this respect. It is certainly several times faster than F# 
for GC-intensive work. The main reason is that .NET imposes concurrent GC, 
which introduces locks around every allocation and cripples performance when 
value lifetime distributions are typical of a functional language. The Unix 
approach of forking processes seems to be far better suited to functional 
languages (this is not dissimilar to Erlang's GC-per-thread approach).

For example, the time taken to solve the 11 queens problem with the same 
program that filters out int pairs from a list of all board positions:

OCaml: 5s
F#: 30s

Also, the worst case performance of our visualization tools is 5x faster in 
OCaml than it was in C++. Assuming the same is true of Haskell, I think it is 
probably premature to be worrying about GC performance.

Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The OCaml Journal

More information about the Haskell-Cafe mailing list