Good comment, and, basically, I fully agree, except, I really dislike your attempt to appropriate the words "programming" and "coding" here. Like, can you just explain what you mean without trying to redefine terms that have broadly accepted definitions distinct from how you're trying to use them here?

(Sorry, this probably sounds more critical than I'm intending...)

No worries, got to use something as the holder of the definition. FWIW I read a similar essay that discussed cooks and chefs and came away seeing the many parallels with programming and coding.

Programming requires creative thinking. Coding, historically, was a lower-paid, unskilled position.

You may think this is redefinition. It's not. This is how both terms originated. A "coder" did the unskilled gruntwork of implementation for business projects, while a programmer was holistic.

> I find it bizarre that people now use the term "coding" to mean programming. For decades, we used the word "coding" for the work of low-level staff in a business programming team. The designer would write a detailed flow chart, then the "coders" would write code to implement the flow chart. This is quite different from what we did and do in the hacker community -- with us, one person designs the program and writes its code as a single activity. When I developed GNU programs, that was programming, but it was definitely not coding.

> Since I don't think the recent fad for "coding" is an improvement, I have decided not to adopt it. I don't use the term "coding", unless I am talking about a business programming team which has coders.

https://stallman.org/stallman-computing.html

In this case, it is you, and the wider cottage industry of business "coders" who are doing the appropriation. It's not your fault. The bootcamp or Super Cool Totally Serious College you likely learned from probably used the term "coder" alongside words like "rockstar!" You were given a bad definition, and never knew any better at all. ChuckMcM's comment, on the other hand, is correct. Using the word "literally" to mean "figuratively," while colloquial, is still less correct than figuratively.

The phrase "code monkey" is not a compliment, and didn't come from nowhere. It came directly from these pre-existing definitions.

Programming requires logic. If you are coding, the thinking's already been done for you. You are just doing unskilled labor akin to data entry to get the computer to actually follow the instructions.

Thing is that no one hires "coders" anymore, even if many people's jobs are in fact mostly coding instead of establishing the design. It's a weird stigma that translated to companies low key lying about what they really want out of an engineer.

It's a shame because there's a nice flow to coding once you got everything nailed down. Coders are no different from (human language) translators and like good localizers, a really good "coder" understands the subtleties of the language. If your application is concerned about scalability or performance or cross-compatibility, you aren't just googling an API and pasting in commands to get something working.

But I guess coding may not really be a thing in the next few decades if AI really does catch on.

I like the distinction, and I think there should exist different terms, but I don't think those two are nearly universal. Many people will use them interchangeably, others may even think other way around ("programming" as a professional discipline where you use tools to achieve an MVP most efficiently, vs "coding" as an enthusiastic activity that's more creative and open ended).

There is a lot to be said for understanding things from first principles, but not everyone wants to go that low. Not everyone is that nerdy or maybe hasn't the time or motivation.

The other issue is that not everyone learns well from the bottom up. I believe that top down is a much better way of learning anything, and lets you progressively get closer to first principles while not discouraging learners with a steep difficulty curve. But unfortunately is an approach that is seldom facilitated by anyone.

2D graphics with bitblits is a completely different paradigm. If you were using 2D GPUs from the 90s, or maybe a 2D Industrial PC's GPU, sure... Learning about Bitblits and rects is good.

But if your goal is to program a modern shader on a modern platform (even if it's a 2D graphic), you should learn a modern graphics library.

-------

A modern graphics API is laid out the way it is: to maximize modern performance on modern systems. A first principles bottom up approach will absolutely cover shaders (maybe compute shaders are easiest?)

There's a lot of leeway to learn 3D principles through a basic software rasterizer. It does not take long - if you already have some awareness of the math, it's at most a few weeks to work through the essentials from a tutorial. Once you get to the point where you're drawing filled triangles through a projected camera, you can move on. There's no need to go into occlusion culling strategies, texture mapping or lighting calculations, or really to make the rasterizer fast in any way. That wouldn't be the point of the exercise. It could be done entirely with a fixed-size bitmap and a setPixel(x, y, v) call.

The argument against "just" using the hardware is that the hardware resists learning that conceptual skeleton. Instead of learning how a rasterizer is implemented, you learn the specific API incantation to bring one up, and that has changed a lot over the years in the direction of being a more professionalized phenomenon, so now it's much easier to start application top-down, from within a premade rendering environment like a game engine or Blender's rasterizers.

Learning to work on production rendering engines would involve reading and studying existing implementations, reading the relevant research papers along the way.

> you learn the specific API incantation to bring one up

The graphics pipeline from geometry -> vertex shader -> pixel shader -> image is the damn point.

When the literal hardware is laid out in a certain way, you must learn that hardware layout and understand it. These API 'incantations' as you put it aren't high magic. They logically flow from the requirements of modern graphics programming.

If you just skip that stuff, you won't ever learn about modern GPUs, modern CPU->GPU data transfers, GPU parallelism or how a CPU calls the GPU routines to render.

Maybe you can make the argument that you should learn rasterizing first to simplify the learning process. But I would argue that it's easy enough to learn rasterizing when you get to the Pixel Shader step.

> The argument against "just" using the hardware is that the hardware resists learning that conceptual skeleton. Instead of learning how a rasterizer is implemented, you learn the specific API incantation to bring one up, and that has changed a lot over the years in the direction of being a more professionalized phenomenon, so now it's much easier to start application top-down, from within a premade rendering environment like a game engine or Blender's rasterizers.

The argument against that is that you eventually have to learn today's hardware anyway. So you might as well start now.

Tomorrow's hardware is based on today's hardware. And today's hardware is based on yesterday's hardware.

It's all incremental progress. I'd personally say that OpenGL with GLSL might kinda sorta look like modern stuff (vertex and pixel shaders), but anything older (ex: 90s BitBlits) is so old it's just completely a waste of time.

Your definitions are made up.

Programming refers to the act of writing a program for a computer to follow.

Coding refers to the act of writing code for a computer.

Edit: The definitions are not commonly used this way and in fact I've heard other people even give opposite definitions to what correponds to which word.

Hate to break it to you, but all definitions are made up. The question is whether or not the distinction is useful or not. In my opinion, it seems useful to distinguish between understanding oriented tasks and goal oriented tasks.