Re: [Caml-list] OCaml on Windows please advise

[achrist@easystreet.com]

Nicolas Cannasse wrote:
> 
> You should perhaps consider packaging your Delphi GUI into a DLL with
> exported function and then have the OCaml Runtime be your startup. 

This is the problem with many of the non-mainstream languages.  
Compatible with ... is the the assertion, but the but is 'as long
as I get to be on top.'  With a GUI application, it is far more
natural (ie ignorant of other architectural possibilities, it seems
to me to be an easy choice) to have the user in charge, ie the user
as the client, and to have the various services (algorithms, databases, 
etc) in servers fulfilling whatever requests the user hurls in through
the GUI.  This design seems right because, with this type of design,
the servers can be de-coupled from the UI and can serve through the
GUI or through any of various other kinds of clients that we might
create.

With a fancy user-centric GUI in a DLL called from the OCaml runtime,
we've got 2-way coupling through some kind of callbacks (don't we? How
would that work?), and that's 1 more way than we really need.  IIRC,
coupling is bad.  An alternative is to have the server be a separate
executable and to have the client just pipe data through it using stdin,
stdout, or various files.  But the overhead of starting and waiting on
an exe makes this somewhat unattractive if the services are not fairly
coarse-grained.  

Your idea is a good one if the GUI is not user-centric.  For example, 
the so-called 'wizard' applications are task-centric, where there is
a predefined sequence of inputs required to complete a task and the
user gets led through the steps page-by-page or screen-by-screen. I
suppose that this kind of GUI could be rolled into a DLL that worked
well without callbacks.  But a system that relied on that style 
excessively would not be one that users liked.  I think that this 
issue is part of a larger culture clash between the unix/linus and
Windows/GUI worlds.  A strength of Unix/linux is that it offers many
small, reliable, single-function programs.  Windows succeeds by giving
the user the feeling/illusion of control, letting them pick from many
options at every turn, open and close Windows willy-nilly,  etc, etc.
This is a lot for OCaml to take in.

> It  seems easier because of the following :
> 
> - if you want an ocaml interpreter, you have to link your Delphi with 

Don't want an interpreter.  

Last I saw, COM was one of the best things that MS had conceived. 
That's extremely faint praise, but COM does look to be a good way to
partition a system into cohesive parts. With Windows as it currently
exists, being able to do COM as both a client and a server would be
a very nice feature for just about any language that targets Windows.

IDK if MS is going to de-emphasize COM and steer us toward building
systems out of .Net components that talk SOAP. Is SOAP a viable and
competitive alternative to COM for creating servers/services with
OCaml under MS-Windows?


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