You can make a small program (say, 1,000 lines) work through brute force even when breaking every rule of good style. For a larger program, this is simply not so. If the structure of a 100,000-line program is bad, you will find that new errors are introduced as fast as old ones are removed.
Interesting, it seems like best practices are easy to teach (just follow these simple rules!), and the dysfunctional thing I’d expect would be for professors to tell you to follow them but not tell you why.
the dysfunctional thing I’d expect would be for professors to tell you to follow them but not tell you why.
That’s the failure mode that most of my profs fell into. When I was in school, there was a strong emphasis on correct style—in the extreme case, for example, some professors would fail an assignment if it didn’t have a high enough fraction of comments to functional code—but very little to suggest a coherent theory of software engineering.
From what I remember, most of my peers approached it with the attitude of being just another hoop to jump through.
One dysfunctional thing I’d expect would be the existence or perceived existence of a contrary movement, using the word “dogma” and saying things like “worse is better” and “if it’s stupid but it works, it isn’t stupid” and “those ivory-tower academics never have to deal with real-world problems” and “when theory and practice clash, theory loses”.
For example, this article makes a specific point about a specific situation (mixed in with some crazy), but might still leave one with an impression of “boo carefully planned programs, yay big hairy messes where you don’t know what half the API calls are for”.
Also, general hyperbolic discounting and programmers just not caring.
Maybe they do, now. When I was in CS, we had no classes on software engineering. But that was a long time ago, in CS terms. So you should not believe that I know what I’m talking about.
Ironic to hear that coming from Stroustrup. The language he has created, C++, is notorious for allowing the programmer to make a wide variety of very subtle errors that are impossible in most other languages.
Yeah, to someone unfamiliar with the topic it would seem that I make very strong statements. “Very subtle”? “Impossible in most other languages”? But the crazy truth is, my words are completely warranted. The most well-known example: after the addition of exceptions and templates to the language, it took several years for people to realize that writing exception-safe template code is a minefield (see Tom Cargill’s 1994 article), and three more years till anyone proposed a valid solution (Herb Sutter in 1997). Note that generic containers were one of the major motivations for templates in the first place! So we see seven years passing from introduction of a feature into a widely-used language, to the first time someone manages to correctly use the feature for its intended purpose.
The good news is, the language is still growing. I think I can confidently predict that when (if) the new standard comes out, people will be finding weird new interactions between features for years to come. I mean, just read that Wikipedia article from beginning to end, and try to tell me you disagree :-)
-- Bjarne Stroustrup
They should teach this in college!
I don’t recall my professors ever making the point that the way we wrote short programs for class would not always work on large programs.
Interesting, it seems like best practices are easy to teach (just follow these simple rules!), and the dysfunctional thing I’d expect would be for professors to tell you to follow them but not tell you why.
Updated.
That’s the failure mode that most of my profs fell into. When I was in school, there was a strong emphasis on correct style—in the extreme case, for example, some professors would fail an assignment if it didn’t have a high enough fraction of comments to functional code—but very little to suggest a coherent theory of software engineering.
From what I remember, most of my peers approached it with the attitude of being just another hoop to jump through.
One dysfunctional thing I’d expect would be the existence or perceived existence of a contrary movement, using the word “dogma” and saying things like “worse is better” and “if it’s stupid but it works, it isn’t stupid” and “those ivory-tower academics never have to deal with real-world problems” and “when theory and practice clash, theory loses”.
For example, this article makes a specific point about a specific situation (mixed in with some crazy), but might still leave one with an impression of “boo carefully planned programs, yay big hairy messes where you don’t know what half the API calls are for”.
Also, general hyperbolic discounting and programmers just not caring.
Also, sort of implied by that: methodologies that don’t actually work.
Unexpectedly semi-relevant: the latest xkcd, Good Code.
Maybe they do, now. When I was in CS, we had no classes on software engineering. But that was a long time ago, in CS terms. So you should not believe that I know what I’m talking about.
Ironic to hear that coming from Stroustrup. The language he has created, C++, is notorious for allowing the programmer to make a wide variety of very subtle errors that are impossible in most other languages.
Yeah, to someone unfamiliar with the topic it would seem that I make very strong statements. “Very subtle”? “Impossible in most other languages”? But the crazy truth is, my words are completely warranted. The most well-known example: after the addition of exceptions and templates to the language, it took several years for people to realize that writing exception-safe template code is a minefield (see Tom Cargill’s 1994 article), and three more years till anyone proposed a valid solution (Herb Sutter in 1997). Note that generic containers were one of the major motivations for templates in the first place! So we see seven years passing from introduction of a feature into a widely-used language, to the first time someone manages to correctly use the feature for its intended purpose.
The good news is, the language is still growing. I think I can confidently predict that when (if) the new standard comes out, people will be finding weird new interactions between features for years to come. I mean, just read that Wikipedia article from beginning to end, and try to tell me you disagree :-)