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

 to implement:  design-by-contract, compiled C performance, clean syntax,

 OO, templates, static typing, dynamic binding, multiple inheritance,

 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

 inter-linked structure by just specify the root object; then you can save

 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

 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

 inter-linked structure by just specify the root object; then you can save

 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

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

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

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

 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...
 D more simular to Ada, no pascal, no C, no Eiffel, C#, no ....oh I


 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

 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


 (and I believe both of you).  It all depends on what your doing and how

 you know.

I believe that too. Just put a badass optimizing backend right at the

 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

 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

 as much as you can to the p-code without actually running it and stop"

 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

 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

 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

 to see if a bigger (and costlier) runtime optimizer was available and

 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

 market to seriously consider alternative languages.
 I think once the industry separates the frontend from the backend

 (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

 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

 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

 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

 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

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

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

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

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

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

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

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

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

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

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

 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.

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


 flaws of C.  C/C++ syntax is notoriously cryptic, yet the D project is


 committed to C that even something as harmless as the use of good names


 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


 flaws of C.  C/C++ syntax is notoriously cryptic, yet the D project is


 committed to C that even something as harmless as the use of good names


 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

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

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

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

 stuff away.

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

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

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

 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

 the solution.

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

 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, C#) is to offer something so far beyond C++ that adoption is a no-brainer. By 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


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


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

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

 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

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

 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

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

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

 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++

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

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

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

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

 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

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

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

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

 C#) is to offer something so far beyond C++ that adoption is a no-brainer.

 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 is 10 times better. Actualy i think Java->D or C#->D should be pretty 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

bring practical benefits.

Everyone knows C++ has problems or there would be no D effort in the first place nor Java nor C#. I would be happy to discuss any particular C++ criticism with 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
is 10 times better. Actualy i think Java->D or C#->D should be pretty
painless aswell.

Why will companies select D over Java, C#, or Eiffel? Any of these languages could be called 10 times better than C++. And all of them enjoy greater market share and maturity than D. What we need is a language that is many times better than Java / C# / 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
Oct 31 2002
next sibling parent reply "anderson" <anderson firestar.com.au> writes:
 What we need is a language that is many times better than Java / C# /

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

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

 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

bring practical benefits.

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

 nor Java nor C#.  I would be happy to discuss any particular C++ criticism

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

 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

 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

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

 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


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


any other method i can think of.

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

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

 destination a lot faster.

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

 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


has this newsgroup full of programers!

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

 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

 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


is 10 times better. Actualy i think Java->D or C#->D should be pretty
painless aswell.

Why will companies select D over Java, C#, or Eiffel? Any of these

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

 share and maturity than D.

Because they have been finalised and have been around longer. D is still beta isnt it? The imediate reason why many programers will choose D over Java/C# is it compiles directly and is faster. I liked Java but it is useless for what i want. You cant write decent windows apps in Java. I need asmebler suport so C# is no use. C# is also useless because of a limitation of the linking of dlls writen in C#. There are things D has that neither Java/C#/Eiffel have aswell!
 What we need is a language that is many times better than Java / C# /

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

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

 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

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

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

 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

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

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

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

 stuff away.

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

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

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

 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? Someone who knows C/C++ (java or C#), most D programmers can do that. The only reason I'm changing over to D is because it's like C/C++, and has the chance to take off like C (as did C# and java). In learning D I have 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
find the tool support to be a problem.  So I started learning C# by writing
a compiler.  Something still feels wrong about C# however.  It doesn't have
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
string support is ok.  It's hard to get excited about C# though.  At least
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++

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

 coding).

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

 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?
 Someone who knows C/C++ (java or C#), most D programmers can do that.

 The only reason I'm changing over to D is because it's like C/C++, and has
 the chance to take off like C (as did C# and java).  In learning D I have
 access to the huge database of support C++ provides, and if it takes off,

 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.

 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

 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.



 enough.


 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

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

 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


 I'm sure he would have looked into a language as popular as Eiffel.


 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

 have a solid foundation of nice, clean, orthogonal software engineering

 instead of the mishmash heritage of C++.
 The C++?? paper shows the problems of C++, and Eiffel shows how to do

 right.  Between these two sources of inspiration I think D can strike a

 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

 to implement:  design-by-contract, compiled C performance, clean syntax,

 OO, templates, static typing, dynamic binding, multiple inheritance,

 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

 for] comments ... disappeared").

 Also look at the granularity of class inheritance mechanism ("In C++, ...

 decision is made at the granularity of the class - that is, entire classes

 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++??

 is an analysis of some of the flaws of C++....The critique uses Java and

 as comparisons to C++ to give a more concrete feel to the criticisms,

 conceptual differences rather than syntactic ones as being more

 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

 philosophy or technical capabilities?  Put another way, why use D instead

 Eiffel?

 You don't need comparisons with every language on earth, just those that

 as inspiration, and bear a resemblance to D.  C++ and Eiffel are D's next

 kin.

 These comparisons belong in the D write-ups.  Reading the D web pages

 impression that C++ was the only source of inspiration and the only

 language.

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