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