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 <schuerig@acm.org>
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 <arg1>
                - subsubmen1b "Show File" print_string <read_in_file arg1>
                - subsubmen1c "Close File" close_in <arg1>

      - 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