Re: [Jython-users] jython to java?

[Samuele P. <pe...@in...>]

Hi.

A) Some general considerations

[John Mudd]
> Maybe there's a market for this sort of scenario.  Use a subset of
> Jython in exchange for the ability to switch to Java after the
> prototype solidifies.  Maybe both languages would benfit from
> collaboration.
As philosophy (unrelated to java) that's the niche (at least in term of 
promises) of Common Lisp System vendors, which still give a lot
of dynamism in the delivered version, and the pontential niche
of dylan (that didn't catch up), where you lose most of the dynamism
for performance in the delivered version of a program, but you
have full dynamism during development.

Having both dynamic language features (very good for RAD) and performance is not 
that simple:

the runtime/compiler should understand when you are not using them ;)


some possible approach are

1) optional static typing over a basically dynamic typed language
   and/or giving up  (implicitly/explicitly)   
   with some dynamic aspects of semantic in deployed versions.
2) dynamic (at runtime) compilation and optimisation techniques
3) closed world assumption (take a whole program and compile it =>
you lose dynamic linking or dynamic linked stuff is much slower than the rest)
  this simplifies type inference and allows vtbls like techniques etc
4) type inference (much a reasearch field in absence of any explicit
type information or implicit rules (like in ML)), mostly an open problem if one 
want dynamic loading: type inference for an object oriented program need
whole call graph construction that needs type inference results, a difficult
fix-point problem , algorithms exist but are "slow" and there are problems
dealing with reflective/introspective features of a language.

* java takes 1) to the extreme (it has static typing) and its runtimes use 2),
  you have dynamic linking
* dylan uses 1) and 3), AFAIK no dynamic linking in deployed versions of a 
program
* Self (a sun/stanford univerty project) takes 2 to the extreme, and some
  of the results of the project are used in java runtimes, such runtimes
  (java and even more Self) are very complex and complicated piece of software,
  AFAIK there is no open source project trying to do that kind of stuff,
  these techniques are not simply JIT.

Python and jython at the moment do not exploit any of these things,

1) and using a bit of 4) as an idea has been around for a long time,
let see if and what will happen with P3K.

What JimH was trying (as far as I have understood) was very experimental
and implied a lot of assumptions that are not true in general for python 
semantic, he was using 3) and mostly trying to detect numeric types.

Maybe a bit of 2) can be put in jython to improve its performance,
but using dynamic techniques over a static typed, typesafe and
dynamic compiling/optimizing runtime (the actual JVMs) is likely
to be difficult or impossible, memory consuming, and not worth the effort,
and the increased code base complexity.
Jython is ideal if you don't want performance or can solve your problems
with adding a reasonable amount of pure java.

****************************

[D-Man]
> Besides, unless the VM's do some
> real intelligent runtime optimizations it can't be as fast as C.  It
> is implemented in C.  Every Java instruction takes several C
> instructions to execute. 
The actual jvms try to do some intelligent runtime opt, on the
other hand what java gives you and what C gives is very different,
java has an effective oo dynamic linking, and when a program crash
you always get a nice stack trace etc

Java gives some performance, effective dynamic linking and gc,
a growing and rich set of libs.
But it's verbose and e.g. swing is slow.
For some kind of application the cons are very important, like
complicated server frameworks that dynamicly load modules at runtime...
but in other cases one is better served elsewhere.

regards, Samuele Pedroni.