[Caml-list] teaching OCaml

[Caml-list] teaching OCaml

[robert.muller2]

Greetings. Bob Muller here, in the CS dept. at Boston College. I've set out to
develop an intro CS course in ML that I hope will be well-suited for similar
universities in the US. My original plan was to teach the course in SML but
after talking with a few people at neighboring schools, I switched to OCaml. I
am now in the final weeks of the first run of the course.  I plan to document
my experience more fully at some point but I wanted to touch base with the
OCaml community because I'm teaching the course again in the spring and I am
leaning toward switching to F#.

While OCaml has in many respects been great and it's easy to see that my
students find the OCaml style of coding very compelling, there are significant
problems. Of course, OCaml wasn't designed for teaching but I'm hoping that
someone on this list might be able to advise me about solutions to some of
these that I just don't know about.

1. Error messages: It's difficult to give good type errors for ML but I was
hoping that the state-of-the-art of type error reporting had improved. When my
students receive a type error, they are utterly mystified,

2. GUIs: several of my problem sets work with simple graphics (e.g., rendering
tessellations) or animations (e.g., a maze walk or a simplified form of
tetris, or the game "Flow"). We have been hobbling along with the Graphics and
Labltk modules for this but it has been more pain than my students ought to
know. We also have some problem sets that work with audio so I would like
support for that.

Any thoughts, ideas and/or leads on either of these would be much appreciated.
I already plan to look at js_of_ocaml more closely.
Thank you,
Bob Muller

Re: [Caml-list] teaching OCaml

[John Whitington]

Hi Bob,

robert.muller2@gmail.com wrote:
> Greetings. Bob Muller here, in the CS dept. at Boston College. I've set out to
> develop an intro CS course in ML that I hope will be well-suited for similar
> universities in the US. My original plan was to teach the course in SML but
> after talking with a few people at neighboring schools, I switched to OCaml. I
> am now in the final weeks of the first run of the course.  I plan to document
> my experience more fully at some point but I wanted to touch base with the
> OCaml community because I'm teaching the course again in the spring and I am
> leaning toward switching to F#.
>
> While OCaml has in many respects been great and it's easy to see that my
> students find the OCaml style of coding very compelling, there are significant
> problems. Of course, OCaml wasn't designed for teaching but I'm hoping that
> someone on this list might be able to advise me about solutions to some of
> these that I just don't know about.
>
> 1. Error messages: It's difficult to give good type errors for ML but I was
> hoping that the state-of-the-art of type error reporting had improved. When my
> students receive a type error, they are utterly mystified,

Arthur Chargueraud has done some work on this, by fixing up the error 
messages using an auxilliary typechecker. There is an OPAM compiler 
switch for it, I recall.

http://gallium.inria.fr/blog/making-it-easier-for-beginners-to-learn-ocaml/

I think it's very important for students to understand how to do a kind 
of mock type inference on paper or in their head. This helps a lot with 
understanding errors, though they will always happen, and the error 
messages are tough to begin with. For example, from the standard library:

let rec fold_left f accu l =
   match l with
     [] -> accu
   | a::l -> fold_left f (f accu a) l

1. Looking at the form of the first line, the type must have the form

... -> ... -> ... -> ...

2. Looking at lines 2 and 3, we know that l is a list, and that the 
final output has the same type as the 'accu' (assign it 'a):

... -> 'a -> ... list -> 'a

3. Look at the last line. Now we can see that f is a function, because 
it is applied, and we can see its first argument is the same type as 
'accu' too:

('a -> ... -> ...) -> 'a -> ... list -> 'a

Since 'accu' feeds back through the recursive call, 'f accu a' must have 
that  type too:

('a -> ... -> 'a) -> 'a -> ... list -> 'a

We have no information to show that the type of the list which 'a' comes 
from in 'f accu a' must be the same as 'a, so call it 'b:

('a -> 'b -> 'a) -> 'a -> 'b list -> a

If they can do that one, they can probably do most things that might 
appear in a beginners course.

I'm also strongly opposed to beginners being encouraged to use type 
annotations in code, which people sometimes do to get 'better' error 
messages. I think it confuses more than helps. But that seems to be a 
controversial opinion, from what I can tell.

> 2. GUIs: several of my problem sets work with simple graphics (e.g., rendering
> tessellations) or animations (e.g., a maze walk or a simplified form of
> tetris, or the game "Flow"). We have been hobbling along with the Graphics and
> Labltk modules for this but it has been more pain than my students ought to
> know. We also have some problem sets that work with audio so I would like
> support for that.

I wrote a version of Graphics which writes to PDF. If you have a PDF 
reader which re-renders when the file on disk is updated, this can be 
used for the non-interactive stuff, and it feels a bit more modern than 
the built-in graphics window.

https://github.com/johnwhitington/graphicspdf

You can get it in OPAM.

Thanks,

-- 
John Whitington
Director, Coherent Graphics Ltd
http://www.coherentpdf.com/

Re: [Caml-list] teaching OCaml

[John Whitington]

Hi,

Robert Muller wrote:
> Thank you John. I will look at your graphics library, much appreciated.
> I didn't require it this first time through but many of my students
> bought your book:
>
> http://www.cs.bc.edu/~muller/teaching/cs110105/f14/lib/html/textbooks.html
>
> They tell me it is very helpful.
>
> To me, what is needed to get ML-in-101 off the ground is simplicity:
>
> 1. a simple implementation/IDE that is trivial to install and "just
> works" on macs, Windows (and linux, I suppose), I am thinking of
> something like the experience I had in the past with Dr. Java.
> 2. a simple, no fuss library for graphics, animation and audio something
> like Sedgewick & Wayne's stdlib (http://algs4.cs.princeton.edu/code/)
> 3. decent error messages for both syntax errors and type errors.
>
> Ideally, I would prefer that both the IDE and the graphics/audio were
> hosted in a brower
> much like in Elm (http://elm-lang.org/).

Have you seen this? I've not used it but I believe it's related:

https://github.com/andrewray/iocaml

> I am only dimly aware of other universities teaching ML. I know that
> some folks in Denmark are using F#. Do you know if any schools in Europe
> are using OCaml in intro courses?

Here's a list, to which you can add yourself:

http://ocaml.org/learn/teaching-ocaml.html

We teach Standard ML at Cambridge, so we have even fewer tools :-) But
then we don't do anything graphical. Our first years do ML & Java, so
they get plenty of graphical / GUI work with Java.

Here's what our ML course looks like (and, basically, has done since 1994):

http://www.cl.cam.ac.uk/teaching/1415/FoundsCS/fcs-notes.pdf

-- 
John Whitington
Director, Coherent Graphics Ltd
http://www.coherentpdf.com/

Re: [Caml-list] teaching OCaml

[Drup]

There are custom toplevels for js_of_ocaml where you can experiment with 
reactive and interactive features, a bit like Elm's "IDE".

See https://github.com/ocsigen/js_of_ocaml#toplevel and 
http://ocsigen.github.io/js_of_ocaml/#version=4.02.0
The source code is [here][1] and should be quite easy to modify if you 
want to add a library (or modify the UI to make the drawing area bigger).

[1]: https://github.com/ocsigen/js_of_ocaml/tree/master/toplevel

Le 25/11/2014 19:21, John Whitington a écrit :
> Hi,
>
> Robert Muller wrote:
>> Thank you John. I will look at your graphics library, much appreciated.
>> I didn't require it this first time through but many of my students
>> bought your book:
>>
>> http://www.cs.bc.edu/~muller/teaching/cs110105/f14/lib/html/textbooks.html 
>>
>>
>> They tell me it is very helpful.
>>
>> To me, what is needed to get ML-in-101 off the ground is simplicity:
>>
>> 1. a simple implementation/IDE that is trivial to install and "just
>> works" on macs, Windows (and linux, I suppose), I am thinking of
>> something like the experience I had in the past with Dr. Java.
>> 2. a simple, no fuss library for graphics, animation and audio something
>> like Sedgewick & Wayne's stdlib (http://algs4.cs.princeton.edu/code/)
>> 3. decent error messages for both syntax errors and type errors.
>>
>> Ideally, I would prefer that both the IDE and the graphics/audio were
>> hosted in a brower
>> much like in Elm (http://elm-lang.org/).
>
> Have you seen this? I've not used it but I believe it's related:
>
> https://github.com/andrewray/iocaml
>
>> I am only dimly aware of other universities teaching ML. I know that
>> some folks in Denmark are using F#. Do you know if any schools in Europe
>> are using OCaml in intro courses?
>
> Here's a list, to which you can add yourself:
>
> http://ocaml.org/learn/teaching-ocaml.html
>
> We teach Standard ML at Cambridge, so we have even fewer tools :-) But
> then we don't do anything graphical. Our first years do ML & Java, so
> they get plenty of graphical / GUI work with Java.
>
> Here's what our ML course looks like (and, basically, has done since 
> 1994):
>
> http://www.cl.cam.ac.uk/teaching/1415/FoundsCS/fcs-notes.pdf
>

Re: [Caml-list] teaching OCaml

[Xavier Leroy]

> Robert Muller wrote:
>> Ideally, I would prefer that both the IDE and the graphics/audio
>> were hosted in a brower much like in Elm (http://elm-lang.org/).

A first step in this direction:  http://try.ocamlpro.com/

Not a full IDE, obviously, but already very useful for teaching the
basics.

- Xavier Leroy

Re: [Caml-list] teaching OCaml

[Daniel Bünzli]

Le mardi, 25 novembre 2014 à 17:03, robert.muller2@gmail.com a écrit :

> 2. GUIs: several of my problem sets work with simple graphics (e.g., rendering
> tessellations) or animations (e.g., a maze walk or a simplified form of
> tetris, or the game "Flow"). We have been hobbling along with the Graphics and
> Labltk modules for this but it has been more pain than my students ought to
> know.

You may want to have a look at Vg (http://erratique.ch/software/vg) which can be used both for offline (PDF, SVG) and interactive rendering (HTML canvas). Here are two small interactive examples (they are a little bit sluggish in ff though, needs investigation):

http://erratique.ch/software/useri/demos/chain.html
http://erratique.ch/tmp/2048.html


The later example is from an OCaml Labs OCaml tutorial available here: https://github.com/ocamllabs/2048-tutorial

Best,

Daniel

Re: [Caml-list] teaching OCaml

[Kenichi Asai]

Hi Bob,

I have been using OCaml as a teaching language for quite a while.

> 1. Error messages: It's difficult to give good type errors for ML but I was
> hoping that the state-of-the-art of type error reporting had improved. When my
> students receive a type error, they are utterly mystified,

Not directly addressing the error messages, but this spring, I used
our type debugger for OCaml in the introductory course.  By answering
questions, it leads you to the source of the type error, with better
error messages.  With proper instruction, I found that students
actually learn how OCaml types work from the interaction with the type
debugger.  It also introduces a few language levels which are good for
novices.

http://pllab.is.ocha.ac.jp/~asai/TypeDebugger/

(English error messages are not polished compared to Japanese error
messages.  Your feedback welcome.)

> 2. GUIs: several of my problem sets work with simple graphics (e.g., rendering
> tessellations) or animations (e.g., a maze walk or a simplified form of
> tetris, or the game "Flow"). We have been hobbling along with the Graphics and
> Labltk modules for this but it has been more pain than my students ought to
> know. We also have some problem sets that work with audio so I would like
> support for that.

One of my students is porting the universe teachpack of Racket into
OCaml, which enables easy game programming similarly to Racket.
I am now encouraging her to make the library public...

Sincerely,

-- 
Kenichi Asai

Re: [Caml-list] teaching OCaml

[Yaron Minsky]

For those following this thread because they're teaching with OCaml,
I really do recommend subscribing to teaching@ocaml.org.  We're
already starting to discuss better support in OPAM for teaching and
what's needed there, and it would be great to have everyone who has a
stake in this looped into that conversation.

Here's the link:

   http://lists.ocaml.org/listinfo/teaching

y

On Wed, Nov 26, 2014 at 6:37 AM, Kenichi Asai <asai@is.ocha.ac.jp> wrote:
> Hi Bob,
>
> I have been using OCaml as a teaching language for quite a while.
>
>> 1. Error messages: It's difficult to give good type errors for ML but I was
>> hoping that the state-of-the-art of type error reporting had improved. When my
>> students receive a type error, they are utterly mystified,
>
> Not directly addressing the error messages, but this spring, I used
> our type debugger for OCaml in the introductory course.  By answering
> questions, it leads you to the source of the type error, with better
> error messages.  With proper instruction, I found that students
> actually learn how OCaml types work from the interaction with the type
> debugger.  It also introduces a few language levels which are good for
> novices.
>
> http://pllab.is.ocha.ac.jp/~asai/TypeDebugger/
>
> (English error messages are not polished compared to Japanese error
> messages.  Your feedback welcome.)
>
>> 2. GUIs: several of my problem sets work with simple graphics (e.g., rendering
>> tessellations) or animations (e.g., a maze walk or a simplified form of
>> tetris, or the game "Flow"). We have been hobbling along with the Graphics and
>> Labltk modules for this but it has been more pain than my students ought to
>> know. We also have some problem sets that work with audio so I would like
>> support for that.
>
> One of my students is porting the universe teachpack of Racket into
> OCaml, which enables easy game programming similarly to Racket.
> I am now encouraging her to make the library public...
>
> Sincerely,
>
> --
> Kenichi Asai
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] teaching OCaml

[Marek Kubica]

Hi,

On Wed, 26 Nov 2014 20:37:38 +0900
Kenichi Asai <asai@is.ocha.ac.jp> wrote:

> Not directly addressing the error messages, but this spring, I used
> our type debugger for OCaml in the introductory course.  By answering
> questions, it leads you to the source of the type error, with better
> error messages.  With proper instruction, I found that students
> actually learn how OCaml types work from the interaction with the type
> debugger.  It also introduces a few language levels which are good for
> novices.
> 
> http://pllab.is.ocha.ac.jp/~asai/TypeDebugger/

If you're interested, I think we can add your patch directly into OPAM
repository, so your students won't have to download additional files
and place them in a hidden folder but everything works out of the box.

regards,
Marek

Re: [Caml-list] teaching OCaml

[Jonathan Kimmitt]

Dear Robert,
  Since you are thinking of switching to F#, without Microsoft bashing I do
feel I have to point out some of the shortcomings of their functional
language. First of all by using the CLR it runs rather slowly, especially
considering almost everything is an object. The second blunder is the re-
introduction of the NULL pointer, that beast of many horns which OCaml works
so hard to get rid of (Some _/None is the type-safe alternative). A further
complication for beginners is that the char type is unicode so it is not
possible to make use of nice syntax like "match ch with 'A'..'Z'". But the
real bugbear for teaching is that indentation is by default significant in the
syntax (instead of using ()/begin/end like OCaml). You can easily imagine the
wonderful results of importing an indentation specific language into Outlook
or Word to write an assignment given the cavalier attitude to line breaks
which is taken by the Office suite in general. I know there are supporters of
the lite syntax on the list but to me it is a can of worms, comparable to the
way that Outlook uppercases every word at the beginning of a line whether it
is the start of a sentence or not. Finally don't forget F# has operator
overloading so in a routine
"let f x y = x+y" instead of assuming x and y are integers as OCaml would do,
instead some obscure error message pops up such as "unable to infer type in
this context". Plus ça change plus c'est la même chose ..

RE: [Caml-list] teaching OCaml

[Jon Harrop]

Jonathan Kimmitt wrote:
> First of all by using the CLR it runs rather slowly, especially considering almost everything is an object.

That is certainly not true in general. Purely functional code is likely to be slower in F# than OCaml. Imperative and numerical code is likely to be faster in F# than OCaml. For example, hash tables with keys/values that are value types were several times faster on .NET than in OCaml, last I looked. And multicore code is likely to be a lot faster in F#, of course.

> The second blunder is the re- introduction of the NULL pointer, that beast of many horns which OCaml works so hard to get rid of (Some _/None is the type-safe alternative).

F# has both type safe Some|None and null. Note that you cannot interchange them accidentally in your program as null is not a valid value of any ordinary ML types in F# but you can still observe them quite easily:

> [Some 3; None];;
val it : int option list = [Some 3; null]

See the "null" creeping in there as the (design flawed) internal representation of None...

Also, .NET also provides a System.Nullable<T>.

On a related note, the two different syntaxes for parametric polymorphism tend to confuse students in my experience. F# offers both "int list" and "list<int>" to mean the same thing, which is rather ridiculous.

> A further complication for beginners is that the char type is unicode so it is not possible to make use of nice syntax like "match ch with 'A'..'Z'".

The syntax 'a'B and "Hello world!"B gives you ASCII chars and strings as bytes and byte arrays, respectively. You still cannot do 'A'B..'Z'B in a pattern though.

> But the real bugbear for teaching is that indentation is by default significant in the syntax (instead of using ()/begin/end like OCaml). You can easily imagine the wonderful results of importing an indentation specific language into Outlook or Word to write an assignment given the cavalier attitude to line breaks which is taken by the Office suite in general. I know there are supporters of the lite syntax on the list but to me it is a can of worms, comparable to the way that Outlook uppercases every word at the beginning of a line whether it is the start of a sentence or not.

Yes, that sucks. I suffer the most when pasting code from the web. And having translating some significant commercial code bases between OCaml and F# I can tell you that indentation sensitivity doesn't buy you much.

> Finally don't forget F# has operator overloading so in a routine "let f x y = x+y" instead of assuming x and y are integers as OCaml would do, instead some obscure error message pops up such as "unable to infer type in this context".

Operator overloading is a huge win over +, +., +|, +/ and so on though. And "1.2 + 2.3" giving a type error is not optimal. And the F# approach to operator overloading is the best of any language, IME, because any errors are local and you never take a performance hit for it.

From my point of view the OS is the elephant in the room here. If you're running Windows then OCaml is a disaster and F# wins hands down. If you're running Linux then F# is a disaster and OCaml wins hands down (although it'll be interesting to see what open source .NET for Linux does). This is true to the extent that I teach quite different courses in OCaml and F#. OCaml is great for metaprogramming with tools like lex and yacc but GUIs are an absolute nightmare. In F#, lexing and parsing are harder (I use active patterns) but GUIs are a piece of cake.

Cheers,
Jon.

[Caml-list] teaching OCaml

[Arthur Charguéraud]

[-- Attachment #1: Type: text/plain, Size: 3130 bytes --]

Hi Bob,

I have been teaching OCaml for a while, and like you I found error
messages to be a major issue. This motivated my recent work on
improving type error messages for OCaml.

My patch is ready for action.

opam switch 4.03.0+pr102
ocamlc -new-type-errors -strict-sequence test.ml

For more information: http://arthur.chargueraud.org/teach/ocaml/

If you have a chance to try it on beginners, please share your feedback!

Best,
Arthur Charguéraud


PS: I know of on-going efforts to try and improve parsing errors too
---it be great to have those fixed too.

PPS: although my patch is usable, I have planned to fix a few things.
- Have a two-column display for type errors on applications,
     with expected types and provided types.
- Remove bracket delimiters around types and use newlines instead.
- Have "-new-type-errors" imply "-strict-sequence",
- Document the fact it does not support GADTs, and does not
    typecheck with "-principal", in particular code that uses overloading
    of record fields.
- Isolate the code associated with "-new-type-errors" so that the patch
    may have a chance of being considered for integration in OCaml.


>
> Greetings. Bob Muller here, in the CS dept. at Boston College. I've set out to
> develop an intro CS course in ML that I hope will be well-suited for similar
> universities in the US. My original plan was to teach the course in SML but
> after talking with a few people at neighboring schools, I switched to OCaml. I
> am now in the final weeks of the first run of the course.  I plan to document
> my experience more fully at some point but I wanted to touch base with the
> OCaml community because I'm teaching the course again in the spring and I am
> leaning toward switching to F#.
>
> While OCaml has in many respects been great and it's easy to see that my
> students find the OCaml style of coding very compelling, there are significant
> problems. Of course, OCaml wasn't designed for teaching but I'm hoping that
> someone on this list might be able to advise me about solutions to some of
> these that I just don't know about.
>
> 1. Error messages: It's difficult to give good type errors for ML but I was
> hoping that the state-of-the-art of type error reporting had improved. When my
> students receive a type error, they are utterly mystified,
>
> 2. GUIs: several of my problem sets work with simple graphics (e.g., rendering
> tessellations) or animations (e.g., a maze walk or a simplified form of
> tetris, or the game "Flow"). We have been hobbling along with the Graphics and
> Labltk modules for this but it has been more pain than my students ought to
> know. We also have some problem sets that work with audio so I would like
> support for that.
>
> Any thoughts, ideas and/or leads on either of these would be much appreciated.
> I already plan to look at js_of_ocaml more closely.
> Thank you,
> Bob Muller
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs


[-- Attachment #2: Type: text/html, Size: 4568 bytes --]

Re: [Caml-list] teaching OCaml

[Alain Frisch]

On 11/25/2014 05:43 PM, Arthur Charguéraud wrote:
> - Document the fact it does not support GADTs, and does not
>     typecheck with "-principal", in particular code that uses overloading
>     of record fields.

Is it really what you mean?  I thought that your alternative 
type-checking rules would be coherent with the existing ones *provided* 
that -principal is enabled, so I'd expect this option to be forced when 
using your mode.


-- Alain

Re: [Caml-list] teaching OCaml

[Arthur Charguéraud]

Ah, sorry for the typo, I meant to say: "the patch is not guaranteed to 
report appropriate error messages for code that would not type-check 
with the -principal flag activated".

In other words, "the patch works as long as the the type-checking of the 
code does not depend on the order in which unifications are performed".

The reason is that the patch performs unification in a different order 
than the standard algorithm (precisely to avoid left-right bias).

Then, the question of whether "-new-type-error" should systematically 
compile all the code (including the one that does not contain type 
errors) using "-principal" is another question, I'm not sure what is the 
best choice.

+
Arthur


>
>> - Document the fact it does not support GADTs, and does not
>>     typecheck with "-principal", in particular code that uses 
>> overloading
>>     of record fields.
>
> Is it really what you mean?  I thought that your alternative 
> type-checking rules would be coherent with the existing ones 
> *provided* that -principal is enabled, so I'd expect this option to be 
> forced when using your mode.
>
>
> -- Alain

Re: [Caml-list] Teaching OCaml

[Brian Hurt]

On Thu, 3 Jun 2004, Jean-Christophe Filliatre wrote:

> 
> > >> Iif you want practical features of OCaml, you could try the classic
> > >> "QuickSort in n lines" where n depends on how efficient you want to
> > >> make it, but you can still achieve O(n log n) in something like 4
> > >> lines.  It takes 10 or so to be efficient, compared to at least 50 in
> > >> C.  Of course, Haskell has even nicer syntax for this, but it looks
> > >> good in O'Caml too.
> 
> I don't  think sorting is  a good example  of ocaml power  w.r.t other
> languages. If you are sorting arrays, an ocaml code and a C code won't
> differ so much and I don't see why the C code would be 10 times longer
> (the C syntax could even make it smaller). If you are sorting lists, I
> agree that ocaml syntax and  pattern matching would make the code much
> concise than the C equivalent.

I don't think any 10-line program shows off the real power of Ocaml.  
That's because Ocaml doesn't turn 100 line C programs into 10 line Ocaml 
programs, Ocaml turns 100,000 line C++ programs into 10,000 line Ocaml 
programs *that work correctly*.  Large programs are different from small 
programs.

An example of this.  100 line programs- in any language- are generally
simple enough I can hold the entire program in my head.  It's easy to spot
bugs in 100 line programs.  So a feature like immutable data structures
doesn't help you in writting 100 line programs.  In fact, it often hinders
you.  But when the two interacting peices of code are thousands, or tens
of thousands, of lines apart, spotting the interaction is a lot harder.  
Now, all of a sudden, immutability is a major advantage.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Teaching OCaml

[Simão Melo de Sousa]

It looks like my previous post never reached the caml-list.
So, accept my apologies if you receive my post twice.

------

Hi!

There is, in the Computer Science department of my university, a
interesting discussion about the programming languages that we should
teach.  Because I defend that functional programming (Haskell,
etc... but Ocaml in particular) has to be teach among other
"classical" paradigms, I have to prepare a talk about the relevance of
the functional programming paradigm in general and OCaml in
particular.

I know that this kind of topic have been already discussed and that
there is a lot of available "material". Nevertheless, I'm interested in
   any suggestions, links to papers, slides, sites...

I'm particularly interested in two kind of informations:

1) material (list of facts, etc..) that describes the good features of 
OCaml (in conceptual terms but also in pratical terms) from the point of 
view of both the Academy and the Industry.
2) url of Caml based functional programming courses sites

Thanks a lot!
Simao Melo de Sousa
ps: Use my email for answers, I will reply to the list with a digest of 
them.


-- 
------------------------------------------------------------------------
Simão Melo de Sousa            | Professor Auxiliar
* -> ., # -> @ => email Simão -> desousa#di*ubi*pt
Departamento de Informática    | http://www.di.ubi.pt/~desousa
Universidade da Beira Interior | Tel: +351 275 319 891
Rua Marquês d'Ávila e Bolama   | Fax: +351 275 319 732
6200-001 Covilhã, PORTUGAL.
------------------------------------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Teaching OCaml

[Michael Hamburg]

Hi.

A few thoughts on the subject.

Iif you want practical features of OCaml, you could try the classic  
"QuickSort in n lines" where n depends on how efficient you want to  
make it, but you can still achieve O(n log n) in something like 4  
lines.  It takes 10 or so to be efficient, compared to at least 50 in  
C.  Of course, Haskell has even nicer syntax for this, but it looks  
good in O'Caml too.

As for conceptual features, O'Caml is, as far as I know, the only  
functional language with OO, even if it is somewhat limited OO (due to  
type-system constraints).  For industrial projects, this enables  
programmers to work together more easily (or is intended to, anyway),  
while writing much less code than for most imperative languages.  For  
academics, it has been said that programmers, especially  
mathematicians, find functional programming very intuitive.

Just some suggestions,
Mike Hamburg

On May 17, 2004, at 7:28 AM, Simão Melo de Sousa wrote:

>
> It looks like my previous post never reached the caml-list.
> So, accept my apologies if you receive my post twice.
>
> ------
>
> Hi!
>
> There is, in the Computer Science department of my university, a
> interesting discussion about the programming languages that we should
> teach.  Because I defend that functional programming (Haskell,
> etc... but Ocaml in particular) has to be teach among other
> "classical" paradigms, I have to prepare a talk about the relevance of
> the functional programming paradigm in general and OCaml in
> particular.
>
> I know that this kind of topic have been already discussed and that
> there is a lot of available "material". Nevertheless, I'm interested in
>   any suggestions, links to papers, slides, sites...
>
> I'm particularly interested in two kind of informations:
>
> 1) material (list of facts, etc..) that describes the good features of  
> OCaml (in conceptual terms but also in pratical terms) from the point  
> of view of both the Academy and the Industry.
> 2) url of Caml based functional programming courses sites
>
> Thanks a lot!
> Simao Melo de Sousa
> ps: Use my email for answers, I will reply to the list with a digest  
> of them.
>
>
> --  
> ----------------------------------------------------------------------- 
> -
> Simão Melo de Sousa            | Professor Auxiliar
> * -> ., # -> @ => email Simão -> desousa#di*ubi*pt
> Departamento de Informática    | http://www.di.ubi.pt/~desousa
> Universidade da Beira Interior | Tel: +351 275 319 891
> Rua Marquês d'Ávila e Bolama   | Fax: +351 275 319 732
> 6200-001 Covilhã, PORTUGAL.
> ----------------------------------------------------------------------- 
> -
>
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives:  
> http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:  
> http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Teaching OCaml

[David Brown]

On Mon, May 17, 2004 at 01:27:02PM -0400, Michael Hamburg wrote:

> As for conceptual features, O'Caml is, as far as I know, the only  
> functional language with OO, even if it is somewhat limited OO (due to  
> type-system constraints).

There is O'Haskell <http://www.cs.chalmers.se/~nordland/ohaskell/>.  It
has some restriction on dynamic binding and inheritance, and I'm not
sure how widely it is used.  It seems to integrate well with Haskell's
existing class system, which already handles some of the OO aspects
(such as dynamic binding).

Dave Brown

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Teaching OCaml

[Richard Jones]

On Mon, May 17, 2004 at 01:27:02PM -0400, Michael Hamburg wrote:
> Hi.
> 
> A few thoughts on the subject.
> 
> Iif you want practical features of OCaml, you could try the classic  
> "QuickSort in n lines" where n depends on how efficient you want to  
> make it, but you can still achieve O(n log n) in something like 4  
> lines.  It takes 10 or so to be efficient, compared to at least 50 in  
> C.  Of course, Haskell has even nicer syntax for this, but it looks  
> good in O'Caml too.

Sorry, but why is this a "practical" feature of OCaml?

Anyone who uses OCaml to sort things will use List.sort, unless they
have incredibly specialist sorting requirements, in which they
certainly won't be using a 4-line implementation of quicksort.

Frankly I don't care how List.sort is implemented, as long as it's (a)
reasonably fast, and (b) bug free.  It may be implemented in C for all
I know/care.

OCaml is a practical language for many good reasons:

(a) Garbage collection, type safety and other features which mean that
many bugs appear at compile time, not when your program has been deployed
at a customer site.

(b) Ability to construct and pattern-match against data structures
almost effortlessly.  Data-driven analysis programs like the sort of
stuff I write for work are a joy to code with these features.

(c) Speed - it's fast enough, and can be very fast when you need it to
be.  I can chew through datasets of hundreds of thousands of rows from
an Apache logfile in much less than a second.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
MONOLITH is an advanced framework for writing web applications in C, easier
than using Perl & Java, much faster and smaller, reusable widget-based arch,
database-backed, discussion, chat, calendaring:
http://www.annexia.org/freeware/monolith/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Teaching OCaml

[Holger Schulz]

Am 18.05.2004 um 10:52 schrieb Richard Jones:

>> Iif you want practical features of OCaml, you could try the classic
>> "QuickSort in n lines" where n depends on how efficient you want to
>> make it, but you can still achieve O(n log n) in something like 4
>> lines.  It takes 10 or so to be efficient, compared to at least 50 in
>> C.  Of course, Haskell has even nicer syntax for this, but it looks
>> good in O'Caml too.
>
> Sorry, but why is this a "practical" feature of OCaml?

I'm not quite sure if it is a practical feature but it is an important 
aspect on teaching programming to have code which is easy to survey.

> Anyone who uses OCaml to sort things will use List.sort, unless they
> have incredibly specialist sorting requirements, in which they
> certainly won't be using a 4-line implementation of quicksort.

Hm, learning algorithms includes implementimg them, even if that has 
been done before.

By the way: are the 4 or 10 line source available online anywhere? I'd 
like to take a look at.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Teaching OCaml

[Evan Martin]

On Mon, May 17, 2004 at 12:28:54PM +0100, Simão Melo de Sousa wrote:
> There is, in the Computer Science department of my university, a
> interesting discussion about the programming languages that we should
> teach.  Because I defend that functional programming (Haskell,
> etc... but Ocaml in particular) has to be teach among other
> "classical" paradigms, I have to prepare a talk about the relevance of
> the functional programming paradigm in general and OCaml in
> particular.

By "OCaml in particular", do you mean the ML family of languages?

I'm currently a teacher's assistant in an introductory programming
languages class at the University of Washington (USA, in Seattle), in
which we've spent about half of the class using New Jersey SML:
Visit http://www.cs.washington.edu/341 for the course webpage, though it
doesn't discuss the motivations for choosing SML.  (The current
professor has indicated he wants to switch to OCaml but we're sticking
with SML for this quarter because that's what's been used in the past
and he's new here.)

(You weren't especially clear about the level of your class, so the rest
of this mail discusses teaching at the introductory level.)


Which programming language to teach as a "first Computer Science course"
is always under debate at this school; there's always tension between
teaching a language that is useful in the industry and teaching a
language that provides a good foundation for the concepts.

As for a class dedidicated to programming languages, I would say that
functional programming is of course important (there's a whole side of
history that includes LISP that feels like it's been more or less
forgotten by both the industry and the curriculum of school).  On top of
that, a language that forces you to be both careful and (sometimes)
explicit about types is a very valuable teaching tool.

Of course, Haskell fits that description as well as ML does.

To respond to some other threads: it seems doubtful to me that OCaml's
object oriented support would be useful for an introductory class.  I
think students who've only seen languages like Java have enough trouble
grasping currying.  :)

-- 
Evan Martin
martine@danga.com
http://neugierig.org

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Teaching OCaml

[Holger Schulz]

Am 17.05.2004 um 13:28 schrieb Simão Melo de Sousa:

> Because I defend that functional programming (Haskell,
> etc... but Ocaml in particular) has to be teach among other
> "classical" paradigms, I have to prepare a talk about the relevance of
> the functional programming paradigm in general and OCaml in
> particular.

Well perhaps some of the following are useful for you.

1. Functional languages usually come with an interpreter running a 
read-evaluate-print loop. That makes it easy to try examples very 
directly, i.e. without compiling, linking and stuff. The interpreter 
can easily be used for live presentations of examples.

2. In OCaml you have a (strong) type system. That makes the student 
think about the types of the objects they deal with. The type checkers 
gives an immediate response, wether they are right or not.

3. In OCaml you have functional, imperative and object orientated 
elements. Thus you can learn three paradigms within a unified syntax.

4. The imperative elements of OCaml fit into the type system, i.e. you 
have a type for references. That makes you learn the difference between 
a name (or identifier) and a reference (or allocated memory). That's 
better than talking of "variables" without knowing what could be ment. 
Moreover with ":=" or rather "<-" you have a meaningful denotation for 
the assignment, you can learn the difference between assigment and 
declaration.

4.' The intergration of objects and functional elements show that the 
implementation of methods in object orientation need not to be done 
(totally) functionally.

5. The behavior of functional languages can easily be described by 
semantic models using enviromnents only.

6. Usually students have varying levels of programming experience. Most 
experience comes from imperative and object orientated programming 
languages. The levels are equalizied a bit when using a programmnig 
language, which is not known by almost all students. And you have a 
chance to bring them away from corrupted programmnig styles, they 
learned elsewhere, on using a new language.

7. Functional programming makes it easy to implement mathematical 
definition. That can help unterstanding theoretical aspects.

Some argument are not on teaching OCaml but on teaching OCaml as the 
first language. Our students learn Java as their first languages, I 
don't think they learn to much on programming principles. And I think 
object orientation is hard to understand in the first year.

hs

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Teaching OCaml

[Nicolas Cannasse]

[...]
> Some argument are not on teaching OCaml but on teaching OCaml as the
> first language. Our students learn Java as their first languages, I
> don't think they learn to much on programming principles. And I think
> object orientation is hard to understand in the first year.

I personally think that OCaml should not be teached as first language. Just
let the students "enjoy" Java and Perl for few years, and when they'll later
eventually discover OCaml, after all that pain, they'll really be able to
enjoy it. That's a kind of programmer's Graal : the quest for it is a
teaching :)

Best Regards,
Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners