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 ;)

"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

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

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

For Microsoft Windows programmers, C# adequately addresses some of the Java
"negatives".
D seems quite similar to C#. C# doesn't have generics yet, but they are
planned also.
Java generics are scheduled for jdk 1.5 iirc.

--
Regards,
Steve.

Yes, both C# and Java don't need to be "interpreted language" but there 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 fast. On another note though I'll bet that CPU's will be designed with C# 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.
>
> For Microsoft Windows programmers, C# adequately addresses some of the
Java
> "negatives".
> D seems quite similar to C#. C# doesn't have generics yet, but they are
> planned also.
> Java generics are scheduled for jdk 1.5 iirc.
>
> --
> Regards,
> Steve.
>
>

Java was designed for interpretation. I think it was M$ would created the first JIT for Java.

MSIL/CIL (C#) was not designed for interpretation. The intermediate language 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...). Java isn't modular - or maybe it could be called class-based modularlity. C# is modular (at least it enable multiple classes per compilation unit) - C# 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.

2. D offers inline assembler if you need it. C# only offer inline IL (!) and 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 languages like Java, C#, Oberon 2, Modula-3. etc. That's a good thing. 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 compiler and tools. I don't think D will hold out against C# in a 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...
> Yes, both C# and Java don't need to be "interpreted language" but there 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 fast. On another note though I'll bet that CPU's will be designed with C#
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.
> >
> > For Microsoft Windows programmers, C# adequately addresses some of the
> Java
> > "negatives".
> > D seems quite similar to C#. C# doesn't have generics yet, but they are
> > planned also.
> > Java generics are scheduled for jdk 1.5 iirc.
> >
> > --
> > Regards,
> > Steve.
> >
> >
>
>

"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.
C#
> is modular (at least it enable multiple classes per compilation unit) - C# 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>.

> 2. D offers inline assembler if you need it. C# only offer inline IL (!)
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 languages like Java, C#, Oberon 2, Modula-3. etc. That's a good thing. Sometimes, though, you can just assume that designers of those language
got
> it right...

D's keel was laid down before I'd ever heard of C#. There are some similarities, but those are coincidences, and I think indicative of those features being very sensible <g>. C# missed important features like unit 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 compiler and tools. I don't think D will hold out against C# in a 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.

"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
> > languages like Java, C#, Oberon 2, Modula-3. etc. That's a good thing. Sometimes, though, you can just assume that designers of those language
> got
> > it right...
>
> D's keel was laid down before I'd ever heard of C#. There are some similarities, but those are coincidences, and I think indicative of those features being very sensible <g>. C# missed important features like unit 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.

C# is so similar to Java you really needn't have seen it to have some
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.

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

"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