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