English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Teaching bottomline, part 3: what should improve.
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-05-23 (21:51)
From: Jon Harrop <jon@f...>
Subject: Re: [Caml-list] Teaching bottomline, part 3: what should improve.
On Wednesday 23 May 2007 20:27:24 Robert C Fischer wrote:
> ...and locks and threads are not a viable long-term solution to the
> problem of concurrency in general.

Absolutely, that's why we have parallel iter, map, fold etc.

> You're future-proofing enough by teaching them functional languages

Functional programming is not a panacea. GUI programming is one application 
area where functional programming, immutability and the parallelizable 
constructs that I just mentioned are not so beneficial.

To solve GUI programming you need different constructs (events, message pumps 

Look at some of the example F# programs on our site. This Sudoku solver uses a 
worker thread to keep the GUI responsive while it solves puzzles:


This ray tracer uses concurrency for incremental update of a responsive GUI:


This particle simulator runs the simulation thread in parallel with the GUI 
thread, for real-time visualization of the particle system:


In the future, I hope OCaml will support concurrency not only to handle 
parallel constructs but also to handle GUI programming elegantly. If there is 
one thing that I have been singularly impressed by from .NET, it is GUI 

Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal