From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id CAA06123; Thu, 13 Mar 2003 02:34:19 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id CAA06055 for ; Thu, 13 Mar 2003 02:34:18 +0100 (MET) Received: from post.webmailer.de (natsmtp00.webmailer.de [192.67.198.74]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h2D1YIX14276 for ; Thu, 13 Mar 2003 02:34:18 +0100 (MET) Received: from pD952EC32.dip.t-dialin.net (pD952EC32.dip.t-dialin.net [217.82.236.50]) by post.webmailer.de (8.12.8/8.8.7) with ESMTP id h2D1YGIS009279 for ; Thu, 13 Mar 2003 02:34:17 +0100 (MET) From: Michael Schuerig Organization: - To: caml-list@inria.fr Subject: [Caml-list] OCaml popularity Date: Thu, 13 Mar 2003 02:34:16 +0100 User-Agent: KMail/1.5 References: <20030312235322.GA1154@first.in-berlin.de> In-Reply-To: <20030312235322.GA1154@first.in-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303130234.16647.schuerig@acm.org> X-Spam: no; 0.00; oliver:01 bandel:01 terrible:01 horror:99 assess:01 java's:01 mvc:99 splitted:01 gui:01 guis:01 reactive:01 hashtables:01 fpls:01 higher-order:01 jfc:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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) pattern. 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 http://www.objectmentor.com/resources/articleIndex > (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 separately. > 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 http://java.sun.com/products/jfc/tsc/articles/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 encountered. 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 applications. > > 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 -- 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