Hacker News Reader

I also don't get the premise; e.g. while low level details have changed (in fact, for the worse and then for the better, e.g. memory management), the basic principles of software engineering I learned in the late '70s are just as valid. At the high level of modularity is a win. Non-local action, be it gotos then, or, say, call-backs today, is powerful but dangerous and confusing. Collect requirements before doing design. Do things from the top down and the bottom up as they make sense. Etc.

> What if you happen to enjoy old-school programming?

This describes me all too well. :-(

> Ask yourself, or a software developer of a certain age: what were the guidelines for crafting excellent software 5 years ago? 10 years ago? 20 years ago? The farther back one goes, the less relevant the answers will be to our modern craft. Memory management? Not a significant issue for most programmers today. Multitasking? Obliterated by modern operating systems with efficient context switches. Concurrent programming? Constantly reinvented in the wake of multi-core CPUs, GPUs, and higher-level programming language features.

Uh what? I guess I don't really get the OP's premise here. While the specifics and priorities change, I don't see how mastering the best practices in any of these areas is in danger of becoming obsolete. For example, threadsafe implementation seems like an engineering skill/mindset that will apply across many platforms and architectures.

For now perhaps.. I think the point he was trying to make is that even those areas are changing over time. Who is to say eventually that hardware or a language won't make them redundant? Just look at the leaps and bounds Go is making for example.

Ummm, what's so new and special about Go?

The Imperfect Craft