I'm good with a lot of the things on that list, but I don't have much professional experience, and obviously there are some things I don't know about yet.

Nothing about games in the programming section. Worthless! Should have had a similar progress thing as what can be found here on a.cc answers to noobies: 1) a guess-the-number text game. 2) snake or pong. 3) Tetris. 4) 3D space shooter with wotnot.

3-D graphics stack programmer would be it's own entire career and matrix.

There are certainly some gamedev fundamentals. But you gotta be careful to be general (or is it specific?) enough to hit the fundamentals and not specific implementations of those fundamentals.

If you've got the programmer fundamentals in say, OO and OS/memory, anyone can make an asset manager. It's just reading three sentences about it ("What is it? Ok, I make now."), then programming something to loading some data, and being careful how you access and store it.

But graphics stacks... oh, man are those so specific that they seem fairly useless outside of programming graphics stacks. I don't think shadow casting is going to be very useful in 99% of jobs outside of gamedev.

You didn't actually say anything to oppose what I said at all. You just went sideways. I said shadow casting isn't useful for non-games in 99% of places. So requiring someone to learn something that is very specific and may have nothing to do with their career is silly for the same reason I'm not forcing you to learn SLAM algorithms. You're not doing robotics, so why would I assume you'd need to know that?

I never said it wasn't important, difficult, or useful.

I often feel that way too. Don't sweat it

You shouldn't feel that way. I appreciate your posts. I always learn something new when you make a thread, and I wish I had modern hardware so I could run your examples. All the work you've done with SVG rasterization is just awesome, and that's just one of your pet projects. It's just that no one ever comes out and says so, but really it is true. I'm sure others appreciate you sharing your work with us as well.

Right.

To play Devil's Advocate: programmers are CRAZY wasteful now a days, since you don't have to care about the hardware you run it on...

We've had astronomical increases in hardware, but do we have the same growth for software? I'd argue hardware is the O(n^2) where as software progression is log(n), which is not what you want.

I felt the list was great, then I got to the self licking ice cream cone of "must have a blog", but there was no mention to standards and the improvement thereof. It's great that there's all of these programming languages that add X feature, but the most impressive feat is taking new "software" and back porting it to old tech. To me that's when you know the software is good. On the flipside: "The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.”—Joe Armstrong. Insert OO with basically anything new for software, and that's my jaded viewpoint

Hardware lesson 101: https://people.freebsd.org/~lstewart/articles/cpumemory.pdf

Regarding maintainability and extensibility: look at the unix suite of tools. Those really have not changed in nearly fort years of computing. Your point of "old and stable is good", which is the other half of the taking "new" software and back porting it (the old stuff is already there, such as unix tools, and chances are it works just fine...).

On CPU Speeds we can get them over 3GHz: http://valid.canardpc.com/records.php, and have had records in the 6-7GHz that are nearly 10 years old. The fact of the matter is it's a power and heat issue: you have physical (ie. cannot refute how electrons are being smashed around) issues that drive power and heat. We want less heat and power consumption (this is driven by battery devices) more that "raw power". Ultimately, it's a waste thing too for hardware: programs are just TOO SLOW to keep up with 9GHZ processing (you have to do a TON of slow writes to disk, waiting for input, etc.) so if we could allow for the heat and extra power the CPU would sit there and do "no ops" for a majority of its time.

Also note that the hardware allows "more to be processed" with the multicores needing no change to software (other than the kernel for the OS). This is a hardware solution, and a needed one since parallel processing (software solution) hasn't (such as you noted) gone anywhere in nearly 30 years.

FPGA's and ASIC's are GREAT pieces of hardware, but then you start facing issue of the micro and monolithic kernels (the great debate of the 70s and 80s have shown us monolithic are king...). There's new trends of micro containers, such as Docker and now Intel/VMware/VirtualBox etc creating standalone execution environments, which will enable hardware to support tons of "standalone devices" in the new "Internet of things" ...but there's no killer app to really showcase why micro's and ASICs are the new "thing".

/end hardware rant ... ha