We probably agree on almost everything - especially at the level of programming language comparisons (except the matter of typing which is beyond the pale- the supposed benefits are totally illusory, IMHO, for a variety of reasons).
For me, design is everything and a programming language is judged almost exclusively on how easy it is to directly express the design. (A secondary consideration is the ease with which the language allows iterative and exploratory development which excludes all compiled languages.) As for where the designs come from - mostly observation and adherence to a few heuristics - almost all of which were espoused by (but not necessarily followed by) the early proponents of OO. Some example of how object designs differ: If you are writing software for a vending machine - money arithmetic belongs with the money object not an accumulator or a counter object, if you are writing software to operate a brewery, design should proceed from the point of view of the beer seeking to leave a vat and enter a mouth instead of the perspective of the "control room" monitoring the bottling line, if you are writing mathematica, your design should be based on expressions that know how to modify and solve themselves (self evaluating rules is the generic design) instead of any form of "calculator" object. You can sometimes tell if your design is OO by looking to see if you have certain structures in your code: case statements for example will not exist (or be needed) if your design was OO, loops will never be explicitly coded (instead you will send messages like "do" and "select" to collection objects, and, if you are using an interpreted VM based language, your code should be modifiable at run time - no need to "bring it back to the shop" for modification, recompilation, relinking, and re-distribution. Russel -- if you would like to chat about design off-line where we do not bore the others -- please email me. You can give me a problem, I will give you an OO design, and we can discuss its problems or merits. davew On Mon, 6 Aug 2007 15:29:28 +1000, "Russell Standish" <[EMAIL PROTECTED]> said: > On Mon, Aug 06, 2007 at 11:06:58AM -0400, Prof David West wrote: > > > > If pressed into a corner, I would say that C++ is not an OO language at > > all - because the philosophy behind its creation is antithetical in > > important ways to the IDEA of objects. Examples: > > .... > > > > > > > The object idea is fundamentally dependent on the concept that > > EVERYTHING is an Object - and any language that enforces strong > > typing violates this principle. > > > > Which appears to reinforce the statement I made that C++ is not _just_ > and OO language. One can program C++ where every type used is derived > from a polymorphic base object in the way that you mention. But strong > typing is an important defence mechanism against bugs, so it would be > silly to actually program C++ in such a way. > > > Having said that - I would admit that C++ is indeed a Turing machine and > > is therefore, at its core, cannot be differentiated from any other > > programming language and that it does provide some constructs that allow > > a developer to construct objects (classes) and do object-like coding - > > but doing so is very unnatural, uncomfortable, and "feels wrong." > > > > This sounds like a C programmer talking! > > > The idea of objects leads one to very different analytical (mostly > > decomposition) and design solutions than procedural or data-based > > thinking. Given an object design it is very difficult to express that > > design in C++ and trivial to express that design in Smalltalk. (Ruby > > makes it easy to express the idea but does make it a bit more difficult, > > but only because you have to ignore some non-relevant aspects of the > > language.) Lisp - with CLOS, Flavors and similar extensions -also > > makes it easier to express object design. > > > > Where do these object designs come from? I get given problems (solve > x, y and z). Its up to me to provice the solution, and I usually do it > directly in C++, occasionally with a hand-drawn picture to see how > chunks fit together. > > > > > > But I would still say that C++ gives me the ability to build more > > > complex code, more efficiently, in about a similar or even reduced > > > development time to other competitive languages. I couldn't give a fig > > > whether it follows a pure OO model or not. > > > > > > > I would be willing to bet that an individual proficient in Smalltalk to > > the same degree as you are in C++ could develop almost any piece of > > software in 1/3 to 1/5 the time it took the C++ team, and with some > > minor tricks make it run in as small or smaller a footprint with an > > equal or lesser number of machine cycles. I have consistently seen it > > done. > > > > davew > > That wasn't exactly the point I was making - I was referring to myself > choosing a language for a task given my already extensive experience > in C++. It does give a "lock-in" advantage to the language. I also had > in mind the supposed C++ replacements, ie Java and C#, rather than say > Smalltalk or Ruby. > > I am not a 1 language shop. I do use Perl for some tasks, as it > sometimes is quicker to get stuff done in a rich, interpretive > environment. I use TCL for mostly GUI type work, and I'm thinking that > Java probably has significant advantages over TCL for GUI stuff. > > Cheers > > -- > > ---------------------------------------------------------------------------- > A/Prof Russell Standish Phone 0425 253119 (mobile) > Mathematics > UNSW SYDNEY 2052 [EMAIL PROTECTED] > Australia http://www.hpcoders.com.au > ---------------------------------------------------------------------------- > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
