Path: utzoo!attcan!uunet!kddlab!titcca!sragwa!wsgw!socslgw!riks From: riks@csl.sony.JUNET (Rik Smoody) Newsgroups: comp.lang.smalltalk Subject: Re: Smalltalk versus C++ Keywords: object-oriented languages Message-ID: <10099@socslgw.csl.sony.JUNET> Date: 9 Jan 89 05:31:47 GMT References: <447@ubbpc.UUCP> <824@laura.UUCP> <451@ubbpc.UUCP> Reply-To: riks@socslgw.csl.sony.JUNET (Rik Smoody) Organization: Sony Computer Science Laboratories, Inc., Tokyo, Japan. Lines: 97 In article <451@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: > This is interesting, but not exactly the _type_ of answer I was looking for. >It seems to me that you may be using dynamic classes because they are _there_, >not because you really need them. Could your applications be written using >statically declared classes? Are dynamic classes necessary for application >development in a structured "software engineering" sort of way, or just handy >for improvising programs at the terminal? Not the *type*??? It's an ascii string, isn't it? (I couldn't resist 8-) Is there something wrong with using what's there? On can write any program at all on a turing machine... I guess we use all this other stuff because it's there. Good thing, too. You ever try to READ a turing machine program that does anything significant? >> > C data types differently from programmer-defined objects; >> This feature is essentially used, too. E.g. it enables to introduce new >> kinds of Numbers (like complex) you can handle like ordinary numbers. You need >> no change of Matrix inversion algorithm after introducing Complex. > > Is this literally true? What about checking values for "close to zero" >in pivoting? Complex numbers are not well-ordered, so you probably want to >check if the magnitude of the number is close to zero. Gee, what a stickler for details.... I can easily imagine a well-done implementation where an element is asked for it's magnitude... and of course a complex number has to answer appropriately, as does a real, as does... If not, of course, it's a mistake. One can write programs with mistakes. > >> >(3) Smalltalk has multiple inheritance, but C++ does not yet (soon ... >> We never used this. Multiple Inheritance leads to much more complex systems >> and mostly can be avoided by distinguishing usage ("has") from inheritance >> ("is)"). Multiple inheritance (MI) can be implemented poorly, and used badly. This is NOT equivalent to saying it is necessarily complex. I think the opposite. For example, I belong to all of the following "classes": hiker, ballroom dancer, folk dancer, computer scientist, college graduate, barbershop singer, skier, kayaker, Smalltalk user, husband, Japanese student, human, ... My friend PaulS belongs to hiker, folk dancer, computer scientist, college graduate, skier, kayaker, bus driver, courting man. Another friend, PaulM belongs at least to ballroom dancer, folk dancer, computer scientist, college graduate, Smalltalk user, company president. We are not that complex. Suppose that you wish to implement a system which can model our behavior in various situations. As you can see, there is no strict tree ordering on the classes. One could impose some partial order (at least based on the above cases alone) and say that all folk dancers are college graduates. One could even implement my class by starting with PaulS's, cutting out some methods and adding some others. This sort of approach has lead us to the Smalltalk image as many of us know it: some classes inherit properties in strange ways. It was not designed around MI, but had MI tacked on later. It does not have to be that way. That is how the image IS, not how it must theoretically be. > Aha! Thanks. (Gee, it seems like you knew what answer you wanted to see....) >> >(4) Smalltalk may be designed in a way such that it has built-in overhead, >> > and it may never be possible to make Smalltalk programs run as fast as >> > C++ on present-day machine architectures (not sure about this ... I think most of us really don't care (even if we don't admit it). I spend very little time waiting for a balls-out process to finish. I spend a lot off time reading: programs, mail, documents (some in Japanese even... I spend a LOT of time at those). I spend more time trying to understand systems so I can change them or cooperate with them than I do waiting for a matrix to invert. I care about how obscure a "finished" system is. I don't much care if it is slow, unless it is very slow. I care if I cannot "fix" things to my preferences, or if the overhead is prohibitive (That is, will it be "better" next time, or will it be backward, er, backward compatible out of laziness) Is it different from saying that there is overhead in using C++ over using assembler? I fear that software will never even get onto a parallel curve with hardware if we keep worrying about issues of small impact. In the mid '70s, an IBM370 was a big cumputer, and C was an interesting programming language. You still insist on C compatibility, but how excited would you be to hear of a board to plug into your 370? You can't go somewhere new unless you leave where you are. Rik Fischer Smoody bN v XSony Computer Science Lab, Inc. \j[ Rs^ TCGX $ 3-14-13 Higashigotanda \=c3[14[13 Shinagawa-ku il f Tokyo 141 Japan '141 phone: (03)448-4380 db E-mail: riks@csl.sony.jp -- Rik Gyofu Smoody Sony Computer Science Lab, Inc., 3-14-13 Higashigotanda Shinagawa-ku, Tokyo 141 Japan (03)448-4380