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

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

Browse thread
[oliver: Re: [Caml-list] OCaml popularity]
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-03-13 (01:34)
From: Michael Schuerig <schuerig@a...>
Subject: [Caml-list] OCaml popularity
On Thursday 13 March 2003 00:53, Oliver Bandel wrote:

[misadventure with Tk]
> But: I found out that this terrible OO-stuff is - again -
> a horror!

Are you sure the problem was with the OO part? It's hard to assess this, 
without knowing how well-versed you are in OO. As little as I know Tk, 
it doesn't make construction of a complex UI for a complex application 
particularly easy, but it doesn't make it impossible, either. Java's 
Swing, for all it's faults, does a lot for UIs that are well-structured 
in themselves and well-separated from the application core. More or 
less, it comes down to variations on the MVC (Model-View-Controller) 

In effect, all I can say is that OO in itself doesn't get in the way -- 
rather, in my opinion, it helps a lot. Just don't expect Good OO 
Programming to be any easier than Good O'Caml Programming.

Recommendation: "Agile Software Development" by Robert C. Martin 
(Prentice-Hall, 2003). See 

> (I have seen mess in Tcl/Tk-programming as well as
>  in OO-stuff for other applications (that was Java-stuff),
>  at least if the objects were splitted into too small
>  pieces (design-question; OO-gurus may tell you more abot this
>  problem)).

No guru here, but someone who thinks it's a good idea to split things 
into individual pieces that each do a single thing and can be tested 

> If there would be a more FP-like approach to GUI-programming
> - and that is what you have mentioned above with "what OCaml
> can contribute to GUI-programming" - then this would help
> a lot.

[GUI ideas snipped]

You're mostly dealing with the (comparatively) easy part: visual 
appearance. The hard part is setting things in motion: Reacting to user 
inputs and actions. Displaying data consistently (even after changes 
done in another place).

There are broadly tested and published ways of dealing with GUIs in the 
OO way. MVC, which I already mentioned, is the arch-pattern in this 
regard. Common OO languages help, as the idea of reactive objects that 
handle messages is natural to them.

I've only had very little exposure to purely-functional UIs. Several 
years ago I looked into how GUIs are done in Clean. It was interesting, 
possibly mind-expanding -- but, at least to me, far from intuitive.

>  - trees/hashtables/trees-of-hashtables which binds GUI-objects
>    to it's *function*s (if a GUI-object would be handled like
>    functions in FPLs, then you may use one button as a parameter
>    for a menue (or vice versa).... => higher-order /functional)
>    GUI-objects; GUI-objects as first-citizens...)

Have a look at this overview of the Swing architecture

[Typical database + GUI enterprise applications]
> > Could OCaml in this area bring such a big improvement
> > over, say, Java and J2EE?
> See above.

No, unfortunately not. You speculate a lot, but don't provide any usable 
solutions. Not that you're required to, of course. But current OO 
languages do have proven ways of dealing with the problems you've 

It's not my intention to disparage OCaml! But I'd like to point out that 
there currently doesn't seem to be a reason to believe that OCaml just 
needs some more libs and app servers to make a combo that's 
*decisively* superior to J2EE (and similar) for a class of very common 

> > Or are there other -- niche? -- areas where
> > the advantages OCaml provides are far more important?
> There are many areas, where OCaml could be important.

Being important is an interesting property in a research context. It 
doesn't make a language popular. The practically interesting areas are 
those, where OCaml provides a significant advantage over other 
languages. These may well be areas deserving of the moniker "difficult 
computing" (as quoted by Xavier in this thread). As a case in point, I 
remember Markus Mottl explaining recently in comp.lang.functional ("AI 
and functional programming") why he chose OCaml.


Michael Schuerig                       They tell you that the darkness
mailto:schuerig@acm.org                      is a blessing in disguise.
http://www.schuerig.de/michael/           --Janis Ian, "From Me To You"

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