Hi
I am a corporate programmer drone and yes, you are right, someone like Mel would not be very suitable. But that doesn't mean todays software building is any easier. Yes, I don't need to know numeric codes of the machine instructions, and I don't write code which modify itself. But the challenges are not lesser - we need to think about how to meaningfully build those layers of abstractions, how the pieces of software will communicate efficiently to each other (sometimes asynchronously), how to build the modules to be both maintanable and expandable, etc. etc...
When I was a student, I played with machine code and assembler and cracking etc., so I have some knowledge of all the layers, but I don't think that qualifies me to be a so-called Real Programmer. ;-)
The problem with corporate programming is not the layers of abstractions or asynchronous communication etc. The real problem is the staggering incompetence of most people involved in the process.
the real problem, is that software languages have not yet caught up with hardware. if software was as powerful now, as code is now, you used to be able to use one instruction and have a computer turn for a millisecond or so. yes it was slow, but it was still faster than having a person process 2 numbers and then add them, or divide them etc...
now i find it hard to find 'useful' instructions that actually take 1ms of processing time. heck, TI's lates micro controllers can turn on and off, and still stabilize analog circuits in less than 1ms now.
new processes and neural networks are becoming more practical every day as information overflow, and processing abundance are allowing us to write code on sample sets, and probabilities.
When I was a student, I played with machine code and assembler and cracking etc., so I have some knowledge of all the layers, but I don't think that qualifies me to be a so-called Real Programmer. ;-)