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

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

[Oliver Bandel]

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

Date: Thu, 13 Mar 2003 01:29:47 +0100
To: Michael Schuerig <schuerig@acm.org>
Subject: Re: [Caml-list] OCaml popularity
Message-ID: <20030313002947.GB1197@first.in-berlin.de>
References: <Pine.GSO.4.44.0303121258020.5464-100000@gradient.cis.upenn.edu> <200303122334.34982.schuerig@acm.org> <20030312231352.GC372@phaeton.entropie.net> <200303130035.39823.schuerig@acm.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <200303130035.39823.schuerig@acm.org>
User-Agent: Mutt/1.3.28i
Status: RO
Content-Length: 2978
Lines: 88

On Thu, Mar 13, 2003 at 12:35:39AM +0100, Michael Schuerig wrote:
> On Thursday 13 March 2003 00:13, Martin Weber wrote:
> > I don't know what usually classifies as 'enterprise application' but
> > I think what I'm doing is one - application(s) written solely for the
> > use within the producing corner - no end user will ever see it
> 
> In my experience, the term "enterprise application" is not used 
> generically for all custom or behind-the-scenes application used in an 
> enterprise. Rather, it's used more specifically for applications that 
> handle large amounts of data managed in databases; stuffing data into 
> and getting it out of a DB and accomodating business processes while 
> doing so.

Well, when reasoning about data-structures, OCaml could provide
much here.
But IMHO, this area is absolutely a high-performance field.

And when you retrieve a lot of data, then every little
performance lack (which is not worth talking about, the little
quantity of some thousands of datasets or so) will
cause long waiting times for the application and the user...

So, if in high-end-perormance OCaml will be fast enough
in "real-world applications", not only in selected
benchmarks, is not proven yet!

But nevetrheless: Programming is a kind of social
task, and the companies normally will not rely
on a small amaount of programmers, which can't be
substituted by other programmers!
There are to view OCaml-programmers for a decision
in Companies to use that language.

So you have to use C/C++ for the next decade there,
IMHO. (But I hope that there are some niches, where
OCaml could be used here too.)



> 
> I've been working on this kind of software for a couple of years and 
> can't say that I'm particularly attracted to it. To be sure, I 
> recognize that there are interesting aspects to it,

Well, there is a lot of trees, and sorting and such stuff
internally in the databases. If they (the databases) would
be more than a row-oriented SQL-engine, and able
to communicate directly to a datastructure in your
program, that would be nice. :)
A typesafe database. :)


Using the newly created toplevel with database.cma:

# let my_db = Database.create_database (type my_example_db = int * Mytype of int*string) 100000
val my_db : my_example_db = [...]


Wouldn't that be nice?


Maybe it's necessary not to *adapt* OCaml to a database,
but *implement* a database with OCaml!


BTW: using a type-declaration as a parameter for a function...
...that seems unusual to me, and not fitting OCaml-language.
Or could it be possible?

If this is bull...., please show me, how such a stuff like
above could look like, when using OCaml (or "enhanced-OCaml"...).

if this could not implemented directly in Ocaml, maybe
a camlp4-solution could help here?





> but it's not what I 
> myself find interesting. Also, as I said before, I don't see that OCaml 
> provides a decisive advantage for *this* kind of software.

Sould be, IMHO (see above).


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

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

[Brian Hurt]

On Thu, 13 Mar 2003, Oliver Bandel wrote:

[ RE: enterprise apps ]

> Well, when reasoning about data-structures, OCaml could provide
> much here.
> But IMHO, this area is absolutely a high-performance field.
> 
> And when you retrieve a lot of data, then every little
> performance lack (which is not worth talking about, the little
> quantity of some thousands of datasets or so) will
> cause long waiting times for the application and the user...

I know a couple of people who work in this field, and from their
experiences the #1 with a bullet delay is the database.  They spend a lot
of time optimizing their queries and table structures (where you put
indexes, etc).  And no time what so ever optimizing their code, because it
just doesn't matter.  If the DB query is going to take 15 minutes, it's
not going to matter much if the code firing off the query takes 1ms or
100ms.  In code, they look for ease of development and maintainance more 
so than performance.

Which is why Java took off *despite* it's earlier (and, to a certain 
extent, continuing) performance problems.  

> So you have to use C/C++ for the next decade there, IMHO. (But I hope
> that there are some niches, where OCaml could be used here too.)

Java is huge, but PowerBuilder (still), VisualBasic, and Perl all have
signifigant market shares.

Brian


-------------------
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

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

[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

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

[Oliver Bandel]

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

To: Brian Hurt <brian.hurt@qlogic.com>
Subject: Re: [Caml-list] OCaml popularity

On Wed, Mar 12, 2003 at 05:47:16PM -0600, Brian Hurt wrote:
[...]
> Having *the* perfect introductory book is actually a detriment, as 
> it discourages other books from entering the field, thus reducing your 
> runnning foot total.  Likewise, being intuitive or easy to understand is 
> also a detriment, as this makes both for fewer books and for slimmer 
> books.  Much better to have multi-thousand page tomes (tombs?).  And 
> naturally, you can't measure running feet of web pages :-).


Having *NO* such an introductional book, and only
high-graded PhD-stuff, would you call this a
detriment too?

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

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

[Oliver Bandel]

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