Hi,

    Comments embedded.

"Farmer" <itsFarmer.@freenet.de> escreveu na mensagem news:Xns9338BA88DDEE8itsFarmer@63.105.9.61...
> "Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in news:b48o5k$vig$1@digitaldaemon.com:
> >     It's an implementation issue, not a language issue, and I tried to
> >     focus
> > the article on language comparison. In agree that almost all uses of
>
> I see. You are comparing the D language with the Java(tm) language. Required runtime environments of a language could be part of your upcoming article "What makes D worth-while?".


The hardest part when you compare languages is separating what is a language issue and what is an implementation issue. For example stack vs. heap is implementation issue, but value vs. reference is a language issue. My upcoming article will deal with language, library and community maturity. I want to isolate the concerns people usually have when they see a new language, like: "Why should I learn this?", "I know that this is better than the 'X' language, but 'X' language is standard/mature/proven.", "Language 'Y' better is 'Z' but worst than 'X', therefore 'Y' is useless, but I'll keep using 'Z' because 'X' is too weird" and other arguments. You can read lots of similar arguments in this newsgroup and in the slashdot comments on D. Comparison about runtimes will be made in the future in another article.


> > Java today use either a interpreter (a few of them) or a JIT compiling
> > VM. But there are some alternatives, like specialized processor
> >  http://www.jopdesign.com/ is particularly interesting) or native
> >  compilers
> > ( http://www.excelsior-usa.com/jet.html supports JDK 1.4). [snip]
>
> Excellent link. They have good stuff on their side about current compiler technology, and free downloads of their development tools.
>
> "Excelsior JET Overview" says:
>
> -Limited support for Java dynamic class loading

[snip]

    Yes, dynamic class-loading is tricky, but plain reflection is possible
without much trouble. If you have access to the compiler during runtime,
reflection isn't much of a problem. Off course you can always bring an
example that'll be very difficult to support, but IMO most of the cases will
be simpler.

    Best regards,
    Daniel Yokomiso.

"If you lie to the compiler, it will get its revenge."
- Henry Spencer


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.459 / Virus Database: 258 - Release Date: 25/2/2003

"Farmer" <itsFarmer.@freenet.de> wrote in message news:Xns9338BA8804C3itsFarmer@63.105.9.61...
> "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in news:b48p3j$105e$1@digitaldaemon.com:
>
>
> >
> > "Farmer" <itsFarmer.@freenet.de> wrote in message news:Xns93372D484073itsFarmer@63.105.9.61...
> >> Hi,
> >> D's powerful template features cannot be efficently implemented with
> >> a
> > JIT-
> >> compiler. Consequently, D will be strongly bound to static compiling.
> >
> > why can't you JIT the D templates ? they are explicitly instatiated first (make finding them a bit easier) (if you compile from the ast rather than trying to create a intermediate bytecode it should work).
>
> Right. I was too narrow minded to recognize that templates are not a
> problem at all, if done during (bytecode) compile time.
> Problems araise only when template are instantiated dynamically. I
remember
> an interesting postscript paper how templates will be supported in the
next
> version of .Net from Microsoft Research.
>

Still don't see it, if you are jit-ing a language with templates, then the
bytecode would (should) reflect that so if an new instance is needed the
compiler has to recompile the bytecode,
if from source, all you need to store is the ast or dag, and again compile
for the new types.

you can't compile once  .... well there are conditions when the templated
types are all a sub class of Object and the methods the template calls are
only every methods of that base class, and I'm sure theres an issue with
writing too, but does allow you to only need small amounts of glue perhaps
treat the template as a object so the info for the runtime type checks are
passed to the functions, or if the language is statically typed then given
class MyObject { Object parent(){ .... } }
class MyDerv : MyObject { Object parent() { .... } }
template( T : MyObject ) { Object func( T o ) { o.getParent(); }
the following two functions
Object func ( MyClass o ) { o.getParent(); }
Object func ( MyDerv o ) { o.getParent(); }
can compile to the same function.
I would expect that only templated simple collection classes would be
compilable in this manner.

> > > Java today use either a interpreter (a few of them) or a JIT compiling VM. But there are some alternatives, like specialized processor

Java is also a set of things;
Java + JavaVM+std libs (Java Platfrom) : which most people call Java
Java the language : designed for the JavaVM but does not have to be, it does
define when things such as class initialisation occurs which make static
compilation a pain (among other things).
Java standard libs (bytecode) : part of the Java platform, but you can
rewrite them all and the JavaVM should still work (MS one short cuts
java.lang.string or did so you could not load your own Object and String
classes)
JavaVM : a cross platform VM/bytecode spec for which Java the lang (and its
compilers) only generate a sub class (a large sub class) of its actual
potential. currently interpreter or JIT, I don't know of any that cache
classes in dll's; again the dynamic loading means that a Dynamic compiler
(or a jit that interprets once) is the best, it can perform all the nec
resolution and write compiled code to be executed next time without having
to check if classes require loading.

there are several VM's and several Java lang to bytecode compilers (Jikes
for instance) and a couple of not quite Java (platform) to native compilers

So what do you compare D to ?
D v Java (just lang v lang)
D+phobos v Java(Sun's JRE)+VM+stdlibs

the same for C/C++ (are libc stl etc issues)