www.digitalmars.com         C & C++   DMDScript  

D - Ok so how does D differ from Eiffel ?

reply "Yeric" <someone somewhere.com> writes:
Ok sorry for what might seem to some as obvious, I am a student struggling
with C++ and looking for a clean implementation of OOP Java might seem like
an obvious choice, but it has flaws like many other so called OOP languages
Eiffel seems to offer a clean implementation of OOP designed from the ground
up offering DBC like D, but lacks any real usage or support, D is just

andclaim to offer speeds comparible to C/C++, I unfortunately do not have
time to read through pages of documentation to decide what to use and what
not to use, I was just about conviced about Eiffel when a friend said have
you looked at D?  No I replied what is D ?
I was given www.digitalmars.com and said read up on it.

I started to read, thought this looks interesting, infact looks very similar
to Eiffel in concept, but offers the opportunity to code like a C/C++
programmer just more cleanly. but since I have not learnt C/C++ properly it
would not matter too much to learn a different syntax, Eiffel offers what
might seem to some a very simple syntax, and comparing to some C/C++
programs very fast, but then again so does D, D seems to offer a syntax
similar to C/C++ to entice these programmers, but what else can it offer, I
notice there is DIDE which looks really cool but like Eifel it is a shame
there is no windows level gui editor like in VB, and what about support for
OLE DB or OpenGL, what support can D offer for database access like VB ( a
horrible language I know ) or for the games programmer, I think I understand
it is like C but since I have not learhnt C will it be hard to pick up? does
D model a true OOP language or is it yet another hybrid C ?

You thoughts are welcome in anticipation
Yeric
Apr 24 2004
next sibling parent reply renZYX hotmail.com writes:
IMHO There are two differences between D and Eiffel:
- technical differences:
For example, Eiffel offer true multiple inheritance, whereas D only offers
interface, probably because it is simpler to implement.

Some people dislike multiple inheritance, but I've never heard Eiffel users
complain about it, and I think that it is really handy for storing/retrieving
the object in an object-database.
The only thing good I can say about the interface compared to multiple
inheritance is that it is probably easier to implement, but to me, it looks like
a kludge..


- mindset differences: Eiffel never had a big following, probably because the
tools were expensive. Now there is SmartEiffel, but Eiffel has long lost its the
appeal. D is new so it still has the new 'kid on the block' factor for it.

I think that the choice of a computer language is like fashion: what's new is
cool..

Technically still D may have some advantages: does Eiffel support threads?

What would be interesting though would be a comparison of templates between
Eiffel and D? I seem to remember that templates in Eiffel were quite good, but
it has been a long time since I've read Meyer's book..
Apr 24 2004
parent reply "Yeric" <someone somewhere.com> writes:
 IMHO There are two differences between D and Eiffel:
 - technical differences:
 For example, Eiffel offer true multiple inheritance, whereas D only offers
 interface, probably because it is simpler to implement.
Sorry I was a bit beered up when I wrote this message, this is not meant to be a TROLL message honestly! I am caught between a rock and a stone, C++ is just too hard to master, sure I understand the basics, pointers I just about understand, as long as it is nothing to do with arrays of pointers and pointers to functions, maybe it is just me, I grasped Java quite well, but it can execute slowly at times especially if it is not the only program running, and load times for complex Java apps is too slow. VB seems simple, but I dislike the error handling in VB it is almost as if it was an after thought, and makes code very messy, in the end I wrote one huge class to handle errors in VB which seems to work quite well, and it connects to databases very nicely and I do like ADO, which is why I have been struggling to get to grips with C++ but just haven't managed it in almost 6 months, because VC++ also supports ADO, but since ADO is M$ specific, I do not think I will find another programming language that will offer ADO support?
 Some people dislike multiple inheritance, but I've never heard Eiffel
users
 complain about it, and I think that it is really handy for
storing/retrieving
 the object in an object-database.
Multiple inheritance in C++ confuses the hell out of me, I have not looked too deeply into this in Eiffel either, so D offeres a similar solution to Java then offering multiple interfaces rather than multiple inheritance?
 The only thing good I can say about the interface compared to multiple
 inheritance is that it is probably easier to implement, but to me, it
looks like
 a kludge..


 - mindset differences: Eiffel never had a big following, probably because
the
 tools were expensive. Now there is SmartEiffel, but Eiffel has long lost
its the
 appeal. D is new so it still has the new 'kid on the block' factor for it.
True nearly 5k for a language can seem steep, especially for a student, but they do now offer a free for non commercial use Eiffel studio and Eiffel vision.
 I think that the choice of a computer language is like fashion: what's new
is
 cool..
Yes this is true, Next year I am doing a project on OOP and have to implement it in an OOP language, which is why I have been trying to learnr C++ because it executes fast, but it is so difficult to get right, if I had just 1 pound for every null pointer exception I would not need to go to college or work, I would be rich :)
 Technically still D may have some advantages: does Eiffel support threads?
I believe it does via an addon on library, but not too sure, as I have not read all the ins and outs of this, I only knew about Eiffel because my tutor mentioned it as I was struggling with C++ and I only know about D because I use digitalmars C++ compiler that I bought some time ago, and every now and then I check out the page and saw D started reading about it but there is a lot to read. I know it has a comparison page, but notice that Eiffel is missing from the D is the way forward because..... listing all its strengths as well as it's weakness.
 What would be interesting though would be a comparison of templates
between
 Eiffel and D? I seem to remember that templates in Eiffel were quite good,
but
 it has been a long time since I've read Meyer's book..
Yes this would be good, Meyer's book OOSC2 is good, but again there is over 1000 pages, but in this case it is justified in most cases OO it self is a huge beast to tackle yet according to Meyer it should be the easiest thing for humans to master, because we already think in terms of objects and abstraction naturally in real life, but the plethora of other programming languages that evolved early on have reprogrammed our minds to not think naturally, I have not read Meyers book yet, but this refers heavily to Eiffel as I understand it. Thanks for the info Yeric
Apr 25 2004
next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Yeric schrieb:
 Sorry I was a bit beered up when I wrote this message, this is not meant to
 be a TROLL message honestly! I am caught between a rock and a stone, C++ is
 just too hard to master, sure I understand the basics, pointers I just about
 understand, as long as it is nothing to do with arrays of pointers and
 pointers to functions, maybe it is just me, I grasped Java quite well, but
 it can execute slowly at times especially if it is not the only program
 running, and load times for complex Java apps is too slow. VB seems simple,
 but I dislike the error handling in VB it is almost as if it was an after
 thought, and makes code very messy, in the end I wrote one huge class to
 handle errors in VB which seems to work quite well, and it connects to
 databases very nicely and I do like ADO, which is why I have been struggling
 to get to grips with C++ but just haven't managed it in almost 6 months,
 because VC++ also supports ADO, but since ADO is M$ specific, I do not think
 I will find another programming language that will offer ADO support?
I don't know what ADO is, but how is it acessed? Is there some library in C or C++ for it? If the source is available, you can compile it with DMD and then wrap it with SWIG/D.
 Multiple inheritance in C++ confuses the hell out of me, I have not looked
 too deeply into this in Eiffel either, so D offeres a similar solution to
 Java then offering multiple interfaces rather than multiple inheritance?
There is not much confusing in multiple inheritance in C++, apart from the hard-to-handle consequences of the things you should not do anyway. :> The thing is, usual programming in C++ is not about knowing everything, it is about having morals. You must always create your own language you use within C++. That's where such books like Thinking In C++ come in handy, they teach you a well establiched moral, as well as give you a feeling of what might go wrong else.
The only thing good I can say about the interface compared to multiple
inheritance is that it is probably easier to implement, but to me, it 
looks like a kludge..
They are 2 different ways of thinking: Multiple Inheritance is self-sufficent in a rootless hierarchy, but forces you to separate your classes into "root hierarchy" and "mix-ins", or an arbitrary number of root hierarchies, which makes it hard to handle though. Single inheritance is the right way where there's a root object, like in Java, D or Delphi. The root object "Object" defines a few behaviours, which can be redefined by descendant classes. If 2 branches both inherit from a root object, and then flow together in a single descendant, they may generate a conflict between the basic object behaviour. Though usually it is not as serious as it sounds, it is nontheless potentially bad and frankly unnnecessary. When D gets a sort of Mix-Ins (I think Mathew takes care of that), our hierarchy system is complete. Sather has a single-inheritance based hierearachy with separated interfaces and mix-ins, although they call it "true" multiple inheritance. I mention Sather here because it is a descendant of Eiffel, and probably does things similarly. I have however not gotten to the details of Eiffel yet, because Eiffel causes me a headache. :> As opposed to Sather and C++.
 True nearly 5k for a language can seem steep, especially for a student, but
 they do now offer a free for non commercial use Eiffel studio and Eiffel
 vision.
You might want to look at Sather. Sather goes the line of Eiffel, but is a much simpler and somewhat more powerful language - don't believe any Eiffelheads when they start bashing on it, i can revide almost any of their arguments. It has not been used by anyone during the last 2 years. Maintainance has been almost none during the last 4. It is hosted on Savannah since a university did not want to take care of it. Read 100 pages on Sather and you're a language expert. Read 100 pages of Eiffel and there's still too much to learn. However, there are too few libraries wrapped. However, SWIG support has been floating around. Anyway, if you are not prepared to wrap one or another C library, than D is not (yet) for you, and forget Sather because it would cause too much work. Actually a pity. Preparing libraries to work in D is much less work than for Sather, because you don't have the huge syntax difference.
 Yes this is true, Next year I am doing a project on OOP and have to
 implement it in an OOP language, which is why I have been trying to learnr
 C++ because it executes fast, but it is so difficult to get right, if I had
 just 1 pound for every null pointer exception I would not need to go to
 college or work, I would be rich :)
You will be getting null pointer exceptions in D as well. :>>> But well, i would hope they would be more understandable or something.
 [...] I check out the page and saw D started reading about it but there is a
 lot to read.
Oh, it's done in one evening. Much faster than i can type in this answer. :> Besides, with good Java knowledge and some even superficial C++, you should have enough to master D wonderfully.
 I know it has a comparison page, but notice that Eiffel is missing from the

 D is the way forward because..... listing all its strengths as well as it's
 weakness.
The tabular language comparisons are always higly unfair - they expose only some spots on the surface and hide any detail.
 Yes this would be good, Meyer's book OOSC2 is good, but again there is over
 1000 pages, but in this case it is justified in most cases OO it self is a
 huge beast to tackle yet according to Meyer it should be the easiest thing
 for humans to master, because we already think in terms of objects and
 abstraction naturally in real life, but the plethora of other programming
 languages that evolved early on have reprogrammed our minds to not think
 naturally, I have not read Meyers book yet, but this refers heavily to
 Eiffel as I understand it.
Uh-oh. Within 1000 pages you could wonderfully learn C++ as well. E.g. "Thinking in C++", first volume, from Bruce Eckel. It actually reads very esily. -eye
Apr 25 2004
next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 Yes this would be good, Meyer's book OOSC2 is good, but again there is over
 1000 pages, but in this case it is justified in most cases OO it self is a
 huge beast to tackle yet according to Meyer it should be the easiest thing
 for humans to master, because we already think in terms of objects and
 abstraction naturally in real life, but the plethora of other programming
 languages that evolved early on have reprogrammed our minds to not think
 naturally, I have not read Meyers book yet, but this refers heavily to
 Eiffel as I understand it.
Uh-oh. Within 1000 pages you could wonderfully learn C++ as well. E.g. "Thinking in C++", first volume, from Bruce Eckel. It actually reads very esily.
If you can wait until Sept/Oct, you can buy the forthcoming "Imperfect C++", which some reviewers have called "an essential and _practical_ survival guide to C++". :-)
Apr 25 2004
prev sibling parent reply "Yeric" <someone somewhere.com> writes:
 I don't know what ADO is, but how is it acessed? Is there some library
 in C or C++ for it? If the source is available, you can compile it with
 DMD and then wrap it with SWIG/D.
ADO = ActiveX Data Objects A Microsoft library designed to plug into VB and VC++, I believe it has a COM interface as well, used to acees and manipulate recordsets in databases either OLE DB or ODBC, providing a nice abstraction layer to avoid exposing mere mortals to the complexities of ODBC and OLE DB Raw :)
 There is not much confusing in multiple inheritance in C++, apart from
 the hard-to-handle consequences of the things you should not do anyway. :>
Oh I see it does not matter how many times I read the section on MI I just do not get it :( and I haver been reading the excellent Bruce Eckel Book Thinking in C++ 2nd Edition Volume One, and yes I agree it is one of the easier books to understand, but I think I do not fully understand OO yet I understand the concept just not the implementation :(
 They are 2 different ways of thinking: Multiple Inheritance is
 self-sufficent in a rootless hierarchy, but forces you to separate your
 classes into "root hierarchy" and "mix-ins", or an arbitrary number of
 root hierarchies, which makes it hard to handle though.

 Single inheritance is the right way where there's a root object, like in
 Java, D or Delphi. The root object "Object" defines a few behaviours,
 which can be redefined by descendant classes. If 2 branches both inherit
 from a root object, and then flow together in a single descendant, they
 may generate a conflict between the basic object behaviour. Though
 usually it is not as serious as it sounds, it is nontheless potentially
 bad and frankly unnnecessary. When D gets a sort of Mix-Ins (I think
 Mathew takes care of that), our hierarchy system is complete.
So essentially Single Inheritance is ok, and not the really bad thing it is made out to be in MI languages ?
 Sather has a single-inheritance based hierearachy with separated
 interfaces and mix-ins, although they call it "true" multiple
 inheritance. I mention Sather here because it is a descendant of Eiffel,
 and probably does things similarly. I have however not gotten to the
 details of Eiffel yet, because Eiffel causes me a headache. :> As
 opposed to Sather and C++.
I have never heard of Sather until now C++ would be fine if I could understand it all, but you mention that this is not neccessary, I guess you are right, when I look back on my VB days I did not read the whole book instead knocked up a couple of forms add some crude code to the button and comboboxes and I got a working app, the error handling code came afterwards <g> and cover almost if not more coding than the actual app, unless I had a single on error routine in main that printed cryptic error messages in err.description, eventually I could map certain error numbers to actual things and this is where it got messy with a plethora of select case statements it was hideous, eventually I moved this code to a seperate module set as public, and then eventually wrapped it all up in a class.
 True nearly 5k for a language can seem steep, especially for a student,
but
 they do now offer a free for non commercial use Eiffel studio and Eiffel
 vision.
You might want to look at Sather. Sather goes the line of Eiffel, but is a much simpler and somewhat more powerful language - don't believe any Eiffelheads when they start bashing on it, i can revide almost any of their arguments. It has not been used by anyone during the last 2 years. Maintainance has been almost none during the last 4. It is hosted on Savannah since a university did not want to take care of it. Read 100 pages on Sather and you're a language expert. Read 100 pages of Eiffel and there's still too much to learn. However, there are too few libraries wrapped. However, SWIG support has been floating around. Anyway, if you are not prepared to wrap one or another C library, than D is not (yet) for you, and forget Sather because it would cause too much work. Actually a pity. Preparing libraries to work in D is much less work than for Sather, because you don't have the huge syntax difference.
You mention library wrapping, but is this only possible if you have the source code ?? I doubt any source code exists for Microsoft products ?
 You will be getting null pointer exceptions in D as well. :>>> But well,
 i would hope they would be more understandable or something.
Me too
 Oh, it's done in one evening. Much faster than i can type in this
 answer. :> Besides, with good Java knowledge and some even superficial
 C++, you should have enough to master D wonderfully.
He he famous last words, Is there a gui designer for D yet, is there one planned in the future? I laugh everytime I read about VC++ I just cant see what is visual about it where is the nice gui designer like you get with VB ?
 The tabular language comparisons are always higly unfair - they expose
 only some spots on the surface and hide any detail.
 Uh-oh. Within 1000 pages you could wonderfully learn C++ as well. E.g.
 "Thinking in C++", first volume, from Bruce Eckel. It actually reads
 very esily.

 -eye
Thanks for the insight
Apr 25 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Yeric wrote:

He he famous last words, Is there a gui designer for D yet, is there one
planned in the future? I laugh everytime I read about VC++ I just cant see
what is visual about it where is the nice gui designer like you get with VB
?
  
There is a GUI designer in VC++ as part of MFC, but it's not nice like VB's. -- -Anderson: http://badmama.com.au/~anderson/
Apr 25 2004
parent reply "Yeric" <someone somewhere.com> writes:
 There is a GUI designer in VC++ as part of MFC, but it's not nice like
VB's. There is an excuse for one <g> but I have not used it, I have been trying to learn the core language first then go onto windows programming.
Apr 25 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Yeric wrote:

There is a GUI designer in VC++ as part of MFC, but it's not nice like
    
VB's. There is an excuse for one <g> but I have not used it, I have been trying to learn the core language first then go onto windows programming.
Yeah I think MFC is really icky. -- -Anderson: http://badmama.com.au/~anderson/
Apr 25 2004
parent reply "Vathix" <vathix dprogramming.com> writes:
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c6gong$2b4n$2 digitaldaemon.com...
 Yeric wrote:

There is a GUI designer in VC++ as part of MFC, but it's not nice like
VB's. There is an excuse for one <g> but I have not used it, I have been trying
to
learn the core language first then go onto windows programming.
Yeah I think MFC is really icky. --
You don't need to use MFC to use VC++'s GUI designer. Add a dialog resource to your non-MFC project; you just can't use the class wizard stuff because you have to manually setup a dialog callback procedure and use CreateDialog() or DialogBox(). -- Christopher E. Miller
Apr 25 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Vathix wrote:

You don't need to use MFC to use VC++'s GUI designer. Add a dialog resource
to your non-MFC project; you just can't use the class wizard stuff because
you have to manually setup a dialog callback procedure and use
CreateDialog() or DialogBox().
The VC++ designer is ugly and the MFC language is ugly. It's full of macros and ditchs. -- -Anderson: http://badmama.com.au/~anderson/
Apr 25 2004
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Yeric schrieb:
I don't know what ADO is, but how is it acessed? Is there some library
in C or C++ for it? If the source is available, you can compile it with
DMD and then wrap it with SWIG/D.
ADO = ActiveX Data Objects A Microsoft library designed to plug into VB and VC++, I believe it has a COM interface as well, used to acees and manipulate recordsets in databases either OLE DB or ODBC, providing a nice abstraction layer to avoid exposing mere mortals to the complexities of ODBC and OLE DB Raw :)
Ok, so it's ActiveX. ActiveX is COM, COM is supported in D through interface. As far as i know, it is possible to query an installed COM object of its interface, this can be used to generate a D imports file, as well as to make a User Interface editor, which would work with COM objects and output D source. However, it takes someone who knows something about COM - and that is definately not me.
There is not much confusing in multiple inheritance in C++, apart from
the hard-to-handle consequences of the things you should not do anyway. :>
Oh I see it does not matter how many times I read the section on MI I just do not get it :( and I haver been reading the excellent Bruce Eckel Book Thinking in C++ 2nd Edition Volume One, and yes I agree it is one of the easier books to understand, but I think I do not fully understand OO yet I understand the concept just not the implementation :(
Then i have to agree to Mathew, who just said basically the same as i did, just *much* better.
 So essentially Single Inheritance is ok, and not the really bad thing it is
 made out to be in MI languages ?
True, because it is always not simple single inheritance we have. And D might make one step further.
 I have never heard of Sather until now
Because it has too few friends to support it. :/ Pity for a fine high performance high safety no-nonsense language.
 You mention library wrapping, but is this only possible if you have the
 source code ?? I doubt any source code exists for Microsoft products ?
Library wrapping requieres that you have a way to call the code from the source language. For example, Sather/C can embed tiny pieces of C code which are passed as they are to the compiler. Sather/Java can call Java classes directly, if you describe their interface in Java syntax first, and Sather/C also has this sort of thing. D can call C code directly, but you also have to describe its interface in D syntax. There is one limitation though: can you call this C code from the corresponding C compiler? Sather/C is known to work with GCC, and can probably be made work with other C compilers. DigitalMars D compiler works only with DigitalMars C because of pecularities of a linking format. There is also Gnu D compiler, which works with GCC. But beware: there might be libraries which are available only for MSVC, and then you're trapped. C++ libraries requiere 2 additional levels of wrapping - since other languages cannot call C++ code, you have to wrap it into C function calls, import them into target language (e.g. D), and wrap them into D code which looks and behaves like C++ code. There is a tool called SWIG developed for Python, Sather, and many other languages, which does all of these steps automatically. Andy has written a module for it which works with D. (http://andy.tadan.us/d/)
 He he famous last words, Is there a gui designer for D yet, is there one
 planned in the future? I laugh everytime I read about VC++ I just cant see
 what is visual about it where is the nice gui designer like you get with VB
 ?
Oh, it will take a long, long way until we have one. It involves parsing D code and generating auto-bindings. But for ActiveX based developement only, i would think one could be written quite easily, but i can't say for sure since i don't know much about COM.
 Thanks for the insight
You're welcome! -eye
Apr 25 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 IMHO There are two differences between D and Eiffel:
 - technical differences:
 For example, Eiffel offer true multiple inheritance, whereas D only offers
 interface, probably because it is simpler to implement.
Sorry I was a bit beered up when I wrote this message, this is not meant to be a TROLL message honestly! I am caught between a rock and a stone, C++ is just too hard to master, sure I understand the basics, pointers I just about understand, as long as it is nothing to do with arrays of pointers and pointers to functions, maybe it is just me,
[sorry I had to break mid-sentence, but ... don't you take a breath? <G>] I love C++, and it's still the language I _think_ in, but I really struggle to recommend it to people entering software engineering. This is really bad for me since my first two books and most of my articles are on the subject. He he.
 I grasped Java quite well, but
 it can execute slowly at times especially if it is not the only program
 running, and load times for complex Java apps is too slow.
With the single domain of "enterprise applications" (websites, in other words), Java is SH, no doubt about it.
 VB seems simple,
 but I dislike the error handling in VB it is almost as if it was an after
 thought,
It was
 and makes code very messy, in the end I wrote one huge class to
 handle errors in VB which seems to work quite well, and it connects to
Geez, man, give us a full stop [US-Trans: "period"] every now and then! VB is a joke language, and no-one should be suggesting it to someone to learn as a first language. I would consider that a deliberate sabotage of that person's future in software engineering.
 databases very nicely and I do like ADO, which is why I have been struggling
 to get to grips with C++ but just haven't managed it in almost 6 months,
 because VC++ also supports ADO, but since ADO is M$ specific, I do not think
 I will find another programming language that will offer ADO support?
Don't get hooked on one database layer. Force yourself to learn at least two different ones, as they're incredibly proprietary, and designed entirely for the lock-in.
 Some people dislike multiple inheritance, but I've never heard Eiffel
users
 complain about it, and I think that it is really handy for
storing/retrieving
 the object in an object-database.
Multiple inheritance in C++ confuses the hell out of me, I have not looked too deeply into this in Eiffel either, so D offeres a similar solution to Java then offering multiple interfaces rather than multiple inheritance?
MI in C++ is simple: don't do it. Except: - tag base classes, such as the iterator tags and the like - empty base classes, such as STL allocators - interfaces (classes/structs composed of pure virtual functions, maybe static functions, and *nothing else*). The fact that these three things are absolutely essential, and *any* language that does not have them is hamstrung by comparison, means that MI in C++ is a great thing (as long as you don't use it for what it was intended for <G>).
 The only thing good I can say about the interface compared to multiple
 inheritance is that it is probably easier to implement, but to me, it
looks like
 a kludge..


 - mindset differences: Eiffel never had a big following, probably because
the
 tools were expensive. Now there is SmartEiffel, but Eiffel has long lost
its the
 appeal. D is new so it still has the new 'kid on the block' factor for it.
True nearly 5k for a language can seem steep, especially for a student, but they do now offer a free for non commercial use Eiffel studio and Eiffel vision.
Paying for a language is joke. Period [Rest of English speaking world-Trans: "full stop"] I have recently recommended D as one of two languages (the scripting language was Ruby) to learn to a close friend who wants to dig a way out of FoxPro hell. I think it is rapidly accelerating to a point of extreme usefulness. For example, today I wrote a tool that I've wanted for years - a registry grepper - and it only took me three hours. (The fact that D's Win32 registry module is of the highest quality, cough cough, may have something to do with that.) Basically, it's std.windows.registry and std.regexp, and just pure client code with no hacks or workarounds. And it works a treat. (I'm going to submit it as a sample for Phobos for the next release, or the one after maybe, depending on my desire to of the effort in messing around with all the twiddly bits. But D ... 3 hours! Learn D.
Apr 25 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:

I love C++, and it's still the language I _think_ in, but I really struggle to
recommend it to people entering software engineering. This is really bad for me
since my first two books and most of my articles are on the subject. He he.
<snip>
Learn D.
Yeah D is probably the best language to begin with before learning C++ <g> -- -Anderson: http://badmama.com.au/~anderson/
Apr 25 2004
parent reply "Yeric" <someone somewhere.com> writes:
Learn D.
Yeah D is probably the best language to begin with before learning C++ <g>
Ok ok I get the picture ;) but is there a book yet that for D apart from the D the language <g> . Yeric
Apr 25 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Yeric wrote:

Ok ok I get the picture ;) but is there a book yet that for D apart from the
D the language <g> .
  
Nope. This group is a good resource. A book on C++ or java (that doesn't discuss the libraries) is probably one course of action to learning D. I do think, however that the best way to learn a language is by doing and looking at what others have done. There are plenty of D tutorials around. You should check out the wiki (http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage) and dsource (http://www.dsource.org/tutorials/). Best thing to so is to imagine something and then try to do it. When you get stuck ask this newsgroup or even chat on the D ICQ group - irc.dprogramming.com #D.
Yeric
  
-- -Anderson: http://badmama.com.au/~anderson/
Apr 25 2004
prev sibling next sibling parent reply "Yeric" <someone somewhere.com> writes:
 [sorry I had to break mid-sentence, but ... don't you take a breath? <G>]
he he no, I can actually type faster than I can speak or think :)
 I love C++, and it's still the language I _think_ in, but I really
struggle to
 recommend it to people entering software engineering. This is really bad
for me
 since my first two books and most of my articles are on the subject. He
he.

So what might you recommend ?

 With the single domain of "enterprise applications" (websites, in other
words),
 Java is SH, no doubt about it.
I agree, which was its primary function I believe ?
 Geez, man, give us a full stop [US-Trans: "period"] every now and then!
Ok . <g>
 VB is a joke language, and no-one should be suggesting it to someone to
learn as
 a first language. I would consider that a deliberate sabotage of that
person's
 future in software engineering.
I agree, it allows anyone with little programming knowledge to program (badly)
 Don't get hooked on one database layer. Force yourself to learn at least
two
 different ones, as they're incredibly proprietary, and designed entirely
for the
 lock-in.
Is this not the case with all M$ products. <-- note the full stop or period <g>
 MI in C++ is simple: don't do it.
 Except:
  - tag base classes, such as the iterator tags and the like
  - empty base classes, such as STL allocators
  - interfaces (classes/structs composed of pure virtual functions, maybe
static
 functions, and *nothing else*).

 The fact that these three things are absolutely essential, and *any*
language
 that does not have them is hamstrung by comparison, means that MI in C++
is a
 great thing (as long as you don't use it for what it was intended for
<G>). He he sounds familiar
 Paying for a language is joke. Period [Rest of English speaking
world-Trans:
 "full stop"]
?? I think it is only fair that someone who has spent a lot of time and effort developing something useful should be paid for it if they want, but this would depend if it was good enough in the first place :)
 I have recently recommended D as one of two languages (the scripting
language was
 Ruby) to learn to a close friend who wants to dig a way out of FoxPro
hell. I
 think it is rapidly accelerating to a point of extreme usefulness. For
example,
 today I wrote a tool that I've wanted for years - a registry grepper - and
it
 only took me three hours. (The fact that D's Win32 registry module is of
the
 highest quality, cough cough, may have something to do with that.)
Basically,
 it's std.windows.registry and std.regexp, and just pure client code with
no hacks
 or workarounds. And it works a treat. (I'm going to submit it as a sample
for
 Phobos for the next release, or the one after maybe, depending on my
desire to

because
 of the effort in messing around with all the twiddly bits. But D ... 3
hours!
 Learn D.
And of course this is a completely unbiased answer :) Perhaps you are right, doing is learning, I have often found this to be the case However I have twice in VB used this method od doing is learning, only to find I have written something that already existed in the library. <-- note the period again [Full Stop] <g> Thanks Yeric
Apr 25 2004
next sibling parent reply "Unknown W. Brackets" <unknown at.simplemachines.dot.org> writes:
Yeric wrote:
 ?? I think it is only fair that someone who has spent a lot of time and
 effort developing something
 useful should be paid for it if they want, but this would depend if it was
 good enough in
 the first place :)
Yes and no. I think the biggest problem here is that so many programming languages are free... so a language would have to be spectacularly good to not be. Even Microsoft recently released their optimized compiler for free - and before that they were offering a compiler for free. I, myself, write open source (well, not always GPL, but pretty close...) projects which are all free. I have spent hours upon hours (in fact, a year's worth of hours!) on this - and I've never asked any money... although we (the team I work with) do offer a paid priority support option. So, I'm not just a freeloader saying everything should be free. Rather, I think programming is an "academic" enough thing that it's more like science than retail. Unless I'm mistaken, this is the rough view point of most open source people. Instead of paying for the software, you "pay" by giving back and contributing things like libraries, contructive comments, and support for the software. Again as someone who provides open source software to thousands across the world, I get more enjoyment out of seeing people happy with my software, helping others or contributing in other ways, than I would by getting $50/hour for programming. (which is my usual rate for hardware or technical support when in person... and would make me a very, very rich man.) But, I didn't write Eiffel, nor have I ever used it. Maybe it is worth however much is being charged for it... maybe the author(s) don't get the same joy out of seeing their users use it. -[Unknown]
Apr 25 2004
parent "Yeric" <someone somewhere.com> writes:
 Yes and no.  I think the biggest problem here is that so many
 programming languages are free... so a language would have to be
 spectacularly good to not be.
He he so how do M$ sleep at night asking people to pay for things like VB <g>
 Even Microsoft recently released their optimized compiler for free - and
 before that they were offering a compiler for free.
Yes this surprised me too but then again all their .Net is free if you download the SDK
 I, myself, write open source (well, not always GPL, but pretty close...)
 projects which are all free.  I have spent hours upon hours (in fact, a
 year's worth of hours!) on this - and I've never asked any money...
 although we (the team I work with) do offer a paid priority support
option. Then you have my respect, I admire Open Source and the principles behind it, if I could write anything useful right now, I would give it to open source if it was good enough, since I have used many Open source tools including GCC, alas at the moment I am struggling period.
 So, I'm not just a freeloader saying everything should be free.  Rather,
 I think programming is an "academic" enough thing that it's more like
 science than retail.
Programming is a way of life :) even though I am not a guru yet, I enjoy it like some people like golf
 Unless I'm mistaken, this is the rough view point of most open source
 people.  Instead of paying for the software, you "pay" by giving back
 and contributing things like libraries, contructive comments, and
 support for the software.
This is precisley the reason Open source exists to spread the knowledge among mortals to learn instead of keeping it to a chosen few.
 Again as someone who provides open source software to thousands across
 the world, I get more enjoyment out of seeing people happy with my
 software, helping others or contributing in other ways, than I would by
 getting $50/hour for programming. (which is my usual rate for hardware
 or technical support when in person... and would make me a very, very
 rich man.)
coding makes me happy too I enjoy the challenge of transferring my ideas into another language not unlike foreigh translator in some ways.
 But, I didn't write Eiffel, nor have I ever used it.  Maybe it is worth
 however much is being charged for it... maybe the author(s) don't get
 the same joy out of seeing their users use it.
Perhaps it is, I might not have heard of it if it were not for my tutor mentioning it i believe there are many programming languages out there it is just that C/C++ and Java hold the limelight. I only know of D because I have the DM C++ compiler if it were not for that I would never have known, I am going to let my tutor read up on it he is an old Unix Guru and loves new programming languages I am sure he will be interested in D. I myself do not understand enought to pass judgement, but if it delivers half of what it says then I will use it. Now whether it is yet complete enough to do my OO project in I do not know, from what I have read then I think it is, it might be missing certain things that I do not know about anyhow. Yeric
Apr 25 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 [sorry I had to break mid-sentence, but ... don't you take a breath? <G>]
he he no, I can actually type faster than I can speak or think :)
I know where you're coming from. ;)
 I love C++, and it's still the language I _think_ in, but I really
struggle to
 recommend it to people entering software engineering. This is really bad
for me
 since my first two books and most of my articles are on the subject. He
he.

 So what might you recommend ?
D and Ruby
 Geez, man, give us a full stop [US-Trans: "period"] every now and then!
Ok . <g>
 VB is a joke language, and no-one should be suggesting it to someone to
learn as
 a first language. I would consider that a deliberate sabotage of that
person's
 future in software engineering.
I agree, it allows anyone with little programming knowledge to program (badly)
Exactly. The same can be said of .NET to some degree - I've certainly seen it abused in commercial developments.
 Don't get hooked on one database layer. Force yourself to learn at least
two
 different ones, as they're incredibly proprietary, and designed entirely
for the
 lock-in.
Is this not the case with all M$ products. <-- note the full stop or period <g>
With almost all (VC++ 7.1 is pretty conformant.)
 Paying for a language is joke. Period [Rest of English speaking
world-Trans:
 "full stop"]
?? I think it is only fair that someone who has spent a lot of time and effort developing something useful should be paid for it if they want, but this would depend if it was good enough in the first place :)
If they want it to succeed, they can't charge for the language. Just the consultancy fees a couple of years down the line.
 I have recently recommended D as one of two languages (the scripting
language was
 Ruby) to learn to a close friend who wants to dig a way out of FoxPro
hell. I
 think it is rapidly accelerating to a point of extreme usefulness. For
example,
 today I wrote a tool that I've wanted for years - a registry grepper - and
it
 only took me three hours. (The fact that D's Win32 registry module is of
the
 highest quality, cough cough, may have something to do with that.)
Basically,
 it's std.windows.registry and std.regexp, and just pure client code with
no hacks
 or workarounds. And it works a treat. (I'm going to submit it as a sample
for
 Phobos for the next release, or the one after maybe, depending on my
desire to

because
 of the effort in messing around with all the twiddly bits. But D ... 3
hours!
 Learn D.
And of course this is a completely unbiased answer :)
It is. First and foremost I'm a C++ programmer, and probably always will be. I D is the language I would recommend to someone learning a compiled language, and Ruby for a scripting one.
 Perhaps you are right, doing is learning, I have often found this to be the
 case
 However I have twice in VB used this method od doing is learning, only to
 find
 I have written something that already existed in the library. <-- note the
 period again [Full Stop] <g>

 Thanks
You're welcome
Apr 25 2004
prev sibling parent reply "Scott Egan" <scotte tpg.com.aux> writes:
Matthew,

firstly I'll try and maintain a judicious use of full-stops.  There how's
that, there's one already ;)

Don't be too quick to bag MI.  I remember many moons ago using the Borland
Windows Framework (can't even remember what it's called now; but it beat MFC
hands down).

There were two window types: a MID Child and a Decorated Frame.  I wanted a
Decorated MDI Child; so I just derived from both and... It worked!

Mind you that's about the only time I remember using MI - maybe you're
correct after all ;)

Regards,

Scott



"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c6ggia$1u5a$1 digitaldaemon.com...
....
 MI in C++ is simple: don't do it.

 Except:
  - tag base classes, such as the iterator tags and the like
  - empty base classes, such as STL allocators
  - interfaces (classes/structs composed of pure virtual functions, maybe
static
 functions, and *nothing else*).
....
Apr 26 2004
next sibling parent "Yeric" <NOSPAM NOSPAM.com> writes:
 Don't be too quick to bag MI.  I remember many moons ago using the Borland
 Windows Framework (can't even remember what it's called now; but it beat
MFC
 hands down).
I remember reading about this on Borlands site, I believe it was called OWL ?
Apr 26 2004
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Scott Egan schrieb:
 There were two window types: a MID Child and a Decorated Frame.  I wanted a
 Decorated MDI Child; so I just derived from both and... It worked!
 
 Mind you that's about the only time I remember using MI - maybe you're
 correct after all ;)
Humm. MDI child may be part of single-inheritance hierarchy, decorated frame may be a mix-in? Anyway, the Borland people have foreseen something in their library, and with smart library writers it can be done with single-inheritance and mix-ins as well... Not so sure. After the first step is done, we could think of how to unify a single-root hierarchy and multiple inheritance and stuff - perhaps it will happen almost automatically with template classes... Sather has been smart in the respect: there is no true multiple inheritance (but instead template+interface inheritance), and a single root. It is not true multiple inheritance, because you cannot combine 2 objects at will, since they will invariably collide on the root object methods. Collisions as such can be resolved though, by using a method renaming feature. The language has some interesting solutions. And it's targetted as a high-performance static rapid prototyping lang - which explains the "hackish" way of programming close to Python. -eye
Apr 26 2004
prev sibling parent reply "Larry" <ljr1981 msn.com> writes:
On Saturday, 24 April 2004 at 19:38:59 UTC, Yeric wrote:
 Ok sorry for what might seem to some as obvious, I am a student 
 struggling
 with C++ and looking for a clean implementation of OOP.
You will not be the first or last person to struggle with C++ (or other languages). If you're looking for a "clean" implementation of OOP, then Eiffel will be what you want from that point of view. To understand what leads to that answer, one must define what one means by "clean implementation of OOP." Just because a language states that it is OO does not mean that it is. One must first understand what OO is without a language implementation. Additionally, one must know what OO is not. How is OO different from Procedural or Process Oriented (PO or POP Vs OOP). What about FO (functional oriented or FOP)? When one explores these concepts without language (except perhaps the language of math), then one can draw mostly clear and clean lines to delineate OO from non-OO concepts. Once one can make a clearer delineation of OO from non-OO, then one can examine the implementation of a language and decide which parts are clearly OO, which parts are something else (PO or FO), and which parts are questionable. Based on the above, I can tell you with some confidence that Eiffel was born of discovering OO Theory (OOT) and then letting the language notation fall out of the theory, much like math notation falls out of playing with symbols and notations used to describe math concepts, theories, and so on. Now, has that process been perfect and "pure" (e.g. "clean" as you state above)? It has been quite clear, but certainly not pure or perfect. One example to prove that point is Multiple Inheritance. Yes -- In C++ it is difficult to understand and manage. That is because the notation of the language (its syntax and semantics) get in the way of seeing the applied theory of MI clearly. It is not MI that is the problem, it is the notation that is wrong, confusing, dangerous, and even silly. What you will find (if you take the time) is that Multiple Inheritance as presented in the Eiffel notation is clear, elegant, simple, and we could not live without it. So prevalent is MI in Eiffel that much of the work we do is done easily and quickly using MI and we can model in ways that are impossible to achieve in other language notations.
 Java might seem like
 an obvious choice, but it has flaws like many other so called 
 OOP languages
 Eiffel seems to offer a clean implementation of OOP designed 
 from the ground
 up offering DBC like D, but lacks any real usage or support,
What you say here about Eiffel lacking programmer community usage is true. However, as a manager of an all-Eiffel team for the last 3 1/2 years, I can relate to you how simple it is to train someone to use Eiffel. I have trained all but one of my team. Each of them has come up to being a production ready programmer in about 4 weeks (e.g. 2 weeks of 10-hours-per-day training, followed by 2 weeks of peer-programming mentoring). So, never let "learnability" get in your way. You can learn. With the above said, I would never ask someone to learn Eiffel on their own. Why? Simple multi-part answer: 1. Language-X-gets-in-the-way: Concepts, notations, and other matters learned in other languages get your brain programmed to think in certain ways that are actually contrary to OO Theory and a notation (perhaps Eiffel) being derived from it. This is the reason that so many people get stuck into thinking that OO is well represented in something like Java or C++, when (in fact) it is not. When they pick up Eiffel to learn it and it does not present itself "intuitively" like what they "think" it ought to based on their thought memes constructed from years of Java, then they give up and walk away. 2. Eiffel-documentation-is-not-so-good: Eiffel Software is aware of this painful fact and is working to resolve it. However, what you must know is this: The writers of the Eiffel documentation are writing from the point of view of Academics and European Academics at that. They think differently and approach logical thought processes differently than Americans. That is not to say they are wrong. They are just so different and so out-of-step with how most American programmers think (and their grammar is quite bad) that the communication breaks down. Again, Eiffel Software is painfully aware of this fact and is working to change it as I am writing this. 3. One-plus-Two-equals-no-so-good-Three: If we take the first point, plus the second point, we end up with the mash that is the documentation + the potential programmers + Eiffel-the-language-notation = Not-so-successful. Add to this that the product is quite expensive (unduly so) and one has a recipe for marketplace disaster. And here we have reality is it presently exists. So -- is there any good news? Sure there is! I have muscled through all three of the above. I have de-wired my brain from the thinking patterns of my 20+ years of programming prior to Eiffel. That took about a year for me to start fully "getting it" -- even now, I find myself having to catch myself from going back to my "old habits". I can tell you that after 3 1/2 years of programming exclusively in Eiffel that the language system is a joy. The only thing I miss is not having (yet) a bunch of libraries for things like making cool websites and mobile phone apps. However, for building industrial strength desktop systems, I would use nothing else. By the way -- the web and mobile stuff is coming. The fine folks at Eiffel Software are working to bring these libraries to market as I write this. The other good news is that when I have a chance to show people Eiffel, when they see it in the hands of someone who knows what they are doing, they fall in love with it. So, if your like me: You look for opportunities to use it and then you pounce on it -- that is -- quit following the "herd" doing Java and C++, .Net and others, and pick up your own mind and do what you study about, research about, and see at the right thing to do. That has led me to building an Eiffel team and having a fun and exciting time building outstanding software.
 D is just

 similar benefits,
 andclaim to offer speeds comparible to C/C++, I unfortunately 
 do not have
 time to read through pages of documentation to decide what to 
 use and what
 not to use, I was just about conviced about Eiffel when a 
 friend said have
 you looked at D?
I hope you will go back with words of encouragement to pick up Eiffel again. Since 2004, the language notation and tools, the method and environment have improved greatly. Not only is there all of what we had in 04', but there is more: SCOOP (Simple Concurrent Object Oriented Programming -- Yes, Eiffel has threads, but in a way you will find nowhere else). Void-safety: You don't have to program in C/C++ very long to learn about the dangers of making a call on an object only to find out that its pointer is Void and non-callable! In Eiffel, Void-safety provides a static and compiler-based means of "proving" that your code is free of any void calls -- EVER! We have been working with that technology since the beginning and I would never write software any other way!
  No I replied what is D ?
 I was given www.digitalmars.com and said read up on it.

 I started to read, thought this looks interesting, infact looks 
 very similar
 to Eiffel in concept, but offers the opportunity to code like a 
 C/C++
 programmer just more cleanly. but since I have not learnt C/C++ 
 properly it
 would not matter too much to learn a different syntax,
Actually, D is not like Eiffel except that it tosses around some words and phrases that seem to correspond to Eiffel. What D really looks like is another Java -- that is -- C/C++ reworked and repackaged based on what someone sees "wrong" in C/C++, with their own notion of some "borrowed" concepts from other languages, like Eiffel. This can be seen in how D implements Eiffel's Design-by-Contract (TM). For example: There is a missing contract: The loop invariant. D does not have them. What that means is that when one has some form of loop, there are conditions that may be defined, which (when once defined) must hold true with each iteration of the loop. The fact that this contract is missing indicates that the makers of the D language and compiler may not understand Design-by-Contract as well as they might. Those missing parts actually are quite meaningful in the day-to-day business of designing, writing, testing, deploying, and supporting code.
 Eiffel offers what
 might seem to some a very simple syntax, and comparing to some 
 C/C++
 programs very fast, but then again so does D,
I can tell you with great pride how wonderful Eiffel syntax and readability is! Moreover, I can also tell you another clue that D is simply another "Java" is the presence of syntactical sugar -- that is -- curly braces and semi-colons. From the point of view of a compiler designer, such things are not needed. They are sugar. The compiler can figure out where one line ends and another begins without semi-colons. Moreover, curly-brace hell is not something you have to deal with because of some notation-need of the compiler. It was introduced by a human being who thought it would be a nice way to delimit things. It turns out that this choice was non-optimal and has caused a great deal of angst among people having to live with curly-brace-hell for decades. There are empirical studies showing that Eiffel codes about 25% faster than its C/C++ counter parts. That is true for Java as well. This is somewhat due to notation and syntax, but also to other important issues like MI, Generics, Agents, and various forms of loops constructs, and other matters as well. Personally, I get dizzy when reading the Reversed-polish-notation of C/C++ or Java. In contrast, modern Eiffel (2014+) reads simply and quickly once one is mentally deprogrammed from other notations. D seems to offer
 a syntax
 similar to C/C++ to entice these programmers, but what else can 
 it offer, I
 notice there is DIDE which looks really cool but like Eifel it 
 is a shame
 there is no windows level gui editor like in VB,
It turns out that there is little need for a "Visual Builder" and that such things actually cause serious limits in terms of what can be built when one starts considering inheritance and complex designs of GUI systems. Most folks question that, but after 3 1/2 years, I can tell you that I do not miss visual GUI builders at all. Nevertheless, with that stated, I will state another thing: In time, I do see the possibility of created a visual builder for Eiffel that knows how to read and recognize Eiffel code, handle the inheritance bits in it, and present a GUI representation of what it sees, at least as well as something like .NET or XAML. However, that will never replace the power and simplicity of just working with the code. At the end of the day, the program does not run in a visual builder, but as an actual program. When one learns how to read the code, especially Eiffel and Vision2 library code, one finds out that having a visual builder offers very little in real programming power (e.g. it's enough to get you started, but gives very little long-term value otherwise).
 and what about support for
 OLE DB or OpenGL, what support can D offer for database access 
 like VB ( a
 horrible language I know ) or for the games programmer, I think 
 I understand
 it is like C but since I have not learhnt C will it be hard to 
 pick up?
This is where we must talk about libraries. It is both a strength and a weakness for Eiffel. The libraries Eiffel does have are quite good, well-oiled, well-exercised, dependable, reliable, and trustworthy. They cover a lot of ground. Libraries like BOOST for example offer a lot and Eiffel libraries cover much of the same core ground. However, there are places that Eiffel has not gone and I am not entirely sure why. The web-related and mobile phone app related libraries are two of the most glaring. Another is some form of reporting library. We are having to build this for ourselves and we may or may not release that library into GPL, and perhaps as a for-sale library, but that is yet to be seen as the library is still under construction. One of the strengths of Eiffel in the realm of C (not C++) is that we have a GPL program called C2Eif, which converts a C code set into pure Eiffel without error (that is well-tested at this point). Even C2Eif is a work-in-progress, where one of the next steps is to take very process oriented code in C, and logically figure out decent looking object oriented classes from the C. You can find this work by simply Googling C2Eif. Still, what is clearly missing from the library mix are what I like to call "RAD" (Rapid Application Development) libraries. So, one will not find an Eiffel library that has a MOVER class in it. I have personally taken up the challenge of writing some of these higher level libraries, but we shall see what time I have, as I am pretty stretched already. Still -- I am following along with an excellent book called "Designing Interfaces", which offers detailed Use-case-like comprehensive list of descriptions for the modern forms of controls. The net result (I hope) will be an Eiffel library of classes that one can use to quickly construct such complex GUI bits for desktop programs. What is needed together with the RAD library set is some of the high level "glue code" below the GUI. Things like Pub-sub libraries, data-binding, state-management, and high-level persistence libraries to handle database access. Speaking of databases, Eiffel Store is a library that ships with Eiffel Studio that handles many databases and access to them. In particular, we use ODBC to access. I do know that it is quite simple to build access to other databases using C/C++ wrappers so that one can access the APIs to those databases cleanly and effortlessly. As a matter of fact, you will find a C2Eif generated version of the MongoDB driver that works quite well.
 does
 D model a true OOP language or is it yet another hybrid C ?

 You thoughts are welcome in anticipation
 Yeric
The purpose of writing this is not the "bash" D. It is simply to inform. Reading the on-line documentation about D and reviewing some of the tutorial pages, I do get the distinct impression that D is another attempt to "correct" someones opinion about the "bad things" in C, yet trying to keep something C-like about it as a point of attraction to get people to start using the language. Also, this is not to say that there are not people using D and building software with it. I do not know. People make choices every day. What I can say is that choosing a language because it "looks like" it is "better", but does not back all the way up to the theory it purports to be "based on" (e.g. Object Oriented Theory) is a dead give-away that it is not what it claims. While Eiffel is not perfect by any stretch, after 24+ years of looking about, I can say that Eiffel is the only language I have ever found that started as a study of the theory, where the notation fell out of the theory instead of a repackaging and rebranding of an existing language with someones juvenile or ill-thought attempt at their version of OOT --> OOP. I hope something in all of this helps.
Mar 27 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
Larry:

This newsgroup is closed, better to discuss in the active 
newsgroups.


 This is the reason that so many people get stuck into thinking 
 that OO is well represented in something like Java or C++, when 
 (in fact) it is not.
what those languages do. This is one of the reasons why they are trying to push Java-style OO inside Javascript in all ways.
 What D really looks like is another Java
You can write D programs that look a lot like Java, or a lot like like C, similar to C++ or Python, or sometimes even Haskell. You can adapt it to different needs, or different brains.
 The fact that this contract is missing indicates that the 
 makers of the D language and compiler may not understand 
 Design-by-Contract as well as they might.
Walter understands DbC well enough, despite some DbC features are not present in D. You don't need to implement something at 100% for it to be useful.
 There is a missing contract: The loop invariant.
I have asked for a loop invariant in D. A possible syntax for the loop invariant (the invariant keyword is already present, and used for class/struct invariants): foreach (i; 0 .. 10) { invariant { ... } } This is a purely additive change, this means it's easy to add this missing feature to D if D developers want. But BbC doesn't seem to be a very used and very popular feature of D, so I guess there is not a lot of interested in completing the D DbC. In Bugzilla there are some DbC-related bugs, like ones related to interface contracts, etc.
 Those missing parts actually are quite meaningful in the 
 day-to-day business of designing, writing, testing, deploying, 
 and supporting code.
Loop invariants are important in computer science, but from what I have seen they are not very important for most D code for most programmers. I agree that adding a feature could push some people into using it, but you need first some interest to add a feature. The DbC part I miss most in D is the pre-state (old), it was asked several times in the forum. But it's not easy to implement well in D. Bye, bearophile
Mar 28 2014