www.digitalmars.com         C & C++   DMDScript  

D - Why D isn't Java? article available

reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
Hi,

    I've finished the first draft of this short article, comparing Java to
D. It's intended to make the differences between D and Java clear.

http://www.minddrome.com/produtos/d/why_d_isnt_java.html

    Best regards,
    Daniel Yokomiso.

"Quidquid latine dictum sit, altum sonatur."


---
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
Mar 03 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
I couldn't ask for a nicer article. I'll make a link to it. Thanks!

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:b40vls$2fqv$1 digitaldaemon.com...

 Hi,

     I've finished the first draft of this short article, comparing Java to
 D. It's intended to make the differences between D and Java clear.

 http://www.minddrome.com/produtos/d/why_d_isnt_java.html

     Best regards,
     Daniel Yokomiso.

 "Quidquid latine dictum sit, altum sonatur."


 ---
 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
Mar 03 2003
parent reply Mark Evans <Mark_member pathlink.com> writes:
How about quoting this interview of STLport author A. Stepanov.  (It's
hilarious.)  http://www.stlport.org/resources/StepanovUSA.html

Question:
Java is a very new language, still it lacks templates, so it prevents
using Generic Programming. Everything must be a class. What do you
think of Java?

Answer:
I spent several months programming in Java. Contrary to its authors
prediction, it did not grow on me. I did not find any new insights -
for the first time in my life programming in a new language did not
bring me new insights. It keeps all the stuff that I never use in C++
- inheritance, virtuals - OO gook - and removes the stuff that I find
useful. It might be successful - after all, MS DOS was - and it might
be a profitable thing for all your readers to learn Java, but it has
no intellectual value whatsoever. Look at their implementation of hash
tables. Look at the sorting routines that come with their "cool"
sorting applet. Try to use AWT. The best way to judge a language is to
look at the code written by its proponents. "Radix enim omnium malorum
est cupiditas" - and Java is clearly an example of a money oriented
programming (MOP). As the chief proponent of Java at SGI told me:
"Alex, you have to go where the money is." But I do not particularly
want to go where the money is - it usually does not smell nice there.
Mar 04 2003
next sibling parent "Walter" <walter digitalmars.com> writes:
"Mark Evans" <Mark_member pathlink.com> wrote in message
news:b441ca$17eh$1 digitaldaemon.com...

 How about quoting this interview of STLport author A. Stepanov.  (It's
 hilarious.)  http://www.stlport.org/resources/StepanovUSA.html


It is a great read. Thanks for posting the link. I wonder what Stepanov
would think of D.
Mar 05 2003
prev sibling next sibling parent reply Bill Cox <Bill_member pathlink.com> writes:
In article <b441ca$17eh$1 digitaldaemon.com>, Mark Evans says...

How about quoting this interview of STLport author A. Stepanov.  (It's
hilarious.)  http://www.stlport.org/resources/StepanovUSA.html


A good read.

In defense of Java, it pushed several concepts into the mainstream:

- Garbage collection
- Interfaces, and elimination of multiple inheritance
- Elimination of pointers
- Elimination of templates
- Elimination of virtual modifier
- Elimination of features that can hurt portability

By adding garbage collection, and eliminating concepts that most programmers are
uncomfortable with, Java made great strides in improving productivity.  Most
Java code I've read is far better than most C++ code that I've read.  Just start
downloading random source code from the web to see what I mean.

An old boss I had said I should get 1 point for every line of code I write, and
2 points for every line I eliminate.  I feel that way about languages, and C++
is a great place to look for features to get rid of.

I have to agree that AWT stinks... JFC fixes it, though.

Here's another quote from the article:

------------
Question:
STL pushes C++ compilers to their limits. Contemporary C++ compilers are still
unable to correctly compile some STL code. How could you develop and test STL? 

Answer:
I do have a lot of gray hair as a result of trying to compile STL. The
unfortunate reality is that a lot of code in the present implementation of STL
is suboptimal because of the compiler limitations and bugs of the compilers I
had to use when I was developing STL. Fortunately, I had help from Bjarne in
figuring out what certain unimplemented features are supposed to do. It does
help a lot if you can ask the language designer what a given construct really
does. 
------------


Generic programming is huge.  If used for nothing else, the STL add great
functionallity to C++.  Templates, on the other hand, are a feature that break
compilers, and confuse programmers.

I think Java has been looking for a way around templates for some time that gets
us generic programming without damaging the compiler or Java's users.  Have they
come up with anything good?

I've found that language support for code generation can replace templates.
It's simplifies the language while dramatically enhancing power.  However, it's
not a feature to be used by the masses.  It probably is too confusing for Java.

Bill
Mar 05 2003
parent reply "Jeroen van Bemmel" <anonymous somewhere.com> writes:
I wonder why it always has to be "this language X versus that language Y",
where X is much better than Y because it has this and this and that, and it
got rid of those nasty features a, b and c

Is it really so hard to acknowledge that in particular circumstances one
language may be more suitable than another, in some person's opinion, and
that in other cases it might not be?

"Why D isn't Java" emphasizes the differences and suggests that it would a
good thing for D to be as different from Java as possible. To me it looks
like many of D's features were inspired by / copied from Java, and as such
they also have many things in common. Given the fact that Java is currently
a very popular programming language and D is not (except on this newsgroup
perhaps), it could be wise to mention the similarities rather than celebrate
the differences.
Mar 06 2003
next sibling parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Jeroen van Bemmel" <anonymous somewhere.com> escreveu na mensagem
news:b48i3p$rc4$1 digitaldaemon.com...

 I wonder why it always has to be "this language X versus that language Y",
 where X is much better than Y because it has this and this and that, and


it

 got rid of those nasty features a, b and c

 Is it really so hard to acknowledge that in particular circumstances one
 language may be more suitable than another, in some person's opinion, and
 that in other cases it might not be?

 "Why D isn't Java" emphasizes the differences and suggests that it would a
 good thing for D to be as different from Java as possible. To me it looks
 like many of D's features were inspired by / copied from Java, and as such
 they also have many things in common. Given the fact that Java is


currently

 a very popular programming language and D is not (except on this newsgroup
 perhaps), it could be wise to mention the similarities rather than


celebrate

 the differences.


Lots of people saw D for the first time and said: "Hey, it's just Java with
pointers", or something like that. Walter asked if someone with experience
in Java and D could write an article pointing the differences between the
two. That's why the article emphasizes on the differences.


---
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
Mar 06 2003
prev sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
it would be good to see a unbiased constructive comparison incorporating
http://www.minddrome.com/produtos/d/why_d_isnt_java.html
and http://www.digitalmars.com/d/index.html
and including delphi. although pascal syntax and lacking (as C does) a
builtin GC or templates it does stem from the same algo root, and many
features such as the way arrays are handled, strong typedefs, nested
function, the proposed properties,
delegates and objects as ref appear delphi influenced (the latter also a


as I start to think about it may be for each langauge someone should write a
page why "X is better than D" and someone else write "why D is better than
X" as I'm not sure unbiased views exist in the programming world (the number
of people I know who say Java is a $%^$%^ language, but have never used it,
and the current perl v python discussion)

it might be nice to include 'alien' (non algo based) languages such as
smalltalk, self, lisp,scheme, ocaml, ml, haskel, prolog along with other

even script langs such as python, lua, perl, tcl.

maybe even a page of how X is bodged in Y example Java's use of anon classes
to replace first order functions and delegates

and may be a few more things on what features D does not have that the other
languages do and why they are not needed
Java : inner classes, and different 'interface' behaviour (call by signature
rather than COM), defined eval order
Smalltalk : instanceof and castableto
C++ : pointer to member function and pointer to member
Delphi : sets, dynamic methods, virtual constructors

stack allocated.
ml : patten matching function params (could this be done via templates in D
[with a slight extension to syntax])



"Jeroen van Bemmel" <anonymous somewhere.com> wrote in message
news:b48i3p$rc4$1 digitaldaemon.com...

 I wonder why it always has to be "this language X versus that language Y",
 where X is much better than Y because it has this and this and that, and


it

 got rid of those nasty features a, b and c

 Is it really so hard to acknowledge that in particular circumstances one
 language may be more suitable than another, in some person's opinion, and
 that in other cases it might not be?

 "Why D isn't Java" emphasizes the differences and suggests that it would a
 good thing for D to be as different from Java as possible. To me it looks
 like many of D's features were inspired by / copied from Java, and as such
 they also have many things in common. Given the fact that Java is


currently

 a very popular programming language and D is not (except on this newsgroup
 perhaps), it could be wise to mention the similarities rather than


celebrate

 the differences.
Mar 06 2003
parent reply "Jeroen van Bemmel" <anonymous somewhere.com> writes:
Something that could be valuable would be to not compare feature by feature
("D supports interfaces") but by the issue or design problem that the
language helps resolving ("D supports separation of specification and
implementation"). This would help when, for example, "anonymous delegates"
and "anonymous classes" may be separate features but can both be used to
tackle similar design issues (in this case, something along the lines of
"keeping declaration of functionality lexically close to its use")

BTW, this raises another "theoretical" question: can delegates (a method
signature and a matching implementation) be considered a special case of
interfaces (a declaration and a matching implementation), namely the case
where the interface consists of exactly 1 method ?
Mar 07 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Jeroen van Bemmel" <anonymous somewhere.com> wrote in message
news:b4auh4$2ahr$1 digitaldaemon.com...

 Something that could be valuable would be to not compare feature by


feature

 ("D supports interfaces") but by the issue or design problem that the
 language helps resolving ("D supports separation of specification and
 implementation"). This would help when, for example, "anonymous delegates"
 and "anonymous classes" may be separate features but can both be used to
 tackle similar design issues (in this case, something along the lines of
 "keeping declaration of functionality lexically close to its use")


I agree that the purposes of each of these features can have a large
overlap. I also find that few, when first encountering D, will go into depth
in the documentation. They want a quick overview of features and using the
common term for them (however imprecise that might be) is the right approach
to deliver it.


 BTW, this raises another "theoretical" question: can delegates (a method
 signature and a matching implementation) be considered a special case of
 interfaces (a declaration and a matching implementation), namely the case
 where the interface consists of exactly 1 method ?


I don't think so, because it's not a matching *instance*.
Mar 07 2003
next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
 BTW, this raises another "theoretical" question: can delegates (a method
 signature and a matching implementation) be considered a special case of
 interfaces (a declaration and a matching implementation), namely the




case

 where the interface consists of exactly 1 method ?


 I don't think so, because it's not a matching *instance*.


but don't

interface foo1 {
    int process( int );
}
and

typedef int delegate( int ) foo2;

basically perform the same task  any object and a method with specific
params.

&process is a  int delegate( int )

in languages without delegates interfaces with one methods are use instead
(i.e. Java anon classes)
the only difference is that you can perform a runtime instanceof on an
interface (is a property of an object) and a delegate is not (it a method)
any 'class' can have either.

interface : Object that implement delegate(s)
delegate : method of an object (and the object ) with specific params.

I would not say they are the same, they are very similar and in many places
can be interchanged without effecting the operations of the program.

if there a flash term for a semantic similie ?
Mar 07 2003
parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Mike Wynn" <mike.wynn l8night.co.uk> escreveu na mensagem
news:b4b5v8$2fb1$1 digitaldaemon.com...

 BTW, this raises another "theoretical" question: can delegates (a






method

 signature and a matching implementation) be considered a special case






of

 interfaces (a declaration and a matching implementation), namely the




 case

 where the interface consists of exactly 1 method ?


 I don't think so, because it's not a matching *instance*.


 but don't

 interface foo1 {
     int process( int );
 }
 and

 typedef int delegate( int ) foo2;

 basically perform the same task  any object and a method with specific
 params.

 &process is a  int delegate( int )

 in languages without delegates interfaces with one methods are use instead
 (i.e. Java anon classes)
 the only difference is that you can perform a runtime instanceof on an
 interface (is a property of an object) and a delegate is not (it a method)
 any 'class' can have either.

 interface : Object that implement delegate(s)
 delegate : method of an object (and the object ) with specific params.

 I would not say they are the same, they are very similar and in many


places

 can be interchanged without effecting the operations of the program.

 if there a flash term for a semantic similie ?


See "Everything is an Object", by Luca Cardelli

http://research.microsoft.com/Users/luca/Slides/EverythingIsAnObject.pdf


---
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
Mar 07 2003
prev sibling parent "Jeroen van Bemmel" <anonymous somewhere.com> writes:
 BTW, this raises another "theoretical" question: can delegates (a method
 signature and a matching implementation) be considered a special case of
 interfaces (a declaration and a matching implementation), namely the




case

 where the interface consists of exactly 1 method ?


 I don't think so, because it's not a matching *instance*.


You could view a delegate as temporarily and implicitly creating a stateless
object (is it then still considered an object?) on which you invoke a
method. Or, you could say it has state, namely the context within which it
is invoked. 'this' then becomes the stackframe.

If you would declare an array of delegates you basically get an the
interface, except that operations are invoked by index and not by name. And
you cannot directly associate state with that 'interface', unless you use
some convention where e.g. delegates[0] is a 'state getter'.

For class, you could say that this implicit object is an instance of class
'delegate' which has an 'invoke' method. You could even use a convention
where delegates[1] == getClass, and then such an object can change class by
assigning another delegate to index 1. Eerie ( actually, technically
assigning another delegate to any of the indexes would mean the object is of
another class, since o1.class == o2.class => o1.methods == o2.methods )
Mar 07 2003
prev sibling parent "Jeroen van Bemmel" <anonymous somewhere.com> writes:
STL could be useful if I wouldn't keep forgetting the syntax - to me ease of
use has its value, perhaps even more than execution efficiency
Mar 06 2003
prev sibling parent reply Farmer <itsFarmer. freenet.de> writes:
Hi,

your article reads very good, but I really missed one major topic:

- Java(TM) requires an interpreting VM or JIT-compiling VM.
- D is compiled statically to native code.

I think, that with the inclusion of RMI and reflection-API in JDK 1.1, 
compiling Java(TM) to native code became impossible.

D's powerful template features cannot be efficently implemented with a JIT-
compiler. Consequently, D will be strongly bound to static compiling.


Furthermore I disagree with this statement:
"While Java intends to be an application programming language, D was 
designed to be a system programming language." 

From D spec "Overview":
"D is a general purpose systems and applications programming language."


I don't like hyping Java(TM) to be an application programming language: 

Maybe calling it a web application programming language would be a fair 
classification; Applets, Servlets, JSP's and EJB's  are all examples for 
this. 



Farmer.



Java is a trademark of Sun Microsystems, Inc.







"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in
news:b40vls$2fqv$1 digitaldaemon.com: 


 Hi,
 
     I've finished the first draft of this short article, comparing
     Java to 
 D. It's intended to make the differences between D and Java clear.
 
 http://www.minddrome.com/produtos/d/why_d_isnt_java.html
 
     Best regards,
     Daniel Yokomiso.
 
 "Quidquid latine dictum sit, altum sonatur."
 
 
 ---
 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
Mar 06 2003
next sibling parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
Hi,

    Comments embedded.


"Farmer" <itsFarmer. freenet.de> escreveu na mensagem
news:Xns93372D484073itsFarmer 63.105.9.61...

 Hi,

 your article reads very good, but I really missed one major topic:

 - Java(TM) requires an interpreting VM or JIT-compiling VM.
 - D is compiled statically to native code.

 I think, that with the inclusion of RMI and reflection-API in JDK 1.1,
 compiling Java(TM) to native code became impossible.



    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 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). Some compiled
languages support some kind of reflection, including Common Lisp
 http://www.cons.org/cmucl/ ) and Smalltalk (there are some implementations
around, but I'm too lazy to google them up). It's just a matter of exposing
the vtables or whatever is your implementation of methods as reflection.
There's some talk about providing reflection in D, but it's not a top
feature. Also it's possible for some D implementation to be fully
interpreted. The DotGNU folks ( http://www.dotgnu.org ) have a C to IL
compiler (proof of concept), giving you the safety of C and the speed of IL
;-)



 D's powerful template features cannot be efficently implemented with a


JIT-

 compiler. Consequently, D will be strongly bound to static compiling.



    Ilya posted a link to http://www.gnu.org/software/lightning/ a very fast
JIT compiler. Templates can be efficiently compiled, specially if you have
some time for the JIT to profile your code and choose the best optimization
strategy.



 Furthermore I disagree with this statement:
 "While Java intends to be an application programming language, D was
 designed to be a system programming language."

 From D spec "Overview":
 "D is a general purpose systems and applications programming language."



    Hmmm, I'll put "too" at the end.



 I don't like hyping Java(TM) to be an application programming language:

 Maybe calling it a web application programming language would be a fair
 classification; Applets, Servlets, JSP's and EJB's  are all examples for
 this.



    I don't know about this. I use Eclipse. It's a Java application and
pretty responsive. There are lots of good application examples from the Sun
site ( http://java.sun.com/products/jfc/tsc/sightings/ ). Java can be used
to develop good applications, but most programmers are lazy and don't
profile their applications correctly.



 Farmer.



[snip]


    Best regards,
    Daniel Yokomiso.

"If people do not believe that mathematics is simple, it is only because
they do not realize how complicated life is."
- John von Neumann


---
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
Mar 06 2003
parent reply Farmer <itsFarmer. freenet.de> writes:
"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?".



 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

Their whitepaper (http://www.excelsior-usa.com/pdf/jetwp.pdf) contains 
details about how static compilation of programms written in the Java 
language is limited.

[
3.2 Mixed Compilation Model

The Java dynamic class loading facility, extensively employed in Java APIs 
and application programs, has always been a headache for authors of ahead-
of-time Java compilers. The only available solutions were:
• require pre-compilation of all classes that the application may 
dynamically load at run-time. This way, classes that are never loaded just 
waste memory space; also applications that load classes unknown at compile-
time may not be compiled by such tools.
• include into the resulting executable a virtual machine for 
interpretation of dynamically loaded classes, effectively profaning the 
very idea of optimizing native code compilation.

Excelsior JET is the first product for the Microsoft Windows platform that 
introduces a complete solution for the problem based solely on optimizing 
compilation. It is called the mixed compilation model and may be used for 
applications which essentially rely on dynamic class loading (e.g. if they 
employ RMI Distributed Class Model, Dynamic Proxy API etc).  

3.2.1 On-the-fly compilation
In the mixed model, the JET run-time system is provided with the JET 
Caching JIT compiler, a scaled down version of the main JET compiler.
...
]



 From D spec "Overview":
 "D is a general purpose systems and applications programming
 language." 


 
 
     Hmmm, I'll put "too" at the end.
 
 


After all, assembler intends to be an application programming language, too 
[Check out win32asm for examples. Not to mention programms written by 
Walter ;-)], and D encompasses assembler. 



Farmer.



Java is a trademark of Sun Microsystems, Inc.
Mar 08 2003
parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
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
Mar 08 2003
parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
 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)
Mar 08 2003
prev sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"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).


 Furthermore I disagree with this statement:
 "While Java intends to be an application programming language, D was
 designed to be a system programming language."


actually intially it was Live Oak, and intended for writing client side X
widgets to reduce network bandwidth (why should button click and mouse move
be sent to the X server when even a slow spec X client could handle the
basic messages instead)
it was then release as a web widget langauge that could be used for apps
(the beta AWT was horrific)


 Maybe calling it a web application programming language would be a fair
 classification; Applets, Servlets, JSP's and EJB's  are all examples for
 this.


it has been used for that,  along with cross platfrom embedded (as in
embedded in something else, or on a PDA/Phone) lang
and I never saw a lot of difference in using C++/MFC, C/GTK, Perl/Tk,

points each has bad points, (put widgets, get events, do stuff)  and most
GUI apps do not need front end performance, (fast underlying libs sometimes
are needed but all the above can link to C dlls)

I always saw it as Suns answer to VB.


 Java is a trademark of Sun Microsystems, Inc.
Mar 06 2003
parent reply Farmer <itsFarmer. freenet.de> writes:
"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.
Mar 08 2003
next sibling parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Farmer" <itsFarmer. freenet.de> escreveu na mensagem
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.


There are some implementations of generics today, like Rotor and DotGnu.


---
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
Mar 08 2003
prev sibling parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"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.
Mar 08 2003