www.digitalmars.com         C & C++   DMDScript  

D - I smell cofee

reply "Andrew Nguyen" <pythonnet hotmail.com> writes:
For some reason, D just looks like compiled JAVA. I suggest you guys _keep_
operator overloading. Heck, read the slashdot comments. You'll some scathing
but all the while TRUE statements.

And either way, it should be called P, CPL->BCPL->B->C->P->L ;)
Jul 16 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Andrew Nguyen" <pythonnet hotmail.com> wrote in message
news:ah17hh$1f5c$1 digitaldaemon.com...
 For some reason, D just looks like compiled JAVA. I suggest you guys
_keep_
 operator overloading. Heck, read the slashdot comments. You'll some
scathing
 but all the while TRUE statements.

 And either way, it should be called P, CPL->BCPL->B->C->P->L ;)
I read 'em. And D code does indeed look a lot like Java code, and with good reason. Java has been well thought out and is widely applauded for the structure of the language. It is thought that Java is excellent for learning Object Oriented Programming, at least at a lot of universities, and it has proven itself as a language capable of creating well maintanable code. There are some negatives about Java too, however. One of them is the overhead that comes with interpreted languaged. And the sandbox model, although very good for web applets and the like, is less suited for 'normal' windowed applications. Being a compiled language D remedies most of these issues, allowing you to write fast, to-the-metal code when you need to, but highly structured and high-level code when you can. It even allows you to include inline assembly into your code. Something Java could never do. Rather then a replacement for Java, think of D as a replacement for C++. By dropping backward compatibility with C, Walter Bright is giving himself some freedoms the designers of C++ didn't have, allowing D to become the language C++ should have been. D also adds some fresh ideas of it's own, such as Design By Contract and properties on all types. Read the spec, you will be pleasantly surprised. Oh and incidently, template support is planned for version 2.0, and there are serious thoughts about operator overloading too. Please let us know what you think, we welcome your input! (Oh and calling it P would be a little pretentious wouldn't it? <g>. Anyway, the language was originally called Mars, but because everyone kept calling it D, Walter caved in and adopted that name) -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
Jul 16 2002
next sibling parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
I like the name Mars.  At least there haven't been 14 of those.

Sean

 (Oh and calling it P would be a little pretentious
 wouldn't it? <g>. Anyway, the language was
 originally called Mars, but because everyone kept
 calling it D, Walter caved in and adopted that name)


 --
 Stijn
 OddesE_XYZ hotmail.com
 http://OddesE.cjb.net
Jul 16 2002
prev sibling parent reply "Steven Shaw" <steven_shaw iprimus.com.au> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:ah1akd$1i42$1 digitaldaemon.com...
*snip*

 There are some negatives about Java too, however.
 One of them is the overhead that comes with interpreted
 languaged. And the sandbox model, although very good
 for web applets and the like, is less suited for
 'normal' windowed applications.
You are misinformed. Java is not an "interpreted language". Modern jvms use just-in-time compilation, though I wish they'd do depoy-time/install-time compilation. Anyone know why they don't? iirc MS-CLR does this. With "normal windowed applications" you are not restricted to a "sandbox model". Gui applications are pretty slow with Java. Maybe that's part of the reason the elispse guys came up with their own peer gui toolkit - rather than using Swing. It's also said that furious object allocations and then garbage collection can become a problem particularly with Java gui applications. This problem is inherent in the language. All objects are allocated on the gc heap. There is no other option. Use of object factories using featherweight pattern can help. I don't think this is such a problem for D as some things (array, structs) can be stack allocated, yes? Could still be a problem in D for class-centric programs since all objects are stored on the gc heap like Java. "negatives". planned also. Java generics are scheduled for jdk 1.5 iirc. -- Regards, Steve.
Jul 20 2002
next sibling parent reply "anderson" <anderson firestar.com.au> writes:

design leans in that direction. They both suffer from high-level language
efficiency problems. There more worried about the making it easy to program
(BASIC) rather then staying close to the OS/machine language and making it

mind in the future (although there's a while to go). It's now more the
language shaping the CPU then the CPU shaping the language as it has been in
the past. Java chips are already being produced. I wouldn't want to see a
comparison of D verse JAVA running on a java chip.

"Steven Shaw" <steven_shaw iprimus.com.au> wrote in message
news:ahcu7l$ggn$1 digitaldaemon.com...
 "OddesE" <OddesE_XYZ hotmail.com> wrote in message
 news:ah1akd$1i42$1 digitaldaemon.com...
*snip*

 There are some negatives about Java too, however.
 One of them is the overhead that comes with interpreted
 languaged. And the sandbox model, although very good
 for web applets and the like, is less suited for
 'normal' windowed applications.
You are misinformed. Java is not an "interpreted language". Modern jvms use just-in-time compilation, though I wish they'd do depoy-time/install-time compilation. Anyone know why they don't? iirc MS-CLR does this. With "normal windowed applications" you are not restricted to a "sandbox model". Gui applications are pretty slow with Java. Maybe that's part of the
reason
 the elispse guys came up with their own peer gui toolkit - rather than
using
 Swing.

 It's also said that furious object allocations and then garbage collection
 can become a problem particularly with Java gui applications. This problem
 is inherent in the language. All objects are allocated on the gc heap.
There
 is no other option. Use of object factories using featherweight pattern
can
 help. I don't think this is such a problem for D as some things (array,
 structs) can be stack allocated, yes? Could still be a problem in D for
 class-centric programs since all objects are stored on the gc heap like
 Java.


Java
 "negatives".

 planned also.
 Java generics are scheduled for jdk 1.5 iirc.

 --
 Regards,
 Steve.
Jul 20 2002
parent reply "Steven Shaw" <steven_shaw iprimus.com.au> writes:
Java was designed for interpretation. I think it was M$ would created the
first JIT for Java.


cannot be efficiently interpreted. One project I'm aware, of, though -
Portable.NET - transforms IL into something that can be efficiently
interpreted and then does so. The Mono project also have an interpreter -
mint, i'm not sure whether that's intended to be efficient (but you can be
sure if it is, it's not interpreting IL directly).

What do you mean be "high-level language efficiency problems"?

In part I am playing devils advocate here. I love programming languages and
so am all for a new one!
I like to understand the motivation behind it etc. I don't like to see
misconceptions being thrown around. You really don't have to be convinced
that every other language is crap before making a new one. There could be
just one thing that they don't do or a unique combination of things etc.

So, taking of any devils cap:

1. I really like that D is modular (the core of D is quite like Oberon
2/Component Pascal with a C-like syntax). Neither C or C++ can claim to be
modular (you can attempt to use these languages in a modular way but...).


namespaces/scoping/linking rules still have me baffled.I have a disturbing
feeling, though, that CLR's way of modularity might just be more scalable
than Oberon2 (it's got all this assembly versioning). Anyways, D overcomes
problems with modules in languages like Oberon by using namespaces in a very
simple way: "module c.stdio". I love this. All modula-style languages should
have had the foresight to adopt this kind of thing long ago.


Java doesn't offer that. Not sure what use inline IL would be anyway.

3. D ability to call C code without fuss. no-fuss C interoperability is not
on offer with Java (don't know about ms-clr). I assume that the
implementation uses the boehm conservative gc? This makes interoperability
even easier.

I find these are 3 features meaningful. Though I'd rarely find a need for
inline assembler in my day-job (information systems).

Like all practical language designs, D borrows useful features from other

Sometimes, though, you can just assume that designers of those language got
it right...

A 4th feature hasn't arrived yet but is in the works is a cross-platform

Windows-only world. Even so, it would have been an interesting experiment.
I'm going to devoate some of my meagre skill to GnuD (D for gcc) or whatever
it's called when I have a linux installation to play with once again.

-- Regards, Steve.


"anderson" <anderson firestar.com.au> wrote in message
news:ahd53a$n2h$1 digitaldaemon.com...

 design leans in that direction. They both suffer from high-level language
 efficiency problems. There more worried about the making it easy to
program
 (BASIC) rather then staying close to the OS/machine language and making it

in
 mind in the future (although there's a while to go). It's now more the
 language shaping the CPU then the CPU shaping the language as it has been
in
 the past. Java chips are already being produced. I wouldn't want to see a
 comparison of D verse JAVA running on a java chip.

 "Steven Shaw" <steven_shaw iprimus.com.au> wrote in message
 news:ahcu7l$ggn$1 digitaldaemon.com...
 "OddesE" <OddesE_XYZ hotmail.com> wrote in message
 news:ah1akd$1i42$1 digitaldaemon.com...
*snip*

 There are some negatives about Java too, however.
 One of them is the overhead that comes with interpreted
 languaged. And the sandbox model, although very good
 for web applets and the like, is less suited for
 'normal' windowed applications.
You are misinformed. Java is not an "interpreted language". Modern jvms use just-in-time compilation, though I wish they'd do depoy-time/install-time
compilation.
 Anyone know why they don't? iirc MS-CLR does this.
 With "normal windowed applications" you are not restricted to a "sandbox
 model".

 Gui applications are pretty slow with Java. Maybe that's part of the
reason
 the elispse guys came up with their own peer gui toolkit - rather than
using
 Swing.

 It's also said that furious object allocations and then garbage
collection
 can become a problem particularly with Java gui applications. This
problem
 is inherent in the language. All objects are allocated on the gc heap.
There
 is no other option. Use of object factories using featherweight pattern
can
 help. I don't think this is such a problem for D as some things (array,
 structs) can be stack allocated, yes? Could still be a problem in D for
 class-centric programs since all objects are stored on the gc heap like
 Java.


Java
 "negatives".

 planned also.
 Java generics are scheduled for jdk 1.5 iirc.

 --
 Regards,
 Steve.
Jul 21 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Steven Shaw" <steven_shaw iprimus.com.au> wrote in message
news:ahdmff$18fr$1 digitaldaemon.com...
 Java was designed for interpretation. I think it was M$ would created the
 first JIT for Java.
Symantec did the first JIT for Java.
 1. I really like that D is modular (the core of D is quite like Oberon
 2/Component Pascal with a C-like syntax). Neither C or C++ can claim to be
 modular (you can attempt to use these languages in a modular way but...).
 Java isn't modular - or maybe it could be called class-based modularlity.

 namespaces/scoping/linking rules still have me baffled.I have a disturbing
 feeling, though, that CLR's way of modularity might just be more scalable
 than Oberon2 (it's got all this assembly versioning). Anyways, D overcomes
 problems with modules in languages like Oberon by using namespaces in a
very
 simple way: "module c.stdio". I love this. All modula-style languages
should
 have had the foresight to adopt this kind of thing long ago.
Yeah, I don't understand why those other languages didn't simply implement the obvious. I hope I didn't miss anything <g>.

and
 Java doesn't offer that. Not sure what use inline IL would be anyway.
You don't need inline assembler often, but when you do need it, it's a real winner to have it right there in the language rather than trying to figure out how to hook up an alien assembler/compiler. D also does inline assembler in a simple, clean manner that is integrated with the optimizer.
 3. D ability to call C code without fuss. no-fuss C interoperability is
not
 on offer with Java (don't know about ms-clr). I assume that the
 implementation uses the boehm conservative gc? This makes interoperability
 even easier.
No, it does not use the Boehm gc. The original design did, but I thought it best to write a gc in D and remove any dependence on having a C compiler to get the library built.
 I find these are 3 features meaningful. Though I'd rarely find a need for
 inline assembler in my day-job (information systems).
The features such as design by contract, unit testing, and other robustness/reliability/testing features are also a big win.
 Like all practical language designs, D borrows useful features from other

 Sometimes, though, you can just assume that designers of those language
got
 it right...
similarities, but those are coincidences, and I think indicative of those testing and design by contract. What Java did was prove there was a market for a language that was simpler and less confusing than C++, though I obviously do not agree with the design choices in Java.
 A 4th feature hasn't arrived yet but is in the works is a cross-platform

 Windows-only world. Even so, it would have been an interesting experiment.
 I'm going to devoate some of my meagre skill to GnuD (D for gcc) or
whatever
 it's called when I have a linux installation to play with once again.
I agree that a gnu D will open up D to much wider acceptance.
Jul 21 2002
parent reply "Steven Shaw" <steven_shaw iprimus.com.au> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ahfuq4$a3a$1 digitaldaemon.com...
 "Steven Shaw" <steven_shaw iprimus.com.au> wrote in message
 news:ahdmff$18fr$1 digitaldaemon.com...
 Java was designed for interpretation. I think it was M$ would created
the
 first JIT for Java.
Symantec did the first JIT for Java.
oops. I really wasn't sure. It was probably that ms had the fastest jvm there for a while.
 *snip*
 3. D ability to call C code without fuss. no-fuss C interoperability is
not
 on offer with Java (don't know about ms-clr). I assume that the
 implementation uses the boehm conservative gc? This makes
interoperability
 even easier.
No, it does not use the Boehm gc. The original design did, but I thought
it
 best to write a gc in D and remove any dependence on having a C compiler
to
 get the library built.
That amazing! I'd love to be able to implement a garbage collector. Is the D gc conservative like Boehm or precise like ms-clr?
 I find these are 3 features meaningful. Though I'd rarely find a need
for
 inline assembler in my day-job (information systems).
The features such as design by contract, unit testing, and other robustness/reliability/testing features are also a big win.
I'm still not sure about integrated unit testing in D. I've got dmd working now so I can give it a try.
 Like all practical language designs, D borrows useful features from
other

 Sometimes, though, you can just assume that designers of those language
got
 it right...
similarities, but those are coincidences, and I think indicative of those testing and design by contract. What Java did was prove there was a market for a language that was simpler and less confusing than C++, though I obviously do not agree with the design choices in Java.
similarities :-) Similarities are good for D because it makes it easier to learn. The worst thing about modula-family languages is the lack of C-like expressions such as "x += y" and assignments without value - 'cause I really like "while ((c = getchar(f) != ' ') { ... }". Regard, Steve.
Jul 21 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Steven Shaw" <steven_shaw iprimus.com.au> wrote in message
news:ahg69o$hmr$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:ahfuq4$a3a$1 digitaldaemon.com...
 "Steven Shaw" <steven_shaw iprimus.com.au> wrote in message
 news:ahdmff$18fr$1 digitaldaemon.com...
 Java was designed for interpretation. I think it was M$ would created
the
 first JIT for Java.
Symantec did the first JIT for Java.
oops. I really wasn't sure. It was probably that ms had the fastest jvm there for a while.
Well, no, Symantec's was faster, too <g>. (Microsoft had better marketing, though.)
 That amazing! I'd love to be able to implement a garbage collector.
 Is the D gc conservative like Boehm or precise like ms-clr?
It's conservative. The source comes with the alpha compiler.
 The worst
 thing about
 modula-family languages is the lack of C-like expressions such as "x += y"
 and
 assignments without value - 'cause I really like "while ((c = getchar(f)
!=
 ' ') { ... }".
My problem with the pascal (and modula) philosophy is that it left you with no way around the type constraints imposed by the language. D tries to provide a safety net without a straight jacket.
Jul 22 2002
next sibling parent reply "Robert M. Münch" <robert.muench robertmuench.de> writes:
"Walter" <walter digitalmars.com> schrieb im Newsbeitrag
news:ahgenb$rsj$1 digitaldaemon.com...

 It's conservative. The source comes with the alpha compiler.
Just a stupid question: How can I write a GC with D while D uses a GC? Can I compile without GC support? Note: I don't have a chance to have a look at the GC sources at the moment. Robert
Jul 22 2002
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
"Robert M. Münch" wrote:

 Just a stupid question: How can I write a GC with D while D uses a GC?
You would have to define your own allocation routine. You could write a mark-and-sweep routine that scans all of the area of memory you've allocated, and cleans up things that aren't used anymore. Since you would always keep a pointer (in the GC code) to each block you've allocated, D would never clean it up until you "forgot" about it.
 Can I
 compile without GC support?
The GC can be disabled. People have talked about removing the GC altogether; that is probably possible, though I don't think that there is an "official" way to do that yet. -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Jul 22 2002
parent reply Pavel Minayev <evilone omen.ru> writes:
On Mon, 22 Jul 2002 06:58:00 -0700 Russ Lewis 
<spamhole-2001-07-16 deming-os.org> wrote:

 You would have to define your own allocation routine.  You could write a
 mark-and-sweep routine that scans all of the area of memory you've allocated,
 and cleans up things that aren't used anymore.  Since you would always keep a
 pointer (in the GC code) to each block you've allocated, D would never clean 
it
 up until you "forgot" about it.
But still, dynamic arrays will still be GCed. You also have to use operator new to create class instances, so these will also be GCed. I think a GC can be written simply by rewriting Walter's GC, keeping the interface, but changing the internals.
 Can I
 compile without GC support?
The GC can be disabled. People have talked about removing the GC altogether; that is probably possible, though I don't think that there is an "official"
way
 to do that yet.
D philosophy is GC-centric. For example, you can frequently find an array or a pointer to memory allocated inside a function then returned from it... how would you handle it if there was no GC?
Jul 22 2002
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Pavel Minayev wrote:

 On Mon, 22 Jul 2002 06:58:00 -0700 Russ Lewis
 <spamhole-2001-07-16 deming-os.org> wrote:

 You would have to define your own allocation routine.  You could write a
 mark-and-sweep routine that scans all of the area of memory you've allocated,
 and cleans up things that aren't used anymore.  Since you would always keep a
 pointer (in the GC code) to each block you've allocated, D would never clean
it
 up until you "forgot" about it.
But still, dynamic arrays will still be GCed. You also have to use operator new to create class instances, so these will also be GCed.
Right, a custom GC would require hooks throughout your code, making it ugly.
 I think a GC can be written simply by rewriting Walter's GC, keeping the
 interface, but changing the internals.
An intriguing solution! -- The Villagers are Online! http://villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Jul 22 2002
prev sibling next sibling parent "Steven Shaw" <steven_shaw iprimus.com.au> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ahgenb$rsj$1 digitaldaemon.com...
 *snip*
 My problem with the pascal (and modula) philosophy is that it left you
with
 no way around the type constraints imposed by the language. D tries to
 provide a safety net without a straight jacket.
Modula-3 allows unsafe casting. It's was designed as a systems programming language. In m3 there are safe and unsafe modules. Unsafe modules can have unsafe features like casts and address manipulation. It's pretty cool.
Jul 24 2002
prev sibling next sibling parent reply "Steven Shaw" <steven_shaw iprimus.com.au> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ahgenb$rsj$1 digitaldaemon.com...
 It's conservative. The source comes with the alpha compiler.
Is it all in the the dmd/src/phobos/gc2 directory?
Jul 24 2002
parent "Walter" <walter digitalmars.com> writes:
"Steven Shaw" <steven_shaw iprimus.com.au> wrote in message
news:ahlsqi$29sg$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:ahgenb$rsj$1 digitaldaemon.com...
 It's conservative. The source comes with the alpha compiler.
Is it all in the the dmd/src/phobos/gc2 directory?
Yes.
Jul 24 2002
prev sibling parent reply "Steven Shaw" <steven_shaw iprimus.com.au> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ahgenb$rsj$1 digitaldaemon.com...
 Symantec did the first JIT for Java.
oops. I really wasn't sure. It was probably that ms had the fastest jvm there for a while.
Well, no, Symantec's was faster, too <g>. (Microsoft had better marketing, though.)
Probably a vicious rumour :-)
Jul 24 2002
parent "Walter" <walter digitalmars.com> writes:
"Steven Shaw" <steven_shaw iprimus.com.au> wrote in message
news:ahltg0$2aic$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:ahgenb$rsj$1 digitaldaemon.com...
 Symantec did the first JIT for Java.
oops. I really wasn't sure. It was probably that ms had the fastest
jvm
 there for a while.
Well, no, Symantec's was faster, too <g>. (Microsoft had better
marketing,
 though.)
Probably a vicious rumour :-)
One of my educations in the power of marketing was a compiler roundup in a programming magazine a few eons ago. There was a nice neat table, with my compiler winning all the speed benchmarks. The text of the article concluded that Brand X's compiler was faster.
Jul 24 2002
prev sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Steven Shaw" <steven_shaw iprimus.com.au> wrote in message
news:ahcu7l$ggn$1 digitaldaemon.com...
 "OddesE" <OddesE_XYZ hotmail.com> wrote in message
 news:ah1akd$1i42$1 digitaldaemon.com...
*snip*

 There are some negatives about Java too, however.
 One of them is the overhead that comes with interpreted
 languaged. And the sandbox model, although very good
 for web applets and the like, is less suited for
 'normal' windowed applications.
You are misinformed. Java is not an "interpreted language". Modern jvms use just-in-time compilation, though I wish they'd do depoy-time/install-time compilation. Anyone know why they don't? iirc MS-CLR does this. With "normal windowed applications" you are not restricted to a "sandbox model".
<SNIP> Maybe I used the term wrong, sorry about that, English is not my native language. What I meant by sandbox here, is that you are shielded from the underlying system. As far as I know, in Java, you cannot call system functions, such as CreateWindowEx for Windows, or fork for Unix. So in that respect, you *are* within a sandbox. It is also difficult if not important, to talk directly to a lot of hardware, although this is also the case for a lot of OS'es. Also, you cannot use inline asm. I call this sandboxed. Ofcourse, the normal sandbox is not as strict as the one used for web applets, where you cannot even write a file to disk, but is still is a form of sandboxing. Sandboxing is great in some occasions, but it can be a big negative in other occasions too. I have nothing against Java, actually I love it. It is a really beautiful language. I was just explaining differences between Java and D, and the 'sandboxing' of Java is definitely a difference, and a negative in some cases. Also, Java *is* an interpreted language. When Java first came out, Just In Time compilation wasn't even available. Just because the JVM's got better, doesn't mean the language changed...I like Java the language, I just don't like Java the environment / Virtual Machine and Java programs. That is the core of the problem, I don't like most Java programs that I have encountered so I am not easily inclined to write one myself. I did do some Java programming though, enough to know that I love most things about the language itself, especially the syntax and the object model. This is what attracts me in D, it 'feels' like Java. :) -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
Jul 23 2002
parent reply "Steven Shaw" <steven_shaw iprimus.com.au> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:ahkfgd$mko$1 digitaldaemon.com...
 *snip*

 Maybe I used the term wrong, sorry about that, English
 is not my native language. What I meant by sandbox here,
 is that you are shielded from the underlying system.

 As far as I know, in Java, you cannot call system
 functions, such as CreateWindowEx for Windows, or fork
 for Unix. So in that respect, you *are* within a sandbox.
Got you. I agree with you that calling C functions directly is a good feature for D. You can call CreateWindowEx or whatever from Java. Just dot directly afaik. I think that Microsoft's Java implementation did allow you to do it more or less directly - via JDirect. That got them in trouble with Sun and hence we
 *snip*

 Also, Java *is* an interpreted language. When Java first
 came out, Just In Time compilation wasn't even available.
 Just because the JVM's got better, doesn't mean the
 language changed...I like Java the language, I just
 don't like Java the environment / Virtual Machine and
 Java programs. That is the core of the problem, I don't
 like most Java programs that I have encountered so I am
 not easily inclined to write one myself. I did do some
 Java programming though, enough to know that I love most
 things about the language itself, especially the syntax
 and the object model. This is what attracts me in D, it
 'feels' like Java. :)
It's doesn't seem right to me to talk about an "interpreted language" in any case. A language definition probably shouldn't say anything about whether the implementation will interpret intermediate code or compile to native code. Languages can be designed with interpretation in mind, though. Fortunately, the Java designers had the foresight not to include features which make native compilation harder. Calling Java an interpreted *language* is just ridculous. Is C an interpreted language because some C interpreters exist? You said yourself that the Java language didn't change when people started inventing JITs - so what about Java made it "interpreted"? Cheers, Steve.
Jul 24 2002
next sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Steven Shaw" <steven_shaw iprimus.com.au> wrote in message
news:ahltmr$2akd$1 digitaldaemon.com...

<SNIP>
 It's doesn't seem right to me to talk about an "interpreted language" in
 any case. A language definition probably shouldn't say anything about
 whether the implementation will interpret intermediate code or compile
 to native code. Languages can be designed with interpretation in mind,
 though. Fortunately, the Java designers had the foresight not to include
 features which make native compilation harder.

 Calling Java an interpreted *language* is just ridculous.
 Is C an interpreted language because some C interpreters exist?
 You said yourself that the Java language didn't change when people started
 inventing
 JITs - so what about Java made it "interpreted"?

 Cheers, Steve.
I guess you are right about that... Are there any native compilers for Java available? That would be cool! -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
Jul 24 2002
parent Jonathan Andrew <jon ece.arizona.edu> writes:
OddesE wrote:
 "Steven Shaw" <steven_shaw iprimus.com.au> wrote in message
 news:ahltmr$2akd$1 digitaldaemon.com...
 
 <SNIP>
 
It's doesn't seem right to me to talk about an "interpreted language" in
any case. A language definition probably shouldn't say anything about
whether the implementation will interpret intermediate code or compile
to native code. Languages can be designed with interpretation in mind,
though. Fortunately, the Java designers had the foresight not to include
features which make native compilation harder.

Calling Java an interpreted *language* is just ridculous.
Is C an interpreted language because some C interpreters exist?
You said yourself that the Java language didn't change when people started
inventing
JITs - so what about Java made it "interpreted"?

Cheers, Steve.
I guess you are right about that... Are there any native compilers for Java available? That would be cool!
For linux, there is the gcj compiler, I haven't looked at it in a while, but you can check it out at http://gcc.gnu.org/java/ I saw a speed comparison between the JVM and gcj, at the time gcj was a little slower than the interpreted bytecode, I dunno if it has improved much since then. -Jon
Jul 24 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Steven Shaw" <steven_shaw iprimus.com.au> wrote in message
news:ahltmr$2akd$1 digitaldaemon.com...
 You can call CreateWindowEx or whatever from Java. Just dot directly
 afaik. I think that Microsoft's Java implementation did allow you to do it
 more or less directly - via JDirect. That got them in trouble with Sun and
 hence we

It's not just a matter of getting the calling conventions right to interface with a C function. Many, many C functions take and return structs. For Java this requires writing a marshaller and unmarshaller for the arguments. Then there's the problem of C functions returning multiple values, again requiring some arbitrary translation piece to deal with that. Add to that the issues of groups of C functions sharing some "handle" type that must somehow be converted too/from a Java type, C functions returning pointers to things that must be released with a call to free(), and things simply not representable in Java, such as returning a pointer to a memory mapped file. None of these issues are any problem for D code to deal with.
Jul 24 2002
parent "Steven Shaw" <steven_shaw iprimus.com.au> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ahnkef$14d6$1 digitaldaemon.com...
 "Steven Shaw" <steven_shaw iprimus.com.au> wrote in message
 news:ahltmr$2akd$1 digitaldaemon.com...
 You can call CreateWindowEx or whatever from Java. Just dot directly
 afaik. I think that Microsoft's Java implementation did allow you to do
it
 more or less directly - via JDirect. That got them in trouble with Sun
and
 hence we

It's not just a matter of getting the calling conventions right to
interface
 with a C function. Many, many C functions take and return structs. For
Java
 this requires writing a marshaller and unmarshaller for the arguments.
Then
 there's the problem of C functions returning multiple values, again
 requiring some arbitrary translation piece to deal with that. Add to that
 the issues of groups of C functions sharing some "handle" type that must
 somehow be converted too/from a Java type, C functions returning pointers
to
 things that must be released with a call to free(), and things simply not
 representable in Java, such as returning a pointer to a memory mapped
file. Yep, I'm with you, Walter. This is what I think of as the data-sharing problem. Many languages provide a ffi but it's no good if you can just pass int, long, float, double and pointers. You need to be able to share data structures. I've seen a bit of nasty jni code! Please tell me more about C functions returning multiple values... oh I think you mean muliple "out" or "inout" parameters. ok. I came across this problem one. I thought that we could replace a proprietary scripting language, I'll call Fudge, with Java. There existed much C and C++ code that already used Fudge values (a C union). This is what makes it difficult. There is no way to natively access those same values from Java. Needless to say, the replacement was never attempted. The increase in speed from Java just-in-time compilation would likely have been thwarted by the glue (marshall/unmarshall). The alternative of replacing the Fudge values with primitive Java values wasn't fully explored as much of the existing code relied in implementation details of the Fudge values.
 None of these issues are any problem for D code to deal with.
Great. Regards, Steve.
Jul 26 2002