Today, you have veritable oceans of RAM and multi-core CPUs and at least a factor of 10 if not a factor of 100 more programmers out there developing tools for you.As a result, the salaries dropped by a significant factor and difficulty to be hired increased by a significant factor. The days when "being able to program a computer" made you a very special person are long over
There are lots of factors involved here and it isn't only because of the number of programmers "out there." When I was trying to decide which direction I wanted to go (and I didn't make a rational decision, I just "fell" into what I became), almost everyone who was a programmer had a PhD in physics or mathematics. At the very least, an MS. The "pyramid" of skillsets was small at the time and the kinds of people who could gravitate into this field was rather a small percentage of the population, too.
When I was 18, I was able to design and build a small computer of my own using wire-wrap. I had newspaper reporters coming to my home because of this. (I have no idea who tipped them off.) This was 1974. My chosen field was physics and mathematics. And it turns out that these were the kinds of people who were involved as programmers back in that day. If I were talking to another programmer then, I could bring up the use of a LambertW function and would NOT need to explain it to them. They would already know exactly what I meant and why it would be appropriate. If I wanted to compute a sine function, I could point out that a Chebyshev function bounds max error and converges faster and I could be assured they would know what I meant and why (Taylor's bounds average error, not max error, and converges more poorly in these cases.) All of us were cut from a similar cloth, then. I could write an operating system, a compiler, etc., from scratch and didn't need a book. (As an example, I was flown to a site in California to work on a project and had written from scratch, tested, and completed a full multi-threaded operating system in less than two days -- without the use of any pre-existing code or libraries.)
As time progressed, more and more work product from this small pyramid became available as tools. And this enabled people with less training or skillsets to dive in and be very successful using those tools. They no longer needed to understand how to write an operating system or compiler on their own and they almost certainly no longer needed to have an interest in physics or mathematics, anymore. They just needed to know how to use the tools provided as programmers and, perhaps, some decent level of algebra and Boolean logic. And so the pyramid height grew and the base widened as more and more programmers were able to make this an avocation or... just a job choice, perhaps.
As time further progressed, you start getting to something like Microsoft's .NET system, which allows almost anyone to create fairly sophisticated program from just a few clicks of the mouse and a few "drag and drops." It's almost trivial. This of course opens the doors for still more people. When I was teaching undergrad CS at the largest university in my state, about a decade back (with class sizes of about 75 or so), most of my students were making a choice for CS as a kind of "Well, I want a low stress, high paying job and it's between this or accounting." (Seriously, I actually had students come into my office during office hours and ask me if perhaps they should leave CS and go into accounting!) The people entering into CS degree choices had far fewer inherent talents, hobbies, and skills and were looking at CS as one of several options, many of which were as far from physics, mathematics, engineering, and computer science as it could get.
This is because of all of the incredible, hard work that has gone on before, creating the vast amount of infrastructures that are used today by programmers. The pyramid height is now incredibly high, and the skillsets and interests needed to enter in at the base of the pyramid is... close to zero as not to matter much.
It will get worse. Eventually, everyone will consider "programming" like "typing" and it will be barely anything different than whether you type faster or slower, is all. Everyone will be a programmer. And the pyramid will be all-inclusive.
But it will still have the pinnacle at the top, too.
I had been offended by a presentation made by Microsoft's Steve Balmer in Portland some years back, so I'd cornered him during lunch and had it out. His presentation showed that pyramid I just discussed above and while he painted it quite differently to the audience (making it sound like Microsoft was wonderful to all of "us programmers"), it sounded horrible to me because I was in business for myself. His presentation basically said that Microsoft would work more and more to increase the height of that pyramid and embrace more and more people who would need fewer and fewer skills. But what offended me was that he added "Microsoft will do all this part", pointing to ALL OF THE PYRAMID but the bottom tier or two!! Which to me basically said, "We will take your business away from you and leave you with the remaining work at the bottom which doesn't pay well."
They wanted the "tough stuff" for themselves (which pays better and requires more skillsets) and would "offer" the scraps to the rest of us.
At the end of my discussion with him over lunch, I had his admission that my take on his presentation was accurate. And "tough beans," so to speak. I pretty much hated him after that little discussion that day.
November 11, 2017, 03:30:40 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
For games which targeted "game machines" that had very little RAM available and relatively slow processors, you were pretty much stuck writing assembly code -- perhaps in a mixture with C, if lucky. There was NO POSSIBLE WAY you could do this without the use of assembly code. If for no other reason, then because C itself doesn't have the semantics and syntax to permit the required hardware mapping (C uses a very strict and rather simple model of the world, which pretty much fits zero game machines of the time.)I wonder what exactly do you mean here ? Are you refer[r]ing to memory-mapped IO ?
I was talking about the fact that C's view of the world is a single memory system. Harvard architectures, for example, deviate from the C model of memory. That doesn't mean C cannot be adapted to Harvard architectures through the use of modifiers (such as "__code" for example; a keyword that is not a part of the strict language but which lets a programmer notify the C compiler about something special.) It just means that you have to use "out of band" language extensions, which are not portable at all, in order to get the job done.
C has two different models in the standard, one for "hosted" and one for "stand alone." They differ just slightly. But the language itself specifies quite a few assumptions about the world it targets. And these assumptions are quite frequently broken by the reality of game machines -- especially the older ones.
Just to offer one more case to the pile (and there are many) that is directly and squarely targeted at SNES cartridges. C has no mechanism to deal with mappers. Nothing at all. A mapper is completely outside of the semantic range of C. And I don't think it ever will be within it. C can be made to deal with them, of course. In fact, as early as 1985 (in my case only, as I'm sure others did work predating me here), I was writing code in C that dealt with the hardware mapping boards that were available then to extend the memory of an IBM PC beyond the "one meg barrier" of DOS. This was driven earlier by the need of spreadsheet programs for LOTS OF MEMORY, despite the terrible limitations of the DOS memory space. They could be ordered to bank in, and bank out, different "pages" of RAM into the DOS memory space. And there were whole standards developed to help programmers do this in a "standard" way (actually, there were competing standards and so there really was NOT a standard way to do it for quite a while.) As I said, C can be "twisted" to work with these hardware systems. But not without (1) extra keywords outside the language specification; or, (2) assembly code that can be called from C (which itself requires knowing details about the specific C compiler's assignment of registers, calling standards, activation record formatting, and other details sometimes quite difficult to track down.)