From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA11495; Sun, 8 Apr 2001 22:51:27 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA11490 for caml-list@pauillac.inria.fr; Sun, 8 Apr 2001 22:51:27 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id XAA11027 for ; Fri, 6 Apr 2001 23:54:21 +0200 (MET DST) Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f36LsK519630; Fri, 6 Apr 2001 23:54:20 +0200 (MET DST) Received: from [195.20.224.219] (helo=mrvdom03.kundenserver.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 14leBN-0004yw-00; Fri, 6 Apr 2001 23:54:17 +0200 Received: from drms-3e364b87.pool.mediaways.net ([62.54.75.135] helo=ice.gerd-stolpmann.de) by mrvdom03.kundenserver.de with esmtp (Exim 2.12 #2) id 14leBH-0006ui-00; Fri, 6 Apr 2001 23:54:12 +0200 Received: from localhost (localhost [[UNIX: localhost]]) by ice.gerd-stolpmann.de (8.9.3/8.9.3) id XAA10485; Fri, 6 Apr 2001 23:52:13 +0200 From: Gerd Stolpmann Reply-To: gerd@gerd-stolpmann.de Organization: privat To: Xavier Leroy Subject: Re: [Caml-list] Re: javacaml Date: Fri, 6 Apr 2001 23:10:47 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: Chris Hecker , caml-list@inria.fr References: <200103292240.OAA22134@smtp5-cm.mail.eni.net> <01040500354406.00489@ice> <20010406172752.C1347@pauillac.inria.fr> In-Reply-To: <20010406172752.C1347@pauillac.inria.fr> MIME-Version: 1.0 Message-Id: <0104062352120D.00489@ice> Content-Transfer-Encoding: 8bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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