>The challenge wasn't overwhelming complexity, as it is today. The challenge was cramming your ideas into machines so slow, so limited that most ideas didn't fit.
I like this line right here. It does seem like we've piled on abstraction after abstraction in these days. Sure this does make things easier, but I think things have gotten so complex that it's much harder to have a complete mental model of what your code is actually doing than in the simpler machines of the past.
There's totally a parallel between this and the video game music of Mario, Zelda and Final Fantasy- they could only play 2-3 notes at once, so they had to work with those constraints. The music couldn't be too complex, so every note had to go really, really far. The result? Extremely memorable tunes with catchy melodies. It was a matter of necessity.
There's a lot to be said about creativity coming from being forced to deal with constraints. It's counterintuitive, but we get most juiced about solving problems when they're tough. It's hardest to start writing when it's blank piece of paper.
When people think of "complexity" in regards to music, they often think of instrumentation, texture, production quality. But some of the most complex music ever written - the Well-Tempered Klavier - was written in mostly 2-4 voices for an instrument with no dynamics. I think the 2-3 note limit really forced chiptune composers to focus on compositional complexity, thus making that music stand out even today.
Honestly I think a lot of this is nostalgia - I grew up with the c64, never had a NES. I enjoy chiptunes but none of the NES stuff really does much for me. I think you have to have had this stuff embedded into your brain by repeated play. I've listened to NES music and haven't had an urge to listen to it enough to learn and hum it, but I could totally hum the eerie opening theme to Parallax, the driving pseudo-Jarre of The Last V8, the electro-rock of Oxxonian, and more.
I'm not entirely sure it's all nostalgia; the c64's sound chip was a bit more flexible than the NES's, and there was a real culture of musicians on the c64, so I may have just gotten used to a higher level of musicianship as a base.
And I'd say today there's a tendency to overabstract and overdesign stuff.
In today's world of "everything fits", some modern developers don't try to "bottom align" their code, but rather "top align". No, a hello world app doesn't need an XML config file.
Of course, not being constrained by machine limitation anymore (unless you're doing video/simulations/games etc) is a blessing
I'm more a fan of 'seat of your pants' programming but to be fair, if abstractions are good they are meant to be a solid bedrock upon which to build a higher level mental model. For example, assembly is one such bedrock - you don't need to understand microcode or transistors to get the most out of it. C is arguably another, Java arguably another (understanding the JVM is nice but not essential).
It's only due to the deficiencies within certain abstractions that it frequently becomes necessary to subordinate and go lower down the chain.
If and only if the abstraction isn't leaky. Unfortunately, non-leaky abstraction layers are exceedingly rare, to the point that I now believe most software engineers don't even aim at trying to avoid leakage in their designs.
If every abstraction were perfect, sure. Of course, they never are, and you will always, at some point, need to understand what your code is actually doing in order to solve a problem.
This is why I love microcontroller programming (but not Arduino, which loses the magic to "high level"). I wrote some PIC24 code where I needed some very fast deterministic interrupt handler[1], so I dropped down to assembly and cycle-counted my way to success. It was nothing nearly as fancy as the article describes. It was really just the ability to accurately count cycles.
[1] I was basically sharing buffers between SPI send/recv interrupts and the code that used them, so I needed a way to lock buffers. I later replaced the code with much simpler, much slower synchronous code.. :-/
I thought exactly the same thing. Read the whole article in my lunch break after getting po'ed at some stupidly complex PHP code written in a Java idiom spread across 5+ files.
I like this line right here. It does seem like we've piled on abstraction after abstraction in these days. Sure this does make things easier, but I think things have gotten so complex that it's much harder to have a complete mental model of what your code is actually doing than in the simpler machines of the past.