My english really sucks.

"anderson" <anderson@firestar.com.au> wrote in message news:aojcob$26m8$1@digitaldaemon.com...
> D is more like Ada, no pascal, no C, no Eiffel, C#, no ....oh I forget the rest.  The point is who do I agree with?  You can't all be right? ;) Everyone seems to have a differnt view.
>
> All I was doing was providing some differnces, which in some cases you simply underlined, "good or bad".
>
> PS - And java did you know, I've also been told it can just as fast as C (and I believe both of you).  It all depends on what your doing and how
much
> you know.
>
> I'm going to make a stand right now!
>
> D's more like Godel (pronounced go da hell).
>
> * Past its due buy date.
> * A logic language.
> * Hated by all.
> * Not used by anyone.
> * Left to bleed when the grant money ran out.
> * unloved.
> * A pain to get running.
> (NOT)
>
> PS - this is not a flamer, I'm just having a bit of fun.
>

I think D is more simular to D.

That's all great stuff, and I've read them. The DbC stuff is inspired by Eiffel.

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:aohv4n$o7g$1@digitaldaemon.com...
> Eiffel is a 10-year-old language which seems to possess everything that D
hopes
> to implement:  design-by-contract, compiled C performance, clean syntax,
clean
> OO, templates, static typing, dynamic binding, multiple inheritance,
garbage
> collection, etc.  It's worth a hard look as a source of inspiration.
>
> Pay particular attention to concepts like Command-Query Separation, which connects to recent D threads about calling conventions ("Notice how the
[need
> for] comments ... disappeared").
>
> Also look at the granularity of class inheritance mechanism ("In C++, ...
[t]he
> decision is made at the granularity of the class - that is, entire classes
are
> merged or replicated...In the Eiffel model, the choice between merging and replication is made at the feature granularity").
>
> Finally the C++ critique cited below is well worth a read.  "The C++??
Critique
> is an analysis of some of the flaws of C++....The critique uses Java and
Eiffel
> as comparisons to C++ to give a more concrete feel to the criticisms,
viewing
> conceptual differences rather than syntactic ones as being more
important."
>
> Mark
>
>
> C++ comparisons to Eiffel http://www.elj.com/eiffel/cpp_report_980807.txt http://www.elj.com/eiffel/lj/eiffel-cpp-map/
>
> C++ critique
> http://www.elj.com/cppcv3/
>
> Advanced Introduction to Eiffel http://www.elj.com/eiffel/intro/
>
> Eiffel FAQ
> http://www.faqs.org/faqs/eiffel-faq/
>
> GNU Eiffel
> http://smarteiffel.loria.fr/index.html
>
>

"anderson" <anderson@firestar.com.au> wrote in message news:aojcob$26m8$1@digitaldaemon.com...
> D more simular to Ada, no pascal, no C, no Eiffel, C#, no ....oh I forget the rest.  The point is who do I agree with?  You can't all be right? ;) Everyone seems to have a differnt view.

D's a bit like Pascal (in the way it links/ modules) but I personally would like it if it were even more so.  I liked Pascal's sets and ranges.  Succ and Pred were handy with enums sometimes.  And the type specifiers read easier (left to right).

I think everyone on here brings something to the table to try to mould D into the language they'd like most to have in the world.  Why else are you here?  You have to be an idealist to use D much at this early stage.  I haven't had much time to lately.

> All I was don't was providing some differnces, which in some cases you simply underlined, "good or bad".
>
> PS - And java did you know I've also been told java can just as fast as C (and I believe both of you).  It all depends on what your doing and how
much
> you know.

I believe that too.  Just put a badass optimizing backend right at the pcode JIT level.  You can do as much optimizing up front as you have time for (incrementally even, as the first few times you want it slow anyway because you're debugging it, and the optimizer takes a whack at it each time it encounters the routine so if it's frequently used it'll be frequently optimized until the compiler has unrolled the entire inner loop of the program like 48x in a last ditch attempt to gain performance.  If the optimizer can't make any improvements it'd mark that down so it doesn't waste any more time working on that section.  For shipping code you say "do as much as you can to the p-code without actually running it and stop" then package it up and let the client's backend do the rest.  With effort being put into both fronts there's surely some progress to be made on one side or the other over time.  Just have to make something like that possible... Making it faster will happen by itself over time.

The whole program could just stay as a memory dump from the IDE/compiler until you decide to package it into source form to save to disk backup or when exiting, or save to a library or p-code executable.  Surely you'd have some kind of runtime compilation so you can have programs that write programs that actually do the work (the language'd have to be tolerant to this) and just build DLL's and EXE's (behind the scenes) that you can then execute.

You could include a mini runtime self-extracting JIT that would first check to see if a bigger (and costlier) runtime optimizer was available and would call into that if found on the host system.  Otherwise it would basically just do unoptimized translation.

> I'm going to make a stand right now!
>
> D's more like Godel (pronounced go da hell).
>
> * Past its due buy date.

?

> * A logic language.

Not in the sense that some other languages are.

> * Hated by all.

Hardly.

> * Not used by anyone.

Pavel does!!

> * Left to bleed when the grant money ran out.

I didn't hear this.

> * unloved.

Not at all.  I love D.  I just wish it were easier to convince the corporate
market to seriously consider alternative languages.
I think once the industry separates the frontend from the backend completely
(i.e. some kind of F.S.F. JVM or .NET, something that maybe grows off the
gcc backend) then it can become a lot more flexible for us to choose
different frontends.

> * A pain to get running.
> (NOT)

be nice!

> PS - this is not a flamer, I'm just having a bit of fun.

lol!


Sean

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:aolm1t$1hnt$1@digitaldaemon.com...
> "anderson" <anderson@firestar.com.au> wrote in message news:aojcob$26m8$1@digitaldaemon.com...
> > D more simular to Ada, no pascal, no C, no Eiffel, C#, no ....oh I
forget
> > the rest.  The point is who do I agree with?  You can't all be right? ;) Everyone seems to have a differnt view.
>
> D's a bit like Pascal (in the way it links/ modules) but I personally
would
> like it if it were even more so.  I liked Pascal's sets and ranges.  Succ and Pred were handy with enums sometimes.  And the type specifiers read easier (left to right).
>
> I think everyone on here brings something to the table to try to mould D into the language they'd like most to have in the world.  Why else are you here?  You have to be an idealist to use D much at this early stage.  I haven't had much time to lately.
>
> > All I was don't was providing some differnces, which in some cases you simply underlined, "good or bad".
> >
> > PS - And java did you know I've also been told java can just as fast as
C
> > (and I believe both of you).  It all depends on what your doing and how
> much
> > you know.
>
> I believe that too.  Just put a badass optimizing backend right at the
pcode
> JIT level.  You can do as much optimizing up front as you have time for (incrementally even, as the first few times you want it slow anyway
because
> you're debugging it, and the optimizer takes a whack at it each time it encounters the routine so if it's frequently used it'll be frequently optimized until the compiler has unrolled the entire inner loop of the program like 48x in a last ditch attempt to gain performance.  If the optimizer can't make any improvements it'd mark that down so it doesn't waste any more time working on that section.  For shipping code you say
"do
> as much as you can to the p-code without actually running it and stop"
then
> package it up and let the client's backend do the rest.  With effort being put into both fronts there's surely some progress to be made on one side
or
> the other over time.  Just have to make something like that possible... Making it faster will happen by itself over time.
>
> The whole program could just stay as a memory dump from the IDE/compiler until you decide to package it into source form to save to disk backup or when exiting, or save to a library or p-code executable.  Surely you'd
have
> some kind of runtime compilation so you can have programs that write programs that actually do the work (the language'd have to be tolerant to this) and just build DLL's and EXE's (behind the scenes) that you can then execute.
>
> You could include a mini runtime self-extracting JIT that would first
check
> to see if a bigger (and costlier) runtime optimizer was available and
would
> call into that if found on the host system.  Otherwise it would basically just do unoptimized translation.
>
> > I'm going to make a stand right now!
> >
> > D's more like Godel (pronounced go da hell).
> >
> > * Past its due buy date.
>
> ?
>
> > * A logic language.
>
> Not in the sense that some other languages are.
>
> > * Hated by all.
>
> Hardly.
>
> > * Not used by anyone.
>
> Pavel does!!
>
> > * Left to bleed when the grant money ran out.
>
> I didn't hear this.
>
> > * unloved.
>
> Not at all.  I love D.  I just wish it were easier to convince the
corporate
> market to seriously consider alternative languages.
> I think once the industry separates the frontend from the backend
completely
> (i.e. some kind of F.S.F. JVM or .NET, something that maybe grows off the gcc backend) then it can become a lot more flexible for us to choose different frontends.
>
> > * A pain to get running.
> > (NOT)

The not was ment to negate the other things said about godel/D (sarcasm).
I'm unsure if you picked that up.  I'm surprised Pavel uses Godel (I know
what you really meant).

> be nice!
>
> > PS - this is not a flamer, I'm just having a bit of fun.
>
> lol!
>
>
> Sean
>
>

<someanon@yahoo.com> wrote in message news:aoid99$16ko$1@digitaldaemon.com...
> >Anyway good comments.  You should look deeper into D and see if there's anything good in Eiffel you would like in D.
>
> Object persistence (or serialization): you can deep_copy/deep_clone an
entire
> inter-linked structure by just specify the root object; then you can save
and
> retrieve that whole structure either to a disk file or over a network connection.
>
> There has been some discussion on this topic before.  Walter, is there any
plan
> to implement it?

Eventually, but not in the near future. Too many other issues at the moment.

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:aoj3t0$1tki$1@digitaldaemon.com...
> > I do think that Walter would have well researched similar languages to D making sure that he wasn't repeating something that has already been
done.
> > I'm sure he would have looked into a language as popular as Eiffel.
> I hope so but it's never too late. I haven't heard Eiffel mentioned once
in
> connection with D.  As far as I know, my post was the first mention.

It's referenced in the DBC stuff. The trouble with Eiffel (for me, anyway) is its syntax. What can I say, I just don't like it.

> I'd like D to be bolder about dropping C-isms and C-ish syntax.  I'd like
D to
> have a solid foundation of nice, clean, orthogonal software engineering
concepts
> instead of the mishmash heritage of C++.
> The C++?? paper shows the problems of C++, and Eiffel shows how to do
things
> right.  Between these two sources of inspiration I think D can strike a
nice
> balance in its target domain.

I think D already does that, though obviously you think it doesn't go far enough.

Walter says...
>
>That's all great stuff, and I've read them. The DbC stuff is inspired by Eiffel.
>

But how do you as author see the two languages differing from each other -- in philosophy or technical capabilities?  Put another way, why use D instead of Eiffel?

You don't need comparisons with every language on earth, just those that served as inspiration, and bear a resemblance to D.  C++ and Eiffel are D's next of kin.

These comparisons belong in the D write-ups.  Reading the D web pages leaves the impression that C++ was the only source of inspiration and the only similar language.

Mark

Walter wrote:
>> Between these two sources of inspiration I think D can strike a nice balance in its target domain.
> I think D already does that, though obviously you think it doesn't go far enough.

What I think is that C/C++ has too much influence on the design relative to other languages.  The world has seen many efforts to fix C/C++ (IMP, C99, C#, Java, ...), and D looks like just one more.  (What Eiffel inspiration D has is very, very subdued.)

D sacrifices compatibility with C++, but so do C# and Java.  My point is that D should not be (C++)++.  It should fully recognize C++ as a cracked old building meriting demolition more than repair.  I'd like the D web pages to discuss how D addresses the specific technical critiques in the "C++??" paper.  I'd like D to escape from the C/C++ badlands by accepting more input from beautiful languages like Icon and Eiffel, and less from C++.  That is what I meant by "balance."

Walter wrote:
> The trouble with Eiffel (for me, anyway)
> is its syntax. What can I say, I just don't like it.

Remarkable!  We've all been doing too much C/C++ to see clearly the syntactical flaws of C.  C/C++ syntax is notoriously cryptic, yet the D project is so overly committed to C that even something as harmless as the use of good names for basic data types is thought impossible.

Eiffel has specific features to support documentation-in-code ("short" form and DbC).  It may not be ideal syntax, but almost *any* language has vastly better syntax than C, which is the main supplier of D syntax at this point.  C is the ugly dog in any syntax beauty contest. <g>

Hey thank you for this forum Walter, and no offense intended.  We still love you!

Mark

Mark Evans wrote:
> ...
> Walter wrote:
> > The trouble with Eiffel (for me, anyway)
> > is its syntax. What can I say, I just don't like it.
> 
> Remarkable!  We've all been doing too much C/C++ to see clearly the syntactical
> flaws of C.  C/C++ syntax is notoriously cryptic, yet the D project is so overly
> committed to C that even something as harmless as the use of good names for
> basic data types is thought impossible.
> ...

Imagine C is like some corrosive gas that has permeated just about every crevice of our programming world.  Programmers breathe this gas on a daily basis, and find that they are very productive while breathing it, despite its corrosive nature.

Everyone complains about the detrimental effects of this gas, yet it keeps getting used and it does its job well.  Some have tried switching to other gasses, and while far less corrosive, these gasses are harder to breathe for those brought up breathing the "C" gas.

Only a relatively small number are able to switch to any of these new gasses.

Some of the new gasses are like Helium, and those who breathe it acquire high, shrill voices that annoy everyone else.  Then they pass out. Other new gasses are like Nitrous Oxide, and those who breathe it laugh at the rest of us, but get nothing useful done.

Rather than be totally different, some gasses are modifications of the "C" gas, but they became even more corrosive than the "C" gas ever was!

What is the corrosive "C" gas?  I'm thinking it is like Oxygen, able to turn iron to rust, yet also able to power Life.  C++ is like Ozone: We need it too, but it is more corrosive than Oxygen, and it also seems to have some large holes in it.

We may never be able to get rid of our need for Oxygen, but it is clear that something better is needed, and it is equally clear that the new gas should be close to Oxygen, but not emulate the hazards of Ozone.

D is not trying to be the ultimate thing:  It is merely trying to be a step in the right direction, where the direction of choice is toward ease of learning (especially for C programmers), power of use, speed of execution and simple compilation.

I can't think of a specific "gas" to compare to D.  But even at this early stage, I know it is easier to breathe than C/C++ in most, but not all, situations.

What I'm looking for, and what Walter is creating, is a powerful change for the better, not something too different or alien.  Maximum gain for minimum pain.

Once D is decades old, we may be ready to move on to something else, something that leaves C/C++ further behind.  But not quite yet.


-BobC

Most of our atmosphere is Nitrogen gas.  N2  But doesn't sound like an appropriate gas to represent D.


Sean

"Robert W. Cunningham" <FlyPG@users.sourceforge.net> wrote in message news:3DB1AB57.C9E17628@users.sourceforge.net...
> Mark Evans wrote:
> > ...
> > Walter wrote:
> > > The trouble with Eiffel (for me, anyway)
> > > is its syntax. What can I say, I just don't like it.
> >
> > Remarkable!  We've all been doing too much C/C++ to see clearly the
syntactical
> > flaws of C.  C/C++ syntax is notoriously cryptic, yet the D project is
so overly
> > committed to C that even something as harmless as the use of good names
for
> > basic data types is thought impossible.
> > ...
>
> Imagine C is like some corrosive gas that has permeated just about every crevice of our programming world.  Programmers breathe this gas on a daily basis, and find that they are very productive while breathing it, despite its corrosive nature.
>
> Everyone complains about the detrimental effects of this gas, yet it keeps getting used and it does its job well.  Some have tried switching to other gasses, and while far less corrosive, these gasses are harder to breathe for those brought up breathing the "C" gas.
>
> Only a relatively small number are able to switch to any of these new gasses.
>
> Some of the new gasses are like Helium, and those who breathe it acquire high, shrill voices that annoy everyone else.  Then they pass out. Other new gasses are like Nitrous Oxide, and those who breathe it laugh at the rest of us, but get nothing useful done.
>
> Rather than be totally different, some gasses are modifications of the "C" gas, but they became even more corrosive than the "C" gas ever was!
>
> What is the corrosive "C" gas?  I'm thinking it is like Oxygen, able to turn iron to rust, yet also able to power Life.  C++ is like Ozone: We need it too, but it is more corrosive than Oxygen, and it also seems to have some large holes in it.
>
> We may never be able to get rid of our need for Oxygen, but it is clear that something better is needed, and it is equally clear that the new gas should be close to Oxygen, but not emulate the hazards of Ozone.
>
> D is not trying to be the ultimate thing:  It is merely trying to be a step in the right direction, where the direction of choice is toward ease of learning (especially for C programmers), power of use, speed of execution and simple compilation.
>
> I can't think of a specific "gas" to compare to D.  But even at this early stage, I know it is easier to breathe than C/C++ in most, but not all, situations.
>
> What I'm looking for, and what Walter is creating, is a powerful change for the better, not something too different or alien.  Maximum gain for minimum pain.
>
> Once D is decades old, we may be ready to move on to something else, something that leaves C/C++ further behind.  But not quite yet.
>
>
> -BobC