* What is wrong with OO ? @ 1996-12-03 0:00 Ahmed 1996-12-03 0:00 ` Fred Parker ` (10 more replies) 0 siblings, 11 replies; 209+ messages in thread From: Ahmed @ 1996-12-03 0:00 UTC (permalink / raw) Cc: a.alkooheji Hello Every Body I am a new research student working at the field of Object Oriented Technology...I have several critical opinions about Object Oriented in general, and I like to participate it with you and hear you expert comments and opinions Object Oriented Technology came with quite promising claims that if achieved can benefit the software development companies and organisations millions of pounds. Some of these claims for instance 1 - high reusability of objects and frameworks 2 - Resilience to change, i.e. low software maintenance and evolution cost 3 - Easier understanding by the user and Natural transition between the analysis, design, implementation because they all use tangible perceived objects. However the reality is not so bright as claimed..if so, then nobody today thought to develop a software on the traditional structural methods... My question is what is wrong with OO ? why it did not achieved its targets yet.? What are the main obstacles? Is the problem with the immature OO methodologies ( OO analysis and design in specific ) ? or is it the deficiency in the development tools used like C++ or Smalltalk ? or is it the steep difference in thinking between the traditional and OO schools ? or is it related with the difficulty of object classification ? or is it because of vast legacy systems done using the traditional methods ? or is a combination of many other factors...? I know that giving a precise answer is very difficult for such a complex question, but I like to hear the comments of people working at the feild and who suffered from many difficulties.. I would really appreciate any participation, response or even leading to a good reference , and would be very grateful if the opinions are supported by some evidences... Thanks Yours Ahmed Alkooheji University of Sheffield UK ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-03 0:00 What is wrong with OO ? Ahmed @ 1996-12-03 0:00 ` Fred Parker 1996-12-03 0:00 ` Bill Gooch ` (9 subsequent siblings) 10 siblings, 0 replies; 209+ messages in thread From: Fred Parker @ 1996-12-03 0:00 UTC (permalink / raw) Ahmed wrote: > chop > My question is what is wrong with OO ? why it did not achieved its targets yet.? > What are the main obstacles? > chop "We don't suffer from a Deficiency of Knowledge, We suffer from a Deficiency of Execution" fjparker@ix.netcom.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-03 0:00 What is wrong with OO ? Ahmed 1996-12-03 0:00 ` Fred Parker @ 1996-12-03 0:00 ` Bill Gooch 1996-12-03 0:00 ` Bill Gooch 1996-12-04 0:00 ` Ahmed 1996-12-04 0:00 ` Robert C. Martin ` (8 subsequent siblings) 10 siblings, 2 replies; 209+ messages in thread From: Bill Gooch @ 1996-12-03 0:00 UTC (permalink / raw) To: Ahmed Ahmed wrote: > .... > Object Oriented Technology came with quite promising claims that if achieved can benefit the software > development companies and organisations millions of pounds. > > Some of these claims for instance > 1 - high reusability of objects and frameworks While this may be claimed about specific frameworks, it is not IMO a valid generalization about OOT. It is feasible and important to design and implement objects which achieve immediate *reuse*, general *reusability* is quite rare, and exceedingly difficult to achieve, IME. Typically the costs outweigh the benefits. To be clear what I mean by "immediate reuse" - it is most often fine-grained (method and protocol level) reuse of behavior via inheritance, delegation, etc. which is readily achievable and most important. Medium-grained (class level) reuse is also feasible, although it requires greater design effort and foresight (and/or prior experience in the domain). Large-grained (framework level) reuse is much harder (I think somewhat exponentially with the number of classes/protocols/ relationships involved), and much more rarely achieved. > 2 - Resilience to change, i.e. low software maintenance and evolution cost This depends entirely on the quality of the analysis, design and implementation. Objects effectively *support* resilience by allowing implementations to mirror problems in a way that minimizes unwanted dependencies, thereby limiting the scope of changes. However, such results certainly aren't automatic, and the misconception that resilience is an inherent attribute of OOT works against the accomplishment of it. > 3 - Easier understanding by the user and Natural transition between the analysis, design, I'm very unclear what you mean by "Natural" here, but again, ease of understanding by anyone is entirely dependent on the quality of analysis, design and documentation. Again, OOT used effectively can facilitate ease of understanding, but that doesn't happen by itself. > implementation because they all use tangible perceived objects.... Sure, software objects are "tangible perceived objects" (sometimes perceived anyway), if only inasmuch as we've decided to *call* them "objects." The more I think about it, the more this choice of a name for software entities strikes me as having been a mistake. -- William D. Gooch bill@iconcomp.com Icon Computing http://www.iconcomp.com Texas liaison for the International Programmers Guild For IPG info, see http://www.ipgnet.com/ipghome.htm ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-03 0:00 ` Bill Gooch @ 1996-12-03 0:00 ` Bill Gooch 1996-12-04 0:00 ` Ahmed 1 sibling, 0 replies; 209+ messages in thread From: Bill Gooch @ 1996-12-03 0:00 UTC (permalink / raw) Bill Gooch wrote: > > Ahmed wrote: > > .... > > Some of these claims for instance > > 1 - high reusability of objects and frameworks > > While this may be claimed about specific frameworks, it is > not IMO a valid generalization about OOT. It is feasible > and important to design and implement objects which achieve > immediate *reuse*, general *reusability* is quite rare, and > exceedingly difficult to achieve, IME.... Sorry, that last sentence should have read: "Although it is feasible and important to design...." ^^^^^^^^ ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-03 0:00 ` Bill Gooch 1996-12-03 0:00 ` Bill Gooch @ 1996-12-04 0:00 ` Ahmed 1996-12-04 0:00 ` Bill Gooch 1 sibling, 1 reply; 209+ messages in thread From: Ahmed @ 1996-12-04 0:00 UTC (permalink / raw) Bill Gooch wrote: > > Ahmed wrote: > > .... > > Object Oriented Technology came with quite promising claims that if achieved can benefit the software > > development companies and organisations millions of pounds. > > > > Some of these claims for instance > > 1 - high reusability of objects and frameworks > > While this may be claimed about specific frameworks, it is > not IMO a valid generalization about OOT. It is feasible > and important to design and implement objects which achieve > immediate *reuse*, general *reusability* is quite rare, and > exceedingly difficult to achieve, IME. Typically the costs > outweigh the benefits. > > To be clear what I mean by "immediate reuse" - it is most > often fine-grained (method and protocol level) reuse of > behavior via inheritance, delegation, etc. which is readily > achievable and most important. Medium-grained (class level) > reuse is also feasible, although it requires greater design > effort and foresight (and/or prior experience in the domain). > Large-grained (framework level) reuse is much harder (I think > somewhat exponentially with the number of classes/protocols/ > relationships involved), and much more rarely achieved. > Actually immediat reuse can be acheived to a certain extent with the traditional structural methods if they adopted a good design What I understand from this is that it is not convinient to reuse objects of other applications because they are built with different perspectives.. Does this mean,If two organizations developed almost typical applications does not mean that the objects developed can be reusable between them.. Is not this a deficiency in OO. Every programmer is tackling the same problem using his own perception of the problem..his own abstraction.. The concept behind OO is that it deals with peices of software as tangible objects exactly as real world works..however in real world every object has a clear behaviour and perception by every body, while in the OO software each object has a behaviour according to the perception of his designer..!! The problem is that many organization avoid moving toword OO because the transfter cost to OO ( training programmers / organization change in standards / new tools / new analysis and design methods / legacy system/ etc. ) are much higher than the benifit of "immediate reuse" Another point regarding inheritance, we know that Visiual Basic does not have the capability of inheritance, however you can build a system much faster compared to using visiual C++ with much less code. I am not saying that we should move to the traditional structural methods No, I have suffered enough from it, I actually like OO because of its strong features..But I want to know why it is not moving so fast.. Regardless of the huge amout of push it got by the major players in the software industry..I believe that OO is still not mature enough in certain aspects. and this is what I am trying to find.. Cheers Ahmed > > -- > William D. Gooch bill@iconcomp.com > Icon Computing http://www.iconcomp.com > Texas liaison for the International Programmers Guild > For IPG info, see http://www.ipgnet.com/ipghome.htm ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-04 0:00 ` Ahmed @ 1996-12-04 0:00 ` Bill Gooch 1996-12-06 0:00 ` Jeff Miller 1996-12-06 0:00 ` Ahmed 0 siblings, 2 replies; 209+ messages in thread From: Bill Gooch @ 1996-12-04 0:00 UTC (permalink / raw) To: Ahmed Ahmed wrote: > > Actually immediat reuse can be acheived to a certain extent with > the traditional structural methods if they adopted a good design A key phrase here is "to a certain extent." OO allows more effective reuse (less redundancy, less copy-and-edit) than alternatives. > What I understand from this is that it is not convinient to reuse > objects of other applications because they are built with different > perspectives.. I think "not convenient" is a bit of an understatement - "very difficult" might typically be more accurate. > Does this mean,If two organizations developed almost typical applications > does not mean that the objects developed can be reusable between them.. > Is not this a deficiency in OO. As compared to what? Non-OO software? I think not. Two different automobile designs rarely share any compatible parts (except those which are industry- standardized, like oil filters), unless the designers worked together with that goal in mind. > Every programmer is tackling the same problem using his own perception > of the problem..his own abstraction.. Yes, and the alternative is?... > The concept behind OO is that it deals with peices of software as > tangible objects exactly as real world works.. Not at all. "How the real world works" is by no means obvious or well understood ("real world" in itself is an exceedingly vague term), and you'd need to provide some definitions of these things, as well as evidence to support the above assertion. > however in real world > every object has a clear behaviour and perception by every body, Not in the slightest. > while in the OO software each object has a behaviour according to > the perception of his designer..!! Sometimes. The designer probably hopes it does. > The problem is that many organization avoid moving toword OO because > the transfter cost to OO ( training programmers / organization change in > standards / new tools / new analysis and design methods / legacy > system/ etc. ) are much higher than the benifit of "immediate reuse" OK - why is this a problem? > Another point regarding inheritance, we know that Visiual Basic does not > have the capability of inheritance, however you can build a system > much faster compared to using visiual C++ with much less code. Depends what system, doesn't it? VB isn't ideal for all computer applications; C++ is probably a better choice for at least some of them. > I am not saying that we should move to the traditional structural methods > No, I have suffered enough from it, I actually like OO because of its > strong features..But I want to know why it is not moving so fast.. Patience is a virtue. Rapid growth and early acceptance can lead to backlash and equally rapid decline. -- William D. Gooch bill@iconcomp.com Icon Computing http://www.iconcomp.com Texas liaison for the International Programmers Guild For IPG info, see http://www.ipgnet.com/ipghome.htm ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-04 0:00 ` Bill Gooch @ 1996-12-06 0:00 ` Jeff Miller 1996-12-06 0:00 ` Bill Gooch 1996-12-14 0:00 ` Chris 1996-12-06 0:00 ` Ahmed 1 sibling, 2 replies; 209+ messages in thread From: Jeff Miller @ 1996-12-06 0:00 UTC (permalink / raw) Bill Gooch wrote: > > Ahmed wrote: > > > > Actually immediat reuse can be acheived to a certain extent with > > the traditional structural methods if they adopted a good design > > A key phrase here is "to a certain extent." OO allows > more effective reuse (less redundancy, less copy-and-edit) > than alternatives. This reminds me of a thread we had on the comp.lang.c++ ng a couple of years ago. I maintained then, and continue to maintain, that the extent to which OO tools incrementally promote reuse (C++ as compared to C, to draw an obvious example) is not in and of itself sufficient to have any meaningful impact in any large organization. Effective reuse is substantially a management issue, not a technical one. OO helps, but organizational and process changes are more important. Jeff Miller Senior Server Architect CSG Systems, Inc. jeff_miller@csgsys.com jmiller@probe.net ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-06 0:00 ` Jeff Miller @ 1996-12-06 0:00 ` Bill Gooch 1996-12-14 0:00 ` Chris 1 sibling, 0 replies; 209+ messages in thread From: Bill Gooch @ 1996-12-06 0:00 UTC (permalink / raw) Jeff Miller wrote: > .... > Effective reuse is substantially a management issue, not a technical > one. OO helps, but organizational and process changes are more > important. I think you may have missed the emphasis I was putting on *immediate* reuse. This means reuse of software modules (methods, interfaces, classes, etc.) within a single application, and sometimes across similar applications that are being developed concurrently. IME, this flavor of reuse is primarily a technical (and technical project management) issue, and not an organizational one. "Process" at some level is always an issue, but then that's not saying very much. OTOH, I agree that large-scale (longer term, and/or broader scope, e.g. framework-level) reuse requires organizational compliance. But still, the technical issues can't take too much of a back seat, or nothing good will come of it. You may accomplish reuse with organizational and process changes in the absence of a strong technical understanding, but the stuff you'll be reusing won't be worth reusing. -- William D. Gooch bill@iconcomp.com Icon Computing http://www.iconcomp.com Texas liaison for the International Programmers Guild For IPG info, see http://www.ipgnet.com/ipghome.htm ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-06 0:00 ` Jeff Miller 1996-12-06 0:00 ` Bill Gooch @ 1996-12-14 0:00 ` Chris 1 sibling, 0 replies; 209+ messages in thread From: Chris @ 1996-12-14 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 511 bytes --] Jeff Miller <jmiller@probe.net> a �crit dans l'article <32A7B9BC.52C71CEF@probe.net>... > Effective reuse is substantially a management issue, not a technical > one. OO helps, but organizational and process changes are more > important. I agree, but OO (design and implementation) will force a minimum of reuse even if for best reusability, we have to think about it. -- Chris, drunk philosoph and bad programmer "The nail pulling up calls the hammer" zen proverb ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-04 0:00 ` Bill Gooch 1996-12-06 0:00 ` Jeff Miller @ 1996-12-06 0:00 ` Ahmed 1996-12-06 0:00 ` Bill Gooch 1 sibling, 1 reply; 209+ messages in thread From: Ahmed @ 1996-12-06 0:00 UTC (permalink / raw) Cc: a.alkooheji Bill Gooch wrote: > > Ahmed wrote: > > > > Does this mean,If two organizations developed almost typical applications > > does not mean that the objects developed can be reusable between them.. > > Is not this a deficiency in OO. > > As compared to what? Non-OO software? I think not. > Compared to the Object concept and its capability ..!! > Two different automobile designs rarely share any > compatible parts (except those which are industry- > standardized, like oil filters), unless the designers > worked together with that goal in mind. > I think this is a good example for comparison, Does every car-company develop the car from a to z ? I doubt it ..! There are special companies dedicated only to develop specific spare parts for the cars, It is true that the spare parts are not compatible ( in general ) between different car models, However almost all cars share the same level of abstraction, when you say a "radiator" to a mechnical engineer he will immediately understand its functionality, no matter if it is a Mercedece or Honda car. When you say to a mechanic "piston" "shaft" "gear-box" "clutch" "handbrake" ...etc. ( you name it ) then an Immediate image will draw in his mind and will grasp a general perception Even if you go to lower levels, each part has a name and a main function, Without this common abstaction between cars then the job of any mechanics will be almost imposible. Otherwise every car model will require a dedicated mechanical engineer. > > Every programmer is tackling the same problem using his own perception > > of the problem..his own abstraction.. > > Yes, and the alternative is?... > In my openion, to get the advantage of OO capability, there must be an agreement on the abstraction level of every domain. This should turn into standard abstaction accessable for any softwaer developer. There should be an institute or company to take this responsibility. Otherwise people will always reenvent the weel by inventing their trivial classes localy which is a waste of a valuable resource .. ( Programmers ) > > The concept behind OO is that it deals with peices of software as > > tangible objects exactly as real world works.. > > Not at all. "How the real world works" is by no means > obvious or well understood ("real world" in itself is > an exceedingly vague term), and you'd need to provide > some definitions of these things, as well as evidence > to support the above assertion. > I feel that this is a more phylosifical answer than being practical. Yes you need to provide some definitions for tricky words that might give different semantics, however trivail words in the proper context are self explainatory ..!! > > however in real world > > every object has a clear behaviour and perception by every body, > > Not in the slightest. > > > while in the OO software each object has a behaviour according to > > the perception of his designer..!! > > Sometimes. The designer probably hopes it does. > > > The problem is that many organization avoid moving toword OO because > > the transfter cost to OO ( training programmers / organization change in > > standards / new tools / new analysis and design methods / legacy > > system/ etc. ) are much higher than the benifit of "immediate reuse" > > OK - why is this a problem? This means that OOP did not yet prove or show its greate advantages in many domains. So It needs efforts more before being accepted widely. I believe that OO has the power to do so but ( probably ) the wrong usage of it is preventing its remarkable success in certain areas. > > > Another point regarding inheritance, we know that Visiual Basic does not > > have the capability of inheritance, however you can build a system > > much faster compared to using visiual C++ with much less code. > > Depends what system, doesn't it? VB isn't ideal for > all computer applications; C++ is probably a better > choice for at least some of them. > Agree with you that C++ is much more powerful that VB in certain areas .. But What prevent an OOP from exceeding a non OOP in all areas ..? Regards, Ahmed > -- > William D. Gooch bill@iconcomp.com > Icon Computing http://www.iconcomp.com > Texas liaison for the International Programmers Guild > For IPG info, see http://www.ipgnet.com/ipghome.htm ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-06 0:00 ` Ahmed @ 1996-12-06 0:00 ` Bill Gooch 0 siblings, 0 replies; 209+ messages in thread From: Bill Gooch @ 1996-12-06 0:00 UTC (permalink / raw) Ahmed wrote: > >.... > It is true that the spare parts are not compatible ( in general ) between different car models, > However almost all cars share the same level of abstraction, > > when you say a "radiator" to a mechnical engineer he will immediately understand its functionality, > no matter if it is a Mercedece or Honda car. > When you say to a mechanic "piston" "shaft" "gear-box" "clutch" "handbrake" ...etc... In software, any of the above would be a "pattern." > Even if you go to lower levels, each part has a name and a main function, > Without this common abstaction between cars then the job of any mechanics will be almost > imposible. Otherwise every car model will require a dedicated mechanical engineer. The analogy breaks down because all cars respond to essentially the same set of general requirements, with variations occurring at a more detailed level. Software requirements vary widely at all levels, and thus the *application* and *composition* of common patterns in different pieces of code also vary accordingly. Cars (and trucks) are all similar in many important respects, in addition to the fact that the patterns involved in their designs are pretty well and widely understood. Your everyday mechanic will usually know most of the patterns by heart, whereas a typical software engineer is often learning new patterns with each new project. > Yes you need to provide some definitions for tricky words that might > give different semantics, however trivail words in the proper context > are self explainatory ..!! IMO words are never "self explanatory." It's in the nature of perception that each individual has his or her own distinct interpretation. But there is a wide range of variation in the ambiguity of different words, and "real" and "world" are both separately, and even more so when used together, highly ambiguous. We tend to ignore or even deny the ambiguity of words like these that we use very frequently, but trying to define them in very specific terms often illuminates the issue. -- William D. Gooch bill@iconcomp.com Icon Computing http://www.iconcomp.com Texas liaison for the International Programmers Guild For IPG info, see http://www.ipgnet.com/ipghome.htm ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-03 0:00 What is wrong with OO ? Ahmed 1996-12-03 0:00 ` Fred Parker 1996-12-03 0:00 ` Bill Gooch @ 1996-12-04 0:00 ` Robert C. Martin 1996-12-04 0:00 ` Matthew Gream ` (7 subsequent siblings) 10 siblings, 0 replies; 209+ messages in thread From: Robert C. Martin @ 1996-12-04 0:00 UTC (permalink / raw) In article <32A4659D.347A@shef.ac.uk>, Ahmed <ACQ95AA@shef.ac.uk> wrote: > Object Oriented Technology came with quite promising claims that if achieved can benefit the software > development companies and organisations millions of pounds. Those claims were not made by the engineers and researchers who "invented" OO. They were made by marketeers who found a new way to differentiate products, and by engineers who had shut off their ability to employ critical thinking. > > Some of these claims for instance > 1 - high reusability of objects and frameworks > 2 - Resilience to change, i.e. low software maintenance and evolution cost > 3 - Easier understanding by the user and Natural transition between the analysis, design, > implementation because they all use tangible perceived objects. > > However the reality is not so bright as claimed..if so, then nobody today thought to develop a > software on the traditional structural methods... > > My question is what is wrong with OO ? why it did not achieved its targets yet.? > What are the main obstacles? The claims were too grandiose. Software is still software; and it is still hard. There are still bugs, still ambiguous specifications, still volatile specifications, still improperly trained engineers, still engineers who shouldn't be engineers, still managers who don't understand the technology they are trying to manage, still arbitrary completion dates, etc, etc, etc. In any case, you shouldn't be surprised when highly publicized claims are not achieved. Generally those claims are just part of the overall hype associated with any new idea. The truth is: (If I may be so bold as to claim to know the truth ;) 1- OO, when properly employed, does enhance the reusability of software. But it does so at the cost of complexity and design time. Reusable code is more complex and takes longer to design and implement. Futhermore, it often takes two or more tries to create somthing that is even marginally reusable. 2- OO, when properly employed, does enhance the software's resilience to change. But it does so at the cost of complexity and design time. This trade off is almost always a win, but it is hard to swallow sometimes. 3- OO does not necessarily make anything easier to understand. There is no magical mapping between the software concepts and every human's map of the real world. Every person is different. What one person percieves to be a simple and elegant design, another will percieve as convoluted and opaque. 4- If a team has been able, by applying point 1 above, to create a repository of reusable items, then development times can begin to shrink significantly due to reuse. 5- If a team has been able, by applying point 2 above, to create software that is resilient to change, then maintenance of that software will be much simpler and much less error prone. In short. Nothing has gone wrong with OO. It is a technology, and it delivers everything it was designed to deliver, and perhaps a bit more. That it doesn't live up to the naive claims made by naive or insincere people is unfortunate, but not unexpected. > > Is the problem with the immature OO methodologies ( OO analysis and design in specific ) ? No, these techniques have been a major contribution to software engineering, and have gone a long way towards improving the way we build software. > or is it the deficiency in the development tools used like C++ or Smalltalk ? No, the tools are more or less adequate for the job. IMHO, someone who blames a language for a failure should be looking a bit closer to home for the cause. > or is it the steep difference in thinking between the traditional and OO schools ? I don't think it's the steepness of the difference, although the difference can be very steep. Instead I think that it is the disagreement by OO authorities on the endpoint of that learning curve. For example, some folks will tell you that the secret of OO is think of the world in terms of objects. Others will tell you that it is to think of the structure of the software in terms of polymorphic interfaces. Still others will tell you that it is to decouple the domains of the problem by describing them using macros that can be statically bound at compile time. Which is right? Which is real? There is a *lot* of confusion out there. That some folks might not be experiencing any of the benefits of OO does not surprise me. (BTW, my own choice is one about structuring the software in terms of polymorphic interfaces) -- Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (847) 918-1004 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-03 0:00 What is wrong with OO ? Ahmed ` (2 preceding siblings ...) 1996-12-04 0:00 ` Robert C. Martin @ 1996-12-04 0:00 ` Matthew Gream 1996-12-05 0:00 ` Tim Ottinger 1996-12-04 0:00 ` Harry Protoolis ` (6 subsequent siblings) 10 siblings, 1 reply; 209+ messages in thread From: Matthew Gream @ 1996-12-04 0:00 UTC (permalink / raw) Hi Ahmed, On Tue, 03 Dec 1996 17:38:37 +0000, Ahmed (ACQ95AA@shef.ac.uk) wrote: > Object Oriented Technology came with quite promising claims that if > achieved can benefit the software development companies and > organisations millions of pounds. OO is no different from many other technologies. It comes with many promises, and it can fulfill these if used in the right situations in the right way. It is not a panacea, which is not a new or surprising statement. When you consider "Object Oriented Technology", you must also consider Domain Analysis, Architecture, Patterns and other lifecycle goodies which are not inherently Object Oriented, but seem to be a necessary requirement for successful OO benefits. > Some of these claims for instance > 1 - high reusability of objects and frameworks This can be achieved, but it requires discipline, investment and experience. Discpline to work hard towards reusability, and to maintain that reusability (though evolution). Investment in terms of the effort involved to establish generic solutions (generic solutions are generally [:-)] much harder than specific solutions). Experience to make the correct decisions when constructing re-usable items (to have some degree of visibility). > 2 - Resilience to change, i.e. low software maintenance and evolution cost How flexible is the software? This has a lot to do with architecture: "if you don't get the architecture right up front, you may as well pack up and go home" [quote made by a fellow engineer]. The architecture in many ways predicts what will happen to the software over its lifecycle. If you don't get this right, you will need to change the architecture: this is usually not a trivial task. This is not exclusively an OO issue though. OO includes inheritence. This promotes generalisation -- factoring out commonalities -- which reduces dependencies. Reduction in dependencies makes maintenance and evolution more predictable and cheaper. It is perhaps predictability that is more important than anything, better to correctly assess that all the costs are high up front, before starting, rather than finding out later. There are also CASE tools, which make evolution and maintenance much easier and achievable (they also keep you focused at a higher level of logic). Having a CASE tool take care of menial details (file organisation, includes, class definitions, method stubs, etc) and take over some of the verification roles (use cases and scenarios) is very important. Though, CASE tools are not inherently an OO thing. There are probably many more items you can mention here as well. > 3 - Easier understanding by the user and Natural transition between the analysis, design, > implementation because they all use tangible perceived objects. The transition is definitely a good thing. Being able to iteratively build software is much more predictable as well. What you've said seems to be much easier to say that to do, from the experience I've seen around me. Getting the right architecture and objects up front requires experience (and therefore, knowledge). It also requires an appropriate balance between the actual system requirements, the system domain and other domains. This requires time and experience. > However the reality is not so bright as claimed..if so, then nobody today thought to develop a > software on the traditional structural methods... > My question is what is wrong with OO ? why it did not achieved its targets yet.? > What are the main obstacles? I would say that it is slowely acheiving its targets and that there are three main inter-related obstacles: time, experience and collaboration. We need more of these to help the overall feedback loop. > Is the problem with the immature OO methodologies ( OO analysis and design in specific ) ? > or is it the deficiency in the development tools used like C++ or Smalltalk ? > or is it the steep difference in thinking between the traditional and OO schools ? > or is it related with the difficulty of object classification ? > or is it because of vast legacy systems done using the traditional methods ? > or is a combination of many other factors...? All of these would seem to be problems from my, limited, experience. The thinking "mindset" is perhaps one of the most important. > I know that giving a precise answer is very difficult for such a complex question, but I like to > hear the comments of people working at the feild and who suffered from many difficulties.. > I would really appreciate any participation, response or even leading to a good reference , > and would be very grateful if the opinions are supported by some evidences... You want evidence ? I need more experience :-). Please excuse my bias towards architecture in the above as well, I think that architecture and organisation are very important. Architecture is everywhere, from the big to the small (in the software, in the process, in the people, in the organisation, etc). Most of the software problems I have encountered can be traced back to architectural issues of one form or another. Cheers, Matthew. -- Email: Matthew.Gream@Jtec.com.au Phone: (02) 390-0194 Fax: (02) 364-0055 Post: Jtec (R&D) Pty Ltd. Unit 3, 118-122 Bowden St. Meadowbank NSW 2114. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-04 0:00 ` Matthew Gream @ 1996-12-05 0:00 ` Tim Ottinger 0 siblings, 0 replies; 209+ messages in thread From: Tim Ottinger @ 1996-12-05 0:00 UTC (permalink / raw) Matthew Gream wrote (And all in all, a thoughtful posting): [in response to question:] > > 2 - Resilience to change, i.e. low software maintenance and evolution cost > > How flexible is the software? This has a lot to do with architecture: > "if you don't get the architecture right up front, you may as well pack > up and go home" [quote made by a fellow engineer]. The architecture in > many ways predicts what will happen to the software over its > lifecycle. If you don't get this right, you will need to change the > architecture: this is usually not a trivial task. This is not exclusively > an OO issue though. By the way, while this is "essentially" right, there are plenty of cases where people did not build the correct architecture the first time out. In fact, many of us will tell you that it's nigh impossible to build it right the first time out if the software project is interesting enough. The iterative incremental model ain't perfect, but using short cycles and daring to revisit can cover an awful lot of design sins. If you commit to an architecture, then you're probably stuck. I propose the motto "design by distrust!". If the work is suitably isolated from the physical and business requirements, then you can reliably insulate yourself from those things you don't believe will be invariant, even if you don't know which direction they'll go in. Of course, this *is* your next point, but I wanted to stress that it's not a top-down thing, and the process is not completely unforgiving. Otherwise, we'd be better off outside of OO for large projects. The architecture thing, even the business model, can be essentially right and correctably wrong, and sometimes it's a close to perfection as you'll get. Especially early on in a project. > OO includes inheritence. This promotes generalisation -- factoring out > commonalities -- which reduces dependencies. Reduction in dependencies > makes maintenance and evolution more predictable and cheaper. It is > perhaps predictability that is more important than anything, better to > correctly assess that all the costs are high up front, before starting, > rather than finding out later. Design by distrust! Estimate by distrust! > > Is the problem with the immature OO methodologies ( OO analysis and design in specific ) ? > > or is it the deficiency in the development tools used like C++ or Smalltalk ? > > or is it the steep difference in thinking between the traditional and OO schools ? > > or is it related with the difficulty of object classification ? > > or is it because of vast legacy systems done using the traditional methods ? > > or is a combination of many other factors...? > > All of these would seem to be problems from my, limited, experience. The > thinking "mindset" is perhaps one of the most important. To begin with, I don't accept the idea that there is a "problem". I'll talk about that in a second. Secondly, I think that the difference in thinking between OO and structured is a matter of breaking mental habits, not the deep and nearly incrossible chasm people make it out to be. We have people who jump from COBOL to C++ and OO in one great leap. We have a number of people who came from procedural 4GLs to OO. It happens very frequently, maybe every week or every day all over the world with thousands and thousands of people. A lot of the "problem" is with organizations. If they've been successful to any degree with other methods (including brute force) then they are unlikely to "mess with the formula" by going into OO. A lot of people still use Fortranm, COBOL, RPG, etc., successfully - untouched by the Client/Server revolution, CASE, even RDBMS. No person or company is obliged to stay "technically current", and so many will not. And they might do fine at it. The fact of the matter is that OO is a change in management and project planning as much as anything else, and a lot of managers aren't too keen on having their world ripped out from under them. That's just an education thing. It'll come in time, but the focus on managing OO is fairly recent in the scheme of things. There's an underlying myth of the question which was originally asked. "If method A is good, then why does anybody do anything else", or "If some people don't use A, then it must not be very good". If I asked "If software is a good career, then why do some people still raise crops?" you might laugh. Software is not for every- body. For that matter, you know that managers and financial people make more money than programmers, so whats wrong with you that you don't go into management instead? Well, maybe programming is fine for you. Maybe that money benefit isn't all that important to you. Does that mean that managers *don't* make more money? Likewise OO. It's not a winner-take-all battle with the rest of the DP world. It doesn't have to be popular, and it doesn't have to be used exclusively by all software companies in order to work. It's just a set of mental tools you can use if you want the benefits it can provide. Some people are gung-ho, some are skeptical, some don't care. And they have that right. -- Tim ******************************************************************** In some sense, all of life is design. The way we pick our friends, the way we plant a garden, and the way we choose software is all design. Sometimes we do things by habit, other times by carefully weighing the pros and cons, and sometimes we make experiments. -- Ralph Johnson -- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-03 0:00 What is wrong with OO ? Ahmed ` (3 preceding siblings ...) 1996-12-04 0:00 ` Matthew Gream @ 1996-12-04 0:00 ` Harry Protoolis 1996-12-04 0:00 ` Joe Winchester ` (3 more replies) 1996-12-04 0:00 ` Piercarlo Grandi ` (5 subsequent siblings) 10 siblings, 4 replies; 209+ messages in thread From: Harry Protoolis @ 1996-12-04 0:00 UTC (permalink / raw) On Tue, 03 Dec 1996 17:38:37 +0000, Ahmed <ACQ95AA@shef.ac.uk> wrote: >Hello Every Body > >I am a new research student working at the field of Object Oriented Technology. > ..I have several >critical opinions about Object Oriented in general, and I like to participate it > with you and hear >you expert comments and opinions > >Object Oriented Technology came with quite promising claims that if achieved can > benefit the software >development companies and organisations millions of pounds. > >Some of these claims for instance >1 - high reusability of objects and frameworks >2 - Resilience to change, i.e. low software maintenance and evolution cost >3 - Easier understanding by the user and Natural transition between the analysis > , design, >implementation because they all use tangible perceived objects. > >However the reality is not so bright as claimed..if so, then nobody today though > t to develop a >software on the traditional structural methods... > >My question is what is wrong with OO ? why it did not achieved its targets yet.? >What are the main obstacles? I think this is overly negative, OO has not been and never will be a 'silver bullet' to solve all software development problems, but no-one but a few spin doctors ever claimed it would be. However, the real question should be 'has OO made a significant positive difference', and in my experience the answer is a resounding 'yes!'. I have been a professional software engineer for 10 years now, the first half of which was spent fighting against traditional structured techinques, it was only despite them I was able to get anything finished. The traditional techniques all suffered from a number of significant flaws. Perhaps the most damaging one was what I (rather unkindly) think of as 'The glorification of idiots' phenomenon. What I mean by this is that projects were typically infested by a group of people who never wrote any software, but spent most of the budget drawing diagrams that the implementors never used. The main contribution of OO has been was could be termed 'The glorification on the implementor'. This has been achieved by the effective marriage of Analysis, Design and Implementation. The result is that every member of the team does all three of the key tasks. In fact IMHO an OO team has no place for anyone who cannot do all three tasks. Jim Coplein wrote an excellent pattern called 'Architect also Implements' which covers very nicely the reasoning behind not allowing non-implementors to design systems. Certainly the mecca of automatic reuse has not been achieved, but the quantity and quality of 3rd party components available for most OO languages already exceeds that available for their non-OO counterparts, and IHMO this suggests a bright future. Certainly OO has not made writing software trivial or automatic, but then, *nothing ever will*. Cheers, Harry - alt.computer pty ltd software development consultants ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-04 0:00 ` Harry Protoolis @ 1996-12-04 0:00 ` Joe Winchester 1996-12-05 0:00 ` Russell Corfman 1996-12-04 0:00 ` Robert C. Martin ` (2 subsequent siblings) 3 siblings, 1 reply; 209+ messages in thread From: Joe Winchester @ 1996-12-04 0:00 UTC (permalink / raw) Harry Protoolis wrote: > In fact IMHO an OO team has no place for anyone who cannot do all > three tasks. Jim Coplein wrote an excellent pattern called > 'Architect also Implements' which covers very nicely the reasoning > behind not allowing non-implementors to design systems. Harry, Do you know where I might be able to get hold of Coplien's pattern. Regards, -- Joe Winchester JoeW@concentric.net 103276,233@Compuserve.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-04 0:00 ` Joe Winchester @ 1996-12-05 0:00 ` Russell Corfman 0 siblings, 0 replies; 209+ messages in thread From: Russell Corfman @ 1996-12-05 0:00 UTC (permalink / raw) It's in the proceedings from the PLoP-94 conference. The proceedings are published by Addison-Wesley in the book "Pattern Languages of Program Design" edited by Coplien and Schmidt, ISBN 0-201-60734. Most good book stores should have it and the PLoPD2 book from PLoP-95. I believe there is a copy on the web that is reachable from Coplien's homepage http://www.bell-labs.com/people/cope/ look for "organizational and process patterns" Russell Corfman corfmanr@agcs.com In article <32A65E19.7E68@concentric.net>, Joe Winchester <JoeW@concentric.net> wrote: >Harry Protoolis wrote: > >> In fact IMHO an OO team has no place for anyone who cannot do all >> three tasks. Jim Coplein wrote an excellent pattern called >> 'Architect also Implements' which covers very nicely the reasoning >> behind not allowing non-implementors to design systems. > >Harry, > >Do you know where I might be able to get hold of Coplien's pattern. > >Regards, > >-- >Joe Winchester >JoeW@concentric.net >103276,233@Compuserve.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-04 0:00 ` Harry Protoolis 1996-12-04 0:00 ` Joe Winchester @ 1996-12-04 0:00 ` Robert C. Martin 1996-12-04 0:00 ` Dr. Richard Botting ` (2 more replies) 1996-12-04 0:00 ` Ahmed 1996-12-04 0:00 ` What is wrong with OO ? Roger T. 3 siblings, 3 replies; 209+ messages in thread From: Robert C. Martin @ 1996-12-04 0:00 UTC (permalink / raw) In article <slrn5a9o60.okl.harry@matilda.alt.net.au>, harry@matilda.alt.net.au (Harry Protoolis) wrote: > The traditional techniques all suffered from a number of significant > flaws. Perhaps the most damaging one was what I (rather unkindly) think > of as 'The glorification of idiots' phenomenon. What I mean by this is > that projects were typically infested by a group of people who never > wrote any software, but spent most of the budget drawing diagrams that > the implementors never used. Much to my dismay, there are some OO methods that are promoting the same scheme. The "analyst" draw nice pretty little diagrams, and even run them through simulators to "prove" that they work. These diagrams are then run through a program that generates code. Programmers who maintain that code generator have to make sure that the "right" code is generated. They have to make the program work. In another case, I have worked with a client who had a bunch of "architects" doing nothing but drawing pretty Booch diagrams and then throwing them over the wall to a bunch of programmers. The programmers hated the architects and ignored what they produced. > > In fact IMHO an OO team has no place for anyone who cannot do all > three tasks. [Analysis, Design, and Implementation] Agreed, emphatically. > Jim Coplein wrote an excellent pattern called > 'Architect also Implements' which covers very nicely the reasoning > behind not allowing non-implementors to design systems. Software architects who do not implement will be ignored by the people who actually *do* implement. An architect cannot be effective unless he/she really understands the problems that the implementors are facing today, now, this minute. -- Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (847) 918-1004 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-04 0:00 ` Robert C. Martin @ 1996-12-04 0:00 ` Dr. Richard Botting 1996-12-05 0:00 ` Tom Bushell 1996-12-05 0:00 ` Piercarlo Grandi 2 siblings, 0 replies; 209+ messages in thread From: Dr. Richard Botting @ 1996-12-04 0:00 UTC (permalink / raw) (Followups trimmed to comp.object and comp.software-eng) Robert C. Martin (rmartin@oma.com) wrote: : In another case, I have worked with a client who had a bunch of : "architects" doing nothing but drawing pretty Booch diagrams and : then throwing them over the wall to a bunch of programmers. The : programmers hated the architects and ignored what they produced. Software people have four traditional ways of handling any problems: (1) ignore it (2) invent a tool (3) try to be methodical (4) define your program to be the solution and standardize it. OO seems to have inheritted these virtual methods. (HHOS) -- dick botting http://www.csci.csusb.edu/dick/signature.html Disclaimer: CSUSB may or may not agree with this message. Copyright(1996): Copy freely but say where it came from. I have nothing to sell, and I'm giving it away. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-04 0:00 ` Robert C. Martin 1996-12-04 0:00 ` Dr. Richard Botting @ 1996-12-05 0:00 ` Tom Bushell 1996-12-05 0:00 ` Piercarlo Grandi ` (6 more replies) 1996-12-05 0:00 ` Piercarlo Grandi 2 siblings, 7 replies; 209+ messages in thread From: Tom Bushell @ 1996-12-05 0:00 UTC (permalink / raw) On Wed, 04 Dec 1996 08:45:22 -0600, rmartin@oma.com (Robert C. Martin) wrote: >harry@matilda.alt.net.au (Harry Protoolis) wrote: > >> The traditional techniques all suffered from a number of significant >> flaws. Perhaps the most damaging one was what I (rather unkindly) think >> of as 'The glorification of idiots' phenomenon. What I mean by this is >> that projects were typically infested by a group of people who never >> wrote any software, but spent most of the budget drawing diagrams that >> the implementors never used. > >Much to my dismay, there are some OO methods that are promoting >the same scheme. The "analyst" draw nice pretty little diagrams, and >even run them through simulators to "prove" that they work. These >diagrams are then run through a program that generates code. Programmers >who maintain that code generator have to make sure that the "right" code >is generated. They have to make the program work. It is my growing opinion that this is a fundamental problem with all "formal" design methods, not just OO design. The effort involved in doing the design is as great or greater than doing the construction (coding). Contrast this with doing the blueprints for a bridge - the design effort is orders of magnitude cheaper than the construction. (Or so I believe - a civil engineer might correct me on this). Also, the OO design models I've studied don't seem to be very good maps of actual real world systems - there seems to be a big gap between high level architecture and running code. I believe there should be a fairly smooth continuim from high level to low level of detail. I'm starting to believe that design and code don't make sense as separate entities - the design should _become_ the code - the design documents for an implemented system are used as the foundation of the code, and then regenerated from the code. Major benefits would be that design work would not be discarded because it was too difficult to bring it up to date with reality. Therefore, the design should never get out of synch. This a similar idea to reverse engineering, but not identical. If anyone has knows of tools that would facilitate this approach, I'd certainly be interested. I've done some very simple prototypes, and hope to work on the idea in future (when I have more time - Hah!). -Tom ---------------------------------------------------------- Tom Bushell * Custom Software Development Telekinetics * Process Improvement Consulting 2653 Highway 202 * Technical Writing RR#1, Elmsdale, NS B0N 1M0 (902)632-2772 Email: tbushell@fox.nstn.ns.ca ---------------------------------------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Tom Bushell @ 1996-12-05 0:00 ` Piercarlo Grandi 1996-12-06 0:00 ` Tom Bushell 1996-12-05 0:00 ` Marnix Klooster ` (5 subsequent siblings) 6 siblings, 1 reply; 209+ messages in thread From: Piercarlo Grandi @ 1996-12-05 0:00 UTC (permalink / raw) >>> "tbushell" == Tom Bushell <tbushell@fox.nstn.ns.ca> writes: tbushell> On Wed, 04 Dec 1996 08:45:22 -0600, rmartin@oma.com (Robert tbushell> C. Martin) wrote> >> harry@matilda.alt.net.au (Harry Protoolis) wrote: harry> The traditional techniques all suffered from a number of harry> significant flaws. Perhaps the most damaging one was what I harry> (rather unkindly) think of as 'The glorification of idiots' harry> phenomenon. What I mean by this is that projects were typically harry> infested by a group of people who never wrote any software, but harry> spent most of the budget drawing diagrams that the implementors harry> never used. But such people are not at all idiots: they are usually the cleverest people on the project, from many points of view, especially self-interest. :-) rmartin> Much to my dismay, there are some OO methods that are promoting rmartin> the same scheme. The "analyst" draw nice pretty little rmartin> diagrams, and even run them through simulators to "prove" that rmartin> they work. These diagrams are then run through a program that rmartin> generates code. Programmers who maintain that code generator rmartin> have to make sure that the "right" code is generated. They rmartin> have to make the program work. Both of these observations seem to me rather realistic, from direct and indirect observation of actual projects. tbushell> It is my growing opinion that this is a fundamental problem tbushell> with all "formal" design methods, not just OO design. This is in part what has made formal methods (as in correctness proofs/verification) rather less popular than perhaps they should be: the ``formal'' bit is as large as, and usually as unreliable as, the ``informal'' bit of a project (getting a specification or a proof right is often about as hard, and sometimes harder, as getting the program itself right) tbushell> The effort involved in doing the design is as great or greater tbushell> than doing the construction (coding). That's quite well often the case -- now, if the design was _useful_, then that would not be a problem. Unfortunately analisyses or designs are often rather dramatically decoupled from each other and implementation, for both technical and sociological (for example inane adherence to the waterfall model) reasons, and so that effort is usually largely wasted. *If* analisys and design efforts were conducted in resonance with each other and implementation, then spending more effort on those than coding would be all fine and actually rather useful, for formulating solutions in more abstract terms usually makes them easier to maintain and modify. tbushell> Contrast this with doing the blueprints for a bridge - the tbushell> design effort is orders of magnitude cheaper than the tbushell> construction. (Or so I believe - a civil engineer might tbushell> correct me on this). It is usually _cheaper_, but on the other hand it might take _longer_. Developing and then ``debugging'' a bridge design is a long and difficult process, that involves a large number of considerations in different fields, from economics to demographics to aestetics. tbushell> Also, the OO design models I've studied don't seem to be very tbushell> good maps of actual real world systems - there seems to be a tbushell> big gap between high level architecture and running code. I tbushell> believe there should be a fairly smooth continuim from high tbushell> level to low level of detail. Why? tbushell> I'm starting to believe that design and code don't make sense tbushell> as separate entities - the design should _become_ the code - tbushell> the design documents for an implemented system are used as the tbushell> foundation of the code, and then regenerated from the code. tbushell> Major benefits would be that design work would not be tbushell> discarded because it was too difficult to bring it up to date tbushell> with reality. Therefore, the design should never get out of tbushell> synch. This a similar idea to reverse engineering, but not tbushell> identical. This seems a bit fuzzy as a description, but reminds me of the ``corroboration'' approach from Dijkstra to program correctness: if one develops programs using methodical techniques _starting_ from their ``proof'', then the correctness of the program is highly corroborated by such a process. tbushell> If anyone has knows of tools that would facilitate this tbushell> approach, I'd certainly be interested. I've done some very tbushell> simple prototypes, and hope to work on the idea in future tbushell> (when I have more time - Hah!). But OO is in large part about this: the ``high level'' modules/classes/prototypes are supposed to capture the essence of the design. Pointing some sort of OO program browser to a program source and removing from the picture the lower levels of abstraction *ought* to reveal the design. This *ought* to be the case with structured programming methods in general, and with OO in particular it should be even more pleasant because of the disciplined modularization of the program it entails. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Piercarlo Grandi @ 1996-12-06 0:00 ` Tom Bushell 1996-12-06 0:00 ` David Bradley 1996-12-08 0:00 ` Piercarlo Grandi 0 siblings, 2 replies; 209+ messages in thread From: Tom Bushell @ 1996-12-06 0:00 UTC (permalink / raw) On 05 Dec 1996 22:30:40 +0000, pcg@aber.ac.uk (Piercarlo Grandi) wrote: >*If* analisys and design efforts were conducted in resonance with each >other and implementation, then spending more effort on those than coding >would be all fine and actually rather useful, I agree that the effort is useful. But my gut feeling is that with better (and apparently undiscovered, as yet) processes and tools, the high level design activity should be about 10% of the total project, not around 50%. >tbushell> Contrast this with doing the blueprints for a bridge - the >tbushell> design effort is orders of magnitude cheaper than the >tbushell> construction. (Or so I believe - a civil engineer might >tbushell> correct me on this). > >It is usually _cheaper_, but on the other hand it might take _longer_. I assume this is because the design is the work of a much smaller team, whose only physical output is computer models or paper. This is my point - other engineering disciplines appear to routinely put much less total effort into design, with much greater success. I guess this is just the positive result of greater maturity as a discipline. >tbushell> Also, the OO design models I've studied don't seem to be very >tbushell> good maps of actual real world systems - there seems to be a >tbushell> big gap between high level architecture and running code. I >tbushell> believe there should be a fairly smooth continuim from high >tbushell> level to low level of detail. > >Why? Why not? ;-) (Don't know what you're asking here...) >But OO is in large part about this: the ``high level'' >modules/classes/prototypes are supposed to capture the essence of the >design. Pointing some sort of OO program browser to a program source and >removing from the picture the lower levels of abstraction *ought* to >reveal the design. This *ought* to be the case with structured >programming methods in general, and with OO in particular it should be >even more pleasant because of the disciplined modularization of the >program it entails. Absolutely! But why doesn't it work out that way? -Tom ---------------------------------------------------------- Tom Bushell * Custom Software Development Telekinetics * Process Improvement Consulting 2653 Highway 202 * Technical Writing RR#1, Elmsdale, NS B0N 1M0 (902)632-2772 Email: tbushell@fox.nstn.ns.ca ---------------------------------------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-06 0:00 ` Tom Bushell @ 1996-12-06 0:00 ` David Bradley 1996-12-08 0:00 ` Piercarlo Grandi 1 sibling, 0 replies; 209+ messages in thread From: David Bradley @ 1996-12-06 0:00 UTC (permalink / raw) >I assume this is because the design is the work of a much smaller >team, whose only physical output is computer models or paper. This is >my point - other engineering disciplines appear to routinely put much >less total effort into design, with much greater success. I guess >this is just the positive result of greater maturity as a discipline. or the result of a more complex field. -------------------------------------------- David Bradley davidb@datalytics.com Software Engineer Datalytics, Inc. http://www.datalytics.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-06 0:00 ` Tom Bushell 1996-12-06 0:00 ` David Bradley @ 1996-12-08 0:00 ` Piercarlo Grandi 1996-12-10 0:00 ` Piercarlo Grandi ` (2 more replies) 1 sibling, 3 replies; 209+ messages in thread From: Piercarlo Grandi @ 1996-12-08 0:00 UTC (permalink / raw) >>> "tbushell" == Tom Bushell <tbushell@fox.nstn.ns.ca> writes: tbushell> On 05 Dec 1996 22:30:40 +0000, pcg@aber.ac.uk (Piercarlo tbushell> Grandi) wrote: pcg> *If* analisys and design efforts were conducted in resonance with pcg> each other and implementation, then spending more effort on those pcg> than coding would be all fine and actually rather useful, tbushell> I agree that the effort is useful. But my gut feeling is that tbushell> with better (and apparently undiscovered, as yet) processes tbushell> and tools, the high level design activity should be about 10% tbushell> of the total project, not around 50%. Perhaps the reverse: if the tools were really advanced, perhaps including a program generator (and despite claims to the contrary no such thing has been yet produced), then high level design activity would be almost all the project. As things stand, human work on the ``lower'' levels of a project is indispensable, and communication problems between the humans doing the various levels of abstraction, if the total effort is divided in groups corresponding to such levels of abstraction, can cause embarassing problems, as Robert Martin has always observed. tbushell> Contrast this with doing the blueprints for a bridge - the tbushell> design effort is orders of magnitude cheaper than the tbushell> construction. (Or so I believe - a civil engineer might tbushell> correct me on this). pcg> It is usually _cheaper_, but on the other hand it might take pcg> _longer_. tbushell> I assume this is because the design is the work of a much tbushell> smaller team, whose only physical output is computer models or tbushell> paper. Not quite, because while _building_ the bridge is an almost-mechanical project, designing it requires a lot of hard thought, and consultation with users, and in particular lots of iterations and refinements. However designing a bridge and building it are not a good analogy for analysis/design and vs. coding; more like an analogy for all three of analisys/design/coding vs. execution. Naturally building a bridge from blueprints is not quite as mechanical as executing a program, for bridges are built by human teams using quite but not-so-precise blueprints. Still it has the characteristics of execution: an abstraction is turned into an instance (and potentially many instances, in the case of things other than bridges of course). tbushell> This is my point - other engineering disciplines appear to tbushell> routinely put much less total effort into design, with much tbushell> greater success. I guess this is just the positive result of tbushell> greater maturity as a discipline. Well, my impression is exactly the opposite: that the design of material entities like a new car or an airplane model requires immense amount of money and time, as compared to almost any software project, and as many iterations, and as much debugging, if not more, and then there are as many *design* bugs (as opposed to manufacturing defects) in the finished products. The saving grace is that cars and other physical systems like a building (but surely not airplanes) are usually, but not often simpler than doing software. Even in *cost* designing a new car or airplane can be a significantly large part of the cost of each instance of the design. I would even argue that the percentage of the sale price of instances that repays the development cost can be significantly higher for cars or airplanes than for software. Then while a large part of the sale price covers instantion costs for cars and airplanes, the instantiation costs of software are very small, and most of the sale price covers marketing expenses and profit; in this software is more like soft drinks and perfumes, physical products sold on their intangible value, than cars or airplanes. tbushell> Also, the OO design models I've studied don't seem to be very tbushell> good maps of actual real world systems - there seems to be a tbushell> big gap between high level architecture and running code. I This is a good reason why architectures as maps of real world system are not such a good idea. tbushell> believe there should be a fairly smooth continuim from high tbushell> level to low level of detail. piercarl> Why? tbushell> Why not? ;-) (Don't know what you're asking here...) I am asking for any argument to support the statements you make. You support your observations with reference to "my gut feeling", "Or so I believe", and "I believe there should be". This is all fine, but then you should provide some argument as to why your gut feelings or beliefs are; for they are about some points where plausibility can work either way, and it's hard to trust one's own instincts in such matter. pcg> But OO is in large part about this: the ``high level'' pcg> modules/classes/prototypes are supposed to capture the essence of pcg> the design. Pointing some sort of OO program browser to a program pcg> source and removing from the picture the lower levels of pcg> abstraction *ought* to reveal the design. This *ought* to be the pcg> case with structured programming methods in general, and with OO in pcg> particular it should be even more pleasant because of the pcg> disciplined modularization of the program it entails. tbushell> Absolutely! But why doesn't it work out that way? Because achieving this requires hard thinking. This is typically beyond the state of the art. Or perhaps because the rather vague statements by those who believe in ``silver bullets'', in particular those with ``real world modeling'' on them, mean that many people don't focus hard enough on the structure of programs _as such_; there is evidence as to what is a good structure for a model of the ``real world'', and then that this would also be a good structure for a program. There is instead some sparse but good evidence about what is a better structure for a program as such. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-08 0:00 ` Piercarlo Grandi @ 1996-12-10 0:00 ` Piercarlo Grandi 1996-12-10 0:00 ` Todd Hoff 1996-12-11 0:00 ` Tom Bushell 2 siblings, 0 replies; 209+ messages in thread From: Piercarlo Grandi @ 1996-12-10 0:00 UTC (permalink / raw) >>> "piercarl" == Piercarlo Grandi <piercarl@sabi.demon.co.uk> writes: piercarl> Or perhaps because the rather vague statements by those who piercarl> believe in ``silver bullets'', in particular those with ``real piercarl> world modeling'' on them, mean that many people don't focus piercarl> hard enough on the structure of programs _as such_; there is piercarl> evidence as to what is a good structure for a model of the ^ | little piercarl> ``real world'', and then that this would also be a good piercarl> structure for a program. There is instead some sparse but good piercarl> evidence about what is a better structure for a program as piercarl> such. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-08 0:00 ` Piercarlo Grandi 1996-12-10 0:00 ` Piercarlo Grandi @ 1996-12-10 0:00 ` Todd Hoff 1996-12-11 0:00 ` Nick Leaton 1996-12-11 0:00 ` Nick Leaton 1996-12-11 0:00 ` Tom Bushell 2 siblings, 2 replies; 209+ messages in thread From: Todd Hoff @ 1996-12-10 0:00 UTC (permalink / raw) Piercarlo Grandi wrote: > Perhaps the reverse: if the tools were really advanced, perhaps > including a program generator (and despite claims to the contrary no > such thing has been yet produced), then high level design activity would > be almost all the project. If you mean a magic machine that eats a spec and spits out perfect code for a target then you are right, no such thing has been produced. But i have created many times, as have others, domain specific languages where custom made code generators can be plugged in that automate large chunks of a system. Programmers can specify what they want in the language and a few people in the project can work on the code generators for the features. Works like a charm. Unfortunatetly it is not "coding" so most managers and programmers see such approaches as a waste of time. ------------------------------------------------------------- tmh@possibility.com | The loyalty of small men can be http://www.possibility.com | bought cheaply, for greed has no | pride. - Michael Kube-McDowell ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-10 0:00 ` Todd Hoff @ 1996-12-11 0:00 ` Nick Leaton 1996-12-11 0:00 ` Matt Kennel 1996-12-12 0:00 ` Piercarlo Grandi 1996-12-11 0:00 ` Nick Leaton 1 sibling, 2 replies; 209+ messages in thread From: Nick Leaton @ 1996-12-11 0:00 UTC (permalink / raw) Piercarlo Grandi wrote: > Perhaps the reverse: if the tools were really advanced, perhaps > including a program generator (and despite claims to the contrary no > such thing has been yet produced), then high level design activity would > be almost all the project. Available now, called a programer. -- Nick ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-11 0:00 ` Nick Leaton @ 1996-12-11 0:00 ` Matt Kennel 1996-12-12 0:00 ` Piercarlo Grandi 1 sibling, 0 replies; 209+ messages in thread From: Matt Kennel @ 1996-12-11 0:00 UTC (permalink / raw) Nick Leaton (nickle@calfp.co.uk) wrote: : Piercarlo Grandi wrote: : > Perhaps the reverse: if the tools were really advanced, perhaps : > including a program generator (and despite claims to the contrary no : > such thing has been yet produced), then high level design activity would : > be almost all the project. : Available now, called a programer. Exactamundo. The 'tool' is known as a "programming language". I don't understand the obsession with "high level design tools" outside programming languages. Programming langauges *are* the proper "high level design tool", and despite seeming fuddy-duddy and old-fashioned, progress in programming language has always been, and will continue to be, the most potent means to deliver the fruits of research to programmers. If you take as an axiom that "humans will always have to make some decisions" then this conclusion will follow. The real improvements in programming come when interesting new concepts are made into technology. : -- : Nick -- Matthew B. Kennel/mbk@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/ I would not, could not SAVE ON PHONE, |================================== I would not, could not BUY YOUR LOAN, |The US Government does not like I would not, could not MAKE MONEY FAST, |spam either. It is ILLEGAL! I would not, could not SEND NO CA$H, |USC Title 47, section 227 I would not, could not SEE YOUR SITE, |p (b)(1)(C) www.law.cornell.edu/ I would not, could not EAT VEG-I-MITE, | /uscode/47/227.html I do *not* *like* GREEN CARDS AND SPAM! |================================== M A D - I - A M! ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-11 0:00 ` Nick Leaton 1996-12-11 0:00 ` Matt Kennel @ 1996-12-12 0:00 ` Piercarlo Grandi 1 sibling, 0 replies; 209+ messages in thread From: Piercarlo Grandi @ 1996-12-12 0:00 UTC (permalink / raw) >>> "nickle" == Nick Leaton <nickle@calfp.co.uk> writes: nickle> Piercarlo Grandi wrote: pcg> Perhaps the reverse: if the tools were really advanced, perhaps pcg> including a program generator (and despite claims to the contrary pcg> no such thing has been yet produced), then high level design pcg> activity would be almost all the project. nickle> Available now, called a programer. rmartin> In another case, I have worked with a client who had a bunch rmartin> of "architects" doing nothing but drawing pretty Booch rmartin> diagrams and then throwing them over the wall to a bunch of rmartin> programmers. The programmers hated the architects and rmartin> ignored what they produced. Unfortunately, no matter how intensely so many managers wishfully think so (note that I am implying that you are a ``suit'' or that you wishfully think so, just that such wishful thinking is common among them), programmers are not "tools", and often not even "really advanced" ones :-). That programmers are not tools is indeed the reason which explains Robert Martin's observation that tossing buble diagrams over the wall does not work. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-10 0:00 ` Todd Hoff 1996-12-11 0:00 ` Nick Leaton @ 1996-12-11 0:00 ` Nick Leaton 1 sibling, 0 replies; 209+ messages in thread From: Nick Leaton @ 1996-12-11 0:00 UTC (permalink / raw) > If you mean a magic machine that eats a spec and > spits out perfect code for a target then you are right, > no such thing has been produced. But i have created many > times, as have others, domain specific languages where > custom made code generators can be plugged in that automate > large chunks of a system. Programmers can specify what > they want in the language and a few people in the project > can work on the code generators for the features. Works > like a charm. Unfortunatetly it is not "coding" so most > managers and programmers see such approaches as a > waste of time. Sometimes this can be a superb techinique. For example interfacing with a DB. Write a schema file. Your code generator spits out code from the schema file. If you have a bug in your design, it is easy to change the generator, and fix all the relavent code. -- Nick ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-08 0:00 ` Piercarlo Grandi 1996-12-10 0:00 ` Piercarlo Grandi 1996-12-10 0:00 ` Todd Hoff @ 1996-12-11 0:00 ` Tom Bushell 2 siblings, 0 replies; 209+ messages in thread From: Tom Bushell @ 1996-12-11 0:00 UTC (permalink / raw) On 08 Dec 1996 18:44:08 +0000, piercarl@sabi.demon.co.uk (Piercarlo Grandi) wrote: >tbushell> I agree that the effort is useful. But my gut feeling is that >tbushell> with better (and apparently undiscovered, as yet) processes >tbushell> and tools, the high level design activity should be about 10% >tbushell> of the total project, not around 50%. > >Perhaps the reverse: if the tools were really advanced, perhaps >including a program generator (and despite claims to the contrary no >such thing has been yet produced), then high level design activity would >be almost all the project. Good point, although I suspect the bulk of the effort would be in what is currently called "detailed" design. This is what I would like to see happen. >However designing a bridge and building it are not a good analogy for >analysis/design and vs. coding; more like an analogy for all three of >analisys/design/coding vs. execution. I _think_ you are saying you believe _building_ a bridge is analogous _executing_ a program. If so, my reply would be that executing a program is more like opening a bridge to traffic - construction is complete and it has been turned over to it's intended users. >Well, my impression is exactly the opposite: that the design of material >entities like a new car or an airplane model requires immense amount of >money and time, as compared to almost any software project, and as many >iterations, and as much debugging, if not more, and then there are as >many *design* bugs (as opposed to manufacturing defects) in the finished >products. You may be right. I've never seen any statistics on how much of the new product development effort can be attributed to design, but I know it is significant. >tbushell> Also, the OO design models I've studied don't seem to be very >tbushell> good maps of actual real world systems - there seems to be a >tbushell> big gap between high level architecture and running code. I > >This is a good reason why architectures as maps of real world system are >not such a good idea. Interesting point. If you are saying that architecture/civil engineering are perhaps not the best fields to look to for inspiration, I'm starting to agree with you. Seems there may be more profit in looking to mechanical engineering and biology - both deal with much more dynamic real world objects. A software system is more like a machine or an organism than like a bridge. Thanks for that insight! > >tbushell> believe there should be a fairly smooth continuim from high >tbushell> level to low level of detail. The point I was trying to emphasize was my perception that there seems to be a big chasm between the high level design models currently advocated, and running code. Perhaps this is why "over the wall" processes fail - only the architect has enough understanding to make the leap, so he/she must also implement. This makes me suspect one or more of the following are true: 1. Current high level design models are inappropriate 2. Additional high level design models are required to supplement existing models 3. "Intermediate" design models are required to bridge the gap between high level and detailed design/coding. >I am asking for any argument to support the statements you make. You >support your observations with reference to "my gut feeling", "Or so I >believe", and "I believe there should be". Quite deliberate choice of words on my part. My intuitions are _usually_ correct, which has served me well in predicting technological trends. But I have only my limited experience to go on with modern design methodologies, and was trying to get some harder data, or at least anecdotal evidence to substantiate or refute my hunches. >tbushell> Absolutely! But why doesn't it work out that way? > >Because achieving this requires hard thinking. This is typically beyond >the state of the art. > >Or perhaps because the rather vague statements by those who believe in >``silver bullets'', in particular those with ``real world modeling'' on >them, mean that many people don't focus hard enough on the structure of >programs _as such_; there is evidence as to what is a good structure for >a model of the ``real world'', and then that this would also be a good >structure for a program. There is instead some sparse but good evidence >about what is a better structure for a program as such. Again, a good point. I read this to mean you might be in agreement with my point #2 above about current models being insufficient. Perhaps we should be using software patterns to constrain the allowable design models that can be produced, so they will be more likely to be implementable. -Tom ---------------------------------------------------------- Tom Bushell * Custom Software Development Telekinetics * Process Improvement Consulting 2653 Highway 202 * Technical Writing RR#1, Elmsdale, NS B0N 1M0 (902)632-2772 Email: tbushell@fox.nstn.ns.ca ---------------------------------------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Tom Bushell 1996-12-05 0:00 ` Piercarlo Grandi @ 1996-12-05 0:00 ` Marnix Klooster 1996-12-06 0:00 ` Roger Vossler ` (4 subsequent siblings) 6 siblings, 0 replies; 209+ messages in thread From: Marnix Klooster @ 1996-12-05 0:00 UTC (permalink / raw) tbushell@fox.nstn.ns.ca (Tom Bushell) wrote: > It is my growing opinion that this is a fundamental problem with all > "formal" design methods, not just OO design. The effort involved in > doing the design is as great or greater than doing the construction > (coding). Contrast this with doing the blueprints for a bridge - the > design effort is orders of magnitude cheaper than the construction. > (Or so I believe - a civil engineer might correct me on this). Also, > the OO design models I've studied don't seem to be very good maps of > actual real world systems - there seems to be a big gap between high > level architecture and running code. I believe there should be a > fairly smooth continuim from high level to low level of detail. Couldn't agree with you more. > I'm starting to believe that design and code don't make sense as > separate entities - the design should _become_ the code - the design > documents for an implemented system are used as the foundation of the > code, and then regenerated from the code. Major benefits would be > that design work would not be discarded because it was too difficult > to bring it up to date with reality. Therefore, the design should > never get out of synch. This a similar idea to reverse engineering, > but not identical. One approach in the direction you sketch is the formal method called the "refinement calculus". Essentially, a (formal) specification is considered to be a very high-level non-executable program, and programming tries to `refine' that program to an equivalent one that is executable. The refinement calculus gives formal proof rules with which refinements can be proven correct. Therefore, the side-effect of developing a program this way is a proof that it meets its specification. In other words, we have a `provably correct program.' > If anyone has knows of tools that would facilitate this approach, I'd > certainly be interested. I've done some very simple prototypes, and > hope to work on the idea in future (when I have more time - Hah!). Because of the emphasis on proof, the refinement calculus requires more mathematical skills of the programmer than other methods. Also, for larger programs having some kind of proof support tool is a necessity. Finally, it often happens that the specification must be changed halfway. With proper tool support it should be easy to check which refinements still hold, and which don't. Such tools are under development; try the "Formal methods" web page at http://www.comlab.ox.ac.uk/archive/formal-methods.html If you want to know more on the refinement calculus, you could begin with Carroll Morgan, "Programming from Specifications", Second Edition, Prentice-Hall, 1994, ISBN 0-13-123274-6. > -Tom Groetjes, <>< Marnix -- Marnix Klooster | If you reply to this post, marnix@worldonline.nl | please send me an e-mail copy. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Tom Bushell 1996-12-05 0:00 ` Piercarlo Grandi 1996-12-05 0:00 ` Marnix Klooster @ 1996-12-06 0:00 ` Roger Vossler 1996-12-10 0:00 ` Tom Bushell 1996-12-06 0:00 ` Mukesh Prasad ` (3 subsequent siblings) 6 siblings, 1 reply; 209+ messages in thread From: Roger Vossler @ 1996-12-06 0:00 UTC (permalink / raw) Tom Bushell wrote: > It is my growing opinion that this is a fundamental problem with all > "formal" design methods, not just OO design. The effort involved in > doing the design is as great or greater than doing the construction <snip> > I'm starting to believe that design and code don't make sense as > separate entities - the design should _become_ the code - the design > documents for an implemented system are used as the foundation of the > code, and then regenerated from the code. Major benefits would be <snip> > If anyone has knows of tools that would facilitate this approach, I'd > certainly be interested. I've done some very simple prototypes, and > hope to work on the idea in future (when I have more time - Hah!). IMHO, this is more of problem with large CASE tools or design systems than it is with design per say. As I understand it from the OO wizards, start with a small number of use-cases in order to understand the problem, and if you go OO subsequently, then do some CRC card modeling. Thus, all you need for a start is a stack of 3x5 index cards, pencil, paper, and a couple of good books. Peter Coad has a lot of good things to say about this. Then, when you understand what you are doing, commmit to the CASE swamp of your choice. The problem is that people first buy a killer tool chest and spend large numbers of hour understanding how to use the beast and even more hours stuffing a data base only to discover thay they have created a big mess. Cheers, Roger Vossler (vossler@csn.net) ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-06 0:00 ` Roger Vossler @ 1996-12-10 0:00 ` Tom Bushell 1996-12-10 0:00 ` Roger Vossler 1996-12-11 0:00 ` Todd Knarr 0 siblings, 2 replies; 209+ messages in thread From: Tom Bushell @ 1996-12-10 0:00 UTC (permalink / raw) On Fri, 06 Dec 1996 14:45:05 -0600, Roger Vossler <vossler@csn.net> wrote: >Then, when you understand what you are doing, commmit >to the CASE swamp of your choice. > >The problem is that people first buy a killer tool chest and spend >large numbers of hour understanding how to use the beast and even >more hours stuffing a data base only to discover thay they have >created a big mess. Agreed. But I think there _may_ be additional, perhaps more fundamental problems: 1. The design/implementation dichotomy that works well in other engineering disciplines does not map to software. 2. The design representations advocated by the gurus are not appropriate or sufficient for real systems - they don't map to the "code" in a useful way. Think we've got a new thread here - "What's wrong with formal design?" -Tom ---------------------------------------------------------- Tom Bushell * Custom Software Development Telekinetics * Process Improvement Consulting 2653 Highway 202 * Technical Writing RR#1, Elmsdale, NS B0N 1M0 (902)632-2772 Email: tbushell@fox.nstn.ns.ca ---------------------------------------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-10 0:00 ` Tom Bushell @ 1996-12-10 0:00 ` Roger Vossler 1996-12-12 0:00 ` Tom Bushell 1996-12-12 0:00 ` Don Harrison 1996-12-11 0:00 ` Todd Knarr 1 sibling, 2 replies; 209+ messages in thread From: Roger Vossler @ 1996-12-10 0:00 UTC (permalink / raw) Tom Bushell wrote: > 1. The design/implementation dichotomy that works well in other > engineering disciplines does not map to software. > > 2. The design representations advocated by the gurus are not > appropriate or sufficient for real systems - they don't map to the > "code" in a useful way. > > Think we've got a new thread here - "What's wrong with formal design?" > > -Tom As far as point 1 is concerned, I would like to known more about where engineering design/implementation dichotomy breaks down with software. OTOH, I have no doubt that software could use a strong dose of engineering discipline. Concerning point 2: wow, is this ever true. I read the books and papers by the gurus and then program using several different languages, frameworks, IDEs, etc. with the result that it takes real work to bridge the gap. A lot of arm waving takes place between OOA/D and working with a real system. Roger Vossler, vossler@csn.net ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-10 0:00 ` Roger Vossler @ 1996-12-12 0:00 ` Tom Bushell 1996-12-12 0:00 ` Don Harrison 1 sibling, 0 replies; 209+ messages in thread From: Tom Bushell @ 1996-12-12 0:00 UTC (permalink / raw) On Tue, 10 Dec 1996 23:17:33 -0600, Roger Vossler <vossler@csn.net> wrote: >As far as point 1 is concerned, I would like to known more about >where engineering design/implementation dichotomy breaks down >with software. Tried to explain this in another post - hope it makes sense! >OTOH, I have no doubt that software could use >a strong dose of engineering discipline. My belief as well. Just think we have to choose carefully what we steal from other disciplines. >Concerning point 2: wow, is this ever true. I read the books and >papers by the gurus and then program using several different >languages, frameworks, IDEs, etc. with the result that it takes >real work to bridge the gap. A lot of arm waving takes place >between OOA/D and working with a real system. Glad I'm not the only one with bruises from the leap. (And as others have related, sometimes it's more like a Roadrunner cartoon - that looooong plummet to the bottom of the canyon...) -Tom ---------------------------------------------------------- Tom Bushell * Custom Software Development Telekinetics * Process Improvement Consulting 2653 Highway 202 * Technical Writing RR#1, Elmsdale, NS B0N 1M0 (902)632-2772 Email: tbushell@fox.nstn.ns.ca ---------------------------------------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-10 0:00 ` Roger Vossler 1996-12-12 0:00 ` Tom Bushell @ 1996-12-12 0:00 ` Don Harrison 1 sibling, 0 replies; 209+ messages in thread From: Don Harrison @ 1996-12-12 0:00 UTC (permalink / raw) Roger Vossler wrote: :I have no doubt that software could use :a strong dose of engineering discipline. It already exists. It's called "Design by Contract" a la Eiffel. :) That alone is not sufficient, of course. There are many other factors that can be brought to bear in the development of high quality software, not the least of which are common sense and discipline. Don. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison donh@syd.csa.com.au ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-10 0:00 ` Tom Bushell 1996-12-10 0:00 ` Roger Vossler @ 1996-12-11 0:00 ` Todd Knarr 1996-12-11 0:00 ` Alan Meyer ` (4 more replies) 1 sibling, 5 replies; 209+ messages in thread From: Todd Knarr @ 1996-12-11 0:00 UTC (permalink / raw) In <32a98036.46416970@news.nstn.ca>, tbushell@fox.nstn.ns.ca (Tom Bushell) writes: >1. The design/implementation dichotomy that works well in other >engineering disciplines does not map to software. >Think we've got a new thread here - "What's wrong with formal design?" I think the problem with formal design goes right to your point #1, since in most other enginerring disciplines there *isn't* the strong dichotomy between design and implementation. Think about an architect designing a bridge, and how much he has to know about the actual construction methods and materials involved to come up with a design that can be built without falling down. No self-respecting architect or mechanical engineer would, for instance, decide that stone is pretty and would fit well with the landscape but arches and intermediate support pylons wouldn't, so "we'll build a 1000 foot stone bridge as a single span with no arches under it". All too often, though, the "systems analysts" hand me a design document which I'm supposed to implement which is exactly the programming equivalent of that 1000-foot single-span stone bridge. -- Todd Knarr : tknarr@xmission.com | finger for PGP public key | Member, USENET Cabal ***** Unsolicited commercial e-mail proof-read at $50/message ***** Seriously, I don't want to die just yet. I don't care how good-looking they are, I! don't! want! to! die!" -- Megazone ( UF1 ) ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-11 0:00 ` Todd Knarr @ 1996-12-11 0:00 ` Alan Meyer 1996-12-12 0:00 ` Ell ` (3 subsequent siblings) 4 siblings, 0 replies; 209+ messages in thread From: Alan Meyer @ 1996-12-11 0:00 UTC (permalink / raw) In article <58lbbo$8kl@news.xmission.com>, tknarr@xmission.com wrote... <<snip>> >All too often, though, the "systems analysts" hand me a design document >which I'm supposed to implement which is exactly the programming >equivalent of that 1000-foot single-span stone bridge. I once visited a large municipal government computing shop with 130 people working there. I was told by the boss that as far as he's concerned, his "systems analysts" are to do all the thinking and his programmers, he called them "coders", are just supposed to translate those lofty thoughts into code. He then thought that the reason the average programmer only stayed 18 months (remember that's the average, I wonder what the good ones were doing!) was because that was the nature of the business and programmers were defective people anyway! I personally believe that the division into "analysts" and "programmers" is a dangerous one. If a person can't do both he is likely to do a lot of harm to a project. An "analyst" that doesn't understand programming will often specify impractical designs. A "programmer" that can't understand the needs of the users will often build unusable programs. The best systems always come from people who make it their business to understand the total problem from the point of view of the user, the point of the view of the machine, and everything in between. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-11 0:00 ` Todd Knarr 1996-12-11 0:00 ` Alan Meyer @ 1996-12-12 0:00 ` Ell 1996-12-12 0:00 ` Tom Bushell ` (2 subsequent siblings) 4 siblings, 0 replies; 209+ messages in thread From: Ell @ 1996-12-12 0:00 UTC (permalink / raw) mj@sjx-ixn10.ix.netcom.com> Organization: The Universe Distribution: Alan Meyer (ameyer@ix.netcom.com) wrote: : In article <58lbbo$8kl@news.xmission.com>, tknarr@xmission.com wrote... : <<snip>> : >All too often, though, the "systems analysts" hand me a design document : >which I'm supposed to implement which is exactly the programming : >equivalent of that 1000-foot single-span stone bridge. : I once visited a large municipal government computing shop with 130 people : working there. I was told by the boss that as far as he's concerned, his : "systems analysts" are to do all the thinking and his programmers, he : called them "coders", are just supposed to translate those lofty thoughts : into code. He then thought that the reason the average programmer only : stayed 18 months (remember that's the average, I wonder what the good ones : were doing!) was because that was the nature of the business and programmers : were defective people anyway! Quite a narrow minded manager. : I personally believe that the division into "analysts" and "programmers" is : a dangerous one. If a person can't do both he is likely to do a lot of harm : to a project. An "analyst" that doesn't understand programming will often : specify impractical designs. A "programmer" that can't understand the : needs of the users will often build unusable programs. The best systems : always come from people who make it their business to understand the total : problem from the point of view of the user, the point of the view of the : machine, and everything in between. How about the formulation of an architecture to span the gap? This may or may not require someone who's called an architect. Elliott ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-11 0:00 ` Todd Knarr 1996-12-11 0:00 ` Alan Meyer 1996-12-12 0:00 ` Ell @ 1996-12-12 0:00 ` Tom Bushell [not found] ` <58mubr$i <58p5ou$dkm@news3.digex.net> [not found] ` <32aefdb0..406273038@news.nstn.ca> 4 siblings, 0 replies; 209+ messages in thread From: Tom Bushell @ 1996-12-12 0:00 UTC (permalink / raw) On 11 Dec 1996 03:55:36 GMT, tknarr@xmission.com ( Todd Knarr ) wrote: >I think the problem with formal design goes right to your point #1, >since in most other enginerring disciplines there *isn't* the strong >dichotomy between design and implementation. Guess I wasn't clear about what I meant by "dichotomy". I was referring to the fact that in current practice, the design and the implementation are almost always distinct artifacts. The "design" is a text, drawings, equations, or whatever. The "implementation" is runnable code. Designs are models - static, abstract, incomplete - not usable except as a precursor to implementation. Implementations are dynamic, tangible, detailed - usable in the real world. If you accept this description, then there *is* a dichotomy in most other enginering disciplines as well - the design for a car is the blueprints, mockup, etc. The implementation is the drivable car. This dichotomy may make sense for other engineering disciplines, who must convert the design (which is information, or "bits", to use Negroponte's term) into "atoms". But for software, it's all bits, from design to implementtion! I'm merely speculating that the dichotomy may only exist in software because the disciplines we're thinking about emulating do it that way. Perhaps this is a fundamental mistake, and we need to think of design as an outline, or a scaffold, or a foundation, or whatever other good analogies we can come up with, as opposed to a "model". Perhaps then we will not face so much difficulty and resistance to formal design, because it will become obvious that this is a worthwhile activity. >All too often, though, the "systems analysts" hand me a design document >which I'm supposed to implement which is exactly the programming >equivalent of that 1000-foot single-span stone bridge. This is a very valid point, but in my mind a different issue (although related). In other parts of this thread, we've been talking about the "gap" between design and code - the sense that there's a big leap of abstraction between current design models and implementable systems. I'm not really happy with the way I've explained this, and not even sure I believe my own explanations, but will let it stand until something better occurs to me. -Tom (practicing semantics without a thesaurus _or_ a license) ---------------------------------------------------------- Tom Bushell * Custom Software Development Telekinetics * Process Improvement Consulting 2653 Highway 202 * Technical Writing RR#1, Elmsdale, NS B0N 1M0 (902)632-2772 Email: tbushell@fox.nstn.ns.ca ---------------------------------------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
[parent not found: <58mubr$i <58p5ou$dkm@news3.digex.net>]
* Re: What is wrong with OO ? [not found] ` <58mubr$i <58p5ou$dkm@news3.digex.net> @ 1996-12-13 0:00 ` Nick Leaton 1996-12-25 0:00 ` Weiqi Gao 0 siblings, 1 reply; 209+ messages in thread From: Nick Leaton @ 1996-12-13 0:00 UTC (permalink / raw) : I once visited a large municipal government computing shop with 130 people : working there. I was told by the boss that as far as he's concerned, his : "systems analysts" are to do all the thinking and his programmers, he : called them "coders", are just supposed to translate those lofty thoughts : into code. He then thought that the reason the average programmer only : stayed 18 months (remember that's the average, I wonder what the good ones : were doing!) was because that was the nature of the business and programmers : were defective people anyway! And the analyst spend more time telling the programmers what to do than it takes to produce the code, and since the actual coding is a small part of the overall time it is not suprising they have a high staff turnover. -- Nick ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-13 0:00 ` Nick Leaton @ 1996-12-25 0:00 ` Weiqi Gao 1996-12-25 0:00 ` Matthew S. Whiting ` (2 more replies) 0 siblings, 3 replies; 209+ messages in thread From: Weiqi Gao @ 1996-12-25 0:00 UTC (permalink / raw) Nick Leaton <nickle@calfp.co.uk> wrote in article <32B12311.5D8E@calfp.co.uk>... > : I once visited a large municipal government computing shop with 130 > : people > : working there. I was told by the boss that as far as he's concerned, > : his > : "systems analysts" are to do all the thinking and his programmers, he > : called them "coders", are just supposed to translate those lofty > : thoughts > : into code. He then thought that the reason the average programmer > : only > : stayed 18 months (remember that's the average, I wonder what the good > : ones > : were doing!) was because that was the nature of the business and > : programmers > : were defective people anyway! > > And the analyst spend more time telling the programmers what to do than > it takes to produce the code, and since the actual coding is a small > part of the overall time it is not suprising they have a high staff > turnover. Us coders usually gather together and joke about the mistakes the analysts put into the design, and then turn around and code it exactly the wrong way! Because we are not paid enough to correct the stupid mistakes they made. -- Weiqi Gao weiqigao@crl.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-25 0:00 ` Weiqi Gao @ 1996-12-25 0:00 ` Matthew S. Whiting 1996-12-26 0:00 ` Bob Jarvis 1996-12-26 0:00 ` Mike Rubenstein 2 siblings, 0 replies; 209+ messages in thread From: Matthew S. Whiting @ 1996-12-25 0:00 UTC (permalink / raw) Weiqi Gao wrote: > > Us coders usually gather together and joke about the mistakes the analysts > put into the design, and then turn around and code it exactly the wrong > way! Because we are not paid enough to correct the stupid mistakes they > made. > Glad you said "coder" and not software engineer! Maybe if you DID use your skills rather than intentionally not use them, you'd be better paid. Matt ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-25 0:00 ` Weiqi Gao 1996-12-25 0:00 ` Matthew S. Whiting @ 1996-12-26 0:00 ` Bob Jarvis 1996-12-26 0:00 ` Arthur Gold 1996-12-26 0:00 ` Mike Rubenstein 2 siblings, 1 reply; 209+ messages in thread From: Bob Jarvis @ 1996-12-26 0:00 UTC (permalink / raw) Weiqi Gao <weiqigao@crl.com> wrote in article <01bbf2b8$d2873080$0f0171a5@weiqigao>... > Us coders usually gather together and joke about the mistakes the analysts > put into the design, and then turn around and code it exactly the wrong > way! Because we are not paid enough to correct the stupid mistakes they > made. I encourage you maintain this attitude, and fervently hope you'll soon be working for any firm I have to compete with. -- Bob Jarvis ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-26 0:00 ` Bob Jarvis @ 1996-12-26 0:00 ` Arthur Gold 0 siblings, 0 replies; 209+ messages in thread From: Arthur Gold @ 1996-12-26 0:00 UTC (permalink / raw) When all is said and done: Good programmers write/contibute to good programs. As for the pictures vs. text debate: Text is great for linear/sequential ideas. Pictures are better at expressing relationships. Both are valuable _and_ necessary. So what's wrong with OO? Well put it this way: Issac Stern can make a student violin sound wonderful. At best, I would make a Stradivarius sound horrid. Just my nickel...(inflation) -- Onward, ************** * Artie Gold * ************************************* * agold@bga.com * ArtieGold@aol.com * WWW Home Page: * 74562.1167@compuserve.com * (coming soon!!!!!!!) ************************************* ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-25 0:00 ` Weiqi Gao 1996-12-25 0:00 ` Matthew S. Whiting 1996-12-26 0:00 ` Bob Jarvis @ 1996-12-26 0:00 ` Mike Rubenstein 2 siblings, 0 replies; 209+ messages in thread From: Mike Rubenstein @ 1996-12-26 0:00 UTC (permalink / raw) "Weiqi Gao" <weiqigao@crl.com> wrote: > Nick Leaton <nickle@calfp.co.uk> wrote in article > <32B12311.5D8E@calfp.co.uk>... > > : I once visited a large municipal government computing shop with 130 > > : people > > : working there. I was told by the boss that as far as he's concerned, > > : his > > : "systems analysts" are to do all the thinking and his programmers, he > > : called them "coders", are just supposed to translate those lofty > > : thoughts > > : into code. He then thought that the reason the average programmer > > : only > > : stayed 18 months (remember that's the average, I wonder what the good > > : ones > > : were doing!) was because that was the nature of the business and > > : programmers > > : were defective people anyway! > > > > And the analyst spend more time telling the programmers what to do than > > it takes to produce the code, and since the actual coding is a small > > part of the overall time it is not suprising they have a high staff > > turnover. > > Us coders usually gather together and joke about the mistakes the analysts > put into the design, and then turn around and code it exactly the wrong > way! Because we are not paid enough to correct the stupid mistakes they > made. Which is probably one of the best ways to ensure that you will never be paid enough to correct the stupid mistakes. Michael M Rubenstein ^ permalink raw reply [flat|nested] 209+ messages in thread
[parent not found: <32aefdb0..406273038@news.nstn.ca>]
* Re: What is wrong with OO ? [not found] ` <32aefdb0..406273038@news.nstn.ca> @ 1996-12-14 0:00 ` "Paul E. Bennett" 0 siblings, 0 replies; 209+ messages in thread From: "Paul E. Bennett" @ 1996-12-14 0:00 UTC (permalink / raw) In article <32aefdb0.406273038@news.nstn.ca> tbushell@fox.nstn.ns.ca "Tom Bushell" writes: > On 11 Dec 1996 03:55:36 GMT, tknarr@xmission.com ( Todd Knarr ) > wrote: > > >I think the problem with formal design goes right to your point #1, > >since in most other enginerring disciplines there *isn't* the strong > >dichotomy between design and implementation. > > Guess I wasn't clear about what I meant by "dichotomy". I was > referring to the fact that in current practice, the design and the > implementation are almost always distinct artifacts. The "design" is > a text, drawings, equations, or whatever. The "implementation" is > runnable code. Designs are models - static, abstract, incomplete - > not usable except as a precursor to implementation. Implementations > are dynamic, tangible, detailed - usable in the real world. > > If you accept this description, then there *is* a dichotomy in most > other enginering disciplines as well - the design for a car is the > blueprints, mockup, etc. The implementation is the drivable car. Perfect! I am glad that someone else seems to share my views on this. > This dichotomy may make sense for other engineering disciplines, who > must convert the design (which is information, or "bits", to use > Negroponte's term) into "atoms". But for software, it's all bits, > from design to implementtion! I'm merely speculating that the > dichotomy may only exist in software because the disciplines we're > thinking about emulating do it that way. I have no problem in supporting the dichotomy. To me a Software design is the source listing, which we will all pore over in review meetings and structured walkthroughs, and this is the detailed instructions which will enable someone to perform the implementation phase (like handing the schematics, PCB layouts, components lists and assembly instructions to the equipment manufacturer). > Perhaps this is a fundamental mistake, and we need to think of design > as an outline, or a scaffold, or a foundation, or whatever other good > analogies we can come up with, as opposed to a "model". Perhaps then > we will not face so much difficulty and resistance to formal design, > because it will become obvious that this is a worthwhile activity. Design exists at several levels in all engineering worlds. Concept Design, Prototype Design, Product Design, Industrial Design, Detail Design. Which level you need to be dealing with depends on how far thorugh your design lifecycle you are and what you are designing. > >All too often, though, the "systems analysts" hand me a design document > >which I'm supposed to implement which is exactly the programming > >equivalent of that 1000-foot single-span stone bridge. > > This is a very valid point, but in my mind a different issue (although > related). In other parts of this thread, we've been talking about the > "gap" between design and code - the sense that there's a big leap of > abstraction between current design models and implementable systems. > > I'm not really happy with the way I've explained this, and not even > sure I believe my own explanations, but will let it stand until > something better occurs to me. If someone wants a 1000-foot single-span stone bridge you can build a structure in exotic materials and stone clad it. As long as the customer has not visited the site during construction he will never know. I believe that we might call this "information hiding" in software. This thread has been a particularly long one for me to read today (as I have just returned to my system after a period away working) and all participants have contributed a mixture of interesting ideas and notions, some of which I can relate to easily. We are all going to need a whole range of tools and paradigms to enable us to grasp the essentials of what our customers want from the systems we build for them. One thing we should all learn from the disasters that have occurred in IS design is that failure of projects is a failure of the management of the project. The projects that are successful, despite their use of "bleeding edge" technology and very difficult concepts are those in which project management has been very effective in maintaining discipline and rigour of application in the teams. Choosing an appropriate "lifecycle" model and tools that enable the easy support of such a lifecycle would seem to be more worthy than arguing over which language a project should be done in. I would hope that we all agree that the language should suit the application area and use concepts natural to that domain (Application Specific Languages). The Critical Failure Factors for any project are: Hostile Culture (in the development or client organisation) Poor reporting structures [a most important issue to get right] Over commitment Political Pressures Under-estimated Complexity of problem domain (during initial phases) Poor Consultation Inappropriate Application (ie: Technical fix for management problem) High Staff Turnover Poor Staff Competency Poor Communication Inadequate Testing and Validation Inadequate User Training Insufficient Review Stages [the above list is taken "Software Failure: Management failure" by Stephen Flowers published by John Wiley and Sons ISBN 0-471-95113-7 and describes many IS systems which failed for one reason or another.] The question therefore is how do we avoid thos CFF's? You will notice that one item that does not appear in the list is Changing Requirements. This is a fact of life for engineers of all disciplines. Engineers have to be good at dealing with changes to the requirements and manage them in an orderly manner. Rather than spend money on CASE tools why not buy a decent Change Management Software Package. -- Paul E. Bennett <peb@transcontech.co.uk> Transport Control Technology Ltd. +44 (0)117-9499861 Going Forth Safely ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Tom Bushell ` (2 preceding siblings ...) 1996-12-06 0:00 ` Roger Vossler @ 1996-12-06 0:00 ` Mukesh Prasad 1996-12-10 0:00 ` Tom Bushell 1996-12-06 0:00 ` Carl Weidling ` (2 subsequent siblings) 6 siblings, 1 reply; 209+ messages in thread From: Mukesh Prasad @ 1996-12-06 0:00 UTC (permalink / raw) Tom Bushell wrote: [snip] > I'm starting to believe that design and code don't make sense as > separate entities - the design should _become_ the code - the design > documents for an implemented system are used as the foundation of the > code, and then regenerated from the code. Major benefits would be > that design work would not be discarded because it was too difficult > to bring it up to date with reality. Therefore, the design should > never get out of synch. This a similar idea to reverse engineering, > but not identical. [...] I have seen the term "iterative prototyping" used to formally describe an approach like this. Iterative prototyping means you start from a prototype of the system, written from a very sketchy design (the design may even be just in peoples' heads.) You use your prototype to write an improved design, which you then use to implement improvements to the prototype, which you then use to improve your design.... repeat until your erstwhile "prototype" becomes the "system" with a very closely matching design spec, and everybody is happy. In practice, I have seen a shortened version, the "backward spec", i.e. specifications done from implemenations (with modifications as required) work very well in certain cases. Much better than the strict "implement exactly from spec" approach. I believe these less top-down approaches work better because in a lot of cases, at specification time the product is very vaguely understood. Moreover, many implementation problems are not anticipated well. An actual, physical implementation can sharpen everybody's hazy understanding to the point where actually good design decisions can be made. Thus doing the spec from an initial implementation, and fixing the implementation to match the final spec, can yield much better results overall. Of course, there is no reason why your design couldn't be OO. The problems you describe, I think, are not problems of OO, but rather the problems of trying to do a detailed design without sufficient understanding of the product to be designed and its problems. /Mukesh ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-06 0:00 ` Mukesh Prasad @ 1996-12-10 0:00 ` Tom Bushell 0 siblings, 0 replies; 209+ messages in thread From: Tom Bushell @ 1996-12-10 0:00 UTC (permalink / raw) On Fri, 06 Dec 1996 11:18:43 -0500, Mukesh Prasad <mprasad@dma.isg.mot.com> wrote: > >In practice, I have seen a shortened version, >the "backward spec", i.e. specifications done >from implemenations (with modifications as required) >work very well in certain cases. Much better than the >strict "implement exactly from spec" approach. The problem is that with current tools available to the average developer, this is a manual step. Most shops don't have the discipline to do it, so we end up with the current situation - the only accurate description of the system is the code, which is at too low a level of abstraction to easily develop system level understanding. >I believe these less top-down approaches work better >because in a lot of cases, at specification time >the product is very vaguely understood. Moreover, >many implementation problems are not anticipated well. >An actual, physical implementation can sharpen everybody's >hazy understanding to the point where actually good design >decisions can be made. Agree 100%. >Thus doing the spec from an >initial implementation, and fixing the implementation >to match the final spec, can yield much >better results overall. Even better - eliminate the spec/implementation dichotomy. The spec is just an "outline", if you will, of the implementation, and remains as an intregal part, automatically tracking the implementation and instantly viewable at any time. I don't see any reason why we can't do this - to use Fred Brook's terms, it's just an "accidental" complexity, not an an "essential" one. -Tom ---------------------------------------------------------- Tom Bushell * Custom Software Development Telekinetics * Process Improvement Consulting 2653 Highway 202 * Technical Writing RR#1, Elmsdale, NS B0N 1M0 (902)632-2772 Email: tbushell@fox.nstn.ns.ca ---------------------------------------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Tom Bushell ` (3 preceding siblings ...) 1996-12-06 0:00 ` Mukesh Prasad @ 1996-12-06 0:00 ` Carl Weidling 1996-12-06 0:00 ` Harry Protoolis 1996-12-06 0:00 ` David B. Shapcott [C] 6 siblings, 0 replies; 209+ messages in thread From: Carl Weidling @ 1996-12-06 0:00 UTC (permalink / raw) In article <32a5ceba.81462731@news.nstn.ca>, Tom Bushell <tbushell@fox.nstn.ns.ca> wrote: >On Wed, 04 Dec 1996 08:45:22 -0600, rmartin@oma.com (Robert C. Martin) >wrote: > >>harry@matilda.alt.net.au (Harry Protoolis) wrote: >> >>> The traditional techniques all suffered from a number of significant >>> flaws. Perhaps the most damaging one was what I (rather unkindly) think >>> of as 'The glorification of idiots' phenomenon. What I mean by this is >>> that projects were typically infested by a group of people who never >>> wrote any software, but spent most of the budget drawing diagrams that >>> the implementors never used. >> ...<stuff deleted for brevity -cpw> > >It is my growing opinion that this is a fundamental problem with all >"formal" design methods, not just OO design. The effort involved in >doing the design is as great or greater than doing the construction >(coding). Contrast this with doing the blueprints for a bridge - the >design effort is orders of magnitude cheaper than the construction. ...<more stuff deleted> >I'm starting to believe that design and code don't make sense as >separate entities - the design should _become_ the code - the design >documents for an implemented system are used as the foundation of the ...<rest of previous posting deleted> I remember seeing a documentary about Gothic Cathedrals as examples of engineering. The commentary compared the way models are constructed first nowadays to test a design, and they showed models of cathedrals going through stress tests, but for those medieval masons, the building was also the engineering model. The flying buttresses for instance, were added when the masons saw how wind was blowing down the walls. On the other hand, wasn't there a famous example back in the 70s when 'top-level design' was first being expounded, where some big project for a newspaper or something was designed first and then coded and it worked. I remember this being cited a lot when I first started programming, can anyone recall details or hard facts about that? -- Cleave yourself to logodedaly and you cleave yourself from clarity. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Tom Bushell ` (4 preceding siblings ...) 1996-12-06 0:00 ` Carl Weidling @ 1996-12-06 0:00 ` Harry Protoolis 1996-12-10 0:00 ` Tom Bushell 1996-12-06 0:00 ` David B. Shapcott [C] 6 siblings, 1 reply; 209+ messages in thread From: Harry Protoolis @ 1996-12-06 0:00 UTC (permalink / raw) On Thu, 05 Dec 1996 03:06:57 GMT, Tom Bushell <tbushell@fox.nstn.ns.ca> wrote: >On Wed, 04 Dec 1996 08:45:22 -0600, rmartin@oma.com (Robert C. Martin) >wrote: > >>harry@matilda.alt.net.au (Harry Protoolis) wrote: >> >>> The traditional techniques all suffered from a number of significant >>> flaws. Perhaps the most damaging one was what I (rather unkindly) think >>> of as 'The glorification of idiots' phenomenon. What I mean by this is >>> that projects were typically infested by a group of people who never >>> wrote any software, but spent most of the budget drawing diagrams that >>> the implementors never used. >> >>Much to my dismay, there are some OO methods that are promoting >>the same scheme. The "analyst" draw nice pretty little diagrams, and >>even run them through simulators to "prove" that they work. These >>diagrams are then run through a program that generates code. Programmers >>who maintain that code generator have to make sure that the "right" code >>is generated. They have to make the program work. > >It is my growing opinion that this is a fundamental problem with all >"formal" design methods, not just OO design. The effort involved in >doing the design is as great or greater than doing the construction >(coding). Contrast this with doing the blueprints for a bridge - the >design effort is orders of magnitude cheaper than the construction. >(Or so I believe - a civil engineer might correct me on this). Also, >the OO design models I've studied don't seem to be very good maps of >actual real world systems - there seems to be a big gap between high >level architecture and running code. I believe there should be a >fairly smooth continuim from high level to low level of detail. IMHO, the trick with OO design is to do it *informally* most of the time. What I mean by this is that you sketch out high level architecture and analysis results as high level class diagrams and then give them to the 'implementors' to design and code. The implementation team then does design as a series of informal gatherings around a white board drawing state diagrams, detailed class diagrams, object diagrams etc. You then photocopy and file the whiteboard drawings and let the same group of people code from the hand drawn design. I then quite often reverse-engineer the resulting code and call *that* the formal system design. I do some formal tracking of this design process, but the golden rule is that nothing should get in the way of the creative process. The failure of *all* attempts at formal design is this mistaken belief that anything short of coding can replace coding ... >I'm starting to believe that design and code don't make sense as >separate entities - the design should _become_ the code - the design >documents for an implemented system are used as the foundation of the >code, and then regenerated from the code. Major benefits would be >that design work would not be discarded because it was too difficult >to bring it up to date with reality. Therefore, the design should >never get out of synch. This a similar idea to reverse engineering, >but not identical. My point is that the *design* and the *code* come into existance together. To talk about the design becoming the code implies that it exists before the code in some sense. >If anyone has knows of tools that would facilitate this approach, I'd >certainly be interested. I've done some very simple prototypes, and >hope to work on the idea in future (when I have more time - Hah!). I think that a facinating tool would be a language sensitive drawing tool in which you could switch your view between diagrams and code and write 'code' in either view. H - Harry Protoolis alt.computer pty ltd harry@alt.net.au software development consultants ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-06 0:00 ` Harry Protoolis @ 1996-12-10 0:00 ` Tom Bushell 0 siblings, 0 replies; 209+ messages in thread From: Tom Bushell @ 1996-12-10 0:00 UTC (permalink / raw) On 6 Dec 1996 07:08:24 GMT, harry@matilda.alt.net.au (Harry Protoolis) wrote: >IMHO, the trick with OO design is to do it *informally* most of the >time. What I mean by this is that you sketch out high level architecture >and analysis results as high level class diagrams and then give them to >the 'implementors' to design and code. > >The implementation team then does design as a series of informal >gatherings around a white board drawing state diagrams, detailed class >diagrams, object diagrams etc. You then photocopy and file the >whiteboard drawings and let the same group of people code from the >hand drawn design. Interesting! How many projects have you done this way? >I then quite often reverse-engineer the resulting code and call *that* >the formal system design. Can you give a rough estimate of the level of effort required to do this reverse engineering, as a percentage of total project effort? I assume you believe this is more cost effective than doing a more formal design up front. >My point is that the *design* and the *code* come into existance >together. To talk about the design becoming the code implies that it >exists before the code in some sense. Doesn't this contradict your previous description of the informal process you follow - the first "design" is the hand drawn sketches, which you then give to your coders, who will probably modify the design as they code. So it _does_ exist before the code. Some interesting semantic issues here - what is meant by "design" and "code"? The biggest distinction I tend to make is that a "design" artifact is at a higher level of abstraction, and not runnable; whereas "code" is runnable, and at the lowest level of abstraction. I may have to reconsider these definitions - they tend to blur together with the tools I'm proposing. >I think that a facinating tool would be a language sensitive drawing >tool in which you could switch your view between diagrams and code and >write 'code' in either view. This is very much as I envision it. What set me down this road of thought was my experience doing high level design for the Prograph class library, which was developed here in Nova Scotia. Prograph is a truly visual language *at the code level*, not just a GUI builder tacked onto an evolved version of FORTRAN, like VB/VC++/Delphi et al. This experience opened my eyes to what is possible. If the "code" is a "diagram", then the "design" is just another diagram at a higher level of abstraction, and it should be possible to move back and forth at will. Interestingly enough, another local person, Randy Giffen, has developed a browser that lets you take existing textual Smalltalk code and display it visually, and modify it or write new code totally within the visual environment. He says he hardly ever looks at the textual code any more - it's easier to write in the visual mode, and it's easier to understand existing code that way as well. Haven't had a chance to play with it yet, but the demo he gave was _very_ impressive! So, the pieces are all there, someone just has to put them together. -Tom ---------------------------------------------------------- Tom Bushell * Custom Software Development Telekinetics * Process Improvement Consulting 2653 Highway 202 * Technical Writing RR#1, Elmsdale, NS B0N 1M0 (902)632-2772 Email: tbushell@fox.nstn.ns.ca ---------------------------------------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Tom Bushell ` (5 preceding siblings ...) 1996-12-06 0:00 ` Harry Protoolis @ 1996-12-06 0:00 ` David B. Shapcott [C] 6 siblings, 0 replies; 209+ messages in thread From: David B. Shapcott [C] @ 1996-12-06 0:00 UTC (permalink / raw) In article <32a5ceba.81462731@news.nstn.ca>, Tom Bushell <tbushell@fox.nstn.ns.ca> wrote: > >It is my growing opinion that this is a fundamental problem with all >"formal" design methods, not just OO design. The effort involved in >doing the design is as great or greater than doing the construction >(coding). Contrast this with doing the blueprints for a bridge - the >design effort is orders of magnitude cheaper than the construction. >(Or so I believe - a civil engineer might correct me on this). Also, >the OO design models I've studied don't seem to be very good maps of >actual real world systems - there seems to be a big gap between high >level architecture and running code. I believe there should be a >fairly smooth continuim from high level to low level of detail. > >I'm starting to believe that design and code don't make sense as >separate entities - the design should _become_ the code - the design >documents for an implemented system are used as the foundation of the >code, and then regenerated from the code. Major benefits would be >that design work would not be discarded because it was too difficult >to bring it up to date with reality. Therefore, the design should >never get out of synch. This a similar idea to reverse engineering, >but not identical. In bridge engineering, design and construction take place in different mediums, unlike software engineering. A software engineer designs and implements on the same medium, a computer, providing an opportunity to at least *partially* translate design information directly into implementation. Mechnical translation is less error prone than humans and far less labor intensive. The complete implementation cannot be synthesized mechanically, but such translation should be maximized. If the developers *depend* on design information, they will keep it up to date (they really have no choice). IME, flow control seems to be the correct level for partitioning. The concept you refer to is termed `round trip engineering' (RTE). Although trying to synthesize up-to-date design from the end product (i.e. reverse engineering) is the wrong way to achieve RTE. RTE works best when changing a design product is the only and *best* method for effecting change in the implementation. (This reverses the path of generation you propose.) Manual update and synchronization of design products with implementation never gets done. Never, IME. Reverse engineering only provides an up-to-date design product at the end of the implementation phase (IMO, synchronization should be continuous) -- although RE helps immensely when the developers are dealing with legacy or third party products. Some RTE schemes also suffer because the reverse engineering relies too heavily on the code generator. Even minor changes to the generated code can defeat reverse engineering. -- D. Brad Shapcott [C] Contractor, Motorola Cellular Infrastructure Group "Theory changes the reality it describes." ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-04 0:00 ` Robert C. Martin 1996-12-04 0:00 ` Dr. Richard Botting 1996-12-05 0:00 ` Tom Bushell @ 1996-12-05 0:00 ` Piercarlo Grandi 2 siblings, 0 replies; 209+ messages in thread From: Piercarlo Grandi @ 1996-12-05 0:00 UTC (permalink / raw) >>> "rmartin" == Robert C Martin <rmartin@oma.com> writes: [ ... ] harry> In fact IMHO an OO team has no place for anyone who cannot do all harry> three tasks. [Analysis, Design, and Implementation] rmartin> Agreed, emphatically. As much as I agree ith these wise words, that clearly arise out of a solid amount of experience with the ``alternative'', I have to sadly add here that sociological reasons make the ``alternative'' rather common; career stratification, harry> Jim Coplien wrote an excellent pattern called 'Architect also harry> Implements' which covers very nicely the reasoning behind not harry> allowing non-implementors to design systems. rmartin> Software architects who do not implement will be ignored by the rmartin> people who actually *do* implement. An architect cannot be rmartin> effective unless he/she really understands the problems that rmartin> the implementors are facing today, now, this minute. I know both you and Harry already know this, but let me add for the sake of completeness and of the record (and Ell :->): and viceversa! Architecture, as you have so many times argued, is extremely important, and the implementor that is not guided by sound architectural principles, by close interaction with analisys and design, is not going to do a nice implementation. Which of course brings us back to the observation above: that programming, and in particular OO with its great emphasis on structured, modular, abstraction, requires the ability to understand and perform at all three levels of discourse. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-04 0:00 ` Harry Protoolis 1996-12-04 0:00 ` Joe Winchester 1996-12-04 0:00 ` Robert C. Martin @ 1996-12-04 0:00 ` Ahmed 1996-12-06 0:00 ` Harry Protoolis 1996-12-22 0:00 ` Chip Richards 1996-12-04 0:00 ` What is wrong with OO ? Roger T. 3 siblings, 2 replies; 209+ messages in thread From: Ahmed @ 1996-12-04 0:00 UTC (permalink / raw) Cc: a.alkooheji Harry Protoolis wrote: > > On Tue, 03 Dec 1996 17:38:37 +0000, Ahmed <ACQ95AA@shef.ac.uk> wrote: > >Hello Every Body > >Object Oriented Technology came with quite promising claims that if achieved can > > benefit the software > >development companies and organisations millions of pounds. > > > >Some of these claims for instance > >1 - high reusability of objects and frameworks > >2 - Resilience to change, i.e. low software maintenance and evolution cost > >3 - Easier understanding by the user and Natural transition between the analysis > > , design, > >implementation because they all use tangible perceived objects. > > > >However the reality is not so bright as claimed..if so, then nobody today though > > t to develop a > >software on the traditional structural methods... > > > >My question is what is wrong with OO ? why it did not achieved its targets yet.? > >What are the main obstacles? > > I think this is overly negative, OO has not been and never will be a > 'silver bullet' to solve all software development problems, but no-one > but a few spin doctors ever claimed it would be. > > However, the real question should be 'has OO made a significant positive > difference', and in my experience the answer is a resounding 'yes!'. > Dear Harry, I agree with you that OO has many advantages, but I can not feel that significant improvement as you said, The important question is how measure the success of OO, Can you please tell me on what crieteria you mesured this significant difference is it ( code reusibility / software development time / software performace / software reliablity/ software cost / software portablity / ...etc .. ) these issues that count for any organization actually I am looking for any references that compares " with figures and statistics" between different applications developped using OO and the traditional methods. All what I have found are examples that show OO is workable, for me this is not an evidence to the significant difference" Another thing, Since you are familiar with OO, Could you please tell me what is the best environment to develop an OO application, ( in my case most of our applications are database systems ) Thank you very much Regards, Ahmed > Cheers, > Harry > - > alt.computer pty ltd software development consultants ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-04 0:00 ` Ahmed @ 1996-12-06 0:00 ` Harry Protoolis 1996-12-06 0:00 ` Ralph Cook 1996-12-22 0:00 ` Chip Richards 1 sibling, 1 reply; 209+ messages in thread From: Harry Protoolis @ 1996-12-06 0:00 UTC (permalink / raw) On Wed, 04 Dec 1996 16:35:54 +0000, Ahmed <ACQ95AA@shef.ac.uk> wrote: >Harry Protoolis wrote: >> >> On Tue, 03 Dec 1996 17:38:37 +0000, Ahmed <ACQ95AA@shef.ac.uk> wrote: >> However, the real question should be 'has OO made a significant positive >> difference', and in my experience the answer is a resounding 'yes!'. >> > > >Dear Harry, >I agree with you that OO has many advantages, but I can not feel that significant improvement >as you said, > >The important question is how measure the success of OO, >Can you please tell me on what crieteria you mesured this significant difference >is it >( code reusibility / software development time / software performace / software reliablity/ >software cost / software portablity / ...etc .. ) these issues that count for any organization > >actually I am looking for any references that compares " with figures and statistics" >between different applications developped using OO and the traditional methods. This, I think is the nub and crux of your problem. The gathering of real empirical data on software development is difficult or impossible. Real software developent companies do not have time to prepare these results for publication, and usually consider them too commercially sensitive. >All what I have found are examples that show OO is workable, for me this >is not an evidence to the significant difference" Sorry, if it's hard evidence you want you probably need to wait another ten years or so at least. However, the anecdotal evidence is that OO is at least as good at getting the job done as conventional techniques, and (very) occasionally spectactularly better. >Another thing, Since you are familiar with OO, >Could you please tell me what is the best environment to develop an OO application, :-), g++, vim, make, purify and ddd on a Sun Ultra Creator 3D with two heads. (sorry guys, sparcworks CC is nice, but debugger *still* bites) I find that Tools.h++ helps a lot, and when I can get it the STL. >( in my case most of our applications are database systems ) Oh, and SYBASE with DbTools.h++ from Roguewave. Seriously that is a very broad question, and depends a great deal on your application domain. This sort of advice is worth what you pay for it. Cheers, H p.s. your lines are too long ... _ Harry Protoolis alt.computer pty ltd harry@alt.net.au software development consultants ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-06 0:00 ` Harry Protoolis @ 1996-12-06 0:00 ` Ralph Cook 1996-12-07 0:00 ` Harry Protoolis [not found] ` <1996Dec7.151850.877@prim.demon.co.uk> 0 siblings, 2 replies; 209+ messages in thread From: Ralph Cook @ 1996-12-06 0:00 UTC (permalink / raw) Harry Protoolis wrote: > > On Wed, 04 Dec 1996 16:35:54 +0000, Ahmed <ACQ95AA@shef.ac.uk> wrote: > >Harry Protoolis wrote: > >All what I have found are examples that show OO is workable, for me this > >is not an evidence to the significant difference" > > Sorry, if it's hard evidence you want you probably need to wait another > ten years or so at least. However, the anecdotal evidence is that OO is > at least as good at getting the job done as conventional techniques, and > (very) occasionally spectactularly better. And occasionally spectacularly worse. And to say that individual projects like this have succeeded or failed does NOT "prove", or even "show", that the language environment used is "good" or "bad". rc -- When I DO speak for a company, I list my title and use "We". ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-06 0:00 ` Ralph Cook @ 1996-12-07 0:00 ` Harry Protoolis 1996-12-09 0:00 ` Nigel Tzeng [not found] ` <1996Dec7.151850.877@prim.demon.co.uk> 1 sibling, 1 reply; 209+ messages in thread From: Harry Protoolis @ 1996-12-07 0:00 UTC (permalink / raw) On Fri, 06 Dec 1996 09:09:54 -0500, Ralph Cook <ralph.cook@mci.com> wrote: >Harry Protoolis wrote: >> >> On Wed, 04 Dec 1996 16:35:54 +0000, Ahmed <ACQ95AA@shef.ac.uk> wrote: >> >Harry Protoolis wrote: >> >All what I have found are examples that show OO is workable, for me this >> >is not an evidence to the significant difference" >> >> Sorry, if it's hard evidence you want you probably need to wait another >> ten years or so at least. However, the anecdotal evidence is that OO is >> at least as good at getting the job done as conventional techniques, and >> (very) occasionally spectactularly better. > >And occasionally spectacularly worse. And to say that >individual projects like this have succeeded or failed does NOT >"prove", or even "show", that the language environment used is >"good" or "bad". Point taken, I guess what I am saying is that the hard statistical evidence needed doesn't exist yet. It is too early to call OO a failure, and given all we have is anecdotal evidence, IME the balance is on the positive side H - Harry Protoolis alt.computer pty ltd harry@alt.net.au software development consultants ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-07 0:00 ` Harry Protoolis @ 1996-12-09 0:00 ` Nigel Tzeng 1996-12-12 0:00 ` David Bradley 0 siblings, 1 reply; 209+ messages in thread From: Nigel Tzeng @ 1996-12-09 0:00 UTC (permalink / raw) In article <slrn5ai5m2.9ce.harry@matilda.alt.net.au>, Harry Protoolis <harry@alt.net.au> wrote: >On Fri, 06 Dec 1996 09:09:54 -0500, Ralph Cook <ralph.cook@mci.com> wrote: >>Harry Protoolis wrote: [snip] >Point taken, I guess what I am saying is that the hard statistical >evidence needed doesn't exist yet. It is too early to call OO a failure, >and given all we have is anecdotal evidence, IME the balance is on the >positive side FWIW In Rise and Resurrection Ed Yourdon has an excerpt from "Survey of Advanced Technology" by Chris Pickering for the years 1991 and 1993. The top performer in 1991 was OO/OOPS with percentage used 3.8, percentage succeeded 91.7 and effective penetration 3.5. In 1993 the worst performer was OO/OOPS with percentage used 11.9, percentage succeeded 66.3 and effective penetration of 7.9%. As a reference Structured Methods had a 84.2 success rate in 1993. RDBMS were the top performer of that year at 96.0 (Gee...I guess we finally know how to write and use RDBMS eh?). I never did bother to find the original study so I don't know the sample size, how he gathered data and so forth. As with all statistics YMMV. >Harry Protoolis alt.computer pty ltd ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-09 0:00 ` Nigel Tzeng @ 1996-12-12 0:00 ` David Bradley 1996-12-20 0:00 ` Nigel Tzeng 0 siblings, 1 reply; 209+ messages in thread From: David Bradley @ 1996-12-12 0:00 UTC (permalink / raw) nigel@access5.digex.net (Nigel Tzeng) wrote: >FWIW In Rise and Resurrection Ed Yourdon has an excerpt from "Survey >of Advanced Technology" by Chris Pickering for the years 1991 and >1993. > >The top performer in 1991 was OO/OOPS with percentage used 3.8, >percentage succeeded 91.7 and effective penetration 3.5. > >In 1993 the worst performer was OO/OOPS with percentage used 11.9, >percentage succeeded 66.3 and effective penetration of 7.9%. My guess is that a greater percentage of people using OOP in 1991 had a better understanding of it than those 1993. It doesn't mean OOP is a failure, just that you have more people in 1993 entering OOP and you have the training curve to deal with. Unfortunately they jumped into the OOP pool without first learning how to swim. They may have taken a lesson or two and could hold their own in calm waters, but when things get rough they drown. In stead of realizing they lack knowledge and accepting the responsibility for their failure they point the finger at OOP. -------------------------------------------- David Bradley davidb@datalytics.com Software Engineer Datalytics, Inc. http://www.datalytics.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-12 0:00 ` David Bradley @ 1996-12-20 0:00 ` Nigel Tzeng 0 siblings, 0 replies; 209+ messages in thread From: Nigel Tzeng @ 1996-12-20 0:00 UTC (permalink / raw) In article <32b00803.2304210038@news>, David Bradley <davidb@datalytics.com> wrote: [snip] >Unfortunately they jumped into the OOP pool without first learning how >to swim. They may have taken a lesson or two and could hold their own >in calm waters, but when things get rough they drown. In stead of >realizing they lack knowledge and accepting the responsibility for >their failure they point the finger at OOP. Well...never ever try to run a project with a new technique, process or metholodgy unless you have a few folks who have "mastery" over it and the majority of the staff at the "journeyman" level unless you don't particularly care about if it delivers on time or not. I don't believe that statistics of this sort either "prove" or "disprove" that OO is a success or failure. On the other hand it does show that once again silver bullets don't exist and if you have a shop of SASD folks you need invest quite a bit of money and time before expecting to EQUAL current levels of productivity and quality. After all there are a lot of shops finally getting SASD more or less correct that blowing away a mature process for eventual improvement two or three projects down the line may not be the worlds brightest move a company banking on the success of the current project. I wonder how many SEI level 4+ orgs are OO vs SASD. >David Bradley davidb@datalytics.com Nigel Tzeng ^ permalink raw reply [flat|nested] 209+ messages in thread
[parent not found: <1996Dec7.151850.877@prim.demon.co.uk>]
* Re: What is wrong with OO ? [not found] ` <1996Dec7.151850.877@prim.demon.co.uk> @ 1996-12-08 0:00 ` Tansel Ersavas 1996-12-14 0:00 ` Kazimir Majorinc 0 siblings, 1 reply; 209+ messages in thread From: Tansel Ersavas @ 1996-12-08 0:00 UTC (permalink / raw) Dave Griffiths wrote: > The last OO project I worked on was a spectacular disaster. A "generic" > reservations system for one of the biggest entertainment companies in the > world. It was cancelled a couple of months ago after millions down the > drain. You won't read about it anywhere because these things aren't discussed > publically. That in itself is part of the OO "problem" - you only hear about > the successes. This particular project failed through lack of a coherent > technical vision. There was nobody "in charge", just a bunch of developers > making it up as they went along. They were pretty talented, but that RAD > approach simply doesn't scale up for large projects. I think that there are a few points here that should be discussed. 1. "The cancelled projects with money down the drain" is not a part of the OO problem, but a general IS one. I know two 100 million projects cancelled after 5 years of great hopes, money and sweat, and they weren't OO projects. Every year, hundreds of BILLIONS of dollars are down the drain because of blown IS budgets and cancelled projects. In fact I would doubt very much that cancelled OO projects to successful OO projects ratio to be anything near cancelled traditional style projects vs overall traditional projects. The only reason we hear about failed traditional systems is that there are so many of them and they are much more spectacular than the one you are mentioning. Still only a very few of them get a mention. 2. You were very right to observe the reasons as to why the project failed. However, this is a more general syndrom of industrial era mentality applied to complex systems. As we move in the post industrial era, most of our problems come from our inability to create new types of organizations that can deal with such situations. 3. I am not a particular fan of the RAD approach. It doesn't imply OO, in fact, OO is only later tucked on to it. RAD is Today's techniques applied to Yesterday's organization structure. OO is not essential to the RAD, and If RAD fails, the failure can not be attributed to its tucked on OO component. 4. You were right to point out scaling as the biggest problem. However, OO, though as practiced Today it has its scaling problems, properly done has a much bigger chance of scaling than the traditional approach. > OO is pretty easy to sell though. You get the salesman to fly in from > California, take the managers out to lunch, talk loudly, smoke big cigars > and so on, then it's back to the conference room for a demo "blah blah, > ten times faster than existing development environments, blah blah", they > show how you can build a GUI interface to the database with just a few > drag'n'drops. Managers are bewitched, they agree to a pilot project to > build a prototype, in come the consultants to head up the project, they > knock up a few bubble diagrams, the prototype gets built and looks better > than anything the managers have ever seen and that's it, they're hooked. I'm glad to hear that. In my time it was much harder. > By the time it all goes horribly wrong, the fast talking consultants who > did the original "design" are long gone (natch) and are now trying to sell > someone their Web based solution... Hey, they have to live, life goes on. What's wrong if they costed a few millions to be wasted on one client's expense? Frankly, I couldn't have kept a straight face if I were responsible of such a failure. Anyway, I think that for OO to succeed, there are certain prerequisites. 1. People and the organization that they are in 2. Proper techniques (such as OO) 3. Tools People and organizations issue is the most important issue. If you get the best people and put them into an average organization, they will be wasted. Why: Current organizations are based on Smith, Fayol and Taylor's industrial era principles. These principles are based not on trust and liberty, but suspect and control. It is a restrictive rather than nourishing environment. In this environment, people are restricted by the system they are in, and act accordingly. I personally witnessed a case where in a big organization three of my friends were working on a project they knew it wouldn't be succesful, because by the time they had finished it, the system that they were developing the software for would be outdated, and being a legacy propriotory system, they wouldn't be able to replace hardware, and there would be no cheap way to port the software. They tried to explain it to the management, but not wholeheartedly. Nobody listened. As nobody owned the system, software was finished, and shelved. In this type of organization the process is divided into little steps of each would be performed by a non-overlapping team. Only the managers high up should have the overall vision and knowledge of which most of it already filtered going up and down; therefore collective vision and knowledge is nowhere to be found. Alternative structures are networking organizations. Indeed, there are a few companies enjoying benefits of human networking, and ours strives to be one of them. As for OO, even if it doesn't work, it should work. I saw it working, and I know it is repeatable. Tools are another chapter, indeed another book, that can help us out of our current misery. However, I don't have time to elaborate on that. Overall, it is a jigsaw, if parts are missing it doesn't look good. Remember, reading the same Bible, some go to crusade and kill thousands, some become loving caring people. Using the same knife, a chef creates masterpieces that are delicious, yet some others use it to threaten others. Techniques are just like that. Not magic wands. People can use OO to drown themselves and others in a spectacular mess, or glorify themselves and their organization. Lets create an unified vision for the people first, and than expect good results. Finally, if OO won't work, what are the alternatives, certainly not the old ways. Kind Regards Tansel Ersavas RASE Inc. mailto:tansel@deep.net http://www.rase.com/ ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-08 0:00 ` Tansel Ersavas @ 1996-12-14 0:00 ` Kazimir Majorinc 1996-12-14 0:00 ` Jeff Miller ` (3 more replies) 0 siblings, 4 replies; 209+ messages in thread From: Kazimir Majorinc @ 1996-12-14 0:00 UTC (permalink / raw) \x1eTansel Ersavas (tansel@deep.net) wrote: : 1. "The cancelled projects with money down the drain" is not a part of : the OO problem, but a general IS one. I know two 100 million projects : cancelled after 5 years of great hopes, money and sweat, and they : weren't OO projects. Every year, hundreds of BILLIONS of dollars are Ubelievable. For that money I could do anything they want. Simulation of whole world economy? No problem! Programming language more complicated than C++? No problem! I do not understand? I can not imagine problem which can not be solved with that money, except if it comes from mathematical world. : 3. I am not a particular fan of the RAD approach. It doesn't imply OO, : in fact, OO is only later tucked on to it. RAD is Today's techniques : applied to Yesterday's organization structure. OO is not essential to : the RAD, and If RAD fails, the failure can not be attributed to its : tucked on OO component. Yeah, neither I. : Anyway, I think that for OO to succeed, there are certain prerequisites. : 1. People and the organization that they are in : 2. Proper techniques (such as OO) : 3. Tools .......... Unfortunately, OO is based on completely wrong principle. If it succeed, it would be on costs which are several times bigger than on procedural paradigm. Which does not mean that it will not succeed commercialy. There are several wrong, although attractive possibilities of OO. Example: If type B is succesor of type A, in that case neither overriding nor polymorphism have no sense. If B requires different procedure than A, which should be more general it means that B is not specialisation of A. I say, complet chaos, which could look nice, like it looked to me before 3 years. _______________________________________________ Author: Kazimir Majorinc, Zagreb, Croatia E-mail: Kazimir.Majorinc@public.srce.hr kmajor@public.srce.hr (slightly better) http: //public.srce.hr/~kmajor (~7min to USA) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ One who knows the secret of the 7th stair ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-14 0:00 ` Kazimir Majorinc @ 1996-12-14 0:00 ` Jeff Miller 1996-12-16 0:00 ` David Bradley 1996-12-14 0:00 ` Tansel Ersavas ` (2 subsequent siblings) 3 siblings, 1 reply; 209+ messages in thread From: Jeff Miller @ 1996-12-14 0:00 UTC (permalink / raw) Kazimir Majorinc wrote: > > \x1eTansel Ersavas (tansel@deep.net) wrote: > > : 1. "The cancelled projects with money down the drain" is not a part > : of the OO problem, but a general IS one. I know two 100 million > : projects : cancelled after 5 years of great hopes, money and sweat, > : and they weren't OO projects. Every year, hundreds of BILLIONS of > : dollars are > > Ubelievable. For that money I could do anything they want. Simulation > of whole world economy? No problem! Programming language more > complicated than C++? No problem! I do not understand? I can not > imagine problem which can not be solved with that money, except if it > comes from mathematical world. Near the beginning of "The Mythical Man Month" an interesting observation is made: Since we so often hear about the stunning success of one or two programmers working at the kitchen table, why is it that all software is not written that way? Why is it that corporations continue to build these crazy, wasteful, failure-prone development departments when all they really needed to do was stuff a couple of talented programmers in a garage for a few months? There are lots of reasons, and I would refer the interested reader to the book (something *anyone* in software development should read!), I won't go into it here, but the details have to do with the geometric growth of communication paths while the staff count is increasing linearly. Anyway, you would be amazed at how easy it is to tear through $100 million. Most commercial software projects are not of the nature you implied. Problems like developing compilers and writing simulations are nicely contained. The big dollar projects you hear about tend to have enormous user interfaces, potentially hundreds of database tables, be distributed on a global basis, involve complex communication and coordination requirements, and require the sort of confirmed reliability associated with computer systems that are managing millions and sometimes of billions of dollars. Jeff Miller Senior Server Architect CSG Systems, Inc. jeff_miller@csgsys.com jmiller@probe.net ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-14 0:00 ` Jeff Miller @ 1996-12-16 0:00 ` David Bradley 0 siblings, 0 replies; 209+ messages in thread From: David Bradley @ 1996-12-16 0:00 UTC (permalink / raw) Jeff Miller <jmiller@probe.net> wrote: >why is it that all software is not written that way? Why is it that >corporations continue to build these crazy, wasteful, failure-prone >development departments when all they really needed to do was stuff >a couple of talented programmers in a garage for a few months? One, is that any such person would be caught dead in such a company. Second there aren't that many out there. -------------------------------------------- David Bradley davidb@datalytics.com Software Engineer Datalytics, Inc. http://www.datalytics.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-14 0:00 ` Kazimir Majorinc 1996-12-14 0:00 ` Jeff Miller @ 1996-12-14 0:00 ` Tansel Ersavas 1996-12-15 0:00 ` Todd Hoff 1996-12-20 0:00 ` The Impossible Project: not so funny... (Was: what's wrong) Tim Ottinger 3 siblings, 0 replies; 209+ messages in thread From: Tansel Ersavas @ 1996-12-14 0:00 UTC (permalink / raw) Kazimir Majorinc wrote: > > Unfortunately, OO is based on completely wrong principle. If it succeed, it > would be on costs which are several times bigger than on procedural paradigm. Compared to what? Procedure orientation? Can you tell me why we program in procedures, what is so absolute about it? In fact the biggest mistake is that we program in procedures. It is one of the biggest problems of this Century. Please read my prev. postings about what's wrong with procedure orientation. > Which does not mean that it will not succeed commercialy. I wouldn't bet on it. > One who knows the secret of the 7th stair But not OO Tansel ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-14 0:00 ` Kazimir Majorinc 1996-12-14 0:00 ` Jeff Miller 1996-12-14 0:00 ` Tansel Ersavas @ 1996-12-15 0:00 ` Todd Hoff 1996-12-15 0:00 ` Patrick Ma 1996-12-15 0:00 ` Tansel Ersavas 1996-12-20 0:00 ` The Impossible Project: not so funny... (Was: what's wrong) Tim Ottinger 3 siblings, 2 replies; 209+ messages in thread From: Todd Hoff @ 1996-12-15 0:00 UTC (permalink / raw) Kazimir Majorinc wrote: > \x1eTansel Ersavas (tansel@deep.net) wrote: > : 1. "The cancelled projects with money down the drain" is not a part of > : the OO problem, but a general IS one. I know two 100 million projects > : cancelled after 5 years of great hopes, money and sweat, and they > : weren't OO projects. Every year, hundreds of BILLIONS of dollars are > > Ubelievable. For that money I could do anything they want. Simulation of > whole world economy? No problem! Programming language more complicated than > C++? No problem! I do not understand? I can not imagine problem which can not > be solved with that money, except if it comes from mathematical world. More money makes the situation worse as it gives the illusion of commitment, of doing something. Building large software systems is fundamentally a social activity, technology isn't even a close second. With the right tribe of people i'd build a system using carrier pigeons. If it's not the right tribe all the money, tools, and consultants won't make a difference. ------------------------------------------------------------- tmh@possibility.com | The loyalty of small men can be http://www.possibility.com | bought cheaply, for greed has no | pride. - Michael Kube-McDowell ^ permalink raw reply [flat|nested] 209+ messages in thread
* RE: What is wrong with OO ? 1996-12-15 0:00 ` Todd Hoff @ 1996-12-15 0:00 ` Patrick Ma 1996-12-16 0:00 ` Robert C. Martin 1996-12-16 0:00 ` Bob Kettig 1996-12-15 0:00 ` Tansel Ersavas 1 sibling, 2 replies; 209+ messages in thread From: Patrick Ma @ 1996-12-15 0:00 UTC (permalink / raw) On 12/15/96 Todd Hoff <tmh@possibility.com> wrote: >Building large software systems >is fundamentally a social activity, technology isn't even >a close second. With the right tribe of people i'd build a system >using carrier pigeons. If it's not the right tribe all the >money, tools, and consultants won't make a difference. Todd, Exactly my thought that I have been trying to add to this thread. Thank you. A 'tribe of people' with OO discipline, willpower and determination is the key to a successful OO project. I wouldn't go as far as using carrier pigeons though. ;-) Of course, like I have mentioned earlier in this thread, knowledge and skill are essential but discipline, willpower and determination are critical factors, too. ------------------------------------------------------------------------ Patrick Ma < pma@partssolution.com > partsSolution, Inc. < http://www.partssolution.com > IBM Certified VisualAge for Smalltalk Developer < SmallNews - a Smalltalk UQWK editor for offline news editing > ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-15 0:00 ` Patrick Ma @ 1996-12-16 0:00 ` Robert C. Martin 1996-12-16 0:00 ` Bob Kettig 1 sibling, 0 replies; 209+ messages in thread From: Robert C. Martin @ 1996-12-16 0:00 UTC (permalink / raw) > On 12/15/96 Todd Hoff <tmh@possibility.com> wrote: > > >Building large software systems > >is fundamentally a social activity, technology isn't even > >a close second. With the right tribe of people i'd build a system > >using carrier pigeons. If it's not the right tribe all the > >money, tools, and consultants won't make a difference. I agree that you have to have the right people on the team. However, you must also have the right technology. If you don't have the technology, you can't build the project. Building large software systems is a technical activity that requires social interaction. Both aspects are critically important. -- Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (847) 918-1004 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-15 0:00 ` Patrick Ma 1996-12-16 0:00 ` Robert C. Martin @ 1996-12-16 0:00 ` Bob Kettig 1 sibling, 0 replies; 209+ messages in thread From: Bob Kettig @ 1996-12-16 0:00 UTC (permalink / raw) In article <32B3B440.46CF@possibility.com> Todd Hoff, tmh@possibility.com writes: > > More money makes the situation worse... > ... > With the right tribe of people I'd build a system using carrier pigeons. > ... > The loyalty of small men can be bought cheaply,... Hmmm... So it's a tribe of diminutive males that we seek? :-) - Bob ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-15 0:00 ` Todd Hoff 1996-12-15 0:00 ` Patrick Ma @ 1996-12-15 0:00 ` Tansel Ersavas 1 sibling, 0 replies; 209+ messages in thread From: Tansel Ersavas @ 1996-12-15 0:00 UTC (permalink / raw) Todd Hoff wrote: > > More money makes the situation worse as it gives the illusion > of commitment, of doing something. Building large software systems > is fundamentally a social activity, technology isn't even > a close second. With the right tribe of people i'd build a system > using carrier pigeons. If it's not the right tribe all the > money, tools, and consultants won't make a difference. > Right on the spot. Tansel ----------------------------------------------------------------------- RASE Inc. Clark NJ USA Voice: (908) 396 7145 mailto:tansel@rase.com Fax: (908) 382 1383 http://www.rase.com/ ----Sufficiently advanced technology is indistinguishable from magic--- A.C. Clarke ----------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: The Impossible Project: not so funny... (Was: what's wrong) 1996-12-14 0:00 ` Kazimir Majorinc ` (2 preceding siblings ...) 1996-12-15 0:00 ` Todd Hoff @ 1996-12-20 0:00 ` Tim Ottinger 1996-12-20 0:00 ` Robert Dewar ` (2 more replies) 3 siblings, 3 replies; 209+ messages in thread From: Tim Ottinger @ 1996-12-20 0:00 UTC (permalink / raw) Kazimir Majorinc wrote: > > \x1eTansel Ersavas (tansel@deep.net) wrote: > > : 1. "The cancelled projects with money down the drain" is not a part of > : the OO problem, but a general IS one. I know two 100 million projects > : cancelled after 5 years of great hopes, money and sweat, and they > : weren't OO projects. Every year, hundreds of BILLIONS of dollars are > > Ubelievable. For that money I could do anything they want. Simulation of > whole world economy? No problem! Programming language more complicated than > C++? No problem! I do not understand? I can not imagine problem which can not > be solved with that money, except if it comes from mathematical world. I added up all of the reasons I've seen things fall apart, and put them into a single nightmare scenario, to show how you can fail even with great, steaming wads of cash. After all, it's my assertion that very few projects fail for reasons of technology. There are so many more reasons. Even with OO, IE, or SA/SD, or any magic bullet methodology in the world, the only answer to this one is to walk away and save the $M. :-( :-( The customer has absolutely no idea how they want to use the system, or what it should do, or how they'll run their newly formed business. They're inventing business processes as they go. Every requirement may be changed or scrapped since they've never actually done the work they're gearing up for. But the software must automate all of their processes, and must be intuitive enough that it can be operated expertly by 10th grade students (not honor students) with less than one day of training. You'll be supporting three customers in three different markets, who will use the system different ways. These way's haven't been decided yet. It must be accurate to the 9th decimal place (right side). Your staff has never programmed in the language and environment that is mandated by the customer. They've also never worked in this domain before. You are similarly clueless. You are not allowed to buy tools or libraries. Only salaries are acceptable. The hardware acquisition cycle runs about 14 months. The software acquisition cycle runs 10. Acquisition cycle for hiring is 8 months. The company requires all applicants have a business degree. You will not be allowed to interview the client directly. Instead you will be expected to work through a mediator. The average turn-around for a question will be about three weeks. The database you'll be using is also mandated, and doesn't work yet. The system must control yet-unspecified equipment in realtime, but provide online reporting which is up-to-the-second in an RDBMS that is hosted on Windows NT box which is to be completed in two years, and the OS will be ready in three. Unless it doesn't work or the client changes their mind about the platform. :-) :-) :-) Okay, I'm being silly, but there is nothing a good or even an excellent developer can do with total uncertainty and ambiguity, especially when the customer is hostile or unapproachable. If requirements are not determined, and the users refuse to settle you are likewise in a position where you probably can't make much success. Now any small set of these problems are present in every single project. Hopefully, we can educate our users and customers so that we don't have too many at once. In this case, it isn't OO that fails, it's the decision to try an build a project that can't work. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: The Impossible Project: not so funny... (Was: what's wrong) 1996-12-20 0:00 ` The Impossible Project: not so funny... (Was: what's wrong) Tim Ottinger @ 1996-12-20 0:00 ` Robert Dewar 1996-12-21 0:00 ` John DiCamillo 1996-12-22 0:00 ` Guy Rixon 2 siblings, 0 replies; 209+ messages in thread From: Robert Dewar @ 1996-12-20 0:00 UTC (permalink / raw) Tim says "Okay, I'm being silly, but there is nothing a good or even an excellent developer can do with total uncertainty and ambiguity, especially when the customer is hostile or unapproachable. If requirements are not determined, and the users refuse to settle you are likewise in a position where you probably can't make much success." Not so silly! Probably the only silly thing was imagining ALL these things to happen on one project, but I would be willing to bet that every single one of your imagined horrors is real in some context. The funny thing is that when someone says "gosh, for a 100 million buckaroos I could build anything", they are falling into the trap which we are discussing, namely the assumption that you can buy your way out of disaster, when in practice money is quite often the means by which you end up spending yourself into disaster. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: The Impossible Project: not so funny... (Was: what's wrong) 1996-12-20 0:00 ` The Impossible Project: not so funny... (Was: what's wrong) Tim Ottinger 1996-12-20 0:00 ` Robert Dewar @ 1996-12-21 0:00 ` John DiCamillo 1996-12-22 0:00 ` Guy Rixon 2 siblings, 0 replies; 209+ messages in thread From: John DiCamillo @ 1996-12-21 0:00 UTC (permalink / raw) Tim Ottinger <tottinge@dave-world.net> writes: >I added up all of the reasons I've seen things fall apart, and put them >into a single nightmare scenario, to show how you can fail even with >great, steaming wads of cash. [loads of good funny stuff mercilessly snipped] >You are not allowed to buy tools or libraries... Or, my personal favorite: You can buy all the libraries and tools you want. However, they are all mutually incompatible and at different release numbers on different platforms. At least one of the tools or libraries will have a new release each month, rendering it incompatible with anything it may have been compatible with in the past, and introducing exciting new bugs to replace the old bugs that you had already found work-arounds for. The bugs you couldn't find work-arounds for will be fixed in a future release, but only on the platform you are not using. (Hey, this is fun! Let's do some more! :-) You buy a source license to one of the tools so that you can fix the bugs you couldn't work around, but now you must dedicate a resource to keep re-fixing the bugs in each new release of the tool, on each platform you need to support. (Thanks for a pre-holiday chuckle, Tim!) -- ciao, milo ================================================================ John DiCamillo Fiery the Angels Fell milod@netcom.com Deep thunder rode around their shores ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: The Impossible Project: not so funny... (Was: what's wrong) 1996-12-20 0:00 ` The Impossible Project: not so funny... (Was: what's wrong) Tim Ottinger 1996-12-20 0:00 ` Robert Dewar 1996-12-21 0:00 ` John DiCamillo @ 1996-12-22 0:00 ` Guy Rixon 2 siblings, 0 replies; 209+ messages in thread From: Guy Rixon @ 1996-12-22 0:00 UTC (permalink / raw) Tim Ottinger wrote: > > Kazimir Majorinc wrote: > ...I added up all of the reasons I've seen things fall apart, and put them > into a single nightmare scenario, to show how you can fail even with > great, steaming wads of cash. [Details of nightmare deleted] Here's another one to worry about: There is no clear customer for your product. The nominal customer is a collaboration of independent organizations. After a little digging, you find that funding, functional requirements, technical contraints, and acceptence testing are being handled by different groups who make conflicting demands because they are unaware of each other. You introduce them and they declare inter-office war on each other: nothing is resolved. About the time that you have something to demonstrate, the war of words goes politically nuclear and one or more of the `customers' gets wiped out. You are left with no sponsors for the many dubious decisions you were forced to make to reconcile the conflicting requirements. -- Guy Rixon, gtr@ast.cam.ac.uk Software Engineering Group, Tel: +44-1223-374000 Royal Greenwich Observatory Fax: +44-1223-374700 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: The Impossible Project: not so funny... (Was: what's wrong) 1996-12-04 0:00 ` Ahmed 1996-12-06 0:00 ` Harry Protoolis @ 1996-12-22 0:00 ` Chip Richards 1 sibling, 0 replies; 209+ messages in thread From: Chip Richards @ 1996-12-22 0:00 UTC (permalink / raw) Tim Ottinger, Robert Dewar, John DiCamillo, and Guy Rixon wrote: > Kazimir Majorinc wrote: [Details of nightmare deleted] Here's another one to worry about: [etc., etc.] Would you guys stop it!? My boss thinks I'm posting our internal memoranda to the net! <grin> Seriously, I've never been on a project that has been afflicted by *all* these problems at once, but they are each terrifyingly familiar. And please, don't really stop writing about it--I'm loving this stuff. Of course, no amount of astute project management can help you if you build your project on a platform that's discontinued by its vendor two weeks after you release your product. Not that such a thing would *ever* happen, noooo. -- Chip ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-04 0:00 ` Harry Protoolis ` (2 preceding siblings ...) 1996-12-04 0:00 ` Ahmed @ 1996-12-04 0:00 ` Roger T. 3 siblings, 0 replies; 209+ messages in thread From: Roger T. @ 1996-12-04 0:00 UTC (permalink / raw) Harry Protoolis <harry@matilda.alt.net.au> wrote in article <slrn5a9o60.okl.harry@matilda.alt.net.au>... > >My question is what is wrong with OO ? why it did not achieved its targets yet.? > >What are the main obstacles? > > The traditional techniques all suffered from a number of significant > flaws. Perhaps the most damaging one was what I (rather unkindly) think > of as 'The glorification of idiots' phenomenon. What I mean by this is > that projects were typically infested by a group of people who never > wrote any software, but spent most of the budget drawing diagrams that > the implementors never used. I agree with your thesis in general but I would like to point out that the the glorification of idiots also included the glorification of those implementors that had no use at all for any high level analysis and design efforts. There are plenty of implementors who could be called idiots for engaging in what I call "stream of consciousness" coding. > The main contribution of OO has been was could be termed 'The > glorification on the implementor'. This has been achieved by the > effective marriage of Analysis, Design and Implementation. The result > is that every member of the team does all three of the key tasks. This is true but the question I wonder about is how much importance and therefore time does the implementor invest in the Analysis and Design parts. The most important result of OO is that it encourages the implementor to value these development stages more highly than he might otherwise. Implementation is the ultimate goal and OO is a means to reach that goal and also provide a quality product. > In fact IMHO an OO team has no place for anyone who cannot do all > three tasks. Jim Coplein wrote an excellent pattern called > 'Architect also Implements' which covers very nicely the reasoning > behind not allowing non-implementors to design systems. Agree. > Certainly the mecca of automatic reuse has not been achieved, but the > quantity and quality of 3rd party components available for most OO > languages already exceeds that available for their non-OO counterparts, > and IHMO this suggests a bright future. Agree. > Certainly OO has not made writing software trivial or automatic, but > then, *nothing ever will*. It will make writing some ever-growing subset of software trivial or automatic and free us to attack more difficult coding problems. Roger T. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-03 0:00 What is wrong with OO ? Ahmed ` (4 preceding siblings ...) 1996-12-04 0:00 ` Harry Protoolis @ 1996-12-04 0:00 ` Piercarlo Grandi 1996-12-05 0:00 ` Daniel Drasin ` (4 subsequent siblings) 10 siblings, 0 replies; 209+ messages in thread From: Piercarlo Grandi @ 1996-12-04 0:00 UTC (permalink / raw) >>> "ACQ95AA" == Ahmed <ACQ95AA@shef.ac.uk> writes: ACQ95AA> Hello Every Body I am a new research student working at the ACQ95AA> field of Object Oriented Technology...I have several critical ACQ95AA> opinions about Object Oriented in general, and I like to ACQ95AA> participate it with you and hear you expert comments and ACQ95AA> opinions ACQ95AA> Object Oriented Technology came with quite promising claims ACQ95AA> that if achieved can benefit the software development companies ACQ95AA> and organisations millions of pounds. ACQ95AA> Some of these claims for instance ACQ95AA> 1 - high reusability of objects and frameworks Of objects? What do you mean? As to ``frameworks'', which I choose to interpret here as ``libraries of software modules'', there is no guarantee that by using OO one _does_ achieve _high_ reusability; one _can_ achieve _higher_ reusability. Whether higher reusability _is_ achieved depends on many factors other than the adoption of OO technology, and whether the reusability achieved is _high_ depends among other things on the problem domain. That it is _possible_ to achieve _higher_ reusability with OO than other approaches is substantiated by some sparse but compelling evidence. ACQ95AA> 2 - Resilience to change, i.e. low software maintenance and ACQ95AA> evolution cost As a _possible_ consequence of _possibly_ _higher_ reuse. Again, there is some sparse but compelling evidence that this actually happens. ACQ95AA> 3 - Easier understanding by the user and Natural transition ACQ95AA> between the analysis, design, implementation because they all ACQ95AA> use tangible perceived objects. This is not a claim in OO technology, but in OO speak, in other words it is purely marketing hype unsubstantiated by any evidence whatsoever. You won't find any such claim in anything but marketing drivel. Any such claim, as you write it, is also manifestly absurd: the very notion of something that is both "tangible perceived" is amusing to say the least. ACQ95AA> However the reality is not so bright as claimed.. Indeed, because most all OO-speak salesmen paint a rosy picture as you describe it above. OO in and by itself does not magically and necessarily "achieve" the magic of "high reusability", and in particular because there is no reason why the use of "tangible perceived objects" should give any benefit like "Easier understanding by the user". ACQ95AA> if so, then nobody today thought to develop a software on the ACQ95AA> traditional structural methods... Software technologies depend more on sociological than technological factors. In particular on the twenty-year cycle of induction of new generations of computer scientists in industry, and their reaching ``manager'' status. ACQ95AA> My question is what is wrong with OO ? why it did not achieved ACQ95AA> its targets yet.? What are the main obstacles? Inflated expectations? Marketing drivel? Facile abuse of OO-speak? Thsoe that do practice OO as a technology and not as the promise of the age of Acquarium in CS find it a very useful concept that does deliver some measurable benefits. I find the discussion of OO and other issues in the second edition of "The Mythical Man Month" a rather good argumentation of some of the issues involved. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-03 0:00 What is wrong with OO ? Ahmed ` (5 preceding siblings ...) 1996-12-04 0:00 ` Piercarlo Grandi @ 1996-12-05 0:00 ` Daniel Drasin 1996-12-06 0:00 ` Steve Heller ` (13 more replies) 1996-12-05 0:00 ` Nick Thurn ` (3 subsequent siblings) 10 siblings, 14 replies; 209+ messages in thread From: Daniel Drasin @ 1996-12-05 0:00 UTC (permalink / raw) Ahmed wrote: > > Hello Every Body > > I am a new research student working at the field of Object Oriented Technology...I have several > critical opinions about Object Oriented in general, and I like to participate it with you and hear > you expert comments and opinions > > Object Oriented Technology came with quite promising claims that if achieved can benefit the software > development companies and organisations millions of pounds. > > Some of these claims for instance > 1 - high reusability of objects and frameworks > 2 - Resilience to change, i.e. low software maintenance and evolution cost > 3 - Easier understanding by the user and Natural transition between the analysis, design, > implementation because they all use tangible perceived objects. > > However the reality is not so bright as claimed..if so, then nobody today thought to develop a > software on the traditional structural methods... > > My question is what is wrong with OO ? why it did not achieved its targets yet.? > What are the main obstacles? > My $0.02. The problems I've seen with OO projects arise not from the use of OO, but from the misuse of OO. Programmers trying to use non-OO methods, incorrectly applying OO concepts, etc. This is a result of a lack of OO teaching at eductational institutions. Even schools that offer 1 or 2 OO language courses usually fail to educate; they use C++ and only really teach the "C" part. There are very few universities that make an effort to inculcate students with an understanding of OO techiniques and methods. So it's no wonder when these graduates try to apply them in the "real world," they get all fouled up. Dan -- Daniel Drasin Applied Reasoning drasin@arscorp.com 2840 Plaza Place, Suite 325 (919)-781-7997 Raleigh, NC 27612 http://www.arscorp.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Daniel Drasin @ 1996-12-06 0:00 ` Steve Heller 1996-12-06 0:00 ` David Bradley ` (12 subsequent siblings) 13 siblings, 0 replies; 209+ messages in thread From: Steve Heller @ 1996-12-06 0:00 UTC (permalink / raw) Daniel Drasin <drasin@arscorp.com> wrote: >The problems I've seen with OO projects arise not from the use of OO, >but from the misuse of OO. Programmers trying to use non-OO methods, >incorrectly applying OO concepts, etc. This is a result of a lack of >OO teaching at eductational institutions. Even schools that offer >1 or 2 OO language courses usually fail to educate; they use C++ >and only really teach the "C" part. There are very few >universities that make an effort to inculcate students with an >understanding of OO techiniques and methods. So it's no wonder >when these graduates try to apply them in the "real world," they >get all fouled up. I agree. Moreover, instructors who DO attempt to teach "real" C++ (i.e., OO) programming run the risk of upsetting students who think they already know how to program and other instructors who are still not completely conversant with OO notions. Steve Heller, author and software engineer http://ourworld.compuserve.com/homepages/steve_heller ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Daniel Drasin 1996-12-06 0:00 ` Steve Heller @ 1996-12-06 0:00 ` David Bradley 1996-12-06 0:00 ` Todd Hoff ` (11 subsequent siblings) 13 siblings, 0 replies; 209+ messages in thread From: David Bradley @ 1996-12-06 0:00 UTC (permalink / raw) The problem is that reuse through OOP takes effort. People seem not willing to expend the effort to get the benefit of OOP. They put an OOP in place and don't change their methods and then wonder why they aren't able to reuse code. You never get something for nothing. If you're not willing or unable to put forth the effort you'll never see the benefit. In order for something to be reused it has to be designed properly. OOD is where most people fail. This takes effort. If you don't expend this effort upfront you'll not get anything out. Look at OOP as a lever. The work you put in will be multiplied out the other end. If you don't put in the initial work on the front end then you'll never get the benefit on the back end. -------------------------------------------- David Bradley davidb@datalytics.com Software Engineer Datalytics, Inc. http://www.datalytics.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Daniel Drasin 1996-12-06 0:00 ` Steve Heller 1996-12-06 0:00 ` David Bradley @ 1996-12-06 0:00 ` Todd Hoff 1996-12-07 0:00 ` Steve Heller ` (2 more replies) 1996-12-13 0:00 ` drush ` (10 subsequent siblings) 13 siblings, 3 replies; 209+ messages in thread From: Todd Hoff @ 1996-12-06 0:00 UTC (permalink / raw) Daniel Drasin wrote: > > The problems I've seen with OO projects arise not from the use of OO, > but from the misuse of OO. Programmers trying to use non-OO methods, > incorrectly applying OO concepts, etc. This is a result of a lack of > OO teaching at eductational institutions. Even schools that offer > 1 or 2 OO language courses usually fail to educate; they use C++ > and only really teach the "C" part. There are very few > universities that make an effort to inculcate students with an > understanding of OO techiniques and methods. So it's no wonder > when these graduates try to apply them in the "real world," they > get all fouled up. If i invented a hammer and 90% of people couldn't use it correctly would we blame the hammer or the people? It seems those who've "got" OO blame the people. Maybe we should blame the hammer. Maybe OO just won't work in the mass market of building applications. Not that it can't, but that it doesn't work often enough to make it universally appropriate. ------------------------------------------------------------- tmh@possibility.com | The loyalty of small men can be http://www.possibility.com | bought cheaply, for greed has no | pride. - Michael Kube-McDowell ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-06 0:00 ` Todd Hoff @ 1996-12-07 0:00 ` Steve Heller 1996-12-07 0:00 ` Tansel Ersavas 1996-12-09 0:00 ` Todd Hoff 1996-12-07 0:00 ` Nick Thurn 1996-12-15 0:00 ` Damon Feldman 2 siblings, 2 replies; 209+ messages in thread From: Steve Heller @ 1996-12-07 0:00 UTC (permalink / raw) Todd Hoff <tmh@possibility.com> wrote: >Daniel Drasin wrote: >> >If i invented a hammer and 90% of people couldn't use >it correctly would we blame the hammer or the people? If I invented an electron microscope and 90% of people couldn't use it, would we blame the electron microscope or the people? In other words, the complexity of the job that the tool needs to do matters as well. >It seems those who've "got" OO blame the people. Maybe we >should blame the hammer. Maybe OO just won't work in >the mass market of building applications. Not that it >can't, but that it doesn't work often enough to make it >universally appropriate. Or maybe it's just taught poorly. I've been pretty successful in teaching OOP to people who don't know it already. However, it takes an awful lot of work on both the instructor's and the student's part, as well as a proper approach. That is, rather than my trying to cram dozens of constructs down the student's throat, we take them slowly and in the proper sequence. The student won't know as many facts when we get done as if he'd read a "Learn C++ in Five Seconds" book, but he or she will KNOW and UNDERSTAND the material I've taught. Steve Heller, author and software engineer http://ourworld.compuserve.com/homepages/steve_heller ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-07 0:00 ` Steve Heller @ 1996-12-07 0:00 ` Tansel Ersavas 1996-12-09 0:00 ` Kenneth Mays 1996-12-14 0:00 ` Robert C. Martin 1996-12-09 0:00 ` Todd Hoff 1 sibling, 2 replies; 209+ messages in thread From: Tansel Ersavas @ 1996-12-07 0:00 UTC (permalink / raw) ... Disucssion deleted > >It seems those who've "got" OO blame the people. Maybe we > >should blame the hammer. Maybe OO just won't work in > >the mass market of building applications. Not that it > >can't, but that it doesn't work often enough to make it > >universally appropriate. > > Or maybe it's just taught poorly. I've been pretty successful in > teaching OOP to people who don't know it already. However, it takes an > awful lot of work on both the instructor's and the student's part, as > well as a proper approach. That is, rather than my trying to cram > dozens of constructs down the student's throat, we take them slowly > and in the proper sequence. The student won't know as many facts when > we get done as if he'd read a "Learn C++ in Five Seconds" book, but he > or she will KNOW and UNDERSTAND the material I've taught. > Ladies and Gentlemen, Before we discuss 'what is wrong with OO', shouldn't we discuss what is wrong with the current popular paradigm, procedure orientation. Most of us seem to have forgotten it is just a historical accident that we program the way we do in procedural approach, and if we are in a total mess as software developers, one of the biggest reasons is our insistence on procedure orientation. Most of the current OO implementations carry a legacy of people with procedure oriented background, and that reflects quite badly on the projects. Languages that easily allow such escapes also contribute to this phenomena. Once we accept the problems of the procedure orientation (see my previous posting to comp.object about the subject) then we can look at the alternatives. When we conquer new places, the first to go usually perish. It is tough to be a pioneer. However, with persistence and perseverence, we build necesary access and support systems, and that new place becomes very hospitable and finally, a source of great wealth. Luckily, time for being a pioneer in OO is just about to pass. Now comes better times and even prosperity. There are three major reasons why OO projects fail. All of them are stated by the great wisdom of Jedi in "Star Wars". These are: "Do or do not. There is no try" Using my tools and techniques, I can prove you that I can produce better and faster systems using OO (Please read my notes at the end of this message). If I can do it, so you can.If you just try to do it, you will fail. Be determined to do it. "You must unlearn what you have learned" People cling so heavily to the baggage they have been carrying, they can not have an open mind about OO. SO the first thing I do in my training sessions is to create doubts and questions about the problems of the procedural approach, and why procedure orientation is a very ineffective technique for most new problems. Of course, you should have a very good mentor that is capable of demonstrating these in practical terms. "You must believe in what you are doing" OO will help you. It will feel awkward at times, but you must persist with it. You will be eventually rewarded. Coming to the question of "What is wrong with OO" the question should read "What are the problems in the current state of OO that slows down it's progress". There three major problems that slows down OO. . Lack of expertise, personal and team skills (human issues) . Lack of fast, efficient and practical tools-environments that make programming one of the the most labor-oriented, miserable works available Today . Lack of practical OO application techniques and ways that will integrate OO with other succesful paradigms Current state of OO suffers from all of the above. Each and every one of these problems are soluble, Indeed as a company, we are working on and have at least intermediate solutions for all of them. BTW I get a much better response for OO from children. For that reason, I'll offer educational versions my tools and techniques to schools so that children can be exposed to these techniques before their minds are clutterd by the current dominant paradigms. Tansel Ersavas RASE Inc. mailto:tansel@deep.net http://www.rase.com/ ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-07 0:00 ` Tansel Ersavas @ 1996-12-09 0:00 ` Kenneth Mays 1996-12-14 0:00 ` Robert C. Martin 1 sibling, 0 replies; 209+ messages in thread From: Kenneth Mays @ 1996-12-09 0:00 UTC (permalink / raw) I agree with the thread on the problems we have in the field of software engineering in OOT/OOP. You don't send students off to a four-year college to learn Pascal programming and then expect them to go into the work force programming in Smalltalk (I can't wait to see "Learn Smalltalk in 21 days"). Even C++ takes a different frame of mind than if you just came from a COBOL or RPG background. But, a lot of this doesn't matter becasue the field is diverse. A person picks up a language or two under his/her belt and that becomes their marketable skill. Lockheed Martim still hires people based on AI knowledge and LISP programming background. Some companies still hire 8051 programmers while some hire FORTRAN programmers. Then, you'll get asked if you know FORTRAN-77, FORTRAN IV, or FORTRAN-90 (when is FORTRAN FORTRAN?). We have that problem with Ada95 and Ada83, many engineers don't have a clue on what Ada95 is beacsue they are stuck on just knowing Ada83 and don't want to learn new languages. I don't think there is anything wrong with OOD/OOT/OOP since it is nothing new and Apple used the concepts back in the late 1980s. Are we just spinning our wheels argueing about something that won't go away anytime soon? Ken ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-07 0:00 ` Tansel Ersavas 1996-12-09 0:00 ` Kenneth Mays @ 1996-12-14 0:00 ` Robert C. Martin 1996-12-14 0:00 ` Patrick Ma ` (2 more replies) 1 sibling, 3 replies; 209+ messages in thread From: Robert C. Martin @ 1996-12-14 0:00 UTC (permalink / raw) In article <32AA207E.3199@deep.net>, tansel@deep.net wrote: > There are three major reasons why OO projects fail. All of them are > stated by the great wisdom of Jedi in "Star Wars". > > These are: > "Do or do not. There is no try" > Using my tools and techniques, I can prove you that I can produce > better and faster systems using OO (Please read my notes at the end > of this message). If I can do it, so you can.If you just try to do > it, you will fail. Be determined to do it. There is something to this. However, OO will not work just because you are determined. You must understand the mechanisms that make it work, and you must know what those mechamisms can, and cannot do. In some sense OO has attracted programmers the way that new weight loss methods attract people who want to lose weight. They will grasp at anything new to solve their problems. OO is a great technique and it can help make software easier to reuse, modify and maintain. But it is not a cure-all; and it must be understood in detail and weilded with skill. > > "You must unlearn what you have learned" > People cling so heavily to the baggage they have been carrying, > they can not have an open mind about OO. SO the first thing I do > in my training sessions is to create doubts and questions about > the problems of the procedural approach, and why procedure > orientation is a very ineffective technique for most new problems. > Of course, you should have a very good mentor that is capable of > demonstrating these in practical terms. Although I agree with your sentiment, I disagree with your terminology. We don't really want to unlearn anything. We want to integrate the new tools and mechanisms of OO into our practices. > > "You must believe in what you are doing" > OO will help you. It will feel awkward at times, but you must > persist with it. You will be eventually rewarded. You can't just believe without evidence. That evidence can be empirical. But there are so few controlled experiments that reliable empirical evidence is hard to find. Or the evidence can be in the form of a believable rationale. One that can be tested with thought experiements. --------- OO is not a motivational discipline. It does not take willpower and determination to "do things right". Rather it takes knowledge and skill. > > Coming to the question of "What is wrong with OO" the question should > read "What are the problems in the current state of OO that slows down > it's progress". > > There three major problems that slows down OO. > . Lack of expertise, personal and team skills (human issues) > . Lack of fast, efficient and practical tools-environments that make > programming one of the the most labor-oriented, miserable works > available Today > . Lack of practical OO application techniques and ways that will > integrate OO with other succesful paradigms > > Current state of OO suffers from all of the above. Each and every one of > these problems are soluble, Indeed as a company, we are working on and > have at least intermediate solutions for all of them. > > BTW I get a much better response for OO from children. For that reason, > I'll offer educational versions my tools and techniques to schools so > that children can be exposed to these techniques before their minds are > clutterd by the current dominant paradigms. > > Tansel Ersavas > RASE Inc. > mailto:tansel@deep.net > http://www.rase.com/ -- Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (847) 918-1004 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan ^ permalink raw reply [flat|nested] 209+ messages in thread
* RE: What is wrong with OO ? 1996-12-14 0:00 ` Robert C. Martin @ 1996-12-14 0:00 ` Patrick Ma 1996-12-18 0:00 ` Harry Protoolis 1996-12-15 0:00 ` Tansel Ersavas 1996-12-16 0:00 ` Karen A. Morrissey 2 siblings, 1 reply; 209+ messages in thread From: Patrick Ma @ 1996-12-14 0:00 UTC (permalink / raw) On 12/14/96 Robert C. Martin <rmartin@oma.com> wrote: >OO is not a motivational discipline. It does not take willpower and >determination to "do things right". Rather it takes knowledge and skill. Robert, Without a doubt, it takes knowledge and skill to "do things right" in OO. However, I do think OO is a discipline and it does take willpower and determination together with knowledge and skill to "do things right." Often, things were done wrong but not corrected even when they are discovered because they were 1. done by higher ranked developers, 2. done for a while or in too many places, 3. insert your favorite scenarios. It is willpower and determination of OO discipline that is going to lead us to break through these hurdles created by our very own minds. ------------------------------------------------------------------------ Patrick Ma < pma@partssolution.com > partsSolution, Inc. < http://www.partssolution.com > IBM Certified VisualAge for Smalltalk Developer < SmallNews - a Smalltalk UQWK editor for offline news editing > ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-14 0:00 ` Patrick Ma @ 1996-12-18 0:00 ` Harry Protoolis 1996-12-18 0:00 ` Patrick Ma 0 siblings, 1 reply; 209+ messages in thread From: Harry Protoolis @ 1996-12-18 0:00 UTC (permalink / raw) On 14 Dec 1996 23:19:51 -0500, Patrick Ma <pma@panix.com> wrote: >On 12/14/96 Robert C. Martin <rmartin@oma.com> wrote: > >>OO is not a motivational discipline. It does not take willpower and >>determination to "do things right". Rather it takes knowledge and skill. > >Robert, > > Without a doubt, it takes knowledge and skill to "do things right" in OO. >However, I do think OO is a discipline and it does take willpower and >determination together with knowledge and skill to "do things right." > > Often, things were done wrong but not corrected even when they are >discovered because they were > 1. done by higher ranked developers, > 2. done for a while or in too many places, > 3. insert your favorite scenarios. > > It is willpower and determination of OO discipline that is going to lead us to >break through these hurdles created by our very own minds. What's OO got to do with it ? Idenitifying and changing errors and bad practices is a matter of *Professionalism*, there is nothing unique to OO that makes it more professional that any other technique. Of course, turning professional programmers into 'code monkeys' is just begging for this sort of problem ... H -- Harry Protoolis alt.computer pty ltd harry@alt.net.au software development consultants ^ permalink raw reply [flat|nested] 209+ messages in thread
* RE: What is wrong with OO ? 1996-12-18 0:00 ` Harry Protoolis @ 1996-12-18 0:00 ` Patrick Ma 1996-12-18 0:00 ` Caitlin 0 siblings, 1 reply; 209+ messages in thread From: Patrick Ma @ 1996-12-18 0:00 UTC (permalink / raw) On 12/18/96 Harry Protoolis <harry@matilda.alt.net.au> wrote: >On 14 Dec 1996 23:19:51 -0500, Patrick Ma <pma@panix.com> wrote: >>On 12/14/96 Robert C. Martin <rmartin@oma.com> wrote: >> >>>OO is not a motivational discipline. It does not take willpower and >>>determination to "do things right". Rather it takes knowledge and skill. >> >>Robert, >> >> Without a doubt, it takes knowledge and skill to "do things right" in OO. >>However, I do think OO is a discipline and it does take willpower and >>determination together with knowledge and skill to "do things right." >> >> Often, things were done wrong but not corrected even when they are >>discovered because they were >> 1. done by higher ranked developers, >> 2. done for a while or in too many places, >> 3. insert your favorite scenarios. >> >> It is willpower and determination of OO discipline that is going to lead us to >>break through these hurdles created by our very own minds. > >What's OO got to do with it ? > >Idenitifying and changing errors and bad practices is a matter of >*Professionalism*, there is nothing unique to OO that makes it more >professional that any other technique. I am not trying to make the point that OO is more professional than any other technique. IMO, OO has a rich set of principles that makes ME see it as a discipline besides being a technology. As a discipline that I practice, I find myself more determined to identify and correct OO errors and bad practices that others may let go for the reasons I mentioned above. I believe in OO and I want to promote it. I want others to see OO as a discipline in addition to being an excellent technology, IMO. ------------------------------------------------------------------------ Patrick Ma < pma@partssolution.com > partsSolution, Inc. < http://www.partssolution.com > IBM Certified VisualAge for Smalltalk Developer < SmallNews - a Smalltalk UQWK editor for offline news editing > ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-18 0:00 ` Patrick Ma @ 1996-12-18 0:00 ` Caitlin 0 siblings, 0 replies; 209+ messages in thread From: Caitlin @ 1996-12-18 0:00 UTC (permalink / raw) Patrick Ma wrote: > > I am not trying to make the point that OO is more professional than any > other technique. IMO, OO has a rich set of principles that makes ME see it > as a discipline besides being a technology. As a discipline that I practice, I find > myself more determined to identify and correct OO errors and bad practices > that others may let go for the reasons I mentioned above. I believe in OO and I > want to promote it. I want others to see OO as a discipline in addition to being > an excellent technology, IMO. OO, particularly OOA, has a lot of potential and IMHO is essential to defining software with resuable components. However, I hope you are not claiming that it is more suitable to a disciplined approach than the classical structure techniques. These techniques, while perhaps at a deadend and in need of fundamental re-thought to encourage re-use and evolutionairy development, are rich in accumulated wisdom and objective criteria that can be applied to a design. Information Engineering afficionados can find flaws in Information Models without even knowing the target application. When OOA achieves a TENTH of the accumulated consensus and rigorous agreed upon rules the Structured Analysis, Structured Design and Information Engineering have accumulated it will finally be getting somewhere. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-14 0:00 ` Robert C. Martin 1996-12-14 0:00 ` Patrick Ma @ 1996-12-15 0:00 ` Tansel Ersavas 1996-12-17 0:00 ` Adam Beneschan ` (3 more replies) 1996-12-16 0:00 ` Karen A. Morrissey 2 siblings, 4 replies; 209+ messages in thread From: Tansel Ersavas @ 1996-12-15 0:00 UTC (permalink / raw) Robert C. Martin wrote: > > In article <32AA207E.3199@deep.net>, tansel@deep.net wrote: > > > There are three major reasons why OO projects fail. All of them are > > stated by the great wisdom of Jedi in "Star Wars". > > > > These are: > > "Do or do not. There is no try" > > Using my tools and techniques, I can prove you that I can produce > > better and faster systems using OO (Please read my notes at the end > > of this message). If I can do it, so you can.If you just try to do > > it, you will fail. Be determined to do it. > > There is something to this. However, OO will not work just because > you are determined. You must understand the mechanisms that make it work, > and you must know what those mechamisms can, and cannot do. > I know. But when you are determined, you will be much more likely to obtain the knowledge that you need to solve your problems. > OO is a great technique and it can help make software easier to reuse, > modify and maintain. But it is not a cure-all; and it must be understood > in detail and weilded with skill. Agreed. > > > > "You must unlearn what you have learned" > > People cling so heavily to the baggage they have been carrying, > > they can not have an open mind about OO. SO the first thing I do > > in my training sessions is to create doubts and questions about > > the problems of the procedural approach, and why procedure > > orientation is a very ineffective technique for most new problems. > > Of course, you should have a very good mentor that is capable of > > demonstrating these in practical terms. > > Although I agree with your sentiment, I disagree with your terminology. > We don't really want to unlearn anything. We want to integrate the new > tools and mechanisms of OO into our practices. First of all, my opinion is, developing systems with procedure oriented techniques is a dangerous, wasteful and unproductive process. So far OO couldn't show a quantum leap of difference, but it is not mature yet. When I train people, I look at their background. Usually the more experienced in the traditional techniques they are, the less they believe the necessity of learning a new technique. In my breakthrough courses, for the first part, I challenge the traditional ways of systems development and show that this way of developing systems is a historical accident, and the more we insist on going that way, the more troubles we will be in. Unfortunately, with their slow and wasteful structure, big companies can absorb huge amounts of losses without blinking. This contributes a lot to people not realizing how big the crisis is. In fact, even many succesful systems Today are big money wasters. Procedural thinking and OO are not complimentary. Procedural thinking requires a major transformation that affects all our thinking. I know it, because I was a procedural programming freak, starting programming with a 6502 board with hex keypad, and being a mad assembler, C and later C++ person. Even when I was a C, C++ person my productivity was substantially higher than others, I couldn't make the switch to OO until I let my strong and enjoyable procedural skills go. Now I only program with Smalltalk (not a prerequisite to anything, just a choice), and I do everything in a much higher level previously unimaginable to me. My productivity increased 5 fold, and I developed a tool to further increase it another 5 fold. Now I know that the tools and techniques I use are anywhere from 5 to 25 times better than my old techniques before. These techniques are pure OO but I am reaching limits of them. Therefore I expanded my horizons to other techniques that I combine with OO which will increase my productivity another order of magnitude. Anybody wishing to see these techniques in action, I'm happy to demonstrate them. It is the only proof I can show to anyone that OO works, and works much better than anything they have seen so far. And without unlearning, it wouldn't have been possible. > > > > "You must believe in what you are doing" > > OO will help you. It will feel awkward at times, but you must > > persist with it. You will be eventually rewarded. > > You can't just believe without evidence. That evidence can be > empirical. But there are so few controlled experiments that reliable > empirical evidence is hard to find. Or the evidence can be in the form > of a believable rationale. One that can be tested with thought experiements. I'll remind you of the placebo effect. IMO belief creates miracles. But it is also true that blind faith is dangerous. Any time a new paradigm comes around there are pioneers. They make the bold decisions to shape the history. They are less than 1% of the participants. Pioneers are nothing but visioners and believers. They create their evidence, and history. Then there come early adopters. People who don't need "empirical evidence". Who use their intuition to make sense of what the pioneers are pointing to. Then there are popularizers. People are quicker than the others, just like the people who watch the other traffic lights to see when they are going red so that they could be the first to respond to the green light. They require evidence, but can act very quickly. Then there are followers, much like people passing at the green light. They do nothing but go with the crowd. There must be empirical evidence for them. Follows the conservatives, after observing the great mass, they join resentfully And there are resistors, they will NEVER come to the band, no matter how succesful it is. So, empirical evidence is important depending on who you want to deal with. We need people to create this evidence at the moment, and we are desperately short of them. > > OO is not a motivational discipline. It does not take willpower and > determination to "do things right". Rather it takes knowledge and skill. Not only being an OO trainer, but a motivational trainer, I would have to disagree here. Every training should include a motivational component. I totally agree that knowledge and skill are paramount. The important thing is to be able to excite people to get this knowledge and skill. The teacher is as good as he or she can motivate the participants to eagerly accept what he or she is offering. One of the reasons that children learn OO quickly is they are so easily excitable. The moment you show them something, that becomes the most important thing on Earth. But for the grown ups (or as they are labeled by children: "given ups") a big dose of motivation is required to grab their attention. In fact, I can't follow all of it, but during this discussion about what's wrong with OO I tried to observe any excitement, but couldn't see much of it around. > Robert C. Martin | Design Consulting | Training courses offered: > Object Mentor | rmartin@oma.com | Object Oriented Design > 14619 N Somerset Cr | Tel: (847) 918-1004 | C++ > Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com > > "One of the great commandments of science is: > 'Mistrust arguments from authority.'" -- Carl Sagan Tansel Ersavas RASE Inc. mailto:tansel@rase.com http://www.rase.com/ ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-15 0:00 ` Tansel Ersavas @ 1996-12-17 0:00 ` Adam Beneschan 1996-12-17 0:00 ` Ralph Cook 1996-12-18 0:00 ` Tansel Ersavas 1996-12-17 0:00 ` Robert Dewar ` (2 subsequent siblings) 3 siblings, 2 replies; 209+ messages in thread From: Adam Beneschan @ 1996-12-17 0:00 UTC (permalink / raw) In article <32B3F45C.5140@deep.net> tansel@deep.net writes: >Not only being an OO trainer, but a motivational trainer, I would have >to disagree here. Every training should include a motivational >component. I totally agree that knowledge and skill are paramount. The >important thing is to be able to excite people to get this knowledge and >skill. The teacher is as good as he or she can motivate the participants >to eagerly accept what he or she is offering. One of the reasons that >children learn OO quickly is they are so easily excitable. The moment >you show them something, that becomes the most important thing on Earth. >But for the grown ups (or as they are labeled by children: "given ups") >a big dose of motivation is required to grab their attention. "Every training should include a motivational component"??? This is probably true for trainings that are likely to include a bunch of unmotivated people who don't want to be there and are in the training only because their boss is making them and who were hoping to go through the rest of their lives making money by doing the same thing over and over without having to learn anything new. Hopefully, I wouldn't have any such people working for me. I also wouldn't want employees who are able to get so excited that they would "eagerly accept" what a teacher is teaching them; I'd prefer those who are smart enough to look at the material analytically, so that they would understand when, how, and why to apply it. [By the way, I'm speaking as someone who spent a lot of time and money in the past in courses that could be called "motivational" or "self-development" seminars. While they did me a world of good, my experiences have convinced me that the practice of exciting trainees so that they accept things eagerly (and unquestioningly) has great potential for harm as well as for good.] Finally, does anyone else feel insulted by Tansel's post? There seems to be an undercurrent that those who don't believe in OO as fervently as he does [I'm assuming Tansel is a "he"] are unmotivated, have "given up", don't want to learn anything new, are "followers", etc. This seems like it would be insulting to many truly professional engineers. -- Adam ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-17 0:00 ` Adam Beneschan @ 1996-12-17 0:00 ` Ralph Cook 1996-12-18 0:00 ` Tansel Ersavas 1 sibling, 0 replies; 209+ messages in thread From: Ralph Cook @ 1996-12-17 0:00 UTC (permalink / raw) Adam Beneschan wrote: ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-17 0:00 ` Adam Beneschan 1996-12-17 0:00 ` Ralph Cook @ 1996-12-18 0:00 ` Tansel Ersavas 1 sibling, 0 replies; 209+ messages in thread From: Tansel Ersavas @ 1996-12-18 0:00 UTC (permalink / raw) Adam Beneschan wrote: > "Every training should include a motivational component"??? This is > probably true for trainings that are likely to include a bunch of > unmotivated people who don't want to be there and are in the training > only because their boss is making them and who were hoping to go > through the rest of their lives making money by doing the same thing > over and over without having to learn anything new. Hopefully, I > wouldn't have any such people working for me. I also wouldn't want > employees who are able to get so excited that they would "eagerly > accept" what a teacher is teaching them; I'd prefer those who are > smart enough to look at the material analytically, so that they would > understand when, how, and why to apply it. I would like to congratulate you if you were able to organize such a group. IME only small software houses or very autonomous, independent sections of big companies are able to collect such people. Sadly, in many other cases there are a bunch of people in the courses just because their company want them to be in that course. If you have a group of people who know what they want, and ready to absorb, that would be great. IME, even for eager classes , still use a touch of motivation, which is embedded in my own (as you say) eagerness, and ability to show what can be done with OO, and how different and better it would be. Also my mention of motivation shouldn�t be mixed with pure motivational techniques, which I also use sometimes at my and the people�s discretion. Training can be thread by itself, and I guess it has no place in comp.object unless it is "how to teach OO" which I think should be discussed as well. Meanwhile I know the effectiveness of my techniques, and I�ll continue to use them. > > [By the way, I'm speaking as someone who spent a lot of time and money > in the past in courses that could be called "motivational" or > "self-development" seminars. While they did me a world of good, my > experiences have convinced me that the practice of exciting trainees > so that they accept things eagerly (and unquestioningly) has great > potential for harm as well as for good.] That's true, but what harm could they get from eagerly learning OO? Applying it more rigorously? IME I get more benefit, and hardly any harm. > Finally, does anyone else feel insulted by Tansel's post? There seems > to be an undercurrent that those who don't believe in OO as fervently > as he does [I'm assuming Tansel is a "he"] are unmotivated, have > "given up", don't want to learn anything new, are "followers", etc. > This seems like it would be insulting to many truly professional > engineers. The quote about the "pioneers", "early adopters" "followers" etc. comes from "Diffusion of Innovations" by Everett Rogers, and I quote it a lot along with the percentages. However, I haven't had anybody offended or insulted by these statistics. Yes, IMO anybody joining OO before OO becomes a mainstream will be pioneers or early adopters. If you are looking at penetration of OO to the mainstream computing, we are far off the mainstream as yet. So I couldn't have possibly said or implied that anybody not coming to the OO bandwagon right now would be followers. Besides, even if I implied that, what could be wrong if someone chooses to be a follower? I have the strong belief that people have a right to be where they are, and do what they want. From time to time, I would like to be a follower, rather than a pioneer or an early adopter, and that would be my choice. Anyone pointing that out to me, I would simply state my reasons to be a follower, and listen to the other person with an open mind. I would choose to be a follower or even a conservative if I think that there won't be any benefits, or even some harm can be done by following a certain path. So even if someone declares that they are a conservative, I would listen to what they say, try to understand their reasons. Because I can learn from them, and to a conservative I am the other extreme. I would hope that he or she could do the same for me. Sometimes there is a wisdom of being ahead or behind, it is very healthy, and I have respect for ALL of them. All I want to do is create a little bit excitement for OO, because I can clearly see the benefits of it. So I want everybody to look into it. BTW I heard the "given ups" comment from a child at one of our conversations about computers, and I sometimes quote it because it is an interesting point of view to come out of a 10 year old , not in any way to deride people. > -- Adam Tansel ----------------------------------------------------------------------- RASE Inc. Clark NJ USA Voice: (908) 396 7145 mailto:tansel@rase.com Fax: (908) 382 1383 http://www.rase.com/ ----Sufficiently advanced technology is indistinguishable from magic--- -------------------------------A.C. Clarke----------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-15 0:00 ` Tansel Ersavas 1996-12-17 0:00 ` Adam Beneschan @ 1996-12-17 0:00 ` Robert Dewar 1996-12-18 0:00 ` Tansel Ersavas 1996-12-19 0:00 ` Robert C. Martin 1996-12-17 0:00 ` Adam Beneschan 1996-12-24 0:00 ` Nigel Tzeng 3 siblings, 2 replies; 209+ messages in thread From: Robert Dewar @ 1996-12-17 0:00 UTC (permalink / raw) Tansel says "First of all, my opinion is, developing systems with procedure oriented techniques is a dangerous, wasteful and unproductive process." It is this kind of unsupporable hyperbole that gives OO a bad name! Why is it that when anyone comes along with new techniques that represent a useful incremental advance in our knowledge in this area (e.g. functional programming, proof of correctness, your-favorite-fad-here) they feel compelled to hype them like this with the approach "what we have done before is an unmitigated disaster, but my new technique will make a revolutionary difference". The trouble with such hype is that inevitably it does not deliver, and then there is a danger of throwing out the baby with the bathwater and discarding what is useful along with the hype. The fact of the matter is that there is NO giant shift of paradigm involved here, despite what anyone says. Just look at the OO programs that people produce. They are not radically different from conventional procedural programs, and one would not expect them to be. OO techniques are a useful way of extending the conceptual design domain, and OO features in programming languages allow added flexibility in the solution space. Good! But trying to fit everything into the OO mold is as reasonable as believing these ads on TV that suggest that all your handy-man's problems at home can be solved with one amazing tool! ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-17 0:00 ` Robert Dewar @ 1996-12-18 0:00 ` Tansel Ersavas 1996-12-27 0:00 ` clovis 1996-12-19 0:00 ` Robert C. Martin 1 sibling, 1 reply; 209+ messages in thread From: Tansel Ersavas @ 1996-12-18 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Tansel says > > "First of all, my opinion is, developing systems with procedure oriented > techniques is a dangerous, wasteful and unproductive process." > > It is this kind of unsupporable hyperbole that gives OO a bad name! Unsupportable? Hyperbole? Are we mentioning about the software gap, or failed projects, or wasted money? Why don't you look at statistics about these? Turning a blind eye on Today's problems will not get us anywhere. First of all, we should admit that we have a problem, then find a solution to it. We ALL contribute to lost billions by ignoring what's happening around us. > Why is it that when anyone comes along with new techniques that represent > a useful incremental advance in our knowledge in this area (e.g. > functional programming, proof of correctness, your-favorite-fad-here) > they feel compelled to hype them like this with the approach OO is not an incremental advance. It has started and continued that way, because SIMULA was an extension to Algol, and some of the most dominant languages are extensions of procedure oriented languages. This does more harm than good to OO. Many professionals I have talked to told me that until they made a switch ( or some of them call it a "click") they weren't able to benefit from OO a lot. It is more difficult to have that "click" if we have to work in an environment and a language which is basically an OO extension to a procedural background. It is true that every newcomer announces that it is a significant advancement over procedure orientation. This is because people are worried about the current paradigm, and they in search for a better one. > "what we have done before is an unmitigated disaster, but my new technique > will make a revolutionary difference". These are not my words > The trouble with such hype is that inevitably it does not deliver, and then > there is a danger of throwing out the baby with the bathwater and > discarding what is useful along with the hype. OO as is now, is a struggling, and not much appreciated figure around. It has its troubles, but they are slowly being ironed out. Yes, there may be a short term backlash against OO, it may even go back a couple of years. This is not important. It will come back, and will eventually dominate. > The fact of the matter is that there is NO giant shift of paradigm involved > here, despite what anyone says. Just look at the OO programs that people > produce. They are not radically different from conventional procedural > programs, and one would not expect them to be. Unfortunately, many OO programs that people produce are produced by people who are learning. They will be better and better, the gap will be larger and larger, and differences will be more and more obvious. People have short memories. A very similar sort of discussion with similar tones was done when first high level languages were introduced. Proponents of machine code and assembly languages said, this new paradigm was nothing new, just a bigger, bulkier way of doing the same thing with speed penalties, it was not practical, people would never program with them in masses, etc, etc. Now we see everything has settled down, there are still people write code in assembly and nothing else, however they are the minority. Same things will happen with object orientation. It is a big paradigm shift even if you deny it. The current object orientation that we use is a layer on top of procedure oriented architectures. That may fool some people into thinking that OO is an incremental advance. It is not. The real benefits of OO will come when the underlying architecture supports it. Then, a new breed of object oriented OSs, languages and tools will emerge, and procedure orientation will shrink into minority. > OO techniques are a useful way of extending the conceptual design domain, > and OO features in programming languages allow added flexibility in > the solution space. Good! But trying to fit everything into the OO mold > is as reasonable as believing these ads on TV that suggest that all your > handy-man's problems at home can be solved with one amazing tool! So far, we benefited marginally by molding everything into procedure oriented paradigm even if it did not naturally fit into it. In fact we tried to use one amazing tool called procedure oriented paradigm for every one of our problems. I admire what we achieved with it because it requires much greater talent and effort than molding everthing into an OO paradigm. But this extra effort and talent can be used somewhere else if we can embrace methodologies which teach us ways of easier and more economical ways of doing it. Kind Regards Tansel ----------------------------------------------------------------------- RASE Inc. Clark NJ USA Voice: (908) 396 7145 mailto:tansel@rase.com Fax: (908) 382 1383 http://www.rase.com/ ----Sufficiently advanced technology is indistinguishable from magic--- -------------------------------A.C. Clarke----------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-18 0:00 ` Tansel Ersavas @ 1996-12-27 0:00 ` clovis 1996-12-27 0:00 ` Jacqueline U. Robertson ` (2 more replies) 0 siblings, 3 replies; 209+ messages in thread From: clovis @ 1996-12-27 0:00 UTC (permalink / raw) In <32B81DA7.6D08@deep.net>, Tansel Ersavas <tansel@deep.net>, in a fit of extreme hubris, wrote: >Robert Dewar wrote: >> >> Tansel says >> >> "First of all, my opinion is, developing systems with procedure oriented >> techniques is a dangerous, wasteful and unproductive process." >> >> It is this kind of unsupporable hyperbole that gives OO a bad name! > >Unsupportable? Hyperbole? Are we mentioning about the software gap, or >failed projects, or wasted money? >Why don't you look at statistics about these? The problem is bad coders. Those of us who have been around for 20 years have long ago noticed that 10% of the world's programmers could do 100% of the work and not have it spontaneously collapse, by doing it right the first time. This has nothing to do with paradigm. It has everything to do with a quality attitude and the ability to conceptualize. What OO will do is help wash some of the dross out of the coding pool. But I've done enough Smalltalk in the past year to know that I can write just as sloppily in Smalltalk, and make even bigger errors, harder to correct, as I code my way along, without a previously completed design, as I can with anything. If anything, Assembly Language is easier to fix, precisely because the procedures are more amenable to "redesign" and "reuse" than a single hirearchy. >Turning a blind eye on Today's problems will not get us anywhere. First >of all, we should admit that we have a problem, then find a solution to >it. We ALL contribute to lost billions by ignoring what's happening >around us. What problems? The lack of good software is due to the lack of good education, high levels of intelligence distributed all around in the people doing the work, and so on. People do programming. OO CAN be easier, in something like Smalltalk, because there is so much framework for grunt stuff like the GUI. So I greatly differ with your take on things here. >> Why is it that when anyone comes along with new techniques that represent >> a useful incremental advance in our knowledge in this area (e.g. >> functional programming, proof of correctness, your-favorite-fad-here) >> they feel compelled to hype them like this with the approach > >OO is not an incremental advance. It has started and continued that way, >because SIMULA was an extension to Algol, and some of the most dominant >languages are extensions of procedure oriented languages. This does more >harm than good to OO. Many professionals I have talked to told me that >until they made a switch ( or some of them call it a "click") they >weren't able to benefit from OO a lot. It is more difficult to have that >"click" if we have to work in an environment and a language which is >basically an OO extension to a procedural background. >It is true that every newcomer announces that it is a significant >advancement over procedure orientation. This is because people are >worried about the current paradigm, and they in search for a better one. Smalltalk and other OO paradigms are an unmitigated disaster at certain kinds of problems. Ask me about Modified Midpoint integration or, say, adaptive Runge- Kutta under Smalltalk. We give up as much as two orders of magnitude in computational efficiency. The more a tool does for you, the more it also does to you. What is being complained about here is that you treat OO as though a pure OO language "gives" all this good stuff without a price. And, in reality, the price is quite high. >> The trouble with such hype is that inevitably it does not deliver, and then >> there is a danger of throwing out the baby with the bathwater and >> discarding what is useful along with the hype. > >OO as is now, is a struggling, and not much appreciated figure around. >It has its troubles, but they are slowly being ironed out. Yes, there >may be a short term backlash against OO, it may even go back a couple of >years. This is not important. It will come back, and will eventually >dominate. I don't find anything "struggling" about using VisualWorks or IBM's VisualAge on Windows, OS/2 or OSF/Motif platforms -- they are basically just extentions of GUI paradigms built on top of Smalltalk/80 to begin with, so they are quite natural and straightforward to use -- ONCE ONE HAS CRACKED INTO THE HIREARCHY. The chief complaint I have about OO is that one has to learn a hirearchy, and one which is in the general case sloppily and amateurishly documented, instead of the better understood and generally much better documented procedural library. This inferior documentation is, in my view, the reason for OO's lack of popular success. It is, much as you are displaying here, more of a religion for its adherents than it is regarded as what it should be -- a convenience tool. There is nothing OO can do that pure object code can't do. All we're doing is adding the hirearchy to raise the level of abstraction, so one doesn't have to spend as much time fussing with daily details. >> The fact of the matter is that there is NO giant shift of paradigm involved >> here, despite what anyone says. Just look at the OO programs that people >> produce. They are not radically different from conventional procedural >> programs, and one would not expect them to be. > >Unfortunately, many OO programs that people produce are produced by >people who are learning. They will be better and better, the gap will be >larger and larger, and differences will be more and more obvious. Duh! This is arrogant nonsense, sir. OO cannot and will not make a case for itself until it can demonstrate to the average working programmer something in the way of return for the struggle to learn the hirearchy. >People have short memories. A very similar sort of discussion with >similar tones was done when first high level languages were introduced. >Proponents of machine code and assembly languages said, this new >paradigm was nothing new, just a bigger, bulkier way of doing the same >thing with speed penalties, it was not practical, people would never >program with them in masses, etc, etc. Now we see everything has settled >down, there are still people write code in assembly and nothing else, >however they are the minority. Yes, Assembler is the minority. And as a result Microsoft Word wants 120 megs on a disk, where WordStar lived comfortably in 64k, code and data both. Word does very little more. Seems we were told the truth to begin with, eh? Word barely runs in 8 megs of RAM. You started out talking about waste. Why 8 megs instead of 64k? We have some differences of opinion here. Regards, Frank ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-27 0:00 ` clovis @ 1996-12-27 0:00 ` Jacqueline U. Robertson 1996-12-27 0:00 ` Tore Lund 1996-12-28 0:00 ` clovis 1996-12-27 0:00 ` Tore Lund 1996-12-28 0:00 ` Stephen Pendleton 2 siblings, 2 replies; 209+ messages in thread From: Jacqueline U. Robertson @ 1996-12-27 0:00 UTC (permalink / raw) In article <59vr2s$55r@masters0.InterNex.Net>, <clovis@wartech.com> wrote: >In <32B81DA7.6D08@deep.net>, Tansel Ersavas <tansel@deep.net>, in a fit of >Yes, Assembler is the minority. And as a result Microsoft Word wants 120 megs on >a disk, where WordStar lived comfortably in 64k, code and data both. Word does >very little more. > >Seems we were told the truth to begin with, eh? > >Word barely runs in 8 megs of RAM. > >You started out talking about waste. Why 8 megs instead of 64k? > >We have some differences of opinion here. > Well, I was with you to some extent until you got here. Code bloat is a simple trade-off for increased maintainability and extensibility. Quite simply, it's easier to maintain and extend a decently written application in high level code than it is to maintain and extend a decently written application in assembler. Why ? Because the high level language applied is easier to read, particularly for follow on developers who were not involved in the original work. The trade-off is that the assembly level application was more compact (both in disk space and in memory usage) - but harder to extend and modify. There's a reason that assembly level development is limited to small areas (such as in the limited resource milieu of deep space probes) - the trade off in favor of high level languages has generally been worth it, as increased disk space and increased amounts of RAM are economically cheaper than the 'more efficient' assembler writing. I'd guess that over time (and in this case I'm guessing a fairly long interval), machine generated applications will end up being cheaper than hand written ones for much the same reason. James A. Robertson email: jamesr@parcplace.com phone: 410 952-0471 <note that I am posting through my wife's account. I don't claim to speak for her> >Regards, > >Frank ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-27 0:00 ` Jacqueline U. Robertson @ 1996-12-27 0:00 ` Tore Lund 1996-12-28 0:00 ` Tansel Ersavas ` (5 more replies) 1996-12-28 0:00 ` clovis 1 sibling, 6 replies; 209+ messages in thread From: Tore Lund @ 1996-12-27 0:00 UTC (permalink / raw) James Robertson wrote: > > In article <59vr2s$55r@masters0.InterNex.Net>, <clovis@wartech.com> wrote: > > (snip) > >You started out talking about waste. Why 8 megs instead of 64k? > > Well, I was with you to some extent until you got here. Code bloat is > a simple trade-off for increased maintainability and extensibility. > Quite simply, it's easier to maintain and extend a decently written > application in high level code than it is to maintain and extend a > decently written application in assembler. Why ? Yes, why? The most important reason is that most programmers don't know assembler or bother to learn it well enough to write decent code in it. You don't agree, of course, but the point here is is that the 64k program written in assembler will still be < 100k when written in C. There is no need for "code bloat" on the scale of 8 megs for maintainability purposes. -- Tore Lund <tl001@sn.no> ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-27 0:00 ` Tore Lund @ 1996-12-28 0:00 ` Tansel Ersavas 1996-12-28 0:00 ` Tore Lund 1996-12-31 0:00 ` Adam Beneschan 1996-12-29 0:00 ` clovis ` (4 subsequent siblings) 5 siblings, 2 replies; 209+ messages in thread From: Tansel Ersavas @ 1996-12-28 0:00 UTC (permalink / raw) > > >The problem is bad coders. Those of us who have been around for 20 > > >years have > > >long ago noticed that 10% of the world's programmers could do 100% of > > >the work > > >and not have it spontaneously collapse, by doing it right the first > > >time. I have similar observations as well. However, I would think that would be only one of the problems, and the approach we have in teaching systems development has a great impact on these people. > > >This has nothing to do with paradigm. It has everything to do with a > > >quality attitude > > >and the ability to conceptualize. IMO that has a lot to do with paradigm. However, I won't have enough time to explain it now. > > >What OO will do is help wash some of the dross out of the coding pool. > > > > > >But I've done enough Smalltalk in the past year to know that I can write > > >just as > > >sloppily in Smalltalk, and make even bigger errors, harder to correct, > > >as I code > > >my way along, without a previously completed design, as I can with > > >anything. That is exactly true > > >If anything, Assembly Language is easier to fix, precisely because the > > >procedures > > >are more amenable to "redesign" and "reuse" than a single hirearchy. > > > I am not sure about that. I dusted out some of the games I wrote in 1982. I can't seem to easily grasp them, maybe because I completely forgot Z80 assembly language, or maybe I don't have a Z80 machine or a decent emulator to run. Even with an emulator, I would have had to rewrite direct screen manipulation modules, keyboard modules and sound modules. > > >>Turning a blind eye on Today's problems will not get us anywhere. First > > >>of all, we should admit that we have a problem, then find a solution to > > >>it. We ALL contribute to lost billions by ignoring what's happening > > >>around us. > > > > > >What problems? The lack of good software is due to the lack of good > > >education, > > >high levels of intelligence distributed all around in the people doing > > >the work, and > > >so on. People do programming. OO CAN be easier, in something like > > >Smalltalk, > > >because there is so much framework for grunt stuff like the GUI. > > > > > >So I greatly differ with your take on things here. The problems I am mentioning about are collapses of big projects with a typical 100 million waste per big project. These companies DO have very good people, because they can afford them. And yes, there are usually 100s of people of which at least 10s are good. In the very beginning of the thread, I had four areas as the source of the problem. Other three are vanished, and I have to defend only one, namely OO approach. However, in my previous postings I stated people, organizational structure, techniques and tools as the sources of the problem. I do not think that we differ greatly, from what you see it looks like I point procedure orientation as the only cause, which is not correct. > > >>> Why is it that when anyone comes along with new techniques that represent > > >>> a useful incremental advance in our knowledge in this area (e.g. > > >>> functional programming, proof of correctness, your-favorite-fad-here) > > >>> they feel compelled to hype them like this with the approach > > >> > > >>OO is not an incremental advance. It has started and continued that way, > > >>because SIMULA was an extension to Algol, and some of the most dominant > > >>languages are extensions of procedure oriented languages. This does more > > >>harm than good to OO. Many professionals I have talked to told me that > > >>until they made a switch ( or some of them call it a "click") they > > >>weren't able to benefit from OO a lot. It is more difficult to have that > > >>"click" if we have to work in an environment and a language which is > > >>basically an OO extension to a procedural background. > > >>It is true that every newcomer announces that it is a significant > > >>advancement over procedure orientation. This is because people are > > >>worried about the current paradigm, and they in search for a better one. > > > > > >Smalltalk and other OO paradigms are an unmitigated disaster at certain > > >kinds > > >of problems. Ask me about Modified Midpoint integration or, say, > > >adaptive Runge- > > >Kutta under Smalltalk. We give up as much as two orders of magnitude in > > >computational efficiency. The more a tool does for you, the more it > > >also does > > >to you. The numerical number crunching problems are perfect problems that a von Neumann machine is designed for, so can be handled quite elegantly with procedural languages. They are well defined algorithms that take up a very reasonable number of lines of code. However we need Runge-Kutta in our real life even less than we need our calculator. I use Smalltalk extensively, but revert back to C or even assembler when I need procedural number crunching, and offer these as DLLs. On the other hand, a simple ORB is reasonably trivial in Smalltalk, but if you want to develop in any procedure oriented system, even in C++, it takes a lot of time and effort. I think people tend to see black and white. When I sent my first replies to this thread, I made my postion clear by first defining the von Neumann machine and what it was initially designed for. Anything that is suitable to this initial design purpose should be handled by the procedural approach, which IME&O is just about 10% of all our problems. Anything beyond that is an abuse of the initial design purpose, and requires much greater effort to get the same work done in a procedural environment. > > > > > >What is being complained about here is that you treat OO as though a > > >pure OO > > >language "gives" all this good stuff without a price. And, in reality, > > >the price is > > >quite high. If you are talking about 20MB image Smalltalk systems, or 80MB Borland compilers, I tend to agree with you there. They could have been done simpler, and less complex. There is also another price that I will mention later. > > >>> The trouble with such hype is that inevitably it does not deliver, and then > > >>> there is a danger of throwing out the baby with the bathwater and > > >>> discarding what is useful along with the hype. > > >> > > >>OO as is now, is a struggling, and not much appreciated figure around. > > >>It has its troubles, but they are slowly being ironed out. Yes, there > > >>may be a short term backlash against OO, it may even go back a couple of > > >>years. This is not important. It will come back, and will eventually > > >>dominate. > > > > > >I don't find anything "struggling" about using VisualWorks or IBM's > > >VisualAge on > > >Windows, OS/2 or OSF/Motif platforms -- they are basically just > > >extentions of > > >GUI paradigms built on top of Smalltalk/80 to begin with, so they are > > >quite > > >natural and straightforward to use -- ONCE ONE HAS CRACKED INTO THE > > >HIREARCHY. > > > > > >The chief complaint I have about OO is that one has to learn a > > >hirearchy, and one > > >which is in the general case sloppily and amateurishly documented, > > >instead of the > > >better understood and generally much better documented procedural > > >library. It parallels my observations that the most difficult part of learning OOP environments is their class hierarchy. Our company is working towards visualizing these class hierarchies that in our experience increase the learning curve no matter what other people say about visualization. > > >This inferior documentation is, in my view, the reason for OO's lack of > > >popular > > >success. It is, much as you are displaying here, more of a religion for > > >its > > >adherents than it is regarded as what it should be -- a convenience > > >tool. I think it is a misunderstanding that I take OO as a religion. However, in my position after observing how much better a decent OO approach is, I see current defenders of the "existing system" much more religious than I can ever be. In our company, we do not only practice OO, we also experiment heavily with neural computing, genetic programming and fuzzy logic, and use them in projects. OO has its shortcomings, but only one of these shortcomings namely number crunching can be remedied by a pure procedural approach. There are certain very serious problems though. First of all, people don't even know why do we program the way we program, and think that must be the right way to do it. I first wanted to indicate that by pointing to the birth of procedure oriented programming, and I raised the voice of its inventor to the dangers of using it at wide scale. > > >There is nothing OO can do that pure object code can't do. ^^^^^^ Was that ment to be procedural? If so, it is true. In fact it is being done everywhere, everyday. However, there is a price that we all pay. Again I'll explain in my posting later. > > >All we're doing is adding the hirearchy to raise the level of > > >abstraction, so one > > >doesn't have to spend as much time fussing with daily details. > > > I will explain one very important difference between PO and OO approach after the new year. I'll prepare and send a post when I have time. > > >>> The fact of the matter is that there is NO giant shift of paradigm involved > > >>> here, despite what anyone says. Just look at the OO programs that people > > >>> produce. They are not radically different from conventional procedural > > >>> programs, and one would not expect them to be. > > >> > > >>Unfortunately, many OO programs that people produce are produced by > > >>people who are learning. They will be better and better, the gap will be > > >>larger and larger, and differences will be more and more obvious. > > > > > >Duh! This is arrogant nonsense, sir. OO cannot and will not make a case > > >for itself > > >until it can demonstrate to the average working programmer something in > > >the way > > >of return for the struggle to learn the hirearchy. I could not possibly agree with the "arrogant nonsense" bit but the rest is true. If you can see that learning the class hierarchy quicker can accelerate the results, it is very positive. In fact this will be an important area, but there are more, again I will explain in my upcoming post. > > >>People have short memories. A very similar sort of discussion with > > >>similar tones was done when first high level languages were introduced. > > >>Proponents of machine code and assembly languages said, this new > > >>paradigm was nothing new, just a bigger, bulkier way of doing the same > > >>thing with speed penalties, it was not practical, people would never > > >>program with them in masses, etc, etc. Now we see everything has settled > > >>down, there are still people write code in assembly and nothing else, > > >>however they are the minority. > > > > > >Yes, Assembler is the minority. And as a result Microsoft Word wants > > >120 megs on > > >a disk, where WordStar lived comfortably in 64k, code and data both. > > >Word does > > >very little more. > > > > > >Seems we were told the truth to begin with, eh? > > > > > >Word barely runs in 8 megs of RAM. > > > > > >You started out talking about waste. Why 8 megs instead of 64k? This is one of the kind of waste I am mentioning. I hope that you are not claiming Microsoft uses OO to create Word. No way! The entire Microsoft suite is a good example of how procedure oriented systems can get out of control. If they had used a true OO approach from their operating system on, they would have a much leaner system with a component architecture, and very high degrees of reuse. > > >We have some differences of opinion here. And it is very healthy, we can learn from each other, and enlarge our horizons. Without differences of opinion, the world would be such a boring place. > > > > > >Regards, > > > > > >Frank > Yes, why? The most important reason is that most programmers don't know > assembler or bother to learn it well enough to write decent code in it. I don't really think that you need to know assembler to develop good compact systems. In fact, we recently developed one of the most useful visual development tools in existence. It is written in Smalltalk, and developed in record time. The SLL of our VSE version is under 300KB before compression. In fact, there was a debate in our company that if we distributed our product in one floppy, nobody would take it seriously, there were serious suggestions to bump it up to offer in several floppies or offering a CD-ROM version only. There are two types of waste we are mentioning here: 1) The time and resources required to develop and maintain that system 2) The hardware demands of that system By far the first item has the biggest impact. If the trends go like they have been going in the past ten years, we will have about half of the world's economy chewed by our blown computer costs of which about 75% or more will be software development and maintenance costs around 2030 (down from 5% of the world economy in late 80s). Any savings we start making now will have a huge impact on our future. The hardware demands of the systems also add to the waste, through to a lesser degree. I will write about these when I prepare my post about the subject of this thread. Please hold on to your questions and objections till I have time to prepare my posting, so that you have a whole perspective of what I am talking about, then I will gladly accept any flames, as well as positive comments. Taking out one statement I say and flaming it out of context doesn't do much justice. Kind Regards Tansel ----------------------------------------------------------------------- RASE Inc. Clark NJ USA Voice: (908) 396 7145 mailto:tansel@rase.com Fax: (908) 382 1383 http://www.rase.com/ ----Sufficiently advanced technology is indistinguishable from magic--- -------------------------------A.C. Clarke----------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-28 0:00 ` Tansel Ersavas @ 1996-12-28 0:00 ` Tore Lund 1996-12-31 0:00 ` Adam Beneschan 1 sibling, 0 replies; 209+ messages in thread From: Tore Lund @ 1996-12-28 0:00 UTC (permalink / raw) Tansel Ersavas wrote: > > >> Yes, why? The most important reason is that most programmers don't know >> assembler or bother to learn it well enough to write decent code in it. > > I don't really think that you need to know assembler to develop good > compact systems. You are quite right, but my comment was an answer to the question of why it's hard to write and maintain programs in assembler. > In fact, we recently developed one of the most useful > visual development tools in existence. It is written in Smalltalk, and > developed in record time. The SLL of our VSE version is under 300KB > before compression. In fact, there was a debate in our company that if > we distributed our product in one floppy, nobody would take it > seriously, there were serious suggestions to bump it up to offer in > several floppies or offering a CD-ROM version only. Fascinating. And thanks for telling us. If you have the time, please add a comment about the execution speed of this Smalltalk system. Regards, Tore -- Tore Lund <tl001@sn.no> ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-28 0:00 ` Tansel Ersavas 1996-12-28 0:00 ` Tore Lund @ 1996-12-31 0:00 ` Adam Beneschan 1996-12-31 0:00 ` Robert C. Martin 1996-12-31 0:00 ` clovis 1 sibling, 2 replies; 209+ messages in thread From: Adam Beneschan @ 1996-12-31 0:00 UTC (permalink / raw) In article <32C557F6.532C@rase.com> tansel@rase.com writes: >The numerical number crunching problems are perfect problems that a von >Neumann machine is designed for, so can be handled quite elegantly with >procedural languages. They are well defined algorithms that take up a >very reasonable number of lines of code. However we need Runge-Kutta in >our real life even less than we need our calculator. I use Smalltalk >extensively, but revert back to C or even assembler when I need >procedural number crunching, and offer these as DLLs. On the other hand, >a simple ORB is reasonably trivial in Smalltalk, but if you want to >develop in any procedure oriented system, even in C++, it takes a lot of >time and effort. A number of times in this thread, OO has been compared to "von Neumann machines" as if they are opposing paradigms. This is confusing to me--could someone explain it? My understanding of von Neumann machines is that they execute one statement at a time, in order. Most of the high-level languages I've seen do the same thing, whether or not they're OO languages. It seems to me that if (as implied by earlier posts in this thread) the "von Neumann" paradigm is the problem, then the solution is something like Backus' FP or Prolog or Haskell or dataflow--not OO, which seems to me to have nothing to do with whether the von Neumann model is being followed or not. Am I missing something? -- Adam ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-31 0:00 ` Adam Beneschan @ 1996-12-31 0:00 ` Robert C. Martin 1996-12-31 0:00 ` clovis 1 sibling, 0 replies; 209+ messages in thread From: Robert C. Martin @ 1996-12-31 0:00 UTC (permalink / raw) In article <5aa0eo$thd@krusty.irvine.com>, adam@irvine.com (Adam Beneschan) wrote: > A number of times in this thread, OO has been compared to "von Neumann > machines" as if they are opposing paradigms. This is confusing to > me--could someone explain it? My understanding of von Neumann > machines is that they execute one statement at a time, in order. Most > of the high-level languages I've seen do the same thing, whether or > not they're OO languages. It seems to me that if (as implied by > earlier posts in this thread) the "von Neumann" paradigm is the > problem, then the solution is something like Backus' FP or Prolog or > Haskell or dataflow--not OO, which seems to me to have nothing to do > with whether the von Neumann model is being followed or not. Am I > missing something? Von Neumann invented the notion that the computer program could be stored in the memory of the computer (rather than wired in through a patch panel). At least that is my recollection. A "Von Neumann Machine" is something different altogether. It is a machine that knows how to make copies of itself. Humans are Von Neumann machines. -- Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (847) 918-1004 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-31 0:00 ` Adam Beneschan 1996-12-31 0:00 ` Robert C. Martin @ 1996-12-31 0:00 ` clovis 1996-12-31 0:00 ` Neville Black ` (3 more replies) 1 sibling, 4 replies; 209+ messages in thread From: clovis @ 1996-12-31 0:00 UTC (permalink / raw) In <5aa0eo$thd@krusty.irvine.com>, adam@irvine.com (Adam Beneschan) writes: >In article <32C557F6.532C@rase.com> tansel@rase.com writes: You're quite right. Tansel is acting like quite a pretender on this one, and he obviously doesn't know what either a Von Neumann machine is, or what a Turing machine is. A Von Neumann "machine" is really a recommended architecture, and really, there aren't many of them. They feature regular instruction sets, with zero duplication of function, and all operations being orthogonal. The basic feature of the Von Neumann machine is all classes of basic arithmetic operation, and all classes of comparisions within the two basic numeric types. The "ideal" Von Neumann machine supports natural numbers, integers, reals (actually, length limited rational numbers), in which any operation -- add, subtract, multiply, divide and compare -- are entirely separate. That is ALL we mean by a Von Neumann machine. If you delete ANY aspect of a Von Neumann machine, you can't do basic computation. One is either missing discrete whole numbers, or the ability to compute rational numbers and their real number simulation, or the ability to tell if one number is the same size as, or larger, than another number. The Von Neumann model, while not strictly followed in terms of orthogonality, is inherent in every general purpose digital computing machine ever made, even the Intel 80x86 family (which does it all, but which is not symmetrical or wholly orthogonal; and the same is largely true of RISC, whose primary function is to reduce transistor count). If you are using a discrete representation, noise-resistant at speed (e.g. this mandates binary encoding at the hardware level), Von Neumann is the Ideal Model. The Turing Machine is the minimal machine -- generally thought of, but not necessarily, a pure Von Neumann, architecture. Anything computable is computable on a Turing Machine with sufficient memory. In short, all digital computers are essentially just variances on Von Neumann and Turing, both of whom were mathematicians interested in computing technology as the notion of a code-based computation became available, that is, a computing machine which was capable of responding to codes which could control execution based on previous results. Similarly, compilers are merely translators which first parse an artificial language, translate (generally) to P-Code, and then finally translate to native object code in the code generator. None of this is really rocket science. And it's never ceased to amaze me how many of the "hip" guys can't even define the basic terms. The most "Von Neumann" architecture seen on a microprocessor was the National Semi 16032 family in its original incarnation. It was entirely symmetrical and entirely orthogonal as nearly as I could tell. The Motorola 68k family was mostly DEC PDP like and borrowed a bit from the VAX as well. The Intel 80x86 family was, and is, quite a mess in its lack of symmetry, and is also not at all fully orthogonal; sometimes it takes two instructions to do one function (memory-memory move from a single register), and sometimes, "special" instructions perform the functoin of several available, simpler instructions. The only "real" operations the hardware CAN perform at this point in time are the four arithmetic operations (+,-,*,/) and compares, and jumps/branches based on flag settings. The most advanced math co-processing units are just larger blocks of these operations. Assembler will ALWAYS be the most efficient language. The more you abstract the problem, the more you "generalize" the solution to a given problem, the more you necessarily give up in efficiency. C takes a minimal 3x hit on integer arithmetic, 10x on more complex stuff; and OO, because of the overhead interpreting where to send things, is 10x on top of that. Whether one can AFFORD to spend the time hand-tweaking a fullbore assembler application is another matter. Obviously, we have to have enough talent to write 3x over C, and 30x over OO. The optimal solution is a tradeoff -- a genuine cost/benefit relationship. My notion of the ideal and genuine Systems Analyst is someone who has the intellect to break a problem to its component parts, and localize which tools and components meet the cost/benefit analysis which gives maximum bang for the buck at each component level. Assembly language has its place. No systems programmer would discard it for a heartbeat -- and it is universally used in realtime since only hand-carved assembler allows on to rigorously control latency and pathlength. Procedural is much easier to maintain, and is typically the language of choice for people doing numerical analysis. Equations are more readily written/debugged/maintained in them; the prototype was FORTRAN, which was the FIRST procedural language and was intended to support primarily this kind of operation. OO is, in my view, strictly a Smalltalk proposition until something slicker comes along. I personally use all three in Smalltalk applications which involve a variety of disciplines. Smalltalk handles the GUI, but engines in C and ASM are also required in some cases. Any realtime requirements point to ASM, and any number crunching points to C most of the time (Assembler if the computation must be made in realtime, and be interruptable in mid-stream). Smalltalk itself is not entirely Smalltalk. It contains both procedural (often C), and frequently ASM routines at the kernel since no general purpose machine ever built comprehends objects -- all the underlying hardware knows about is basic arithmetic, compares, and jumps/branches based on flags settings. ASM is REALITY. C is an abstraction of that reality. Smalltalk is an abstraction of reality at a higher level than C. And that's all that is REALLY happening here. We're building in convenience features to avoid having to write 200 lines of Assembler to handle a single Smalltalk message. And we get "safety features" to go along with it (where Assembler has no safety features at all). Where Smalltalk simply "does not understand message XXX" Asm returns garbage, or plain crashes. This is why, although I'm as good as they come at basic Von Neumann coding, I don't sneer at Smalltalk. One instance of a Smalltalk debugger coming up with "YYY doesn't understand XXX" could be worth 8 hours of assembler debugging. It's a tradeoff, and if we want to represent ourselves as real computer scientists, and real computing professionals, it behooves us to be able to explain in clear terms why one paradigm is better, where it is better, and the details of why it is better AT A GIVEN TASK. I'd never code for a GUI with assembler, nor use Smalltalk for solving systems of differential equations. We can get by without smalltalk if we must. If we try to do without Von Neumann, there isn't such a thing as a working computer. If we try to do without Turing Theory and practice, we are again without a working computer. If we try to do without object code, the machine will never understand us, and that means, basically, the Assembler, and we can't write working programs even if we have a working computer if we don't use that object code. We CAN live without C, or C++, or Smalltalk. I wouldn't like it a lot to do without them. The whole point is that I'm so far advanced on all levels that I can use any of them interchangably. Let's get it right, people. Object code (the assembler's output) is reality. Von Neumann is reality. Turing is reality. Procedural and OO are only TOOLS built on these basics. Machines work just fine without them. They don't work AT ALL without object code, assemblers, Von Neumann basics and Turing Basics. The rest is extremely convenient and extremely productive. But they're just the decorations on the icing on the cake. And if they disappeared tomorrow, we'd all live, and still get our work done -- just more slowly and with more frustration than before. > >The numerical number crunching problems are perfect problems that a von > >Neumann machine is designed for, so can be handled quite elegantly with > >procedural languages. They are well defined algorithms that take up a > >very reasonable number of lines of code. However we need Runge-Kutta in > >our real life even less than we need our calculator. I use Smalltalk > >extensively, but revert back to C or even assembler when I need > >procedural number crunching, and offer these as DLLs. On the other hand, > >a simple ORB is reasonably trivial in Smalltalk, but if you want to > >develop in any procedure oriented system, even in C++, it takes a lot of > >time and effort. > >A number of times in this thread, OO has been compared to "von Neumann >machines" as if they are opposing paradigms. This is confusing to >me--could someone explain it? My understanding of von Neumann >machines is that they execute one statement at a time, in order. Most >of the high-level languages I've seen do the same thing, whether or >not they're OO languages. It seems to me that if (as implied by >earlier posts in this thread) the "von Neumann" paradigm is the >problem, then the solution is something like Backus' FP or Prolog or >Haskell or dataflow--not OO, which seems to me to have nothing to do >with whether the von Neumann model is being followed or not. Am I >missing something? > > -- Adam ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-31 0:00 ` clovis @ 1996-12-31 0:00 ` Neville Black 1996-12-31 0:00 ` Tansel Ersavas ` (2 subsequent siblings) 3 siblings, 0 replies; 209+ messages in thread From: Neville Black @ 1996-12-31 0:00 UTC (permalink / raw) This is all mythology. The fundamental aspect of a von Neumann machine is to store program and data in the same memory. This was thought to be hot stuff for "self modifying programs", and also very clever way of fully utilizing memory (precious beyond imagining). The "opposite" of a von Neumann machine is the "Harvard Architecture" in which program and data memory are distinct. Example: the IBM 610 which used magnetic drum for data storage and paper tape for code (yes, the tape was automatically replicated for each iteration..). Given the large drop in memory costs, it is surprising that Harvard Archirectures have not seen a revival..... clovis@wartech.com wrote: > > In <5aa0eo$thd@krusty.irvine.com>, adam@irvine.com (Adam Beneschan) writes: > >In article <32C557F6.532C@rase.com> tansel@rase.com writes: > > You're quite right. Tansel is acting like quite a pretender on this one, and he > obviously doesn't know what either a Von Neumann machine is, or what a Turing > machine is. A Von Neumann "machine" is really a recommended architecture, > and really, there aren't many of them. They feature regular instruction sets, > with zero duplication of function, and all operations being orthogonal. The basic > feature of the Von Neumann machine is all classes of basic arithmetic operation, > and all classes of comparisions within the two basic numeric types. The "ideal" > Von Neumann machine supports natural numbers, integers, reals (actually, length > limited rational numbers), in which any operation -- add, subtract, multiply, divide > and compare -- are entirely separate. > > That is ALL we mean by a Von Neumann machine. If you delete ANY aspect of a > Von Neumann machine, you can't do basic computation. One is either missing > discrete whole numbers, or the ability to compute rational numbers and their > real number simulation, or the ability to tell if one number is the same size as, > or larger, than another number. ....<snip>..... ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-31 0:00 ` clovis 1996-12-31 0:00 ` Neville Black @ 1996-12-31 0:00 ` Tansel Ersavas 1997-01-01 0:00 ` Tom Bushell 1997-01-10 0:00 ` Bart Samwel 3 siblings, 0 replies; 209+ messages in thread From: Tansel Ersavas @ 1996-12-31 0:00 UTC (permalink / raw) clovis@wartech.com wrote: > > In <5aa0eo$thd@krusty.irvine.com>, adam@irvine.com (Adam Beneschan) writes: > >In article <32C557F6.532C@rase.com> tansel@rase.com writes: > > You're quite right. Tansel is acting like quite a pretender on this one, and he > obviously doesn't know what either a Von Neumann machine is, or what a Turing > machine is. A Von Neumann "machine" is really a recommended architecture, > and really, there aren't many of them. They feature regular instruction sets, > with zero duplication of function, and all operations being orthogonal. The basic > feature of the Von Neumann machine is all classes of basic arithmetic operation, > and all classes of comparisions within the two basic numeric types. The "ideal" > Von Neumann machine supports natural numbers, integers, reals (actually, length > limited rational numbers), in which any operation -- add, subtract, multiply, divide > and compare -- are entirely separate. I am preparing a Web page with references about the history of computing that includes pointers to von Neumann architecture and his devised machine, and the Turing machine, I'll make it available to everybody when it is ready. On the subject of von Neumann architectures and Turing machines, I wouldn't recommend that you to jump to conclusions before seeing the material that I said I would post. > The Von Neumann model, while not strictly followed in terms of orthogonality, is > inherent in every general purpose digital computing machine ever made, even > the Intel 80x86 family (which does it all, but which is not symmetrical or wholly > orthogonal; and the same is largely true of RISC, whose primary function is to > reduce transistor count). This is precisely my point. ... > In short, all digital computers are essentially just variances on Von Neumann and > Turing, both of whom were mathematicians interested in computing technology as > the notion of a code-based computation became available, that is, a computing > machine which was capable of responding to codes which could control execution > based on previous results. Can you point me to one popular CPU that uses a Turing machine as a main means of computation? Turing machines are conceptually very significant, especially for showing us that a regular grammar can be used to solve all practically solvable problems, however their architectural influence in modern computers is not comparable to the von Neumann architecture. Some people think or even inacurately quote that von Neumann architecture is a kind of a Turing machine. Although a Turing machine can be used to parse and interpret any von Neumann style stored program, the level of the grammars these two types of machines deal with are essentially different. A Turing machine deals with a regular grammar, whereas a von Neumann style stored program uses a context free grammar. To anybody interested in Alan Mathison Turing's Turing machines I recommend this excellent source: R. Herken, Berlin, FRG (Ed.) "The Universal Turing Machine, A Half-Century Survey" Springer-Verlag Vienna New York 1995. ... > None of this is really rocket science. And it's never ceased to amaze me how many > of the "hip" guys can't even define the basic terms. Nobody says it is. Again, I would urge you to wait till I say what I have to say about these subjects. ... Happy new year to all Tansel ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-31 0:00 ` clovis 1996-12-31 0:00 ` Neville Black 1996-12-31 0:00 ` Tansel Ersavas @ 1997-01-01 0:00 ` Tom Bushell 1997-01-10 0:00 ` Bart Samwel 3 siblings, 0 replies; 209+ messages in thread From: Tom Bushell @ 1997-01-01 0:00 UTC (permalink / raw) On 31 Dec 1996 06:54:51 GMT, clovis@wartech.com wrote: >You're quite right. Tansel is acting like quite a pretender on this one, and he >obviously doesn't know what either a Von Neumann machine is, or what a Turing >machine is. Let's wait until he gets his article together before slagging him, eh? Although he may be guilty of a bit of hyperbole, I have a hunch he may be on to something - time will tell. >A Von Neumann "machine" is really a recommended architecture, >and really, there aren't many of them. They feature regular instruction sets, >with zero duplication of function, and all operations being orthogonal. As other postings have said, my understanding was that shared program and data memory is the defining characteristic. >None of this is really rocket science. And it's never ceased to amaze me how many >of the "hip" guys can't even define the basic terms. Seems to be a problem with the field in general, not just a few hip guys. Terminology and concepts havn't stabilized. Witness your own statement about the "true" meaning of von Neumann architecture, extended discussions about what OO "really" means, and so on. >Assembler will ALWAYS be the most efficient language. The more you abstract the >problem, the more you "generalize" the solution to a given problem, the more you >necessarily give up in efficiency. Agreed, if you define "efficency" as "doing the most computation with the fewest instructions". >C takes a minimal 3x hit on integer arithmetic, >10x on more complex stuff; and OO, because of the overhead interpreting where >to send things, is 10x on top of that. Saying that there is a 10x hit for using OO is a pretty sweeping statement. May be correct for a Smalltalk message send, which is late bound. But an early bound C++ call just requires one more indirect jump through the vtable, so the performance hit is more like 3 _percent_ according to what I've read, which is trivial. >I personally use all three in Smalltalk applications which involve a variety of >disciplines. Smalltalk handles the GUI, but engines in C and ASM are also required >in some cases. Any realtime requirements point to ASM, and any number crunching >points to C most of the time (Assembler if the computation must be made in >realtime, and be interruptable in mid-stream). I agree 100%. The huge reduction in development time for the 90% of the system that doesn't need speed more than repays the extra effort and complexity of a multi language solution. >Smalltalk itself is not entirely Smalltalk. It contains both procedural (often C), and >frequently ASM routines at the kernel since no general purpose machine ever >built comprehends objects -- all the underlying hardware knows about is basic >arithmetic, compares, and jumps/branches based on flags settings. As an aside, many Forth compilers are written in Forth. The Forth stack based virtual machine is coded using the Forth postfix assembler for the target machine. The result is a programming system that is completely able to regenerate itself (wasn't that one of the definitions of a von Neumann machine?) >ASM is REALITY. > >>In this thread someone said assembler was "real" and higher level >>languages were abstractions above that. I always thought voltage >>states/levels were real and that assembler was an abstraction of voltage >>states/levels. > >Elliott Have to agree with Elliot on this one - assembler is just a textual abstraction for the binary numbers that are computer instructions. And the binary numbers are abstractions for voltages, and the voltages are...it's elephants all the way down. If you are saying assembler is the lowest abstraction we can program in under normal circumstances, I agree. (Although I wrote a Forth in hex on a KIM-1, back in the bad old days.) >It's a tradeoff, and if we want to represent ourselves as real computer scientists, >and real computing professionals, it behooves us to be able to explain in clear >terms why one paradigm is better, where it is better, and the details of why it is >better AT A GIVEN TASK. I agree, but IMO the field has a lot more maturing to do before this will happen. >We can get by without smalltalk if we must. If we try to do without Von Neumann, >there isn't such a thing as a working computer. True for current computers, and one of the reasons I'm a little skeptical about what I _think_ Tansel is saying - the implication that we need a whole new hardware architecture before we can benefit from OO. But he claims von Neumann himself was dissatisfied, and if there is a much better architecture for CPUs, we can assume it will be built and commercialized - eventually. -Tom ---------------------------------------------------------- Tom Bushell * Custom Software Development Telekinetics * Process Improvement Consulting 2653 Highway 202 * Technical Writing RR#1, Elmsdale, NS B0N 1M0 (902)632-2772 Email: tbushell@fox.nstn.ns.ca ---------------------------------------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-31 0:00 ` clovis ` (2 preceding siblings ...) 1997-01-01 0:00 ` Tom Bushell @ 1997-01-10 0:00 ` Bart Samwel 1997-01-10 0:00 ` Robert Dewar ` (2 more replies) 3 siblings, 3 replies; 209+ messages in thread From: Bart Samwel @ 1997-01-10 0:00 UTC (permalink / raw) > Assembler will ALWAYS be the most efficient language. The more you > abstract the problem, the more you "generalize" the solution to a > given problem, the more you necessarily give up in efficiency. C > takes a minimal 3x hit on integer arithmetic, 10x on more complex > stuff; and OO, because of the overhead interpreting where > to send things, is 10x on top of that. IMO this number is only a valid approximation for Smalltalk and other dynamically typed OO languages. Statically typed languages like C++ (hybrid, but supporting OO) and Eiffel (pure OO) achieve a much lower impact on performance than 10x. I won't give any numbers because I don't have them, but I know most number-crunching usually runs at very acceptable speed in these languages; a bit, but not much slower than C. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1997-01-10 0:00 ` Bart Samwel @ 1997-01-10 0:00 ` Robert Dewar 1997-01-10 0:00 ` Assembler most efficient??? (was Re: What is wrong with OO ?) Richie Bielak 1997-01-15 0:00 ` What is wrong with OO ? Richard Kenner 1997-01-11 0:00 ` Randy A. Ynchausti 1997-01-12 0:00 ` Piercarlo Grandi 2 siblings, 2 replies; 209+ messages in thread From: Robert Dewar @ 1997-01-10 0:00 UTC (permalink / raw) "> Assembler will ALWAYS be the most efficient language. The more you > abstract the problem, the more you "generalize" the solution to a > given problem, the more you necessarily give up in efficiency. C > takes a minimal 3x hit on integer arithmetic, 10x on more complex > stuff; and OO, because of the overhead interpreting where > to send things, is 10x on top of that." First, it is only true that assembler is most efficient if written by a competent programmer. Since well over 90% of the assembly language that I have seen is highly incompetent, this is an important criterion. In particular, I often see the phenomenon of super ferocious, super tight coding of junk algorithms, and the result can easily be beaten by a decent algorithm written in any language. As for the 3x hit on integer arithmetic, this seems complete nonsense. Almost any decent C compiler these days should be able to handle near optimal code generation for simple integer arithmetic. Finally, writing assembly these days is getting more and more difficult. Doing your own global scheduling as well as a good optimizing compiler can do it is a very big challenge on modern superscalar machines. Yes, it is true that you can often pick up a considerable advantage by choosing clever machine dependent data structures, and taking advantage of processor flags etc, but a modern optimizing compiler will almost certainly be able to do a better job than most assembly language programmers of global register allocation and scheduling. Indeed the most efficient way to write assembly language might well be to use the machine insertions available in many compilers (including GCC and GNAT) that allow you to write register independent code, and then let the optimizer circuits of the compiler do register allocation and instruction scheduling on the instructions you write. I should say that I certainly agree that it is *possible* to achieve remarkable time and space efficiency in assembly. My DASC program is a nice example. It is a complete scanner and syntax recognizer for Ada 83, that gives a pretty nice first error message on syntactically invalid programs. It runs well over a million lines a minute on a 25MHz 386 (I have not run it on more recent machine -- actually let me do it, easy enough in another window here --- OK, a source file of 1.04 million lines of Ada (actually 100 concatenated copies of the GNAT unit sem_ch3.adb) took 14 seconds on my 133 MHs Pentium notebook, so well over four million lines a minute on a machine with a very slow disk). The size is also startling, it is a COM file less than 15K bytes long, and that size INCLUDES 2K bytes of help text, and all the error message text. So this kind of ancedotal evidence does indeed suggest that it is possible some times to get startling performance from hand coded programs, but you have to be VERY careful about extending this kind of data. Whether this approach is practical in other situations depends on all sorts of factors. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Assembler most efficient??? (was Re: What is wrong with OO ?) 1997-01-10 0:00 ` Robert Dewar @ 1997-01-10 0:00 ` Richie Bielak 1997-01-11 0:00 ` Robert Dewar 1997-01-15 0:00 ` What is wrong with OO ? Richard Kenner 1 sibling, 1 reply; 209+ messages in thread From: Richie Bielak @ 1997-01-10 0:00 UTC (permalink / raw) Robert Dewar wrote: > > "> Assembler will ALWAYS be the most efficient language. The more you > > abstract the problem, the more you "generalize" the solution to a > > given problem, the more you necessarily give up in efficiency. C > > takes a minimal 3x hit on integer arithmetic, 10x on more complex > > stuff; and OO, because of the overhead interpreting where > > to send things, is 10x on top of that." > > First, it is only true that assembler is most efficient if written by > a competent programmer. Since well over 90% of the assembly language > that I have seen is highly incompetent, this is an important criterion. > In particular, I often see the phenomenon of super ferocious, super > tight coding of junk algorithms, and the result can easily be beaten > by a decent algorithm written in any language. > [...] I agree with Robert 100%. In John Bentley's book "Programming Pearls" there is a neat example of this. He shows a program written in BASIC on a TRS-80 and a program written in FORTRAN on a Cray. The BASIC program used a linear algorithm and the FORTRAN program used a quadratic algorithm to solve the same problem. When the size of problem got to about 10,000 the TRS-80 beat the Cray. Part of the difficulty compilers have with generating good code is that CPUs are being designed by people who coded in assembler and never had to write a compiler. Niklaus Wirth's Lilith computer was an example of a CPU designed with a compiler in mind. He has written a bunch of articles comparing the performance of his Modula-2 compilers on Lilith and the MC68000 (see past issues of CACM - about 10 years ago?). The Lilith outperformed most computers in its class and it didn't have an assembler. Compilers can be much smarter than programmers in generating machine code, especially on some of these pipe-lined RISC CPUs. ...richie * richieb@netlabs.net - at home | Richie Bielak * * richieb@calfp.com - at work | * * Home page: http://www.netlabs.net/hp/richieb * * "Fight software piracy, use free software!" (me) * ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Assembler most efficient??? (was Re: What is wrong with OO ?) 1997-01-10 0:00 ` Assembler most efficient??? (was Re: What is wrong with OO ?) Richie Bielak @ 1997-01-11 0:00 ` Robert Dewar 1997-01-11 0:00 ` James S. Rogers ` (2 more replies) 0 siblings, 3 replies; 209+ messages in thread From: Robert Dewar @ 1997-01-11 0:00 UTC (permalink / raw) Richie said "Part of the difficulty compilers have with generating good code is that CPUs are being designed by people who coded in assembler and never had to write a compiler." Do you really have evidence of this? What machines are you talking about? I know quite a bit about the design of the common processor chips around, and I really cannot think of one case where the scenario you present above rings true. On the contrary, for example, the design of the MIPS chip was done with input from compiler considerations all along the way. In some sense the whole business of pipelined RISC architecture is intimately wound up with compiler considerations. I can think of some examples in the past where instruction sets have been designed with far too much naive input from high level language and compiler considerations, but none of them seem to have survived into the modern RISC era. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Assembler most efficient??? (was Re: What is wrong with OO ?) 1997-01-11 0:00 ` Robert Dewar @ 1997-01-11 0:00 ` James S. Rogers 1997-01-11 0:00 ` Larry Kilgallen 1997-01-13 0:00 ` Richie Bielak 2 siblings, 0 replies; 209+ messages in thread From: James S. Rogers @ 1997-01-11 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Richie said > > "Part of the difficulty compilers have with generating good code > is that CPUs are being designed by people who coded in assembler > and never had to write a compiler." > > On the contrary, for example, the design of the MIPS chip was > done with input from compiler considerations all along the way. In some > sense the whole business of pipelined RISC architecture is intimately > wound up with compiler considerations. Another example is the HP-PA-RISC chip. Extensive work was done profiling the instructions from many languages including COBOL, Pascal and C. In fact, this effort is what the "PA" in the name of the architecture stands for. "PA" is Precision Architecture. It refers to the fact that the architecture is built upon the very extensive and precise measurements HP made to determine which architectural features were most important to modern computing. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Assembler most efficient??? (was Re: What is wrong with OO ?) 1997-01-11 0:00 ` Robert Dewar 1997-01-11 0:00 ` James S. Rogers @ 1997-01-11 0:00 ` Larry Kilgallen 1997-01-12 0:00 ` Joel VanLaven 1997-01-13 0:00 ` Richie Bielak 2 siblings, 1 reply; 209+ messages in thread From: Larry Kilgallen @ 1997-01-11 0:00 UTC (permalink / raw) In article <dewar.852989882@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes: > Do you really have evidence of this? What machines are you talking about? > I know quite a bit about the design of the common processor chips around, > and I really cannot think of one case where the scenario you present above > rings true. On the contrary, for example, the design of the MIPS chip was > done with input from compiler considerations all along the way. In some > sense the whole business of pipelined RISC architecture is intimately > wound up with compiler considerations. Compared to the operating system groups, the DEC compiler groups had as much if not more input to the designers of the Alpha chips. Larry Kilgallen ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Assembler most efficient??? (was Re: What is wrong with OO ?) 1997-01-11 0:00 ` Larry Kilgallen @ 1997-01-12 0:00 ` Joel VanLaven 0 siblings, 0 replies; 209+ messages in thread From: Joel VanLaven @ 1997-01-12 0:00 UTC (permalink / raw) Just to add my little bit of trivia, I read once about the CRISP architecture designed by ATT (I think) that stood for the C Rational Instruction Set Processor, that was designed almost solely to be better for programs written in C. I think they decided that optimizing the stack was very important for the C programs they were working with and so designed a special "stack cache." Actually, much of UNIX is written in C anyway, so optimizing for the compiler IS optimizing for the OS, at least indirectly. Larry Kilgallen (kilgallen@eisner.decus.org) wrote: : In article <dewar.852989882@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes: : > Do you really have evidence of this? What machines are you talking about? : > I know quite a bit about the design of the common processor chips around, : > and I really cannot think of one case where the scenario you present above : > rings true. On the contrary, for example, the design of the MIPS chip was : > done with input from compiler considerations all along the way. In some : > sense the whole business of pipelined RISC architecture is intimately : > wound up with compiler considerations. : Compared to the operating system groups, the DEC compiler groups had : as much if not more input to the designers of the Alpha chips. : Larry Kilgallen -- -- Joel VanLaven ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Assembler most efficient??? (was Re: What is wrong with OO ?) 1997-01-11 0:00 ` Robert Dewar 1997-01-11 0:00 ` James S. Rogers 1997-01-11 0:00 ` Larry Kilgallen @ 1997-01-13 0:00 ` Richie Bielak 2 siblings, 0 replies; 209+ messages in thread From: Richie Bielak @ 1997-01-13 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Richie said > > "Part of the difficulty compilers have with generating good code > is that CPUs are being designed by people who coded in assembler > and never had to write a compiler." > > Do you really have evidence of this? [...] > > I can think of some examples in the past where instruction sets have been > designed with far too much naive input from high level language and > compiler considerations, but none of them seem to have survived into the > modern RISC era. My comments were mostly based on what I read about Wirth's work on Modula-2, Oberon, Lilith etc., which I realize I somewhat outdated. I know that many of the RISC processors are designed more with the compiler in mind. My favorite example of a compiler going wrong with the instruction set provided, was DEC's old COBOL compiler on the VAX. As you must know, VAX provided many instructions specifically aimed at making code generation easier (eg. INDEX, LOCC, SCAN etc). In one case the COBOL compiler generated exponential algorithm for a linear problem using those fancy instructions. Finally, to get back to the orignal topic, I think that on the modern RISC processors it is more likely for a compiler to generate faster code than what could be hand written in assembler. ...richie -- * richieb@netlabs.net - at home | Richie Bielak * * richieb@calfp.com - at work | * * Home page: http://www.netlabs.net/hp/richieb * * "Fight software piracy, use free software!" (me) * ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1997-01-10 0:00 ` Robert Dewar 1997-01-10 0:00 ` Assembler most efficient??? (was Re: What is wrong with OO ?) Richie Bielak @ 1997-01-15 0:00 ` Richard Kenner 1 sibling, 0 replies; 209+ messages in thread From: Richard Kenner @ 1997-01-15 0:00 UTC (permalink / raw) In article <dewar.852912391@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes: >Indeed the most efficient way to write assembly language might well be to >use the machine insertions available in many compilers (including GCC >and GNAT) that allow you to write register independent code, and then let >the optimizer circuits of the compiler do register allocation and >instruction scheduling on the instructions you write. This is actually not as straightforward as it might seem since there needs to be a way of describing the scheduling attributes of the instructions you write and such a mechanism would be tricky (GCC and GNAT don't support it, for example). However, some assemblers will do instruction scheduling. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1997-01-10 0:00 ` Bart Samwel 1997-01-10 0:00 ` Robert Dewar @ 1997-01-11 0:00 ` Randy A. Ynchausti 1997-01-12 0:00 ` Piercarlo Grandi 2 siblings, 0 replies; 209+ messages in thread From: Randy A. Ynchausti @ 1997-01-11 0:00 UTC (permalink / raw) Bart Samwel wrote: > > > Assembler will ALWAYS be the most efficient language. The more you > > abstract the problem, the more you "generalize" the solution to a > > given problem, the more you necessarily give up in efficiency. C > > takes a minimal 3x hit on integer arithmetic, 10x on more complex > > stuff; and OO, because of the overhead interpreting where > > to send things, is 10x on top of that. > > IMO this number is only a valid approximation for Smalltalk and other > dynamically typed OO languages. Statically typed languages like C++ > (hybrid, but supporting OO) and Eiffel (pure OO) achieve a much lower > impact on performance than 10x. I won't give any numbers because I > don't have them, but I know most number-crunching usually runs at > very acceptable speed in these languages; a bit, but not much slower > than C. So what's your point. Computer speeds are increasing rapidly. The cost is decreasing rapidly. I am willing to trade your perceived efficiency of Assembler for the ease and enjoyment of creating applications for families of micro-processors in a high-level language. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1997-01-10 0:00 ` Bart Samwel 1997-01-10 0:00 ` Robert Dewar 1997-01-11 0:00 ` Randy A. Ynchausti @ 1997-01-12 0:00 ` Piercarlo Grandi 2 siblings, 0 replies; 209+ messages in thread From: Piercarlo Grandi @ 1997-01-12 0:00 UTC (permalink / raw) >>> "bsamwel" == Bart Samwel <bsamwel@wi.leidenuniv.nl> writes: >> Assembler will ALWAYS be the most efficient language. The more you >> abstract the problem, the more you "generalize" the solution to a >> given problem, the more you necessarily give up in efficiency. C >> takes a minimal 3x hit on integer arithmetic, 10x on more complex >> stuff; and OO, because of the overhead interpreting where >> to send things, is 10x on top of that. bsamwel> IMO this number is only a valid approximation for Smalltalk and bsamwel> other dynamically typed OO languages. Statically typed bsamwel> languages like C++ (hybrid, but supporting OO) and Eiffel (pure bsamwel> OO) achieve a much lower impact on performance than 10x. I bsamwel> won't give any numbers because I don't have them, but I know bsamwel> most number-crunching usually runs at very acceptable speed in bsamwel> these languages; a bit, but not much slower than C. By using clever implementation tricks (such as dynamic inlining!) many dynamically typed languages can be just as fast as. Self is claimed to run at just half the speed of C, and two to three times the speed of most compiled ``Smalltalk'' implementations (to the point that the Smalltalk-80 implementation written in Self by Mario Wolzcko usually runs twice as fast as native commercial ``Smalltalk'' implementations). Then some Lisp implementations are amazingly fast as well; CMU CL with the Python compiler can be quite impressive. The NeXT and GNU Objective-C iplementations have been carefully tuned, and result in programs usually about as fast as those written in C; for dynamic resolution is quite fast and is not the dominant overhead. ``Eiffel'' compilers also offer default dynamic resolution which is well optimized. In many cases high performance is also achieved by analyzing the program and inferring where dynamic overload resolution is actually not needed... ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-27 0:00 ` Tore Lund 1996-12-28 0:00 ` Tansel Ersavas @ 1996-12-29 0:00 ` clovis 1996-12-31 0:00 ` Tom Bushell 1996-12-31 0:00 ` Jon S Anthony ` (3 subsequent siblings) 5 siblings, 1 reply; 209+ messages in thread From: clovis @ 1996-12-29 0:00 UTC (permalink / raw) In <32C43AC8.24E2@sn.no>, Tore Lund <tl001@sn.no> writes: >Yes, why? The most important reason is that most programmers don't know >assembler or bother to learn it well enough to write decent code in it. Most "programmers" don't bother to learn ANYTHING well enough to write well in it. With 20 years of C under my belt, I'm still asked to write snippets when I go see a consulting client, because most of those who have been doing it for a while write really atrocious C. The same is true of assembly language -- people will ask to see a snippet to see if one has just done it, or really knows what is going on. >You don't agree, of course, but the point here is is that the 64k >program written in assembler will still be < 100k when written in C. >There is no need for "code bloat" on the scale of 8 megs for >maintainability purposes. Well, not under 100k. I typically find that, because of the need for "generality" in C, 64k of assembler -- by someone who is really hot -- turns into about 256k of C. About 4 to 1 -- simply because the C code has to be so generalized, and the assembler can really tune-down by being highly algorithm specific. The more general the assembler, the less the difference, of course, until the sizes become truly equivalent. The real deal with Assembly Language is tuning that code so that one exploits the instruction set, executes many fewer instructions etc, which is mostly a matter of concern in realtime, or OS kernels, or diagnostics, where one has to sort of do it all oneself. Paradoxically -- and this really is a paradox -- Smalltalk seems to be smaller and faster both when dealing with a GUI. Minimum size on my VA applications, the really small little demo things, is about 1.8 megs. But it doesn't grow much unless one is throwing the whole kitchen sink at things. And the debugger etc etc and the whole runtime development environment only occupies about 15 megs on disk including a de facto text processing system, all sorts of graphical widgets, and some very complex connection and self-maintainance code. Compare this to, say, the Watcom C++ compiler which, to support all environments and stuff, occupies 380 megs on a secondary drive. I get Windows 3.1, Windows 95, Windows NT and OS/2 for about 35 megs under VisualAge -- and more and better Windows and OS/2 than I'd get under any other system. And, generally, I seem not to have any performance hit (perhaps because I'm clever enough not to execute smalltalk code every time a variable changes). OO can be wonderfully effective. I can't figure out what they're doing in Word that takes 8 megs. And herein is the danger of the Ultimate Procedural Model (getting back to OO paradigms). In Procedural, one builds a procedure for each action. Each procedure is separate, and shares nothing with everything else. Voila, an 8 meg "word processor" which could probably be done in half that with OO, and probably run more quickly besides. This is why code re-use is so important in a design. Generality saves space, and very often, a good deal of time as well. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-29 0:00 ` clovis @ 1996-12-31 0:00 ` Tom Bushell 1996-12-31 0:00 ` clovis 1997-01-10 0:00 ` Bart Samwel 0 siblings, 2 replies; 209+ messages in thread From: Tom Bushell @ 1996-12-31 0:00 UTC (permalink / raw) On 29 Dec 1996 22:09:28 GMT, clovis@wartech.com wrote: >Paradoxically -- and this really is a paradox -- Smalltalk seems to be smaller and >faster both when dealing with a GUI. Minimum size on my VA applications, the really >small little demo things, is about 1.8 megs. But it doesn't grow much unless one is >throwing the whole kitchen sink at things. And the debugger etc etc and the whole >runtime development environment only occupies about 15 megs on disk including >a de facto text processing system, all sorts of graphical widgets, and some very >complex connection and self-maintainance code. I have noticed this also applies to Visual BASIC and Forth. These languages all use a technique that is often poo pooed by C/C++ junkies obsessed with wringing every cycle out of the CPU - they compile to a virtual machine, which is then interpreted. These runtimes tend to be very compact compared to the native code produced by conventional compilers. Of course, the execution time is slower, but this normally is only an issue for about 10% or less of the code in a typical program. This 10% can be written in C or assembler, but this is rarely necessary. I also suspect that the bloated executables often execute more slowly than they would if interpreted, because they spend so much time being swapped in an out of virtual memory. -Tom ---------------------------------------------------------- Tom Bushell * Custom Software Development Telekinetics * Process Improvement Consulting 2653 Highway 202 * Technical Writing RR#1, Elmsdale, NS B0N 1M0 (902)632-2772 Email: tbushell@fox.nstn.ns.ca ---------------------------------------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-31 0:00 ` Tom Bushell @ 1996-12-31 0:00 ` clovis 1997-01-10 0:00 ` Bart Samwel 1 sibling, 0 replies; 209+ messages in thread From: clovis @ 1996-12-31 0:00 UTC (permalink / raw) In <32c72272.204443082@news.nstn.ca>, tbushell@fox.nstn.ns.ca (Tom Bushell) writes: >On 29 Dec 1996 22:09:28 GMT, clovis@wartech.com wrote: > >>Paradoxically -- and this really is a paradox -- Smalltalk seems to be smaller and >>faster both when dealing with a GUI. Minimum size on my VA applications, the really >>small little demo things, is about 1.8 megs. But it doesn't grow much unless one is >>throwing the whole kitchen sink at things. And the debugger etc etc and the whole >>runtime development environment only occupies about 15 megs on disk including >>a de facto text processing system, all sorts of graphical widgets, and some very >>complex connection and self-maintainance code. > >I have noticed this also applies to Visual BASIC and Forth. These >languages all use a technique that is often poo pooed by C/C++ junkies >obsessed with wringing every cycle out of the CPU - they compile to a >virtual machine, which is then interpreted. These runtimes tend to be >very compact compared to the native code produced by conventional >compilers. Of course, the execution time is slower, but this normally >is only an issue for about 10% or less of the code in a typical >program. This 10% can be written in C or assembler, but this is >rarely necessary. It depends on the application. A proper architect breaks the problems into rational pieces, and uses the appropriate paradigm on each. An example may help. I am presently writing a simulator which models the flight of ballistic objects in 4 space, where the 4-space computations are second order differential equations. The simulator is not written all in Smalltalk. Chunks which are bad for Smalltalk are done in C or Assembler. If I had to do realtime, there would be an Assembler dispatcher controlling the system which would itself be hardware-driven. >I also suspect that the bloated executables often execute more slowly >than they would if interpreted, because they spend so much time being >swapped in an out of virtual memory. I entirely concur with this sentiment. If you gots to swap, a VM works better and faster. Disk access is one of the major IO dogs of the system. Fairly cheap chips are running 10,000x faster than a disk. If any significant swapping occurs, one can kiss performance goodbye. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-31 0:00 ` Tom Bushell 1996-12-31 0:00 ` clovis @ 1997-01-10 0:00 ` Bart Samwel 1 sibling, 0 replies; 209+ messages in thread From: Bart Samwel @ 1997-01-10 0:00 UTC (permalink / raw) Tom Bushell wrote: > I have noticed this also applies to Visual BASIC and Forth. These > languages all use a technique that is often poo pooed by C/C++ junkies > obsessed with wringing every cycle out of the CPU - they compile to a > virtual machine, which is then interpreted. These runtimes tend to be > very compact compared to the native code produced by conventional > compilers. Of course, the execution time is slower, but this normally > is only an issue for about 10% or less of the code in a typical > program. This 10% can be written in C or assembler, but this is > rarely necessary. Ah! It is also useful to notice the incremental compilation available in some Eiffel compilers (Visual Eiffel from SiG and ISE's Eiffel 4 have this feature, but there might be other compilers that have it too). These compilers compile to interpreted p-code only the parts in the program that have changed, so that other truly compiled parts do execute at full speed, only the changed bits are slower. This saves lots of compilation time, but retains most of the speed if you compile everything to native code every once in a while. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-27 0:00 ` Tore Lund 1996-12-28 0:00 ` Tansel Ersavas 1996-12-29 0:00 ` clovis @ 1996-12-31 0:00 ` Jon S Anthony 1997-01-01 0:00 ` Jon S Anthony ` (2 subsequent siblings) 5 siblings, 0 replies; 209+ messages in thread From: Jon S Anthony @ 1996-12-31 0:00 UTC (permalink / raw) In article <5aa0eo$thd@krusty.irvine.com> adam@irvine.com (Adam Beneschan) writes: > machines is that they execute one statement at a time, in order. Most > of the high-level languages I've seen do the same thing, whether or > not they're OO languages. Right. > It seems to me that if (as implied by earlier posts in this thread) > the "von Neumann" paradigm is the problem, then the solution is > something like Backus' FP or Prolog or Haskell or dataflow--not OO, Right. > which seems to me to have nothing to do with whether the von Neumann > model is being followed or not. Am I missing something? No, I think you have it surrounded. Procedural/"Von Neumann" is orthogonal to OO. As is declaritive (which is the correct counterpoint to procedural). /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-27 0:00 ` Tore Lund ` (2 preceding siblings ...) 1996-12-31 0:00 ` Jon S Anthony @ 1997-01-01 0:00 ` Jon S Anthony 1997-01-12 0:00 ` Corey Minyard 1997-01-13 0:00 ` Nick Thurn 5 siblings, 0 replies; 209+ messages in thread From: Jon S Anthony @ 1997-01-01 0:00 UTC (permalink / raw) In article <rmartin-3112960919160001@pool11-019.wwa.com> rmartin@oma.com (Robert C. Martin) writes: > In article <5aa0eo$thd@krusty.irvine.com>, adam@irvine.com (Adam > Beneschan) wrote: > > > A number of times in this thread, OO has been compared to "von Neumann > > machines" as if they are opposing paradigms. This is confusing to > > me--could someone explain it? My understanding of von Neumann > > machines is that they execute one statement at a time, in order. Most > > of the high-level languages I've seen do the same thing, whether or > > not they're OO languages. It seems to me that if (as implied by > > earlier posts in this thread) the "von Neumann" paradigm is the > > problem, then the solution is something like Backus' FP or Prolog or > > Haskell or dataflow--not OO, which seems to me to have nothing to do > > with whether the von Neumann model is being followed or not. Am I > > missing something? > > Von Neumann invented the notion that the computer program could be > stored in the memory of the computer (rather than wired in through a > patch panel). At least that is my recollection. I agree. But for some reason, in this thread at least, people seem to be using it as some sort of synonym for "procedural". > A "Von Neumann Machine" is something different altogether. It is a > machine that knows how to make copies of itself. Humans are Von > Neumann machines. This too seems to be the most appropriate use of the term in various bits of the literature... /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-27 0:00 ` Tore Lund ` (3 preceding siblings ...) 1997-01-01 0:00 ` Jon S Anthony @ 1997-01-12 0:00 ` Corey Minyard 1997-01-14 0:00 ` Vos nom et pr�nom 1997-01-13 0:00 ` Nick Thurn 5 siblings, 1 reply; 209+ messages in thread From: Corey Minyard @ 1997-01-12 0:00 UTC (permalink / raw) > Assembler will ALWAYS be the most efficient language. The more you > abstract the problem, the more you "generalize" the solution to a > given problem, the more you necessarily give up in efficiency. C > takes a minimal 3x hit on integer arithmetic, 10x on more complex > stuff; and OO, because of the overhead interpreting where > to send things, is 10x on top of that. These numbers are completely bogus for modern compilers. There have been documented cases where compiled code has actually produced faster code than an experienced human writing assembler. See the ammunition section at http://www.adahome.com. I would expect the numbers for a compiler would improve with a complex system. Two factors contribute to this. Modern optimizing compilers can do global optimization far beyond what a human could ever do. This is why I expect compilers to do better than humans for complex systems. The other is the state of modern processors. In the old days, processors were very simple and so were compilers. Now, processors have big pipelines, tons of registers, lots of little tricky speed optimizations, lots of condition code registers, etc. I have done pipeline and register optimization in assembly language for small routines (50-200 instructions for TMS320C40); it is enough to make your head hurt. Although the routines where better than could be produced by a compiler (they HAD to be fast), they took an extremely long time to write. You can spend all day optimizing and debugging 100 instructions. With VLIW coming, humans optimization anything that is not dirt simple is just simply not feasible. A compiler will always do a better job. And the OO hit is not 10x. I have seen numbers on that for C and C++; although I don't remember them exactly they were in the 20-30% range. -- Corey Minyard Internet: minyard@acm.org Work: minyard@nortel.ca UUCP: minyard@wf-rch.cirr.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1997-01-12 0:00 ` Corey Minyard @ 1997-01-14 0:00 ` Vos nom et pr�nom 0 siblings, 0 replies; 209+ messages in thread From: Vos nom et pr�nom @ 1997-01-14 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1306 bytes --] Corey Minyard <minyard@acm.org> a �crit dans l'article <m26812ld16.fsf@acm.org>... > > Assembler will ALWAYS be the most efficient language. The more you > > abstract the problem, the more you "generalize" the solution to a > > given problem, the more you necessarily give up in efficiency. C > > takes a minimal 3x hit on integer arithmetic, 10x on more complex > > stuff; and OO, because of the overhead interpreting where > > to send things, is 10x on top of that. I agree. Assembler is the fastest when (and because you can in assembler) you wrote specialized routines. For more generalized routines, compilers are becoming quite as good optimizers to perform the job (closely) like any assembly programmer. But in most systems, time is spent in OS (or waiting I/O). Most applications are databases. Assembler for these ones is irrelevant. Assembler is useful for complex calculus. But only critical parts (the most often used) of the code should be written in assembler because finding more efficient algorythms gives generally far more improvements that just rewriting the C++ code in assembler. Because C++ is HLL, we can try many algorythms easier and quicker than we'd do in assembly. -- Chris "The nail pulling up calls the hammer" zen proverb ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-27 0:00 ` Tore Lund ` (4 preceding siblings ...) 1997-01-12 0:00 ` Corey Minyard @ 1997-01-13 0:00 ` Nick Thurn 5 siblings, 0 replies; 209+ messages in thread From: Nick Thurn @ 1997-01-13 0:00 UTC (permalink / raw) Corey Minyard wrote: > > And the OO hit is not 10x. I have seen numbers on that for C and C++; > although I don't remember them exactly they were in the 20-30% range. > My experience with OO suggests there can be a 10x hit for *bad* design. OO code (C++) can be faster than procedural code because it is possible to use more complex algorithms (because you can hide the complexity). A *good* OO system *should* be smaller, faster and easier to understand than the procedural equivalent. The sad fact that many use OO as an excuse to wallow in complexity is another issue. cheers Nick (my opinions only) > -- > Corey Minyard Internet: minyard@acm.org > Work: minyard@nortel.ca UUCP: minyard@wf-rch.cirr.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-27 0:00 ` Jacqueline U. Robertson 1996-12-27 0:00 ` Tore Lund @ 1996-12-28 0:00 ` clovis 1996-12-30 0:00 ` John (Max) Skaller 1997-01-03 0:00 ` markj 1 sibling, 2 replies; 209+ messages in thread From: clovis @ 1996-12-28 0:00 UTC (permalink / raw) In <5a0niaINNlda@topdog.cs.umbc.edu>, jur@cs.umbc.edu (Jacqueline U. Robertson) writes: Big snip, to save bandwidth >Well, I was with you to some extent until you got here. Code bloat is a >simple trade-off for increased maintainability and extensibility. Quite >simply, it's easier to maintain and extend a decently written application >in high level code than it is to maintain and extend a decently written >application in assembler. What you are saying is a damnable lie, but let's hear your reason for thinking something as inaccurate as this. > Why ? Because the high level language applied is >easier to read, particularly for follow on developers who were not involved >in the original work. Would someone PLEASE and QUICKLY hang those who insist that code is "self-documenting?" Bad algorithms can be written in anything, and so can "cute" an impenetrable code -- AND hirearchies. So you have entirely the wrong answer here. Bad hirearchies are even MORE impenetrable than spaghetti code. >The trade-off is that the assembly level application was more compact (both in disk space and in memory usage) - but harder to extend >and modify. There's a reason that assembly level development is limited >to small areas (such as in the limited resource milieu of deep space probes) - >the trade off in favor of high level languages has generally been worth it, >as increased disk space and increased amounts of RAM are economically cheaper >than the 'more efficient' assembler writing. This is also wrong. The reason that "paradigms" proliferate is obvious; people, and managers in particular, are trying to get something for nothing. Compared to procedural languages, it takes 3 lines of assembler to equal one line of, say, PASCAL stuff. And it generally takes 5 lines of PASCAL to equal a line of Smalltalk in a properly constructed hirearchy. Any operation one needs to do should not be a series of lines, but a single method, and a single message sent to the instance. There are exceptions, but with the compactness come other problems. >I'd guess that over time (and in this case I'm guessing a fairly long >interval), machine generated applications will end up being cheaper than hand >written ones for much the same reason. Assuming that we can afford the machines that generate these applications, and the amount of RAM required to run them. Microsoft WORD is not as reliable, in my experience, as WordStar. And it's not a fraction as friendly. Purportedly it does more, but I think that's only purportedly. The more code paths and code there is, the more there is to go wrong. This is the same, simple principle as Consumer Reports has been telling people about for years -- the more buttons, the sooner it will break down, and the more often it will require repair after it breaks. If you're just blending Mai Tais, no big deal. If on the other hand you lose a file you've been working on all day, not so good. >James A. Robertson >email: jamesr@parcplace.com >phone: 410 952-0471 > ><note that I am posting through my wife's account. I don't claim to speak for >her> The problem remains one of having better programmers rather than better languages. I've done superb work in assembler, and all other paradigms, and I've also hacked out really ugly stuff in Smalltalk. If you design thoroughly, and document thoroughly, it turns out pretty well, if one understands the problem one is trying to solve at all. If you don't, it's a mess, and the particular language, paradigm etc is pointless. OO is NOT a panacea. It is more useful than not ONLY if it is used properly. And that remains a function of a good computer scientist, properly pursuing the trade, eh? Think about it and get back to me. Regards, Frank ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-28 0:00 ` clovis @ 1996-12-30 0:00 ` John (Max) Skaller 1996-12-29 0:00 ` Rosimildo da Silva 1996-12-31 0:00 ` Ian Joyner 1997-01-03 0:00 ` markj 1 sibling, 2 replies; 209+ messages in thread From: John (Max) Skaller @ 1996-12-30 0:00 UTC (permalink / raw) On 28 Dec 1996 04:58:39 GMT, clovis@wartech.com wrote: >Would someone PLEASE and QUICKLY hang those who insist that code is >"self-documenting?" The code I write _IS_ self-documenting. But then, I do write using a literate-programming system :-) ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-30 0:00 ` John (Max) Skaller @ 1996-12-29 0:00 ` Rosimildo da Silva 1996-12-31 0:00 ` Ian Joyner 1 sibling, 0 replies; 209+ messages in thread From: Rosimildo da Silva @ 1996-12-29 0:00 UTC (permalink / raw) John (Max) Skaller wrote: > > On 28 Dec 1996 04:58:39 GMT, clovis@wartech.com wrote: > > >Would someone PLEASE and QUICKLY hang those who insist that code is > >"self-documenting?" > > The code I write _IS_ self-documenting. > But then, I do write using a literate-programming system :-) I believe that code MUST be self-documented, even though the tools currently available does not help much. my $02 cents. Rosimildo. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-30 0:00 ` John (Max) Skaller 1996-12-29 0:00 ` Rosimildo da Silva @ 1996-12-31 0:00 ` Ian Joyner 1 sibling, 0 replies; 209+ messages in thread From: Ian Joyner @ 1996-12-31 0:00 UTC (permalink / raw) John (Max) Skaller wrote: > > On 28 Dec 1996 04:58:39 GMT, clovis@wartech.com wrote: > > >Would someone PLEASE and QUICKLY hang those who insist that code is > >"self-documenting?" > > The code I write _IS_ self-documenting. > But then, I do write using a literate-programming system :-) I think code should be written to be self-documenting, but certainly it is not self-documenting in itself, unless you have a conscientious programmer like John. But yes it can and should be self-documenting. Since we are talking about documentation, how many documents should you produce on a project? Many people I suspect would start to enumerate 'requirements spec', 'functional design doc,' 'detailed design', etc. However, the answer, I think is one! Only one document should be produced for any project no matter how large. This will link requirements and functions with bits of program, etc. With facilities like OpenDoc and to a lesser extent OLE becoming available, such documents will be possible. But they will require better programming languages. What made me think of this was that Bill Gates stated in his book that Boeng designed the entire 777 aircraft using one gigantic electronic document! Physical engineering disciplines have made good use of computing technology, it's about time software engineers followed the same path... better and more productive languages and environments, and stop defending archaic 25 year old languages from another era. And this gets back to a point Robert Martin made quite a while ago in this thread, that analysis and design is programming, and that these should not be done by different groups. For more thoughts: http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3.html ------------------------------------------------------------------------ Ian Joyner | "for when lenity and cruelty play | All opinions are Internet email: | for a kingdom, the gentler | personal and are i.joyner@acm.org | gamester is the soonest winner" | not Unisys | William Shakespeare Henry V | official comment ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-28 0:00 ` clovis 1996-12-30 0:00 ` John (Max) Skaller @ 1997-01-03 0:00 ` markj 1997-01-03 0:00 ` Natan 1 sibling, 1 reply; 209+ messages in thread From: markj @ 1997-01-03 0:00 UTC (permalink / raw) In <5a29dv$hb2@masters0.InterNex.Net>, clovis@wartech.com writes: >In <5a0niaINNlda@topdog.cs.umbc.edu>, jur@cs.umbc.edu (Jacqueline U. Robertson) writes: > >>Well, I was with you to some extent until you got here. Code bloat is a >>simple trade-off for increased maintainability and extensibility. Quite >>simply, it's easier to maintain and extend a decently written application >>in high level code than it is to maintain and extend a decently written >>application in assembler. I agree. >>The trade-off is that the assembly level application was more compact (both in disk space and in memory usage) - but harder to extend >>and modify. There's a reason that assembly level development is limited >>to small areas (such as in the limited resource milieu of deep space probes) - >>the trade off in favor of high level languages has generally been worth it, >>as increased disk space and increased amounts of RAM are economically cheaper >>than the 'more efficient' assembler writing. >This is also wrong. The reason that "paradigms" proliferate is obvious; people, and >managers in particular, are trying to get something for nothing. Compared to >procedural languages, it takes 3 lines of assembler to equal one line of, say, >PASCAL stuff. And it generally takes 5 lines of PASCAL to equal a line of Smalltalk >in a properly constructed hirearchy. Any operation one needs to do should not >be a series of lines, but a single method, and a single message sent to the instance. >There are exceptions, but with the compactness come other problems. I think you people are forgetting about the portability issue. I would always write in C rather than assembler because I can run the same code on many different CPU's. Also I'm lazy. Why should I bother to learn N assembly languages when I only need to learn 1 high level language, that is, C. Cheers, +------------------------------------+---------------------------------------+ | EMBEDDED SYSTEMS SOFTWARE ENGINEER | Specialist In: | | Mark Jordan TC, NZCE, BE, MIEEE | - DSP Applications | | Top Quality Work, Reasonable Rates | - Microprocessor Applications | | markj@netaccess.co.nz | - Reusable Software Libraries | +------------------------------------+---------------------------------------+ ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1997-01-03 0:00 ` markj @ 1997-01-03 0:00 ` Natan 0 siblings, 0 replies; 209+ messages in thread From: Natan @ 1997-01-03 0:00 UTC (permalink / raw) To: markj Mark Jordan wrote: > Also I'm lazy. Why should I bother to learn N assembly languages when I only > need to learn 1 high level language, that is, C. Since when is C a high level language? It is very easy to convert C-code to assembler. That's why some call C portable assembler. BTW I don't think discussions about assembler should be posted to OO-newsgroups (okay I'm guilty too). ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-27 0:00 ` clovis 1996-12-27 0:00 ` Jacqueline U. Robertson @ 1996-12-27 0:00 ` Tore Lund 1996-12-28 0:00 ` clovis 1996-12-28 0:00 ` Stephen Pendleton 2 siblings, 1 reply; 209+ messages in thread From: Tore Lund @ 1996-12-27 0:00 UTC (permalink / raw) clovis@wartech.com wrote: > > (snip) > > Yes, Assembler is the minority. And as a result Microsoft Word wants > 120 megs on a disk, where WordStar lived comfortably in 64k, code and > data both. Word does very little more. > > Seems we were told the truth to begin with, eh? > > Word barely runs in 8 megs of RAM. > > You started out talking about waste. Why 8 megs instead of 64k? Finally a voice of reason - also in the parts snipped out here. The main problem with OO and functional programming and all the other bright "paradigms" is their sectarian tendencies. They suffer from an utter inability to face their own shortcomings and cooperate with other modes of programming. As for the quote above - 8 megs vs. 64k - one must suspect that it is a conscious strategy to squeeze more money out of end users. (Who just *love* this sort of squeeze, judging from their reactions.) Or, it is due to the incompetence of Microsoft and the general megalomania of these times. In any case, OO as such is not to blame for it. -- Tore Lund <tl001@sn.no> ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-27 0:00 ` Tore Lund @ 1996-12-28 0:00 ` clovis 1996-12-28 0:00 ` Tore Lund 0 siblings, 1 reply; 209+ messages in thread From: clovis @ 1996-12-28 0:00 UTC (permalink / raw) In <32C3E34F.5DC5@sn.no>, Tore Lund <tl001@sn.no> writes: >Finally a voice of reason - also in the parts snipped out here. The main >problem with OO and functional programming and all the other bright >"paradigms" is their sectarian tendencies. They suffer from an utter >inability to face their own shortcomings and cooperate with other modes >of programming. Why, Thanks, Tore! I've been around the block a few times, and it sounds as though you have been as well. Differential equations, solved in Smalltalk, are no bargain. Neither are they solved best in C (although Smalltalk seems to lack a coherent assembly language interface for genuine engineering-based problems; I find this to be a major shortcoming, almost as though the Smalltalk folks who work on these systems have not paid their dues). >As for the quote above - 8 megs vs. 64k - one must suspect that it is a >conscious strategy to squeeze more money out of end users. (Who just >*love* this sort of squeeze, judging from their reactions.) Or, it is >due to the incompetence of Microsoft and the general megalomania of >these times. In any case, OO as such is not to blame for it. True. My point in all of this is that it comes down to a responsible and disciplined PROGRAMMER, a software professional. After that, the paradigm hardly matters; it is chosen to fit the problem at hand. Smalltalk and C++ are ridiculous for diagnostics, just as Assembly Language makes no sense coding for OSF/Motif's front end. We make hammers in different sizes, and screws and screwdrivers. I believe the same is true of languages; they are tools, not ends in themselves. And the good workmanship is done by those who know which tool to use for what, and don't try to drive screws with a hammer, or nails with the butts of screwdrivers. I would think long and hard before I would forsake Smalltalk for GUI programming. But there may well come a time when the task is sufficiently unusual that it makes more sense than not. The primary loyalty has to be to good work, and nothing else at all. Regards, Frank ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-28 0:00 ` clovis @ 1996-12-28 0:00 ` Tore Lund 0 siblings, 0 replies; 209+ messages in thread From: Tore Lund @ 1996-12-28 0:00 UTC (permalink / raw) clovis@wartech.com wrote: > > In <32C3E34F.5DC5@sn.no>, Tore Lund <tl001@sn.no> writes: > >>Finally a voice of reason (etc.) > > Why, Thanks, Tore! I've been around the block a few times, and it > sounds as though you have been as well. Just for the record: I am one of those lone developers who would like to use OO or functional languages but cannot do so because they never really get off the ground. Small-time customers want standards, and you cannot sell them Eiffel or Miranda as a standard when 4GLs do all they ever want to do in a cheaper and more portable way. I hope that Java will change this. But if so happens, it will be due to popular demand and a great user base rather than to any intrinsic properties of Java itself. One problem with OO and other paradigms is that they are never exposed to the merciless criticism of a demanding marketplace and the consequent effort to satisfy customers. Still, I make my living from programs that remedy the shortcomings of 4GLs, so maybe I should not complain. But it makes me feel more like a scavenger than like the craftsman I would like to be. Tore -- Tore Lund <tl001@sn.no> ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-27 0:00 ` clovis 1996-12-27 0:00 ` Jacqueline U. Robertson 1996-12-27 0:00 ` Tore Lund @ 1996-12-28 0:00 ` Stephen Pendleton 1996-12-31 0:00 ` Edward de Jong 2 siblings, 1 reply; 209+ messages in thread From: Stephen Pendleton @ 1996-12-28 0:00 UTC (permalink / raw) > > Yes, Assembler is the minority. And as a result Microsoft Word wants 120 megs on > a disk, where WordStar lived comfortably in 64k, code and data both. Word does > very little more. > To say that Word does little more than WordStar is comical. You people who complain about bloated code need to make the transition to the modern age. Granted WordStar may have only have used 64k, but those were the days when 64k was a lot of memory. Worry less about efficiency and more about functionality and maintainability and you will make better software. Steve ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-28 0:00 ` Stephen Pendleton @ 1996-12-31 0:00 ` Edward de Jong 1996-12-31 0:00 ` clovis ` (2 more replies) 0 siblings, 3 replies; 209+ messages in thread From: Edward de Jong @ 1996-12-31 0:00 UTC (permalink / raw) There is nothing comical at all in the comparison between WordStar and Microsoft Word. WordStar was the creation of one genius, Rob Barnaby, whom I met when Micropro bought my clone of WordStar, written in C, which became WordStar 2000. It took 12 programmers, myself included, one entire year, and about 100,000 lines of code to surpass the work of just one man, working in macro assembler. But let me tell you, macro assemblers are very clever tools; they can do amazing things; you can have multiple levels of macros, which are effectively miniature compilers, which output executable code, with the lowest possible overhead. In the hands of a genius, assembler can do amazing things in tiny spaces; that is why Barnaby could do so much in so little room. To implement a word processor that could run (with overlays), in a total space of 64kb, that had mail merge, all the printer drivers embedded in it, as well as controlling the screen in an optimal way, should be acknowledged for the amazing feat that it was. The reason macro assembler can be MORE POWERFUL than so-called higher level languages is that by using multiple levels of macros, you are creating a multi-level programming language, while most high level languages actually operate on a single or double level of abstraction. The real practical reasons for not using assembler are: 1) geniuses are rather rare 2) the resulting product has a lot of lines of code (4 to 10 times more than high level languges), which makes it harder to understand 3) the resulting product is almost impossible for another person to understand, because of the multi-level programming involved. -- edward@magicmouse.com author of Flying Colors for Macintosh, Pippin, and Windows platforms ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-31 0:00 ` Edward de Jong @ 1996-12-31 0:00 ` clovis 1996-12-31 0:00 ` Nick Leaton 1997-01-01 0:00 ` Tore Lund 2 siblings, 0 replies; 209+ messages in thread From: clovis @ 1996-12-31 0:00 UTC (permalink / raw) In <edward-3112960259160001@server.magicmouse.com>, edward@magicmouse.com (Edward de Jong) writes: Excellent analysis. Thanks for sharing it. And it is true -- without a LOT of sideline documentation, pure object code IS the most difficult to comprehend and maintain. >There is nothing comical at all in the comparison between WordStar and >Microsoft Word. WordStar was the creation of one genius, Rob Barnaby, >whom I met when Micropro bought my clone of WordStar, written in C, which >became WordStar 2000. It took 12 programmers, myself included, one entire >year, and about 100,000 lines of code to surpass the work of just one man, >working in macro assembler. But let me tell you, macro assemblers are >very clever tools; they can do amazing things; you can have multiple >levels of macros, which are effectively miniature compilers, which output >executable code, with the lowest possible overhead. > >In the hands of a genius, assembler can do amazing things in tiny spaces; >that is why Barnaby could do so much in so little room. To implement a >word processor that could run (with overlays), in a total space of 64kb, >that had mail merge, all the printer drivers embedded in it, as well as >controlling the screen in an optimal way, should be acknowledged for the >amazing feat that it was. > >The reason macro assembler can be MORE POWERFUL than so-called higher >level languages is that by using multiple levels of macros, you are >creating a multi-level programming language, while most high level >languages actually operate on a single or double level of abstraction. > >The real practical reasons for not using assembler are: > 1) geniuses are rather rare > 2) the resulting product has a lot of lines of code (4 to 10 times more >than high level languges), which makes it harder to understand > 3) the resulting product is almost impossible for another person to >understand, because of the multi-level programming involved. > >-- >edward@magicmouse.com >author of Flying Colors for Macintosh, Pippin, and Windows platforms ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-31 0:00 ` Edward de Jong 1996-12-31 0:00 ` clovis @ 1996-12-31 0:00 ` Nick Leaton 1997-01-01 0:00 ` Tore Lund 2 siblings, 0 replies; 209+ messages in thread From: Nick Leaton @ 1996-12-31 0:00 UTC (permalink / raw) > The real practical reasons for not using assembler are: > 1) geniuses are rather rare > 2) the resulting product has a lot of lines of code (4 to 10 times more > than high level languges), which makes it harder to understand > 3) the resulting product is almost impossible for another person to > understand, because of the multi-level programming involved. > Oh, and it is hard to port to machines that don't have that instruction set. Ah he say's retorically, you can get the macros to do it, but then again is that what a compiler does? -- Nick ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-31 0:00 ` Edward de Jong 1996-12-31 0:00 ` clovis 1996-12-31 0:00 ` Nick Leaton @ 1997-01-01 0:00 ` Tore Lund 1997-01-01 0:00 ` Tore Lund 2 siblings, 1 reply; 209+ messages in thread From: Tore Lund @ 1997-01-01 0:00 UTC (permalink / raw) Edward de Jong wrote: > > (snip) > It took 12 programmers, myself included, one entire year, and about > 100,000 lines of code to surpass the work of just one man, > working in macro assembler. But let me tell you, macro assemblers are > very clever tools; they can do amazing things; you can have multiple > levels of macros, which are effectively miniature compilers, which > output executable code, with the lowest possible overhead. > > In the hands of a genius, assembler can do amazing things in tiny > spaces; > (snip) This is very interesting. But tell us, Edward, is this is a mode of programming that is confined to geniuses only? I get the impression that you are saying something along those lines. Just about everything technical or scientific that has been invented by geniuses can be emulated by the normally talented engineer once it has been properly understood. What makes macro programming so special? I have been doing assembly for 12 years and have often heard about the wonders of macro programming, but I have never actually *seen* those wonders at work. Are you able to illustrate this mode of programming somehow? I realize that you are not trying to sell us macro programming as a style to be emulated. But you have actually seen a very successful system of this sort, so you might know pointers to examples or literature or whatever. I hope I don't sound skeptical or sarcastic. We know for sure that some programmers are far better designers than others, and it would be of considerable interest to get to know their modus operandi. It may turn out to be as futile as trying to map the mental processes of great composers or poets, but we could still make a try. If it took 12 years to surpass the work of just one man, then what you call multi-level programming has got to be something more tangible than sheer, formless "genius". Tore -- Tore Lund <tl001@sn.no> ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1997-01-01 0:00 ` Tore Lund @ 1997-01-01 0:00 ` Tore Lund 0 siblings, 0 replies; 209+ messages in thread From: Tore Lund @ 1997-01-01 0:00 UTC (permalink / raw) Tore Lund wrote: > > If it took 12 years to surpass the work of just one man, etc. I'm sorry. Please read 12 programmers, not 12 years. Too much fireworks outside for concentration. Happy New Year! -- Tore Lund <tl001@sn.no> ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-17 0:00 ` Robert Dewar 1996-12-18 0:00 ` Tansel Ersavas @ 1996-12-19 0:00 ` Robert C. Martin 1 sibling, 0 replies; 209+ messages in thread From: Robert C. Martin @ 1996-12-19 0:00 UTC (permalink / raw) In article <dewar.850825775@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > The fact of the matter is that there is NO giant shift of paradigm involved > here, despite what anyone says. Just look at the OO programs that people > produce. They are not radically different from conventional procedural > programs, and one would not expect them to be. > > OO techniques are a useful way of extending the conceptual design domain, > and OO features in programming languages allow added flexibility in > the solution space. Good! But trying to fit everything into the OO mold > is as reasonable as believing these ads on TV that suggest that all your > handy-man's problems at home can be solved with one amazing tool! I certainly agree with this sentiment; with one minor exception. While there may not be a "Giant Shift" of paradigm; there is a paradigm shift, and it can be overwhelming for some. The shift is, for the most part, a shift in priorities. We shift our focus from the details of what needs to be done to the structure of the code that will do it. We think more in terms of abstractions and interfaces than functions and data. We guard against undesirable dependencies rather than just depending on what we think we need at the time. We think about cogent groupings of data and function that can implement those interfaces as a single unit rather than just the data and functions that will do the job. Some engineers have a great deal of trouble making this kinds of shift. In some cases the problem is conceptual. i.e. the engineer just can't see the interfaces, the groupings, the structure, etc. In other cases the problem is a fear of overdesign. By building the abstractions and structures the engineer feels that he/she is wasting time and not actually making the program work. In either case, the shift of thinking, the paradigm shift, can be quite difficult to make. -- Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (847) 918-1004 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-15 0:00 ` Tansel Ersavas 1996-12-17 0:00 ` Adam Beneschan 1996-12-17 0:00 ` Robert Dewar @ 1996-12-17 0:00 ` Adam Beneschan 1996-12-17 0:00 ` Tansel Ersavas 1996-12-24 0:00 ` Nigel Tzeng 3 siblings, 1 reply; 209+ messages in thread From: Adam Beneschan @ 1996-12-17 0:00 UTC (permalink / raw) In article <32B3F45C.5140@deep.net> tansel@deep.net writes: >First of all, my opinion is, developing systems with procedure oriented >techniques is a dangerous, wasteful and unproductive process. OO techniques are a relatively recent development. Major software has been developed for the last several decades. If the above statement were true as written, one would have to draw the conclusion that software developers, whose best tool was "procedure-oriented techniques", were unable to produce ANY good software, and the software they did produce was dangerous. Clearly, that isn't the case--a lot of good software has been produced over the last 30-40 years. Procedure-oriented programming has its limitations, and OO pioneers must be credited with exposing its flaws and, more importantly, developing a viable alternative. This hardly makes procedure-oriented techniques dangerous or wasteful or unproductive. >So far OO >couldn't show a quantum leap of difference, but it is not mature yet. Another reason there isn't a quantum leap is that procedure-oriented programming is not the demonic evil you make it out to be. >When I train people, I look at their background. Usually the more >experienced in the traditional techniques they are, the less they >believe the necessity of learning a new technique. In my breakthrough >courses, for the first part, I challenge the traditional ways of systems >development and show that this way of developing systems is a historical >accident, and the more we insist on going that way, the more troubles we >will be in. I'd hardly call it a "historical accident". Procedure-oriented ("structured programming") techniques were a huge improvement over what was done before, which was to write code haphazardly and completely unstructured. Whether we had the know-how at the time to develop OO techniques instead of procedural techniques, I don't know. Probably not. I suspect that the structured-programming "revolution" was a necessary step in the evolution of software engineering techniques that is now leading us to OO techniques and will probably lead to something completely different a couple decades hence. In other words, our experiences with structured programming have taught us a lot of the things we needed to know in order to develop OO techniques--things we wouldn't have found out if the evolutionary step you call a "historical accident" had never taken place. >Unfortunately, with their slow and wasteful structure, big companies can >absorb huge amounts of losses without blinking. This contributes a lot >to people not realizing how big the crisis is. In fact, even many >succesful systems Today are big money wasters. >Procedural thinking and OO are not complimentary. Procedural thinking >requires a major transformation that affects all our thinking. I know >it, because I was a procedural programming freak, starting programming >with a 6502 board with hex keypad, and being a mad assembler, C and >later C++ person. Even when I was a C, C++ person my productivity was >substantially higher than others, I couldn't make the switch to OO until >I let my strong and enjoyable procedural skills go. Now I only program >with Smalltalk (not a prerequisite to anything, just a choice), and I do >everything in a much higher level previously unimaginable to me. My >productivity increased 5 fold, and I developed a tool to further >increase it another 5 fold. Now I know that the tools and techniques I >use are anywhere from 5 to 25 times better than my old techniques >before. These techniques are pure OO but I am reaching limits of them. >Therefore I expanded my horizons to other techniques that I combine with >OO which will increase my productivity another order of magnitude. The rest of this post, which I didn't quote, runs along the same lines. To be honest, if I was in a management position and needed OO training, I wouldn't consider using your training services, since I can't tell whether you're turning out good software engineers or engineers who go around chanting "Four legs good, two legs bad" . . . er, "OO good, Procedural bad". Come on. OO is a better mousetrap, not a knight on a white horse come to save the world from the evil oppression of procedural thinking. Thinking about it in such a polarized manner is not going to produce engineers who understand software engineering issues realistically. -- Adam ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-17 0:00 ` Adam Beneschan @ 1996-12-17 0:00 ` Tansel Ersavas 1996-12-18 0:00 ` Ralph Cook ` (3 more replies) 0 siblings, 4 replies; 209+ messages in thread From: Tansel Ersavas @ 1996-12-17 0:00 UTC (permalink / raw) Adam Beneschan wrote: > > OO techniques are a relatively recent development. Major software has > been developed for the last several decades. If the above statement > were true as written, one would have to draw the conclusion that > software developers, whose best tool was "procedure-oriented > techniques", were unable to produce ANY good software, and the > software they did produce was dangerous. OO techniques are not a relatively recent development. OO has been around since SIMULA (1965-1967). > > Clearly, that isn't the case--a lot of good software has been produced > over the last 30-40 years. Procedure-oriented programming has its > limitations, and OO pioneers must be credited with exposing its flaws > and, more importantly, developing a viable alternative. This hardly > makes procedure-oriented techniques dangerous or wasteful or > unproductive. This is true, depending on the criteria that you are using. There are a lot of procedure oriented systems that I developed or was the architect of, and are considered very good. Individual success stories don't change the following facts though: a) Software industry is in a crisis. b) The application gap is still growing c) Every year abandoned software costs the world economy unmentionable billions of dollars. d) Even many so called successful projects Today are big money drains e) The approach we use for systems development influence a, b, c and d How can we justify massive collapses of big systems with hundreds of millions of dollars down the drain with a cool face? If we don't call this a failure, what are we going to call? If it not waste, I would like to learn your definition of waste. And, dangerous, yes, because it creates a false sense of security once people get used to it. > >So far OO > >couldn't show a quantum leap of difference, but it is not mature yet. > > Another reason there isn't a quantum leap is that procedure-oriented > programming is not the demonic evil you make it out to be. I never said procedure oriented programming was the demonic evil. I just said, wasteful, dangerous, and unproductive. I must admit, when I was developing procedure oriented systems, I would enjoy developing them. Something can be dangerous, but still enjoyable; take motorcycle riding. It is very enjoyable, and the bikes are beautiful, but it doesn't change the fact that they are a few times more dangerous that cars. How can I say that motorcycle riding is evil? But it doesn't stop me from pointing out dangers to myself and others. Or take guinea pigs, they are lovely pets, but they are wasteful, and unproductive IF you have all females (males tend to fight, and male-female combinations are extremely productive) but they just are, they make cute pets and we enjoy them. Things just are. We simply observe them, and put out our comments from our perspective. We don't want to sort things out as good or evil. Potential dangers should be noted though. I.e. it is a nice idea to mark quicksand as dangerous, especially if you saw some people drowning. > I'd hardly call it a "historical accident". Procedure-oriented > ("structured programming") techniques were a huge improvement over > what was done before, which was to write code haphazardly and > completely unstructured. Whether we had the know-how at the time to > develop OO techniques instead of procedural techniques, I don't know. > Probably not. I suspect that the structured-programming "revolution" > was a necessary step in the evolution of software engineering > techniques that is now leading us to OO techniques and will probably > lead to something completely different a couple decades hence. In > other words, our experiences with structured programming have taught > us a lot of the things we needed to know in order to develop OO > techniques--things we wouldn't have found out if the evolutionary step > you call a "historical accident" had never taken place. In fact, you are right. I shouldn't have called it a historical accident. It is actually a series of historical accidents. I'll put some of these historically important milestones to somewhere in my site, so that it can be visited like a museum, for people have tendency to quickly forget. As an example would you like to tell me say, how and why one of the most popular languages "C" was developed to prove your point that the language which is very widely used now and enjoyed by many (which includes me) is not a historical accident? And yes, there are undeniably a few moments in recent history which were carefully planned attempts to solve problems, but they are more exception than the norm. Also, I would like to clarify that structured programming is NOT procedure orientation. Writing code haphazardly is also procedure orientation. Procedure oriented programming is the technique we apply when we write code directly for a von Neumann machine. I don't deny that structured programming, structured design and structured analysis are all big improvements over unstructured procedural approach, and all of them are procedural as much as a spaghetti code, they are only more structured. I have explained in a few of my previous postings, and I get many requests to repost them, but, I feel that people are already getting sick, I'll organize this information and present it in our web site: http://www.rase.com/ after the new year break. So if you want to know what I mean by "historical accidents", and other information that I present, along with the proper references. Please browse after the new year's eve, and if you have any questions or problems I'll be happy to discuss either publicly or via e-mail. > The rest of this post, which I didn't quote, runs along the same > lines. To be honest, if I was in a management position and needed OO > training, I wouldn't consider using your training services, since I > can't tell whether you're turning out good software engineers or > engineers who go around chanting "Four legs good, two legs bad" . . . > er, "OO good, Procedural bad". Again, something, I couldn't possibly have told, or taught without reason. On the other hand, as a trainer (which I am occasionally, only because I enjoy it so much), If I were to be able to help you, I'm sure both of us would benefit. I feel that sharing what I know is a duty. I am not sentimental. It wouldn't bother me if you wouldn't come to me Today, but in 5 years, things may change, and if you come to me then, I'll do my best to accommodate training your people. And a guarantee, nobody will be chanting anything without solidly supporting these ideas with figures and references. Why is it difficult to accept any questions, comments and criticisms about procedure orientation? If you accept the premise that procedure orientation was as good as you say it is, how do you explain a big failure rate in complex software, and lost billions? > Come on. OO is a better mousetrap, not a knight on a white horse come > to save the world from the evil oppression of procedural thinking. > Thinking about it in such a polarized manner is not going to produce > engineers who understand software engineering issues realistically. OO can be a mousetrap, yes, but guess for whom? It is clearly a knight for some. Remember, only the princess who kissed the frog got a prince, to some other, it was just a frog. Coming to the issue of engineers that understand software engineering issues realistically, If we don't change things right now, Tomorrow will be the same. Many people rightly pointed out that as long as the university curriculums don't change, engineers of Tomorrow will not be so much different to engineers of Today. All I want to do is to start changing things Today, so that I can tell my children that I have done what I could. > -- Adam Tansel ----------------------------------------------------------------------- RASE Inc. Clark NJ USA Voice: (908) 396 7145 mailto:tansel@rase.com Fax: (908) 382 1383 http://www.rase.com/ ----Sufficiently advanced technology is indistinguishable from magic--- A.C. Clarke ----------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-17 0:00 ` Tansel Ersavas @ 1996-12-18 0:00 ` Ralph Cook 1996-12-18 0:00 ` Adam Beneschan ` (2 subsequent siblings) 3 siblings, 0 replies; 209+ messages in thread From: Ralph Cook @ 1996-12-18 0:00 UTC (permalink / raw) Tansel Ersavas wrote: > ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-17 0:00 ` Tansel Ersavas 1996-12-18 0:00 ` Ralph Cook @ 1996-12-18 0:00 ` Adam Beneschan 1996-12-19 0:00 ` Robert C. Martin 1996-12-19 0:00 ` Nick Leaton 3 siblings, 0 replies; 209+ messages in thread From: Adam Beneschan @ 1996-12-18 0:00 UTC (permalink / raw) In article <32B758D7.61EF@deep.net> tansel@deep.net writes: >Why is it difficult to accept any questions, comments and criticisms >about procedure orientation? If you accept the premise that procedure >orientation was as good as you say it is, how do you explain a big >failure rate in complex software, and lost billions? It would take me some time to look over and prepare a response to your entire response to my post (assuming I decide to respond at all rather than let others address your points). But I can deal with this one now. Nowhere did I say that procedure orientation is immune from criticism or question. In fact, I've been working as a programmer for 20 years, and almost since the beginning I've had a sense that there should be a better way. I've always been interested in languages with totally different paradigms, such as "pure" Lisp, Prolog, Backus' FP, Lucid, dataflow, some 4GL ideas, more recently Haskell, and several other experimental languages that have gotten write-ups in SIGPLAN notices and have since seemingly disappeared from the face of the earth. (Whatever happened to M'PAL?) OO is, in fact, another idea that I've been really interested in, and I think it's a significant step forward in software engineering. (I did, after all, describe it as a "better mousetrap.") What I object to is not the idea that OO is better than what we were doing before (I think it is), nor that "procedure orientation" is flawed (I'm sure it is). Rather, it's the black-and-white tone of your post, that OO is completely wonderful, that "procedure orientation" has no value whatsoever, and that programmers who don't see things that way are simply unwilling to change, or unwilling to try something new, or have been using procedural techniques so long that they are stuck with them, or just hate new ideas or some such. The fragment I've quoted above is a symptom of this kind of thinking; apparently because I criticized your first post, you've assumed, without justification, that I find it difficult to accept questions or criticisms about procedure orientation. Nothing could be further from the truth. -- Adam ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-17 0:00 ` Tansel Ersavas 1996-12-18 0:00 ` Ralph Cook 1996-12-18 0:00 ` Adam Beneschan @ 1996-12-19 0:00 ` Robert C. Martin 1996-12-20 0:00 ` Tansel Ersavas 1996-12-19 0:00 ` Nick Leaton 3 siblings, 1 reply; 209+ messages in thread From: Robert C. Martin @ 1996-12-19 0:00 UTC (permalink / raw) In article <32B758D7.61EF@deep.net>, tansel@deep.net wrote: > > a) Software industry is in a crisis. > b) The application gap is still growing > c) Every year abandoned software costs the world economy unmentionable > billions of dollars. > d) Even many so called successful projects Today are big money drains > e) The approach we use for systems development influence a, b, c and d > > How can we justify massive collapses of big systems with hundreds of > millions of dollars down the drain with a cool face? If we don't call > this a failure, what are we going to call? If it not waste, I would like > to learn your definition of waste. And, dangerous, yes, because it > creates a false sense of security once people get used to it. The logical leap that you are making is that "procedural programming" is responsible for points a-e. I'd like to see some concrete evidence to that effect. The other logical leap you are implying is that OO corrects points a-e. Again, I'd like to see some empirical evidence. Now, my belief is, (and my own experiences bear this out) that proper (repeat *proper*) use of OO techniques can help to make large software projects somewhat more maintainable, more flexible, more robust, and more reusable. (Did I get all the buzz words in there?) Not that they didn't have some of those traits before; its just that OO can enhance those particular traits by some amount. And it seems reasonable (although I have only the most miniscule amount of real empirical evidence to support this) that enhancing these traits has an impact upon your points a-e above. But I have no proof as yet. And, as far as I know, neither does the industry at large. On the other hand, there are costs associated with OO. Done properly, the structural complexity of applications increases, sometimes dramatically. This complexity is what enhances the maintainability, flexibility, etc. But the cost is real. I have experienced the payback. I know that OO is almost always worth the cost. Indeed, when a large supply of reusable components is assembled into a framework, the savings can be significant. But the cost must still be paid. (See my paper "ETS Case Study" available from the freeware section of my website). Another point is that there is massive confusion in the industry regarding methodology. Should you use Booch? OMT? UML? How about Shlaer/Mellor? Some of these methods are remarkably different from the others. Which one yeilds the best benefits. IMHO, some of them work quite well, and some are exceedingly dangerous. But who do you believe? Thus, for the typical software manager, the costs of OO may overwhelm the potential benefits. If he makes the wrong choices with respect to methodology, if he fails to adequately train his people in the proper use of OO, if he expects to immediately reduce his costs, then for him OO will be more wasteful and dangerous than procedural. The manager who is careful to research the methods, who checks as much empirical data as possible, who carefully runs trials without committing his whole organization, who energetically trains his people, who makes sure they are properly mentored during their first few projects; this manager may reap the benefits of OO by producing systems that are easier to change, easier to maintain, and easier to reuse. This manager may be able to build up a stockpile of reusable software and arrange it in a framework that allows applications to be developed in significantly less time than before. But those are very big IFs. -- Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (847) 918-1004 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-19 0:00 ` Robert C. Martin @ 1996-12-20 0:00 ` Tansel Ersavas 1996-12-21 0:00 ` Michael Malak 0 siblings, 1 reply; 209+ messages in thread From: Tansel Ersavas @ 1996-12-20 0:00 UTC (permalink / raw) Robert C. Martin wrote: > > The logical leap that you are making is that "procedural programming" is > responsible for points a-e. I'd like to see some concrete evidence to > that effect. The other logical leap you are implying is that OO corrects > points a-e. Again, I'd like to see some empirical evidence. It is known that a vast majority of Today's systems (about 92%) are procedure oriented systems. Do you think this is not enough? OO corrects this? There are no controlled studies so far, however we plan to start one using our systems development tool late next year in colloboration with various universities. There is also a big problem with how we interpret, and apply OO which in most cases I observed far less than optimal. > Another point is that there is massive confusion in the industry regarding > methodology. Should you use Booch? OMT? UML? How about Shlaer/Mellor? Some > of these methods are remarkably different from the others. Which one yeilds > the best benefits. IMHO, some of them work quite well, and some are > exceedingly dangerous. But who do you believe? With most dominant methodologies molding to one, the holy "Unified" methodology with Booch, Rumbaugh and Jacobson together, I guess the current battle is over with them having a big chunk of the market, at least for now. I still expect some more action in methodologies corner, especially from the RDD side. Which methodologies are you referring to as exceedingly dangerous ones? > Thus, for the typical software manager, the costs of OO may overwhelm the > potential benefits. If he makes the wrong choices with respect to methodology, > if he fails to adequately train his people in the proper use of OO, if he > expects to immediately reduce his costs, then for him OO will be more wasteful > and dangerous than procedural. > The manager who is careful to research the methods, who checks as much > empirical data as possible, who carefully runs trials without committing > his whole organization, who energetically trains his people, who makes > sure they are properly mentored during their first few projects; this manager > may reap the benefits of OO by producing systems that are easier to change, > easier to maintain, and easier to reuse. This manager may be able to build > up a stockpile of reusable software and arrange it in a framework that allows > applications to be developed in significantly less time than before. But those > are very big IFs. This is a problem I observed when I first started practicing OO. Your observations parallel mine where switching to OO techniques were brought at a significant cost. It does not have to be that way. OO in its current form is costly, because it is pushed as a useful incremental advance over the procedural techniques. I will explain why. << Please do not separate any of this segment to quote, because it is extremely important that it is presented as a whole to keep its meaning >> << Begin segment >> We have been taught to solve problems in a certain way (i.e. procedurally). When we are introduced to OO, we still subliminally think in procedural terms. The OO techniques are taught, and the development process starts. We think, "OK, these concepts of classes and objects, inheritence, polymorphism, and encapsulation seem to be cool" and start applying these techniques. If we stop there, by doing nothing but exactly using these above, all we can get is very much like a manual and labor intensive data compression over our procedural approach. Inheritance, besides creating a much greater understanding about what we are dealing with, allows us to structure our classes in nice tree forms so that we can locate duplicated chunks easily, and promote reuse through automatic access to procedures and data at higher levels through generalization and specialization. Polymorphism simplifies things by allowing us to use same familiar interface to custom tailored individual response, and encapsulation allows us to hide implementations of these classes and objects from others. All the above gives us is a different, but neat looking way of solving problems. We start developing systems with this approach, soon we find out that it is difficult. Why? Because we are manually applying a "data compression" like algorithm on top of our existing procedure orientation approach. We can not haphazardly introduce new data and code, we have to know about the system a lot. In the end, after a sweating experience, we can show that our new system took longer to develop, however, it looks somehow simpler, this much shorter and that much easier to maintain. If this is the approach we are taking, it is not going to be significantly better the next time. Because we will still be using the same compression algorithm, slightly improved after our lessons from the first project. The results of the previous systems development effort can offer us some reusable material, but no one will bother unless it is made extremely simple by creating repositories over this vast structure. Using this technique, depending on our understanding of the problem at hand, and ability to deliver, we can come up with ratios similar to 1:2 to 1:5 with especially initially working much harder than the procedural approach. My initial understanding of OO was something similar along these lines, and it didn�t take me anywhere. This approach is not a major paradigm shift and in this case all people saying that OO is an incremental advance over procedure orientation are right if that�s all they saw so far. << End segment >> At its simplest, data compression is an analogy that I wanted to use because it resembles Today's OO systems development efforts. However, there is always an overhead of data compression, it may not be feasible for certain data, and results widely change from data to data as well as the compression algoritm. One of my initial failures while practicing OO was that I hadn�t realized the most important difference of OO to all other previous approaches. I would like to ask this question here. << $1,000,000.- Question >> What is the most important difference between the procedural paradigm and the object oriented paradigm that makes OO a significantly different one? << End question >> I will answer to this question after I see peoples� responses by referring to one of the forefathers of object orientation and one of the great visionaries of our times. First to answer correctly (IMO) to this question will get a small surprise present if he or she e-mails me a copy of the post. I am missing a lot of the postings, so there is no guarantee that I�ll see the posted ones. If someone can actually pull out who I am hinting about, I will have a bigger present for that person. Meanwhile I would like to thank all the people sent e-mail to me. I�ll do my best to reply them, however there are too many of them which will take me some time to reply. I would like to thank to each and every one, including flames, for each of them teach me something, or confront me with questions I can come across somewhere else. Tansel ----------------------------------------------------------------------- RASE Inc. Clark NJ USA Voice: (908) 396 7145 mailto:tansel@rase.com Fax: (908) 382 1383 http://www.rase.com/ ----Sufficiently advanced technology is indistinguishable from magic--- -------------------------------A.C. Clarke----------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-20 0:00 ` Tansel Ersavas @ 1996-12-21 0:00 ` Michael Malak 0 siblings, 0 replies; 209+ messages in thread From: Michael Malak @ 1996-12-21 0:00 UTC (permalink / raw) In article <32BB2C50.2B0B@rase.com>, Tansel Ersavas <tansel@rase.com> wrote: > ><< $1,000,000.- Question >> >What is the most important difference between the procedural paradigm >and the object oriented paradigm that makes OO a significantly different >one? ><< End question >> OO reduces complexity in a system by reducing the number of dependencies. A good OO system will have a number of loosely coupled objects, with much of the detail encapsulated in the objects themselves. Moreover, OO systems are resiliant to change. In OO, one identifies the "objects", the "things" in the domain. It turns out that these boundaries change less frequently than do their implementations. Objects may (and are almost always) expanded, but not "changed" as the system grows. In procedural systems, boundaries are less common (to be sure, different "subsystems" are independent, but that's the big exception) and less rigid. Dependencies are combinatorically more prevalent. Worse, the dependencies are not necessarily organized or recognized in any explicit way, so that a change to one part of the system has unknown effects in other parts of the system. OO exploits (and relies upon) human being's ability to abstract -- to be able to see a table and recognize its "tableness" -- in order to "magically" reduce dependencies, complexity, and brittleness (w.r.t. change). -- Michael Malak Magic forwarding e-mail address: Washington, DC malak@acm.org ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-17 0:00 ` Tansel Ersavas ` (2 preceding siblings ...) 1996-12-19 0:00 ` Robert C. Martin @ 1996-12-19 0:00 ` Nick Leaton 3 siblings, 0 replies; 209+ messages in thread From: Nick Leaton @ 1996-12-19 0:00 UTC (permalink / raw) Tansel Ersavas wrote: > Or take guinea pigs, they are lovely pets, but they are wasteful, and > unproductive IF you have all females (males tend to fight, and > male-female combinations are extremely productive) but they just are, > they make cute pets and we enjoy them. If you want, I can find you some recipes. -- Nick ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-15 0:00 ` Tansel Ersavas ` (2 preceding siblings ...) 1996-12-17 0:00 ` Adam Beneschan @ 1996-12-24 0:00 ` Nigel Tzeng 1996-12-26 0:00 ` Tansel Ersavas 3 siblings, 1 reply; 209+ messages in thread From: Nigel Tzeng @ 1996-12-24 0:00 UTC (permalink / raw) In article <32B3F45C.5140@deep.net>, Tansel Ersavas <tansel@deep.net> wrote: >Robert C. Martin wrote: >> >> In article <32AA207E.3199@deep.net>, tansel@deep.net wrote: >> >> > There are three major reasons why OO projects fail. All of them are >> > stated by the great wisdom of Jedi in "Star Wars". >> > >> > These are: >> > "Do or do not. There is no try" >> > Using my tools and techniques, I can prove you that I can produce >> > better and faster systems using OO (Please read my notes at the end >> > of this message). If I can do it, so you can.If you just try to do >> > it, you will fail. Be determined to do it. Why does this remind me of the get rich on real estate seminars? Well, gee people fail using my strategy becuase they weren't committed enough. They didn't truly believe it would work so it failed.... [snip] >First of all, my opinion is, developing systems with procedure oriented >techniques is a dangerous, wasteful and unproductive process. So far OO Any particular reason why? Do you have metrics that show that procedure oriented techniques are inherently dangerous or wasteful? What do you mean by dangerous anyway? >couldn't show a quantum leap of difference, but it is not mature yet. >When I train people, I look at their background. Usually the more >experienced in the traditional techniques they are, the less they >believe the necessity of learning a new technique. In my breakthrough IMHO this is more likely the case of being around the block a couple of times and seeing several "silver-bullet" approaches fail miserably rather than some inherent dislike of doing something different. We are an OO shop and there are many advantages to doing OO design but is it the savior of all programming projects? Nah. Is it really THAT much more efficient or successful than SASD? Nah. Why? Becuase the root cause of a lot of project failure isn't with the underlying technology (OO vs SASD) but due to the politics and social dynamics of any project. My opinion is that peopleware issues are more important than the underlying methodology used in a project...and that you are far more likely to see these "order of magnitude" productivity changes by adhering to Peopleware than OO (not that Peopleware is a silver bullet mind you :). [procedural thinking vs OO deleted] >Anybody wishing to see these techniques in action, I'm happy to >demonstrate them. It is the only proof I can show to anyone that OO >works, and works much better than anything they have seen so far. And >without unlearning, it wouldn't have been possible. I think that most members of this newsgroup are open to new ideas and success stories. Feel free to share your experience. [snip] >I'll remind you of the placebo effect. IMO belief creates miracles. But >it is also true that blind faith is dangerous. Great...well I suppose that we can increase productivity by changing the light level every couple of months. >Any time a new paradigm comes around there are pioneers. They make the >bold decisions to shape the history. They are less than 1% of the >participants. Pioneers are nothing but visioners and believers. They >create their evidence, and history. And never ever let one of these folks lead your project. Yeah, they will strike gold 1% of the time but do you really want to be on the other 99% of the projects? Now these folks can change the face of the market...but it's too bad that in general some popularizer steals the market from the visionary. Steve Jobs lives here... >Then there come early adopters. People who don't need "empirical >evidence". Who use their intuition to make sense of what the pioneers >are pointing to. These folks have a higher success rate but people who live on the cutting edge tend to bleed. Will they really gain a significant market advantage? Depends a little on luck...but if there's nothing to lose. I'd say Netscape lives here...they scored big by early adoption of internet technology and splitting off from NCSA. >Then there are popularizers. People are quicker than the others, just >like the people who watch the other traffic lights to see when they are >going red so that they could be the first to respond to the green light. >They require evidence, but can act very quickly. Probaby the best place to live...the visionaries and early adopters has weeded out the "looked like a good idea on paper" strategies out and there are valuable lessons to be mined from their successes and failures. Here be Microsoft...or maybe a little lower. Wherever they live they seem to real good at stealing markets from visionaries and early adopters :) >Then there are followers, much like people passing at the green light. >They do nothing but go with the crowd. There must be empirical evidence >for them. And most of us sit here. After all, most of us aren't doing anything to win Nobel prizes over or changing the face of the market. [snip] >In fact, I can't follow all of it, but during this discussion about >what's wrong with OO I tried to observe any excitement, but couldn't see >much of it around. The thing is that the best programmers out there are constantly learning, making improvements and adopting new technology as it becomes useful. But they don't tend to be zealots over any particular tool or even set of tools...because one you buy into a particular paradigm with heart and soul you're a lot less likely to change or to see the problems with the paradigm. Besides...methodologies are only tools...important in that they help us get the job done but they are not and should not be the focus of our excitement (unless we are researchers). There is an interesting comment I read in a home theater magazine where an individual states that he never wanted to be one of those people who said "Hey, you have to come over and see/hear my system!" because the objective is to come over and see a movie or hear music. The A/V equipment should be so good as to be unnoticable. Likewise I'd rather say "Hey, come use my great new product" and not "Hey, we designed this thing using OO isn't that great!" >> Robert C. Martin | Design Consulting | Training courses offered: >Tansel Ersavas Nigel ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-24 0:00 ` Nigel Tzeng @ 1996-12-26 0:00 ` Tansel Ersavas 1996-12-26 0:00 ` Bill Gooch 0 siblings, 1 reply; 209+ messages in thread From: Tansel Ersavas @ 1996-12-26 0:00 UTC (permalink / raw) Nigel Tzeng wrote: ... > >First of all, my opinion is, developing systems with procedure oriented > >techniques is a dangerous, wasteful and unproductive process. So far OO > > Any particular reason why? Do you have metrics that show that procedure > oriented techniques are inherently dangerous or wasteful? What do you > mean by dangerous anyway? I have stated this in a few of my previous postings. However, I will post about this subject in detail after the new year. You might also want to look at my reply to David Rush (drush@zakalwe.raleigh.ibm.com). ... > We are an OO shop and there are many advantages to doing OO design but > is it the savior of all programming projects? Nah. Is it really THAT > much more efficient or successful than SASD? Nah. The problem is how we currently apply the OO approach. It CAN be THAT much more efficient than SA SD. Again, you might want to browse my reply to David Rush. > Why? Becuase the root cause of a lot of project failure isn't with > the underlying technology (OO vs SASD) but due to the politics and > social dynamics of any project. > > My opinion is that peopleware issues are more important than the > underlying methodology used in a project...and that you are far more > likely to see these "order of magnitude" productivity changes by > adhering to Peopleware than OO (not that Peopleware is a silver bullet > mind you :). That is very true, indeed I have stated it in many of my postings. I stated that the only silver bullet is to have the right people, right type of organization, right type of approach and right types of tools all together. One missing, efficiency reduces dramatically ... > > >Anybody wishing to see these techniques in action, I'm happy to > >demonstrate them. It is the only proof I can show to anyone that OO > >works, and works much better than anything they have seen so far. And > >without unlearning, it wouldn't have been possible. > > I think that most members of this newsgroup are open to new ideas and > success stories. Feel free to share your experience. I'll sure do that. So far, I only had to reply to individual postings, which can not give clear view of my ideas. I plan to prepare a posting about this discussion and send it after the new year, time permitting. ... > Great...well I suppose that we can increase productivity by changing the > light level every couple of months. Which can be done, of course. And if you don't believe me, just visit a hen battery to see how they are, or can be tricked to get twice the eggs by changing the light level twice a day. (Not recommending it for anybody though) > >Any time a new paradigm comes around there are pioneers. They make the > >bold decisions to shape the history. They are less than 1% of the > >participants. Pioneers are nothing but visioners and believers. They > >create their evidence, and history. > > And never ever let one of these folks lead your project. Yeah, they will > strike gold 1% of the time but do you really want to be on the other 99% > of the projects? > > Now these folks can change the face of the market...but it's too bad > that in general some popularizer steals the market from the visionary. > > Steve Jobs lives here... I agree with your sentiments. > >Then there come early adopters. People who don't need "empirical > >evidence". Who use their intuition to make sense of what the pioneers > >are pointing to. > > These folks have a higher success rate but people who live on the cutting > edge tend to bleed. Will they really gain a significant market advantage? > Depends a little on luck...but if there's nothing to lose. > > I'd say Netscape lives here...they scored big by early adoption of > internet technology and splitting off from NCSA. That's true as well > >Then there are popularizers. People are quicker than the others, just > >like the people who watch the other traffic lights to see when they are > >going red so that they could be the first to respond to the green light. > >They require evidence, but can act very quickly. > > Probaby the best place to live...the visionaries and early adopters > has weeded out the "looked like a good idea on paper" strategies out > and there are valuable lessons to be mined from their successes and > failures. That's also very agreeable, which is just about where we are coming in OO. ... > >Then there are followers, much like people passing at the green light. > >They do nothing but go with the crowd. There must be empirical evidence > >for them. > > And most of us sit here. After all, most of us aren't doing anything > to win Nobel prizes over or changing the face of the market. And there's nothing wrong with it. In many issues, I choose to be a follower, even conservative in some. ... > The thing is that the best programmers out there are constantly > learning, making improvements and adopting new technology as it > becomes useful. But they don't tend to be zealots over any particular > tool or even set of tools...because one you buy into a particular > paradigm with heart and soul you're a lot less likely to change or to > see the problems with the paradigm. That's true. However, that's naturally done by many in the form of unconsciously clinging to the existing paradigm, probably till its collapse. However we deny it, paradigms shape our thinking, which is at the center of this discussion. Many people think that they can look at procedure orientation from a neutral point of view, but they can't. Here, I can't help but quote from Ed Yourdon: << Please only quote this as a whole >> " 'From Emerging Software Technologies by Ed Yourdon:' . Software methodologies are often supported and marketed by a specific vendor, or guru . The guru becomes dependent on the success of his/her methodology in order to pay rent and maintain credibility/status/ego . The fiery, young revolutionary often becomes conservative old fart, defending his/her paradigm as more and more exceptions and problems found . Methodology collapses under its own weight when a critical mass of people believes that it no longer serves their needs - but the change is often delayed for years and decades because of inertia, politics, etc. " << End quote >> > Besides...methodologies are only tools...important in that they help > us get the job done but they are not and should not be the focus of > our excitement (unless we are researchers). That's true, but there is also nothing wrong about being excited about something that you can see it can clearly improve your productivity dramatically. > There is an interesting comment I read in a home theater magazine > where an individual states that he never wanted to be one of those > people who said "Hey, you have to come over and see/hear my system!" > because the objective is to come over and see a movie or hear music. > The A/V equipment should be so good as to be unnoticable. This is probably more relevant to computers themselves, being ugly bulks of heat producing masses with primitive user interfaces that still tend to alienate a reasonable chunk of people from what they can offer. I agree with what you say about this subject. > Likewise I'd rather say "Hey, come use my great new product" and not > "Hey, we designed this thing using OO isn't that great!" That's true. In fact what people will call OO will be largely defined by themselves. It is not very right to apply a rigid classification and divide things in two, and unconditionlly defend one. However, it is also important the differences of different apporaches and their potential benefits to make people more aware of what is possible with other approaches. > Nigel Tansel ----------------------------------------------------------------------- RASE Inc. Clark NJ USA Voice: (908) 396 7145 mailto:tansel@rase.com Fax: (908) 382 1383 http://www.rase.com/ ----Sufficiently advanced technology is indistinguishable from magic--- -------------------------------A.C. Clarke----------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-26 0:00 ` Tansel Ersavas @ 1996-12-26 0:00 ` Bill Gooch 0 siblings, 0 replies; 209+ messages in thread From: Bill Gooch @ 1996-12-26 0:00 UTC (permalink / raw) Tansel Ersavas wrote: > ... > Here, I can't help but quote from Ed Yourdon: > > << Please only quote this as a whole >> > " 'From Emerging Software Technologies by Ed Yourdon:' > . Software methodologies are often supported and marketed by a > specific vendor, or guru > . The guru becomes dependent on the success of his/her methodology in > order to pay rent and maintain credibility/status/ego > . The fiery, young revolutionary often becomes conservative old fart, > defending his/her paradigm as more and more exceptions and problems > found > . Methodology collapses under its own weight when a critical mass of > people believes that it no longer serves their needs - but the change > is often delayed for years and decades because of inertia, > politics, etc. " > << End quote >> I wonder where Ed Yourdon fits into his own model... I think that a true visionary (Alan Kay, Nicholas Negroponte and Buckminster Fuller are a few who come to mind) never becomes a "conservative old fart," because s/he is never fully satisfied. New ideas and refinements of old ideas are always worth exploring. A couple of years ago, I heard Alan Kay talk about "inventing the future." He said that most people using Smalltalk have apparently "missed the point," because they don't bother replacing the class hier- archy with one of their own devising. -- William D. Gooch bill@iconcomp.com Icon Computing http://www.iconcomp.com Texas liaison for the International Programmers Guild For IPG info, see http://www.ipgnet.com/ipghome.htm ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-14 0:00 ` Robert C. Martin 1996-12-14 0:00 ` Patrick Ma 1996-12-15 0:00 ` Tansel Ersavas @ 1996-12-16 0:00 ` Karen A. Morrissey 1996-12-16 0:00 ` Bob Kettig 1996-12-17 0:00 ` David Bradley 2 siblings, 2 replies; 209+ messages in thread From: Karen A. Morrissey @ 1996-12-16 0:00 UTC (permalink / raw) Robert C. Martin wrote: > [...] > In some sense OO has attracted programmers the way that new weight > loss methods attract people who want to lose weight. They will grasp > at anything new to solve their problems. > > OO is a great technique and it can help make software easier to reuse, > modify and maintain. But it is not a cure-all; and it must be understood > in detail and weilded with skill. > [...] This reminds me of the hoopla surrounding the introduction, to the masses, of "knowledge bases" and OODBMSs. When asked about each I remarked, sounding perhaps a bit like Eeyore (the old, cynical, donkey from Winnie-the-pooh), "Great. Now there's another paradigm that everyone will use but no one will bother to learn." -- Karen A. Morrissey kxmorr4@uswest.com (USW business) US West Communications kmorris692@aol.com (other business & personal) 1801 California (on assignment from Analysts International) Suite 310 Denver, CO 80202 "Everything comes in fives." 303-965-8473 -- Hagbard Celine ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-16 0:00 ` Karen A. Morrissey @ 1996-12-16 0:00 ` Bob Kettig 1996-12-17 0:00 ` Robert Dewar 1996-12-17 0:00 ` David Bradley 1 sibling, 1 reply; 209+ messages in thread From: Bob Kettig @ 1996-12-16 0:00 UTC (permalink / raw) In article <32b6a57d.342498767@news> David Bradley, davidb@datalytics.com writes: >Jeff Miller <jmiller@probe.net> wrote: >>Why is it that >>corporations continue to build these crazy, wasteful, failure-prone >>development departments when all they really needed to do was stuff >>a couple of talented programmers in a garage for a few months? >... >...there aren't that many out there. That's at least partly because once is enough for most folks. You may climb Mt.Everest once, but you probably won't want to do it again. - Bob ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-16 0:00 ` Bob Kettig @ 1996-12-17 0:00 ` Robert Dewar 0 siblings, 0 replies; 209+ messages in thread From: Robert Dewar @ 1996-12-17 0:00 UTC (permalink / raw) Jeff Miller <jmiller@probe.net> wrote: >Why is it that >corporations continue to build these crazy, wasteful, failure-prone >development departments when all they really needed to do was stuff >a couple of talented programmers in a garage for a few months? it's a nice fantasy, but not remotely connected to reality. The domain of programs that can be attacked this way is a small fraction of real life programs. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-16 0:00 ` Karen A. Morrissey 1996-12-16 0:00 ` Bob Kettig @ 1996-12-17 0:00 ` David Bradley 1 sibling, 0 replies; 209+ messages in thread From: David Bradley @ 1996-12-17 0:00 UTC (permalink / raw) "Karen A. Morrissey" <kxmorr4@netmail.mnet.uswest.com> wrote: >This reminds me of the hoopla surrounding the introduction, to the >masses, of "knowledge bases" and OODBMSs. When asked about each I >remarked, sounding perhaps a bit like Eeyore (the old, cynical, donkey >from Winnie-the-pooh), "Great. Now there's another paradigm that >everyone will use but no one will bother to learn." So true. Unfortunately it seems that many think they can get something for nothing. -------------------------------------------- David Bradley davidb@datalytics.com Software Engineer Datalytics, Inc. http://www.datalytics.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-07 0:00 ` Steve Heller 1996-12-07 0:00 ` Tansel Ersavas @ 1996-12-09 0:00 ` Todd Hoff 1996-12-10 0:00 ` Steve Heller ` (2 more replies) 1 sibling, 3 replies; 209+ messages in thread From: Todd Hoff @ 1996-12-09 0:00 UTC (permalink / raw) Steve Heller wrote: > If I invented an electron microscope and 90% of people couldn't use > it, would we blame the electron microscope or the people? In other > words, the complexity of the job that the tool needs to do matters as > well. The analogy doesn't hold as an electron microscope is a specialized tool. OO is not supposed to be a specialized tool but a general methodology for designing and implementing software systems. > Or maybe it's just taught poorly. I've been pretty successful in > teaching OOP to people who don't know it already. Or the flip side, why is it so hard to learn? And if it really takes top teachers working over extended periods of time with individual students to learn OO what is the chance of it being taught properly in the large? ------------------------------------------------------------- tmh@possibility.com | The loyalty of small men can be http://www.possibility.com | bought cheaply, for greed has no | pride. - Michael Kube-McDowell ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-09 0:00 ` Todd Hoff @ 1996-12-10 0:00 ` Steve Heller 1996-12-10 0:00 ` Snowball queries 1996-12-12 0:00 ` Samuel S. Shuster 2 siblings, 0 replies; 209+ messages in thread From: Steve Heller @ 1996-12-10 0:00 UTC (permalink / raw) Todd Hoff <tmh@possibility.com> wrote: >Steve Heller wrote: >> If I invented an electron microscope and 90% of people couldn't use >> it, would we blame the electron microscope or the people? In other >> words, the complexity of the job that the tool needs to do matters as >> well. >The analogy doesn't hold as an electron microscope is a specialized >tool. OO is not supposed to be a specialized tool but a general >methodology for designing and implementing software systems. All programming is difficult. Programming is a specialized task, which implies the need for specialized tools. Designing good libraries is even more difficult than writing good programs, and it requires talents in addition to those needed for application programming. Therefore, library design should be done primarily by specialists. This will make the job of the application programmer easier, not harder. >> Or maybe it's just taught poorly. I've been pretty successful in >> teaching OOP to people who don't know it already. >Or the flip side, why is it so hard to learn? And if it >really takes top teachers working over extended periods >of time with individual students to learn OO what is the chance >of it being taught properly in the large? I haven't had an "extended period" to teach OO, if by that you mean more than a couple of months. Of course, the students will have to apply what they learn in the real world in order to be truly fluent with their new knowledge, but this is true of any applied field. However, the necessity for good teachers is a real constraint, since it appears that many "OO teachers" don't understand it very well themselves. Another part of the problem is poor textbooks that don't give enough background and depth so that the students can really grasp the fundamentals; I'm doing what I can to fix that. Steve Heller, author and software engineer http://ourworld.compuserve.com/homepages/steve_heller ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-09 0:00 ` Todd Hoff 1996-12-10 0:00 ` Steve Heller @ 1996-12-10 0:00 ` Snowball queries 1996-12-12 0:00 ` Samuel S. Shuster 2 siblings, 0 replies; 209+ messages in thread From: Snowball queries @ 1996-12-10 0:00 UTC (permalink / raw) Todd Hoff wrote: > Or the flip side, why is it so hard to learn? And if it > really takes top teachers working over extended periods > of time with individual students to learn OO what is the chance > of it being taught properly in the large? It is NOT hard to learn. What is hard is how to UNLEARN. I have been teaching OO for a long time and the problem IS that we have learned procedure orientation first, which interferes a lot with OO teachings. Though it is such an awkward modeling, we spend years and years learning it, then stick to it as it were the ten commandmends. I discovered that I can teach OO to children very quickly whereas sometimes it takes a considerable amount of time to initiate professionals to OO. OO is much more closer to the human thinking and reasoning process than the procedure oriented approach. Good OO teachers first explain well why procedure orientation is a historical accident, and they convince their audience as to why procedure oriented approach is in fact a terribly inefficient way of modeling large systems. Then they introduce OO. Tansel Ersavas RASE Inc. mailto:tansel@deep.net http://www.rase.com/ ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-09 0:00 ` Todd Hoff 1996-12-10 0:00 ` Steve Heller 1996-12-10 0:00 ` Snowball queries @ 1996-12-12 0:00 ` Samuel S. Shuster 1996-12-12 0:00 ` Dr. Richard Botting 1996-12-13 0:00 ` Nick Leaton 2 siblings, 2 replies; 209+ messages in thread From: Samuel S. Shuster @ 1996-12-12 0:00 UTC (permalink / raw) Todd Hoff, >OO is not supposed to be a specialized tool but a general >methodology for designing and implementing software systems. Maybe that's a problem in and of itself. Maybe OO is supposed to be a specialized tool, but has been inappropriately hyped so much that too many people think that it is supposed to be E-Z. Let's look out to the side a moment. VisualBasic. Certainly it's one of those "EveryMan" tools. But why does it fail so bad on large enterprise systems, and in particular why does it fail so bad when the system requires large groups of interacting subsystems and interaction between developers and testing and even worse for maintenance? I've got an opinion as to why. VisualBasic does not promote a disciplined approach to development. I hold that in fact it promotes a cowboy attitude. In order to get to the large system with all that goes with it with VisualBasic, one not only has to diligently apply an external discipline, one has to fight the tool in order to do so! What OT (or any methodology does) is define a discipline. Is it a general methodology? Yes. But a methodology none the less, and as such, demands that discipline be used in order to see any benefit from it. Lip service doesn't do it. Knowledge alone doesn't do it. Doing it, with rigor, is the only way. So, if OT has failed in any way, it is in not stopping the hype that allows people to perceive that OT is just some kind of E-Z solution to all their problems. Is OT a better discipline for developing large systems? I believe so, but I don't believe that this is the debate here. A better question is, has Structured/Procedural Technology failed? If we only judge by looking in the context of how the majority of procedural tools/languages are used, then in my opinion, Yes. It has failed miserably... in my further opinion, it has failed worse than OT. However, if we look and judge by when the rigor of the discipline of Structured/Procedural technology is used, then I believe it has succeeded fairly well. Further, if we look and judge Object Technology in terms of a rigor & discipline, I believe it to be successful also. Finally, we come to the comparison. When we look and judge by rigor & discipline, and then finally _add_ in effectiveness and then compare, then I believe OT is comparatively more successful. But to reiterate, this all depends, deeply, on the fact that OT isn't a belief, isn't simply the understanding of three concepts (Encapsulation, Inheritance and Polymorphism), isn't even simply the correct applying of these and related concepts. It is a discipline. It is a discipline like all other disciplines that in order to be successful must be applied. Applied rigorously. In my opinion, anything less is not Object Technology... It's the lip service of the self anointed experts whom I wouldn't trust to design my cat's upchucked hair balls... even from a fresh example. So, what's wrong with OO? What's wrong is people who think they should be able to see the structure of molecules with a High School Microscope, and are then so overwhelmed when someone says "It takes a powerful electron microscope, bub, and you'll have to learn how to use one, and apply some discipline in order to get the results you need" TANSTAAFL. The biggest problem facing the software community is the too widespread belief that Object Technology is a free lunch. And So It Goes Sames ============================================================================ sshuster@parcplace.com ParcPlace-Digitalk Consultant All opinions are my own. ============================================================================ ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-12 0:00 ` Samuel S. Shuster @ 1996-12-12 0:00 ` Dr. Richard Botting 1996-12-13 0:00 ` Nick Leaton 1 sibling, 0 replies; 209+ messages in thread From: Dr. Richard Botting @ 1996-12-12 0:00 UTC (permalink / raw) From the point of view of a hypothetical software engineer: Someone who takes a project from the user's griping thru to implementation, maintenance and a nice fee:-) Implementations of OO share a defect with a number of earlier methods and methodologies:- Optimism. By which I mean that there is no apparent part of many OO methods that signals that the problem you are trying to solve is going to be hard until it is too late. Very few methods (in any paradigm) have a step that says: Don't use this method. Whereas I have come to believe that a step like this is essential. Similarly I am suspicious of software development processes or methods (or methodologies) that don't have a step that works out prior prior to coding that the design has a high chance of satsfying the user. Performance, maintenance, usability, ...???? And so, I prefer approaches that allow one to collect and organize data about the problem... not the solution, so that I have the figures to be able to make sure my ideas will work. -- dick botting http://www.csci.csusb.edu/dick/signature.html Disclaimer: CSUSB may or may not agree with this message. Copyright(1996): Copy freely but say where it came from. I have nothing to sell, and I'm giving it away. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-12 0:00 ` Samuel S. Shuster 1996-12-12 0:00 ` Dr. Richard Botting @ 1996-12-13 0:00 ` Nick Leaton 1996-12-16 0:00 ` Samuel S. Shuster 1 sibling, 1 reply; 209+ messages in thread From: Nick Leaton @ 1996-12-13 0:00 UTC (permalink / raw) > I've got an opinion as to why. VisualBasic does not promote a disciplined > approach to development. I hold that in fact it promotes a cowboy attitude. In > order to get to the large system with all that goes with it with VisualBasic, > one not only has to diligently apply an external discipline, one has to fight > the tool in order to do so! It also fails because it is 'visual'. People think building the UI is building the system. Building a model is not the usual disciplined approach taken with VB. You can do this with VB, but I haven't seen many examples. -- Nick ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-13 0:00 ` Nick Leaton @ 1996-12-16 0:00 ` Samuel S. Shuster 1996-12-16 0:00 ` Bob Kettig ` (2 more replies) 0 siblings, 3 replies; 209+ messages in thread From: Samuel S. Shuster @ 1996-12-16 0:00 UTC (permalink / raw) Nick Leaton, >> I've got an opinion as to why. VisualBasic does not promote a disciplined >> approach to development. [ yadda-yadda-my-babble ] > >It also fails because it is 'visual'. People think building the UI is >building the system. Building a model is not the usual disciplined >approach taken with VB. You can do this with VB, but I haven't seen >many examples. Ok, but only to a point. There is nothing inherently wrong with Visual programming. Read on. There is significant problems with 99% of the tools out there that are "Visual" today. The problem is that they focus the Visual stuff totally on the "View" - User Interface. There is no Visual Application Modeling, there is no Visual Domain Modeling (well, no Dynamic stuff, just static CASE - ER Modeling BS), there is no Visual Persistence Modeling, there is no Visual Coordinator Modeling, etc. Each of these things CAN be presented with Visual tools. I worked on a project (Continuum) that was doing this. The fact that these tools don't exist commercially, doesn't in and of itself make "Visual" bad. Only the current myopic set of tools that focus on the least meaningful end of the development continuum... the User Interface. That said, yes, people think building the UI is building the system, and its not only the cart in front of the horse, it's the whole buggy before there's a road to ride it on. It is wrong, and it is promoted by almost every visual tool on the market. Because of this, Visual/Declaritive development probably won't see it's full potential. This is sad. I just don't believe that it's a fundamental problem of "Visual Development"... any more than it was a fundamental problem of the IDE tools of the previous generation. And So It Goes Sames ============================================================================ sshuster@parcplace.com ParcPlace-Digitalk Consultant All opinions are my own. ============================================================================ ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-16 0:00 ` Samuel S. Shuster @ 1996-12-16 0:00 ` Bob Kettig 1996-12-16 0:00 ` Robert Dewar 1996-12-17 0:00 ` Tansel Ersavas 1996-12-17 0:00 ` Nick Leaton 2 siblings, 1 reply; 209+ messages in thread From: Bob Kettig @ 1996-12-16 0:00 UTC (permalink / raw) In article <32B36929.12B51408@probe.net> Jeff Miller, jmiller@probe.net writes: > ... > you would be amazed at how easy it is to tear through $100 million. Reminds me of something a U.S. Senator (whose name I don't recall) once said, which is humorous, out-of-context: "A million here, a million there, and pretty soon you're talking about real money." - anon - Bob ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-16 0:00 ` Bob Kettig @ 1996-12-16 0:00 ` Robert Dewar 0 siblings, 0 replies; 209+ messages in thread From: Robert Dewar @ 1996-12-16 0:00 UTC (permalink / raw) Bob said "Reminds me of something a U.S. Senator (whose name I don't recall) once said, which is humorous, out-of-context: "A million here, a million there, and pretty soon you're talking about real money." - anon" It was Senator Everett Dirkson (I am not 100% sure of spelling) from Illinois, and the original quote is billion not million :-) ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-16 0:00 ` Samuel S. Shuster 1996-12-16 0:00 ` Bob Kettig @ 1996-12-17 0:00 ` Tansel Ersavas 1996-12-18 0:00 ` Tom Bushell 1996-12-17 0:00 ` Nick Leaton 2 siblings, 1 reply; 209+ messages in thread From: Tansel Ersavas @ 1996-12-17 0:00 UTC (permalink / raw) Samuel S. Shuster wrote: > >It also fails because it is 'visual'. People think building the UI is > >building the system. Building a model is not the usual disciplined > >approach taken with VB. You can do this with VB, but I haven't seen > >many examples. > > Ok, but only to a point. There is nothing inherently wrong with Visual > programming. Read on. There is significant problems with 99% of the tools out > there that are "Visual" today. The problem is that they focus the Visual stuff > totally on the "View" - User Interface. There is no Visual Application Modeling, > there is no Visual Domain Modeling (well, no Dynamic stuff, just static CASE - > ER Modeling BS), there is no Visual Persistence Modeling, there is no Visual > Coordinator Modeling, etc. That's quite right. The object model can be represented, as well as the existing code can be visualized with the right visual tools, and this can be very enlightening. In fact I have been using visual tools to not only program, but teach OO and Smalltalk. Have you ever seen the entire class structure of Smalltalk visually? It is quite a sight. Logical grouping to categories, viewing a small part of the class hierarcy, visually adding, deleting classes, changing the inheritence structure in your favorite notation right on the spot? These are very powerful features, and allow you to model your system, not only the UI, with the user. > The fact that these tools don't exist > commercially, This statement will not be true after we release our new OO modeling tool "Snowball Rapid Systems Engineering Tool" very soon. ... All deleted stuff, very much agreed ... > Because of this, Visual/Declaritive development probably won't see it's full > potential. This is sad. I just don't believe that it's a fundamental problem of > "Visual Development"... any more than it was a fundamental problem of the IDE > tools of the previous generation. Times are changing. We have such a tool, and we are very convinced that this is the way of future. However, our approach to the problem is quite different to most other people's approach. First of all, we didn't invent a visual programming language. What we did was to take an existing language, and create a visual layer (aka a visual editor) on top of it. This language had to be very flexible, so most of the current populer languages didn't qualify, except Smalltalk. Our approach to visual programming is to visualize the system in any of its canonical forms the developer requests instantly: class diagrams, category diagrams, std diagrams. We are also adding to this list object diagrams that are dynamically generated while your program is running, and you can use them as visual inspectors-debuggers. We use a trademark techniques that we developed to visualize the system and create source from the system we call "Instant Reverse Engineering(tm)", and "Instant Code Generation(tm)". With these techniques, the moment you draw a class on a screen, your corresponding Smalltalk class is ready. You can switch between the textual and visual views of the system within seconds, and work at the level you feel comfortable. If a class represents a window, then you can switch between the class diagram view, window design view, stm view, or source code. You can create an instance and test it at any time. You can also create documentation related to not only visual parts of the system, but for non visual parts as well. I think, we can now show people how visual programming can really bump up their productivity. It also accelerates learning, and promotes more high level thinking. Visual programming is to textual programming what is textual programming to assembly language. > And So It Goes > Sames Tansel Ersavas ----------------------------------------------------------------------- RASE Inc. Clark NJ USA Voice: (908) 396 7145 mailto:tansel@rase.com Fax: (908) 382 1383 http://www.rase.com/ ----Sufficiently advanced technology is indistinguishable from magic--- A.C. Clarke ----------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-17 0:00 ` Tansel Ersavas @ 1996-12-18 0:00 ` Tom Bushell 1996-12-18 0:00 ` Matt Kennel 1996-12-19 0:00 ` Tansel Ersavas 0 siblings, 2 replies; 209+ messages in thread From: Tom Bushell @ 1996-12-18 0:00 UTC (permalink / raw) On Tue, 17 Dec 1996 00:45:47 -0800, Tansel Ersavas <tansel@deep.net> wrote: >I think, we can now show people how visual programming can really bump >up their productivity. It also accelerates learning, and promotes more >high level thinking. Visual programming is to textual programming what >is textual programming to assembly language. Good analogy. Although this may sound like marketing hype, my exposure to _true_ visual programming tools (ie the Prograph language) leads me to believe that Tansel is not just talking through his hat. Sounds like Snowball does many of the things I've been advocating in other posts to this thread. So, when will Snowball be available? What Smalltalks does it run with? Cost? Tansel, if you need a beta tester for the MS-Windows version, keep me in mind. :-) -Tom ---------------------------------------------------------- Tom Bushell * Custom Software Development Telekinetics * Process Improvement Consulting 2653 Highway 202 * Technical Writing RR#1, Elmsdale, NS B0N 1M0 (902)632-2772 Email: tbushell@fox.nstn.ns.ca ---------------------------------------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-18 0:00 ` Tom Bushell @ 1996-12-18 0:00 ` Matt Kennel 1996-12-18 0:00 ` Tansel Ersavas ` (3 more replies) 1996-12-19 0:00 ` Tansel Ersavas 1 sibling, 4 replies; 209+ messages in thread From: Matt Kennel @ 1996-12-18 0:00 UTC (permalink / raw) Tom Bushell (tbushell@fox.nstn.ns.ca) wrote: : On Tue, 17 Dec 1996 00:45:47 -0800, Tansel Ersavas <tansel@deep.net> : wrote: : >I think, we can now show people how visual programming can really bump : >up their productivity. It also accelerates learning, and promotes more : >high level thinking. Visual programming is to textual programming what : >is textual programming to assembly language. : Good analogy. Is it really? Can a painting communicate subtle ideas as clearly as literature? : -Tom -- Matthew B. Kennel/mbk@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/ ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-18 0:00 ` Matt Kennel @ 1996-12-18 0:00 ` Tansel Ersavas 1996-12-19 0:00 ` David Bradley ` (2 subsequent siblings) 3 siblings, 0 replies; 209+ messages in thread From: Tansel Ersavas @ 1996-12-18 0:00 UTC (permalink / raw) Matt Kennel wrote: > > Tom Bushell (tbushell@fox.nstn.ns.ca) wrote: > : On Tue, 17 Dec 1996 00:45:47 -0800, Tansel Ersavas <tansel@deep.net> > : wrote: > > : >I think, we can now show people how visual programming can really bump > : >up their productivity. It also accelerates learning, and promotes more > : >high level thinking. Visual programming is to textual programming what > : >is textual programming to assembly language. > > : Good analogy. > > Is it really? Can a painting communicate subtle ideas as clearly as > literature? A picture is worth a thousand words. BTW I do not defend a total pictorial approach. There are certain things I can do faster and better in text. In fact, I still don't much use the Windows file management facilities and drop down to dos prompt (especially while no one is around). However, When I am using the right kind of visual tool, there are certain things that I can do which is definitely a higher level, where I have no hope of achieving with the same ease if I did it at the text level. For example, changing the parent class of a class, I find it quite useful to do it at a visual level. It is much easier to move the tip of an inheritance line from one class to another, and having the underlying mechanism to do all necessary checks for you, and change the class hierarchy for that class. There are many things that we can do much more faster and at a higher level with visuals, but most visual tools I found weren't practical, and limiting. You should be able to switch between text view of your program and visual view within a blink of an eye, and anything you do textually should be reflected in the visual view, and vice versa. Besides, it is much more easier to teach people visually, if it is done correctly. Once they learn it visually first, then people tend to stick to visuals. When they grasp the concepts, they can dwelve into text if they want to. Still I believe that the next generation will work predominantly with pictures and will rarely revert to bulky chunks of text, unless it is a meaningful whole. In one of our new projects, we are developing an object oriented systems development tool for children to develop their own games. This is a visual development tool, and we had great success with children with early prototypes of it. It needs a lot of work, but watching this experiment gave me the feeling that, the next generation will have an entirely different understanding of computers, languages, and programming. It is a scary feeling, but also a most enjoyable one. Tansel ----------------------------------------------------------------------- RASE Inc. Clark NJ USA Voice: (908) 396 7145 mailto:tansel@rase.com Fax: (908) 382 1383 http://www.rase.com/ ----Sufficiently advanced technology is indistinguishable from magic--- -------------------------------A.C. Clarke----------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-18 0:00 ` Matt Kennel 1996-12-18 0:00 ` Tansel Ersavas @ 1996-12-19 0:00 ` David Bradley 1996-12-20 0:00 ` Chris Brand [not found] ` <01bbee11$dcae8460$ca61e426@DCorbit.solutionsiq.com> 1996-12-19 0:00 ` Jeffrey C. Dege 1996-12-19 0:00 ` Tom Bushell 3 siblings, 2 replies; 209+ messages in thread From: David Bradley @ 1996-12-19 0:00 UTC (permalink / raw) mbk@caffeine.engr.utk.edu (Matt Kennel) wrote: >Is it really? Can a painting communicate subtle ideas as clearly as >literature? The thing that comes to my mind, is if visual is so much better then why are we still "reading" books. I'm sure visual has its advantages, but I think at best the visual would augment written programming not supplant it. -------------------------------------------- David Bradley davidb@datalytics.com Software Engineer Datalytics, Inc. http://www.datalytics.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-19 0:00 ` David Bradley @ 1996-12-20 0:00 ` Chris Brand [not found] ` <01bbee11$dcae8460$ca61e426@DCorbit.solutionsiq.com> 1 sibling, 0 replies; 209+ messages in thread From: Chris Brand @ 1996-12-20 0:00 UTC (permalink / raw) David Bradley wrote: - - mbk@caffeine.engr.utk.edu (Matt Kennel) wrote: - - >Is it really? Can a painting communicate subtle ideas as clearly as - >literature? - - The thing that comes to my mind, is if visual is so much better then - why are we still "reading" books. - Kids aren't. They're watching TV or movies. -- Chris Stating my own opinions, not those of my company. ^ permalink raw reply [flat|nested] 209+ messages in thread
[parent not found: <01bbee11$dcae8460$ca61e426@DCorbit.solutionsiq.com>]
* Re: What is wrong with OO ? [not found] ` <01bbee11$dcae8460$ca61e426@DCorbit.solutionsiq.com> @ 1996-12-23 0:00 ` David Bradley 0 siblings, 0 replies; 209+ messages in thread From: David Bradley @ 1996-12-23 0:00 UTC (permalink / raw) "Dann Corbit" <dcorbit@solutionsiq.com> wrote: >Think of an architect, designing a building. In the high level >drawing, they do not have a picture of every fastener and joint. >But somewhere, the detail will eventually be stored. True, but even at the high level there are annotations on the drawing that can not be caputured in images and are more than just comments. Thus I'd love a system where I can interact visually but be able to revert to a language when the need arose. >Back to the original subject, "What's wrong with OO?", there is >nothing wrong with Object Oriented programming. But it is not >the ultimate tool for each and every business problem. First, >you need to have an object model that fits the OO paradigm you >are using. Not all physical business problems can best be expressed >in this way (most of them can). Then you need to have someone >who knows OO techniques. There's the old lame joke about someone >who was having trouble with his chainsaw. He took it in to the >salesman to find out what the problem was. When the salesman started >it, he said, "What's that noise?" > >Know your tools. Quite true. I don't think anything is wrong OO. It's only failed for two reasons. One is lack of knowledge, the other is lack of proper design. People tend to forget that OO only makes programming easier for those who know how to use it. A poorly design OO system can be worse than a poorly design procedural system. Lack of good design results in a very brittle system. Alas no one seems to look beyond the short term. They don't want to make the investment upfront. "Just get it done". -------------------------------------------- David Bradley davidb@datalytics.com Software Engineer Datalytics, Inc. http://www.datalytics.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-18 0:00 ` Matt Kennel 1996-12-18 0:00 ` Tansel Ersavas 1996-12-19 0:00 ` David Bradley @ 1996-12-19 0:00 ` Jeffrey C. Dege 1996-12-20 0:00 ` Tom Bushell 1996-12-19 0:00 ` Tom Bushell 3 siblings, 1 reply; 209+ messages in thread From: Jeffrey C. Dege @ 1996-12-19 0:00 UTC (permalink / raw) On 18 Dec 1996 19:19:05 GMT, Matt Kennel <mbk@caffeine.engr.utk.edu> wrote: >Tom Bushell (tbushell@fox.nstn.ns.ca) wrote: >: On Tue, 17 Dec 1996 00:45:47 -0800, Tansel Ersavas <tansel@deep.net> >: wrote: >: >Visual programming is to textual programming what >: >is textual programming to assembly language. > >: Good analogy. > >Is it really? Can a painting communicate subtle ideas as clearly as >literature? Easily. Can painting communicate non-visual ideas as _precisely_ as literature? Not a chance. -- Never worry about theory as long as the machinery does what it's supposed to do. -- R. A. Heinlein ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-19 0:00 ` Jeffrey C. Dege @ 1996-12-20 0:00 ` Tom Bushell 0 siblings, 0 replies; 209+ messages in thread From: Tom Bushell @ 1996-12-20 0:00 UTC (permalink / raw) On 19 Dec 1996 06:36:05 GMT, jdege@jdege.visi.com (Jeffrey C. Dege) wrote: >>Is it really? Can a painting communicate subtle ideas as clearly as >>literature? > >Easily. Can painting communicate non-visual ideas as _precisely_ as >literature? Not a chance. "How is a raven like a writing desk?" -The Mad Hatter My whole point here is to grope towards better ways to think about and represent software systems. Do I think a software system is like a painting? No. Do I think a software system is like a novel or other work of literature, designed to be read from start to finish? No. Do you? Do I think a software system is like a technical document or user's manual - highly structured, and designed to be read non-linearly? Sort of. Do I think a software system is like an electronic schematic - emphasizing connection and flow - in parallel? You betcha! ;-) -Tom ---------------------------------------------------------- Tom Bushell * Custom Software Development Telekinetics * Process Improvement Consulting 2653 Highway 202 * Technical Writing RR#1, Elmsdale, NS B0N 1M0 (902)632-2772 Email: tbushell@fox.nstn.ns.ca ---------------------------------------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-18 0:00 ` Matt Kennel ` (2 preceding siblings ...) 1996-12-19 0:00 ` Jeffrey C. Dege @ 1996-12-19 0:00 ` Tom Bushell 1996-12-23 0:00 ` David Bradley 3 siblings, 1 reply; 209+ messages in thread From: Tom Bushell @ 1996-12-19 0:00 UTC (permalink / raw) On 18 Dec 1996 19:19:05 GMT, mbk@caffeine.engr.utk.edu (Matt Kennel) wrote: >: >Visual programming is to textual programming what >: >is textual programming to assembly language. > >: Good analogy. > >Is it really? Can a painting communicate subtle ideas as clearly as >literature? Sometimes more clearly, and more efficiently - although perhaps the ideas are less verbal. Think of the Mona Lisa's smile, Alanis Morrissette's expression in her videos, the sense of grandeur and isolation you often get from a single shot in a Kubrick movie... I think this is an artistic analogy, and I'm more comfortable with engineering analogies for software development (though I don't deny that there's a strong element of craft or art in SW development when practiced well). Most other engineering disciplines use visual representations as fundamental tools. Civil engineers use blueprints, electrical engineers use schematics, and so on. IME, a good diagram _is_ worth a thousand words. (Unfortunately, I haven't seen many good diagrams for SW systems.) The main benefits I see are quickly conveying larger scale structure, and connections and relationships among system components. Text is too linear to convey this sort of information well, although text is a necessary adjunct to most diagrams. I basicly agree with Tansel - programming will become much more visual in the medium term future. Text will still be required, but mainly for commenting, not for code. What makes a good diagram is a fascinating subject, but way off topic for this thread. I'm starting a new one on comp.object and comp.software-eng, if anyone's interested. -Tom ---------------------------------------------------------- Tom Bushell * Custom Software Development Telekinetics * Process Improvement Consulting 2653 Highway 202 * Technical Writing RR#1, Elmsdale, NS B0N 1M0 (902)632-2772 Email: tbushell@fox.nstn.ns.ca ---------------------------------------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-19 0:00 ` Tom Bushell @ 1996-12-23 0:00 ` David Bradley 1996-12-23 0:00 ` Jeffrey C. Dege 0 siblings, 1 reply; 209+ messages in thread From: David Bradley @ 1996-12-23 0:00 UTC (permalink / raw) tbushell@fox.nstn.ns.ca (Tom Bushell) wrote: >I basicly agree with Tansel - programming will become much more visual >in the medium term future. Text will still be required, but mainly >for commenting, not for code. I think it will be more a combination of both. Its easier to manage relationships and interactions visually, but its easier to describe the objects in text. However, I don't think such a solid line should be drawn there. Sometimes it may be easier to describe a relationship than to draw it. I also know some people work better with one or the other. -------------------------------------------- David Bradley davidb@datalytics.com Software Engineer Datalytics, Inc. http://www.datalytics.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-23 0:00 ` David Bradley @ 1996-12-23 0:00 ` Jeffrey C. Dege 0 siblings, 0 replies; 209+ messages in thread From: Jeffrey C. Dege @ 1996-12-23 0:00 UTC (permalink / raw) On Mon, 23 Dec 1996 13:11:46 GMT, David Bradley <davidb@datalytics.com> wrote: >tbushell@fox.nstn.ns.ca (Tom Bushell) wrote: > >>I basicly agree with Tansel - programming will become much more visual >>in the medium term future. Text will still be required, but mainly >>for commenting, not for code. > >I think it will be more a combination of both. Its easier to manage >relationships and interactions visually, but its easier to describe >the objects in text. However, I don't think such a solid line should >be drawn there. Sometimes it may be easier to describe a relationship >than to draw it. I also know some people work better with one or the >other. Personnally, I will limit my use of visual programming tools until they provide merge and diff tools. I need to be able to tell what has been changed between versions 2.3B and 2.3D and I need to be able to merge those changes into the trunk in a semi-automated fashion. Supporting old releases, or providing several versions of the current current release customized for particular clients is not at all unusual. Combine that with a system comprising >2000 classes and you have a system that _cannot_ be managed without automatic differencing tools. There are fairly good diff and merge tools available for text files, and textual programming languages can take advantage of them. I've seen some graphical tools store their output in a text format that could be merged by textual tools with some success, but not many. I've seen many graphical tools that provided no method for comparing different versions of a file, and these are, IMO, suitable only for one-off, throw-away systems. -- Never worry about theory as long as the machinery does what it's supposed to do. -- R. A. Heinlein ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-18 0:00 ` Tom Bushell 1996-12-18 0:00 ` Matt Kennel @ 1996-12-19 0:00 ` Tansel Ersavas 1996-12-27 0:00 ` clovis 1 sibling, 1 reply; 209+ messages in thread From: Tansel Ersavas @ 1996-12-19 0:00 UTC (permalink / raw) To: Tom Bushell Tom Bushell wrote: > > On Tue, 17 Dec 1996 00:45:47 -0800, Tansel Ersavas <tansel@deep.net> > wrote: > > >I think, we can now show people how visual programming can really bump > >up their productivity. It also accelerates learning, and promotes more > >high level thinking. Visual programming is to textual programming what > >is textual programming to assembly language. > > Good analogy. Although this may sound like marketing hype, my > exposure to _true_ visual programming tools (ie the Prograph language) > leads me to believe that Tansel is not just talking through his hat. > Sounds like Snowball does many of the things I've been advocating in > other posts to this thread. We are glad to see our ideas are shared by professionals. I personally believe in visual programming, even though I am still a command-line person from time to time, especially in Unix. But with the right tool, even if we don't spend the majority of our time in the tool, we can achieve a lot, as I observed it in the case with Snowball. I also find it very useful as a documentation tool. In many projects, even though documentation is kept in high $$ CASE tools, it is practically impossible to reverse engineer the entire system and regenerate the document every time documentation is required. Snowball generates this documentation every time directly from the source, because Smalltalk is used as a specification and a repository for all the documentation information. So it is very useful even for people who won't do any visual programming, but want to have access to the visual views of their system at any time on demand, such as presentations. Most visual tools limit us do things their own way. They look nice in demos, but when we start using them in real life, we feel limited. That is one of the issue we wanted to address clearly in Snowball. We wanted Snowball to be a non-intrusive tool. When it is invoked, Snowball will understand your work without forcing you to any special format, or restrictions. It is available within a matter of seconds, and after you have made your changes, or even while you are doing changes, you can return to the Smalltalk environment and do what you want there. > So, when will Snowball be available? What Smalltalks does it run > with? Cost? Snowball Rapid Systems Engineering Tool is currently available for purchase from our site for VSE only. We do not promote it as yet, because we are waiting on some non-technical issues to be resolved. We will announce it either late December, or very early January. We plan to come out with ST/V STExpress version, followed by IBM VA, and VW. Costwise, we are determined to keep it as down as possible. Our aim is to make Snowball available to every OO enthusiast at a reasonable price. Our current target is for most versions, the basic edition without source should be under $200, and the developers edition with source and meta-tools for developing your own extensions-graphical notations with extensive documentation should be under $600. If we can release a STExpress edition, we want to keep it under $100. > Tansel, if you need a beta tester for the MS-Windows version, keep me > in mind. :-) We will certainly do that, Tom. I'll contact you via e-mail after the new year's day. > -Tom Tansel Ersavas Designer and Developer of Snowball Rapid Systems Engineering Tool ----------------------------------------------------------------------- RASE Inc. Clark NJ USA Voice: (908) 396 7145 mailto:tansel@rase.com Fax: (908) 382 1383 http://www.rase.com/ ----Sufficiently advanced technology is indistinguishable from magic--- -------------------------------A.C. Clarke----------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-19 0:00 ` Tansel Ersavas @ 1996-12-27 0:00 ` clovis 0 siblings, 0 replies; 209+ messages in thread From: clovis @ 1996-12-27 0:00 UTC (permalink / raw) In <32B9607F.470B@rase.com>, Tansel Ersavas <tansel@rase.com> writes: >We are glad to see our ideas are shared by professionals. I personally >believe in visual programming, even though I am still a command-line >person from time to time, especially in Unix. But with the right tool, >even if we don't spend the majority of our time in the tool, we can >achieve a lot, as I observed it in the case with Snowball. I also find >it very useful as a documentation tool. In many projects, even though >documentation is kept in high $$ CASE tools, it is practically >impossible to reverse engineer the entire system and regenerate the >document every time documentation is required. Snowball generates this >documentation every time directly from the source, because Smalltalk is >used as a specification and a repository for all the documentation >information. So it is very useful even for people who won't do any >visual programming, but want to have access to the visual views of their >system at any time on demand, such as presentations. Sounds interesting. I'll be interested in seeing it when it arrives. VisualAge from IBM is good, but in certain respects, especially as based on ENVY Smalltalk, it is very limiting. I'd personally prefer something more towards the VisualWorks model. This is a VERY visible system, even though I'm current tied to IBM's stuff in my current project. >Most visual tools limit us do things their own way. They look nice in >demos, but when we start using them in real life, we feel limited. That >is one of the issue we wanted to address clearly in Snowball. We wanted >Snowball to be a non-intrusive tool. When it is invoked, Snowball will >understand your work without forcing you to any special format, or >restrictions. It is available within a matter of seconds, and after you >have made your changes, or even while you are doing changes, you can >return to the Smalltalk environment and do what you want there. I hope this is true! If so, you are pushing things a great step foward. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-16 0:00 ` Samuel S. Shuster 1996-12-16 0:00 ` Bob Kettig 1996-12-17 0:00 ` Tansel Ersavas @ 1996-12-17 0:00 ` Nick Leaton 2 siblings, 0 replies; 209+ messages in thread From: Nick Leaton @ 1996-12-17 0:00 UTC (permalink / raw) Samuel S. Shuster wrote: > >> I've got an opinion as to why. VisualBasic does not promote a disciplined > >> approach to development. [ yadda-yadda-my-babble ] > > > >It also fails because it is 'visual'. People think building the UI is > >building the system. Building a model is not the usual disciplined > >approach taken with VB. You can do this with VB, but I haven't seen > >many examples. > > Ok, but only to a point. There is nothing inherently wrong with Visual > programming. Read on. There is significant problems with 99% of the tools out > there that are "Visual" today. The problem is that they focus the Visual stuff > totally on the "View" - User Interface. There is no Visual Application Modeling, > there is no Visual Domain Modeling (well, no Dynamic stuff, just static CASE - > ER Modeling BS), there is no Visual Persistence Modeling, there is no Visual > Coordinator Modeling, etc. > > Each of these things CAN be presented with Visual tools. I worked on a project > (Continuum) that was doing this. The fact that these tools don't exist > commercially, doesn't in and of itself make "Visual" bad. Only the current > myopic set of tools that focus on the least meaningful end of the development > continuum... the User Interface. > > That said, yes, people think building the UI is building the system, and its > not only the cart in front of the horse, it's the whole buggy before there's a > road to ride it on. It is wrong, and it is promoted by almost every visual tool > on the market. > > Because of this, Visual/Declaritive development probably won't see it's full > potential. This is sad. I just don't believe that it's a fundamental problem of > "Visual Development"... any more than it was a fundamental problem of the IDE > tools of the previous generation. > And So It Goes I agree, I think you can produce good systems with VB. However you need to use VB to produce top quality objects that then get used in different ways. In a bank there should be a counterparty object, that you can use to select counterparties, input them if you have the right etc. However everybody I have seen doing VB writes there own screens to do this, with SQL or otherwise interacting with the DB. More coordination would help but in a RAD environment, it tends to go out of the window. -- Nick ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-06 0:00 ` Todd Hoff 1996-12-07 0:00 ` Steve Heller @ 1996-12-07 0:00 ` Nick Thurn 1996-12-14 0:00 ` Robert C. Martin 1996-12-15 0:00 ` Damon Feldman 2 siblings, 1 reply; 209+ messages in thread From: Nick Thurn @ 1996-12-07 0:00 UTC (permalink / raw) Todd Hoff wrote: > > If i invented a hammer and 90% of people couldn't use > it correctly would we blame the hammer or the people? > It seems those who've "got" OO blame the people. Maybe we > should blame the hammer. Maybe OO just won't work in > the mass market of building applications. Not that it > can't, but that it doesn't work often enough to make it > universally appropriate. > Todd, I think it is the expectations placed on the people. Michaelangelo user a hammer and chisel to produce great art. I use it to bang a hole in my kitchen wall. If I expected great art I would be disappointed. The expectation that *all* those who use OO should be producing reusable, high quality stuff is false however it appears IME to be (or at least have been initially) the case. For the "average" programmer OO should be mainly using not creating. Of course it's chicken and egg, something must be created to be reused. cheers Nick (my opinions only) "If I had a hammer, I'd hammer in the ...." > ------------------------------------------------------------- > tmh@possibility.com | The loyalty of small men can be > http://www.possibility.com | bought cheaply, for greed has no > | pride. - Michael Kube-McDowell ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-07 0:00 ` Nick Thurn @ 1996-12-14 0:00 ` Robert C. Martin 1996-12-15 0:00 ` Todd Hoff 0 siblings, 1 reply; 209+ messages in thread From: Robert C. Martin @ 1996-12-14 0:00 UTC (permalink / raw) > Todd Hoff wrote: > > > > If i invented a hammer and 90% of people couldn't use > > it correctly would we blame the hammer or the people? > > It seems those who've "got" OO blame the people. Maybe we > > should blame the hammer. Maybe OO just won't work in > > the mass market of building applications. Not that it > > can't, but that it doesn't work often enough to make it > > universally appropriate. I think this depends upon your expectations. If you expect that OO is the solution to the so called "software crisis" that will make all software projects fast and simple, and eliminate all major bugs; if you expect that OO will allow junior engineers to rapdily gain the skills of experienced designers; if you think that older styles of software are completely obsolesced by the far superior technology of OO; then you will certainly be disapponted. OO does not meet those expectations. However, if you expect that you can use the technology of OO as a tool to help you manage the interdependencies between software modules in order to make software architectures that are reusable, resilient, and maintainable; then you will probably not be dissapointed. -- Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (847) 918-1004 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-14 0:00 ` Robert C. Martin @ 1996-12-15 0:00 ` Todd Hoff 1996-12-15 0:00 ` Joseph W. Seda ` (2 more replies) 0 siblings, 3 replies; 209+ messages in thread From: Todd Hoff @ 1996-12-15 0:00 UTC (permalink / raw) Robert C. Martin wrote: > However, if you expect that you can use the technology of OO as a tool > to help you manage the interdependencies between software modules in > order to make software architectures that are reusable, resilient, and > maintainable; then you will probably not be dissapointed. I expect a largish group of diverce yet intelligent people to effectively deploy OO*. So far i have not seen this to be the case. ------------------------------------------------------------- tmh@possibility.com | The loyalty of small men can be http://www.possibility.com | bought cheaply, for greed has no | pride. - Michael Kube-McDowell ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-15 0:00 ` Todd Hoff @ 1996-12-15 0:00 ` Joseph W. Seda 1996-12-16 0:00 ` David Bradley 1996-12-19 0:00 ` Robert I. Eachus 2 siblings, 0 replies; 209+ messages in thread From: Joseph W. Seda @ 1996-12-15 0:00 UTC (permalink / raw) Todd Hoff wrote: > > I expect a largish group of diverce yet intelligent people > to effectively deploy OO*. So far i have not seen this to be > the case. > This means that the market is FAR from saturated. All the better for my company. :) ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-15 0:00 ` Todd Hoff 1996-12-15 0:00 ` Joseph W. Seda @ 1996-12-16 0:00 ` David Bradley 1996-12-19 0:00 ` Robert I. Eachus 2 siblings, 0 replies; 209+ messages in thread From: David Bradley @ 1996-12-16 0:00 UTC (permalink / raw) Todd Hoff <tmh@possibility.com> wrote: >I expect a largish group of diverce yet intelligent people >to effectively deploy OO*. So far i have not seen this to be >the case. What, that a large group of intelligent people are unable to "deploy OO" or that a large group of intelligent people were used to deploy OO? -------------------------------------------- David Bradley davidb@datalytics.com Software Engineer Datalytics, Inc. http://www.datalytics.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-15 0:00 ` Todd Hoff 1996-12-15 0:00 ` Joseph W. Seda 1996-12-16 0:00 ` David Bradley @ 1996-12-19 0:00 ` Robert I. Eachus 2 siblings, 0 replies; 209+ messages in thread From: Robert I. Eachus @ 1996-12-19 0:00 UTC (permalink / raw) In article <01bbec0b$03cb9690$1e8c71a5@dhoossr> "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes: > It was Senator Everett Dirkson (I am not 100% sure of spelling) from > Illinois, and the original quote is billion not million :-) Actually, the original was, "A hundred million here, a hundred million there.." I believe he said it during a debate about expressing the federal budget resolution to the nearest hundred million instead of the nearest $10,000. (For those not familar with the details of US government budgeting, the budget bill is where most of the infighting takes place, but the appropriations bills actually parcel out the money.) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-06 0:00 ` Todd Hoff 1996-12-07 0:00 ` Steve Heller 1996-12-07 0:00 ` Nick Thurn @ 1996-12-15 0:00 ` Damon Feldman 2 siblings, 0 replies; 209+ messages in thread From: Damon Feldman @ 1996-12-15 0:00 UTC (permalink / raw) tmh@possibility.com wrote: >Daniel Drasin wrote: >> > >> The problems I've seen with OO projects arise not from the use of OO, >> but from the misuse of OO. Programmers trying to use non-OO methods, >> incorrectly applying OO concepts, etc. >If i invented a hammer and 90% of people couldn't use >it correctly would we blame the hammer or the people? >It seems those who've "got" OO blame the people Programming is a technichal discipline and you've got to know what you're doing. By the 90% rule computers themselves would be considered useless. It's just that all of us here know how to use them. The question is whether or not spending time teaching OO properly and then applying that knowledge is effective or not. The fact that people don't use OO properly when they have inadequate training can't legitamately be used to disparage OO. Damon ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Daniel Drasin ` (2 preceding siblings ...) 1996-12-06 0:00 ` Todd Hoff @ 1996-12-13 0:00 ` drush 1996-12-18 0:00 ` Matt Austern ` (9 subsequent siblings) 13 siblings, 0 replies; 209+ messages in thread From: drush @ 1996-12-13 0:00 UTC (permalink / raw) ObOOPSelfCongratulation: I'm finding this thread to be *very* interesting. Thanks, everyone. Samuel Shuster wrote: > However, if we look and judge by when the rigor of the discipline of >Structured/Procedural technology is used, then I believe it has succeeded >fairly well. > I'm glad to see someone else saying this for a change. Good programming practices don't change just because the technology changes. Using smalltalk (your-OOPL-here) means that you don't spend as much time implementing the infrastructure used to support good practices. Or it should. > Further, if we look and judge Object Technology in terms of a rigor & >discipline, I believe it to be successful also. > No argument here. (the preceding sentence was included as flame-proofing material.) >the lip service of the self anointed experts whom I wouldn't trust to >design my cat's upchucked hair balls... even from a fresh example. Please, don't hold back. Tell us how you *really* feel. I *like* object gurus. On toast. > TANSTAAFL. The biggest problem facing the software community is the too >widespread belief that Object Technology is a free lunch. Damn straight. I'm really sick of this industry's tendency to look for "silver bullets." Good code for a big problem takes time to develop. ObWorry: Are patterns going to turn into the next silver bullet buzzword? I hope not. But I do find them useful for speeding the discussion of design ideas. <twitter, mumble, blecch> (Smalltalkin') david rush mailto:kumo@intercenter.net flamesto:/dev/null I bill $100/min for reading commercial email ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Daniel Drasin ` (3 preceding siblings ...) 1996-12-13 0:00 ` drush @ 1996-12-18 0:00 ` Matt Austern 1996-12-19 0:00 ` Risto Lankinen 1996-12-20 0:00 ` Tansel Ersavas ` (8 subsequent siblings) 13 siblings, 1 reply; 209+ messages in thread From: Matt Austern @ 1996-12-18 0:00 UTC (permalink / raw) Tansel Ersavas <tansel@rase.com> writes: > > Is it really? Can a painting communicate subtle ideas as clearly as > > literature? > > A picture is worth a thousand words. Literally so? In that case, that suggests an interesting challenge. The article I'm replying to, <32B89D8D.7999@rase.com>, consists of 552 words. That figure includes some initial praise of visual programming, Matt Kennel's skeptical question about the ability of a painting to communicate subtle ideas, and a response defending visual programming in some detail. (And actually, 552 is probably an overestimate: I used wc to get that number, and it includes the header lines and the .sig file.) So is a picture worth five hundred words? Can someone come up with a picture that says the same things that this 552 word article does? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-18 0:00 ` Matt Austern @ 1996-12-19 0:00 ` Risto Lankinen 0 siblings, 0 replies; 209+ messages in thread From: Risto Lankinen @ 1996-12-19 0:00 UTC (permalink / raw) Hi! Matt Austern <austern@isolde.mti.sgi.com> wrote in article <fxtohfrfpkk.fsf@isolde.mti.sgi.com>... > Tansel Ersavas <tansel@rase.com> writes: > > > > Is it really? Can a painting communicate subtle ideas as clearly as > > > literature? > > > > A picture is worth a thousand words. > > So is a picture worth five hundred words? Can someone come up with a > picture that says the same things that this 552 word article does? Of course no one can. Put another way, someone might say... "A high level language statement is worth ten machine instructions" ... and still not be able to represent most given ten machine instructions in a single statement of any HLL (if at all). terv: Risto ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Daniel Drasin ` (4 preceding siblings ...) 1996-12-18 0:00 ` Matt Austern @ 1996-12-20 0:00 ` Tansel Ersavas 1996-12-20 0:00 ` Bill Gooch ` (7 subsequent siblings) 13 siblings, 0 replies; 209+ messages in thread From: Tansel Ersavas @ 1996-12-20 0:00 UTC (permalink / raw) Jon S Anthony wrote: > > > Can a painting communicate subtle ideas as clearly as literature? > > In general, no. Also, they don't convey abstract ideas too well > either. > > And it is a well known problem that it is rather difficult to convey > information consisting of many dimensions (facets) visually that does > not lose semantic content. 3D even 4D, not too much a problem. > 100-D? Infinite-D? How about transfinite? These are all more or > less trivial to capture algebraically. > > /Jon Well, that explains the popularity of algebra around circles. We use canonical forms of systems to get only the "relevant" information about that system for our certain needs. Nobody is talking about representing the entire information in one diagram, or even representing entire systems with only diagrams. However, I will not debate the usefulness of diagrams. It is trivial dealing with 10,000 lines of code, but if you have a million lines of code, you have no other way but summarize some of the information into some diagrams if you want to communicate them effectively. (Unless of course, you want to stuff them into 100-D matrixes). Tansel ----------------------------------------------------------------------- RASE Inc. Clark NJ USA Voice: (908) 396 7145 mailto:tansel@rase.com Fax: (908) 382 1383 http://www.rase.com/ ----Sufficiently advanced technology is indistinguishable from magic--- A.C. Clarke ----------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Daniel Drasin ` (5 preceding siblings ...) 1996-12-20 0:00 ` Tansel Ersavas @ 1996-12-20 0:00 ` Bill Gooch 1996-12-20 0:00 ` Jon S Anthony ` (6 subsequent siblings) 13 siblings, 0 replies; 209+ messages in thread From: Bill Gooch @ 1996-12-20 0:00 UTC (permalink / raw) Jon S Anthony wrote: > > Give me a single picture > that conveys the total information caught by "mountain". Easy - I have lots of mountain pictures. Any one will do. > Hmmmm, do you really think any attempt you try to provide for my first > question will be any where near as light weight as "mountain"??????? The word "mountain" *by itself* conveys nothing whatsoever. Its meaning is known via a learned association, which is not inherent in the word itself. It could just as well mean "a small furry animal with a pink nose," if we chose to use it that way. A picture of a mountain, OTOH, needs no definition, and carries a lot more than just the generic concept "mountain" with it - it shows the specific shape and character of a particular mountain, i.e. it has a much more refined meaning than the word, or quite a large verbal description, for that matter. Try to describe the geometry and terrain detail shown in the picture verbally, and it will no doubt take quite a few thousand words. None of this has much bearing on the use of diagrammatic object models for OO analysis and design, however. Those models are of abstractions, and have no "natural" interpretation by themselves. Like words, their meanings must be defined. Still, a few graphic symbols put together can often carry the same meaning as quite a few words. IME, both the diagrams and the words that describe them (especially in terms of object dynamics, which are very hard to show using static graphics) can be very helpful. -- William D. Gooch bill@iconcomp.com Icon Computing http://www.iconcomp.com Texas liaison for the International Programmers Guild For IPG info, see http://www.ipgnet.com/ipghome.htm ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Daniel Drasin ` (6 preceding siblings ...) 1996-12-20 0:00 ` Bill Gooch @ 1996-12-20 0:00 ` Jon S Anthony 1996-12-20 0:00 ` Jon S Anthony ` (5 subsequent siblings) 13 siblings, 0 replies; 209+ messages in thread From: Jon S Anthony @ 1996-12-20 0:00 UTC (permalink / raw) In article <599g39$l5v@gaia.ns.utk.edu> mbk@caffeine.engr.utk.edu (Matt Kennel) writes: > Tom Bushell (tbushell@fox.nstn.ns.ca) wrote: > : On Tue, 17 Dec 1996 00:45:47 -0800, Tansel Ersavas <tansel@deep.net> > : wrote: > > : >I think, we can now show people how visual programming can really bump > : >up their productivity. It also accelerates learning, and promotes more > : >high level thinking. Visual programming is to textual programming what > : >is textual programming to assembly language. > > : Good analogy. > > Is it really? Typically, no. > Can a painting communicate subtle ideas as clearly as literature? In general, no. Also, they don't convey abstract ideas too well either. And it is a well known problem that it is rather difficult to convey information consisting of many dimensions (facets) visually that does not lose semantic content. 3D even 4D, not too much a problem. 100-D? Infinite-D? How about transfinite? These are all more or less trivial to capture algebraically. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Daniel Drasin ` (7 preceding siblings ...) 1996-12-20 0:00 ` Jon S Anthony @ 1996-12-20 0:00 ` Jon S Anthony 1996-12-20 0:00 ` Tansel Ersavas ` (4 subsequent siblings) 13 siblings, 0 replies; 209+ messages in thread From: Jon S Anthony @ 1996-12-20 0:00 UTC (permalink / raw) In article <32B89D8D.7999@rase.com> Tansel Ersavas <tansel@rase.com> writes: > A picture is worth a thousand words. A cliche with only limited basis in reality. Give me a single picture that conveys the total information caught by "mountain". > Besides, it is much more easier to teach people visually, if it is done It is well known that this depends on the cognitive bias of the person. A cut with an ax taxonomy would start with "geometers" and "algebraists" > Still I believe that the next generation will work predominantly with > pictures and will rarely revert to bulky chunks of text Hmmmm, do you really think any attempt you try to provide for my first question will be any where near as light weight as "mountain"??????? Take a look at the "byte-size" of even the simplest graphic in any representation you care to and compare it to a "corresponding textual description". /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Daniel Drasin ` (8 preceding siblings ...) 1996-12-20 0:00 ` Jon S Anthony @ 1996-12-20 0:00 ` Tansel Ersavas 1996-12-26 0:00 ` What sells IT (was: What is wrong with OO ?) Cameron Laird 1996-12-23 0:00 ` What is wrong with OO ? Jon S Anthony ` (3 subsequent siblings) 13 siblings, 1 reply; 209+ messages in thread From: Tansel Ersavas @ 1996-12-20 0:00 UTC (permalink / raw) Jon S Anthony wrote: > > > Still I believe that the next generation will work predominantly with > > pictures and will rarely revert to bulky chunks of text > > Hmmmm, do you really think any attempt you try to provide for my first > question will be any where near as light weight as "mountain"??????? > Take a look at the "byte-size" of even the simplest graphic in any > representation you care to and compare it to a "corresponding textual > description". I remember similar discussions that took place when GUIs were first introduced. However, it didn't change the fact that GUI dominated. When CERN fist introduced the text based ancestor of Mosaic, it didn't really motivate any users to participate until the hyper-media concept was introduced. Rest is history. It is not the hyper-link concept that started the web-mania. This was around before. It is the ability to combine text, sound and images together to offer a whole. Same things will happen, in fact already happening in the systems development area. The first examples mostly suck, but they will be better, and will eventually dominate. One should also remember that text is a visual represenatation as well. We have nice little icons that represent letters. So it is just one way of pictorial representation. It is a fascinating evolution how we ended up with text, and I enjoy reading about how iconic languages became textual ones. This subject is very deep, and would start several threads, so I'll keep quiet about it now. I don't think that we can justify the graphical craze in measurable terms such as of ease of use, or or ease of learning. Indeed, when the icon based file interface first introduced in Lisa, there were a series of tests with users about the ease of learning of this new approach. To many people's surprise they didn't turn out to be faster to learn than the other concepts when they were first introduced. Even error rates came about the same. What was different, though, people's enjoyment of the "little pictures" as they defined it. This enjoyment in turn promoted wider use, and indirectly more efficient learning. Pictures are sexier. They can immediately grab our attention. BTW I also sometimes watch with worry as GUIS dominate, because they disadvantage one group of people, namely blind people. To the blind, text is as meaningless as pictures unless it is converted to sound or braille. However text can be converted to either of these mediums easily, while GUIs can not be. The ideal solution is to keep the development model independent of its views, and show it to people who want to view it in text as text, pictures as pictures, or sound, and any other views imaginable, and that lies in the core of some new systems we are developing. Tansel ----------------------------------------------------------------------- RASE Inc. Clark NJ USA Voice: (908) 396 7145 mailto:tansel@rase.com Fax: (908) 382 1383 http://www.rase.com/ ----Sufficiently advanced technology is indistinguishable from magic--- -------------------------------A.C. Clarke----------------------------- ^ permalink raw reply [flat|nested] 209+ messages in thread
* What sells IT (was: What is wrong with OO ?) 1996-12-20 0:00 ` Tansel Ersavas @ 1996-12-26 0:00 ` Cameron Laird 0 siblings, 0 replies; 209+ messages in thread From: Cameron Laird @ 1996-12-26 0:00 UTC (permalink / raw) In article <32BB2C13.A38@rase.com>, Tansel Ersavas <tansel@rase.com> wrote: . . . >introduced. However, it didn't change the fact that GUI dominated. When >CERN fist introduced the text based ancestor of Mosaic, it didn't really >motivate any users to participate until the hyper-media concept was >introduced. Rest is history. It is not the hyper-link concept that . . . It motivated me. 'Still does. I don't know whether individual experience affects your larger argument, but I've been a WWW enthusi- ast from early on, and I still use lynx at least one order of magnitude more than any other browser. The sights-and-sounds dimen- sion of WWW generally leaves me cold. I've severely trimmed follow-ups. -- Cameron Laird http://starbase.neosoft.com/~claird/home.html claird@NeoSoft.com +1 713 623 8000 #227 +1 713 996 8546 FAX ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Daniel Drasin ` (9 preceding siblings ...) 1996-12-20 0:00 ` Tansel Ersavas @ 1996-12-23 0:00 ` Jon S Anthony 1996-12-23 0:00 ` Jon S Anthony ` (2 subsequent siblings) 13 siblings, 0 replies; 209+ messages in thread From: Jon S Anthony @ 1996-12-23 0:00 UTC (permalink / raw) In article <32BB2C13.A38@rase.com> Tansel Ersavas <tansel@rase.com> writes: > Jon S Anthony wrote: > > > > > Still I believe that the next generation will work predominantly with > > > pictures and will rarely revert to bulky chunks of text > > > > Hmmmm, do you really think any attempt you try to provide for my first > > question will be any where near as light weight as "mountain"??????? > > Take a look at the "byte-size" of even the simplest graphic in any > > representation you care to and compare it to a "corresponding textual > > description". > > I remember similar discussions that took place when GUIs were first > introduced. However, it didn't change the fact that GUI dominated. When True, but irrelevant. Your point was that pictures were less "bulky" than text. That is simply untrue. > CERN fist introduced the text based ancestor of Mosaic, it didn't really > motivate any users to participate until the hyper-media concept was Sure, everyone understands that flash sells. > will happen, in fact already happening in the systems development area. > The first examples mostly suck, but they will be better, and will > eventually dominate. They may, but they will be bulky and resource intensive. It is interesting to note that in general you can get most of the "useful" information content of the Web with somethin like Lynx which is very very light weight. Netscape and other such browsers are very heavy weight. And they don't offer a lot of real value added. At least not yet. Perhaps they will. > One should also remember that text is a visual represenatation as well. > We have nice little icons that represent letters. So it is just one way > of pictorial representation. It is a fascinating evolution how we ended Fine, using this argument it is easy to say that pictures are text (especially when you consider pictograms and hieroglyphs). So, now you've managed to remove any content from the discussion. > of tests with users about the ease of learning of this new approach. To > many people's surprise they didn't turn out to be faster to learn than > the other concepts when they were first introduced. Even error rates > came about the same. What was different, though, people's enjoyment of > the "little pictures" as they defined it. This enjoyment in turn This is not particularly surprising. The same thing can be said, at a finer granularity, about embedded formating text processors and WYSIWYG. > promoted wider use, and indirectly more efficient learning. Pictures are > sexier. They can immediately grab our attention. This is clearly true. At least for the majority of people. It is also rather uninteresting as it is boringly obvious. Just look at what is more popular: TV or books. Also, just look at what has more content: Books or TV. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Daniel Drasin ` (10 preceding siblings ...) 1996-12-23 0:00 ` What is wrong with OO ? Jon S Anthony @ 1996-12-23 0:00 ` Jon S Anthony 1996-12-26 0:00 ` drush 1996-12-26 0:00 ` drush 13 siblings, 0 replies; 209+ messages in thread From: Jon S Anthony @ 1996-12-23 0:00 UTC (permalink / raw) In article <32BB2C3D.68CB@rase.com> Tansel Ersavas <tansel@rase.com> writes: > that system for our certain needs. Nobody is talking about representing > the entire information in one diagram, or even representing entire > systems with only diagrams. However, I will not debate the usefulness of > diagrams. Diagrams are cleary useful and sometimes basically essential. The same thing can be said about textual representation. > It is trivial dealing with 10,000 lines of code, but if you have a > million lines of code, you have no other way but summarize some of > the information into some diagrams if you want to communicate them > effectively. (Unless of course, you want to stuff them into 100-D > matrixes). It is not obvious how diagrams would communicate this _abstraction_ significantly more effectively than a corresponding reduction utilizing text symbols. The key isn't necessarily a diagram it is the abstraction. Whether communicated via a picture or textual symbols, or for that matter a set of sounds or texture or what have you. Mathematics has done this sort of thing for millenia. At the end of the day, nothing that's been said here or in the many other places I've read and examined on this subject, is in any way convincing that diagrams, by their nature, somehow capture and/or communicate concepts in a way that is somehow so intuitive that you can ken the information merely by taking a quick look or something. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Daniel Drasin ` (11 preceding siblings ...) 1996-12-23 0:00 ` Jon S Anthony @ 1996-12-26 0:00 ` drush 1996-12-26 0:00 ` drush 13 siblings, 0 replies; 209+ messages in thread From: drush @ 1996-12-26 0:00 UTC (permalink / raw) Chris Brand <cbrand@ccgate.hac.com> *wrote*: ~David Bradley wrote: ~- ~- mbk@caffeine.engr.utk.edu (Matt Kennel) wrote: ~- ~- >Is it really? Can a painting communicate subtle ideas as clearly as ~- >literature? ~- ~- The thing that comes to my mind, is if visual is so much better then ~- why are we still "reading" books. ~- ~Kids aren't. They're watching TV or movies. Speak for youself. Mine are voracious readers. As are their parents :) david rush mailto:kumo@intercenter.net I bill $100/minute for reading commercial email. ObTextVsPicturesOpinion: Text *is* more accurate. Nobody uses hieroglyphics anymore. (And yes I *also* read Kanji). ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-05 0:00 ` Daniel Drasin ` (12 preceding siblings ...) 1996-12-26 0:00 ` drush @ 1996-12-26 0:00 ` drush 13 siblings, 0 replies; 209+ messages in thread From: drush @ 1996-12-26 0:00 UTC (permalink / raw) *Text* from the keyboard of Tansel Ersavas: >I remember similar discussions that took place when GUIs were first >introduced. However, it didn't change the fact that GUI dominated. When >CERN fist introduced the text based ancestor of Mosaic, it didn't really >motivate any users to participate until the hyper-media concept was >introduced. BZZZZ - There were also a lot less people connected back then, too. I was there. Hypertext systems were gaining in popularity everywhere, from Apple's Hypercard to on-line help systems, to project documentation (think Web and info). I run about 90% of the time in "no-images mode" using netscrape, and I only use netscrape because the folx desigining web pages think that layout is more important than content. NS seems to be able to keep pages intelligible even without the pics. >One should also remember that text is a visual represenatation as well. Pedant. Please pick your terms then. Verbal vs pictorial? Logical vs Gestalt? Procedural vs OO? We all know the semantic tension about which we are speaking. The representation is *not* the issue. >We have nice little icons that represent letters This subject is very >deep, and would start several threads, so I'll keep quiet about it now. Thank you. >I don't think that we can justify the graphical craze in measurable >terms such as of ease of use, or or ease of learning. To quote Robert Heinlein, "If you can't measure it, it's not science." This does not mean, however, that it is worthless. I was going to comment on his final paragraph (about text, pictures, blind people, and software architecture), but untangling the good from the silly was too tiresome. bleah - david rush mailto:kumo@intercenter.net Go away. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-03 0:00 What is wrong with OO ? Ahmed ` (6 preceding siblings ...) 1996-12-05 0:00 ` Daniel Drasin @ 1996-12-05 0:00 ` Nick Thurn 1996-12-06 0:00 ` Ranjan Bagchi ` (2 subsequent siblings) 10 siblings, 0 replies; 209+ messages in thread From: Nick Thurn @ 1996-12-05 0:00 UTC (permalink / raw) IMO asking "what is wrong with OO?" is a bit like asking "what is wrong with a hammer?" My point is OO is only a tool. The user of a tool is fundamental to the results. IMO if anything is wrong with OO it is inflated expectations. In the end it is people who create software. Good people create good software in any language/paradigm. Good OO looks deceptivly simple. Attaining simplicity is the hard part. I think of it as the difference between whistling a tune and writing a tune. Currently there are to many writers and not enough whistlers :) Regarding reuse and reusability, there are two levels of reuse: personal and strangers. Personal (including your team) reuse is pretty easy to achieve, reuse by strangers is hard. Reusable is in the eye of the reuser not the writer. All a writer can do is *attempt* to create reusable code it is for others to decide whether it is reusable or not. In C++ land the biggest barrier to reuse has been the proliferation of proprietry container librarys (usually as part of a more high level set of functionality). With the standard basically here this problem may go away. We still have the problem that most (probably all) mature librarys are written in legacy C++, when will they port across? when will compilers be available that handle all the new features? when will there be a standard ABI? IMO OO is a great tool, if it is flawed it is the execution not the concept. Oh well, back to the salt mines... cheers Nick (my opinions only) ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-03 0:00 What is wrong with OO ? Ahmed ` (7 preceding siblings ...) 1996-12-05 0:00 ` Nick Thurn @ 1996-12-06 0:00 ` Ranjan Bagchi 1996-12-06 0:00 ` Myles Williams 1996-12-06 0:00 ` Myles Williams 1996-12-07 0:00 ` Kazimir Majorinc 10 siblings, 1 reply; 209+ messages in thread From: Ranjan Bagchi @ 1996-12-06 0:00 UTC (permalink / raw) Myles Williams wrote: > > In article <588g4v$jer@samba.rahul.net> Carl Weidling <cpw@rahul.net> writes: > On the other hand, wasn't there a famous example back in the 70s > when 'top-level design' was first being expounded, where some big project > for a newspaper or something was designed first and then coded and it worked. > I remember this being cited a lot when I first started programming, can > anyone recall details or hard facts about that? > > That would be the New York Times database, created by IBM circa 1970. > It was the first full-scale application of structured programming, and > was completed early and under budget with approximately 0.25 > defects/kLOC. > Wow.. that's impressive. It also indicates to me that flagship projects in any methodology seem to be incredibly successful. Perhaps it's because world-class engineers are working on it and they're just succesful regardless of technology or tools or anything. The suggestion, though, may be that success of projects done by mere-mortal engineers using a particular methodology provide better data points. How this applies to the success of O-O is interesting because I think most people agree that misapplied O-O results in failed projects which sully O-O's reputation. Is it easier for mere-mortals to understand O-O? Should mere-mortals be in the software development business at all is another question, which is vaguely frightening. -rj ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-06 0:00 ` Ranjan Bagchi @ 1996-12-06 0:00 ` Myles Williams 0 siblings, 0 replies; 209+ messages in thread From: Myles Williams @ 1996-12-06 0:00 UTC (permalink / raw) In article <32A8631E.4CB0@pobox.com> Ranjan Bagchi <ranjan.bagchi@pobox.com> writes: > That would be the New York Times database, created by IBM circa 1970. > It was the first full-scale application of structured programming, and > was completed early and under budget with approximately 0.25 > defects/kLOC. Wow.. that's impressive. It also indicates to me that flagship projects in any methodology seem to be incredibly successful. Perhaps it's because world-class engineers are working on it and they're just succesful regardless of technology or tools or anything. The suggestion, though, may be that I tend to think it's because the people working on it are familiar with the methodology in its original incarnation, before marketers and "armchair experts" corrupt it. That's why, whenever someone needs an explanation of OO, I direct them to the work by Parnas and co. in the 70s. -- Myles Williams "When you see me again, it won't be me." http://funnelweb.utcc.utk.edu/%7Ewilliams/freeos | Guide to free | operating system kernels ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-03 0:00 What is wrong with OO ? Ahmed ` (8 preceding siblings ...) 1996-12-06 0:00 ` Ranjan Bagchi @ 1996-12-06 0:00 ` Myles Williams 1996-12-07 0:00 ` Kazimir Majorinc 10 siblings, 0 replies; 209+ messages in thread From: Myles Williams @ 1996-12-06 0:00 UTC (permalink / raw) In article <588g4v$jer@samba.rahul.net> Carl Weidling <cpw@rahul.net> writes: On the other hand, wasn't there a famous example back in the 70s when 'top-level design' was first being expounded, where some big project for a newspaper or something was designed first and then coded and it worked. I remember this being cited a lot when I first started programming, can anyone recall details or hard facts about that? That would be the New York Times database, created by IBM circa 1970. It was the first full-scale application of structured programming, and was completed early and under budget with approximately 0.25 defects/kLOC. -- Myles Williams "When you see me again, it won't be me." http://funnelweb.utcc.utk.edu/%7Ewilliams/freeos | Guide to free | operating system kernels ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-03 0:00 What is wrong with OO ? Ahmed ` (9 preceding siblings ...) 1996-12-06 0:00 ` Myles Williams @ 1996-12-07 0:00 ` Kazimir Majorinc 1996-12-14 0:00 ` Chris 10 siblings, 1 reply; 209+ messages in thread From: Kazimir Majorinc @ 1996-12-07 0:00 UTC (permalink / raw) Hello! I spent last two years in programming (for me) very complex structures in C++, and before that in Borland's Object Pascal. Although I was very enthusiastic with OO in the beginning, I'm losing this day by day. Before few months I thinked that Smalltalk could be better than C++, now I am in doubt with this. Listen why. 1. My analyse of my work shows that I will wrote programs faster if I use some of good old procedural languages, like Modula-2. I know how you could criticize me, but I'm exposed here. 8-) 2. Encapsulation, I mean that both data and functions are together in object seems to me like very unnatural shape today. Look at mathemathics. Mathematical language do not use that paradigm, although things which are described there are more complex than any software. They use something which looks like procedural paradigm with operators. It talks to me that, paradoxaly, object paradigm could work only for simple problems, but for complex, we have to come back to procedural. Looking just hierarchicaly, functions should be one level higher than data. Moreover, it is especially unnatural that one object contains functions which uses many others. If I overload operators, for example + in C++, I have disgusting when I use object model, and I have to prefer first element, when there is absolutely no reasons for that. If I could choose, I use procedural overload. If is necessary to make groups of functions, it is better to use some sort of packages. Class with lot of function members look really unnatural. I believe Smalltalk is even worse here. 3. Polymorphism. The greatest part of OO. I understand wish, but look at C++. Why if I want to do this things, I have to do it implicitely. I mean why functions which overload each other should have same name? It is better to do it explicitely, to say which function is overload of which. Now things could be simpler. I do not know how to do it in procedural paradigm, but I believe that it is somehow possible. 4. Inheritance. It seems OK. 5. Constructors, Destructors. They are great! 6. Messages. I do not know a lot of this, but Idea that object change himself alone remembers me at the days of programming on TI57, or in assembler, when every instruction is on so called accumulator. OO wants accumulator back. I would apprettiate one copy of answer privately (because news from my server expire fast), and use my name, that I could find you with Deja News. Of course, public answer is even better. _______________________________________________ Author: Kazimir Majorinc E-mail: Kazimir.Majorinc@public.srce.hr kmajor@public.srce.hr (slightly better) http: //public.srce.hr/~kmajor (~7min to USA) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ One who knows the secret of the 7th stair ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: What is wrong with OO ? 1996-12-07 0:00 ` Kazimir Majorinc @ 1996-12-14 0:00 ` Chris 0 siblings, 0 replies; 209+ messages in thread From: Chris @ 1996-12-14 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1743 bytes --] Kazimir Majorinc <kmajor@jagor.srce.hr> a �crit dans l'article <58b9jt$jhh@bagan.srce.hr>... > Hello! > 2. Encapsulation, I mean that both data and functions are together in > object seems to me like very unnatural shape today. Look at > mathemathics. Mathematical language do not use that paradigm, although > things which are described there are more complex than any software. that's because what you can with types in mathematics is not a finite state. What you can do with objects (classes) is supposed to be known and finite. > ... If I overload operators, for > example + in C++, I have disgusting when I use object model, and I have > to prefer first element, when there is absolutely no reasons for that. That's why we should use friend functions... > 3. Polymorphism. The greatest part of OO. I understand wish, but look at > C++. Why if I want to do this things, I have to do it implicitely. I > mean why functions which overload each other should have same name? It > is better to do it explicitely, to say which function is overload of > which. Now things could be simpler. I do not know how to do it in > procedural paradigm, but I believe that it is somehow possible. Because at an abstract level, you may want different (derived) objects do a certain stuff without caring with how it will be performed (like a base or overloaded way). > 6. Messages. I do not know a lot of this, but Idea that object change > himself alone remembers me at the days of programming on TI57, or in > assembler, when every instruction is on so called accumulator. OO wants > accumulator back. ??? -- Chris, drunk philosoph and bad programmer "The nail pulling up calls the hammer" zen proverb ^ permalink raw reply [flat|nested] 209+ messages in thread
end of thread, other threads:[~1997-01-15 0:00 UTC | newest] Thread overview: 209+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-12-03 0:00 What is wrong with OO ? Ahmed 1996-12-03 0:00 ` Fred Parker 1996-12-03 0:00 ` Bill Gooch 1996-12-03 0:00 ` Bill Gooch 1996-12-04 0:00 ` Ahmed 1996-12-04 0:00 ` Bill Gooch 1996-12-06 0:00 ` Jeff Miller 1996-12-06 0:00 ` Bill Gooch 1996-12-14 0:00 ` Chris 1996-12-06 0:00 ` Ahmed 1996-12-06 0:00 ` Bill Gooch 1996-12-04 0:00 ` Robert C. Martin 1996-12-04 0:00 ` Matthew Gream 1996-12-05 0:00 ` Tim Ottinger 1996-12-04 0:00 ` Harry Protoolis 1996-12-04 0:00 ` Joe Winchester 1996-12-05 0:00 ` Russell Corfman 1996-12-04 0:00 ` Robert C. Martin 1996-12-04 0:00 ` Dr. Richard Botting 1996-12-05 0:00 ` Tom Bushell 1996-12-05 0:00 ` Piercarlo Grandi 1996-12-06 0:00 ` Tom Bushell 1996-12-06 0:00 ` David Bradley 1996-12-08 0:00 ` Piercarlo Grandi 1996-12-10 0:00 ` Piercarlo Grandi 1996-12-10 0:00 ` Todd Hoff 1996-12-11 0:00 ` Nick Leaton 1996-12-11 0:00 ` Matt Kennel 1996-12-12 0:00 ` Piercarlo Grandi 1996-12-11 0:00 ` Nick Leaton 1996-12-11 0:00 ` Tom Bushell 1996-12-05 0:00 ` Marnix Klooster 1996-12-06 0:00 ` Roger Vossler 1996-12-10 0:00 ` Tom Bushell 1996-12-10 0:00 ` Roger Vossler 1996-12-12 0:00 ` Tom Bushell 1996-12-12 0:00 ` Don Harrison 1996-12-11 0:00 ` Todd Knarr 1996-12-11 0:00 ` Alan Meyer 1996-12-12 0:00 ` Ell 1996-12-12 0:00 ` Tom Bushell [not found] ` <58mubr$i <58p5ou$dkm@news3.digex.net> 1996-12-13 0:00 ` Nick Leaton 1996-12-25 0:00 ` Weiqi Gao 1996-12-25 0:00 ` Matthew S. Whiting 1996-12-26 0:00 ` Bob Jarvis 1996-12-26 0:00 ` Arthur Gold 1996-12-26 0:00 ` Mike Rubenstein [not found] ` <32aefdb0..406273038@news.nstn.ca> 1996-12-14 0:00 ` "Paul E. Bennett" 1996-12-06 0:00 ` Mukesh Prasad 1996-12-10 0:00 ` Tom Bushell 1996-12-06 0:00 ` Carl Weidling 1996-12-06 0:00 ` Harry Protoolis 1996-12-10 0:00 ` Tom Bushell 1996-12-06 0:00 ` David B. Shapcott [C] 1996-12-05 0:00 ` Piercarlo Grandi 1996-12-04 0:00 ` Ahmed 1996-12-06 0:00 ` Harry Protoolis 1996-12-06 0:00 ` Ralph Cook 1996-12-07 0:00 ` Harry Protoolis 1996-12-09 0:00 ` Nigel Tzeng 1996-12-12 0:00 ` David Bradley 1996-12-20 0:00 ` Nigel Tzeng [not found] ` <1996Dec7.151850.877@prim.demon.co.uk> 1996-12-08 0:00 ` Tansel Ersavas 1996-12-14 0:00 ` Kazimir Majorinc 1996-12-14 0:00 ` Jeff Miller 1996-12-16 0:00 ` David Bradley 1996-12-14 0:00 ` Tansel Ersavas 1996-12-15 0:00 ` Todd Hoff 1996-12-15 0:00 ` Patrick Ma 1996-12-16 0:00 ` Robert C. Martin 1996-12-16 0:00 ` Bob Kettig 1996-12-15 0:00 ` Tansel Ersavas 1996-12-20 0:00 ` The Impossible Project: not so funny... (Was: what's wrong) Tim Ottinger 1996-12-20 0:00 ` Robert Dewar 1996-12-21 0:00 ` John DiCamillo 1996-12-22 0:00 ` Guy Rixon 1996-12-22 0:00 ` Chip Richards 1996-12-04 0:00 ` What is wrong with OO ? Roger T. 1996-12-04 0:00 ` Piercarlo Grandi 1996-12-05 0:00 ` Daniel Drasin 1996-12-06 0:00 ` Steve Heller 1996-12-06 0:00 ` David Bradley 1996-12-06 0:00 ` Todd Hoff 1996-12-07 0:00 ` Steve Heller 1996-12-07 0:00 ` Tansel Ersavas 1996-12-09 0:00 ` Kenneth Mays 1996-12-14 0:00 ` Robert C. Martin 1996-12-14 0:00 ` Patrick Ma 1996-12-18 0:00 ` Harry Protoolis 1996-12-18 0:00 ` Patrick Ma 1996-12-18 0:00 ` Caitlin 1996-12-15 0:00 ` Tansel Ersavas 1996-12-17 0:00 ` Adam Beneschan 1996-12-17 0:00 ` Ralph Cook 1996-12-18 0:00 ` Tansel Ersavas 1996-12-17 0:00 ` Robert Dewar 1996-12-18 0:00 ` Tansel Ersavas 1996-12-27 0:00 ` clovis 1996-12-27 0:00 ` Jacqueline U. Robertson 1996-12-27 0:00 ` Tore Lund 1996-12-28 0:00 ` Tansel Ersavas 1996-12-28 0:00 ` Tore Lund 1996-12-31 0:00 ` Adam Beneschan 1996-12-31 0:00 ` Robert C. Martin 1996-12-31 0:00 ` clovis 1996-12-31 0:00 ` Neville Black 1996-12-31 0:00 ` Tansel Ersavas 1997-01-01 0:00 ` Tom Bushell 1997-01-10 0:00 ` Bart Samwel 1997-01-10 0:00 ` Robert Dewar 1997-01-10 0:00 ` Assembler most efficient??? (was Re: What is wrong with OO ?) Richie Bielak 1997-01-11 0:00 ` Robert Dewar 1997-01-11 0:00 ` James S. Rogers 1997-01-11 0:00 ` Larry Kilgallen 1997-01-12 0:00 ` Joel VanLaven 1997-01-13 0:00 ` Richie Bielak 1997-01-15 0:00 ` What is wrong with OO ? Richard Kenner 1997-01-11 0:00 ` Randy A. Ynchausti 1997-01-12 0:00 ` Piercarlo Grandi 1996-12-29 0:00 ` clovis 1996-12-31 0:00 ` Tom Bushell 1996-12-31 0:00 ` clovis 1997-01-10 0:00 ` Bart Samwel 1996-12-31 0:00 ` Jon S Anthony 1997-01-01 0:00 ` Jon S Anthony 1997-01-12 0:00 ` Corey Minyard 1997-01-14 0:00 ` Vos nom et pr�nom 1997-01-13 0:00 ` Nick Thurn 1996-12-28 0:00 ` clovis 1996-12-30 0:00 ` John (Max) Skaller 1996-12-29 0:00 ` Rosimildo da Silva 1996-12-31 0:00 ` Ian Joyner 1997-01-03 0:00 ` markj 1997-01-03 0:00 ` Natan 1996-12-27 0:00 ` Tore Lund 1996-12-28 0:00 ` clovis 1996-12-28 0:00 ` Tore Lund 1996-12-28 0:00 ` Stephen Pendleton 1996-12-31 0:00 ` Edward de Jong 1996-12-31 0:00 ` clovis 1996-12-31 0:00 ` Nick Leaton 1997-01-01 0:00 ` Tore Lund 1997-01-01 0:00 ` Tore Lund 1996-12-19 0:00 ` Robert C. Martin 1996-12-17 0:00 ` Adam Beneschan 1996-12-17 0:00 ` Tansel Ersavas 1996-12-18 0:00 ` Ralph Cook 1996-12-18 0:00 ` Adam Beneschan 1996-12-19 0:00 ` Robert C. Martin 1996-12-20 0:00 ` Tansel Ersavas 1996-12-21 0:00 ` Michael Malak 1996-12-19 0:00 ` Nick Leaton 1996-12-24 0:00 ` Nigel Tzeng 1996-12-26 0:00 ` Tansel Ersavas 1996-12-26 0:00 ` Bill Gooch 1996-12-16 0:00 ` Karen A. Morrissey 1996-12-16 0:00 ` Bob Kettig 1996-12-17 0:00 ` Robert Dewar 1996-12-17 0:00 ` David Bradley 1996-12-09 0:00 ` Todd Hoff 1996-12-10 0:00 ` Steve Heller 1996-12-10 0:00 ` Snowball queries 1996-12-12 0:00 ` Samuel S. Shuster 1996-12-12 0:00 ` Dr. Richard Botting 1996-12-13 0:00 ` Nick Leaton 1996-12-16 0:00 ` Samuel S. Shuster 1996-12-16 0:00 ` Bob Kettig 1996-12-16 0:00 ` Robert Dewar 1996-12-17 0:00 ` Tansel Ersavas 1996-12-18 0:00 ` Tom Bushell 1996-12-18 0:00 ` Matt Kennel 1996-12-18 0:00 ` Tansel Ersavas 1996-12-19 0:00 ` David Bradley 1996-12-20 0:00 ` Chris Brand [not found] ` <01bbee11$dcae8460$ca61e426@DCorbit.solutionsiq.com> 1996-12-23 0:00 ` David Bradley 1996-12-19 0:00 ` Jeffrey C. Dege 1996-12-20 0:00 ` Tom Bushell 1996-12-19 0:00 ` Tom Bushell 1996-12-23 0:00 ` David Bradley 1996-12-23 0:00 ` Jeffrey C. Dege 1996-12-19 0:00 ` Tansel Ersavas 1996-12-27 0:00 ` clovis 1996-12-17 0:00 ` Nick Leaton 1996-12-07 0:00 ` Nick Thurn 1996-12-14 0:00 ` Robert C. Martin 1996-12-15 0:00 ` Todd Hoff 1996-12-15 0:00 ` Joseph W. Seda 1996-12-16 0:00 ` David Bradley 1996-12-19 0:00 ` Robert I. Eachus 1996-12-15 0:00 ` Damon Feldman 1996-12-13 0:00 ` drush 1996-12-18 0:00 ` Matt Austern 1996-12-19 0:00 ` Risto Lankinen 1996-12-20 0:00 ` Tansel Ersavas 1996-12-20 0:00 ` Bill Gooch 1996-12-20 0:00 ` Jon S Anthony 1996-12-20 0:00 ` Jon S Anthony 1996-12-20 0:00 ` Tansel Ersavas 1996-12-26 0:00 ` What sells IT (was: What is wrong with OO ?) Cameron Laird 1996-12-23 0:00 ` What is wrong with OO ? Jon S Anthony 1996-12-23 0:00 ` Jon S Anthony 1996-12-26 0:00 ` drush 1996-12-26 0:00 ` drush 1996-12-05 0:00 ` Nick Thurn 1996-12-06 0:00 ` Ranjan Bagchi 1996-12-06 0:00 ` Myles Williams 1996-12-06 0:00 ` Myles Williams 1996-12-07 0:00 ` Kazimir Majorinc 1996-12-14 0:00 ` Chris
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox