cml@tove.cs.umd.edu (Christopher Lott) (04/23/91)
In article <jls.672364339@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes: >.... until the 1800's, HALF of all bridges built fell down. Why? Because the >principles of civil engineering were not well-understood, and so much of it >was empirical and artistic: more craft than science. It is different now, but >I bet for a while there were members of the old guard who protested loudly >that civil engineering was not a science and never could be...just like hackers >proclaim loudly now. uh, half? But I don't know any better. However, I DO dispute your claim that the bridge-builders of yore claimed that their craft would never be a science. They were developing the science of statics through trial and error. We're using trial and error, but I'm not convinced we're developing a science. The high level of human creativity in every software enterprise as compared to the creativity involved in a static structure like a bridge makes me (IMHO) confident you're comparing tomatoes and avocadoes. On a positive note, I think that bridge builders of today are confident that there are techniques developed by others that work, and they are happy to (perhaps required to) use these techniques. Compare this situation with software, where we have a multitude of techniques, some quite rudimentary and well accepted, yet there are developers who play cowboy and ignore the helpful work done by others. Either they suffer from NIH syndrome or are simply ill informed. What can be done to reach the ill-informed practictioner? chris... -- Christopher Lott \/ Dept of Comp Sci, Univ of Maryland, College Park, MD 20742 cml@cs.umd.edu /\ 4122 AV Williams Bldg 301 405-2721 <standard disclaimers>
jls@rutabaga.Rational.COM (Jim Showalter) (04/25/91)
>The high level of human creativity in every software >enterprise as compared to the creativity involved in a static structure like >a bridge makes me (IMHO) confident you're comparing tomatoes and avocadoes. You miss my point--the high level of creativity required in software is due to our not yet having a clue how to make writing software more like building bridges. Bridge builders were undoubtedly VERY creative before there was any grasp of how to build bridges. >yet there are developers who play cowboy and ignore the >helpful work done by others. Exactly my point--and I believe this is BECAUSE they regard themselves as these creative geniuses who don't NEED discipline, science, etc, when in fact they're really sort of emotionally retarded wannabee artistes. >Either they suffer from NIH syndrome or are >simply ill informed. What can be done to reach the ill-informed practictioner? Large caliber handguns come to mind... -- * "Beyond 100,000 lines of code, you should probably be coding in Ada." * * - P.G. Plauger, Convener and Secretary of the ANSI C Committee * * * * The opinions expressed herein are my own. *
chrisp@regenmeister.EBay.Sun.COM (Chris Prael) (04/26/91)
From article <jls.672529800@rutabaga>, by jls@rutabaga.Rational.COM (Jim Showalter): >>The high level of human creativity in every software >>enterprise as compared to the creativity involved in a static structure like >>a bridge makes me (IMHO) confident you're comparing tomatoes and avocadoes. > You miss my point--the high level of creativity required in software is > due to our not yet having a clue how to make writing software more like > building bridges. Bridge builders were undoubtedly VERY creative before > there was any grasp of how to build bridges. May I suggest that you both are missing a crucial point. I have been developing software for most of the last 25 years and I have worked for quite a few companies. From this experience, I have observed that most software developers display the same level of creativity as the average builder of culverts in CalTrans. I have also observed that it is a rare software developer indeed who displays the level of creativity that can be seen in the Golden Gate Bridge or the Alfa Romeo Alfetta GT. From watching my wife, who is a structural engineer, and her collegues, I would have to say that the average software engineer is somewhat less creative than the average structural engineer. If you look around a bit, you will probably conclude that the most creative engineering going on right now is by European automotive engineers and American aviation engineers. >>yet there are developers who play cowboy and ignore the >>helpful work done by others. > > Exactly my point--and I believe this is BECAUSE they regard themselves > as these creative geniuses who don't NEED discipline, science, etc, > when in fact they're really sort of emotionally retarded wannabee > artistes. Well said, and very true. >>Either they suffer from NIH syndrome or are >>simply ill informed. What can be done to reach the ill-informed practictioner? > Large calliber handguns come to mind. Perhaps a little extreem. From what I have seen, a lot of these people are educable. Most of them were put on the wrong track by "computer science" training in college and have never had the advantage of being trained by an engineer. If all they have ever seen is pseudo-scientists being technicians, that's all they will know how to do. The ones who won't learn you convey gently to the street. Chris Prael
taylor@intellistor.com (Dick Taylor) (04/26/91)
In article <jls.672529800@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes: >>The high level of human creativity in every software >>enterprise as compared to the creativity involved in a static structure like >>a bridge makes me (IMHO) confident you're comparing tomatoes and avocadoes. > >You miss my point--the high level of creativity required in software is >due to our not yet having a clue how to make writing software more like >building bridges. Bridge builders were undoubtedly VERY creative before >there was any grasp of how to build bridges. > Y'know, it occurs to me that your analogy is closer than you might think, but not in a way that agrees with your central point. I think that building _some_kinds_ of software is very much like building bridges. That is, the thing is expensive to produce, and so critical in its function that any failure at all is potentially catastrophic and certainly expensive. Space shuttle operating software, for example, fits nicely into this mold. Other kinds of software may not have this level of expense and criticality. Or they may not be susceptible to the same kind of orderly design methodology. The problem with building everything as if it were a bridge is that bridges cost lots to build (lots more per square foot than, for example, a parking lot) and they take a lot of design and implementation time. Civil engineering has progressed to the point that bridges are built like bridges should be built, buildings are build like buildings should be built, and parking lots are built with as little effort as possible. All done with good engineering. I don't there there is or ever will be one and only one good method of software engineering. I think we do have a LONG way to go before we have the methods as codified and tested as engineers in more concrete (ick. :-) fields. And I think your .sig indicates that you agree, or at least that you quote someone who agrees: >-- >* "Beyond 100,000 lines of code, you should probably be coding in Ada." * >* - P.G. Plauger, Convener and Secretary of the ANSI C Committee * >* * >* The opinions expressed herein are my own. * That is, there are times when ANY software methodology may not work.
reggie@paradyne.com (George W. Leach) (04/26/91)
In article <1991Apr25.200023.5334@intellistor.com> taylor@intellistor.com (Dick Taylor) writes: >I think that building _some_kinds_ of software is very much like building >bridges. That is, the thing is expensive to produce, and so critical in >its function that any failure at all is potentially catastrophic and >certainly expensive. Space shuttle operating software, for example, >fits nicely into this mold. IBM Houston is the ONLY SEI Level 5 organization that I know of. They develop the space shuttle software. However, cost is not a factor in their development equation. >Other kinds of software may not have this level of expense and criticality. Or >they may not be susceptible to the same kind of orderly design methodology. Right. We must make tradeoffs based upon constraints. The trick is to adequately balance quality, time, and money. Unfortunately, most organizations tend to focus on the later two and ignore the first. -- George W. Leach AT&T Paradyne reggie@paradyne.com Mail stop LG-133 Phone: 1-813-530-2376 P.O. Box 2826 FAX: 1-813-530-8224 Largo, FL 34649-2826 USA
chaplin@keinstr.uucp (chaplin) (04/27/91)
In article <33407@mimsy.umd.edu> cml@tove.cs.umd.edu (Christopher Lott) writes: >Either they suffer from NIH syndrome or are >simply ill informed. What can be done to reach the ill-informed practictioner? > >chris... >-- >Christopher Lott \/ Dept of Comp Sci, Univ of Maryland, College Park, MD 20742 > cml@cs.umd.edu /\ 4122 AV Williams Bldg 301 405-2721 <standard disclaimers> First, identify them. Being ill-informed, they are unaware of their condition, right? How to identify them? (Here goes....) Measure their effectiveness. -- Roger Chaplin | uunet!keinstr!chaplin | Don't blame my Instruments Division Engineering | CI$: 76307,3506 | company for my Keithley Instruments, Inc. | voice: (216) 498-2815 | opinions, nor me Solon, Ohio 44139 USA | FAX: (216) 248-6168 | for theirs!
jls@rutabaga.Rational.COM (Jim Showalter) (04/27/91)
>I think your .sig indicates that you agree, or at least that >you quote someone who agrees: >>* "Beyond 100,000 lines of code, you should probably be coding in Ada." * >>* - P.G. Plauger, Convener and Secretary of the ANSI C Committee * >That is, there are times when ANY software methodology may not work. Not at all--I have been involved in several MEGA-SLOC projects that were completed satisfactorily. Clearly, something DID work. See, the reason I think software can be engineered like anything else is that I've seen that done in actual practice, and on some of the largest and most complex projects ever attempted. As for the quote itself, Plauger's point is that Ada is a language designed from the ground up to support software engineering, whereas C most decidedly is not (I do hear they recently made it harder to pass an arbitrary number of arguments of arbitrary type to a C function, so I guess progress is being made....). -- * "Beyond 100,000 lines of code, you should probably be coding in Ada." * * - P.G. Plauger, Convener and Secretary of the ANSI C Committee * * * * The opinions expressed herein are my own. *
chrisp@regenmeister.EBay.Sun.COM (Chris Prael) (04/30/91)
From article <jls.672700751@rutabaga>, by jls@rutabaga.Rational.COM (Jim Showalter): > As for the quote itself, Plauger's point is that Ada is a language > designed from the ground up to support software engineering, whereas ^^^^^^^ Judging from the rest of this paragraph, you seem to mean 'force' rather than 'support'. > C most decidedly is not (I do hear they recently made it harder to If you can't engineer software well in C, you can't engineer software well period! > pass an arbitrary number of arguments of arbitrary type to a C function, > so I guess progress is being made....). One of the grossest conceptual errors of well intended designers is the idea that it is useful to constrain a programmer to do the right thing. While it is demonstrably useful to harness, bridle, and blinder a draft animal, it is just as obviously disfunctional to try to do this with programmers/engineers/designers. Tools that control the programmer can only do so by disabling. The result is not a technician forced to behave like an engineer but a hobbled technician. Chris Prael
koehnema@ENUXHA.EAS.ASU.EDU (Harry Koehnemann) (05/02/91)
In article <1259@grapevine.EBay.Sun.COM> chrisp@regenmeister.EBay.Sun.COM (Chris Prael) writes: > >> C most decidedly is not (I do hear they recently made it harder to > >If you can't engineer software well in C, you can't engineer software >well period! > Tell that to AT&T after their 1-800 blunder. That error would have been less likely in different language (like Ada - I had to say that.). Harry Koehnemann koehnema@enuxha.eas.asu.edu
cml@care.cs.umd.edu (Christopher Lott) (05/02/91)
>In article <> chrisp@regenmeister.EBay.Sun.COM (Chris Prael) writes: >If you can't engineer software well in C, you can't engineer software >well period! In article <> koehnema@enuxha.eas.asu.edu (Harry Koehnemann) replies: >Tell that to AT&T after their 1-800 blunder. That error would have been >less likely in different language (like Ada - I had to say that.). This is a red herring. I assume you refer to the failure of switching software that resulted from a missing "break" statement. We can go around and around, arguing that this was caused by the use of C, but it's not IMHO productive to do so. There are classes of faults that are more prevalent in some languages than others. I'm not proficient enough in Ada to give a counter example, and actually it's better that I don't, because that would just set off more flame wars. Let's discuss how we can identify these classes of faults, so we are able to say before code reviews "watch out for this class of mistakes." What are the classes of faults which occur most often in your environment? How expensive are they to identify, fix? (In the previous red herring, due to the application, pretty darned expensive if missed.) I agree with Chris Prael's first comment - the syntax and low-level issues of your development language are important, but other issues dominate. chris... -- Christopher Lott \/ Dept of Comp Sci, Univ of Maryland, College Park, MD 20742 cml@cs.umd.edu /\ 4122 AV Williams Bldg 301 405-2721 <standard disclaimers>
koehnema@ENUXHA.EAS.ASU.EDU (Harry Koehnemann) (05/02/91)
In article <33846@mimsy.umd.edu> cml@care.cs.umd.edu (Christopher Lott) writes: > >Let's discuss how we can identify these classes of faults, so we are >able to say before code reviews "watch out for this class of mistakes." >What are the classes of faults which occur most often in your environment? >How expensive are they to identify, fix? (In the previous red herring, >due to the application, pretty darned expensive if missed.) > It's more than that. The point is that the error was not caused by a single programming mistake. It was designed, reviewed, and tested extensively (I hope). Therefore, we must blame th process as being inadequate to catch that type of error. Now, is that type of error less likely to occur in a strongly typed language that strictly enforces well identified software engineering principles (which C does not). I'd say yes. Hell, anyone that uses a break stmt to transfer control out of an if probably needs a little help.
hammondr@sunroof.crd.ge.com (Richard A Hammond) (05/02/91)
In article <33846@mimsy.umd.edu> cml@care.cs.umd.edu (Christopher Lott) writes: >Let's discuss how we can identify these classes of faults, so we are >able to say before code reviews "watch out for this class of mistakes." >What are the classes of faults which occur most often in your environment? >How expensive are they to identify, fix? (In the previous red herring, >due to the application, pretty darned expensive if missed.) >It's more than that. The point is that the error was not caused by To which, In article <9105020234.AA01202@enuxha.eas.asu.edu> koehnema@enuxha.eas.asu.edu (Harry Koehnemann) responds: >a single programming mistake. It was designed, reviewed, and tested >extensively (I hope). Therefore, we must blame th process as being >inadequate to catch that type of error. Now, is that type of error >less likely to occur in a strongly typed language that strictly enforces >well identified software engineering principles (which C does not). >I'd say yes. Hell, anyone that uses a break stmt to transfer control >out of an if probably needs a little help. Does anybody have the actual code fragment and what it should have been? What follows may not apply (but neither may Harry's comment above). BULL!!! Harry, the error has nothing to do with typing, strong or weak, it was a syntax error, according to your description. In fact, the same error could be made in Ada, i.e. using 'exit' out of an if statement which is inside a loop, e.g. (formatted to line up parallel constructs) Ada version C Version loop for .... { if condition if ( condition ) then { do_something; do_something; exit; break; end if; } something_else_to_do; something_else_to_do; end loop; } Now I admit that the actual description I heard, which was similar to that given by Harry, was: using a break statement to terminate an if, makes no sense to me, i.e. it would be like saying that they used exit to terminate an if in Ada. Both only work in the syntax of the language if there is an outer loop (or case statement in C). As far as a language that supports "software engineering prnciples", I fail to see how this would help in this case. The error was inside a single module. I've done 13 years of programming in C, and spent the last two using Ada. While I much prefer using Ada to C, I won't be so bold as to claim that they make any difference in my error rate or productivity. In fact, I strongly suspect that some of the Ada sucess stories I've been hearing, on closer examination are examples of the Hawthorn effect, i.e. management pays attention to what's going on and gets better results. Disclaimer: my opinions are my own and not GE's. Rich Hammond
adam@visix.com (05/02/91)
In article <9105020234.AA01202@enuxha.eas.asu.edu>, koehnema@ENUXHA.EAS.ASU.EDU (Harry Koehnemann) writes: |> The point is that the error was not caused by |> a single programming mistake. It was designed, reviewed, and tested |> extensively (I hope). Therefore, we must blame th process as being |> inadequate to catch that type of error. I'm sorry, but you can't blame an entire process based on a single data point. You may well argue that C is statistically more likely to have errors, but that is a different argument, for which anecdotes are irrelevant. Adam
chaplin@keinstr.uucp (chaplin) (05/03/91)
In article <9105012313.AA23259@enuxha.eas.asu.edu> koehnema@enuxha.eas.asu.edu (Harry Koehnemann) writes: >In article <1259@grapevine.EBay.Sun.COM> chrisp@regenmeister.EBay.Sun.COM (Chris Prael) writes: >>If you can't engineer software well in C, you can't engineer software >>well period! >> > >Tell that to AT&T after their 1-800 blunder. That error would have been >less likely in different language (like Ada - I had to say that.). > >Harry Koehnemann >koehnema@enuxha.eas.asu.edu Baloney! Read what Chris Prael said! The fact that it is *possible* to engineer software well in *any* language does not mean that well-engineered software is guaranteed. Perhaps the blunder would not have happened had AT&T used Ada, but using Ada would not have guaranteed that the blunder would not have happened. If I have a hacksaw but not a wrench, I can still remove a bolt. It may be easier and I may like the result better if I have a wrench. I have programmed large systems using Forth (no flames, please!) and small systems using C. Had it been the other way around I probably would not have spent as much time programming these systems, but the fact remains that they both perform to specs. -- Roger Chaplin / Instruments Division Engineering / uunet!keinstr!chaplin CI$: 76307,3506 / voice: (216) 498-2815 / FAX: (216) 248-6168 "In the last analysis the customer is the independent auditor. In the merciless light of real use, every flaw will show." - Frederick P. Brooks, Jr.
alesha@auto-trol.com (Alec Sharp) (05/04/91)
In article <1991May3.142824.208@keinstr.uucp> chaplin@keinstr.uucp (chaplin) writes: >In article <9105012313.AA23259@enuxha.eas.asu.edu> koehnema@enuxha.eas.asu.edu (Harry Koehnemann) writes: >>In article <1259@grapevine.EBay.Sun.COM> chrisp@regenmeister.EBay.Sun.COM (Chris Prael) writes: >>>If you can't engineer software well in C, you can't engineer software >>>well period! >>> >> >>Tell that to AT&T after their 1-800 blunder. That error would have been >>less likely in different language (like Ada - I had to say that.). >> >>Harry Koehnemann >>koehnema@enuxha.eas.asu.edu > >Baloney! Read what Chris Prael said! The fact that it is *possible* to >engineer software well in *any* language does not mean that well-engineered >software is guaranteed. Perhaps the blunder would not have happened had >AT&T used Ada, but using Ada would not have guaranteed that the blunder would >not have happened. All this talk about C and software engineering reminds me of the NRA argument - guns aren't dangerous, people are dangerous. Sure, you can do software engineering in C, but most people don't. Maybe the people defending C as a software engineering tool force themselves to abide by various conventions but most people I've worked with don't. In my experience there are too many hackers out there, and they love C because it let's them hack. So, are they the dangerous ones, or is it C that's dangerous because it lets them skip the software engineering part of things and go straight to the serious hacking part. Of course, I'm sure all you fellow posters are very responsible with your guns, and I'm sure you impose a lot of discipline on your C development. I'm just not sure about all the others out there. Incidentally, C is my favorite language, and I've never worked with Ada, so I'm not biased. I just happen to think that C only works with software engineering if discipline is mixed in, and this seems to be a commodity in short supply, certain among most of the software developers I've worked with in the last ten years. So, people being people, I sort of figure I'm safer if no one has guns, and I sort of figure people do better software engineering if they have a language more conducive to it than C. Alec Sharp -- ------Any resemblance to the views of Auto-trol is purely coincidental----- Don't Reply - Send mail: alesha%auto-trol@sunpeaks.central.sun.com Alec Sharp Auto-trol Technology Corporation (303) 252-2229 12500 North Washington Street, Denver, CO 80241-2404
koehnema@ENUXHA.EAS.ASU.EDU (Harry Koehnemann) (05/06/91)
(Richard A Hammond) writes: > BULL!!! Harry, the error has nothing to do with typing, strong or weak, it > was a syntax error, according to your description. In fact, the same > error could be made in Ada, i.e. using 'exit' out of an if statement > which is inside a loop, e.g. (formatted to line up parallel constructs) But it wasn't a syntax error or the compiler would have caught it, or at least warned about it. That's part of the point - a language should allow a programmer to convey as much information as possible. I agree the error could have happened in Ada, but is it less likely? Break is an integral part of C - you cannot write a switch without it. You don't need exit in Ada. When you teach an Ada class, do you mention exit or goto? Probably not - it's like showing a child where you store your gun. Therefore, if your not using it, it can't hurt you. > As far as a language that supports "software engineering prnciples", > I fail to see how this would help in this case. The error was inside > a single module. My point is that, if proper techinques are strictly followed, errors are less likely and IMO C does not support them very well. Things like encapsulation and ADTs, separating specification from implementation, packaging, private sections, parameter modes, overloading, a powerful typing mechanism, etc. allow a programmer to express more information to a compiler and allow it to catch more 'this is a stupid thing and I'm not going to let you do it' errors. This is not very well supported in C. Granted it can be done, just like that error could have been written in Ada, but it is much more work and IMO it is not as likely to happen. However, it has been rather interesting watching people run to C's defense :). Hell, it all started out as a joking comment anyways. > In fact, I strongly suspect that some of the Ada sucess stories I've > been hearing, on closer examination are examples of the Hawthorn effect, > i.e. management pays attention to what's going on and gets better results. Good point. Many claim that the largest benefit of this entire Ada thing will be that programmers will be forced to get training. While they're learning the language, they'll also be reinforced (or introduced) to some solid principles as well. Have a nice day.... Harry Koehnemann koehnema@enuxha.eas.asu.edu
hammondr@sunroof.crd.ge.com (Richard A Hammond) (05/06/91)
In commenting about the AT&T error I wrote: As far as a language that supports "software engineering prnciples", I fail to see how this would help in this case. The error was inside a single module. In article <9105051741.AA27297@enuxha.eas.asu.edu> koehnema@enuxha.eas.asu.edu (Harry Koehnemann) replies: >My point is that, if proper techinques are strictly followed, errors >are less likely and IMO C does not support them very well. Things like >encapsulation and ADTs, separating specification from implementation, >packaging, private sections, parameter modes, overloading, a powerful >typing mechanism, etc. allow a programmer to express more information >to a compiler and allow it to catch more 'this is a stupid thing and I'm >not going to let you do it' errors. This is not very well supported in >C. Granted it can be done, just like that error could have been written >in Ada, but it is much more work and IMO it is not as likely to happen. All these are good things that Ada does, but they don't apply to the specific bug in question. The bug wasn't 'stupid' in that one could very easily really want the program to have control flow as specified. >However, it has been rather interesting watching people run to C's >defense :). Hell, it all started out as a joking comment anyways. You're wrong, I am not defending C, I am against the following logic: Premise 1: Ada supports Software Engineering better than C (I agree) Premise 2: AT&T switching code was written in C (I agree) Premise 3: AT&T switching code had a 'bug' (I agree) Conclusion: the bug would have been prevented by using Ada. (doesn't follow) If the bug had been an argument type mis-match error or some other interface error I would accept that Ada could have prevented it. But, as far as the actual error involved, it was one that put a break statement in a logically incorrect but syntactically legal location. Ada wouldn't have prevented this. Without the actual code fragment in C and what it should have been we can't even say that Ada would have made it mroe difficult. Cheers, Rich Hammond
koehnema@ENUXHA.EAS.ASU.EDU (Harry Koehnemann) (05/08/91)
[Talking about AT&T bug - using a break to transfer out of an if stmt] >All these are good things that Ada does, but they don't apply to the >specific bug in question. The bug wasn't 'stupid' in that one could >very easily really want the program to have control flow as specified. Bite your tongue :). You *want* to transfer control out of the middle of a block? Remember single entry/exit? Really, if that had been flight system software and had caused a casualty, do you think a victims lawyer would be glad or disappointed to find it was caused by that type of an error? i.e. One that they could easily show does not follow good practices. When you think about it, AT&T got off rather cheap. >You're wrong, I am not defending C, I am against the following logic: [middle logic deleted] >Conclusion: the bug would have been prevented by using Ada. (doesn't follow) But I have never said 'prevent' as you've been saying. Hell, nothing prevents errors. Can we do anything to prevent errors? No, we can simple decrease the likelyhood that they exists. All this time I've been saying 'less likely' and since 'exit' is not an integral part of Ada as 'break' is with C (you won't use it if you don't need it and you can't use it if you don't know it's there, or better yet *forbidden*), "that error might have been less likely in a different language". --orig stmt I'll talk to you by Email next time - I'm sure everones bored of this by now... Harry Koehnemann koehnema@enuxha.eas.asu.edu
chrisp@regenmeister.EBay.Sun.COM (Chris Prael) (05/09/91)
From article <1991May3.234349.14026@auto-trol.com>, by alesha@auto-trol.com (Alec Sharp): > > All this talk about C and software engineering reminds me of the NRA > argument - guns aren't dangerous, people are dangerous. Sure, you can You ever have someone come after you with a carving knife or a tire iron? I haven't either, but if someone did, it wouldn't make the least little bit of difference that neither device can throw lead. > do software engineering in C, but most people don't. Maybe the people > defending C as a software engineering tool force themselves to abide > by various conventions but most people I've worked with don't. In my > experience there are too many hackers out there, and they love C > because it let's them hack. The point that you seem to me to be missing is that the languages that attempt to force the programmer into "good" practices do no better than C. No one has built a compiler that can force you to get or develop a clear statement of requirements. No one has built a compiler that can force you to completely design the functionality of a program (or even partially, for that matter). No one has built a compiler that can force you to have peers and/or users review your design. No one has built a compiler that will force you to design how the program will implement the functionality you have arrived at. These are the processes that an "engineer" goes through, whether s/he is building software, a disk drive, a car engine, or a bridge. If you are not going through these processes, you are not an engineer and no compiler yet imagined can help or force you to be one. If you just sit down and start bashing out code, you are hacking, no matter how "clean" the code is. Chris Prael
rlk@telesoft.com (Bob Kitzberger @sation) (05/13/91)
chrisp@regenmeister.EBay.Sun.COM (Chris Prael) writes: >The point that you seem to me to be missing is that the languages that >attempt to force the programmer into "good" practices do no better than >C. Nope, that's the point that is _denied_, not missed. >No one has built a compiler that can force you to get or develop a clear >statement of requirements. No one has built a compiler that can force >you to completely design the functionality of a program (or even >partially, for that matter). No one has built a compiler that can force >you to have peers and/or users review your design. No one has built a >compiler that will force you to design how the program will implement the >functionality you have arrived at. All valid points, however, there are languages that _encourage_ good software engineering practices, e.g. separation of specification and implementation, strong type checking, inter-module dependency verification, etc. C isn't one of them. Can this honestly be denied? >These are the processes that an "engineer" goes through, whether s/he is >building software, a disk drive, a car engine, or a bridge. If you are >not going through these processes, you are not an engineer and no >compiler yet imagined can help or force you to be one. ^^^^^^^^ big difference between helping and forcing. Yes, but insistence on using a tool that discourages engineering discipline warrants justfication! Simile and analogy seem to be popular in this newsgroup lately... let me draw another. I'm marginally content that small housing structures are built with relatively quick, low accuracy techniques. HOWEVER, if a builder uses the same tools and techniques to build skyscrapers and large public buildings that he uses to slap together a condo complex, they're setting themselves up for a serious lawsuit. The tools must scale up with the complexity of the project. The complexity of software systems is growing quickly, such that there are rarely any projects under 100,000 SLOC (sweeping assumption). It borders on negligence to build these systems with nothing more than a screwdriver, a hammmer, and a level, despite any commitment to modern software engineering principles. .Bob. -- Bob Kitzberger Internet : rlk@telesoft.com TeleSoft uucp : ...!ucsd.ucsd.edu!telesoft!rlk 5959 Cornerstone Court West, San Diego, CA 92121-9891 (619) 457-2700 x163 ------------------------------------------------------------------------------ "Wretches, utter wretches, keep your hands from beans!" -- Empedocles
chrisp@regenmeister.EBay.Sun.COM (Chris Prael) (05/16/91)
From article <1264@telesoft.com>, by rlk@telesoft.com (Bob Kitzberger @sation): > All valid points, however, there are languages that _encourage_ good > software engineering practices, e.g. separation of specification and > implementation, strong type checking, inter-module dependency > verification, etc. C isn't one of them. Can this honestly be denied? It is very easy to deny for the simple reason that you are not talking about engineering practices, you are talking about software coding practices. Coding is not an engineers issue, it is a technicians issue. If you are willing to be accurate enough to assert that C++, for example, forces better CODING practices, there is no impediment to agreeing with you. But any claims that mechanisms that operate on a technicians performance is erroneously putting software engineering on teh same level as field engineering and custodial engineering. I hope that is not your intent. > Yes, but insistence on using a tool that discourages engineering > discipline warrants justfication! The problem with your assertion is that the tool, C, has no effect on ENGINEERING discipline. It does have some connection with coding discipline. In a real engineering environment, coding discipline is a very minor issue, if it is an issue at all. Sure, C lets a software blacksmith be a real slob. C++ can make the software blacksmith a much tidyer blacksmith. But neither of them can turn a blacksmith into an engineer. Chris Prael
dmg@ssc-vax (David M Geary) (05/17/91)
Chris Prael writes:
]]From article <1991May3.234349.14026@auto-trol.com], by alesha@auto-trol.com (Alec Sharp):
]]
]] argument - guns aren't dangerous, people are dangerous. Sure, you can
]] do software engineering in C, but most people don't. Maybe the people
]] defending C as a software engineering tool force themselves to abide
]] by various conventions but most people I've worked with don't. In my
]] experience there are too many hackers out there, and they love C
]] because it let's them hack.
]The point that you seem to me to be missing is that the languages that
]attempt to force the programmer into "good" practices do no better than
]C.
I'm not sure what this means - no better than C *at what*. If Chris
means that other languages' attempts to force (or help) programmers to write
better code are all failures, that is certainly arguable.
]No one has built a compiler that can force you to get or develop a clear
]statement of requirements. No one has built a compiler that can force
]you to completely design the functionality of a program (or even
]partially, for that matter). No one has built a compiler that can force
]you to have peers and/or users review your design. No one has built a
]compiler that will force you to design how the program will implement the
]functionality you have arrived at.
No one has built a compiler that washes dishes either. *Compilers* are not
meant to help you one bit with requirements, or force humans to perform
certain actions, such as reviewing a design. Compilers are meant to
produce executables from code, and help the programmer by pointing out
errors and warnings found in the code. There are *environments* available
that can assist in the things mentioned above.
Note too that IMHO, compilers have been written that do a better job of
*helping* the programmer write correct code than C compilers. C's lax type
checking of function calls is not a problem with many other languages (although
that has been alieviated with ANSI C). Eiffel for example, has assertions and
exceptions - two important tools not supported by C compilers that allow
programmers to produce better code.
]These are the processes that an "engineer" goes through, whether s/he is
]building software, a disk drive, a car engine, or a bridge. If you are
]not going through these processes, you are not an engineer and no
]compiler yet imagined can help or force you to be one.
Well, I'm not so sure. The field of software engineering is very young.
Like other "sciences", (please - no thread on whether sw engr is science and/or
engineering) I am sure that some of the things that we think are gospel today
will prove to be folly tomorrow. One example would be structured (top-down)
design, which, when used to specify a *system* is at odds with the current
methods of object-oriented programming. Thus, structured programming,
previously thought to be one of the processes that a "software engineer"
must go through to properly construct software, may turn out to be a
methodology best avoided.
]If you just sit down and start bashing out code, you are hacking, no
]matter how "clean" the code is.
I can agree with this. There is a difference between software engineering
and hacking. C has a reputation (well-deserved or not) of being used mainly
by hackers who know nothing of "software engineering principles". Like all
sterotypes this perception is to some degree true. However, it does not
automatically follow that noone can "software engineer" if they are using C.
]Chris Prael
rlk@telesoft.com (Bob Kitzberger @sation) (05/22/91)
chrisp@regenmeister.EBay.Sun.COM (Chris Prael) writes: >From article <1264@telesoft.com>, by rlk@telesoft.com (Bob Kitzberger @sation): > >> All valid points, however, there are languages that _encourage_ good >> software engineering practices, e.g. separation of specification and >> implementation, strong type checking, inter-module dependency >> verification, etc. C isn't one of them. Can this honestly be denied? > >It is very easy to deny for the simple reason that you are not talking >about engineering practices, you are talking about software coding >practices. Coding is not an engineers issue, it is a technicians >issue. The division at coding seems somewhat arbitrary... with higher levels of abstraction, your requirements tool becomes your design tool becomes your coding tool. Nonetheless, assuming that I take off my engineer's hat and put on the rumpled technicians hat when I code, I am forced to deal with the errors of my designs. Tools (and in this context, languages) that help point out flaws in design (see list in original post) help me to learn _some_ of my design mistakes earlier in the process. Being the good engineer that I am, I carry these lessons with me when I again don my engineer's hat. I maintain that separation of specification and implementation is a strong design tool, as are Ada's exceptions and Eiffel's assertions. As languages provide more and more "design level" capabilities such as these, the importance of them in the design process increases. >If you are willing to be accurate enough to assert that C++, for example, >forces better CODING practices, there is no impediment to agreeing with >you. Ah, but I used the word "encourage" (highlighted, even), not "force". BIG difference. Anybody can write FORTRAN in Ada, if they're determined. >Sure, C lets a software blacksmith be a real slob. C++ can make the >software blacksmith a much tidyer blacksmith. But neither of them can >turn a blacksmith into an engineer. Agreed. My assertion was that some languages _encourage_ better engineering practices. This is not the same assertion that some people make -- that using a certain language _forces_ better engineering practices. .Bob. -- Bob Kitzberger Internet : rlk@telesoft.com TeleSoft uucp : ...!ucsd.ucsd.edu!telesoft!rlk 5959 Cornerstone Court West, San Diego, CA 92121-9891 (619) 457-2700 x163 ------------------------------------------------------------------------------
dc@sci.UUCP (D. C. Sessions) (05/23/91)
In article <1338@grapevine.EBay.Sun.COM> chrisp@regenmeister.EBay.Sun.COM (Chris Prael) writes: # From article <1264@telesoft.com>, by rlk@telesoft.com (Bob Kitzberger @sation): # # > All valid points, however, there are languages that _encourage_ good # > software engineering practices, e.g. separation of specification and # > implementation, strong type checking, inter-module dependency # > verification, etc. C isn't one of them. Can this honestly be denied? # # It is very easy to deny for the simple reason that you are not talking # about engineering practices, you are talking about software coding # practices. Coding is not an engineers issue, it is a technicians # issue. [etc. -- dcs] # Chris Prael We seem to have some major differences between our definitions of "engineering". From where I sit (which is frequently behind a soldering iron) engineers are the folks who *document* the *process* which results in a *product*. I wish *I* could get away with telling the manufacturing department that a calibration procedure "is not an engineers issue, it is a technicians issue". (I won't, though -- I need the work!) An engineer doesn't live in lofty isolation from the grungy details of production. Instead, most of an engineer's work concerns making the most cost-effective use of the "materials" available. If that means steel instead of carbon composites, or 7400 TTL instead of the latest GaAs logic, or C instead of Ada; well, so be it. If s/he *does* end up with steel instead of fiber, though, the design had better be optimized for steel. Similarly, if the mandated toolset only supports global scoping a competant software engineer plans in the manual symbol-space management instead of whining "that's not my job." ---------------------------------------------------------------------- Sorry, folks. My sysadmin informed us today that the company is cutting our net access to save on phone bills. I guess I won't be getting any flames, will I? ---------------------------------------------------------------------- -- | The above opinions may not be original, but they are mine and mine alone. | | "While it may not be for you to complete the task, | | neither are you free to refrain from it." | +-=-=- (I wish this _was_ original!) D. C. Sessions -=-=-+