gbt@sequoia.cray.com (Greg Titus) (05/31/91)
In article <1991May30.004144.24252@netcom.COM> jls@netcom.COM (Jim Showalter) writes: > [Somebody else writes:] >>I won't argue the point that Ada is far superior when it comes to large system >>development. This is a fact, plain and simple, and C++ cannot hold a candle >>to Ada's abilities to decompose a problem into managable pieces and insure >>the consistency between them. However, Ada is not all things to all programming >>tasks, and one of the things it isn't is an object oriented programming >>language. > >From the above paragraph, we have these two statements: > >1) Ada is a superior language for engineering large complex systems. >2) Ada is not particularly supportive of OOP. > >These two statements lead to the following conclusion: > >3) OOP is largely irrelevant when it comes to engineering large complex systems. > >Now, far be it from me to actually MAKE this claim [;-)], I'm merely >pointing out that it is the inevitable subtext of the above paragraph. I don't see that, Jim. I'd replace your 3) with "Ada is not the best language when it comes to engineering large complex OO systems." (Replace "not the best language" with "largely irrelevant" if you want to retain the strength of your original conclusion.) My own feeling is that we simply don't *have* a true object-oriented language that is also appropriate for large systems. Might be a neat thing to work on, though ... greg -- -------------------------------------------------------------- Greg Titus (gbt@zia.cray.com) Compiler Group (Ada) Cray Research, Inc. Santa Fe, NM Opinions expressed herein (such as they are) are purely my own.
jls@netcom.COM (Jim Showalter) (06/01/91)
Our story thus far: >>>I won't argue the point that Ada is far superior when it comes to large system >>>development. This is a fact, plain and simple, and C++ cannot hold a candle >>>to Ada's abilities to decompose a problem into managable pieces and insure >>>the consistency between them. However, Ada is not all things to all programming >>>tasks, and one of the things it isn't is an object oriented programming >>>language. >> >>From the above paragraph, we have these two statements: >> >>1) Ada is a superior language for engineering large complex systems. >>2) Ada is not particularly supportive of OOP. >> >>These two statements lead to the following conclusion: >> >>3) OOP is largely irrelevant when it comes to engineering large complex systems. >I don't see that, Jim. I'd replace your 3) with "Ada is not the best >language when it comes to engineering large complex OO systems." >(Replace "not the best language" with "largely irrelevant" if you want >to retain the strength of your original conclusion.) Well, I may have overstated the case. Taking a page from the Get Smart show, WOULD YOU BELIEVE: "3) OOP _may_ be largely irrelevant when it comes to engineering large complex systems."? I think I can support this one pretty easily: we have already established from 1) above that Ada is a superior language for engineering large complex systems, and from 2) we admit that Ada is not an OOP language [at least not in the classic sense of the term], and so we have the apparent paradox of large complex systems being superiorly engineered using a non-OOP language. This certainly makes ME suspect that OOP must not be particularly important when it comes to engineering large complex systems. >My own feeling is that we simply don't *have* a true object-oriented >language that is also appropriate for large systems. Ah, okay--this changes things considerably. What you (I THINK) are claiming is that IF there were a true object-oriented language that was also appropriate for engineering large systems, then it would be a better tool to use for such engineering than Ada but that, in the absence of such a beast, Ada wins by default. Or am I completely lost (wouldn't be the first time...). >Might be a neat >thing to work on, though ... You could ask the Ada 9x people how neat they think things have been for them. ;-) -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
gbt@sequoia.cray.com (Greg Titus) (06/04/91)
In article <1991Jun1.044011.29894@netcom.COM> jls@netcom.COM (Jim Showalter) writes: > > ... [a lot of stuff we've all seen already] > >Well, I may have overstated the case. Taking a page from the Get Smart >show, WOULD YOU BELIEVE: "3) OOP _may_ be largely irrelevant when it comes >to engineering large complex systems."? ... You betcha. > > [I (gbt) said] >>My own feeling is that we simply don't *have* a true object-oriented >>language that is also appropriate for large systems. > >Ah, okay--this changes things considerably. What you (I THINK) are >claiming is that IF there were a true object-oriented language that was also >appropriate for engineering large systems, then it would be a better >tool to use for such engineering than Ada but that, in the absence of >such a beast, Ada wins by default. Or am I completely lost (wouldn't >be the first time...). That's it exactly. The usefulness of a language for large systems is based on its ability to represent a relatively clean homomorphism of the designer's favorite decomposition of the data structures and activities in the solution. The decomposition is the primary thing. The question of whether the objects or the activites are more important is far less important, to my mind. > >>Might be a neat >>thing to work on, though ... > >You could ask the Ada 9x people how neat they think things have been >for them. ;-) Perhaps I should have emphasized the "might". ;-) They are somewhat constrained, I'm afraid. greg -- -------------------------------------------------------------- Greg Titus (gbt@zia.cray.com) Compiler Group (Ada) Cray Research, Inc. Santa Fe, NM Opinions expressed herein (such as they are) are purely my own.
dlindsle@afit.af.mil (David T. Lindsley) (06/05/91)
Ada is not an OOPL in the classic sense, no. But Ada does allow and
in fact encourage object-oriented _design_. Encapsulation (packages),
information hiding (private types), etc., are part of OOD (and OOPLs).
In other words, many of the things that make Ada suitable for working
with/on large, complex systems are those object-oriented techniques which
the language _does_ support. Given this, I find the statement that OO
(analysis? design? programming? all three?) are "largely irrelevant"
to the development of large, complex systems somewhat hard to swallow.
This doesn't mean that I believe C++ or Smalltalk (or any of the other
OOPLs) to be superior to Ada in the production of large systems. The
final word on OO{whatever} isn't in yet (IMHO) -- I await the judgment
of history on that score...
--
Dave Lindsley #24601# OPINIONS. MINE.
dlindsle@blackbird.afit.af.mil (The words don't come no smaller.)
?? lamroN eb yhW ??jls@netcom.COM (Jim Showalter) (06/05/91)
>Ada is not an OOPL in the classic sense, no. But Ada does allow and >in fact encourage object-oriented _design_. Encapsulation (packages), >information hiding (private types), etc., are part of OOD (and OOPLs). >In other words, many of the things that make Ada suitable for working >with/on large, complex systems are those object-oriented techniques which >the language _does_ support. Given this, I find the statement that OO >(analysis? design? programming? all three?) are "largely irrelevant" >to the development of large, complex systems somewhat hard to swallow. My comment was that the so-called "pure" OO might well be largely irrelevant to such systems. Pure OO encompasses, by what I THINK is the general definition, not just encapsulation and information hiding but messages/methods, polymorphism, dynamic binding, and inheritance. Considering that Ada supports none of these well and yet supports the engineering of large complex systems quite well, the argument that pure OO may be largely irrelevant to the construction of such systems seems valid. I'm STILL waiting for someone who has actually completed a large complex system using pure OO to speak up. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
larryc@puente.jpl.nasa.gov (Larry Carroll) (06/06/91)
The most impressive aspect of C++, as reported by a group of programmers (most of them Fortran & C users) here who were forced to learn & use it for a task last year, was inheritance. With careful attention to design, they were able to re-use a lot of their own code, & re-design it quickly when needed.
baker@csl.dl.nec.com (Larry Baker) (06/06/91)
larryc@puente.jpl.nasa.gov (Larry Carroll) writes: |> The most impressive aspect of C++, as reported by a group of programmers |> (most of them Fortran & C users) here who were forced to learn & use it for a |> task last year, was inheritance. With careful attention to design, they |> were able to re-use a lot of their own code, & re-design it quickly when |> needed. We use C++, and there are several people here (myself included) with Ada backgrounds, who would add to the above observation: Dynamic Binding has, for us, been a very significant added benefit. The combination of DB and Inheritance is a very, very powerful mechanism. -- Larry Baker NEC America C&C Software Laboratories, Irving (near Dallas), TX baker@csl.dl.nec.com cs.utexas.edu!necssd!baker
knoll@coopn1.csc.ti.com (Ed Knoll @(719)593-5182) (06/06/91)
I'm starting to find this thread a little bit tedious, mainly because of some of the poorly constructed arguements. Let's line up some of the basic premises. 1) Some people believe Ada to be more OO than not. 2) Some people believe that there are attributes to "true" OO that are not encompassed by Ada. 3) Some people feel that Ada is good for large system development. 4) Some people feel that C/C++ is not as good for large system development. From what I have observed personally and absorbed via second sources, I will group myself in the "Some people" camps. The two competing arguements that have been lined up are that: a) Ada should adopt some of the other attributes that make a "true" OO, b) there is not a demonstrated need to adopt these other conventions. I won't try to debate either of two arguements above, however, I will debate the validity of the following arguement. > My comment was that the so-called "pure" OO might well be largely > irrelevant to such systems. Pure OO encompasses, by what I THINK is > the general definition, not just encapsulation and information hiding > but messages/methods, polymorphism, dynamic binding, and inheritance. > Considering that Ada supports none of these well and yet supports > the engineering of large complex systems quite well, the argument that > pure OO may be largely irrelevant to the construction of such systems > seems valid. 1) Just because Ada currently supports large systems development well, does not mean that it can't support that activity better. 2) The reason that Ada is better suited to large systems development than C++ is due to the physical manisfestation in Ada of many attributes of good software design practices. This is an arguement against those lacks in C++; this is not a valid arguement against the ineffectiveness of the other OO attributes (i.e polymorphism, dynamic binding, etc...). I not arguing for or against the other OO extensions to Ada. It will always be easier to "adopt" new features than to "remove" poor ones because of the backwards compatability problems, therefore, I think all extensions should be well considered (which seems to be the case). However, we shouldn't try to argue against the OO extensions because C++ doesn't seem to have exhibited success in large systems development when we also argue that large systems development is outside of the reasonable problem domain for the C/C++ language. It might help if those who advocate those extensions will also supply the arguements (or references to same) for why those features are desirable. Edward L. Knoll Texas Instruments knoll@coopn1.csc.ti.com
jls@netcom.COM (Jim Showalter) (06/07/91)
Overall, a nice cogent post. I have a few quibbles (don't I always?): >1) Just because Ada currently supports large systems development well, does not > mean that it can't support that activity better. Agreed. However, I have not seen any compelling argument(s) to the effect that, if Ada supported "pure" OO, it would support development of large complex systems any better than it does now. I HAVE heard a lot of quasi- religious tub-thumping for pure OO as a miracle cure-all for what ails software development organizations, but I've seen precious little hard data in its favor, and precious few success stories. Mind you, I'm not predisposed to reject pure OO as a valid software engineering paradigm--I actually find the model rather pleasing from an aesthetic standpoint--but I DO think it's fair to ask what proof there is that pure OO is anything more than a research toy and/or snake oil du jour that sells compilers and introductory texts but produces few if any demonstrable results. I have buckets full of success stories for Ada in large complex systems: I am STILL waiting to hear success stories for pure OO on similar systems (and no, 20K programming-in-the-small efforts don't count). >However, we shouldn't try to argue against the OO extensions because C++ >doesn't seem to have exhibited success in large systems development when >we also argue that large systems development is outside of the reasonable >problem domain for the C/C++ language. Speak for yourself--there are plenty of people arguing that C++ IS suited for the development of large complex systems. Some even make that claim for C. >It might help if those who advocate those extensions will also supply the >arguements (or references to same) for why those features are desirable. Indeed. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
eachus@largo.mitre.org (Robert I. Eachus) (06/12/91)
In article <1991Jun04.185632.18204@afit.af.mil> dlindsle@afit.af.mil (David T. Lindsley) writes:
Ada is not an OOPL in the classic sense, no. But Ada does allow and
in fact encourage object-oriented _design_. Encapsulation (packages),
information hiding (private types), etc., are part of OOD (and OOPLs)...
Hmmm. In Ada you can (and most software engineers do) use OO
DESIGN methods. However, the properties of the language are such that
it is very difficult to modify data abstractions in unintended ways.
In the AI field, I have seen lots of Smalltalk, LISP, Scheme, LOOPS,
etc. systems which, like Topsy, just growed. The lack of information
hiding and isolation of abstractions makes violations of any original
design easy in most "pure" OO PROGRAMMING environments. And in most
of the OOP systems I have seen not only are these violations notable
by their presence, they make any maintenance a nightmare.
I think that the ability we have to hide data abstractions in Ada
is precious, and any attempt to break that barrier to permit "pure"
OO programming in Ada is misguided.
(Flame Retardant: I am very much in favor of OO extensions in
Ada 9X, we just need to be very careful not to break more important
Ada properties.)
--
Robert I. Eachus
with STANDARD_DISCLAIMER;
use STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...