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 PAA30600; Thu, 13 Mar 2003 15:55:06 +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 PAA30521 for ; Thu, 13 Mar 2003 15:55:05 +0100 (MET) Received: from hirsch.in-berlin.de (hirsch.in-berlin.de [192.109.42.6]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h2DEt4X12682 for ; Thu, 13 Mar 2003 15:55:04 +0100 (MET) Received: from hirsch.in-berlin.de (localhost [127.0.0.1]) by hirsch.in-berlin.de (8.12.8/8.12.8/Debian-2) with ESMTP id h2DEt4mC022210 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 13 Mar 2003 15:55:04 +0100 Received: from first.UUCP (uucp@localhost) by hirsch.in-berlin.de (8.12.8/8.12.8/Debian-2) with UUCP id h2DEt3Zw022208 for inria.fr!caml-list; Thu, 13 Mar 2003 15:55:03 +0100 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: inria.fr!caml-list Received: by first.in-berlin.de via sendmail from stdin id (Debian Smail3.2.0.114) Thu, 13 Mar 2003 15:39:54 +0100 (CET) From: oliver@first.in-berlin.de (Oliver Bandel) Date: Thu, 13 Mar 2003 15:39:54 +0100 To: caml-list@inria.fr Subject: [oliver: Re: [Caml-list] OCaml popularity] Message-ID: <20030313143953.GA1646@first.in-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Spam: no; 0.00; oliver:01 in-berlin:01 bandel:01 caml-list:01 terrible:01 horror:99 assess:01 splitted:01 guis:01 gui:01 mvc:99 reactive:01 haskell:01 counted:01 behave:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk ----- Forwarded message from oliver ----- To: Michael Schuerig Subject: Re: [Caml-list] OCaml popularity On Thu, Mar 13, 2003 at 02:34:16AM +0100, Michael Schuerig wrote: > 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, [...] OK, thanks for the links, I will browse them. But nevertheless I'm looking for OCaml-like solutions. And the Tk-stuff looks weird to me. > > (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. Yes, you even can write parsers in OO, and there are Design Patterns for it. But functional programming makes more sense to me here. Well, in GUIs there OO does makes sense. But using a more functional approach might help here too. > > > > 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). I added this too. There are functions which are bind to each appearence of a GUI-object. Look at the stuff. When I can't express how it has to look like to match my needs, then the reason is, that even well-experienced FP/OOP/IP-people have there no functional solution. If I had one, I would not ask for it while explaining, what I'm looking for. If I would know how to solve it, I had written a solution or a paper about such a project. Well, what I have written in my examples looks more like an aequivalent to tools like lex/yacc are and maybe could be called guilex/guiyacc. > > 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. Yes, that is the problem with OO: sometimes problems are bloating up, when splitting up problems into objects. For GUIs OO might be a good choice; but as long as it is not tested that FP doesn't help here, I will insist on such a solution. > > 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. There is at least one GUI-approach with Haskell. Looked very clean and good, but needs Haskell-experience (and Monads-stuff). So I have this in mind, and maybe come back later to this. There was no object-mess. [...] > [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. When there are hundreds of FP-programmers do not offer solutions (not counted the one haskell-approach), and many-thousands of OO-programmers are throwing around their OO-mess, how should I (not computer science studied; have studied electrical engeneering) provide a solution? When looking at the code, I know what's good and wrong, even if I'm not able to find the correct words in computer-science terms. (But even 95% of those computer studied people would not be able to do that; and worse: they would not be able to see the difference in the code.) Writing in FP is like having functions, that behave determined; when looking at OO-stuff, it looks like a stochastical process. Well I like stochastics-stuff, and markov modells are nice. :) But there is a difference, when I want to program. Then I like it non-stochastical. And that's the reason, why I like that FP-stuff. It's not dividing things apart, which should be handled as a whole. > Not that you're required to, of course. But current OO > languages do have proven ways of dealing with the problems you've > encountered. OK, I will look at your links. [...] > > > 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. I'm now a t a point, where the popularity is not so much a matter to me. I want to learn and to use that language. If other people want not, it's their problem. Maybe with the right marketing/communication, you also can write OCaml-programs and sell them. And I'm not part of a team. I work as a one-person-team. So I have not disadvantagesm, but advantages, when I use OCaml, and others not. :) > The practically interesting areas are > those, where OCaml provides a significant advantage over other > languages. It does provide significant advantages, as I recently found out even in comparing with Perl - and I used Str-module in the OCaml-part and Perl on the other side. The OCaml-stuff was clearer in code and faster developed. If you had asked me this in the beginnings of my OCaml- journey, I would have said (and I had said that), that I think, that OCaml might be good for larger projects, but not for scrippting. But even there it is better! It provides significant adcantage(s) and that makes the language important (to me). > 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. Thanks for that hint. I will read his articles. (But I don't think that he will apologize OO there... well let's look.) Ciao, Oliver ----- End forwarded message ----- ------------------- 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