craig@gpu.utcs.utoronto.ca (Craig Hubley) (02/16/91)
In article <27BC17C4.6304@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >[ This article is almost appropriate for comp.object. Please redirect > followups appropriately, according to their content. ] Followups to comp.sw.components. The C++ issues are now in another thread with followups to comp.std.c++, where the issue of "fixing" the types returned/accepted by virtuals was raised by someone else. Since it involves changing the language it belongs in .std rather than .lang Since this one is about the relationship of C++ to the so-called "software component industry" I've left it here. >According to craig@gpu.utcs.utoronto.ca (Craig Hubley): >>In article <27B94CC2.5A6C@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>>Good. If I wanted a revolution, I'd move to Lithuania. >> >>Not to be a killjoy, but that isn't all that funny. People are dying there. > >Sigh. I know all about Lithuania's deathly serious struggle for >independence. Here's some free advice: Enjoy humor where you find it, >even if you find it in war. Living with a frown doesn't help anyone. I got the joke. I suppose I was rather annoyed that you had read the entire post and then decided to comment only on this rather emotive conclusion. What I guess I should have said was "if we want to get reusable components with predictable behavior out of C++, we better start thinking about this." with the implication that extending C alone is not likely to permit such components to be easily developed. >My point is only that tired old observation that ideology is a >hindrance to intelligent choice. If I wanted a "revolution," I >wouldn't be programming. Technical fields can do without Lenins >and Castros. But not without Stroustrops and Coxes and Kays. Leadership of a different sort, I'll grant. No need to natter over these terms anymore. I'll refrain from calling it a revolution, if you like. >C++ is very much a pragmatic language, not an ideological one. Hmm... but in failing to do anything drastic you may fail to do anything at all. Politicians pride themselves on being "pragmatic" rather than "ideological" or "partisan" too. Is C++ a politician's language ? :) For those who can't argue well enough for OO to get to ues a real OO language. :) :) >For example, the language is extensible, but not mutable: you cannot >redefine operations that already have a meaning in the base language. >Why? Doesn't that reduce the conceptual purity of the type space? >Sure. Who cares? Not me. Me neither. I don't expect conceptual purity out of a C extension. >In a related vein, C++ is almost entirely compatible with C. Why? Is >C is a particularly good basis on which to build the pure essence of >object orientation? Of course not. But with the huge number of C >programs and C programmers in existence, it was the natural choice for >a language that aims to enhance existing software development efforts >without the necessity of starting over. Yes, a reasonable design choice. Training is most of the costs of introducing any new software, and development tools are the most labor-eating software of all... next to word processors and spreadsheets. And those aren't likely to change that much either in the next 20 years. However, none of what I am suggesting would change any part of C++ that was inherited from C. So this is not an issue. And these changes would not even affect present C++ programmers or their code. >The moral of these examples is that sloganeering will get you nowhere. I was not "sloganeering". I said a lot of other things and ended with what you chose to take as a slogan. That's enough about that, from me anyway. >The market has voted with its feet: Pragmatism wins the day. Point >out concrete benefits of specific proposals, and people will take you >seriously. This is being done in comp.std.c++. Someone else proposed one of the very same changes as I did, just today. They posted their code and why the existing rules made it a mess. I couldn't do that because all of my code that does this is in other languages. I am a pragmatic guy, and previously I hadn't tried to get C++ to do these things. >>What you want is irrelevant. If building reusable software components is >>more economically sustainable than building custom parts every time you >>build an application, you will soon be out of a job ... > >That statement is only true if (1) there exists a method of combining >pre-made software components into complete applications without >programming, This "method" could require some programming and still beat the cost/ benefit beejeezus out of anything built mostly from scratch. Anyway, (1) is already coming - check out NewWave, or the OMG. If what you mean is that users will always need programmers, I'll buy that. >(2) that method works significantly better than whatever >I'm doing at that future time, > >(3) my competition is using it, and >(4) I'm not willing to change. > >*IF* (1), (2) and (3) are satisfied, you can bet that (4) won't be. Fair enough. You've got plenty of time to change your mind, improve your tools, or whatever. If it's necessary, and there's a chance that it won't be. >>Neither gunmakers nor cotton processors nor anyone else who had mastered >>a "craft" made the adjustment to "industry" - they were simply replaced >>by others who had mastered a more predictable and reproducible process >>for building parts. > >That's fine as a history lesson. I'm under no delusions that the way >I work is the perfect method of software construction. But misapplied >history as as bad as forgotten history. And I have yet to see any >evidence whatsoever that the craft of programming is endangered by the >spectre of component assembly. I'll believe it when I see it, but I >don't see it. (Somebody has to write the modules, after all!) The craft of programming will continue to exist, but it will migrate, hopefully, into higher-level concerns and lowest-level details. Architects and general contractors still exist side-by-side, as do plumbers. The analogies to buildings or guns or cotton aren't mine, they come from others, notably Cox, so I refer you there to determine if you think they are misapplied. >Please remember that I am fond of writing reusable code, simply as a >way to avoid unnecessary work. Otherwise, I wouldn't have made the >effort to switch myself and my co-workers from C to C++. But "The reasonable man accepts things as they are - thus all progress depends on the unreasonable man" (paraphrase) - G. Bernard Shaw My version, and probably yours too from what you say: "The industrious man is always willing to work to overcome deficiency - thus all breakthroughs depend on the lazy man" :) >agglomeration of modules as described by Objective-C zealots is not >the be-all and end-all of programming techniques. It's just another >technique, to be used or ignored according to the good judgement of >the experienced craftsman. Well, this bears an uncanny resemblance to what those gunmakers said. Sure, there are drawbacks to standardized components, like over-generality and the need to trust other programmers. But if I can build software that does 95% of what I need at 10% of the cost, I am pretty likely to figure out good reasons not to need that 5%. Like nice designs etched on the gunstock, or even a certain level of accuracy. Mass-produced cars and guns were markedly inferior to their handmade counterparts in the beginning. They appealed to people because they were *cheap*. Period. Only once a huge market groundswell had gathered was there enough R&D money to really improve the quality of the mass-produced product. >>I am only suggesting that building these parts is easier if there is a way >>to explicitly control the behavior presented to the (re)user of a component. > >A vague statement such as that is impossible to disagree with. Then agree, and let's talk about how to do it. Assertions ? Contracts ? Comments ? There have been good posts about all of these lately. >It's the talk of "revolutions" that gets my goat. Clearly. Well, hopefully the analogies get your goat less. If not, ignore 'em and follow up on my other, strictly technical post. In any case, I don't care to argue for the "revolution" any more. That's Brad Cox's job, and he does good work. >Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> -- Craig Hubley "...get rid of a man as soon as he thinks himself an expert." Craig Hubley & Associates------------------------------------Henry Ford Sr. craig@gpu.utcs.Utoronto.CA UUNET!utai!utgpu!craig craig@utorgpu.BITNET craig@gpu.utcs.toronto.EDU {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig
chip@tct.uucp (Chip Salzenberg) (02/18/91)
Craig writes a very pragmatic [:-)] description of object oriented programming and its possible future directions. I suppose I should have read Craig's original article in its entirety, rather than judging its contents by the one "revolution" remark. Mea culpa. According to craig@gpu.utcs.utoronto.ca (Craig Hubley): >If what you mean is that users will always need programmers, >I'll buy that. I'm glad. :-) Some people have truly unrealistic expectations for the reduction of programming effort. IMHO, given the expanding importance of computers in society, programming tasks will expand to use all available programmers. If OO makes us more productive, that's all the better: we'll get more done. But we'll still be needed. >The craft of programming will continue to exist, but it will migrate, >hopefully, into higher-level concerns and lowest-level details. What he said. >My version, and probably yours too from what you say: >"The industrious man is always willing to work to overcome deficiency - > thus all breakthroughs depend on the lazy man" :) Absolutely. Larry Wall's three virtues of programmers are Laziness, Impatience and Hubris. And let us not forget Heinlein's great example for programmers everywhere: "The Man Who Was Too Lazy To Fail." >Mass-produced cars and guns were markedly inferior to their handmade >counterparts in the beginning. They appealed to people because they >were *cheap*. Period. Indeed (and handmade goods are still superior in quality). But we here at TCT already have a production line: one person with a box of standard streamer tapes, and a "publications department" consisting of a few people and a huge copying machine. So much for software production! Programming is not production in the industrial sense. I would consider it more similar to the design department of the car and gun manufacturers than to their production lines. Programming is a low-volume, high-creativity consolidation of thought into a formal notation. As such, it is fundamentally different from the high-volume, low-creativity work that characterizes mass production. (Don't get hung up on the term "low-volume." As programming methods progress, our sadly limited mental output can produce greater and greater results.) >I am only suggesting that building these parts is easier if there is a way >to explicitly control the behavior presented to the (re)user of a component. I would like to see this done with assertions as part of the C++ class definition. The more checking that can be done by the compiler, the better. But I am not willing to jump on the Objective-C bandwagon, if only because static typing is a useful way to avoid a great deal of run-time messaging and debugging overhead. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "I want to mention that my opinions whether real or not are MY opinions." -- the inevitable William "Billy" Steinmetz
cox@stpstn.UUCP (Brad Cox) (02/19/91)
In article <27BFDF44.3EA6@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to craig@gpu.utcs.utoronto.ca (Craig Hubley): >>If what you mean is that users will always need programmers, >>I'll buy that. Network constipation caused me to miss the original that prompted this discussion. Would some (one!) kind soul please email it? >I would like to see this done with assertions as part of the C++ class >definition. Do not confuse white box assertions inside the code (preconditions, postconditions, and class invarients, as in Eiffel) with black box assertions expressed externally to the class. >The more checking that can be done by the compiler, the >better. Assertions are checked by the application's running image, not by the compiler. >But I am not willing to jump on the Objective-C bandwagon, if >only because static typing is a useful way to avoid a great deal of >run-time messaging and debugging overhead. There's an Objective-C bandwagon? Where?! Who do I see to join? ;-> -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
chip@tct.uucp (Chip Salzenberg) (02/24/91)
According to cox@stpstn.UUCP (Brad Cox): >In article <27BFDF44.3EA6@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>The more checking that can be done by the compiler, the better. > >Assertions are checked by the application's running image, not by the >compiler. Of course. What I meant was, the programmer writes the condition once, and the compiler inserts the code _where it is needed_, thus saving grunt work. In particular, when one member function calls another, it should be possible to delay any class consistency checking until the outermost member function returns. >>But I am not willing to jump on the Objective-C bandwagon ... > >There's an Objective-C bandwagon? Where?! Who do I see to join? ;-> What, didn't you know? You're the driver... -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "It's not a security hole, it's a SECURITY ABYSS." -- Christoph Splittgerber (with reference to the upage bug in Interactive UNIX and Everex ESIX)