Path: utzoo!attcan!uunet!wuarchive!psuvax1!rutgers!dptg!ulysses!andante!alice!bs From: bs@alice.UUCP (Bjarne Stroustrup) Newsgroups: comp.lang.smalltalk Subject: Re: Questions from a novice on development environments... Summary: easy now Message-ID: <9987@alice.UUCP> Date: 2 Oct 89 01:28:38 GMT References: <6023@tekgvs.LABS.TEK.COM> Organization: AT&T Bell Laboratories, Murray Hill NJ Lines: 107 There seems to be a misconception that C++ is supposed to be Smalltalk (or that Smalltalk and C++ are in some way supposed to be the same). It follows from that view that you should be able to work in exactly the same way with implementations of the two languages, that you should be able to acomplish the same tasks with the two languages, and that when you cannot someone has goofed. I disagree with this premise. People who naively approach C++ and Smalltalk with this premise are going to be disappointed. C++ was NOT designed as an immitation Smalltalk. Had I tried that, I would naturally have produced something much closer to Smalltalk. Actually, I do not see a need for immitation-Smalltalks. Smalltalk is still the best Smalltalk around; it is a very nice language/system and its evolution is in very capable hands. So, C++ is not a very good Smalltalk; it was not meant to be. Similarly, Smalltalk is not a very good C++; it was not meant to be. There are two fundamental differences between C++ and Smalltalk: C++ is a language; Smalltalk is a system. C++ is statically typed; Smalltalk is dynamically typed. These first order differences follow partly from needs and application areas, partly they represent alternative strategies for attacking problems. Many differences follow from them. For example, in general - it is harder to built a high-quality (``modern,'' ``Smalltalk-like'') programming environment for a statically typed language. - it is harder to provide a high-quality programming environment for a language used on a diverse range of systems (rather than being a system in itself). - it is easier to design ``standard libraries'' in a dynamically typed language. - it is harder to produce efficiently running code for a dynamically typed language. - it is harder to cooperate with ``traditional'' systems from a dynamically typed language embedded in a non-traditional standard environment. - it is easier to manage the integration of large systems written by many programmers if statically typed interfaces are used. The list could be made much longer, but as it becomes more specific the specifics become hard to understand in isolation, data is harder to come by, and the issues gets more sensitive to matters of system maturity, application area, economics, and the background of the users. It is clear that both classes of languages/systems evolve to compensate for their weaknesses. The style of programming and the approach to design is (and I think ought to be) strongly influenced by the language/system used. The choice of language/system chosen for a job should be done with a degree of understanding of both the strenghts and the weaknesses of the alternative languages/systems. There is no reason to believe that a single language/ system will be the best choice for all applications - even if a particular user may have the luxury of working exclusively on projects where a single language/system has a fairly constant overall advantage. A novice's questions deserve a better answer than a polemic blast. The various ``object oriented'' languages do have something basic in common (for example, see my paper `What is Object-Oriented Programming? in IEEE Software Magazine, May 1988) and if people apporaching OOP is wellcomed by a blast from a parochial regigious war it reflets badly on all such languages. There is no language/system in existence that can serve the range of applications/needs that is currently served by various ``OOP languages'' - let alone the range of needs they could serve. C++ and Smalltalk were DELIBERATELY placed at the extreemes of the spectrum of reasonable design choices for practical languages at the times they were developed. That makes comparisons between them interesting (but tricky) and they support each others' growth as much as they compete for resources. I conjecture that there are many more Smalltalk programmers now than there would have been had C++ not existed - and visa versa. I suspect we could have a rather interesting debate about these issues, but I and many others will be at OOPSLA all of next week so we might have to wait a bit. One thing I'm looking forward to at OOPSLA is a panel/debate on almost this topic. The basic observation is that there are far too many silly ``religious'' arguments over language choices and that many such unconstructive debates are based on ignorance of and disrespect for other peoples' problems, needs, basic assumptions, backgrounds, and strenghts (and worse: often heavily influenced/biased by commercial interests). Dan Bobrow (from PARC) proposed a panel where people would present what they like about each other's languages: Gregor Kiczales (PARC) will present Smalltalk, Peter Deutsch (ParkPlace) will present C++, I will present CLOS. This could be interesting and definitely a change from the more traditional ``technical panels'' that IMHO are often no better than the commercial hype found on the exhibition floor.