CompuServe Thread

#ObjectOriented

4 messages in this thread
#48189From: Greg Comeau@Comeau CmptgSep 19, 1995 5:47 PM
>> As far as I am concerned, OO makes programs slower, bigger, more buggy, >> … than plain good (not too structured) programming. > >I suppose it is the same trade off between low level efficiency and fast >development that has been going on since programming began. Not necessarily. >I miss programming in Assembler, these days I use a so called Fourth >Generation Language at work, I miss it too, but then a lot of what I do these days would be foolish for me to do in asm. It's simply a matter of where things lay within their goals. >they get worried if I use C. I'm much more worried about programmers than the languages they use 🙁 >But I would expect OO to make programs less buggy. Not necessarily, just in a different realm and light. Remember too, people still write and design programs 🙁
#48208From: Peter WadeSep 19, 1995 6:48 PM
> >they get worried if I use C. > I'm much more worried about programmers than the languages they use 🙁 That sounds like a good attitude. The worst thing is non-programming managers who take the old cliches at face value. Like "Fourth Generation Languages improve programmer productivity", so we spend ages trying to force a 4GL to do a complex job it was never designed for and end up with a convoluted and almost non-maintainable mess. And "C code is difficult to maintain", so they never consider using it unless you can prove there is no alternative even though it would have been a lot easier to do the same job in C. Of course assembler doesn't have a chance since "Assembler programmers only produce 10 lines a day (or something close to that figure)". Peter Wade Autopiloting from London, England
#48216From: Greg Comeau@Comeau CmptgSep 20, 1995 10:18 AM
>>>they get worried if I use C. >> I'm much more worried about programmers than the languages they use 🙁 >That sounds like a good attitude. I think so. I learned early on to keep a broad and open mind on issues. Thinks are just too diverse to be pig headed, ignorant, throw ones weight around, etc, generally all counter productive. The bottom line is that we need to sit down and contemplate what needs to be done. I don't care if you flowchart, use a CASE, or just stare at the wall (or your navel), but the thought must go into the things. As such, the primary consideration is the process and design. The focus on the language is trivia in some ways. Of course, it should not be discarded because as some point the designs needs to be twisted into the means of expression supported. And that can lead to a beast. >The worst thing is non-programming managers who take the old cliches at >face value. Yep, makes me sick to my stomach. >Like "Fourth Generation Languages >improve programmer productivity", so we spend ages trying to force a 4GL to do >a complex job it was never designed for and end up with a convoluted and >almost non-maintainable mess. This is where good senior programmers can come into play. It involves some level of insubordination, but the foot must come down in many cases. Monsters can be avoided but one must stick to ones guns. Of course, you need a good track record and must be right too. I've seen way too much of what you say above. Even when the 4GL is the right thing, from time to time it might be beneficial to have outside hooks available. Silly managers must learn to respect the capabilities and advise of the people they hired, or else, why hire them? Especially what that too expensive $200 thing will say them thousands. > And "C code is difficult to maintain", so they never >consider using it unless you can prove there is no alternative even though it >would have been a lot easier to do the same job in C. Well, that's just stupid IMO. One can write bad and unmaintainable code in any language, and sticking it just on C isn't going to get them anywhere. Yeah, sure, pointers and such can kill ya, but still, a good programmer is a good programmer and a bad programmer is a bad programmer. Juniors and seniors should work together not in closets. >Of course assembler doesn't have a chance since "Assembler programmers >only produce 10 lines a day (or something close to that figure)". Actually, you might be surprised to know that the average HLL programmer doesn't produce all that much more per day of working and debugged code.
#48232From: Bart Van BockstaeleSep 20, 1995 10:22 PM
>>That sounds like a good attitude. The worst thing is non-programming managers who take the old cliches at face value. Like "Fourth Generation Languages improve programmer productivity", so we spend ages trying to force a 4GL to do a complex job it was never designed for and end up with a convoluted and almost non-maintainable mess. And "C code is difficult to maintain", so they never consider using it unless you can prove there is no alternative even though it would have been a lot easier to do the same job in C. Of course assembler doesn't have a chance since "Assembler programmers only produce 10 lines a day (or something close to that figure)".<< Well said! Bart Van Bockstaele at 100574.2352@compuserve.com … On AutoPilot and Amiga all the way from Belgium NOT from Mars!…