dcmartin@cheddar.cs.wisc.edu (David C. Martin) (11/11/88)
In article <5155@thorin.cs.unc.edu> (Dr. James Coggins) writes: >Now for the leap... > >4. The Smalltalk-like languages will be the better tools for large >software development because item #1 above will kick in to make the >project more manageable. > >Opinions? I have been reading this newgroup for sometime and with this posting finally saw something with which I agreed. To make things clear, I am an experienced C, LISP and CLOS programmer and am now attempting to master C++. One of the things which I first noted about C++ was that it was not a true OO language like CLOS since it did not have a class lattice or the ability to have objects change w/ the changes in the definitions of their superclasses. This latter lack can be attributed to the lack of a run-time system supporting such modifications. In essence, C++ appears to be an ADT language w/ some support for OO-like inheritence, but that is about it. As for managing projects, I can't really say whether any non-interactive, non-dynamic system could *ever* compete w/ something like SmallTalk or CLOS. There are several features of OO languages which C++ does not provide (e.g. metaclasses) which are incredibly important for doing things like building architecture dependent types (e.g. Casey Leedom's Connection Machine integers). In addition, there is currently no way to build things like browsers w/o writing code to support the currently internal definitions in an external format (e.g. attributes = attributes(classof(object))). However, I *like* C++ for building ADTs! Perhaps, someday, I will even use C++ to build a real OOPS. dcm ----- David C. Martin arpa: dcmartin@cs.wisc.edu University of Wisconsin - Madison uucp: ..!ucbvax!dcmartin Computer Sciences Department at&t: 608/262-6624 (O)
coggins@pooh.cs.unc.edu (Dr. James Coggins) (11/12/88)
In article <6639@spool.cs.wisc.edu> dcmartin@cheddar.cs.wisc.edu (David C. Martin) writes: >In article <5155@thorin.cs.unc.edu> (Dr. James Coggins) writes: > >>Now for the leap... >> >>4. The Smalltalk-like languages will be the better tools for large >>software development because item #1 above will kick in to make the >>project more manageable. >> >>Opinions? > >I have been reading this newgroup for sometime and with this posting >finally saw something with which I agreed. Good. (But note that in this discussion I'm not "selling" anything - I'm really trolling for ideas.) >In essence, >C++ appears to be an ADT language w/ some support for OO-like inheritence, >but that is about it. > >However, I *like* C++ for building ADTs! Perhaps, someday, I will even >use C++ to build a real OOPS. This is an interesting comment since the (in-person) discussion that led to my original posting arrived at a concensus that C++ classes are NOT ADTs and that Smalltalk classes are closer to ADTs. (an ADT consists of data, procedures, and axioms that define consistent states of the structure. Most discussions and all implementations forget about the axioms.) More specifically, my colleague's assertion was that the ABSTRACTION in the ADT is in Smalltalk-like OO languages more thoroughly divorced from implementation than in Simula-like languages. That is, a C++ class is intimately bound to its implementation, therefore in order to reuse any code between projects and people, the reuser must buy into the abstraction produced by the author AND into the implementation and realization baggage the author produced. It is the latter stuff that kills most potential opportunities for extensive, small-granularity code reuse. His assertion was that the increased independence between specification and implementation available in Smalltalk-like OO languages would yield greater benefits in very large systems because the reuser could switch implementation/realizations more easily if required. Maybe we see here the beginning of a new paradigm that will be the "structured programming of the '90's" as OOP is the "SP of the '80's"? --------------------------------------------------------------------- Dr. James M. Coggins coggins@cs.unc.edu Computer Science Department "Make it in Massachusetts" - ad slogan UNC-Chapel Hill "I made it OUT of Massachusetts" Chapel Hill, NC 27514-3175 - my slogan ---------------------------------------------------------------------
johna@cognos.uucp (John C. Anderson) (11/15/88)
In article <5263@thorin.cs.unc.edu> coggins@cs.unc.edu (Dr. James Coggins) writes: >In article <6639@spool.cs.wisc.edu> dcmartin@cheddar.cs.wisc.edu (David C. Martin) writes: >>In article <5155@thorin.cs.unc.edu> (Dr. James Coggins) writes: > >(an ADT consists of data, procedures, and axioms that define consistent >states of the structure. Most discussions and all implementations forget >about the axioms.) ^^^ Try Eiffel. Eiffel routines can have REQUIRE/ENSURE clauses (pre/post-conditions), and the classes themselves can have INVARIANTs. We use these to do exactly what you mentioned, ie define consistent states of a structure. Seems to work quite well. -- John Anderson, Cognos Incorporated, P.O. Box 9707, 3755 Riverside Drive, Ottawa, Ontario, CANADA K1G 3Z4 (613) 738-1440 decvax!utzoo!dciem!nrcaer!cognos!johna
jss@hector.UUCP (Jerry Schwarz) (11/15/88)
In article <5263@thorin.cs.unc.edu> coggins@cs.unc.edu (Dr. James Coggins) writes: > >This is an interesting comment since the (in-person) discussion that >led to my original posting arrived at a concensus that C++ classes are >NOT ADTs and that Smalltalk classes are closer to ADTs. > >(an ADT consists of data, procedures, and axioms that define consistent >states of the structure. Most discussions and all implementations forget >about the axioms.) > I do not think this is a correct description of Abstract Data Types. The usual presentations of ADT involve axioms (commonly in the form of equations) that say something about the abstract values and do not refer to the internal state of data structures. There will also be some way of relating the "concrete" representation to the "abstract" value being represented. The aspect that most clearly distinguishes ADT from OO is that using an ADT approach one does not define operations that modify the state of a value. (It makes no more sense to modify the state of an abstract value than it does to modify the number 2.) For the record, I believe both ADT and OO, (and some other programming frameworks I won't name here) are each appropriate for certain problems. One of the attractive aspects of C++ is that it allows a wide variety of approaches to be used efficiently. Jerry Schwarz AT&T Bell Labs, Murray Hill