craig@gpu.utcs.utoronto.ca (Craig Hubley) (02/19/91)
In article <27BFDF44.3EA6@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >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. Hey, I plead guilt of not reading manuals most of the time. :) And objections to how C++ works belong in comp.std.c++, not .lang.c++, so you're entirely within your rights to misinterpret my remarks. :) >According to craig@gpu.utcs.utoronto.ca (Craig Hubley): >>The craft of programming will continue to exist, but it will migrate, >>hopefully, into higher-level concerns and lowest-level details. > >What he said. I think of it like architecture, which is at once an art and the nitty- grittiest of crafts... Half your work is catching imagination on paper and the other half is sticking your hand in the dirt, sniffing the air and pounding the soil. Half your head has to be on what kind of building your client needs, the other half on what kind the land will tolerate... at least that's the best kind of architecture. >>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). Actually today there is *more* of a quality gap. Because the artisans are producing for an audience that appreciates the craft, rather than one that needs the product. I worked with a lot of beta-level PARC software, and research products sometimes have the same feel... >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. Hmm. Agreed. But building is not like mass production, either, and not all the parts are prefab components. I consider this a better analogy than either cars or guns, although Cox may care to differ. >>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. Now that's an idea I can agree with. Assertions, however, only really extend the safety of the type system somewhat. If you think about the set of all objects, "type safety" divides them into little groups (e.g. integers). And "assertions" divide them into somewhat smaller groups (e.g. integers between 5 and 99). But neither can guarantee me that this number is the correct age of someone buying books, or the correct price of tea in China, or that an extra year hasn't been added or subtracted somewhere. We can only cut the risk that this is so by flagging unusual cases: Kids younger than 5 wander in, and some people shop well past 100. Semantic guarantees of this sort will still always be provided by the programmer, who is the only one who can judge what they mean. Assertions can check across object boundaries and strengthen the type system, but they can't do much more. So a programmer with a consistent set of mechanisms (as few as possible) is still the one who bears the burden of understanding and verifying his/her code. >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. So who's pushing Objective-C ? I'm in favor of optimizing compilers, myself, and abhor stupid syntax that forces things to be left until runtime that could have been resolved earlier. -- 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/21/91)
According to craig@gpu.utcs.utoronto.ca (Craig Hubley): >I think of it like architecture, which is at once an art and the nitty- >grittiest of crafts... Half your work is catching imagination on paper >and the other half is sticking your hand in the dirt, sniffing the air >and pounding the soil. Architecture is an excellent analogy, in my opinion. >... building is not like mass production, either ... Quite true. Prefab available, but the best work involves lots of custom design and imagination. >Assertions, however, only really extend the safety of the type system >somewhat. And I think that's all we'll ever get out of our compilers until we finally manage to incomporate AI into our compilers. But then, who will need to program? :-)