Re: [Caml-list] Re: javacaml

[Gerd Stolpmann <gerd@gerd-stolpmann.de>]

On Fri, 06 Apr 2001, Xavier Leroy wrote:
>> Don't misunderstand me: mlj is excellent work if you take it
>> academically, but the authors argue that it is also usable for
>> practical purposes, and this is the reason why I am amuzed. The
>> better conclusion from the facts in the mlj paper is that it is not
>> practicable to compile ML to Java bytecode.
>
>I agree with your conclusions, however you're perhaps slightly too
>harsh with MLj: for developing applet-sized programs, for instance,
>the limitations of MLj (whole-program compilation, size limitations)
>are acceptable.

You are right. I'm quite impressed from the techniques MLj applies, and the
thing I'm wondering is that somebody really went such a long way only to get an
alternate language for applets. Maybe these techniques are interesting
anyway, and MLj is only an example. 

>> - Why isn't there an O'Caml plugin for Mozilla? In many environments, you do
>>   not need a sandbox, e.g. within intranets, and code signing suffices.
>
>François Rouaix hacked together a Caml plugin for Netscape a few years
>ago.  It sort of worked (under Unix and with Caml actually running in
>a different process and communicating over a pipe), but he sort of
>lost interest in it.  I have doubts on the cleanliness and stability
>of the Netscape plugin API :-)  Also, the same technical tricks might
>not work under Windows...

I never programmed with the plugin API, so I don't know anything about the
stability. The Mozilla source code is now available, and I think this makes it
much easier to work around instable parts.

>At any rate, I believe Web applets are a totally uninteresting
>application area.  Most Web designers seem happy with JavaScript
>hacks, and in many years of intense Web surfing, I came across an
>interesting Java applet only once (Certicom's excellent tutorial on
>elliptic curve cryptography).

I have already seen several interesting applets, but these are commerical
intranet applets you don't find in the internet.

I'm doing much Web development, and the current rationale is to do as much as
possible at the server side. This has several reasons:

- Every browser version has its own set of bugs, and using less features of the
  browsers makes it less likely that bugs play a role

- There are only two languages that are usually available in browsers:
  Javascript and Java. Javascript is good to better control the GUI elements
  and to write adaptors betweem several parts of the application. However, you
  cannot really write bigger programs. Java is rather heavy-weight (development
  costs; applet load time) and is only used for special tasks, e.g. complex
  visualizations.

This is of course a bit unsatisfactory. In the near future, we will have
stable browsers that can dynamically change the HTML tree (with lots of
interesting applications), but I fear the two browser languages are not very
well suited for such dynamic web apps. Javascript is too lightweight, and in
Java you would need to program many steps for every dialog event.

I think an O'Caml plugin with access to the DOM tree (and DOM events) and that
can do some own networking would be a very nice programming environment. (I
don't want an alternative to Java, but an alternative to Javascript.)

>> - Why isn't there a version of the bytecode interpreter that can dynamically
>>   load libraries? (I know that there is a patch, but nothing
>>   official.)       
>
>Because I'm lazy.  And it's a somehow more subtle change than you think.  
>(The patch you mention misses a number of issues.)

I know it's more than just to apply the patch.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr