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

[Jon Harrop <jon@ffconsultancy.com>]

Fascinating. Thanks for reporting the information. If I might be so brash as 
to comment on the problems you had that have already been fixed by F#:

On Tuesday 22 May 2007 23:10:23 David Teller wrote:
> * OCamlWinPlus...Camelia IDE...LablGtk, LablGl, Camlimage ...
> ... It seems that Graphics doesn't work with Cygwin, hence with Camelia ...

There are two possibilities here:

You want to use Windows => Use F#, Visual Studio and F# for Visualization and 
not OCaml.

You want good free software => Use Linux and not Windows.

> == Error messages ==
>
> * Error messages of the type system are somewhat obscure. The reflex of
> many students is "OCaml wants it to be of type XXX", rather than "there
> is a contradiction in what I wrote". It would be nice if there was a way
> to ask OCaml to display additional information on type errors. Say
> something like, whenever typing of an expression fails, restarting the
> type algorithm but printing out the various unifications as they take
> place.

F# currently has better graphical throwback of inferred type information but 
slightly worse messages, IMHO.

> * Documentation of LablTk is non-existent. I'm thinking about taking a
> student to write a more OCaml-ish layer on top of LablTk but I don't
> know if/when this will happen.

You get what you pay for as far as documentation is concerned. OCaml is 
largely undocumented (the compiler, several code libraries, the top-level, 
camlp4). There is some additional documentation (e.g. my book) but you must 
pay for it.

> * A nice *beginner-oriented* tutorial is really missing for students who
> failed to pay attention to the beginning of the lecture. Something more
> applied than _Developing applications with OCaml_ and less technical
> than http://ocaml-tutorial.org . Say, leading a beginner to define a
> Connect 4 game. I'm willing to participate into writing this, but not
> alone. I might launch a thread on this subject on the ML.

I'm very interested in writing an introduction to OCaml and publishing it as a 
very cheap book, maybe through O'Reilly.

> * That's not OCaml-specific but there must be some construction better 
> suited than "for" or "while" to write loops without having to handcode a
> recursive loops. Right now, I can't think of anything better than a
> "hidden" Y combinator, but there must be something.

I often use a nest function:

  let rec nest n f x = if n=0 then x else nest (n-1) f (f x)

F# also provides sequences and comprehensions:

  let factorial n = Seq.fold ( * ) 1 {2 .. n}

> * Arrays of arrays (of arrays...) are a bit obscure for students,
> although they're getting better at it.

F# provides multidimensional arrays, arbitrary-size arrays, immutable arrays, 
resizeable arrays, allows array subscript syntax to be overloaded and is 
faster than OCaml on array code. Arrays are a real weak point of OCaml ATM, 
along with div and mod, functors, concurrency and some other things.

> * Some students rely too much on references.

F# doesn't help you there.

> * The usual note-taking/attention deficit/motivation deficit problems.

Or there...

> * Anonymous functions are still beyond most of them.

SML can do them with one fewer letters!

If you want your students to be future proof then you would do well to prepare 
them for massively parallel computing on CPUs with hundreds or even thousands 
of cores. OCaml it completely ill-equipped for this. In contrast, F# provides 
native threads/locks/semaphores/threads/threadpools inherited from .NET as 
well as async programming via extra syntax. Concurrency is beautiful in F# 
and it works today.

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