March 07, 2003
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


March 07, 2003
"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,
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.
>



March 07, 2003
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 ?


March 07, 2003
"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*.


March 07, 2003
>
> > 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 ?



March 07, 2003
> > 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 )


March 08, 2003
"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


March 08, 2003
"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.

March 08, 2003
"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.
March 08, 2003
"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