3 ms·

I feel like this comment perfectly captures the difference between programming and coding. Programming comes from a place of first principles, the goal being t

I feel like this comment perfectly captures the difference between programming and coding. Programming comes from a place of first principles, the goal being to understand what is needed completely so that a solution that meets many parallel constraints can be constructed. Coding comes from a place of completing a task, the goal being to get from the requirement to the operating task in as short a time as possible so that one might move on to the next task. Both disciplines have value. The original question was unclear about where the author hoped to end up. To put this in a slightly different perspective, a graphics programmer can write a program to show a shaded object on any platform with a CPU and a way to display graphics. A graphics coder can write a program to show a shaded object only on those platforms where they have previously mastered the APIs for generating display graphics.

NikolaNovak 3y ago
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).
charcircuit 3y ago
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.
- javajosh 3y ago
  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.
dragontamer 3y ago
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?)
- crq-yml 3y ago
  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.
  - dragontamer 3y ago
    > 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.
lackbeard 3y ago
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...)
- ChuckMcM 3y ago
  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.
- caslon 3y ago
  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 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.
dkjaudyeqooe 3y ago
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.

NikolaNovak 3y ago

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).

charcircuit 3y ago

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.

javajosh 3y ago
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.

dragontamer 3y ago

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?)

crq-yml 3y ago
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.
- dragontamer 3y ago
  > 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.

lackbeard 3y ago

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...)

ChuckMcM 3y ago
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.
caslon 3y ago
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 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.

dkjaudyeqooe 3y ago

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.