April 26, 2004
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*).
....


April 26, 2004
> 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 ?



April 26, 2004
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
March 28, 2014
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
> starting out as a new language like C# all seem to offer 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.
March 28, 2014
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.

People use Java, C++, C#. So what "OO" means gets redefined by 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
1 2 3
Next ›   Last »