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 AAA03848; Thu, 13 Mar 2003 00:55:05 +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 AAA03549 for ; Thu, 13 Mar 2003 00:55:04 +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 h2CNt3X11531 for ; Thu, 13 Mar 2003 00: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 h2CNt3vp002244 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 13 Mar 2003 00:55:03 +0100 Received: from first.UUCP (uucp@localhost) by hirsch.in-berlin.de (8.12.8/8.12.8/Debian-2) with UUCP id h2CNt18K002233 for inria.fr!caml-list; Thu, 13 Mar 2003 00:55:01 +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 00:53:22 +0100 (CET) From: oliver@first.in-berlin.de (Oliver Bandel) Date: Thu, 13 Mar 2003 00:53:22 +0100 To: caml-list@inria.fr Subject: [oliver: Re: [Caml-list] OCaml popularity] Message-ID: <20030312235322.GA1154@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 anoying:01 alwyn:01 goodloe:01 prover:01 gui:01 screens:99 hmhhh:01 terrible:01 horror:99 splitted:01 knuth:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Well, forgotten the List. Was there a reply-to? Normally the message goes to the list... well... anoying... Ciao, Oliver ----- Forwarded message from oliver ----- To: Michael Schuerig Subject: Re: [Caml-list] OCaml popularity On Wed, Mar 12, 2003 at 11:34:34PM +0100, Michael Schuerig wrote: > On Wednesday 12 March 2003 19:08, Alwyn Goodloe wrote: > > I agree. This is really the difference between what most people do > > in industry and what we do in academia. People out there just don't > > care about how well you can build an automated theorem prover if they > > can't draw their GUI screens and access their Oracle data bases. > > Is software development in industry only about GUI screens, web pages > and database access? YES! > Well, from my own experience, I fear the answer is > mostly yes. ...hmhhh... I hoped for a different statement. :( > That being as it is, would things in industry be that much > better if OCaml had everything it takes for writing enterprise > applications? Well, some days ago I recently found out, that I once had tried to play around with Ocaml and it's tk-binding. Well, I've forgotten that experiments (I like CLI :)) and explored them again. And it's relativley few lines of code for that functionality (well, maybe Tcl has vewer lines in this special task, I think, but I have not compared it with tcl-scripts). But: I found out that this terrible OO-stuff is - again - a horror! Each little detail needs it's own object and message. This is terrible. Maybe it is possible to set global parameters for the Tk- variables, like style-sheets or something like this (I think in Tcl/TK it was possible to set such default-values). But if not thinking abot this, I have seen *again* that OO-stryle of programming yields to a cluttered code, at least when using it for setting Tk-GUI-parameters. But maybe there could be a better interface? I have not explored in detail, if it is the Tk, or the OO-stuff, that makes the code a mess, but I think, both approaches are part of the mess! (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)). 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. Maybe it is possible to put typographic conventions in a functional form (ask Mr. Knuth, please) and write a function, that creates values (e.g. polynomicl stuff? or even only a list of values?), which can be subsampled from the function (Stream(?)) and setting the GUI-parameters. So, what is needed for GUI-programming (and where OCaml could be a good language for) is: - global style parameters for the GUI ( hey, that's typography! :) ) - a function that can describe typographical stuff (e.g. how much the size of fonts in "small" depends on the base fontsize and os on - again, here Mr. Knuth (or typographers, or the people, who had implemented the many TeX-systems) could be asked for more details) - a good interface to this stuff - 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...) - powerful tools to handle the GUIs - higher-level functions/language for using it, someting like Gui.map or so or List.map #change_button_properties list_of_buttons_in_right_frame I'm not clear about what OCaml already have here, but *all* GUI-code (with labltk) I have seen, was cluttered like any OO-/TK- stuff. And that's not, what I'm looking for! There should be a language like menu1 - submen1 - subsubmen1a "Open File" open_in - subsubmen1b "Show File" print_string - subsubmen1c "Close File" close_in - submen2 - subsubmen2a "No function" print_string "no function!" - subsubmen2b "" raise exception Wrong_key and this could be added to a declaration of things like: menu: font=basefont=12pt submenu: font = smallfont(basefont) (* smallfont is based on typographical issues... ... maybe you should replace "basefont" here with menu.font or menu#font (s. comments at subsubmenue) *) subsubmenu: font = tinyfont(basefont) (* instead of basefont you may write menu#font or in dot-notation menu.font so that you have automatic adaption to changes of the font of the main-menu *) IMHO, the ocamlp4 and/or ocamllex/ocamlyacc-Gurus her on this mailinglist could write such stuff in some weeks or even some days. Is such a tool would be available (I hope good documented), I would use it, because I don't want to do that I-declare-each-button-individually idiots-tasks. > Could OCaml in this area bring such a big improvement > over, say, Java and J2EE? See above. If you can handle *many* objects of the gui in a more functional way, thei would make things easier and really easy and nice. > Or are there other -- niche? -- areas where > the advantages OCaml provides are far more important? There are many areas, where OCaml could be important. But sometimes I ask myself: Well, why are we looking for the big masses? As other peoples stated here: They are (almost everyone - but not all) idiots. But maybe they are idiots, because they need to be, to get the job and stay in job... 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