wgh@ubbpc.UUCP (William G. Hutchison) (01/04/89)
I am currently learning C++ and I have read about Smalltalk, but have not
used it. I have seen some disparaging remarks about C++ from some Smalltalk
gurus (or self-appointed experts) here.
I was wondering what the real differences between the two languages are,
and whether they are important.
From my reading, it appears that
(1) Smalltalk can create classes dynamically, whereas C++ does it at
compile time;
(2) In Smalltalk "everything is an object" whereas C++ treats the traditional
C data types differently from programmer-defined objects;
(3) Smalltalk has multiple inheritance, but C++ does not yet (shortly, I am
informed);
(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, so I
thought I would ask).
To summarize, Smalltalk seems to have goodies that C++ lacks, but, since I
am new to object-oriented programming, I do not perceive the need for these
goodies. Would some experienced Smalltalk programmers comment on how they
actually USE these non-C++ features? Saying that these features are nifty
in the abstract is not the same as actually using them day-to-day.
--
Bill Hutchison, DP Consultant rutgers!liberty!burdvax!ubbpc!wgh
Unisys UNIX Portation Center
P.O. Box 500, M.S. B121 "The unexamined life is not worth living!"
Blue Bell, PA 19424 -- Educational Testing Service, Princeton, NJjohnson@p.cs.uiuc.edu (01/05/89)
This is in response to the message by wgh@ubbpc.UUCP asking about the differences between C++ and Smalltalk. I use both, so I'll comment. I program the same way in each, so I believe that at a high enough level of abstraction all object-oriented programming languages are the same. Of course, that level of abstraction is so high as to make everything below look fuzzy. The Smalltalk programming environment is much more dynamic than that of C++ and it carries the object-oriented point of view to an extreme (which is where I think it should be carried). It also has no static type checking. This makes it very hard to implement Smalltalk as efficiently as C++, though I don't think it is impossible to do so. As far as language differences go, Smalltalk has no compile-time type-checking, automatic memory management (i.e. has garbage collection), closures as first-class objects (i.e. blocks), everything is an object, including numbers, classes, and contexts, small syntax. C++ uses static type-checking to provide a very efficient implementation of message-sending, a moderately complicated mechanism that can be used to allocate and deallocate garbage collection efficiently (constructors and destructors), no closures, thus permitting stack allocation of contexts, mixture of objects and nonobjects, providing more opportunities for optimization syntax considerably larger than C Note that most of the differences impact performance. I'll say more about this later. The standard Smalltalk image supports multiple inheritance, but it is not documented very well, is rarely used, and is reputed not to work very well. The version of C++ that is currently being sold doesn't have multiple inheritance, but research versions do, and it is just a matter of time before the commercial versions do, too. On the other hand, people argue a lot over how to do multiple inheritance, and some people (like me) don't like the approach that C++ has taken. The really big difference between Smalltalk and C++ is not the languages, but the implemenation and programming environments. Basically, Smalltalk is a lot more fun to use and better for rapid-prototyping, but C++ is a lot more practical for many projects and fits better into the traditional way of building computer systems. Smalltalk comes with a great programming environment that lets you examine everything, change everything, and reuse anything. It also comes with a large library of fairly reusable code. C++ doesn't have either of these features, though there is no reason in principle that it couldn't. Smalltalk programs require the entire Smalltalk image. There is currently no easy to use method of stripping a Smalltalk application out of an image, though several research groups have built prototypes. This makes it hard to use Smalltalk as just another component in a large system. Also, until recently Smalltalk programs could not call subroutines in other languages, though both Tektronix and ParcPlace now have "user-defined primitives" that permit this with some degree of difficulty. The Smalltalk image is fairly large, so any application will also be large. Since any application comes with the image, and the image has tools for looking at source, it is hard (but not impossible) to hide source code. Many of these problems have possible solutions. I'll describe the ultimate solution at the end of this message. Smalltalk is not as portable as C++. Most implementations of C++ use the regular C compiler as an intermediate step, so any machine with a C compiler can run C++. Smalltalk requires an "interpreter" (actually, what ParcPlace sells isn't really an interpreter) and the fast ones are proprietary and are only ported by their owners. Smalltalk and C++ are really designed for very different kinds of applications. You would never want to design an operating system in Smalltalk. However, Smalltalk is ideal for prototyping, for building highly interactive programs like hypertext-like systems, and for building large systems that will have a small number of highly skilled users who will want to customize the system. In these cases, you don't mind needing forcing customers to buy Mac IIs or Suns to get good performance and the advantages of Smalltalk outweigh its drawbacks. There are some areas, such as research into visual programing, where I think that Smalltalk is far and away the best system of any kind, and I can't understand why more people don't use it. (Actually, a lot of the more successful people in those areas do.) For other areas, using Smalltalk would be a disaster. C++ is upward compatible with C (sort of) so it is fairly easy to train people who know C to use it. Anyplace you can use C, you can use C++ just as well. It fits in with the standard software engineering models and can use traditional tools. Of course, I think that the standard models and tools need a massive overhaul, and that Smalltalk gives some good pointers on how, but lots of people only want to change one thing at a time. C++ is just as efficient as C, which is certainly not true of Smalltalk at present, and it allows the programmer complete control over machine resources. Lots of people are working on adding Smalltalk features to C++, in particular, there is a lot of work on improving the environment. C++ needs incremental compilation, browsers and on-line cross-reference tools, and better debuggers. Conferences have papers on all these things, so it is just a matter of time before they become available. The best environment for C++ might just turn out to be Cynergy, which is written in Smalltalk. (snicker, snicker!) Some people are also working on making Smalltalk better suited for traditional environments. In particular, I am building an optimizing compiler for Smalltalk that has the potential to solve all the problems I listed above. It could make Smalltalk as fast as C, let you run programs without the development environment, let you easily call library routines written in C or FORTRAN, and make Smalltalk more portable. Of course, it isn't done yet, though we are getting close. If you are interested in object-oriented programming and can afford the time to educate yourself, I would advise you to play around with Smalltalk. You may not be able to fit Smalltalk into the projects that you are building (though you might find out it is just the thing) but learning it will raise your expections of what computer systems should be and what object-oriented programming should be. Ralph Johnson -- University of Illinois at Urbana-Champaign johnson@cs.uiuc.edu, uiucdcs!johnson
georg@exunido.uucp (Georg A. M. Heeg) (01/05/89)
In article <447@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: > > >(1) Smalltalk can create classes dynamically, whereas C++ does it at > compile time; In Smalltalk you use this feature all the time. It is the way to deal with an interactive system to change it dynamically. Even on brand fast machines make makes me crazy to wait until its ready. >(2) In Smalltalk "everything is an object" whereas C++ treats the traditional > 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. >(3) Smalltalk has multiple inheritance, but C++ does not yet (shortly, I am > informed); We never used this. Multiple Inheritance leads to much more complex systems and mostly can be avoided by distinguishing usage ("has") from inheritance ("is)"). >(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, so I > thought I would ask). This is true for small programs. Due to the good construction models and the good programming interface medium size programs (or large programs) often run blind fast in Smalltalk-80. We (Hans-Martin Mosner) wrote a vt220 emulater in Smalltalk-80 which runs faster than most host platform window system terminal emulators (and has more features). To summarize: Flexibility and interactive visibility are the major differences. Both are VERY important to me. Georg Heeg Smalltalk-80 Systeme Baroper Str. 337 D-4600 Dortmund 50
wgh@ubbpc.UUCP (William G. Hutchison) (01/06/89)
In article <824@laura.UUCP>, georg@exunido.uucp (Georg A. M. Heeg) writes: > In article <447@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: > >(1) Smalltalk creates classes dynamically, whereas C++ does it statically. > In Smalltalk you use this feature all the time. It is the way to deal with > an interactive system to change it dynamically. 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? > >(2) In Smalltalk "everything is an object" whereas C++ treats the traditional > > 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. > >(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)"). Aha! Thanks. > >(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 ... > This is true for small programs. Due to the good construction models and > the good programming interface medium size programs (or large programs) often > run blind fast in Smalltalk-80. We (Hans-Martin Mosner) wrote a vt220 > emulater in Smalltalk-80 which runs faster than most host platform window > system terminal emulators (and has more features). > To summarize: Flexibility and interactive visibility are the major > differences. Both are VERY important to me. > Georg Heeg > Smalltalk-80 Systeme > Baroper Str. 337 > D-4600 Dortmund 50 Thanks for the info. Does anybody know if one of the inexpensive Smalltalk implementations runs correctly on the AT&T 6300PLUS (80286) ??? (inews pablum) (inews pablum) (inews pablum) (inews pablum) -- Bill Hutchison, DP Consultant rutgers!liberty!burdvax!ubbpc!wgh Unisys UNIX Portation Center P.O. Box 500, M.S. B121 "The unexamined life is not worth living!" Blue Bell, PA 19424 -- Educational Testing Service, Princeton, NJ
diamond@csl.sony.JUNET (Norman Diamond) (01/06/89)
In article <447@ubbpc.UUCP>, wgh@ubbpc.UUCP (William G. Hutchison) writes: > From my reading, it appears that > (1) Smalltalk can create classes dynamically, whereas C++ does it at > compile time; Smalltalk is based on an interpreter, and the standard system includes interfaces to the "compiler" (which translates source to pseudo-codes that may be interpreted), so classes and everything else may be created dynamically. The same could be done theoretically in any language, but has not been done in most languages because efficiency has usually been considered more important. > (2) In Smalltalk "everything is an object" whereas C++ treats the traditional > C data types differently from programmer-defined objects; Smalltalk requires "everything" to be accessed as an object, through an interface defined in a class. However, the interpreter really knows that some primitive data types have to be implemented differently, and you can get in trouble if you don't attach grains of salt where necessary. (Just use traditional data types for their traditional purposes and you won't get in trouble.) > (3) Smalltalk has multiple inheritance, but C++ does not yet (shortly, I am > informed); Both languages have multiple inheritance in implementations, though the manuals for both languages deny it. > (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, so I > thought I would ask). Huh? ANY language "may be designed in a way such that it has built-in overhead." Any implementation may do so too. Perhaps you mean that Smalltalk MUST be implemented in such a way -- that is why Smalltalk programs cannot run as fast as C++ programs potentially can (usually). Yes, that is true. That is why interpretive implementations of any language are less popular than compiler-based languages and compiler implementations. Are your programs CPU-intensive, real-time, etc.? If not, Smalltalk's speed may be quite sufficient. It depends on your applications. -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) The above opinions are my own. | Why are programmers criticized for If they're also your opinions, | re-inventing the wheel, when car you're infringing my copyright. | manufacturers are praised for it?
warner@s3snorkel.ARPA (Ken Warner) (01/07/89)
In article <451@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: >In article <824@laura.UUCP>, georg@exunido.uucp (Georg A. M. Heeg) writes: >> In article <447@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: >> >(1) Smalltalk creates classes dynamically, whereas C++ does it statically. Duh...sorry to intrude on your conversation but could you explain to me the difference between dynamic and static classes. I'm not trying to pick a fight; I really don't understand the difference. >> >(3) Smalltalk has multiple inheritance... I am working with ParcPlace ST-80. How do I do multiple-inheritance? It sounds interesting. Ken Warner
georg@exunido.uucp (Georg A. M. Heeg) (01/07/89)
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? > It is not necessary (you can simulate a turing machine in c and thus in c++ :-)) but really handy: William mentions "development". You can really develop interactively a program try notions (classes) try hierarchies and redesign them. To my opinion software development is a creative process with a lot of design and redesign cycles and improvising is often a valuable first step to get a rough idea of a new application field. ...... > 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. Close to 0 means: | a(i,j) | < epsilon (in mathematical notaion) In Smalltalk-80-Notation (a at: i@j) abs < epsilon Certainly abs is differently defined for real and complex numbers. > Thanks for the info. Does anybody know if one of the inexpensive Smalltalk >implementations runs correctly on the AT&T 6300PLUS (80286) ??? Smalltalk-80 is a large memory system and you can hardly address 4 or 8 MB with 16 bit addresses of a 80286 linearly. You need a 80386 to run it. It is available since december 88 from ParcPlace Systems, Palo Alto, e-mail: sales@ParcPlace.com or from us (for Germany, BeNeLux, Austria and Switzerland) and this version runs under MS-DOS. May be somebody recommends to you Smalltalk-V, I don't. Georg Heeg Smalltalk-80 Systeme Baroper Str. 337 D-4600 Dortmund 50
georg@exunido.uucp (Georg A. M. Heeg) (01/07/89)
In article <907@scubed.UUCP> warner@s3snorkel.UUCP (Ken Warner) writes: ... >Duh...sorry to intrude on your conversation but could you explain to me >the difference between dynamic and static classes. I'm not trying to pick >a fight; I really don't understand the difference. Don't be shy! I welcome any contribution. In standard compilation languages like c or c++ you do not have a chance to change any class during the run time of an application. You have to change sources and recompile and relink the whole thing. This is called "static". "Dynamic" you know yourself being a Smalltalk-80 programmer. >>> >(3) Smalltalk has multiple inheritance... > >I am working with ParcPlace ST-80. How do I do multiple-inheritance? It >sounds interesting. In the VI2.2 documentation there is a reprint of Borning's article how to use it. What is described there also works in VI2.3 (I did not test VI2.4 yet). use subclass: t otherSupers: others instanceVariableNames: f classVariableNames: d category: cat instead of: subclass: t instanceVariableNames: f classVariableNames: d poolDictionaries: s category: cat as class creation message. I played a bit with this feature. But I decided to never use it really. I think this is the reason ParcPlace excluded the description from their new documentation. Georg Heeg
riks@csl.sony.JUNET (Rik Smoody) (01/09/89)
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
mark@mamab.UUCP (Mark Woodruff) (01/11/89)
> From: riks@csl.sony.JUNET (Rik Smoody) > Date: 9 Jan 89 05:31:47 GMT > Message-ID: <10099@socslgw.csl.sony.JUNET> > > 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. I think you're overlooking the architectual requirements to run Smalltalk *well*. C++ runs *well* on most popular existing architectures; Smalltalk runs at best only fair. The biggest advantage that C++ has over Smalltalk is that it provides userful object-oriented features NOW and for the next few years on current architectures. While that feature may not thrill you, it is imminently useful to most folks. mark But then I work on a System/370... --- * Origin: MaMaB--the Machine in Mark's Bedroom *HST* (Opus 1:363/9)
raidun@intel.com (Rashid Aidun) (12/05/90)
Does anyone out there use SmallTalk AND C++ ? I am looking for help to compare the two languages. I know some of the differences, but I have just learned both in the last three months and am not an everyday user. If you know of any papers, or books that compare the two language in as much detail as possible, I would appreciate it. If you know some general differences, that can help as well. I am suppose to compare a C++ program to a SmallTalk program, but would like to give a complete list of differences between the two langauges before I describe the differences in the program. Please post replies, or mail directly to me (better if both). I can compile all the mail and post it on the NET if there is enough interest. Thanks My direct email is: raidun@cadev5.intel.com