Re: [Caml-list] Teaching bottomline, part 3: what should improve.

[Jon Harrop <jon@ffconsultancy.com>]

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 
etc.).

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:

  http://www.ffconsultancy.com/dotnet/fsharp/sudoku/index.html

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

  http://www.ffconsultancy.com/dotnet/fsharp/raytracer/index.html

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

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

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 
programming.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e