JIT-compilation for OCaml?

JIT-compilation for OCaml?

[Markus Mottl]

Hello,

one thing I just wondered about is whether there are any intentions
concerning a JIT-compiler for OCaml byte code similar to what Java
offers. This would allow much faster execution while still retaining
full portability of the byte code. Is this a goody we might expect in the
(near? far?) future?

- Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

RE: JIT-compilation for OCaml?

[Mattias Waldau]

Why do you want JIT? Do you use Java for regular development? It is a pain,
the reason is

1. Slow, slow
2. Big, big

and the reason that Java gets away with it, is the JIT-compiler. That mean
that after enormous start-time, the program might achieve resonable
performance after a couple of minutes. However, at that time, it still needs
10-20 extra megs, since the compiler is still loaded into memory.

The beatty of Ocaml are the fast compilers, the optimizing compiler is
faster than javac, which only produces bytecode. It is sad that so few
other programming language developers realizes that the speed of the
development environment matters.

The only thing Ocaml can learn from Java is its libraries. If I would invent
a programming language with a library today, I would just copy Java's
interface. Libraries are much harder to learn than programming languages,
thus standards are needed.


/mattias



-----Original Message-----
From: Pierre.Weis@inria.fr [mailto:Pierre.Weis@inria.fr]On Behalf Of
Markus Mottl
Sent: Tuesday, January 02, 2001 5:08 PM
To: OCAML
Subject: JIT-compilation for OCaml?


Hello,

one thing I just wondered about is whether there are any intentions
concerning a JIT-compiler for OCaml byte code similar to what Java
offers. This would allow much faster execution while still retaining
full portability of the byte code. Is this a goody we might expect in the
(near? far?) future?

- Markus Mottl

--
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: JIT-compilation for OCaml?

[Markus Mottl]

On Tue, 02 Jan 2001, Mattias Waldau wrote:
> Why do you want JIT?

I don't need it currently, but I can imagine applications that greatly
benefit from it.

> Do you use Java for regular development? It is a pain,

No, I don't use it at all, but I believe you that it must be very
painful ;)

> the reason is
> 
> 1. Slow, slow
> 2. Big, big

Maybe that's because the Java JIT-compilers were not written by Xavier? ;)

> and the reason that Java gets away with it, is the JIT-compiler. That mean
> that after enormous start-time, the program might achieve resonable
> performance after a couple of minutes. However, at that time, it still needs
> 10-20 extra megs, since the compiler is still loaded into memory.

It shouldn't be too difficult to come up with a protocol that informs
the interpreter whether it should actually use JIT-compilation or not
and if yes, how it should compile the code for optimum performance, etc.

This meta information could be generated by passing options to the byte
code compiler or maybe even by some kind of pragmas in the source. Or
maybe by a magnificent program analysis tool that finds the "hot spots"
automatically.

> The beatty of Ocaml are the fast compilers, the optimizing compiler is
> faster than javac, which only produces bytecode.

But the JIT-compiled/interpreted byte code seems to be pretty fast: I have
tried it with a few mini-benchmarks to see whether this JIT-technology
is of any worth. Really not bad...

> It is sad that so few
> other programming language developers realizes that the speed of the
> development environment matters.

Certainly! I definitely don't want to replace the normal byte code
interpreter with a purely JIT-one. My motivation was rather portability +
speed rather than speed alone. For the latter "ocamlopt" is more than
good enough, and for portability we have the byte code compiler. But
if you want to have portability with reasonable speed for demanding
applications...

> The only thing Ocaml can learn from Java is its libraries. If I would invent
> a programming language with a library today, I would just copy Java's
> interface. Libraries are much harder to learn than programming languages,
> thus standards are needed.

I haven't tried the Java-libraries so far. The OCaml-ones are quite
usable, but if you can tell us what Java has that OCaml is missing,
just tell us (in time! ;)

- Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: JIT-compilation for OCaml?

[Alain Frisch]

Hello,

my 0.02 euros ideas about a JIT for OCaml:

There are basically two ways to JIT-compile a bytecode program: at
startup or during runtime.

Compiling the bytecode at startup makes sense for instance for web
distributed code (applets). Otherwise, if the code is to be used more than
once by a given user, it's better to convert statically the bytecode to
native code. Hacking ocamlrun to produce native code simply by expanding
each opcode from the abstract machine seems fairly easy. Some
optimizations are lost. Another idea would be to make the compiler
outputs the "lambda" intermediate code (shared between ocamlc and
ocamlopt) and distribute it, maybe with some modification to
prevent reverse engineering. The backend of ocamlopt (code generation)
is run by the user to produce an executable program.

Compiling the code really during runtime opens the door to further
optimizations (I guess this is how Java JIT compilers work, but I have no
idea). For instance, it is possible to watch conditionnal jumps and
reorganize the code so that the most taken branches don't need any jump.
The GC and the memory allocator have the opportunity to adapt themselves
to the application. Of course, this only makes sense for long running
applications. The user should be able to record the optimization
information collected. Actually, there are two operations involved: a
profiler (a bytecode interpreter that also collects optimization
information) and a bytecode-to-nativecode converter as in the previous
paragraph. I don't see the advantage of mixing them in a complex JIT
compiler (which will be slow for a long time after startup if the
optimizations are non trivial).


Happy new year to everybody !


-- 
  Alain Frisch

Re: JIT-compilation for OCaml?

[Fabrice Le Fessant]

> Hacking ocamlrun to produce native code simply by expanding
> each opcode from the abstract machine seems fairly easy. Some
> optimizations are lost.

This has already been done by Piumarta & Riccardi (PLDI'98 ?) on the
ocaml system, version 2.04 I think.

> Another idea would be to make the compiler outputs the "lambda"
> intermediate code (shared between ocamlc and ocamlopt) and distribute
> it,

The lambda code is not exactly the same for both bytecode and native
code. This is however not a really big problem. It would probably be a
good solution, since using both dynamic linking and ocamlopt, we can
generate assembler files and then load them dynamically ...

> , maybe with some modification to prevent reverse engineering.

Don't understand what you want. Reverse engineering is always
possible ... 

> For instance, it is possible to watch conditionnal jumps and
> reorganize the code so that the most taken branches don't need any
> jump.

This has nothing to do with JIT. Using profiling information can also
be done for statically compiled programs, by recompiling them with
this information. (this is already done by many compilers).

- Fabrice

Re: JIT-compilation for OCaml?

[Alain Frisch]

On Thu, 4 Jan 2001, Fabrice Le Fessant wrote:

> > , maybe with some modification to prevent reverse engineering.
> 
> Don't understand what you want. Reverse engineering is always
> possible ... 

I meant: making it more laborious. For instance by changing the name of
identifiers or the structure of the code. I know that Java bytecode has
been blamed for allowing straightforward reverse engineering by
recognizing standard patterns associated to constructions in the source.
For OCaml, the lambda representation may be already far enough from
the source code.

> > For instance, it is possible to watch conditionnal jumps and
> > reorganize the code so that the most taken branches don't need any
> > jump.
> 
> This has nothing to do with JIT. Using profiling information can also
> be done for statically compiled programs, by recompiling them with
> this information. (this is already done by many compilers).

My point, precisely. If the JIT can't make the code run faster than
a static bytecode-to-nativecode converter, that is, if it doesn't use
any profiling information, I don't see how it is useful.


--
  Alain

RE: JIT-compilation for OCaml?

[Mattias Waldau]

If you just want portability, then why not generate Java-byte code instead
of Ocaml-bytecode. Then you can distribute you Ocaml-applications in Jars.
And you can benefit from the JIT of SUN etc, for example SUN's latest JIT
called HotSpot.

This has been done for many languages, for example JPython.

See http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html for more examples.

/mattias

> Certainly! I definitely don't want to replace the normal byte code
> interpreter with a purely JIT-one. My motivation was rather portability +
> speed rather than speed alone. For the latter "ocamlopt" is more than
> good enough, and for portability we have the byte code compiler. But
> if you want to have portability with reasonable speed for demanding
> applications...

Re: JIT-compilation for OCaml?

[Markus Mottl]

On Wed, 03 Jan 2001, Mattias Waldau wrote:
> If you just want portability, then why not generate Java-byte code instead
> of Ocaml-bytecode. Then you can distribute you Ocaml-applications in Jars.
> And you can benefit from the JIT of SUN etc, for example SUN's latest JIT
> called HotSpot.

This would be a (pragmatic) possibility. As far as I have heard, OCaml
byte code has advantages over and/or is cleaner than Java byte code. I
am not competent here to judge this - details anybody?

- Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

RE: JIT-compilation for OCaml?

[STARYNKEVITCH Basile]

>>>>> "Mattias" == Mattias Waldau <mattias.waldau@tacton.se> writes:

    Mattias> If you just want portability, then why not generate
    Mattias> Java-byte code instead of Ocaml-bytecode. 

It is well known (e.g. see the Kawa implementation of Scheme on the
JVM) that the Java Virtual Machine is not well suited for functional
programming: function closures and tail-recursion calls (which are
actually jump with arguments) do not exist in the JVM, and emulating
them (e.g. closures as instances of specially generated classes) is
quite inefficient. The JVM is not as universal as Sun's marketing hype
claim it is...

On the contrary the Ocaml virtual machine was (of course) designed for
functional programming, and efficiently implement tails calls and
closure constructions.

Regards and Happy New Year to all,

N.B. Any opinions expressed here are only mine, and not of my organization.
N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA.

---------------------------------------------------------------------
Basile STARYNKEVITCH   ----  Commissariat à l Energie Atomique 
DTA/LETI/DEIN/SLA * CEA/Saclay b.528 (p111f) * 91191 GIF/YVETTE CEDEX * France
phone: 1,69.08.60.55; fax: 1.69.08.83.95 home: 1,46.65.45.53
email: Basile point Starynkevitch at cea point fr 
web perso: http://perso.wanadoo.fr/starynkevitch/basile/

Re: JIT-compilation for OCaml?

[John Max Skaller]

Markus Mottl wrote:

> > the reason is
> >
> > 1. Slow, slow
> > 2. Big, big
> 
> Maybe that's because the Java JIT-compilers were not written by Xavier? ;)

	IMHO: the reason is that Ocaml is based on theory, 
extended and modified over time with experience. Congratulations
to the Ocaml team for refusing to compromise a sound theoretical
basis.
 
> But the JIT-compiled/interpreted byte code seems to be pretty fast: I have
> tried it with a few mini-benchmarks to see whether this JIT-technology
> is of any worth. Really not bad...

	Why bother? The native code compiler is so fast,
it can compile a whole system faster than Java can load 
an already compiled one :-)

> Certainly! I definitely don't want to replace the normal byte code
> interpreter with a purely JIT-one. My motivation was rather portability +
> speed rather than speed alone. For the latter "ocamlopt" is more than
> good enough, and for portability we have the byte code compiler. 

	Actually, I think ocamlopt is _more_ portable.
There's no mucking around with custom run-times, etc.

> I haven't tried the Java-libraries so far. The OCaml-ones are quite
> usable, but if you can tell us what Java has that OCaml is missing,
> just tell us (in time! ;)

	That's easy: a half way decent GUI.
If Ocaml had a decent GUI API that worked on just X- and MS- Windows
systems, it would be a killer. Tk just doesn't cut it anymore.
GTK has promise, but the widgets are immature and lacking functionality.
Java's Swing is a bit messy, but it does provide a rich variety
of configurable widgets, and some documentation. :-(


-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: JIT-compilation for OCaml?

[Markus Mottl]

On Thu, 04 Jan 2001, John Max Skaller wrote:
> 	Actually, I think ocamlopt is _more_ portable.
> There's no mucking around with custom run-times, etc.

Well, it would be really funny to see OCaml compete against Java in
the browser market (a rather unrealistic dream, I fear). Wasn't there a
basic WWW-browser written in OCaml? I am not sure, but I think it also
supported OCaml-byte code.

> 	That's easy: a half way decent GUI.
> If Ocaml had a decent GUI API that worked on just X- and MS- Windows
> systems, it would be a killer. Tk just doesn't cut it anymore.
> GTK has promise, but the widgets are immature and lacking functionality.
> Java's Swing is a bit messy, but it does provide a rich variety
> of configurable widgets, and some documentation. :-(

I expected that people would mention GUI-libraries, but I don't write
GUIs. Is this really everything people are missing? I wouldn't mind
porting the one or other library if it has functionality I need.

- Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: JIT-compilation for OCaml?

[Michael Hicks]

> On Thu, 04 Jan 2001, John Max Skaller wrote:
> > 	Actually, I think ocamlopt is _more_ portable.
> > There's no mucking around with custom run-times, etc.
> 
> Well, it would be really funny to see OCaml compete against Java in
> the browser market (a rather unrealistic dream, I fear). Wasn't there a
> basic WWW-browser written in OCaml? I am not sure, but I think it also
> supported OCaml-byte code.

MMM, the Ocaml-based web browser, still exists, see
http://caml.inria.fr/archives/200005/msg00082.html.  However, last I knew,
the Ocaml bytecode lacks the security guarantees of Java bytecode.  Dynamic
linking will not violate stated interface constraints, but these can be
spoofed, I believe.  

Mike

-- 
Michael Hicks
Ph.D. Candidate, the University of Pennsylvania
http://www.cis.upenn.edu/~mwh            mailto://mwh@dsl.cis.upenn.edu
*There was a man who entered a local paper's pun contest; He sent in ten
*different puns, in the hope that at least one of the puns would win.  
*Unfortunately, no pun in ten did.

Re: JIT-compilation for OCaml?

[Xavier Leroy]

> MMM, the Ocaml-based web browser, still exists, see
> http://caml.inria.fr/archives/200005/msg00082.html.  However, last I knew,
> the Ocaml bytecode lacks the security guarantees of Java bytecode.  Dynamic
> linking will not violate stated interface constraints, but these can be
> spoofed, I believe.  

I'd be interested to know how you'd spoof them.  (Except by breaking
the MD5 crypto hash function, of course, but if you manage to do so,
that would be quite an achievement!  Not only would you immediately
get a PhD in crpytography, but you would also have a "fun" time with
men in black from various organizations...)

As far as we know, the interface checking for MMM applets is safe, but
it is very brittle: the slightest change in the browser's APIs will
cause interface checking to fail, requiring a recompile of the
applets.  That, and the need for a centralized trusted compiling
authority, makes the scheme much less practical than Java-style
bytecode verification.

- Xavier Leroy

Re: JIT-compilation for OCaml?

[John Max Skaller]

Markus Mottl wrote:

> > If Ocaml had a decent GUI API that worked on just X- and MS- Windows
> > systems, it would be a killer. 

> I expected that people would mention GUI-libraries, but I don't write
> GUIs. Is this really everything people are missing?

	Actually, no, there are some other significant
problems (apart from education) with Ocaml. 

	1. The lack of dynamic loading virtually wipes it out 
as a serious commercial language (IMHO). 
This can probably be fixed.

	2. The difficulty of interfacing to existing
C/C++ code. This probably cannot be fixed. [For example,
consider the sheer volume of work required to map GTK
to Ocaml]

	There are, of course, many other problems, such as
the lack of intermodule recursion, but all languages have
various difficulties which can usually either be fixed
or worked around. 

	But clearly the biggest problem is one of education,
both of the virtues of functional programming, and the details
of the ocaml syntax/semantics (much of which escapes me, after
several years usage).

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: JIT-compilation for OCaml?

[Joseph R. Kiniry]

And my 2c (or perhaps 10c) as well...

--On Tuesday, January 02, 2001 20:30:51 +0100 Markus Mottl 
<mottl@miss.wu-wien.ac.at> wrote:

> On Tue, 02 Jan 2001, Mattias Waldau wrote:
>> Why do you want JIT?
>
> I don't need it currently, but I can imagine applications that greatly
> benefit from it.

If OCaml does indeed just do unintelligent interpretation of bytecodes and 
there is sufficient reason for running a non-compiled version of a 
codebase, then a JIT-like mechanism is a wise path to follow.  This bears 
no insult to the OCaml compiler, it has simply been justified by example 
many times over.

>> Do you use Java for regular development? It is a pain,
>
> No, I don't use it at all, but I believe you that it must be very
> painful ;)

Not to go offtopic, but I'd rather see list members educated rather than 
FUD'ded.  If ML is a Prius we still have to respect the Taurus that is Java.

Actually, using Java for regular development isn't all that bad.  The 
libraries are extensive, the language is relatively mature (but still 
experiences growing pains), the platform support is very broad, the 
compilation speed problem is fixed by using a compiler like jikes from IBM, 
and the run-time speed is (these days) excellent.

In fact, one of my companies chose Java over five competitor languages 
(Objective-C, C++, Eiffel, CLOS, and oTcl) in a head-to-head test.  Note 
that this company is a group of uber-geeks with a language geek at the helm 
(me), so we were not working in a vacuum.  We picked a set of languages 
that fulfilled a specific criteria for our work, designed a 
prototype/benchmarking application that would test our design space, and 
implemented it in all but one of the languages (with expert review, of 
course).  We then did writeups of all languages and systems and performed a 
numeric evaluation on a couple of dozen criteria to evaluate our choices. 
In the end, Java and Eiffel came out on top and thus we went with Java for 
mostly business (and a couple of technical) reasons.  A draft whitepaper on 
this is available if anyone is interested, just email me.

>> the reason is
>>
>> 1. Slow, slow
>> 2. Big, big
>
> Maybe that's because the Java JIT-compilers were not written by Xavier? ;)

Speaking from my experience (using Java since the day it came out of Sun in 
1995 and either being a member of, or running, three research groups thus 
far that use Java among other languages),

1. That was true in the past but is no longer the case.  I have problems 
with performance when doing GUI work with Java, but in all other cases I 
have seen, including intensive cases numerical work (our physics and alife 
engines) and language design (projects like Vanilla) Java more than matches 
up with the competition.  The recent JITs (esp Sun's on x86 and SPARC, 
IBM's on x86, HP's on PA, and Compaq's on Alpha) are astounding.

2. The 6-8MB overhead that the runtime imposes on a standard architecture 
most folks will gladly eat. If you are really crunched for space you 
shouldn't be using full Java, but instead should use one of the numerous 
embedded alternatives, some of which run in < 1/4 MB.

>> and the reason that Java gets away with it, is the JIT-compiler. That
>> mean that after enormous start-time, the program might achieve resonable
>> performance after a couple of minutes. However, at that time, it still
>> needs 10-20 extra megs, since the compiler is still loaded into memory.

False on both counts.  Some new variants (like Sun's HotSpot) do amortized 
program analysis at run-time to find code segments to re-optimize, but 
those JITs are only used on very long running (i.e. > days) server-side 
processes.  Neither they, nor the "classic" JITs require 10-20 extra MB of 
memory.

> It shouldn't be too difficult to come up with a protocol that informs
> the interpreter whether it should actually use JIT-compilation or not
> and if yes, how it should compile the code for optimum performance, etc.
>
> This meta information could be generated by passing options to the byte
> code compiler or maybe even by some kind of pragmas in the source. Or
> maybe by a magnificent program analysis tool that finds the "hot spots"
> automatically.

The direction most have gone and certainly an opportunity area.

>> The beatty of Ocaml are the fast compilers, the optimizing compiler is
>> faster than javac, which only produces bytecode.
>
> But the JIT-compiled/interpreted byte code seems to be pretty fast: I have
> tried it with a few mini-benchmarks to see whether this JIT-technology
> is of any worth. Really not bad...
>
>> It is sad that so few
>> other programming language developers realizes that the speed of the
>> development environment matters.
>
> Certainly! I definitely don't want to replace the normal byte code
> interpreter with a purely JIT-one. My motivation was rather portability +
> speed rather than speed alone. For the latter "ocamlopt" is more than
> good enough, and for portability we have the byte code compiler. But
> if you want to have portability with reasonable speed for demanding
> applications...

Excellent point.

>> The only thing Ocaml can learn from Java is its libraries. If I would
>> invent a programming language with a library today, I would just copy
>> Java's interface. Libraries are much harder to learn than programming
>> languages, thus standards are needed.
>
> I haven't tried the Java-libraries so far. The OCaml-ones are quite
> usable, but if you can tell us what Java has that OCaml is missing,
> just tell us (in time! ;)

Certainly the breadth and growth of Java's libraries is a marvel, but I 
*certainly* wouldn't say that they are a uniform example of good design. 
It amazes me that a package can go through so much semi-public design 
review and still have serious design flaws.  Until one uses a library on 
large projects with many people for a some reasonable period of time, 
claims of excellence, esp from the library vendor, are premature.

> - Markus Mottl

And now back to your regularly scheduled ML discussion.

Best,
Joe Kiniry
-- 
Joseph R. Kiniry                   http://www.cs.caltech.edu/~kiniry/
California Institute of Technology       ID 78860581      ICQ 4344804

P.S. I've been simming on throwing in my 2c on overloading, but my bias of 
algebraic systems vs. type systems would expose itself.

P.P.S. The company that I mentioned is called DALi and is linked from my 
homepage.  Much more information is available there.

Re: JIT-compilation for OCaml?

[Markus Mottl]

On Wed, 03 Jan 2001, Joseph R. Kiniry wrote:
> > No, I don't use it at all, but I believe you that it must be very
> > painful ;)
> 
> Not to go offtopic, but I'd rather see list members educated rather than 
> FUD'ded.  If ML is a Prius we still have to respect the Taurus that is Java.

There was a smiley after my criticism... - anyway, though I'd never want
to switch to Java when I can use OCaml, it isn't this bad compared to
other mainstream languages. At least some major insanities have been
removed.

> In fact, one of my companies chose Java over five competitor languages 
> (Objective-C, C++, Eiffel, CLOS, and oTcl) in a head-to-head test.  Note 
> that this company is a group of uber-geeks with a language geek at the helm 
> (me), so we were not working in a vacuum.

Why didn't you compare to OCaml or other FPLs (e.g. Haskell, Clean, etc.)?
Business reasons?

> Certainly the breadth and growth of Java's libraries is a marvel, but I 
> *certainly* wouldn't say that they are a uniform example of good design. 
> It amazes me that a package can go through so much semi-public design 
> review and still have serious design flaws.  Until one uses a library on 
> large projects with many people for a some reasonable period of time, 
> claims of excellence, esp from the library vendor, are premature.

It would be interesting to know what (except for GUI-stuff) people are
missing in OCaml or other FPLs. I just haven't used Java often enough
to know details about its libraries.

- Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: JIT-compilation for OCaml?

[Joseph R. Kiniry]

Hello Markus,

--On Wednesday, January 03, 2001 19:19:03 +0100 Markus Mottl 
<mottl@miss.wu-wien.ac.at> wrote:

> On Wed, 03 Jan 2001, Joseph R. Kiniry wrote:
>> > No, I don't use it at all, but I believe you that it must be very
>> > painful ;)
>>
>> Not to go offtopic, but I'd rather see list members educated rather than
>> FUD'ded.  If ML is a Prius we still have to respect the Taurus that is
>> Java.
>
> There was a smiley after my criticism... - anyway, though I'd never want
> to switch to Java when I can use OCaml, it isn't this bad compared to
> other mainstream languages. At least some major insanities have been
> removed.

Sorry, I'm seriously emoticon disabled.  I agree with your sentiment.  Some 
of the final insantities are being addressed by pretty bright people, 
(thread semantics, lack of assertions, parameterization), so let's hope 
they get it right.

>> In fact, one of my companies chose Java over five competitor languages
>> (Objective-C, C++, Eiffel, CLOS, and oTcl) in a head-to-head test.  Note
>> that this company is a group of uber-geeks with a language geek at the
>> helm  (me), so we were not working in a vacuum.
>
> Why didn't you compare to OCaml or other FPLs (e.g. Haskell, Clean, etc.)?
> Business reasons?

Entirely.  I would have been happy to work in OCaml, but trying to convince 
investors (who are reluctant enough to go with something like Objective-C 
or CLOS) that ML is a viable option is a hard-sell.  Couple that with the 
whole training, hiring, maintenence, and Open Source issues and you hit a 
dead end immediately.

>> Certainly the breadth and growth of Java's libraries is a marvel, but I
>> *certainly* wouldn't say that they are a uniform example of good design.
>> It amazes me that a package can go through so much semi-public design
>> review and still have serious design flaws.  Until one uses a library on
>> large projects with many people for a some reasonable period of time,
>> claims of excellence, esp from the library vendor, are premature.
>
> It would be interesting to know what (except for GUI-stuff) people are
> missing in OCaml or other FPLs. I just haven't used Java often enough
> to know details about its libraries.
>
> - Markus Mottl

While on the other hand I can't claim expertise in OCaml -- hundreds of 
lines of code do not an expert make!.  Perhaps someone else on the list has 
written OCaml/ML and Java for > 10,000 LOC?  I hope to become an OCaml 
expert this year, partly because I'm doing a port to the new Amiga VP/Taos 
architecture and partly because it is next on "the list".

Best,
Joe
-- 
Joseph R. Kiniry                   http://www.cs.caltech.edu/~kiniry/
California Institute of Technology       ID 78860581      ICQ 4344804

Re: JIT-compilation for OCaml?

[Markus Mottl]

On Wed, 03 Jan 2001, Joseph R. Kiniry wrote:
> > Why didn't you compare to OCaml or other FPLs (e.g. Haskell, Clean, etc.)?
> > Business reasons?
> 
> Entirely.  I would have been happy to work in OCaml, but trying to convince 
> investors (who are reluctant enough to go with something like Objective-C 
> or CLOS) that ML is a viable option is a hard-sell.  Couple that with the 
> whole training, hiring, maintenence, and Open Source issues and you hit a 
> dead end immediately.

It's sad that it is still so difficult to attract investors to modern
(as opposed to "new") technologies. OTOH, it is understandable that they
are reluctant if they know that you are likely to have problems hiring
or training staff (-> higher costs = less profit).

How is the situation in France? Isn't (O)Caml used in most universities /
hautes ecoles for teaching? There should be much more "programmer supply"
over there (but probably not enough "venture capital supply" as compared
to the US...).

I do not really follow your concerns about Open Source: OCaml is pretty
"free" as are most other FPLs. Or do you mean something else?

- Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: JIT-compilation for OCaml?

[Joseph R. Kiniry]

--On Wednesday, January 03, 2001 19:58:32 +0100 Markus Mottl 
<mottl@miss.wu-wien.ac.at> wrote:

> On Wed, 03 Jan 2001, Joseph R. Kiniry wrote:
>> > Why didn't you compare to OCaml or other FPLs (e.g. Haskell, Clean,
>> > etc.)? Business reasons?
>>
>> Entirely.  I would have been happy to work in OCaml, but trying to
>> convince  investors (who are reluctant enough to go with something like
>> Objective-C  or CLOS) that ML is a viable option is a hard-sell.  Couple
>> that with the  whole training, hiring, maintenence, and Open Source
>> issues and you hit a  dead end immediately.
>
> It's sad that it is still so difficult to attract investors to modern
> (as opposed to "new") technologies. OTOH, it is understandable that they
> are reluctant if they know that you are likely to have problems hiring
> or training staff (-> higher costs = less profit).

And that is exactly the problem in my situation.  The investors (myself 
being one of them) weren't that concerned with the choice of a 
non-mainstream/modern language/system for technical reasons, but we were 
entirely for many, many business reasons.

> How is the situation in France? Isn't (O)Caml used in most universities /
> hautes ecoles for teaching? There should be much more "programmer supply"
> over there (but probably not enough "venture capital supply" as compared
> to the US...).
>
> I do not really follow your concerns about Open Source: OCaml is pretty
> "free" as are most other FPLs. Or do you mean something else?

I'm sorry, I should have been more explicit.  I meant that if you are 
developing and Open Source product and you'd like large scale involvement, 
choosing OCaml as a source language isn't in your best interest.  While it 
is true that you are likely to get higher quality people involved, the 
source pool is several orders of magnitude smaller than that of Java.

Joe
-- 
Joseph R. Kiniry                   http://www.cs.caltech.edu/~kiniry/
California Institute of Technology       ID 78860581      ICQ 4344804

Re: JIT-compilation for OCaml?

[Jonathan Coupe]

>
> And that is exactly the problem in my situation.  The investors (myself
> being one of them) weren't that concerned with the choice of a
> non-mainstream/modern language/system for technical reasons, but we were
> entirely for many, many business reasons.
>
>
> I'm sorry, I should have been more explicit.  I meant that if you are
> developing and Open Source product and you'd like large scale involvement,
> choosing OCaml as a source language isn't in your best interest.  While it
> is true that you are likely to get higher quality people involved, the
> source pool is several orders of magnitude smaller than that of Java.
>
> Joe
> --
> Joseph R. Kiniry                   http://www.cs.caltech.edu/~kiniry/
> California Institute of Technology       ID 78860581      ICQ 4344804

Ironically, my experience would suggest the opposite regarding the
acceptability of Java vs OCaml on business grounds. The project you're
working on seems to be an  ALife video game (a fairly established genre by
now, which is beneficial if you go after investment.) The major source of
funding for such projects is from existing videogame publishers - VC's are
highly allergic to entertainment software. And the videogame industry does
not favour Java, even as a scripting language. (I won't go into the reasons
for this, or whether that view is correct.) The use of game scripting
languages with very similar characteristics toOCaml is well accepted
however - search +GOOL +"Crash Bandicoot" for an example. Typically game
companies write their own scripting languages. Using a well-supported and
tested open source language may well be an idea whose time has come.

The key questions in my mind are how well OCaml works in a situatuion when
its being called from a C++/C program, and how easily portable it is to new
platforms (contrarily, I haven't heard of any plans to launch a high
performance Java compiler for the PS2.)

As for the lack of experienced OCaml programmers, competent programmers in
the videogame industry have learnt Lisp-based languages like GOOL, or
pure(ish) OO languages in just days, often with only experience of C to draw
upon. For an open source project, things may be different. My impression is,
however, that Java is considered extremely uncool by the open source
community, partly because of licensing issues, partly because some many
influential members of the community don't like Java. C, Perl, Python, TCL -
and even the Squeak dialect of Smalltalk and Scheme (consider GIMP and
Guile) - seem to rate much higher.

Jonathan Coupe

Re: JIT-compilation for OCaml?

[Chris Hecker]

> The use of game scripting
>languages with very similar characteristics toOCaml is well accepted
>however - search +GOOL +"Crash Bandicoot" for an example. Typically game
>companies write their own scripting languages. Using a well-supported and
>tested open source language may well be an idea whose time has come.

A couple points:  Several games have used Lua as a scripting language, so developers are already using open source scripting languages.  And, while game developers are relatively flexible on which scripting languages are used, trying to use something that's not C or C++ as the main core programming language would be heresy right now in the game industry (even Java would be considered very risky).  I didn't get the impression that the previous poster was evaluating scripting languages as much as the core language for the project.

For what it's worth, I'm doing a talk about wacky languages at the GDC this year:

http://cmp.bluedot.com/re/attendee/sessionViewer/gdcEventViewer.esp?presentationIds=36554534&searchResults=true&lastChoice=search

And, James Hague (who's on the list) wrote an artcle about this for gamasutra:

http://www.gamasutra.com/features/19990813/languages_01.htm

Chris

Re: JIT-compilation for OCaml?

[Sven LUTHER]

On Wed, Jan 03, 2001 at 11:06:09AM -0800, Joseph R. Kiniry wrote:
> --On Wednesday, January 03, 2001 19:58:32 +0100 Markus Mottl 
> <mottl@miss.wu-wien.ac.at> wrote:
> > How is the situation in France? Isn't (O)Caml used in most universities /
> > hautes ecoles for teaching? There should be much more "programmer supply"
> > over there (but probably not enough "venture capital supply" as compared
> > to the US...).
> >
> > I do not really follow your concerns about Open Source: OCaml is pretty
> > "free" as are most other FPLs. Or do you mean something else?
> 
> I'm sorry, I should have been more explicit.  I meant that if you are 
> developing and Open Source product and you'd like large scale involvement, 
> choosing OCaml as a source language isn't in your best interest.  While it 
> is true that you are likely to get higher quality people involved, the 
> source pool is several orders of magnitude smaller than that of Java.

A, yes, but is it not said that ocaml programs are easier to write and smaller
in size, thus easier to maintain ? would this not compensate the lower number
of available developpers ?

BTW, about the amiga/TAO stuff ? what is your feeling about the virtual code
or whatever they call it ? i had the feeling that it was very i386 like, but
haven't looked at it very long, but it would make it kind of a heresy to
longtime amiga users ?

Friendly,

Sven Luther

Re: JIT-compilation for OCaml?

[Joseph R. Kiniry]

Hello Sven,

Apologies for the off-topic-ness of this post, but since OCaml will be 
running on this architecture soon, and since this set of software is fairly 
innovative, it is likely of interest to the readers of this list.

--On Friday, January 05, 2001 13:52:58 +0100 Sven LUTHER 
<luther@dpt-info.u-strasbg.fr> wrote:

> On Wed, Jan 03, 2001 at 11:06:09AM -0800, Joseph R. Kiniry wrote:
>> I'm sorry, I should have been more explicit.  I meant that if you are
>> developing and Open Source product and you'd like large scale
>> involvement,  choosing OCaml as a source language isn't in your best
>> interest.  While it  is true that you are likely to get higher quality
>> people involved, the  source pool is several orders of magnitude smaller
>> than that of Java.
>
> A, yes, but is it not said that ocaml programs are easier to write and
> smaller in size, thus easier to maintain ? would this not compensate the
> lower number of available developpers ?

You'll get no argument for me on these points.  The only maintainence 
issues with OCaml are from a 
non-language-expert-business-investor-standpoint: the lack of a large 
corporation to support tools, the small number of existing expert 
programmers as a hiring pool, and the standard chicken-and-egg argument 
("well no one _else_ is using this language, so it _must_ not be a good 
choice!").  Note that *I* do not subscribe to the above, but I am only one 
of many investors/participants.  In my other company, as in my research 
work, I'm the boss, so to speak, so we hear a different tune there.

> BTW, about the amiga/TAO stuff ? what is your feeling about the virtual
> code or whatever they call it ? i had the feeling that it was very i386
> like, but haven't looked at it very long, but it would make it kind of a
> heresy to longtime amiga users ?

The "new" Amiga <http://www.amiga.com/> is really a set of technologies 
built on top of a virtual operating system from the Tao Group 
<http://www.tao-group.com/>.  It is a processor agnostic, clean-room OS 
built from the ground up to be scalable (i.e. run on anything from a 
wristwatch to a multi-processor server), portable (i.e. runs on over 20 
processor architectures), high performance (mostly due to an advanced 
load-time compiler that does data-flow analysis), and of elegant design 
(innovative "tools" as a unit of memory management and compilation, 
asynchronous messaging-based communication throughout, multiprocessor ready 
from day zero, etc.).

I'm really impressed with the Tao codebase.  The VP design is the nicest 
assembly language I have ever used.  (I know most Motorola, MIPS, and Intel 
assembly languages, as a reference).  It is object-based(!), has unlimited 
registers, has a clean and flexible syntax, and (by design) is very 
efficiently translated to machine code.

For the hard-core Amiga user of old (of which I am one, as well as a C=64 
and NeXT geek), it is nice to see the name rebirthed with innovative 
technology, but it is unclear if the team can follow-through with their 
typically-Amiga grandiose visions (your standard ubiquitous distributed 
components discovering each other at run-time &c).

The Amiga SDK is available for Linux and Windows and comes with extensive 
documentation, support for several languages (C, C++, Java, Python, Perl, 
and I've already ported Eiffel), and a whole host of new and innovative 
technologies.  And at $99, it's hard to beat if you are into tinkering with 
really innovative stuff.

Joe
-- 
Joseph R. Kiniry                   http://www.cs.caltech.edu/~kiniry/
California Institute of Technology       ID 78860581      ICQ 4344804

Re: JIT-compilation for OCaml?

[John Max Skaller]

Markus Mottl wrote:

> It's sad that it is still so difficult to attract investors to modern
> (as opposed to "new") technologies. OTOH, it is understandable that they
> are reluctant if they know that you are likely to have problems hiring
> or training staff (-> higher costs = less profit).

	At least in Australia, almost all computer science courses
include functional and logic programming as topics. 
Furthermore, programmers are _intelligent_ organisms: 
they can learn new languages. And since Ocaml is
so much more efficient to develop with, the savings in programmers
would easily offset any extra time required to learn it. IMHO. :-)

	The problem is one of hype and marketing.
 
> I do not really follow your concerns about Open Source: OCaml is pretty
> "free" as are most other FPLs. Or do you mean something else?

	Consider the following note included in the 'wlex' README:

-----------------------------------------------------------------------
NOTE
 *  The lexer generator is derived from ocamllex; due to licence issues
 *  (this part of the OCaml system is distributed under the terms of the
 *  QPL), I have to distribute it as a patch. This imply you will need
 *  the whole OCaml source tree to build wlex. If you experience any
 *  problem to apply the patch, please don't hesitate to contact me.
-----------------------------------------------------------------------

	Please compare to the Python licence, which is unequivocal:
Python is FREE FOR ANY USE. [Its that simple]

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: JIT-compilation for OCaml?

[John Max Skaller]

Markus Mottl wrote:

> though I'd never want
> to switch to Java when I can use OCaml, it isn't this bad compared to
> other mainstream languages. At least some major insanities have been
> removed.

	It has a serious faulty static
type system, idiotic object orientation, no generics, isn't
compatible with C, uses the worst features of C/C++ syntax,
is inefficient to compile, load, and run, doesn't interface
well, uses Unicode instead of ISO-10646, has a hodge podge library,
is less portable than C, C++ or Eiffel, stuffed up finalisation ...

	Surely, Java is the worst modern language around.
It is an inexcusably travesty, when so much good theory is
around, and C compatibility is not required.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: JIT-compilation for OCaml?

[Sven LUTHER]

On Tue, Jan 02, 2001 at 07:16:37PM +0100, Mattias Waldau wrote:
> Why do you want JIT? Do you use Java for regular development? It is a pain,
> the reason is
> 
> 1. Slow, slow
> 2. Big, big
> 
> and the reason that Java gets away with it, is the JIT-compiler. That mean
> that after enormous start-time, the program might achieve resonable
> performance after a couple of minutes. However, at that time, it still needs
> 10-20 extra megs, since the compiler is still loaded into memory.
> 
> The beatty of Ocaml are the fast compilers, the optimizing compiler is
> faster than javac, which only produces bytecode. It is sad that so few
> other programming language developers realizes that the speed of the
> development environment matters.

Well yes, but you forget architecture independence. With a JIT-like thing,
you could achieve native-code like speed out of byte-code. not sure though if
it is possible, or if the speed advantage is worth the trouble. 

Friendly,

Sven Luther

Re: JIT-compilation for OCaml?

[Vitaly Lugovsky]

On Tue, 2 Jan 2001, Markus Mottl wrote:

> Hello,
> 
> one thing I just wondered about is whether there are any intentions
> concerning a JIT-compiler for OCaml byte code similar to what Java
> offers. This would allow much faster execution while still retaining
> full portability of the byte code. Is this a goody we might expect in the
> (near? far?) future?

 Very nice idea. And it also will be a solution to dynamic loading
problem!

 I just tryed to understand, how ocaml bytecode interpreter works, and I
think, it is possible to place a kind of JIT there with a little pain.

--

   V.S.Lugovsky aka Mauhuur (http://ontil.ihep.su/~vsl) (UIN=45482254)

RE: JIT-compilation for OCaml?

[Jerry Jackson]

-----Original Message-----
From: Alain Frisch [mailto:frisch@clipper.ens.fr]
Sent: Wednesday, January 03, 2001 5:15 AM
To: Markus Mottl
Cc: Mattias Waldau; OCAML
Subject: Re: JIT-compilation for OCaml?


Hello,

Compiling the code really during runtime opens the door to further
optimizations (I guess this is how Java JIT compilers work, but I have no
idea). For instance, it is possible to watch conditionnal jumps and
reorganize the code so that the most taken branches don't need any jump.
The GC and the memory allocator have the opportunity to adapt themselves
to the application. Of course, this only makes sense for long running
applications. The user should be able to record the optimization
information collected. Actually, there are two operations involved: a
profiler (a bytecode interpreter that also collects optimization
information) and a bytecode-to-nativecode converter as in the previous
paragraph. I don't see the advantage of mixing them in a complex JIT
compiler (which will be slow for a long time after startup if the
optimizations are non trivial).

[JRJ] There are many other sorts of optimizations that can be done by
compiling at runtime.  A simple case is that processor-specific instructions
can be generated instead of generic ones (e.g. Pentium III instructions
rather than generic 486).  A more interesting example is used by Sun's
current JIT compiler...  Aggressive inlining and direct dispatch are done
for all sorts of method calls (that could potentially be overloaded).  If a
class is later loaded that extends one of the inlined or directly called
methods, the JIT compiler goes back and "unoptimizes" the code it had
previously optimized!

Re: JIT-compilation for OCaml?

[Alan Schmitt]

This reminds me of slim binaries and runtime optimizations ...
(see http://caesar.ics.uci.edu/oberon/research.html#SlimBinaries )

I noticed something funny there: the PhD student who was working on
dynamic optimizations is now working for Transmeta. What a coincidence
;-)

Alan Schmitt


>[JRJ] There are many other sorts of optimizations that can be done by
>compiling at runtime.  A simple case is that processor-specific instructions
>can be generated instead of generic ones (e.g. Pentium III instructions
>rather than generic 486).  A more interesting example is used by Sun's
>current JIT compiler...  Aggressive inlining and direct dispatch are done
>for all sorts of method calls (that could potentially be overloaded).  If a
>class is later loaded that extends one of the inlined or directly called
>methods, the JIT compiler goes back and "unoptimizes" the code it had
>previously optimized!


--
The hacker: someone who figured things out and made something cool happen.

RE: JIT-compilation for OCaml?

[Dave Berry]

Dynamic libraries would be useful, but there are other areas where OCaml
(and most if not all other FLs) falls short.  See below.

Regarding C/C++ interfacing, this should be do-able, it's just a lot of
work.  What might be useful would be if all the implementors of advanced
programming languages (OCaml, SML, Dylan,...) got together and wrote a tool
for generating IDL from C/C++ header files.  Then each implementor could
write a language-specific IDL translator.  I know the Dylan community made
some headway with parsing header files.

Here are some application areas to consider:

1.  Huge numbers of commercial programs are simple UIs on top of simple
databases.  Hence the success of VB.  A UI builder and simple DB interface
would meet this need.  (This is easier said than done).

2.  A smaller number of commercial programs are complex UIs on top of
complex databases.  Here a UI builder is less important, but a UI toolkit
and a sophisticated DB interface are essential.

3.  Web programs require interfacing to web browsers.  Perhaps someone could
add the OCaml VM to Mozilla?

4.  A growing number of commercial offerrings are based on component
technology (ActiveX controls or Javabeans).  Support for these (or perhaps a
native equivalent) would be very useful.  (Again, this is easier said than
done).

5.  There are many embedded programs out there.  These are tricky to write
with a GC.

Dave.

-----Original Message-----
From: John Max Skaller [mailto:skaller@ozemail.com.au]
Sent: Tuesday, January 09, 2001 6:40
To: Markus Mottl
Cc: Mattias Waldau; OCAML
Subject: Re: JIT-compilation for OCaml?


Markus Mottl wrote:

> > If Ocaml had a decent GUI API that worked on just X- and MS- Windows
> > systems, it would be a killer. 

> I expected that people would mention GUI-libraries, but I don't write
> GUIs. Is this really everything people are missing?

	Actually, no, there are some other significant
problems (apart from education) with Ocaml. 

	1. The lack of dynamic loading virtually wipes it out 
as a serious commercial language (IMHO). 
This can probably be fixed.

	2. The difficulty of interfacing to existing
C/C++ code. This probably cannot be fixed. [For example,
consider the sheer volume of work required to map GTK
to Ocaml]

	There are, of course, many other problems, such as
the lack of intermodule recursion, but all languages have
various difficulties which can usually either be fixed
or worked around. 

	But clearly the biggest problem is one of education,
both of the virtues of functional programming, and the details
of the ocaml syntax/semantics (much of which escapes me, after
several years usage).

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: JIT-compilation for OCaml?

[John Max Skaller]

Dave Berry wrote:
 
> Here are some application areas to consider:
> 
> 1.  Huge numbers of commercial programs are simple UIs on top of simple
> databases.  Hence the success of VB.  A UI builder and simple DB interface
> would meet this need.  (This is easier said than done).

	I actually don't believe in UI builders.
I have an alternate idea, I'd just love to implement in Ocaml.
(I have done it in Tcl, oTcl, and Python). 

	I call the system HWM, for Heirachical Window Manager.
The idea is to use a tree widget instead of a linear panel.
Each (application level) window is a node in the tree.
The user can:

	1. Move, iconise, and delete whole subtrees.
	2. Spawn new applications as children of
		some other window (usually a container)
	3. Dynamically change the type of a container

	What this means is that instead of building a huge,
monolithic, integrated GUI application, configuration/placement/
organisation/style of windows is up to the user.

	This means you don't need a UI builder to build a client
interface: HWM is the UI builder, and it is used by the client.

	For example: the otherwise excellent OcamlBrowser
has a fixed, and, for me, quite broken, method of organising
its windows (they come in the wrong places, and the scroll boxes
are always the wrong size: it takes one click to spawn a new window
showing some module used in another, and ten clicks and drags
to get the size right). With HWM, I, as the client, would
have complete control over where those new windows went.
 
	[The actual impetus for the design was an IDE for
a Literate Programming Tool, which must handle
edit/compilation/make/test
of the software, as well as providing views of the 'book' text.
The complexity required when dynamically displaying both kinds of
information with various aspects of the structure (such as index
of indentifiers, and index of words in the documentation) is
far beyond conventional organisational techniques.]

> 4.  A growing number of commercial offerrings are based on component
> technology (ActiveX controls or Javabeans).  Support for these (or perhaps a
> native equivalent) would be very useful.  (Again, this is easier said than
> done).

	I guess these things have the wrong kinds of 'component'.
Ocaml already has the 'right' kind of component: the module.
What is needed is to dynamically load them (i.e. some module
conforming to some statically specified interface).
 
> 5.  There are many embedded programs out there.  These are tricky to write
> with a GC.

	Perhaps the Ocaml GC is too heavyweight for microcontrollers.
But I don't know: Java was designed to program a toaster wasn't it? :-)

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

RE: JIT-compilation for OCaml?

[Dave Berry]

This view seems extreme to me.  Certainly the Java type system has faults --
lack of generics being one, lack of enumerated types another, and various
other points as well.  But surely Unicode is a useful de facto standard?
Using C syntax was a strong point -- it made the language familiar to many
people.  IMO Java syntax does avoid many of the worst aspects of C syntax
(e.g. pointers).  It's surely portable: JVMs run on many systems.  It
certainly isn't slow to compile, and a previous poster suggested that with
modern compilers run-time performance is not too bad.  You can access C or
C++ functions from Java using JNI (although you seem to be in two minds as
to whether C compatibility is desirable or irrelevant).

And this omits it's plus points, especially its utility in net programming.
Its security model is not the last word, but it's better than C, C++ or
Eiffel!  And its use of byte code ensures portability of compiled apps.

Dave.

-----Original Message-----
From: John Max Skaller [mailto:skaller@ozemail.com.au]
Sent: Tuesday, January 09, 2001 6:50
To: Markus Mottl

	It has a serious faulty static
type system, idiotic object orientation, no generics, isn't
compatible with C, uses the worst features of C/C++ syntax,
is inefficient to compile, load, and run, doesn't interface
well, uses Unicode instead of ISO-10646, has a hodge podge library,
is less portable than C, C++ or Eiffel, stuffed up finalisation ...

	Surely, Java is the worst modern language around.
It is an inexcusably travesty, when so much good theory is
around, and C compatibility is not required.

Re: JIT-compilation for OCaml?

[John Max Skaller]

Dave Berry wrote:
> 
> This view seems extreme to me.  Certainly the Java type system has faults --
> lack of generics being one, lack of enumerated types another, and various
> other points as well.  But surely Unicode is a useful de facto standard?

	No. Unicode was abandoned years ago: there is an 'offical'
ISO Standard: ISO-10646. There are 2^31 code points, unlike
Unicode's 2^16, which is already barely adequate. ISO C and ISO C++
support ISO-10646. Linux runs ISO-10646 (via UTF-8).

> Using C syntax was a strong point -- it made the language familiar to many
> people. 

	This is a selling point: Felix also uses a C like syntax,
but it fixes the worst deficiency in C/C++, namely declarator
syntax, indeed Felix is LR(1) [works with ocamlyacc] and unambiguous 
except for the usual 'dangling else' ambiguity.

	A competent C/C++ programmer had no trouble learning
it in a few minutes. It isn't hard to learn:

	val x: int = 1;
	function f(x:int) { .. }

although I often make the mistake:

	function f(int x) { .. }

myself, being an (ex-)C/C++ programmer :-)

> IMO Java syntax does avoid many of the worst aspects of C syntax
> (e.g. pointers).  

	Really, this is a matter of semantics rather than syntax.
Java uses references and a garbage collector, which I agree can
have advantages over pointers and manual storage control.

	Felix uses pointers, but they cannot be NULL,
and it uses a garbage collector: syntactically you have to
form them by addressing (&variable) and use them with
dereferencing (*pvariable). I don't think the syntax
is that much of an issue -- in Ocaml, you have to dereference
references too.

> It's surely portable: JVMs run on many systems.  

	Sure. With restricted functionality. To get 'many real' programs
to work you need native code extensions.

> It certainly isn't slow to compile, 

	The version of Java I used (1.2) was so slow as to be unusable.
It ran THOUSANDS of times slower than g++. (And ocaml is even faster!)
Perhaps this has changed recently.

> and a previous poster suggested that with
> modern compilers run-time performance is not too bad.  You can access C or
> C++ functions from Java using JNI (although you seem to be in two minds as
> to whether C compatibility is desirable or irrelevant).

	Like I said, there goes portability :-)
 
> And this omits it's plus points, especially its utility in net programming.
> Its security model is not the last word, but it's better than C, C++ or
> Eiffel!  And its use of byte code ensures portability of compiled apps.

	Python and Ocaml also use portable bytecodes. 
Python at least is every bit as good at 'net' programming as Java,
and faster to develop with. I dare say, that with some basic
libraries, Ocaml would be vastly superior at 'net' programming,
simply because it is vastly superior as a programming language :-)

	For example, Ocaml runs on MS's .net platform.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: JIT-compilation for OCaml?

[Alain Frisch]

On Thu, 11 Jan 2001, John Max Skaller wrote:

> > This view seems extreme to me.  Certainly the Java type system has faults --
> > lack of generics being one, lack of enumerated types another, and various
> > other points as well.  But surely Unicode is a useful de facto standard?
> 
> 	No. Unicode was abandoned years ago: there is an 'offical'
> ISO Standard: ISO-10646. There are 2^31 code points, unlike
> Unicode's 2^16, which is already barely adequate. ISO C and ISO C++
> support ISO-10646. Linux runs ISO-10646 (via UTF-8).

What are you calling 'Unicode' ?  For me it is the 'Unicode standard'
from the 'Unicode consortium' (http://www.unicode.org/), and it doesn't
seem like it was abandoned. Actually, it is in sync with ISO/IEC 10646
as for the character set.

See for instance:
http://www.unicode.org/unicode/faq/unicode_iso.html


-- 
  Alain Frisch

Re: JIT-compilation for OCaml?

[John Max Skaller]

Alain Frisch wrote:
 
> What are you calling 'Unicode' ?  For me it is the 'Unicode standard'
> from the 'Unicode consortium' (http://www.unicode.org/), and it doesn't
> seem like it was abandoned. Actually, it is in sync with ISO/IEC 10646
> as for the character set.

	Perhaps I should have been clearer: the Unicode consortium
is indeed active, and is one of the main players in the ISO-10646
and related standards forum. It is also responsible for making
data available freely, unlike ISO and National Standards Bodies,
for I am very thankful.

	What I meant was that, as a separate
Standard, Unicode is considered archaic: it is subsumed by ISO-10646.
No one should provide (merely) Unicode support in a modern language, 
(IMHO) they should provide ISO-10646 support. 

	ISO usually provides the basis for National
Standards when these exist, for example the  US National Standard
for C++ is a rubber stamp of the ISO one (although the US was the
main, but not only, contributor to the formation of the document).

	Unicode was useful in the days when industry couldn't
wait for international consensus, but that consensus now exists,
and the standard to use for international character sets is ISO-10646,
not Unicode. This does require more work, since while tables
of size 2^16 words are viable, 2^31 generally isn't. However
the 2^31 code points leave plenty of room for expansion, while
Unicode is already too small to encode all the world's languages
(although the coverage is quite good), in particular,
there's little room for extensive coverage of mathematical symbols.

	Note that some government type projects require conformance
to ISO standards, and merely providing Unicode may threaten the 
commerical viability of a product. For example, countries like
Australia and New Zealand have a need for working with text in
many languages, and they're likely to require ISO-10646,
since it has scope to include Aboriginal and Maori, which 
Unicode does not.

	I note that Unicode is still important, because many
operating systems support Unicode filenames, and some programming
languages like Java and Python provide Unicode support. 
One still has to support 'legacy' systems.

	[BTW: Java's lack of ISO-10646 support would likely
have been an obstacle in the process of ISO Standardisation,
had that been followed through]

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

RE: JIT-compilation for OCaml?

[Dave Berry]

By "component", I mean an object with methods, asynchronous events, and
settable properties, working in containers that know how to embed these
components.  The origin of this approach was (I think) the Andrew project at
CMU, many years ago.  ML modules are different.

As for whether these are "right" or "wrong", this depends on whether you
want to work in a small purist community or interact with the wider world.
To date, OCaml has emphasised interoperability (e.g. with C), which is one
of the reasons that its been successful.

Dave.

-----Original Message-----
From: John Max Skaller [mailto:skaller@ozemail.com.au]
Sent: Thursday, January 11, 2001 6:38
To: Dave Berry
Cc: Markus Mottl; OCAML
Subject: Re: JIT-compilation for OCaml?


> 4.  A growing number of commercial offerrings are based on component
> technology (ActiveX controls or Javabeans).  Support for these (or perhaps
a
> native equivalent) would be very useful.  (Again, this is easier said than
> done).

	I guess these things have the wrong kinds of 'component'.
Ocaml already has the 'right' kind of component: the module.
What is needed is to dynamically load them (i.e. some module
conforming to some statically specified interface).
 

Re: JIT-compilation for OCaml?

[John Max Skaller]

Dave Berry wrote:
> 
> By "component", I mean an object with methods, asynchronous events, and
> settable properties, working in containers that know how to embed these
> components.  The origin of this approach was (I think) the Andrew project at
> CMU, many years ago.  ML modules are different.

	OK. I think we'd agree roughly on what a 'component' is.

> As for whether these are "right" or "wrong", this depends on whether you
> want to work in a small purist community or interact with the wider world.

	That isn't how I see it. Pragmatically, we must use available
technology, even if it is faulty, since _all_ the available technology
is faulty.

	For me, the issue is to recognize the flaws, and work 
towards fixing them, or finding a better solution -- probably at 
the same time as continuing to use better understood but flawed
technology when the commerical risks don't justify trying something
more experimental.

	To this end, I can understand why you might choose Java 
as an implementation language: but I think a large part of that choice
is driven by non-expert perceptions (of, for example, shareholders and
clients), rather than by technical evaluations.

	Perhaps by expertise biases my opinion. For example,
a lot of Windows code is developed using MFC, which I believe
is pretty bad. I'd never bother, since I can develop similar but
better functionality as required more quickly than learn the
quirks of an ugly system.

	Except in the case of applets, I'd never use Java,
since I know C++ well enough that I'd gain almost nothing
from it's 'advantages', and lose a lot of the advantages
of C++. More likely, I'd use Ocaml if at all possible :-)

> To date, OCaml has emphasised interoperability (e.g. with C), which is one
> of the reasons that its been successful.

	Yes, I agree. And this is one of the major components
of the design of C++: it is simultaneously a strength and a serious
weakness. My Felix language generates C++, but provides a saner
syntax/semantics (at least, that is the idea); it provides
much better interoperability than Ocaml. Some things are lost
of course!

	 But Java is not compatible with C or C++, so there was no need 
to make a language with so many of the faults it has. IMHO. :-)
Instead, the designers should have looked at the kinds of languages
researchers were working with (like ML), and provided as version of
them with a 'simplified' syntax. At least that's what I would have done,
(and indeed _is_ what I'm doing with Felix :-)

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net