I guess I'm a sucker for these programmers of yore stories. Yes, Mel would be an unsuitable candidate for most modern, team-oriented programming positions. But, heck, to be truly one with the machine in understanding all of its nuances is extraordinary. (Yes, the machines were smaller and simpler then, but still...)
It's disappointing that a great majority of software developers (read: corporate programmer drones) have little understanding of what's really going on under the covers of the layers upon layer of abstractions.
Perhaps, if they truly did know, it might make them wonder if their code will run at all?
Actually, I wonder about your assertion as to whether Mel would be suitable for a corporate programming job. In the sense that no typical corporate hiring manager would approve of him and his habits, then no, of course he would not fit.
However, even corporations occasionally need people who just get things done. I have, in my past life as a programmer at a bank, seen some incredibly opaque, hard-to-maintain systems hacked together in the course of a few sleepless nights in 1992, which still tick, do their work, and help generate millions in revenue. IT departments then take months, if not years, to attempt to replace some of that code, and typically fail. So occasionally, people who work somewhat like Mel do get approved by higher-ups who value the productivity of one incredibly smart hacker over the productivity of a mediocre team.
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.
i college i wrote a little man computer program that calculated gpa scores. when the assignment was given, the example would take an input, load them into an array, and then iterate through the array, to compute the GPA. our teacher, now a PhD, told us that there was not enough room to do more than 5 or 6 classes.
as a natural hacker i took that as a challenge.
his code was very functionally written, it was like a Java programmer witting some thing in LMC, where my experience in programming was in getting my mechanical engineering friends TI80s to play Tetris. To pull this off, you needed to know how to follow directions on the Internet, build a custom serial cable, and understand binary. The stunt involved you triggering some buffer overflow that was never solved, and seemed to be on purpose as I look back on it. This alt mode allowed you to execute your own assembly code.
In any case, my experiences were not based in java or c in fact the only code i had written was an autoexec.bat and config.sys at the time, but to get my DAMN games to work, you had to spend a lot of time hacking them and getting drivers to load in the right order so that the memory managers would not over allocate for one driver vs. another. In the end, my experience of hacking a TI80, cheating in SimCity with a Hex editor, and booting my Wolfenstien 3d prepared me better for this task than classic programing did.
I decided to go a completely different approach than my professor did, and instead of using an array, I used an input buffer, and and a grade counter. I then wrote two major functions, a float multiply, and a long division routine. The only problem was, there was not enough space to make both work in the 100 memory spaces that the LMC had to load instructions, so I added a mode switch routine, that would rewrite the code in a few key places that allowed me to share instructions between the multiply and divide functions. In the end I had a calculator that was able to calculate about 20 grades with 5 decimal points of precision.
When I turned in the project, I was sure that my prof would be impressed, but when i got it back, i received an F. An F, i was sooooooo pissed, i took my timid self and asked him what was this score for, i thought i deserved an A, did he mix up the grades or something. He told me that when he tested the program the last few digits were flopping all over the place. I told him that those were the second part of the float gpa value. He responded that I did not document it. I asked him if he read the readme.txt that i submitted with my code. He claimed that it was not written clear enough ( i knew he did not read it ), so he compromised and gave me a b+, because my documentation was insufficient.
I learned a valuable lesson,"A" students never prove a teacher wrong. It's the same lesson I could have learned in High School, if i was paying attention.
I really miss assembly, not x86 assembly, but embedded assembly, later in college i got to program boot loaders for my co-op, and hack some sound cards for a speaker recognition project. Today I want to get into CUDA as a side hobby, when I have the time.
It's disappointing that a great majority of software developers (read: corporate programmer drones) have little understanding of what's really going on under the covers of the layers upon layer of abstractions.
Perhaps, if they truly did know, it might make them wonder if their code will run at all?