Old-School Coding Techniques You May Not Miss 731
CWmike writes "Despite its complexity, the software development process has gotten better over the years. 'Mature' programmers remember manual intervention and hand-tuning. Today's dev tools automatically perform complex functions that once had to be written explicitly. And most developers are glad of it. Yet, young whippersnappers may not even be aware that we old fogies had to do these things manually. Esther Schindler asked several longtime developers for their top old-school programming headaches and added many of her own to boot. Working with punch cards? Hungarian notation?"
Universal timeless programmer problem (Score:5, Funny)
Re:Dirty old Fortran (Score:4, Funny)
Years ago I programmed with a true genius. His language of choice was PL/1, but sometimes he had to use FORTRAN to fit in with what other people were doing. Any fool could write FORTRAN code in any language they wanted, but he was the only man I ever saw write PL/1 in FORTRAN.
Old school coding problems... (Score:3, Funny)
1. Writing on a slate. Man, did that compile slow!
2. When you heard "stack," it meant firewood.
3. The error message was a ruler across the knuckles.
4. Memory overloads. My own memory, I mean.
5. If you wanted to change your resolution, you had to wait until New Years.
6. Try coding when you're drinking the original mountain dew.
7. The rantings of code guru SFBM, the inventor of open Morse code.
Re:Hungarian Notation (Score:4, Funny)
I don't get what the big deal is with Hungarian Notation. Why do people consider it a bad thing?
The proper name is Hungarian Line Noise, which should answer your question.
And more cargo-cultism (Score:5, Funny)
And a few more examples of cargo-cultism, from people who were untrained to understand what they're doing, but someone thought it was ok because the Java standard library does it for them anyway.
1. The same Wally 1 from the previous story had written basically this method:
Then he called it like this, to try to get around an immutable field in an object. Let's say we have an object called Name, which has an immutable String. So you create it with that string and can't change it afterwards. You have a getName() but not a setName() on it. So he tried to do essentially:
I understand that he worked a week on trying to debug into why it doesn't work, until he asked for help.
2. From Ted's aforementioned project:
So they used the wrapper classes like Integer or Character all over the place instead of int or char. This was back in Java 1.3 times too, so there was no automatic boxing and unboxing. The whole code was a mess of getting the values boxed as parameters, unboxing them, doing some maths, boxing the result. Lather, rinse, repeat.
I ask what that's all about.
"Oh, that's a clever optimization Ted came up with. See, if you have the normal int as a parameter, Java copies the whole integer on the stack. But if you use Integer it only copies a pointer to it."
AAARGH!
Re:Some, not all... (Score:1, Funny)
I thought that people who understood the force were called Jedis...
Re:True story (Score:4, Funny)
So Wally 1 keeps clicking and staring at the screen all week and spewing things like "Unbelievable!" every 5 minutes. My curiosity gets the better of me and I ask what's happening.
Is it just me who would be_much_ more tempted to say, "You keep using that word. I don't think it means what you think it means."
(Yes, I know it's a slight misquote, but it's close enough to be really tempting...)
Re:The Story of Mel (Score:3, Funny)
Re:Some, not all... (Score:2, Funny)
On the other hand, yeah... fuck punch cards.
Oh, that is so *not* the way to program punch cards ...
Re:Ya I would compare it to long division (Score:5, Funny)
Re:Some, not all... (Score:3, Funny)
</Lisp_FTW>
Re:True story (Score:3, Funny)