Linked by Thom Holwerda on Fri 28th Sep 2012 21:51 UTC, submitted by MOS6510
General Development "When I started writing programs in the late 80s it was pretty primitive and required a lot of study and skill. I was a young kid doing this stuff, the adults at that time had it even worse and some of them did start in the punch card era. This was back when programmers really had to earn their keep, and us newer generations are losing appreciation for that. A generation or two ago they may have been been better coders than us. More importantly they were better craftsmen, and we need to think about that." I'm no programmer, but I do understand that the current crop of programmers could learn a whole lot from older generations. I'm not going to burn my fingers on if they were better programmers or not, but I do believe they have a far greater understanding of the actual workings of a computer. Does the average 'app developer' have any clue whatsoever about low-level code, let alone something like assembly?
Permalink for comment 537071
To read all comments associated with this story, please click here.
Comment by MOS6510
by MOS6510 on Sun 30th Sep 2012 18:39 UTC
Member since:

WHen I used to hang out on Usenet, the Commodore groups, people would sometimes ask how to do something in Assembler.

Someone would reply with some 25 lines of code, someone else would reply to that with 18 lines and then someone would come up only 11 which someone else would change so it would run faster.

Although I had no idea what was going on it always seemed very cool and almost magical. But this required a high level of Assembler and C64 chip knowledge. It's not realistic or practical to code user applications using Assembler or take in to account the hardware as hardware is very diverse.

So you have to use libs and APIs, but I think it's rather annoying when a "programmer" makes something, that doesn't work and he then blames Microsoft or someone else.

In the old days and with all that low level stuff people could at least debug their code almost all the way. Now they suggest to reboot, reinstall the application, reinstall .NET or reinstall Windows. And even then that's no guarantee it works!

If when something doesn't work and the fault is with some library/include, the programmer should at least be able to see what he sends to an external routine and what comes back, but for some strange reason they don't see this as an option.

Recently we had a process that ran as a Windows service. Suddenly it kept stopping until it even refused to start. The guy on the phone couldn't figure it out (and yes, he did the reboot and reinstall thing), but lucky the expert joined in... and he didn't know what to do either.

Reply Score: 2