[oliver: Re: [Caml-list] OCaml popularity]

[oliver@first.in-berlin.de (Oliver Bandel)]

----- Forwarded message from oliver -----

To: Michael Schuerig <schuerig@acm.org>
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 <function_call arg>
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