Xref: utzoo comp.lang.smalltalk:673 comp.lang.c++:1588 Newsgroups: comp.lang.smalltalk,comp.lang.c++ Path: utzoo!henry From: henry@utzoo.uucp (Henry Spencer) Subject: Re: Re: OO debuggers Message-ID: <1988Sep15.200651.18802@utzoo.uucp> Organization: U of Toronto Zoology References: <3941@tekgvs.GVS.TEK.COM> Date: Thu, 15 Sep 88 20:06:51 GMT In article <3941@tekgvs.GVS.TEK.COM> jans@tekgvs.GVS.TEK.COM (Jan Steinman) writes: >Garbage collection: yes, it's a pain when it fires off in the middle of some >critical code... Personally, I rather like the idea of garbage collection, although I'm not entirely convinced we know how to keep it under control. Note that there are experimental garbage-collecting allocators for C and/or C++. You don't need Smalltalk for that. >Run-time binding: in my opinion, any C++ application that does not use virtual >functions is not object oriented... Puh-leeze, let us not get back into the debate about what "object oriented" means. (Although I do tend to agree.) >... Typical Smalltalk run-time binding enjoys a >97% method cache hit rate, negating most of the arguments of those who claim >run-time binding is a major performance bottleneck. Well, I would point out that atypical cases are often a significant performance issue. Also, you miss another aspect of the difference: run-time binding makes compile-time checking a lot harder. This is not a trivial issue for production programs, which are supposed to be right *before* they are released. >...look what [interpretation] buys Smalltalk: incremental compilation (yes, I >know there are other ways to do this, why doesn't Unix/C do them?)... If you look around, you will find no shortage of people willing to sell you incremental interpretive environments for C. Now, how about showing me a high-performance compile-time-checked environment for Smalltalk? :-) >Hardware is getting faster and faster. The hardware installed in any given location gets faster only occasionally. There is still a heavy premium for getting maximum use out of a specific hardware configuration. >Let us be reminded that the first >FORTRAN compilers were greeted with contempt by those who said they wouldn't >produce adequately performing code... Let us be reminded that the first FORTRAN compiler was accepted mostly because those people were *wrong*: it *DID* produce red-hot code, usually equal to or even superior to what human assembly coders could do. Backus and his team at IBM worked long and hard to make this happen, and they are seldom given adequate credit for it. They knew what their customers' priorities were, and they knew that excuses like "hardware is getting faster and faster" wouldn't cut it. They not only invented the true compiler, they invented the super-optimizing compiler. >"Adequately performing" is a relative >constant in many, many fields, and the leaps in performance that hardware is >giving us should be put to use reducing the software life-cycle cost... As Mike O'Dell observed a while ago (roughly): "the machines keep getting faster, but somehow the response at my keyboard hasn't improved much". Too many of the improvements in hardware performance are being eaten up by software writers who assume that they don't have to care about efficiency any more. >... By emphasizing "the >performance issue", people do stupid things like make benchmarks run fast, >rather than making systems more usable. By emphasizing "making systems more usable", people do stupid things like building a system that has ultra-spiffy demos but bogs down hopelessly when you try to use it for real work. Ask Apple about the Lisa. >The big win is an area that is receiving distressing little research or >attention: hybrid systems... I agree that there is real promise there, although it's not clear to me that Smalltalk is the ideal upper-level language for it. >prettier languages were forgotten, by being more practical. C++ is "the next >C" in more ways than one.> > >And just as C was "a smart assembler" before it, C++ is simply providing a >prettier face for the same set of problems that are causing software costs to >go out of control... You know, oddly enough, the people who tell me that C is "just a smart assembler" have a tendency to define anything that their pretty little language can't solve as "not a real problem", ignoring the fact that C copes with it just fine. The same silly remark can be made about most programming languages; it is no more true for C than for the rest. By the same token, Smalltalk is just smart BASIC, a prettier face for the problems that have kept interpretive languages out of mainstream production programming. >I am not a Smalltalk chauvinist. It is not without its >problems. I even happen to like Unix and C++... Actually, I'm not a C/C++ (Unix has little to do with this) chauvinist either. Smalltalk has its points. Unfortunately, while the C community has a lamentable tendency to stress efficiency and disregard the importance of easing development, the Smalltalk community tends to go the other way, stressing easy development and ignoring the quality of the result. There is an important distinction here: easy development of a program is valuable (and getting more so all the time), but adequate performance of the result is often a *constraint*, i.e. a non-negotiable requirement that absolutely must be met. To some extent the difference is a matter of perceptions rather than deep underlying need, but that *is* the way things work today. -- NASA is into artificial | Henry Spencer at U of Toronto Zoology stupidity. - Jerry Pournelle | uunet!attcan!utzoo!henry henry@zoo.toronto.edu