Teaching bottomline, part 3: what should improve.

Teaching bottomline, part 3: what should improve.

[David Teller]

Third and (probably) last part of my Teaching bottomline. I hope some of
you find this useful.


Let's start by problems I didn't cause.

= Not my fault =

== Environment ==

* OCamlWinPlus, in its current incarnation, is just awful. To improve
it, one would need to fix the bugx, make it possible to remember the
list of modules loaded, link it to the documentation, etc.


* Camelia IDE is simple and good but difficult to install, as it
requires Cygwin. It lacks project management, though -- and, now,
ocamlbuild support. I believe that it could draw some inspiration from
Dr.Java.


* Students just can't install LablGtk, LablGl, Camlimage... by
themselves, nor would I expect them to. A nice, centralised, installer,
would be nice.


* Building projects is just too hard. I hope ocamlbuild will solve this.


* It seems that Graphics doesn't work with Cygwin, hence with Camelia
for Windows. Which is bad, as they seem to enjoy both Graphics and
Camelia. What prevents Graphics in Cygwin+X ?


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


== Documentation ==

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


* Type 'option' doesn't appear in the list of types of the
documentation. Nor do 'Some' and 'None' appear in the list of values.


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


= My fault =

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

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

* Some students rely too much on references.

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

* Anonymous functions are still beyond most of them.





-- 
David Teller ------------------------------------------
Security of Distributed Systems -----------------------
-- http://www.univ-orleans.fr/lifo/Members/David.Teller
----- Laboratoire d'Informatique Fondamentale d'Orleans

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

[William D. Neumann]

On Tue, 22 May 2007, David Teller wrote:

> * Type 'option' doesn't appear in the list of types of the
> documentation. Nor do 'Some' and 'None' appear in the list of values.

Huh?  It's there in section 19.1 of the manual -- Built-in types and 
pre-defined exceptions.

William D. Neumann

---

"There's just so many extra children, we could just feed the
children to these tigers.  We don't need them, we're not doing 
anything with them.

Tigers are noble and sleek; children are loud and messy."

         -- Neko Case

Life is unfair.  Kill yourself or get over it.
 	-- Black Box Recorder

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

[David Teller]

Indeed, but not in Appendix V, "Index of types" and "Index of values".
Which is the right place to look for this kind of information.

Cheers,
 David

On Tue, 2007-05-22 at 16:22 -0600, William D. Neumann wrote:
> On Tue, 22 May 2007, David Teller wrote:
> 
> > * Type 'option' doesn't appear in the list of types of the
> > documentation. Nor do 'Some' and 'None' appear in the list of values.
> 
> Huh?  It's there in section 19.1 of the manual -- Built-in types and 
> pre-defined exceptions.
> 
> William D. Neumann

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

[Erik de Castro Lopo]

David Teller wrote:

> Third and (probably) last part of my Teaching bottomline. I hope some of
> you find this useful.

Thanks David. I'm not even a teacher (well not currently) and I
still found that an interesting read.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Copyrighting allows people to benefit from their labours, 
but software patents allow the companies with the largest 
legal departments to benefit from everyone else's work."
-- Andrew Brown
(http://www.guardian.co.uk/online/comment/story/0,12449,1387575,00.html)

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

[skaller]

On Tue, 2007-05-22 at 18:10 -0400, David Teller wrote:

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

This is a long standing peeve of mine. Lets face it: Ocaml just lies.
If it has inferred a type, then finds a contradiction, it should
report both the location of the contradication AND all of the source
lines that contributed to the inference.

I understand that is may be hard, if not impossible, to implement,
as it would require a unification engine that could manage
source references in parallel with deductions .. still the information
IS available originally.

I bet this would be an interesting and valuable PhD project,
and, IMHO, without it type inferencing languages are useless
in industry. Type errors in Ocaml code are very common for the
simple reason they're just about the only error you can make :)


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

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

[David Thomas]

Would it be possible for this to be an option?  I
mean, it seems like the information is at least
available on another pass through the code.  Twice the
compilation time in some cases will typically win out
over minutes-to-hours trying to figure out where it
inferred THAT.


--- skaller <skaller@users.sourceforge.net> wrote:

> On Tue, 2007-05-22 at 18:10 -0400, David Teller
> wrote:
> 
> > * 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.
> 
> This is a long standing peeve of mine. Lets face it:
> Ocaml just lies.
> If it has inferred a type, then finds a
> contradiction, it should
> report both the location of the contradication AND
> all of the source
> lines that contributed to the inference.
> 
> I understand that is may be hard, if not impossible,
> to implement,
> as it would require a unification engine that could
> manage
> source references in parallel with deductions ..
> still the information
> IS available originally.
> 
> I bet this would be an interesting and valuable PhD
> project,
> and, IMHO, without it type inferencing languages are
> useless
> in industry. Type errors in Ocaml code are very
> common for the
> simple reason they're just about the only error you
> can make :)
> 
> 
> -- 
> John Skaller <skaller at users dot sf dot net>
> Felix, successor to C++: http://felix.sf.net
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
>
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list:
> http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 



       
____________________________________________________________________________________Ready for the edge of your seat? 
Check out tonight's top picks on Yahoo! TV. 
http://tv.yahoo.com/

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

[Vincent Hanquez]

On Wed, May 23, 2007 at 09:16:44AM +1000, skaller wrote:
> On Tue, 2007-05-22 at 18:10 -0400, David Teller wrote:
> 
> > * 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.
> 
> This is a long standing peeve of mine. Lets face it: Ocaml just lies.
> If it has inferred a type, then finds a contradiction, it should
> report both the location of the contradication AND all of the source
> lines that contributed to the inference.

I agree, this is one of the worst thing about ocaml type inference,
and you sometimes end up to have to put explicit type to functions to
find the offending lines (usually hundreds lines before the actual line
that's printed), defeating the whole thing...

Cheers,
-- 
Vincent Hanquez

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

[Brian Hurt]

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

Vincent Hanquez wrote:

>On Wed, May 23, 2007 at 09:16:44AM +1000, skaller wrote:
>  
>
>>On Tue, 2007-05-22 at 18:10 -0400, David Teller wrote:
>>
>>    
>>
>>>* 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.
>>>      
>>>
>>This is a long standing peeve of mine. Lets face it: Ocaml just lies.
>>If it has inferred a type, then finds a contradiction, it should
>>report both the location of the contradication AND all of the source
>>lines that contributed to the inference.
>>    
>>
>
>I agree, this is one of the worst thing about ocaml type inference,
>and you sometimes end up to have to put explicit type to functions to
>find the offending lines (usually hundreds lines before the actual line
>that's printed), defeating the whole thing...
>
>Cheers,
>  
>

Hundreds of lines?  I've seen ten's of lines, but never hundreds.

Of course, I generally type annotate at the level of functions at least 
(using .mli files is to be encouraged, IMO).  So type errors generally 
don't escape functions.  And I keep functions reasonably short- tens of 
lines long at most...

Brian


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

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

[Gerd Stolpmann]

Am Mittwoch, den 23.05.2007, 08:49 -0400 schrieb Brian Hurt:
> Vincent Hanquez wrote:
> > On Wed, May 23, 2007 at 09:16:44AM +1000, skaller wrote:
> >   
> > > On Tue, 2007-05-22 at 18:10 -0400, David Teller wrote:
> > > 
> > >     
> > > > * 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.
> > > >       
> > > This is a long standing peeve of mine. Lets face it: Ocaml just lies.
> > > If it has inferred a type, then finds a contradiction, it should
> > > report both the location of the contradication AND all of the source
> > > lines that contributed to the inference.
> > >     
> > 
> > I agree, this is one of the worst thing about ocaml type inference,
> > and you sometimes end up to have to put explicit type to functions to
> > find the offending lines (usually hundreds lines before the actual line
> > that's printed), defeating the whole thing...
> > 
> > Cheers,
> >   
> 
> Hundreds of lines?  I've seen ten's of lines, but never hundreds.

I can confirm that: hundreds. This happens especially for mismatching
class types, because the compiler tries to break the mismatch down.

But beginners shouldn't use classes.

> Of course, I generally type annotate at the level of functions at
> least (using .mli files is to be encouraged, IMO).  So type errors
> generally don't escape functions.  And I keep functions reasonably
> short- tens of lines long at most...

There is certainly a point. The length of type errors depends on your
programming style. A teacher can give hints how to make everything
easier to handle. (Although it is also a valid point in education to let
the students find their limits.)

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------

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

[skaller]

On Wed, 2007-05-23 at 15:36 +0200, Gerd Stolpmann wrote:

> 
> There is certainly a point. The length of type errors depends on your
> programming style. 

It can also depend on the size of the type involved,
which is not nearly as much of a stylistic thing.

If you have several polymorphic variants types of
20-30 constructors each, recursively included in
each other .. you can get errors many hundreds of lines
long, involving scores of invented type variables, and
for me, when i get such errors, the information in the 
diagnostic is more or less entirely useless.

I use the error location and knowledge of my last
change to track down where to add coercions and
annotations to help find the error ..

I got one a couple of days ago in code generated
by dypgen .. and just gave up .. since I didn't write
the code and had no idea what the types were (my
types were involved too .. the combination was
a type about 80 lines long .. :)

Ocaml has improved though: today it often gives a nasty
message and the kindly tells you which constructor is
causing the mismatch. This helps a LOT!


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

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

[Florian Hars]

Brian Hurt schrieb:
> Hundreds of lines?  I've seen ten's of lines, but never hundreds.

Not only hundreds of lines, but usually in a completely different file, too.

This expression has type exactly_what_it_should be, but is here used with
type compeletly_off_the_mark.

How I hate it.

Yours, Florian.

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

[Brian Hurt]

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

Florian Hars wrote:

>Brian Hurt schrieb:
>  
>
>>Hundreds of lines?  I've seen ten's of lines, but never hundreds.
>>    
>>
>
>Not only hundreds of lines, but usually in a completely different file, too.
>
>This expression has type exactly_what_it_should be, but is here used with
>type compeletly_off_the_mark.
>
>How I hate it.
>
>  
>

.mli files.  Use them.  Trust me.

Simply because code compiles doesn't necessarily mean it's right.  Often 
times I write the .mli file first, as it's a convient level to think 
about what the interface to a module should be.  But at the very least 
you should use ocamlc -i to generate the .mli file when you are more or 
less done with the module, and then hand verify it as correct.  And then 
keep it around, to make sure the module remains correct in the face of 
future changes.  Doing this will keep type errors in the same file, at 
least.

Brian



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

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

[Vincent Hanquez]

On Wed, May 23, 2007 at 08:49:57AM -0400, Brian Hurt wrote:
> Hundreds of lines?  I've seen ten's of lines, but never hundreds.

It's happening sometimes, and it's a major pain. It usually because you
got the wrong type returned, and you got lots of passthrough functions.
when it gets into the function that actually do something with the data,
ocaml see a mismatch obviously... in this case you want to correct the
source function, not where the error happened ...

> Of course, I generally type annotate at the level of functions at least 
> (using .mli files is to be encouraged, IMO).  So type errors generally 
> don't escape functions.  And I keep functions reasonably short- tens of 
> lines long at most...

this is certainly a very good thing to do, but some people doesn't do
this unfortunately :(

For .mli file, it's not always an advantage to have them; having 2
files to edit each time you make a modification is quite annoying..
I wish there was an inline signature ala Haskell for OCaml, something
along the line of:

=== string.ml ====
val length : string -> int
....

let length s = ...
....
==================

Cheers,
-- 
Vincent Hanquez

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

[Markus E.L.]

> For .mli file, it's not always an advantage to have them; having 2
> files to edit each time you make a modification is quite annoying..
> I wish there was an inline signature ala Haskell for OCaml, something
> along the line of:
>
> === string.ml ====
> val length : string -> int
> ....
>
> let length s = ...
> ....
> ==================


let len (s :string) : int = ... ?

Regards -- M

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

[Vincent Hanquez]

On Thu, May 24, 2007 at 10:04:21AM +0200, Markus E.L. wrote:
> let len (s :string) : int = ... ?

yes I know about this but I'ld rather create and modify an .mli than
have this horrible syntax inlined in the implementation.

The signature code (the one in sig end) is nice, and I want to use that
for describing my functions, so that implementation and description
stays reasonably distinct. OCaml let you do that inline when you
create a module in a file:

module xx : sig
  ....
end = struct
  ....
end

but for a file (which is also a module), you need to have a separate
file (a .mli) to do that.. and that's my point.

Cheers,
-- 
Vincent Hanquez

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

[skaller]

On Thu, 2007-05-24 at 10:32 +0200, Vincent Hanquez wrote:
> On Thu, May 24, 2007 at 10:04:21AM +0200, Markus E.L. wrote:

> OCaml let you do that inline when you
> create a module in a file:
> 
> module xx : sig
>   ....
> end = struct
>   ....
> end
> 
> but for a file (which is also a module), you need to have a separate
> file (a .mli) to do that.. and that's my point.

Can't you can fix that by:

module xx : sig .. end = struct
..
end include xx

That way all the symbols you want are in the .ml
file.

However this isn't really the same as

private val f: int -> int
let f x = ..

which can be done by:

let f (x:int):int = ..

the problem being it is invasive (you have to
edit the function decl instead of writing a 
separate type decl).

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

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

[Vincent Hanquez]

On Thu, May 24, 2007 at 07:51:02PM +1000, skaller wrote:
> Can't you can fix that by:
> 
> module xx : sig .. end = struct
> ..
> end include xx
> 
> That way all the symbols you want are in the .ml
> file.

Yes that would kind of work, however that generate an ugly signature
with ocamlc -i (I know i'm beeing difficult here ;))

> However this isn't really the same as
> 
> private val f: int -> int
> let f x = ..
> 
> which can be done by:
> 
> let f (x:int):int = ..
> 
> the problem being it is invasive (you have to
> edit the function decl instead of writing a 
> separate type decl).

I like the separation personally. Haskell has it, and I found it quite neat.

Cheers,
-- 
Vincent Hanquez

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

[David Teller]

On Wed, 2007-05-23 at 09:16 +1000, skaller wrote:
> On Tue, 2007-05-22 at 18:10 -0400, David Teller wrote:
> 
> > * Error messages of the type system are somewhat obscure. 

[...]

> I understand that is may be hard, if not impossible, to implement,
> as it would require a unification engine that could manage
> source references in parallel with deductions .. still the information
> IS available originally.

I tend to believe that there is a simple solution to the problem (I
haven't looked at Dan Grossman's paper yet): re-run the typing of the
last function and print out the hypothesis and each unification as it
happens.

> I bet this would be an interesting and valuable PhD project,
> and, IMHO, without it type inferencing languages are useless
> in industry. 

I concur.

> Type errors in Ocaml code are very common for the
> simple reason they're just about the only error you can make :)

:)

-- 
David Teller ------------------------------------------
Security of Distributed Systems -----------------------
-- http://www.univ-orleans.fr/lifo/Members/David.Teller
----- Laboratoire d'Informatique Fondamentale d'Orleans

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

[skaller]

On Tue, 2007-05-22 at 18:10 -0400, David Teller wrote:

> * Students just can't install LablGtk, LablGl, Camlimage... by
> themselves, nor would I expect them to. A nice, centralised, installer,
> would be nice.

This sound like your School's fault. Why aren't they running
Debian or Ubuntu?

Because on those systems .. installing Ocaml packages is a breeze.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

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

[Richard Jones]

On Wed, May 23, 2007 at 09:19:20AM +1000, skaller wrote:
> On Tue, 2007-05-22 at 18:10 -0400, David Teller wrote:
> 
> > * Students just can't install LablGtk, LablGl, Camlimage... by
> > themselves, nor would I expect them to. A nice, centralised, installer,
> > would be nice.
> 
> This sound like your School's fault. Why aren't they running
> Debian or Ubuntu?
> 
> Because on those systems .. installing Ocaml packages is a breeze.

Just what I was going to say!

Hopefully it'll be a breeze on Fedora soon too.

Rich.

-- 
Richard Jones
Red Hat

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

[David Teller]

That's a non-argument, I'm afraid. You can't demand the (unenthusiastic)
administrator and all students to install Linux just for one lecture. I
mean, I guess I could, but for a lecture titled "Algorithmics,
Functional Programming", that's a bit drastic.

Cheers,
 David


On Wed, 2007-05-23 at 11:41 +0100, Richard Jones wrote:
> On Wed, May 23, 2007 at 09:19:20AM +1000, skaller wrote:
> > On Tue, 2007-05-22 at 18:10 -0400, David Teller wrote:
> > 
> > > * Students just can't install LablGtk, LablGl, Camlimage... by
> > > themselves, nor would I expect them to. A nice, centralised, installer,
> > > would be nice.
> > 
> > This sound like your School's fault. Why aren't they running
> > Debian or Ubuntu?
> > 
> > Because on those systems .. installing Ocaml packages is a breeze.
> 
> Just what I was going to say!
> 
> Hopefully it'll be a breeze on Fedora soon too.
> 
> Rich.
> 
-- 
David Teller ------------------------------------------
Security of Distributed Systems -----------------------
-- http://www.univ-orleans.fr/lifo/Members/David.Teller
----- Laboratoire d'Informatique Fondamentale d'Orleans

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

[Richard Jones]

On Wed, May 23, 2007 at 09:04:06AM -0400, David Teller wrote:
> That's a non-argument, I'm afraid. You can't demand the (unenthusiastic)
> administrator and all students to install Linux just for one lecture. I
> mean, I guess I could, but for a lecture titled "Algorithmics,
> Functional Programming", that's a bit drastic.

Live CDs might be a solution ...

Building a custom Live CD isn't too easy, although apparently there
are sites which do it now.

Rich.

-- 
Richard Jones
Red Hat

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

[Robert Fischer]

Building a Knoppix disk with a custom selection of software and a page 
that boots whenever its loaded (to explain what you just did to your 
student's computer and where their Windows went) isn't too bad.  I'd 
suggest the "Knoppix Hacks" book from O'Reilly for help on this.

I'd be willing to do this as a moonlighting gig, if someone had some 
budget to burn.

Robert Fischer
IT Firefighter
Smokejumper Consulting


Richard Jones wrote:
> On Wed, May 23, 2007 at 09:04:06AM -0400, David Teller wrote:
>   
>> That's a non-argument, I'm afraid. You can't demand the (unenthusiastic)
>> administrator and all students to install Linux just for one lecture. I
>> mean, I guess I could, but for a lecture titled "Algorithmics,
>> Functional Programming", that's a bit drastic.
>>     
>
> Live CDs might be a solution ...
>
> Building a custom Live CD isn't too easy, although apparently there
> are sites which do it now.
>
> Rich.
>
>   

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

[Jon Harrop]

On Wednesday 23 May 2007 14:04:06 David Teller wrote:
> That's a non-argument, I'm afraid. You can't demand the (unenthusiastic)
> administrator and all students to install Linux just for one lecture.

You realise this is as easy as putting a Knoppix CD in your drive and 
rebooting into Linux directly from the CD?

If you can't afford anything and they can't afford anything then this is 
easily your best course of action.

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

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

[Robert Fischer]

Now that I'm thinking about it, it's probably the route I'm going to go 
for my presentation on Test Driven Development with OCaml  for Agile 
2007 -- I don't have a Mac or a Linux laptop kicking around (former is 
too expensive, latter won't get wireless working for me), but I 
definitely want to be in Linux for development.

So, if you're willing to wait until the early Augustish timeframe, I 
might have just such a LiveCD to share.

Robert Fischer
IT Firefighter
Smokejumper Consulting


Jon Harrop wrote:
> On Wednesday 23 May 2007 14:04:06 David Teller wrote:
>   
>> That's a non-argument, I'm afraid. You can't demand the (unenthusiastic)
>> administrator and all students to install Linux just for one lecture.
>>     
>
> You realise this is as easy as putting a Knoppix CD in your drive and 
> rebooting into Linux directly from the CD?
>
> If you can't afford anything and they can't afford anything then this is 
> easily your best course of action.
>
>   

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

[David Teller]

Last time I checked, we needed the BIOS password to boot on anything
besides the internal HD. Still, I might be able to convince the
administrator to let me boot on CD.

Thanks for the suggestion,
 David

On Thu, 2007-05-24 at 15:00 +0100, Jon Harrop wrote:
> On Wednesday 23 May 2007 14:04:06 David Teller wrote:
> > That's a non-argument, I'm afraid. You can't demand the (unenthusiastic)
> > administrator and all students to install Linux just for one lecture.
> 
> You realise this is as easy as putting a Knoppix CD in your drive and 
> rebooting into Linux directly from the CD?
> 
> If you can't afford anything and they can't afford anything then this is 
> easily your best course of action.
> 

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

[skaller]

On Wed, 2007-05-23 at 09:04 -0400, David Teller wrote:
> That's a non-argument, I'm afraid. You can't demand the (unenthusiastic)
> administrator and all students to install Linux just for one lecture. I
> mean, I guess I could, but for a lecture titled "Algorithmics,
> Functional Programming", that's a bit drastic.

Heck no, I'd demand they eradicate Windows entirely,
it has no place in institutions of any kind.

One sensible government has already banned closed
source software in all departments (Peru).

There really is NO excuse for publically funded institutions
to continue to waste taxpayer money on insecure operating
environments which don't meet the most basic principles 
or western democracy, namely open government. Since it
is software that implements most decisions of the legislature,
the software should be open to public scrutiny, and
the principle should descend to other institutions which
are expected to be accountable.

Universities should take the lead, because in the event
of a problem they have inhouse resources -- namely students --
who can fix them.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

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

[Jon Harrop]

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

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

[Richard Jones]

On Wed, May 23, 2007 at 12:39:29AM +0100, Jon Harrop wrote:
> 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.

F# scales to hundreds or thousands of cores?

If the OP wants to teach his students about massively parallel
computing, he should avoid the Microsoft lock-in and teach them about
it on Linux clusters.

Rich.

-- 
Richard Jones
Red Hat

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

[Robert C Fischer]

...and locks and threads are not a viable long-term solution to the 
problem of concurrency in general.  You're future-proofing enough by 
teaching them functional languages: Erlang and Cilk are closer to the 
needed future.

~~ Robert.

Richard Jones wrote:
> On Wed, May 23, 2007 at 12:39:29AM +0100, Jon Harrop wrote:
>   
>> 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.
>>     
>
> F# scales to hundreds or thousands of cores?
>
> If the OP wants to teach his students about massively parallel
> computing, he should avoid the Microsoft lock-in and teach them about
> it on Linux clusters.
>
> Rich.
>
>   

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

[Brian Hurt]

Robert C Fischer wrote:

> ...and locks and threads are not a viable long-term solution to the 
> problem of concurrency in general.  You're future-proofing enough by 
> teaching them functional languages: Erlang and Cilk are closer to the 
> needed future.
>
I think you mean "Haskell+STM" instead of Cilk.  Cilk isn't a 
particularly functional language (being effectively C plus a little bit).

Brian

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

[Robert Fischer]

Granted, although I haven't played with Haskell+STM: the point I was 
trying to make was that we need to be denoting parallelism instead of 
implementing it.  To that end, functional languages are better for that 
kind of work (due to their disdain of side effects, if nothing else).

Robert Fischer
IT Firefighter
Smokejumper Consulting



Brian Hurt wrote:
> Robert C Fischer wrote:
>
>> ...and locks and threads are not a viable long-term solution to the 
>> problem of concurrency in general.  You're future-proofing enough by 
>> teaching them functional languages: Erlang and Cilk are closer to the 
>> needed future.
>>
> I think you mean "Haskell+STM" instead of Cilk.  Cilk isn't a 
> particularly functional language (being effectively C plus a little bit).
>
> Brian
>
>

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

[Jon Harrop]

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

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

[Jacques Garrigue]

From: Jon Harrop <jon@ffconsultancy.com>

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

But... this is exactly the kind of things for which you can already
use concurrency in ocaml. For instance, lablgtk2 provides a GtkThread
module, which lets you run the GUI in another thread, and post updates
asynchronously. This is also possible with labltk, albeit not
documented.
I do not say this is elegant in its current form, but we are limited
by the underlying library.

There are weaknesses, like the fact you cannot kill a worker thread,
but this looks like a limitation of posix threads, since you can do it
with bytecode threads.

Jacques Garrigue

Revolution

[Jon Harrop]

On Wednesday 23 May 2007 23:14:05 Jacques Garrigue wrote:
> But... this is exactly the kind of things for which you can already
> use concurrency in ocaml. For instance, lablgtk2 provides a GtkThread
> module, which lets you run the GUI in another thread, and post updates
> asynchronously. This is also possible with labltk, albeit not
> documented.
> I do not say this is elegant in its current form, but we are limited
> by the underlying library.

I appreciate the limitations of the existing GUI libraries on Linux. I'll try 
to translate some of the examples from the tutorials into F# and show you the 
difference.

I'm going to let you in on a recurring dream of mine. Ever since I saw how 
easy .NET makes GUI and web programming, and ever since I saw the demos of a 
Windows GUI based on hardware-accelerated vector graphics in Vista, Windows 
Presentation Foundation and now Silverlight, I have wanted to see this on 
Linux.

The fact is, the OCaml community are extraordinarily talented and I've been 
sitting on the OCaml translation of our hardware-accelerated vector graphics 
engine for years. We are in the process of translating this into F# for 
Windows:

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

and we already have customers.

Is there any chance that we can team up to produce Linux's Vista- and 
Silverlight-killer and write the whole thing in OCaml?

Here are my ideas:

1. A new GUI library written in a functional style that renders controls as 
vector graphics via Smoke. Everything is rendered using OpenGL but abstracted 
behind Smoke.

2. Typesetting graphical IDEs for programming with integrated visualization.

3. A document format to replace HTML that provides mathematical typesetting 
and embedded, scriptable 2D and 3D vector graphics, and a browser to 
view/edit these documents.

Does anyone else find this idea awe inspiring?

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

Re: [Caml-list] Revolution

[skaller]

On Thu, 2007-05-24 at 02:38 +0100, Jon Harrop wrote:

> Here are my ideas:
> 
> 1. A new GUI library written in a functional style that renders controls as 
> vector graphics via Smoke. Everything is rendered using OpenGL but abstracted 
> behind Smoke.

> Does anyone else find this idea awe inspiring?

Just one problem: OpenGL has a non-reentrant interface.
How anyone could be allowed to get away with this utter
garbage today I don't know. But the implication is you need
to provide a GUI server with a proper design, which requires
some work. Some operations can be done in parallel and some
must be serialised and some don't make sense unless explicitly
synchronised.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Revolution

[Chris King]

On 5/23/07, Jon Harrop <jon@ffconsultancy.com> wrote:
> 1. A new GUI library written in a functional style that renders controls as
> vector graphics via Smoke. Everything is rendered using OpenGL but abstracted
> behind Smoke.

I don't know anything about Smoke, but part of my secret plan behind
my O'Caml Reactive Toolkit project is to allow one to develop a pretty
GUI widget set using OpenGL (or Cairo or what-have-you) and have much
of the GUI functionality (such as layout management) already there.
Whether I get as far as implementing an OpenGL-based widget set in the
nine weeks I'm working with Jane St. Capital remains to be seen (I
sort of doubt it, given the amount of other work I'll have), but I'm
keeping that goal in mind as I design it so the infrastructure to
support it will be there.

(Re OpenGL reentrancy, in O'Caml RT multiple OpenGL contexts are
handled in such a way that they are invisible to the user.)

I've also been considering the possibility of writing the library in
such a way that it also compiles under F#, or compiles with a few
changes, but right now I don't know enough about F# to know whether
that's at all possible (especially since I make use of objects,
polymorphic variants, and private types for software engineering
purposes, and would like to avoid giving them up).

- Chris

Re: [Caml-list] Revolution

[David Teller]

On my side, I've just started working on the (module) interfaces for
simplified, declarative, UI creation. Aims to be slightly more readable
and customisable than [what I've seen of] your work, Chris, but based
essentially on the same ideas.

If this module interface brings anything interesting, I'll be sure to
warn the list.

On the other hand, I'd be very interested in participating to the
development of a functional, cross-platform, GUI library that could be
deployed with OCaml.

Cheers,
 David

On Wed, 2007-05-23 at 23:21 -0400, Chris King wrote:
> On 5/23/07, Jon Harrop <jon@ffconsultancy.com> wrote:
> > 1. A new GUI library written in a functional style that renders controls as
> > vector graphics via Smoke. Everything is rendered using OpenGL but abstracted
> > behind Smoke.
> 
> I don't know anything about Smoke, but part of my secret plan behind
> my O'Caml Reactive Toolkit project is to allow one to develop a pretty
> GUI widget set using OpenGL (or Cairo or what-have-you) and have much
> of the GUI functionality (such as layout management) already there.
> Whether I get as far as implementing an OpenGL-based widget set in the
> nine weeks I'm working with Jane St. Capital remains to be seen (I
> sort of doubt it, given the amount of other work I'll have), but I'm
> keeping that goal in mind as I design it so the infrastructure to
> support it will be there.
> 
> (Re OpenGL reentrancy, in O'Caml RT multiple OpenGL contexts are
> handled in such a way that they are invisible to the user.)
> 
> I've also been considering the possibility of writing the library in
> such a way that it also compiles under F#, or compiles with a few
> changes, but right now I don't know enough about F# to know whether
> that's at all possible (especially since I make use of objects,
> polymorphic variants, and private types for software engineering
> purposes, and would like to avoid giving them up).
> 
> - Chris
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

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

[Brian Hurt]

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

Jon Harrop wrote:

>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.
>  
>
The problem is not so much expressing the parallelism (especially 
data-level parallelism), it's dealing with the consequences- especially 
the race conditions and deadlocks that result.  How do you gaurentee 
that the function passed into the parallel iter, map, or fold is 
appropriately reentrant?

>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.).
>
>  
>
Yep.  The advantage of data-level parallelism is that it scales with the 
amount of data.  You can always use more processors simply by throwing 
more data at the program.  The problem is that it is of limited 
applicability, and that a lot of problems don't fit well (or at all) in 
it.  The advantage of event/message based parallelism is that it is more 
widely applicable, the problem is that it doesn't scale- if you write 
your ap with N threads, it'll use up to about N processors- but the 
N+1st  processor will be useless.  This is a problem because the current 
proper formulation of Moore's law is that the number of processors 
available is doubling every 18-24 months (maybe faster).

Brian


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

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

[Jon Harrop]

On Wednesday 23 May 2007 19:54:28 Richard Jones wrote:
> ... he should avoid the Microsoft lock-in ...

Then he should not be using Microsoft Windows.

I think Linux users should use OCaml and Windows users should use F#. Anything 
else is just perverted.

I suspect the reality is that both Windows and zero-budget have been imposed 
upon David, which is simply insane because Windows is a very expensive 
commercial platform and the quality of free software on Windows is far below 
that on Linux.

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

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

[David Teller]

On Wed, 2007-05-23 at 00:39 +0100, Jon Harrop wrote:
> 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#:

I mentioned F# to them, by the way. Somewhere along the lines of "It looks
good, it might be the future, unfortunately, at the moment, you need Windows and 400€
worth of Visual Studio to try it".


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

Not my call, unfortunately. So far, I have no budget, and Windows.

> > * Error messages of the type system are somewhat obscure. [...]
> F# currently has better graphical throwback of inferred type information but 
> slightly worse messages, IMHO.

Good to know. Can I get this graphical throwback without VS ?

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

There's no way I'm going to demand additional purchases from my
students.

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

Div and mod ? How so ?


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

Well, I didn't have enough time to tell them much about threads et al. I
just had time to mention their existence.

Plus I tend to believe that the OCaml-style future looks more like
JoCaml (or Acute, or Oz, or Erlang) than like semaphores.

Cheers,
 David

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

[Jon Harrop]

On Wednesday 23 May 2007 21:20:57 David Teller wrote:
> On Wed, 2007-05-23 at 00:39 +0100, Jon Harrop wrote:
> > 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#:
>
> I mentioned F# to them, by the way. Somewhere along the lines of "It looks
> good, it might be the future, unfortunately, at the moment, you need
> Windows and 400€ worth of Visual Studio to try it".

This blog entry implies that F# works with free editions of Visual Studio:

  http://grammerjack.spaces.live.com/blog/cns!F2629C772A178A7C!156.entry

I'll try F# on a machine without the commercial Visual Studio ASAP and see if 
I can get it working.

> So far, I have no budget, and Windows.

Could they boot the machines into Linux at the start of each lecture?

> Can I get this graphical throwback without VS ?

I do not believe so although there are some free IDEs:

  http://sourceforge.net/projects/sharpedit/

> Div and mod ? How so ?

Div and mod by constants are not optimized by the OCaml compiler, which can 
lead to pathological performance on some programs (e.g. sieve, sudoku).

> Plus I tend to believe that the OCaml-style future looks more like
> JoCaml (or Acute, or Oz, or Erlang) than like semaphores.

Except for Erlang, none of those languages have a significant number of users 
today. I haven't tried Erlang but it may be worth a look.

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

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

[skaller]

On Wed, 2007-05-23 at 16:20 -0400, David Teller wrote:
> On Wed, 2007-05-23 at 00:39 +0100, Jon Harrop wrote:
> > 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#:
> 
> I mentioned F# to them, by the way. Somewhere along the lines of "It looks
> good, it might be the future, unfortunately, at the moment, you need Windows and 400€
> worth of Visual Studio to try it".

You do? Doesn't it run on Visual Studio Express .. which is 
completely free?

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net