www.digitalmars.com         C & C++   DMDScript  

D - Eiffel and C++ Critique

reply Mark Evans <Mark_member pathlink.com> writes:
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
Oct 15 2002
next sibling parent reply "anderson" <anderson firestar.com.au> writes:
"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.


multiple inheritance? I didn't know that was planned for D.

"... Although D and Java share the notion that garbage collection is good
and multiple inheritance is bad ..."

Anyway a comparison between D and Eiffel would be interesting.

Eiffel has a different form of virtual methods then D.
Eiffel is "pure OO" (D is a hybrid with standard datatypes).
D doesn't have multi inheritance (and I don't think it's planned. Walter?).
D has type casting.
D is C/C++ based (Eiffel is not).

I wouldn't be supprised if D outperforms Eiffel (because it is not pure OO
and because Walter programmed it ;) ).

Good or bad these are substantial differences, I think.

Eiffel does have some nice things, that may be useful in D.  The ability to
remove or rename methods (however, I can also see disadvantages to this such
as code learnability and reusability).

I do think that Walter would have well reserached simular 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.

Anyway good comments.  You should look deeper into D and see if there's
anything good in Eiffel you would like in D.
Oct 16 2002
next sibling parent reply someanon yahoo.com writes:
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?
Oct 15 2002
next sibling parent "anderson" <anderson firestar.com.au> writes:
Yes I remember that. And I want , I want it, please?

<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?
Oct 16 2002
prev sibling next sibling parent Burton Radons <loth users.sourceforge.net> writes:
someanon yahoo.com wrote:

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?


Pickling is implemented in DLI, in a robust manner.  Walter's previously 
expressed sentiment is that he wants introspection to be 
purpose-oriented (to serve tasks as they come up, rather than just 
throwing things in).  Look up the TypeInfo thread.

The problem with language picklers I've found has been a presumption 
that it can possibly do everything.  The things need to be transparent 
and user-controllable with a clean break between the high-level 
interface and the low-level nuts and bolts.

Once I get back to DLI it'll be one of the things to revisit.  I'll look 
into Eiffel's method.
Oct 15 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
<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.
Oct 18 2002
prev sibling parent reply Mark Evans <Mark_member pathlink.com> writes:
Eiffel and D share practically identical objectives.  They do not have
"substantial differences" at the conceptual level.

The major differences are that (1) D wants to be closer to the hardware and (2)
D wants to look and feel like C++.  Goal (1) is reasonable -- though it has ill
effects on high-level goals.  Goal (2) is a mistake, because C++ is flawed at
all levels.

Unattributed quotations below are from "C++?? A Critique of C++" by Ian Joyner.
Everyone should sit down for an hour and read the PDF.  It would elevate the
level of thought and discussion about D.  The PDF is at
http://www.elj.com/cppcv3/

If the D project succeeds, then it might end up looking like "Eiffel with
pointers."  It probably should.  D will offer more capability at the low level
but more awkwardness/ugliness at the high level.



 
 Eiffel has a different form of virtual methods then D.


Not really.  The goals are practically identical.  Default virtual applies as in
D.  Eiffel uses the dot notation like D.  Private is gone (and good riddance).
D has static constructors and Eiffel has "once."  The C++ critique covers this
topic in great detail.  "Virtual is an example of where C++ obscures the
concepts of OOP."  "In Eiffel ... global analysis of the entire system is done
to determine the truly polymorphic calls and accordingly construct the virtual
tables."




 Eiffel is "pure OO" (D is a hybrid with standard datatypes).


I might quibble with both characterizations but that can pass.  It's instructive
that Python recently unified its type/class distinction.  (Python types now act
like classes.)  In C++, there is little difference between structs and classes
(structs are public classes).

There is a more fundamental problem with the C++ type system.  "C++ is
statically typed, but there are many mechanisms that allow the programmer to
render it effectively untyped [e.g. type casting, void pointers], which means
errors are not detected until a serious failure....Undermining the type system
is not needed [in a well-designed language], as the type system is where the
flexibility should be, not in the ability to undermine the type system."  That
statement addresses the negative connotations carried by the "pure OO" epithet.

Take a look at how Eiffel handles the "gettor/settor" problem recently discussed
on the list.  It's in the Critique too.




 D doesn't have multi inheritance (and I don't think it's planned. Walter?).


Then Eiffel wins on that score.  Eiffel even implements a name resolution
technique that was advocated by Stroustroup for C++, but nixed in committee.

"Both Eiffel and C++ provide multiple inheritance. Java does not, claiming it
results in many problems. Instead Java provides interfaces [like D?], which are
similar to Objective C’s protocols. Sun claims [that] interfaces provide all the
desirable features of multiple inheritance....Eiffel has taken the approach that
multiple inheritance poses some interesting and challenging problems, but rises
to the challenge, and solves them elegantly. Nor does the order of inheritance
matter. All resolutions that the programmer must specify are given in the
inheritance clause of a class. This includes renaming to ensure that multiple
features inherited with the same name end up as multiple features with
unambiguous names, redefining, new export policies for inherited features,
undefining, and disambiguating with select. In all cases, the action taken by
the compiler, whether using fork or join semantics is made clear, and the
programmer has complete control."



 D has type casting.


See comments under pure-OO.  By the way, Stroustroup would like to get rid of
type casting in C++.



 D is C/C++ based (Eiffel is not).


C/C++ is a flawed foundation and D is trying to fill in the cracks instead of
laying a new one (Walter can correct the metaphor if I'm wrong on that).  I view
D as an opportunity to break with C++ tradition and do things right.  The basis
of D, or any language, should be software engineering concepts.



 I wouldn't be surprised if D outperforms Eiffel (because it is not pure OO
 and because Walter programmed it ;) ).


Very wrong.  Eiffel is a screamer.  From the Eiffel FAQ:

"How fast do Eiffel applications run? Eiffel is a statically typed
object-oriented language using automatic memory management.  Many Eiffel
compilers make use of the static typing and perform extensive global
optimisations producing performance comparable with other well-optimised
statically typed languages like C++."

Many Eiffel compilers produce C code as their output, so performance is as good
as C and just as portable.



 Good or bad these are substantial differences, I think.


The languages have more similarities than differences.  They are chasing after
identical software engineering goals in any case (two exceptions were noted
above).



 Eiffel does have some nice things, that may be useful in D.  The ability to
 remove or rename methods (however, I can also see disadvantages to this such
 as code learnability and reusability).


Don't follow you. Eiffel is the king of learnability, readability, and
reusability.



 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.



 Anyway good comments.


Thanks.



 You should look deeper into D and see if there's
 anything good in Eiffel you would like in D.


It's not a matter of cherry-picking features and putting them in a blender.  We
are talking about high-level language design.

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.                    

Mark
Oct 16 2002
next sibling parent reply "anderson" <anderson firestar.com.au> writes:

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 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'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.
Oct 17 2002
next sibling parent "anderson" <anderson firestar.com.au> writes:
My english really sucks.

"anderson" <anderson firestar.com.au> wrote in message
news:aojcob$26m8$1 digitaldaemon.com...


 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.
Oct 17 2002
prev sibling next sibling parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:aojcob$26m8$1 digitaldaemon.com...


 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
Oct 16 2002
parent "anderson" <anderson firestar.com.au> writes:
"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...






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
Oct 18 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:aojcob$26m8$1 digitaldaemon.com...

 D's more like Godel (pronounced go da hell).
 * Left to bleed when the grant money ran out.


There never was any grant money for D to begin with <g>.
Oct 21 2002
parent "anderson" <anderson firestar.com.au> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ap1idi$1o0t$2 digitaldaemon.com...

 "anderson" <anderson firestar.com.au> wrote in message
 news:aojcob$26m8$1 digitaldaemon.com...

 D's more like Godel (pronounced go da hell).
 * Left to bleed when the grant money ran out.


 There never was any grant money for D to begin with <g>.


Exactly, I didn't think you were it it for the money (like the inventors of
godel were).   They simply followed the money and when the money ran out for
godel they simply started a new language on more grant money (hopping that
godel would take off).
In "barzzaro world" D would probably be called godel.
Oct 22 2002
prev sibling next sibling parent reply Mac Reiter <Mac_member pathlink.com> writes:
 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.


Walter has definitely looked into Eiffel.  Design By Contract was "invented" by
Bertrand Meyer, the inventor of Eiffel.  Walter liked Design By Contract enough
to put it into his C++ compiler, and has included it as a major feature of D.

I brought up Eiffel's "Constrained Genericity" features a couple of times during
earlier discussions of how templates should be done in D.  During those
conversations, I seem to remember that Walter liked the capabilities of Eiffel,
but not the syntax, and possibly not some of the heavy-handedness.

My personal experience is that Eiffel looks really good in the books (and I own
several, as well as my own copy of EiffelStudio 5.1 from ISE), but is somewhat
painful in practice.  It is entirely possible, and even probable, that the pain
I have experienced is caused more by the substantial shift of paradigm and by
poorly designed (at least IMHO) standard libraries.  I have found the ISE
product (EiffelStudio) to have fairly buggy libraries, which tends to deaden my
enthusiasm for all of the claims of good software engineering and so forth.
Logically, I realize that there is a considerable difference between how good
the tool can be and how well it is used, but it is depressing when the creators
of the tool fail to use it properly.  It is especially depressing when you
consider that EiffelStudio generally goes for over $2000 (my copy was $500 as a
special introductory deal 'coz I took a training seminar, but still quite a bit
for a development system that sits in an envelope in a drawer at my house and is
never used).  I do not have tremendous experience with the GNU SmallEiffel
effort, though I have repeatedly downloaded the elj-win32 package, installed it,
and played around with it.  I probably need to spend some more concerted time
with it at some point.

I have also discovered that the STL tends to be more capable than the EiffelBase
libraries, although the EiffelBase is probably broader and easier for basic
usage.  I am unfamiliar with Gobo or any of the other "standard" libaries for
Eiffel.

I definitely think that Eiffel is a good language to examine for ideas.  I think
that anyone planning on constructing an object oriented language should set
aside a year or so and do a serious and in-depth read of "Object Oriented
Software Construction, 2nd Edition", also written by Bertrand Meyer.  Such a
reading will provide a tremendous insight both into some of the weirder problems
that OO faces, and various solutions that have been proposed.  I like several
Eiffel features.  I personally find the syntax mildly painful to read, but that
is probably the whole paradigm issue again -- I also find most languages mildly
painful to read until I've worked with them for awhile.  I think D could use
some of the Eiffel functionality, though I would be perfectly happy if a more
C-ish syntax was proposed.

I would like to point out, however, that Walter does have a more pragmatic
approach than Bertrand.  During the seminar, I engaged Bertrand in a discussion
of deterministic object finalization, and no matter how I phrased it or
attempted to tackle it, he could never see any need for such a capability.  As
such, Eiffel will probably never have deterministic object finalization (DOF),
which makes it almost useless for certain categories of application.  Walter
understood this need and worked with us to provide at least some level of DOF
support (I'd still prefer an option to reference count, but I'll take what I can
get, since it's much more than I could get from Bertrand).

Sorry, I'm not sure if that post really had any particular direction.  Just
wanted to throw in another set of perspectives (and toss out some keywords for
people who might be interested in looking at Eiffel ;-).  If I could summarize,
I guess it would be that I would like D to take the good features of Eiffel,
fill in the missing features (DOF, a few others that escape me at the moment),
and make a more comfortable syntax for it all...

Mac
Oct 16 2002
next sibling parent reply Mac Reiter <Mac_member pathlink.com> writes:
Oh, and while we're discussing things that Eiffel has and D doesn't ;-)

I *really* like "agents", otherwise known as "anonymous functions", "lambda
functions", or "lambda expressions".  These are especially useful once your
language has generic algorithms that can iterate over some form of a collection
and do something (the Visitor pattern, if I remember correctly).  It is nice to
be able to specify what you would like done at each point directly inline,
rather than having to go somewhere else and write up a tiny little function and
then pass that function to the generic algorithm.

This capability is so useful that the BOOST library has even figured out a way
to do it from within C++, which is so painful to contemplate that I don't even
want to start.  The interface is fairly nice, with a few kludges because of
limitations of C++.

Eiffel sets off agents with a special keyword ("agent", not surprisingly).  The
agent mechanism is not discussed in OOSC2 (Object Oriented Software
Construction, 2nd Ed), so you'll have to retrieve some of the newer
documentation for the Eiffel language to see how it works.  GNU SmallEiffel now
has agent support, so they should have some documentation, or at least links to
good documentation.  

D could have a similar capability.  I think someone even suggested it during the
for_each discussion, possibly with the "anon" keyword to set off the function
body.

As a more concrete example, instead of:

void increment(long x)
{
x++;
}

void do_something(void)
{
// lots of code here

for_each(x, set_of_xs, increment);

// lots more code here
}


you can do:

void do_something(void)
{
// lots of code here

for_each(x, set_of_xs, anon(long x){x++;});

// lots more code here
}


without needing to write the trivial and mostly pointless increment() function
and worry about if you are going to have a namespace collision with someone else
who needed to do a similar task.

Of course, this can be abused.  anon(){} should only be used for very small
functions -- putting a large function in such a place would make the code
unreadable, and should use the standard "write a function and use the name here"
method.  But for small behaviors that are not encapsulated in standard functions
(which is STL's answer -- supply common functions for increment, decrement,
etc), this capability is very nice.  It can actually make the generic algorithms
worth using.  Without it, the amount of extra effort needed means that it would
be easier to rewrite the generic algorithm than to use it.

Mac
Oct 16 2002
next sibling parent Burton Radons <loth users.sourceforge.net> writes:
Mac Reiter wrote:

 Oh, and while we're discussing things that Eiffel has and D doesn't ;-)
 
 I *really* like "agents", otherwise known as "anonymous functions", "lambda
 functions", or "lambda expressions".  These are especially useful once your
 language has generic algorithms that can iterate over some form of a collection
 and do something (the Visitor pattern, if I remember correctly).  It is nice to
 be able to specify what you would like done at each point directly inline,
 rather than having to go somewhere else and write up a tiny little function and
 then pass that function to the generic algorithm.


I doish tooish.  Lambda in Python is generally next-to-useless in my 
experience, but any nested functions are very useful.  The problem is 
that doing it with only the function pointer is a rather hackish process 
called trampolines; basically on-stack function call building.  It's so 
limited, I tell you what.

We already have the engineering solution with delegates.  The "this" 
pointer can be a pointer to the stack frame which the nested function 
uses.  This would have slightly loosened restrictions over trampolining, 
and will definitely be a lot simpler.

I also want frozen-scope nested functions, which is what I generally use 
Python's nested functions for.  That would involve allocating a struct 
and filling it with the locals the nested function uses when the 
function pointer is retrieved.  It'll be easier to present as a matter 
of contrast once normal nested functions are implemented.
Oct 16 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Mac Reiter" <Mac_member pathlink.com> wrote in message
news:aoko6l$k3m$1 digitaldaemon.com...

 Of course, this can be abused.  anon(){} should only be used for very


small

 functions -- putting a large function in such a place would make the code
 unreadable, and should use the standard "write a function and use the name


here"

 method.


One way to keep them simple is to only allow expressions, not statements, in
the anonymous function. Any thoughts on this?
Oct 21 2002
next sibling parent reply Mac Reiter <Mac_member pathlink.com> writes:
In article <ap1j97$1or0$1 digitaldaemon.com>, Walter says...

"Mac Reiter" <Mac_member pathlink.com> wrote in message
news:aoko6l$k3m$1 digitaldaemon.com...

 Of course, this can be abused.  anon(){} should only be used for very


small

 functions -- putting a large function in such a place would make the code
 unreadable, and should use the standard "write a function and use the name


here"

 method.


One way to keep them simple is to only allow expressions, not statements, in
the anonymous function. Any thoughts on this?


Hmmm.  I think that my "this can be abused" comment was more of a style
guideline kind of a thing.  I would prefer to allow anything that is valid in a
function to be valid in an anonymous function.  Sometimes you need little loops
or switches or other non-expression constructs, and can still fit them cleanly
into place.  I suspect that the line between "nicely expressive" and "hideously
contorted" is a matter of taste and highly context sensitive.  I think "proper"
use of anon funcs will just require programmer experience -- newer programmers
can either stay away from them until they have seen enough examples to learn a
"good" balance, or can dive in and risk the wrath of fellow programmers (which
is how most of us learn company style guidelines anyway).  I would expect that
any attempt by the compiler or language to limit the capability of anon funcs
would turn into a source of frustration (admittedly, one that could be worked
around by making a real function, but still somewhat annoying).

Anything that is expressive enough to be useful can be abused.  Programmers
should be taught not to misuse and abuse features.  One of my coworkers is
having to maintain some old C code that the authors must have developed during
the "gee, look how few lines of code it takes to do this" developmental stage.
We've all seen the strcpy() implementation that looks like:

for (pSrc = Src, pDst = Dst; pSrc; *pDst++ = *pSrc++) {}

And that's fine, I suppose.  Since we've all seen it, we all recognize it and it
isn't a problem.  But sometimes new programmers see things like that and the
trinary operator ( ?: , which is perfectly useful when used responsibly) and
wander off to create truly horrendous code segments, most of which would be
serious competitors in the code obfuscation contests.

The expressiveness is not to blame, nor is the trinary operator, nor any other
feature of the language.  They've just been used by an inexperienced programmer
who, for some reason, thought that the shorter source code would translate into
shorter/faster program executable code.

Mac
Oct 21 2002
parent "Walter" <walter digitalmars.com> writes:
"Mac Reiter" <Mac_member pathlink.com> wrote in message
news:ap1kvb$1qh3$1 digitaldaemon.com...

 Hmmm.  I think that my "this can be abused" comment was more of a style
 guideline kind of a thing.  I would prefer to allow anything that is valid


in a

 function to be valid in an anonymous function.  Sometimes you need little


loops

 or switches or other non-expression constructs, and can still fit them


cleanly

 into place.  I suspect that the line between "nicely expressive" and


"hideously

 contorted" is a matter of taste and highly context sensitive.  I think


"proper"

 use of anon funcs will just require programmer experience -- newer


programmers

 can either stay away from them until they have seen enough examples to


learn a

 "good" balance, or can dive in and risk the wrath of fellow programmers


(which

 is how most of us learn company style guidelines anyway).  I would expect


that

 any attempt by the compiler or language to limit the capability of anon


funcs

 would turn into a source of frustration (admittedly, one that could be


worked

 around by making a real function, but still somewhat annoying).


I think you're right. It would probably produce the same frustration as the
base initializer syntax does in C++.
Oct 21 2002
prev sibling parent Patrick Down <pat codemoon.com> writes:
"Walter" <walter digitalmars.com> wrote in
news:ap1j97$1or0$1 digitaldaemon.com: 

 One way to keep them simple is to only allow expressions, not
 statements, in the anonymous function. Any thoughts on this?
 


I agree with Mac Reiter.  I don't think that expressions are
enough.  I think it's just best to leave it up to time and
usage to see what is a good convention here.  I will also
say that I don't think that anonymous functions of 5 or 6
lines are even bad.  I think it's much more readable to
have the code in place than to have to search for the named
function.
Oct 21 2002
prev sibling parent reply Mark Evans <Mark_member pathlink.com> writes:
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

Java, ...), and D looks like just one more.  (What Eiffel inspiration D has is
very, very subdued.)


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
Oct 18 2002
next sibling parent reply "Robert W. Cunningham" <FlyPG users.sourceforge.net> writes:
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
Oct 19 2002
next sibling parent "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
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
Oct 19 2002
prev sibling next sibling parent "chris jones" <flak clara.co.uk> writes:
I enjoyed reading that :)

chris

"Robert W. Cunningham" <FlyPG users.sourceforge.net> wrote in message
news:3DB1AB57.C9E17628 users.sourceforge.net...

 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
Oct 19 2002
prev sibling next sibling parent "anderson" <anderson firestar.com.au> writes:
Parhaps this is good enough, for the D journal option page?

"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
Oct 19 2002
prev sibling parent reply Mark Evans <Mark_member pathlink.com> writes:
If I were to draw a gas analogy it would be a dying old man on an oxygen tank.
C/C++ is the dying old man and D is the oxygen tank.  It would be better to get
rid of the smog and cigarettes in the first place, so that people don't grow old
prematurely.  Clean language design is like a storm front that blows all the bad
stuff away.

All competent software engineers know a variety of languages and are able to
learn new ones quickly.  Those viewing C++ as some kind of comfort zone just
haven't spent enough time in other languages to understand the dramatic gains
that are available from superior syntax and expressiveness.

Mark
Oct 20 2002
next sibling parent reply "chris jones" <flak clara.co.uk> writes:
Roberts analogy was a great deal fairer. By your analogy D isnt even part of
the solution.

I dont even think you want is what D is suposed to be. From the 'Overview' D
is clearly meant to be a pragmatic language, you always seem to be putting
the idealistic argument.

chris

"Mark Evans" <Mark_member pathlink.com> wrote in message
news:aovdpb$2fr5$1 digitaldaemon.com...

 If I were to draw a gas analogy it would be a dying old man on an oxygen


tank.

 C/C++ is the dying old man and D is the oxygen tank.  It would be better


to get

 rid of the smog and cigarettes in the first place, so that people don't


grow old

 prematurely.  Clean language design is like a storm front that blows all


the bad

 stuff away.

 All competent software engineers know a variety of languages and are able


to

 learn new ones quickly.  Those viewing C++ as some kind of comfort zone


just

 haven't spent enough time in other languages to understand the dramatic


gains

 that are available from superior syntax and expressiveness.

 Mark
Oct 20 2002
next sibling parent "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
I believe there is room for both pragmatism and idealism in a language.
There's nothing that says a language can't be both high, medium, and low
level.

I think the ideal language wouldn't need a scripting "high end" or a fast
"low end" such as C.  Asm you can't escape from but is inherently platform
specific so a builtin assembler and language support for detecting target
and using the right assembly function is needed.

I tend to throw ideas out without thinking them through enough, so I guess I
tend to clutter the language.  Not that my ideas are all that novel.

I should probably lurk more.

Sean

"chris jones" <flak clara.co.uk> wrote in message
news:aovmbm$2nm1$1 digitaldaemon.com...

 Roberts analogy was a great deal fairer. By your analogy D isnt even part


of

 the solution.

 I dont even think you want is what D is suposed to be. From the 'Overview'


D

 is clearly meant to be a pragmatic language, you always seem to be putting
 the idealistic argument.

 chris
Oct 20 2002
prev sibling parent reply Mark Evans <Mark_member pathlink.com> writes:
I dont even think you want is what D is suposed to be. From the 'Overview' D
is clearly meant to be a pragmatic language, you always seem to be putting
the idealistic argument.

chris



I want D to take the practical steps of learning from the mistakes of
predecessor languages, while using design principles systematically -- instead
of suffering through ad-hoc design techniques such as produced C.  And D's hope
to fix C++ is severely hindered by its over-commitment to C++ syntax and
semantics.  So I want it to loosen up.  These points are very pragmatic ones.

A good exercise would be to walk through the "C++??" critique and ask how D
solves each problem.  Those it does not solve belong on our to-do list.

At the same time, Walter says Eiffel was an inspiration, yet also admits having
too little knowledge of Eiffel to draw a comparison with D.  That strikes me as
a pretty weak inspiration.  So I see a lot of fertile ground we can explore in
the Eiffel language.

For us to suppose that we can dream up better ideas than expert C++ critics or
language authors like Eiffel's is a bit impractical!  I suggest standing on
their shoulders to get a better view of things.  That's entirely practical and
very smart.  With that vantage we can come up with *really* good ideas.  Without
it, we will be lucky just to duplicate their insights (and don't stand a very
good chance of even that much).

I think that D can be a successor to C++ without having to look a whole lot like
it.  This is where I differ with Walter.  He is courageously willing to break
C++ compatibility, but then turns yellow in thinking that C++-ness is required
to attract users.  I believe the only way D can displace C++ (let alone Java,

demanding such hard C++-ness we are shooting ourselves in the foot.

Mark
Oct 30 2002
parent reply "chris jones" <flak clara.co.uk> writes:
Hi Mark, have you been on Holiday? Havnt seen any posts from you lately.


"Mark Evans" <Mark_member pathlink.com> wrote in message
news:apqakn$2pio$1 digitaldaemon.com...

I dont even think you want is what D is suposed to be. From the




'Overview' D

is clearly meant to be a pragmatic language, you always seem to be




putting

the idealistic argument.

chris



 I want D to take the practical steps of learning from the mistakes of
 predecessor languages, while using design principles systematically --


instead

 of suffering through ad-hoc design techniques such as produced C.  And D's


hope

 to fix C++ is severely hindered by its over-commitment to C++ syntax and
 semantics.  So I want it to loosen up.  These points are very pragmatic


ones.

Ok mabey some truth, but 'severly hindered' is way over the top.


 A good exercise would be to walk through the "C++??" critique and ask how


D

 solves each problem.  Those it does not solve belong on our to-do list.


Asuming you agree with all the critisims. And solving all those problems
bring practical benefits.

Cant you do it? Its the second time you have sugested somting like this.


 At the same time, Walter says Eiffel was an inspiration, yet also admits


having

 too little knowledge of Eiffel to draw a comparison with D.  That strikes


me as

 a pretty weak inspiration.  So I see a lot of fertile ground we can


explore in

 the Eiffel language.


I think you are being unfair. I suspect he meant sombody who had experience
using it would do a better comparison, or he just picked the bones for
ideas? And You cant expect him to be an expert on Eiffel and every other
language on the planet and write a compiler and asnwer questions in this
newsgroup and feed his 17 children. I am feeling tired just thinking about
it.


 For us to suppose that we can dream up better ideas than expert C++


critics or

 language authors like Eiffel's is a bit impractical!  I suggest standing


on

 their shoulders to get a better view of things.  That's entirely practical


and

 very smart.  With that vantage we can come up with *really* good ideas.


Without

 it, we will be lucky just to duplicate their insights (and don't stand a


very

 good chance of even that much).


I think Walters is doing great. The diversity of input from this newsgroup
and Walters willingness to engage discusion is going to do far better than
any other method i can think of.

As walter says it is a language for programers not academics. Thats why he
has this newsgroup full of programers!


 I think that D can be a successor to C++ without having to look a whole


lot like

 it.  This is where I differ with Walter.  He is courageously willing to


break

 C++ compatibility, but then turns yellow in thinking that C++-ness is


required

 to attract users.  I believe the only way D can displace C++ (let alone


Java,




By

 demanding such hard C++-ness we are shooting ourselves in the foot.


Given the right airplay and backing i think D will easily take over from
C++. simply because the transition from C++ will be fairly painless and it

painless aswell.

chris
Oct 31 2002
parent reply Mark Evans <Mark_member pathlink.com> writes:
 A good exercise would be to walk through the "C++??" critique


Asuming you agree with all the critisims. And solving all those problems
bring practical benefits.


Everyone knows C++ has problems or there would be no D effort in the first place

which you disagree.  You seem to love the language like an ugly puppy -- just
because it's yours.

The article shows case-by-case how Java and Eiffel address each problem (or
don't).  How much more practical can you get.

There is a whole industry full of computer science and language experts.  The
C++ critique is just one of their products.  If you don't like it, read B.
Stroustroup himself -- he will tell you all about the flaws in C++ -- and he
designed it!

The practical / academic argument is a false-choice fallacy.  You are saying
that only C++-derived or D-newsgroup-inspired design ideas are "practical," a
ludicrous position.  We can get pracical ideas from all kinds of sources.





Cant you do it? Its the second time you have sugested somting like this.


A more enthusiastic reception might encourage me.




I think you are being unfair.
I think Walters is doing great. The diversity of input from this newsgroup
and Walters willingness to engage discusion is going to do far better than
any other method i can think of.


Walter is doing great but can do better.  So can we.  There are more resources
to exploit than just our own imaginations.  Using them will get us to the final
destination a lot faster.

It saves labor to get things right from a high-level design standpoint -- and
also creates a better language.  You are missing that point in a big way.  




As walter says it is a language for programers not academics. Thats why he
has this newsgroup full of programers!


There's the false-choice fallacy again.  It's stupidity to ignore the rest of
the world.  Anyway, Walter is not doing that to the extent that you claim.
Thankfully he does look at languages like Eiffel and Icon, and even hears a few
academics.  Thank God we are not his only source of inspiration.

My major point is that D's over-commitment to C++-ness will prohibit the
significant gains that would be possible in a breakthrough design.




Given the right airplay and backing i think D will easily take over from
C++. simply because the transition from C++ will be fairly painless and it

painless aswell.



could be called 10 times better than C++.  And all of them enjoy greater market
share and maturity than D.


not just many times better than C++.  The only way I see that happening is to
loosen the coupling with C++ and seek good ideas from any place we can get them.
That is the practical approach.

Mark
Oct 31 2002
next sibling parent reply "anderson" <anderson firestar.com.au> writes:



Eiffel,

 not just many times better than C++.  The only way I see that happening is


to

 loosen the coupling with C++ and seek good ideas from any place we can get


them.

 That is the practical approach.

 Mark


Although I like the way D is going...

If you want to take D in a direction away from the C++ direction provide
some good ideas.  They will probably be taken in and result in a C++
syntaxical form, however that's a start.  After all D is meant to be based
on C not C++ but it does take alot of it's ideas from C++.

I think D has been developed to much for Walter to want to start on it again
(and I see no need to).  If D was made radically differnt from it's present
form, many of the programs that have already been written wouldn't work, and
would need a re-write.
Nov 01 2002
parent Mark Evans <Mark_member pathlink.com> writes:
If you want to take D in a direction away from the C++ direction


I don't, nor do I accept the inference that inputs from other sources will cause
such deviation.  Instead they can smooth the roadway for us.



provide
some good ideas.  They will probably be taken in and result in a C++
syntaxical form, however that's a start.


Oh gosh, I have.  Yet even mild syntax improvements are deemed unfit to survive.
A rational naming scheme for numeric types was killed.  Now I don't care that my
ideas are killed, but I do care why, because that affects everyone's ideas.  In
this case it was basically "we want D to read like C++" when the goal should be
"we want D to read more cleanly than C++."  This is what I mean about shooting
ourselves in the foot over C++-ness.

I've thrown in Icon, Eiffel, the C++?? Critique, and a few other things.
Negative indices were shot down.  Oh well.  Walter says there are STL-ish
iterators in the works.  I'll keep hope alive.


I think D has been developed to much for Walter to want to start on it again
(and I see no need to).  If D was made radically differnt from it's present
form, many of the programs that have already been written wouldn't work, and
would need a re-write.


That is not persuasive.  As I just said, even mild ideas (syntax changes to
rationalize C++ numeric types) are killed for un-C++-ness.  In such a situation,
what you should worry about is not radical change, but overly conservative
C++-ness effectively steamrolling many of the wonderful benefits available from
a broader design perspective.

OK Walter -- I've worn out my time on this subject.  My views are known and I
will leave it there.  I'm sure people will take more potshots but that is the
end of it for me.  I still think the world of you and hope the best for D.  I
would merely close by cautioning you that this newsgroup population is a small
and probably biased sample population, so you should explore discussions with
others too.  Thanks Walter!

Good luck,

Mark
Nov 01 2002
prev sibling parent reply "chris jones" <flak clara.co.uk> writes:
"Mark Evans" <Mark_member pathlink.com> wrote in message
news:apt6ht$2q1d$1 digitaldaemon.com...

 A good exercise would be to walk through the "C++??" critique


Asuming you agree with all the critisims. And solving all those problems
bring practical benefits.


 Everyone knows C++ has problems or there would be no D effort in the first


place




with

 which you disagree.  You seem to love the language like an ugly puppy --


just

 because it's yours.


I didnt say i like C/C++, i dont, i use Delphi because of that. What i was
saying is that you cant just assume every critisism from the paper is valid.
You have to decide which of them are relevant to D.

All of my main dislikes of C/C++ have been fixed in D. There are other
things that i would like diferantly but they are the kind of things that you
get used to and forget about very quickly.


 The article shows case-by-case how Java and Eiffel address each problem


(or

 don't).  How much more practical can you get.


Yes but it does not adress if they are practical in D. What may be practical
in Java/Eiffel may not be in D.

There is not one language that can be alll things to all programers, Java
and Eiffel may have diferant philosphies behind the language and so not all
of it may be relevant to D


 The practical / academic argument is a false-choice fallacy.  You are


saying

 that only C++-derived or D-newsgroup-inspired design ideas are


"practical," a

 ludicrous position.  We can get pracical ideas from all kinds of sources.


I said nothing of the sort. The people in this newsgroup may be acedemics. I
said the process of open discusion availible to anyone is better than a few
academics sat round a table. The people in this newsgroup can take
inspiration from anywhere they like. They can read the papers you cite.


Cant you do it? Its the second time you have sugested somting like this.


 A more enthusiastic reception might encourage me.


Less 'D is Doomed' might make people more enthusiastic :)



I think you are being unfair.
I think Walters is doing great. The diversity of input from this




newsgroup

and Walters willingness to engage discusion is going to do far better




than

any other method i can think of.


 Walter is doing great but can do better.  So can we.  There are more


resources

 to exploit than just our own imaginations.  Using them will get us to the


final

 destination a lot faster.

 It saves labor to get things right from a high-level design standpoint --


and

 also creates a better language.  You are missing that point in a big way.


Im not, just because i dont agree with you doesnt mean i missed the point.


As walter says it is a language for programers not academics. Thats why




he

has this newsgroup full of programers!


 There's the false-choice fallacy again.  It's stupidity to ignore the rest


of

 the world.  Anyway, Walter is not doing that to the extent that you claim.
 Thankfully he does look at languages like Eiffel and Icon, and even hears


a few

 academics.  Thank God we are not his only source of inspiration.


I never claimed he was doing it to any extent. The point is about the
diferance between what Academics want from a language and what programers
want from it.

A language will suceed if it satisfies the needs of the masses not the few.


 My major point is that D's over-commitment to C++-ness will prohibit the
 significant gains that would be possible in a breakthrough design.


Yes i think we got that. Mabey people would be more likely to agree if they
had more idea of what you mean. Just saying D can be better without specific
examples isnt going to win much suport. Write somthing up and post it here?
You will get more soapbox time than if you just post links to webpages.

To be honest i dont know what you want diferant. It sounds like almost
everything.


Given the right airplay and backing i think D will easily take over from
C++. simply because the transition from C++ will be fairly painless and




it


painless aswell.





languages

 could be called 10 times better than C++.  And all of them enjoy greater


market

 share and maturity than D.


Because they have been finalised and have been around longer. D is still
beta isnt it?


compiles directly and is faster.

I liked Java but it is useless for what i want. You cant write decent









Eiffel,

 not just many times better than C++.  The only way I see that happening is


to

 loosen the coupling with C++ and seek good ideas from any place we can get


them.

 That is the practical approach.


Yes but are the sacrifices worth it? You are not concerned with speed we
know, but many people are, most people who are still using C/C++ and
assembler. D is meant for those people aswell. I supose you would happily
dump them for the UberLanguage.

chris
Nov 01 2002
parent reply Mark Evans <Mark_member pathlink.com> writes:
Chris I am willing to let you have the last word because we are talking past
each other.  You think I am impractical and I think you are impractical, so
let's leave it there.  There is too much misreading and mischaracterization of
my arguments for me to spend more time on them with you.

Thanks-
Mark
Nov 01 2002
parent "chris jones" <flak clara.co.uk> writes:
Fair enough.

chris


"Mark Evans" <Mark_member pathlink.com> wrote in message
news:apv23q$2o9f$1 digitaldaemon.com...

 Chris I am willing to let you have the last word because we are talking


past

 each other.  You think I am impractical and I think you are impractical,


so

 let's leave it there.  There is too much misreading and


mischaracterization of

 my arguments for me to spend more time on them with you.

 Thanks-
 Mark
Nov 01 2002
prev sibling parent reply "anderson" <anderson firestar.com.au> writes:
"Mark Evans" <Mark_member pathlink.com> wrote in message
news:aovdpb$2fr5$1 digitaldaemon.com...

 If I were to draw a gas analogy it would be a dying old man on an oxygen


tank.

 C/C++ is the dying old man and D is the oxygen tank.  It would be better


to get

 rid of the smog and cigarettes in the first place, so that people don't


grow old

 prematurely.  Clean language design is like a storm front that blows all


the bad

 stuff away.

 All competent software engineers know a variety of languages and are able


to

 learn new ones quickly.  Those viewing C++ as some kind of comfort zone


just

 haven't spent enough time in other languages to understand the dramatic


gains

 that are available from superior syntax and expressiveness.

 Mark


The point is that C/C++ are the most used program languages in the world.
Of all it's cons, there must be something right in the languages otherwise
they wouldn't be used.  Just like windows, allot of people say they don't
like it, but it's the most popular PC OS.

I think the major thing C/C++ has going for it is that everything connects
into it (even Eiffel).  While Eiffel gains all the conectivity that C++ has
by connecting to it, it's a two step proccess (which may result in some C++
coding).

I have used a variety of other languages (Eiffel, basic, Ada, java, pascal,
prolog ect...)  but they just don't enjoy the level of support C++ does.
Even most persuado code is C syntax.  Go for a job and what do they want?


The only reason I'm changing over to D is because it's like C/C++, and has

access to the huge database of support C++ provides, and if it takes off, D
will also have it's own legacy database.  How many failed "so called good"
languages are there now?  Otherwise I'd use Eiffel (or some other popular
non-C++ language).

I think the name D indicates that it in the C family and an improvement. It
would have to be called something like Eiffel++ if it was to use Eiffel
syntax (or a different name if not using C syntax).

Even the great Walter himself choose C to create D and probably would have
used D if it had been avaliable at the time ;)

Perhaps were just all old hacks following the crowd, but the biggest crowds
have the biggest support.
Oct 20 2002
parent "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
That is both a blessing and a curse though.  Sure, deriving from C ties into
the vast pool of support C has.  But it also feels alot like a manacle that
you can't escape from.

My opinion on Eiffel is that it has a lot of good concepts but needs a
drastic syntax overhaul to be accepted by most programmers.  It seems overly
wordy.  Too many reserved words, and too much required use of them.
Terseness to me is a measure of expressive power.  Look at math;  very
terse, yet extremely flexible and powerful.

I'm so frustrated with languages at the moment.  I can't even find a good
language in which to start a compiler project.  ;(

I was going to use D, but it's still pretty early and changing alot and I


great array handling support (not quite as much as D has anyway) and the
lack of generics is a problem (can't easily do typed collections).  The

it has good debugger support.

It doesn't appear that MS has made it very easy to add new languages into
Visual Studio .NET, either.  I was looking toward integrating it briefly
last night.

Sean

"anderson" <anderson firestar.com.au> wrote in message
news:aovnk7$2p1s$1 digitaldaemon.com...

 The point is that C/C++ are the most used program languages in the world.
 Of all it's cons, there must be something right in the languages otherwise
 they wouldn't be used.  Just like windows, allot of people say they don't
 like it, but it's the most popular PC OS.

 I think the major thing C/C++ has going for it is that everything connects
 into it (even Eiffel).  While Eiffel gains all the conectivity that C++


has

 by connecting to it, it's a two step proccess (which may result in some


C++

 coding).

 I have used a variety of other languages (Eiffel, basic, Ada, java,


pascal,

 prolog ect...)  but they just don't enjoy the level of support C++ does.
 Even most persuado code is C syntax.  Go for a job and what do they want?


 The only reason I'm changing over to D is because it's like C/C++, and has

 access to the huge database of support C++ provides, and if it takes off,


D

 will also have it's own legacy database.  How many failed "so called good"
 languages are there now?  Otherwise I'd use Eiffel (or some other popular
 non-C++ language).

 I think the name D indicates that it in the C family and an improvement.


It

 would have to be called something like Eiffel++ if it was to use Eiffel
 syntax (or a different name if not using C syntax).

 Even the great Walter himself choose C to create D and probably would have
 used D if it had been avaliable at the time ;)

 Perhaps were just all old hacks following the crowd, but the biggest


crowds

 have the biggest support.
Oct 20 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Mark Evans" <Mark_member pathlink.com> wrote in message
news:aoqfbb$ebk$1 digitaldaemon.com...

 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.


D is designed to be an evolutionary successor to C/C++, and so necessarilly
will look a lot like them. It is designed to appeal to C/C++ programmers and
minimize the learning curve to jump from them to D. If that were not true,
not many people would even give D a chance.
Oct 21 2002
parent "anderson" <anderson firestar.com.au> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ap1j0h$1oou$1 digitaldaemon.com...

 D is designed to be an evolutionary successor to C/C++, and so


necessarilly

 will look a lot like them. It is designed to appeal to C/C++ programmers


and

 minimize the learning curve to jump from them to D. If that were not true,
 not many people would even give D a chance.


I agree, you need to stick to the scope.
Oct 22 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"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.
Oct 18 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
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
Oct 16 2002
parent reply Mark Evans <Mark_member pathlink.com> writes:
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
Oct 18 2002
parent "Walter" <walter digitalmars.com> writes:
"Mark Evans" <Mark_member pathlink.com> wrote in message
news:aoq44v$452$1 digitaldaemon.com...

 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.


I don't know enough about Eiffel to do an intelligent comparison.
Oct 20 2002