|
Post by tofu on Sept 19, 2007 12:00:53 GMT -4
I don't disagree that much fault lies with programmers themselves. My boss's boss is actually quite brilliant and technically competent, and I have a lot of respect for her, but she's famous around here for writing stuff like this: if (condition) { (tab char)blah blah } else { (tab char)more blah } and once I found a whole block of this: write ("some text ") as opposed to, write("some text\n"). And it bit me because I enclosed it in an if and dutifully indented the block, which resulted in the equivalent of this: write("some text\n\t"). Good times, good times. On the other hand, my immediate supervisor is such a stickler for good code that his comments are complete sentences with capitalization, punctuation, and everything.
|
|
|
Post by JayUtah on Sept 19, 2007 12:27:09 GMT -4
Friends don't let friends program in COBOL.
But well-written COBOL is better than badly-written, say, Perl. Yes, there's something spine-tingling about ADD DAILY-HOURS TO WEEKLY-HOURS GIVING WEEKLY-HOURS, but I'd rather have that in a program I need to maintain than some obscure (and likely broken) regular expression substitution that took the original programmer half an hour to figure out how to do in the cleverest way possible, but now he can't remember exactly what it does. I've literally seen code written by self-absorbed Perl jockeys that uses regular expression substitution on strings to implement otherwise straightforward arithmetic, just because they could.
That's one of the factors that affect software engineering. Languages and the operating systems and hardware on which they are commonly used give rise to cultures that exhibit particular traits, both positive and negative. One negative aspect of the Perl culture is that since there are eight ways to do any one thing in Perl, you should use all eight ways in every program. Shops that make money programming in Perl do so only when they use a decreed subset of the language.
|
|
|
Post by JayUtah on Sept 19, 2007 12:44:32 GMT -4
On the other hand, my immediate supervisor is such a stickler for good code that his comments are complete sentences with capitalization, punctuation, and everything.
As, usually, are mine. Program code must be comprehensible to another programmer if it is to be useful. It must be clearly formatted and easy to read. It must be modular. It must express clearly the underlying process or algorithm and refer clearly to the associated problem space. Use straightforward constructs where possible and eschew cleverness where unnecessary. Do it right the first time. Don't optimize prospectively; optimize retrospectively.
The computer largely doesn't care what your code looks like. And unless you're solving a linear system with millions of unknowns, it probably doesn't matter too much how fast your code runs, so use a simple linked list or a dynamic array to store your hundred items instead of a Wanker-Wonkley depth-balanced hypertree, which you've almost certainly implemented wrong.
But the next programmer will care immensely what your code looks like and how straightforwardly it has been implemented. The maintainability of your code dictates in factors of 2 or 3 (sometimes up to 10) how costly it will be to service defect reports and change requests, and thus how viable your product is in the market. And the next programmer may be you, in six months after you've forgotten what you were doing when you originally wrote the code, and have gotten over the "time savings" you achieved by hacking it out quickly rather than planning and executing properly.
|
|
|
Post by tofu on Sept 19, 2007 14:20:57 GMT -4
Program code must be comprehensible to another programmer if it is to be useful. It must be clearly formatted and easy to read. It must be modular. It must express clearly the underlying process or algorithm and refer clearly to the associated problem space. Use straightforward constructs where possible and eschew cleverness where unnecessary. Do it right the first time. Don't optimize prospectively; optimize retrospectively. Something interesting to think about. When a house is built, the builder has to meet certain codes and standards set by the government. We actually pay more and wait longer for our houses because of these building codes, but people are willing to pay it. If you had to make a decision between two contractors, and one of them said, "I can build this house for $100k and deliver it in 6 months." And the other one said, "I can build this house for $150k and deliver it in 9 months, but the wiring wont start a fire and the roof will not leak." You would likely pick the second contractor. However, when it comes to software, people will invariably pick contractor A. Fast and cheap is all that matters. I've never seen a customer who cared about correctness. There's a great website that posts stories of people making the fast/cheap-in-lieu-of-correct decision: worsethanfailure.com/Default.aspx
|
|
|
Post by Joe Durnavich on Sept 19, 2007 14:27:07 GMT -4
Look, Joe, you're among friends, so if you need to admit this, well, we're here for you.
Hey, some like to read about Apollo-era technology; others like to live it...
|
|
|
Post by JayUtah on Sept 19, 2007 14:44:19 GMT -4
As I said, this is a topic on which I can speak in book-length volumes.
Hastily-written code also has coupling issues. Not only would the cheaply and quickly built house suffer the likelihood of failure from its component systems, but every wall would be load-bearing, the television would be set into the wall in concrete, there would be only one light switch for all the lights in the house, and the washer would work only when the microwave was plugged in.
Tight interactive coupling is the single most prevalent problem with modern software practice, yet none of the practitioners whom I've consulted for seem to understand what it is or why it's a problem.
|
|
|
Post by PhantomWolf on Sept 19, 2007 18:11:25 GMT -4
The computer largely doesn't care what your code looks like. And unless you're solving a linear system with millions of unknowns, it probably doesn't matter too much how fast your code runs, so use a simple linked list or a dynamic array to store your hundred items instead of a Wanker-Wonkley depth-balanced hypertree, which you've almost certainly implemented wrong. Heh, next you'll be saying that we shouldn't go around creating a peudo-pointer system in Javascript to store which rows of a table the user selects or deselects.
|
|
|
Post by JayUtah on Sept 19, 2007 18:37:54 GMT -4
In my opinion there's not much you can do to make Javascript worse.
|
|
|
Post by pzkpfw on Sept 19, 2007 20:37:58 GMT -4
In my opinion there's not much you can do to make Javascript worse. Call it "Ajax" and use it continue using browsers for what they were never designed to do.
|
|
|
Post by homobibiens on Sept 19, 2007 23:12:27 GMT -4
The computer largely doesn't care what your code looks like. And unless you're solving a linear system with millions of unknowns, it probably doesn't matter too much how fast your code runs, Even pretty simple partial differential equations can bring most computers to their knees. Or they would, if computers had knees. so use a simple linked list or a dynamic array to store your hundred items instead of a Wanker-Wonkley depth-balanced hypertree, which you've almost certainly implemented wrong. Uh, the Wanker-Wonkley hypertree is a made up thing, or so I hope.
|
|
|
Post by Joe Durnavich on Sept 19, 2007 23:42:09 GMT -4
Yes, there's something spine-tingling about ADD DAILY-HOURS TO WEEKLY-HOURS GIVING WEEKLY-HOURS, but I'd rather have that in a program I need to maintain...
Yeah, the ADD statement provides very little rope with which you can hang yourself or the next programmer. (And not that this is going to make COBOL any more palatable, but in this case you could have written just: ADD DAILY-HOURS TO WEEKLY-HOURS.)
...than some obscure (and likely broken) regular expression substitution that took the original programmer half an hour to figure out how to do in the cleverest way possible, but now he can't remember exactly what it does.
Even in this case, the problem likely is isolated to a small, well-defined region of a single program, although it may not be clear exactly what that problem is.
Tight interactive coupling is the single most prevalent problem with modern software practice,
These dependencies can become frustratingly complex and intricate over time. Every additional change to the system only makes things worse. Beyond a certain point, a paralysis sets in in which nobody is brave enough to make a change to one part of the system for customer A for fear of breaking another part of the system that some other customer might depend on.
One challenge is how to prevent such tight coupling from developing in systems that are incrementally modified over many years by a programming staff with a high turnover rate in a world that is constantly changing.
|
|
|
Post by BertL on Sept 20, 2007 2:12:59 GMT -4
Talking about off-topic...
|
|
|
Post by Mr Gorsky on Sept 20, 2007 4:16:24 GMT -4
I always thought COBOL was the home of the Gods in Battlestar Galactica ... but what do I know.
|
|
|
Post by Joe Durnavich on Sept 20, 2007 8:04:05 GMT -4
Talking about off-topic...
My apologies. I of all people should be more mindful of this.
So, is IDW the fellow that whatever expertise or credentials are needed at any point in an argument, he manages to have them?
|
|
|
Post by Grand Lunar on Sept 20, 2007 8:40:15 GMT -4
From his brief stay, I gathered that he was someone that made claims, didn't back them up, and asked to be banned when he found he couldn't defend his claims. I believe he asked to be banned in hopes that his posts would go away, making it look like we censored him. Then he could claim to be an HB martyr. Unfortunately for him, his request to be banned remains in plain site.
BTW, and comments by computer folks about C++?
|
|