Old-School Coding Techniques You May Not Miss

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?"

Comments

Some, not all...

[bsDaemon]

Some of those are obnoxious and good to see them gone. Others, not so much. For instance, sorting/searching algorithms, data structures, etc. Don't they still make you code these things in school? Isn't it good to know how they work and why?

On the other hand, yeah... fuck punch cards.

Re:Some, not all...

[SanityInAnarchy]

any programmer who can't do a list, hash table, bubble sort, or btree at the drop of a hat ought to be kicked out of the industry.

Why?

Lists, hash tables, and sorting is already built in to many languages, including my language of choice. The rest, I can easily find in a library.

When performance starts to matter, and my profiling tool indicates that the sorting algorithm is to blame, then I'll consider using an alternate algorithm. But even then, there's a fair chance I'll leave it alone and buy more hardware -- see, the built-in sorting algorithm is in C. Therefore, to beat it, it has to be really inappropriate, or I have to also write that algorithm in C.

It's far more important that I know the performance quirks of my language of choice -- for instance, string interpolation is faster than any sort of string concatenator, which is faster than straight-up string concatenation ('foo' + 'bar').

And it's far more important that I know when to optimize.

Now, any programmer who couldn't do these at all should be kicked out of the industry. I could very likely code one quickly from the Wikipedia article on the subject. But by and large, the article is right -- there's a vast majority of places where these just don't matter anymore.

Not that there's nowhere they matter at all -- there are still places where asm is required. They're just a tiny minority these days.

Re:Some, not all...

[Ruie]

any programmer who can't do a list, hash table, bubble sort, or btree at the drop of a hat ought to be kicked out of the industry.

Why?

Because if these well known tasks are difficult for them their job title is really typist, not programmer. The challenge is not to write bubble sort day in and day out, but being several levels above that so it is as easy as computing six times seven or reading road signs.

Re:Some, not all...

[Unoriginal_Nickname]

I'll agree with you for most of what you said, but I disagree that programmers should learn to implement sorting algorithms. Unless they're doing serious research on the subject it's doubtful that Joe Programmer is going to be whipping up a sorting algorithm that's better than the one provided.

What you're suggesting here isn't like a mathematician not understanding calculus. It's more like a mathematician only having pi memorized to the 8th decimal. I see zero value in learning to parrot quicksort, especially since the information is easily obtained and the implementation you use is almost certainly as fast as is possible (assuming you aren't Abrash).

Re:Some, not all...

[Garridan]

Recently, I had a colleague ask me what sorting algorithm he should use in the inner loop of some algorithm he was implementing. Most CS majors I've talked to just blurt out "QUICKSORT!" without thought. Ok, that's got an average runtime of nlg(n). After about an hour of discussion and analysis, we came up with an algorithm that ran in sub-linear time. Now's the time for the CS kids to blurt, "ZOMG, but you can't sort in less than O(nlg(n)!" Ah, but you can, if you know what your input is going to look like.

When a function gets executed billions or trillions of times, it's worth optimizing. Often times, doubling the speed of a deep internal function does nothing -- other times, it can cut the runtime of your program in half. I come from a mathematical background, and I do lots of computation. Often times, it can take a year or more to solve a problem with a quick implementation. Spend a few weeks optimizing it, and you might be able to solve the problem in a few hours.

There is no substitute for analyzing your code. And I do mean, sitting down with a writing implement and a blank surface, and tracing through the algorithm. Then, profiling the code and hammering down hotspots. And then, take a page out of Knuth's book -- throw the code away, and write it again.

Re:Some, not all...

[Anonymous Coward]

*different* AC

Why, why, why do people get SO offended when you tell them they have to learn computers to be good at computers?

People expect to learn engineering to be a mechanic. To study biology if they want to be a surgeon. Hell, to read a cookbook just to learn how to cook.

But answer "How do I program?" with "Well, there's this manual, see..." and you get "Elitist! Elitist! Hey everybody, come see the arrogant condescending elitist who's persecuting me! Come and see the violence inherent in the sys-teeeem!"

Fine then, let's start telling everybody it's magic. Get some chicken bones and some goat's blood and some black candles...

Re:Some, not all...

[16Chapel]

Number of times I had to implement sorting algorithms for my degree: 3

Number of times I've had to implement sorting algorithms in my 10 year career: 0

They make good teaching exercises, but any programmer in my team who wasted time building their own sorting algorithms rather than using a library function, would get a few sharp words about efficiency.

Yes, I'm old

[QuantumG]

* Sorting algorithms

If you don't know them, you're not a programmer. If you don't ever implement them, you're likely shipping more library code than application code.

* Creating your own GUIs

Umm.. well actually..

* GO TO and spaghetti code

goto is considered harmful, but it doesn't mean it isn't useful. Spaghetti code, yeah, that's the norm.

* Manual multithreading

All the time. select() is your friend, learn it.

* Self-modifying code

Yup, I actually write asm code.. plus he mentions "modifying the code while it's running".. if you can't do that, you shouldn't be wielding a debugger, edit and continue, my ass.

* Memory management

Yeah, garbage collection is cheap and ubiquitous, and I'm one of the few people that has used C++ garbage collection libraries in serious projects.. that said, I've written my own implementations of malloc/free/realloc and gotten better memory performance. It's what real programmers do to make 64 gig of RAM enough for anyone.

* Working with punch cards

Meh, I'm not that old. But when I was a kid I wrote a lot of:

100 DATA 96,72,34,87,232,37,49,82,35,47,236,71,231,234,207,102,37,85,43,78,45,26,58,35,3
110 DATA 32,154,136,72,131,134,207,102,37,185,43,78,45,26,58,35,3,82,207,34,78,23,68,127

on the C64.

* Math and date conversions

Every day.

* Hungarian notation

Every day. How about we throw in some reverse polish notation too.. get a Polka going.

* Making code run faster

Every fucking day. If you don't do this then you're a dweeb who might as well be coding in php.

* Being patient

"Hey, we had a crash 42 hours into the run, can you take a look?"
"Sure, it'll take me about 120 hours to get to it with a debug build."

OO isn't even different.

[jd]

There is no practical difference between OO code and structured code. The article assumed structured code means goto and gosub, but any Real Programmer knows that procedures (which are just gosubs by name rather than address) are still structured programming.

So what's OO? Each class is just a bunch of functions and procedures, with one entry point and one exit point for each - your standard structured programming methodology. The fact that there are different classes makes no difference. Calls between classes don't change the nature of a class any more than pipes between programs change the nature of programs.

I wasn't impressed by other claims, either. Garbage collection is still a major headache in coding, which is why there are so many debugging mallocs and so many re-implementations of malloc() for specialist purposes. Memory leaks are still far, far too common - indeed they're probably the number 1 cause of crashes these days.

Pointer arithmetic? Still very very common. If you want to access data in an internal database quickly, you don't use SQL. You use a hash lookup and offset your pointer.

Sorts? Who the hell uses a sort library? Sort libraries are necessarily generic, but applications often need to be efficient. Particularly if they're real-time or HPC. Even mundane programmers would not dream of using a generic library that includes sorts they'll never refer to in, say, an e-mail client or a game. They'll write their own.

One of the reasons people will choose a malloc() like hoard, or an accelerated library like liboil is that the standard stuff is crappy for anything but doing standard stuff. This isn't the fault of the glibc folks, it's the fault of computers for not being infinitely fast and the fault of code not being absolutely identical between tasks.

The reason a lot of these rules were developed was that you needed to be able to write reusable code that also had a high degree of correctness. Today, you STILL need to be able to write reusable code that also has a high degree of correctness. If anything, the need for correctness has increased as security flaws become all the more easily exploited, and the need for reusability has increased as code bases are often just too large to be refactored on every version. (Reusability is just as important between versions as it is between programs - a thing coders often forget, forcing horrible API and ABI breakages.)

The reason that software today is really no better, stability-wise, than it was 15-30 years ago is that new coders think they can ignore the old lessons because they're "doing something different", only to learn later on that really they aren't.

Re:True story

[fractoid]

My mother, who was programming before a fair few of us (including me) were born, once told me this: If you think you've found a bug in a compiler, or an operating system, or a programming language, or a well-known commonly used library... you're wrong.

Of course, this doesn't hold true 100% of the time, especially when you're pushing the limits of new versions of large 3rd party libraries, but when one is just starting to program (and hence using very well known, well tested libraries and code) it's true 99.99% of the time.

(Oh, btw, I love your sig. Makes me laugh every time. :)