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

 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

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

 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
Java and C# feature[as are delegates]).

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
algo langs c,c++, pascal, delphi, c#, Java, modular3, oberon, eiffel and
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
C# : boxed items, unsafe, different approach to 'auto' and arrays that are
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

 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

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

 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

 ("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


 where the interface consists of exactly 1 method ?

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

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



 signature and a matching implementation) be considered a special case



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


 where the interface consists of exactly 1 method ?

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

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

 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


 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

 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

 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."

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.

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, Delphi/VCL, Java/[Swing/awt/jfc] or C# for app developement each has good 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 

 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

 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

 an interesting postscript paper how templates will be supported in the

 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

 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

 an interesting postscript paper how templates will be supported in the

 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