purchase@pyr1.cs.ucl.ac.uk (09/10/88)
I am currently conducting some research into object oriented debugging tools and techniques. I have been surprised and disappointed to learn that most of the testing/debugging tools I have come across for OO languages seem to be merely poor conversions of procedure-oriented language debuggers. It is neither polite nor legal to mention any products by name, but with few exceptions, most OO debugging tools seem to be afterthoughts. I might be wrong, but I think that languages of a (relatively) new paradigm like OOP need *new* innovative support tools to back them. Does anyone out there have any opinions about this? With this in mind, has anyone out there used a OO debug tool (or related utility) of any real merit? Do you feel that a tool should be specialized for the paradigm (or even language) which it supports? In connection with this, does anyone have the addresses (email or otherwise) of the following:- Norm Kerth (University of Portland) Dan Moore (US West) Both of whom submitted some interesting comments to the OO Tools workshop of OOPSLA 87. I would be eternally grateful for any help J.P. **************************************************************************** FROM: Jan Andrew Purchase | Snail: Room 208, PhD Lab., at : pyr1.cs.ucl.ac.uk | Computer Science Dept., | University College, | London, UK. | JANET: purchase@cs.ucl.ac.uk Usenet: {uk}!cs.ucl.ac.uk!purchase ARPANET: purchase%cs.ucl.ac.uk@nss.cs.ucl.ac.uk **************************************************************************** (these are my views, and are not necessarily those of UCL) ****************************************************************************
winnie@pyr1.cs.ucl.ac.uk (09/12/88)
Hi Jan, address of Norman Kerth is : The University of Portland Applied Research Center Multnomah School of Engineering 5000 North Willamette Blvd. Portland, Oregon 97203-5978. Winnie.
jans@tekgvs.GVS.TEK.COM (Jan Steinman) (09/13/88)
<<I am currently conducting some research into object oriented debugging tools and techniques. I have been surprised and disappointed to learn that most of the testing/debugging tools I have come across for OO languages seem to >be merely poor conversions of procedure-oriented language debuggers. >> <...this lack of debugging tools is not confined to the OO domain. I defy you to show you one generally-available debugger that is the least bit "innovative".> Unfortunately, C++ has taken the language veneer of object-orientation, just as the Macintosh took the user-interface veneer. Unless you narrowly define "generally-available" as "one I can use on an arbitrary Unix object file", you should look closely at the generally available Smalltalk-80 debugger, or even the less capable, but more generally available (meaning cheaper), Smalltalk-V debugger. (I think "generally available" means you can buy it for a reasonable price for the most popular computing platforms.) C++ has a lot of catching up to do, but it seems to be evolving strictly in the incestuous C-Unix environment. It currently provides nowhere near the productivity nor capability (except in execution speed, the least important metric in the present "software crisis") of even a moderate Smalltalk implementation, nor will it as long as people are thinking of dbx as the model to improve upon! C'mon, guys, if you're going to make things better, at least start with what was state-of-the art in 1980! :::::: Software Productivity Technologies -- Experiment Manager Project :::::: :::::: Jan Steinman N7JDB Box 500, MS 50-383 (w)503/627-5881 :::::: :::::: jans@tekcrl.TEK.COM Beaverton, OR 97077 (h)503/657-7703 ::::::
reggie@pdn.UUCP (George W. Leach) (09/13/88)
In article <3930@tekgvs.GVS.TEK.COM> jans@tekgvs.GVS.TEK.COM (Jan Steinman) writes: >In article: <37100002@pyr1.cs.ucl.ac.uk> Jan Andrew Purchase >(purchase@pyr1.cs.ucl.ac.uk) writes: >><...this lack of debugging tools is not confined to the OO domain. I defy you >>to show you one generally-available debugger that is the least bit ^^^^^^^^^^^^^^^^^^^ >>"innovative".> Notice the operative adjective. >C++ has a lot of catching up to do, but it seems to be evolving strictly in the >incestuous C-Unix environment. It currently provides nowhere near the >productivity nor capability (except in execution speed, the least important >metric in the present "software crisis") of even a moderate Smalltalk >implementation, nor will it as long as people are thinking of dbx as the model >to improve upon! Tom Cargill's Pi (Process Inspector) debugger is a step in the right direction in the UNIX-C Domain. Unfortunately, it is only available on the research editions of UNIX. With bit-mapped displays becoming more prevelant these days, perhaps we shall see more efforts like this appear as commercial products. We need more than a fancy UI for dbx! See the following papers: T. A. Cargill, "The Feel of Pi", 1986 Winter USENIX Conference Proceedings, pp. 62-71. T.A. Cargill, "Pi: A Case Study in Object-Oriented Programming", OOPSLA'86 Conference Proceedings, pp. 350-360. -- George W. Leach Paradyne Corporation ..!uunet!pdn!reggie Mail stop LF-207 Phone: (813) 530-2376 P.O. Box 2826 Largo, FL 34649-2826
henry@utzoo.uucp (Henry Spencer) (09/14/88)
In article <3930@tekgvs.GVS.TEK.COM> jans@tekgvs.GVS.TEK.COM (Jan Steinman) writes: >C++ ... seems to be evolving strictly in the >incestuous C-Unix environment. It currently provides nowhere near the >productivity nor capability (except in execution speed, the least important >metric in the present "software crisis") of even a moderate Smalltalk >implementation... Au contraire, execution speed is a major metric in the software crisis, although somewhat indirectly: it is important because lack of it leads to otherwise-promising software tools being rejected as impractical. Whether this is rational or not -- and personally I think there is much to be said for it -- it is the way things are. Smalltalk's performance problems, more than anything else, have given it its reputation of being a nice toy for researchers and nothing more. I don't think anybody would claim that C++ is as nice as Smalltalk, but it moves a useful distance in the right direction, and it does a much better job of meeting performance constraints that are considered non-negotiable in many applications. Let us not forget how C became a major programming language, while many prettier languages were forgotten, by being more practical. C++ is "the next C" in more ways than one. -- NASA is into artificial | Henry Spencer at U of Toronto Zoology stupidity. - Jerry Pournelle | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
jans@tekgvs.GVS.TEK.COM (Jan Steinman) (09/15/88)
<<jans@tekgvs.GVS.TEK.COM (Jan Steinman)>> <henry@utzoo.uucp (Henry Spencer)> <<C++... provides nowhere near the productivity nor capability (except in execution speed, the least important metric in the present "software crisis") of even a moderate Smalltalk implementation...>> <Au contraire, execution speed is a major metric in the software crisis... because lack of it leads to otherwise-promising software tools being rejected as impractical... Smalltalk's performance problems, more than anything else, have given it its reputation...> This is close to what I was describing: <<C++ has a lot of catching up to do, but it seems to be evolving strictly in the incestuous C-Unix environment...>> Smalltalk is rejected for its reputation, not for anything based in recent fact. Most people who have seriously considered Smalltalk for projects, and then rejected it, have a slew of other problems with it, but they generally are willing to take a modest performance hit for what it buys them. Let's look at a few cases: Garbage collection: yes, it's a pain when it fires off in the middle of some critical code. It's more of a pain when, through "programmer garbage collection" you destroy an object that still has references, or when unused, undestroyed objects fragment memory space, or when a project runs over because destructor conventions were not followed consistently, none of which happens in Smalltalk. The solution is not to throw out GC as performance-costly, but to build better collectors, and to give users some degree of control. Most who gripe at GC would be satisfied with some kind of "don't you dare interrupt me till I'm through with this stuff" directive. Run-time binding: in my opinion, any C++ application that does not use virtual functions is not object oriented, and those that do are difficult to design, and often lack the flexibility of true polymorphism. In Smalltalk, the programmer doesn't even have to think about it -- it just happens. By dispatching through function tables instead of truly implementing run-time binding, C++ gains only slightly. 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. Byte-code interpretation: this is the one that makes C++ers laugh! How dare anyone use a system that "wastes" so much time simply figuring out what it has to do! However, look what it buys Smalltalk: incremental compilation (yes, I know there are other ways to do this, why doesn't Unix/C do them?) and true object-oriented control over the execution state. It can be argued that the first (in combination with run-time binding) is a major source of productivity in Smalltalk -- you can change and run a method of a moderately sized application ten times in the time consumed by one C++ edit-compile-link-run cycle. I don't expect those who's experience is limited to "traditional" debuggers to truly understand the enormous power the latter gives you: to carry on a dialogue with an execution state is much more than finding new ways of changing memory locations and breakpointing! Hardware is getting faster and faster. Let us be reminded that the first FORTRAN compilers were greeted with contempt by those who said they wouldn't produce adequately performing code. "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. If a spreadsheet that took two months to build in Smalltalk performs just as well as an identical one that took two years to build in C++, who cares if some interpreter somewhere is chewing up 15% of the cycles? By emphasizing "the performance issue", people do stupid things like make benchmarks run fast, rather than making systems more usable. The big win is an area that is receiving distressing little research or attention: hybrid systems. "Smalltalk as a controller" is showing big success with the work of Dave Thomas at CMU and Dick Peskin at Rutgers, among others. Smalltalk appears to be ideally suited for rapidly assembling (an re-assembling) optimally performing "computational units", whether they be multi-processor nodes or snippets of assembly/C/C++ generated code. PPS shows little interest in this area, preferring to "protect their users from themselves", while Digitalk has provided the hooks, but is too busy shipping orders to put it all together. Tektronix is the leader here, but is unfortunately limited to Tektronix platforms through oppressive licensing. <Let us not forget how C became a major programming language, while many 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. I am not a Smalltalk chauvinist. It is not without its problems. I even happen to like Unix and C++. What I argue against is the narrow-mindedness that many in the Unix/C community show for "other" conceptual models; such thinking keeps them from even considering the next set of problems. (OK, I'd better say it: the above statements are my personal views only, and some of them most certainly do not reflect the views of Tektronix.) :::::: Software Productivity Technologies -- Experiment Manager Project :::::: :::::: Jan Steinman N7JDB Box 500, MS 50-383 (w)503/627-5881 :::::: :::::: jans@tekcrl.TEK.COM Beaverton, OR 97077 (h)503/657-7703 ::::::
dannyb@kulcs.uucp (Danny Backx) (09/15/88)
> Tom Cargill's Pi (Process Inspector) debugger is a step in the right >direction in the UNIX-C Domain. Unfortunately, it is only available on the >research editions of UNIX. With bit-mapped displays becoming more prevelant >these days, perhaps we shall see more efforts like this appear as commercial >products. We need more than a fancy UI for dbx! See the following papers: > > > T. A. Cargill, "The Feel of Pi", 1986 Winter USENIX Conference >Proceedings, pp. 62-71. > > T.A. Cargill, "Pi: A Case Study in Object-Oriented Programming", >OOPSLA'86 Conference Proceedings, pp. 350-360. Does anybody have more references to papers on debugging ? Please send me (E-)mail. My special interest is debugging parallel/distributed programs. Any references to OO-debugging papers are appreciated. Danny Backx -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Danny Backx | mail: Danny Backx Tel: +32 16 200656 x 3544 | Katholieke Universiteit Leuven Fax: +32 16 205308 | Dept. Computer Science E-mail: dannyb@kulcs.UUCP | Celestijnenlaan 200 A ... mcvax!prlb2!kulcs!dannyb | B-3030 Leuven dannyb@blekul60.BITNET | Belgium
jans@tekgvs.GVS.TEK.COM (Jan Steinman) (09/15/88)
Oops! I bet Dave Thomas was suprised when he woke up in Pittsburgh this morning! In my previous article, I mistakenly affiliated him with CMU. Dave Thomas is with Carleton University in Ottowa. (Thanks to the readers who noticed the error.) :::::: Software Productivity Technologies -- Experiment Manager Project :::::: :::::: Jan Steinman N7JDB Box 500, MS 50-383 (w)503/627-5881 :::::: :::::: jans@tekcrl.TEK.COM Beaverton, OR 97077 (h)503/657-7703 ::::::
henry@utzoo.uucp (Henry Spencer) (09/16/88)
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. ><Let us not forget how C became a major programming language, while many >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
reggie@pdn.UUCP (George W. Leach) (09/16/88)
In article <1988Sep15.200651.18802@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >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. Another factor eating away at the improvements in hardware is the increased functionality we expect from them. We now have graphical user interfaces, expert systems and relational databases to contend with. These all consume resources. The systems we are building are far more ambitious than those built years ago. The more powerful you make the tools the more applicable those tools become to difficult problems. -- George W. Leach Paradyne Corporation ..!uunet!pdn!reggie Mail stop LF-207 Phone: (813) 530-2376 P.O. Box 2826 Largo, FL 34649-2826
purchase@pyr1.cs.ucl.ac.uk (09/17/88)
KEY: >>> Written 09:37 pm Sep 9, 1988 by purchase@uk.ac.ucl.cs >> Written 12:47 am Sep 12, 1988 by becher@argosy.UUCP > Written 07:19 pm Sep 12, 1988 by jans@tekgvs.GVS.TEK.COM >>>I have been surprised and disappointed to learn that most >>>of the testing/debugging tools I have come across for OO languages seem to >>>be merely poor conversions of procedure-oriented language debuggers. >>So we have poor conversions of poor products ... >>>I might be wrong, but I think that languages of a (relatively) new paradigm >>>like OOP need *new* innovative support tools to back them. Does any one out >>>there have any strong opinions about this? >>You are not wrong - you are absolutely right. >>However, this lack of debugging tools is not confined to the OO domain. >>I defy you to show you one generally-available debugger that is the least >>bit "innovative". They all seem to be stuck in the Linton dbx mold -- >>i.e. dumb terminal textual rather than multiple window graphical (no >>offense Mark, but the time has come to move on). From what I can gather >>there are precious few people working on the debugging problem >>(Zellwegger and Cargill are exceptions). I could not agree more. During my preliminary literature survey I noticed a distinct lack of any truly innovative work after 1985. With the exceptions of Bruegge and Cargill. One of my colleagues conducted a survey (amongst colleges in London University) which showed that 40% of programmers *never* use debuggers and of these who do 25% consider that they are not very useful because they are: too cumbersome to use; are too difficult to learn and have inadequate user interfaces. The lack of good tools, both OO and otherwise is a problem. >>>With this in mind, has anyone out there used a OO debug tool (or related >>>utility) of any real merit? >>No (see above). In my humble opinion, gdb+ doesn't even come close. >>(Although, admittedly, it's better than almost anything else). You mean you got gdb+ to work? I could get it to debug straightforward c++ but as soon as I used the methods-display command or any of the extra "OO facilities" it went spurious on me. >you should look closely at the generally available Smalltalk-80 debugger, or >even the less capable, but more generally available (meaning cheaper), >Smalltalk-V debugger. (I think "generally available" means you can buy it >for a reasonable price for the most popular computing platforms.) I have. I am preparing a few internal research reports on it now. Agreed its better than gdb+ and one could not even begin to compare it to dbx (or dbxtool) but it has its problems. >C++ has a lot of catching up to do, but it seems to be evolving strictly in >the incestuous C-Unix environment. Agreed. Sad isn't it? > ..execution speed, the least important metric in the present "software > crisis" ... I'm not sure I agree fully here. Although you are undoubtedly right generally, one of the important properties of a debugger is that it has minimal effect on the observable run-time behaviour of one's program. Smalltalk's debugger (and one or two others I have used) falls over here. Having to wait a minute for the debugger to simulate a method that usually concludes in 200mS is unacceptable -- especially if you are not informed of the delay in advance. >C'mon, guys, if you're going to make things better, >at least start with what was state-of-the art in 1980! I'm working on it! >>> Jan Purchase >> Jon Becher > Jan Steinman Thanks for listening... **************************************************************************** FROM : Jan Andrew Purchase | Snail: Room 208, PhD Lab., at : pyr1.cs.ucl.ac.uk | Computer Science Dept., | University College, | London, UK. | JANET : purchase@uk.ac.ucl.cs ARPANET : purchase@pyr1.cs.ucl.ac.uk@nss.cs.ucl.ac.uk **************************************************************************** (these are my views, and are not necessarily those of UCL) ****************************************************************************
johnson@p.cs.uiuc.edu (09/19/88)
/* Written 3:06 pm Sep 15, 1988 by henry@utzoo.uucp in comp.lang.smalltalk */ Now, how about showing me a high-performance compile-time-checked environment for Smalltalk? :-) /* End of text from p.cs.uiuc.edu:comp.lang.smalltalk */ Typed Smalltalk is a high-performance compile-time-checked environment for Smalltalk. It is not finished yet, but we are starting to get results. There is a paper about it at OOPSLA'88, and I would be glad to talk about it there with anybody else who is going. Leave a message for me at the message board and we can try to get together. Ralph Johnson
bs@alice.UUCP (Bjarne Stroustrup) (09/20/88)
I have now seen this remark flash by my scream a couple of times: > C++ has a lot of catching up to do, but it seems to be evolving strictly in > the incestuous C-Unix environment. and somebody even agrees: > Agreed. Sad isn't it? I'm not sure the C/UNIX environment is more ``incestuous'' than other environments, but even if it is the statement is flat wrong. C++ work - including work that will directly affect the language and the way it is used - is going on in other environments including the Mac, the PCclone world, and Smalltalk. Come on guys. C++ hasn't been generally available for 3 years yet. It hasn't even completed its planned growth in its native UNIX environment. How fast do you expect evolution to work?
jans@tekgvs.GVS.TEK.COM (Jan Steinman) (09/21/88)
<<jans@tekgvs.GVS.TEK.COM>>
<purchase@pyr1.cs.ucl.ac.uk>
<<...you should look closely at the generally available Smalltalk-80
debugger...>
<I have... but it has its problems.>
I'm glad you have,and I agree that it is not without problems. The fact that
it is quite different than most debuggers is what I want people to pay
attention to. It's a matter of "execution state as an object" vs "rape and
pillage the process".
<<...execution speed, the least important metric in the present "software
crisis"...>>
(Boy, am I catching flak for this statement!)
<...one of the important properties of a debugger is that it has minimal effect
on the observable run-time behaviour of one's program. Smalltalk's debugger...
falls over here. Having to wait a minute for the debugger to simulate a method
that usually concludes in 200mS is unacceptable -- especially if you are not
informed of the delay in advance.>
(More specifically, the Smalltalk-80 V2.2 debugger from PPS.) I plead the
ultimate cop-out, "it's an implementation detail." It's unfortunate if anyone
has formed an impression of Smalltalk performance based on the debugger. The
Tektronix Smalltalk debugger runs at full execution speed, while the original
Version 2 debugger (and PPS follow-ons) interpret (in Smalltalk) the executing
method. I do not know how Smalltalk-V handles this, although I have heard good
things about their 286-version debugger.
But I digress. Henry Spencer would turn this discussion into a
Smalltalk-bashing session, and seems to be unwilling to discuss the
shortcomings of C++ when used for OO. I'm unwilling to be pressed into
defending Smalltalk, rather I'm saying, "Why aren't all you C++ object-oriented
neophytes looking at the rich body of OO knowledge that has evolved in
Smalltalk?", with the debugger as an example.
And also with the debugger as an example, I'm pointing out that C++
inadequately addresses Smalltalk's greatest strengths: rapid prototyping and
incremental development. Smalltalk excels at the "make it work, then make it
fast" model of development, whereas it appears to me that C++ is heading in the
direction of more up-front design work, and less in the direction of promoting
evolutionary development.
I can only laugh sadly when I hear the unspoken undercurrent: "Now that C is
object-oriented, there's no longer any need for Smalltalk.", and am dismayed
that a whole generation is doomed to think C++ synonymous with
object-orientation. ("Huh, what's Smalltalk?") I am gratified that Jan Andrew
Purchase is taking a larger view than most OO newcomers have taken.
:::::: Software Productivity Technologies -- Experiment Manager Project ::::::
:::::: Jan Steinman N7JDB Box 500, MS 50-383 (w)503/627-5881 ::::::
:::::: jans@tekcrl.TEK.COM Beaverton, OR 97077 (h)503/657-7703 ::::::scs@itivax.UUCP (Steve C. Simmons) (09/22/88)
In article <3967@tekgvs.GVS.TEK.COM> jans@tekgvs.GVS.TEK.COM (Jan Steinman) writes: >I'm unwilling to be pressed into defending Smalltalk, rather I'm saying, "Why >aren't all you C++ object-oriented neophytes looking at the rich body of OO >knowledge that has evolved in Smalltalk?", with the debugger as an example. I'll bite. Is it something that can be adequately described in a usenet article? -- Steve Simmons ...!umix!itivax!vax3!scs Industrial Technology Institute, Ann Arbor, MI. "You can't get here from here."
mhyman@cup.portal.com (09/22/88)
In article <3967@tekgvs.GVS.TEK.COM> jans@tekgvs.GVS.TEK.COM (Jan Steinman) says: >.... Smalltalk excels at the "make it work, then make it >fast" model of development, whereas it appears to me that C++ is heading in the >direction of more up-front design work, and less in the direction of promoting >evolutionary development. What am I missing? I can use both languages in either mode. I am able to prototype quicker in Smalltalk but that does not stop me from prototyping in C++. I also believe in "Growing a program" (See No Silver Bullet by Fred Brooks, printed in several journals). Using C++, or C, or any other compiled language just means more compilations. Marco S. Hyman mhyman@cup.portal.com ...!sun!portal!cup.portal.com!mhyman
henry@utzoo.uucp (Henry Spencer) (09/23/88)
In article <3967@tekgvs.GVS.TEK.COM> jans@tekgvs.GVS.TEK.COM (Jan Steinman) writes: >... Henry Spencer would turn this discussion into a >Smalltalk-bashing session, and seems to be unwilling to discuss the >shortcomings of C++ when used for OO... "If you don't want flames, don't be inflammatory." Let us discuss how, specifically, Smalltalk is better, not rant about how lousy C++ is. Nobody, including me, claims that C++ is perfect. It is a small step in the right direction, and by the looks of it, the market is much more willing to accept a small step than a large one. If there are ways in which that small step can be made a bit larger, I for one would be interested to hear about them. It may not be too late to improve the situation. Please don't just say "C++ is crummy and everyone should run right out and spend lots of time and effort learning about Smalltalk before saying anything more". I, for one, don't have time to do that just now. You've already made that effort; how about sharing some of your knowledge with the unwashed masses? -- NASA is into artificial | Henry Spencer at U of Toronto Zoology stupidity. - Jerry Pournelle | uunet!attcan!utzoo!henry henry@zoo.toronto.edu