Old-school programming techniques you probably don't miss

11 skills and tactics that every programmer once needed to master ... and today can blissfully forget

Go To and spaghetti code ...

... or really, any programming methodology before structured programming and object-oriented development came along -- except only prissy academics used words like "methodology" back then, and most of us didn't have a college degree.

In many early programming languages, the application flow was controlled by instructions like GOTO 10, whereupon the code would jump to Label 10, which might or might not appear between 9 and 11, and continue execution. It was frighteningly easy to jump over and into code, creating a Gordian knot of executable code that became a maintenance migraine, giving rise to the pejorative term " spaghetti code."

Structured programming, which suggested that code could be categorized into decisions, sequences and loops, "was a godsend in the '70s ... much better than the 'code now, design later' approach it replaced," says Jay Elkes, who was a Cobol programmer back then. (I must note, however, that the seminal 1968 article "Go To Statement Considered Harmful," penned by structured programming proponent Edsger Dijkstra, spawned entirely too many "...Considered Harmful" parodies.)

Newer object-oriented languages, starting with C++ in the early '90s, eliminated the need for structured programming -- which hasn't kept some developers from going full circle to reinvent Go To on their own.

Manual multithreading and multitasking

Today, we expect our computers to do many things simultaneously through multitasking (running multiple processes on a single operating system) and multithreading (running multiple processes, or threads of execution, in a program). But early PC operating systems such as CP/M and MS-DOS were built to do just one thing at a time.

Brilliant programmers with specialized knowledge could hack alternatives, but it was a messy and painful experience. C programmers, for example, might turn to setjump and longjump to implement threads, which was a recipe for a long weekend of debugging accompanied by at least three pots of coffee.

Multithreading still isn't easy, but development tools and operating systems have streamlined the process. Since the introduction of Windows 2000, for example, developers have been able to use overlapped I/O to enable an auto-scaling multithreading platform, points out Dan Rosanova, principal consultant at Nova Enterprise Systems. That works "much better than the old ' start x threads to do y,'" he notes.

Honorable mention:

Writing Terminate-and-Stay-Resident (TSR) routines, an early and very popular hack toward multitasking, on MS-DOS. "One system call -- a specific group of register settings left in place when you invoked Interrupt 21h -- had the effect of returning control to DOS but leaving your code in allocated heap space," remembers Mark W. Schumann, software developer at Critical Results, who got started in college making things work on a DEC PDP-11.

"If you also redirected, for example, Interrupt 9 -- keyboard handler -- to point at your own code, which then chained back to the original interrupt vector, your code would be executed just before normal handling of the keystroke," continues Schumann. "That's how you wrote 'pop-up' programs back in the day. You had to be careful about file-system operations because DOS itself wasn't re-entrant, and you had to make your code extra-fast so it wouldn't mask the next interrupt."

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags software developmentprogramming language

More about APLAppleAustralian Securities & Investment CommissionLinuxMicrosoftTSRWikipediaWYSIWYG

Show Comments
[]