Hungarian notation and other language limitations
Credited to Microsoft's Charles Simonyi, who hailed from Hungary, Hungarian notation is a naming convention that was used primarily by those writing for Windows.
It added a prefix to an identifier name to indicate its functional type. For instance, "pX" indicated that the function was a pointer to X. If you changed the identifier's type, you'd have to rename the variable; that caused some ugly patches.
Although some developers continue to use Hungarian notation today, it's generally unnecessary; most text editors instantly tell you the variable type.
Honorable mention:
- Fortran's formatted input and variable names bound to types (variables beginning with I, J and K were always integers)
- BASIC code requiring line numbers
- Initializing all variables to known values
- Null-terminating C strings
Doing strange things to make code run faster
Throughout programming's (relatively) early history, it was common to rely on undocumented features, such as with the early Windows API. Visual Basic programming required poking at Windows' internals, many of which were undocumented hacks. Naturally, these hacks regularly broke every time Microsoft released a new version of Windows, or sometimes just because of a security patch.
Nowadays, everything is well documented and trustworthy. Yeah. Sure it is.
Honorable mention:
- Writing your own utilities to search for where you'd used functions or procedures and where you'd called them
- Manually optimizing the compiler's generated code to meet a project's performance goals
- Using one-letter variable names in a BASIC interpreter because you could see the increase in execution speed
Being patient
It's hard to explain how slowly programming happened back in the day. You started a compile and went to lunch. When compile time took several hours, you wrote as much code as possible and then dove into a multipart debugging session.
Unfortunately, as most programmers know, the more things you mess with, the harder it is to find the bug causing the problem. Instead of writing and debugging one routine at a time, it took weeks to get the code written and tested.
To speed up development time, programmers would arrive at the office at some ungodly hour in the morning to get dedicated time on the mainframe (if they weren't paying per CPU cycle on a time-sharing system).
The only benefit of the long debug cycles was that it made programmers think about their code rather than slapping it together. And we had time for lunch.
What else?
What old-school programming skills are you glad you don't need today? Tell us in the comments.
Esther Schindler has been writing about technology since 1992, and she started programming in 1973. She won't admit how many of the techniques in this story she used, but she still has a few Hollerith cards floating around.