4 ms·

I think in this context, it’s attempting to draw a distinction between “programming” and “coding”. Reasonable minds can disagree with whether or not this is suc

I think in this context, it’s attempting to draw a distinction between “programming” and “coding”. Reasonable minds can disagree with whether or not this is successful (or even all that meaningful).

kazinator 2y ago
The idea that a programmer can work on an executable form of the solution, but not be coding, disappeared decades and decades ago and is probably not worth resurrecting. The term "coding" in computing originally referred to encoding a program in the language of the machine: "machine code". Machine code was probably called that because it is cryptic, not allowing calculations to be specified in ordinary notation and in a machine-independent way. Programming was the overall activity of designing a program, which could have involved planning it on paper; coding was the manual translation of the design into machine code. Early programs that translated higher level statements into machine coders were called "automatic coders" and not "compilers", because they helped with the step that was already called "coding". The idea was that when you prepare input for the "automatic coder", in the higher level language like Fortran or whatever, you are programming, but not yet coding: the automatic coder is the thing that is coding for you; i.e. making machine code. (The term "compiling" also existed, but it had a meaning similar to the dictionary meaning: something like accumulating multiple library functions into a single image. I think, something similar to producing a .a archive from .o files. The way we use "compiling" and "compiler" today doesn't make sense in regard to the ordinary meaning of the word.) Eventually, writing in a high level language became "coding". The idea is that as soon as you begin steps which communicate your solution to the computer, which the computer will take as-is and execute, you're coding: you're encoding the abstract idea into a form which the machine understands, whether that be assembly language or Prolog. Those aspects of programming that are not coding have to do with clarifying requirements and planning the solution (and, later, testing and debugging). Once you have clarified the requirements and planned the solution, and have started using a GUI to hook up functional blocks to make it happen, you are coding the solution. There is no need to go back to the old terminology whereby you are programming the solution, and the "automatic coder" then takes your graph and turns it into computer code. Not even if we think that the terminology was good. It was good for "compiling" to just refer to sticking things into a bundle, rather than translating in a complex way, but we are not going back to that, either. We will just have to see how the language develops. Maybe developers will prefer not to call any graphical manipulation of functional blocks "coding". Especially if it's in a paradigm where the graph is translated into code that they often look at and perhaps edit, because you then might want the word "code" to unambiguously refer to that code.
- teddyh 2y ago
  When bugs too easily derange or mung the programs of machines; When programs too "intelligent" start taking over the machines: Is this the end of AutoProg? — The HACTRN
- nativeit 2y ago
  That was interesting, it added a good deal of context to topics I was familiar with on a surface level. Thanks for expanding on that.

kazinator 2y ago

The idea that a programmer can work on an executable form of the solution, but not be coding, disappeared decades and decades ago and is probably not worth resurrecting. The term "coding" in computing originally referred to encoding a program in the language of the machine: "machine code". Machine code was probably called that because it is cryptic, not allowing calculations to be specified in ordinary notation and in a machine-independent way. Programming was the overall activity of designing a program, which could have involved planning it on paper; coding was the manual translation of the design into machine code. Early programs that translated higher level statements into machine coders were called "automatic coders" and not "compilers", because they helped with the step that was already called "coding". The idea was that when you prepare input for the "automatic coder", in the higher level language like Fortran or whatever, you are programming, but not yet coding: the automatic coder is the thing that is coding for you; i.e. making machine code. (The term "compiling" also existed, but it had a meaning similar to the dictionary meaning: something like accumulating multiple library functions into a single image. I think, something similar to producing a .a archive from .o files. The way we use "compiling" and "compiler" today doesn't make sense in regard to the ordinary meaning of the word.) Eventually, writing in a high level language became "coding". The idea is that as soon as you begin steps which communicate your solution to the computer, which the computer will take as-is and execute, you're coding: you're encoding the abstract idea into a form which the machine understands, whether that be assembly language or Prolog. Those aspects of programming that are not coding have to do with clarifying requirements and planning the solution (and, later, testing and debugging). Once you have clarified the requirements and planned the solution, and have started using a GUI to hook up functional blocks to make it happen, you are coding the solution. There is no need to go back to the old terminology whereby you are programming the solution, and the "automatic coder" then takes your graph and turns it into computer code. Not even if we think that the terminology was good. It was good for "compiling" to just refer to sticking things into a bundle, rather than translating in a complex way, but we are not going back to that, either. We will just have to see how the language develops. Maybe developers will prefer not to call any graphical manipulation of functional blocks "coding". Especially if it's in a paradigm where the graph is translated into code that they often look at and perhaps edit, because you then might want the word "code" to unambiguously refer to that code.

teddyh 2y ago
When bugs too easily derange or mung the programs of machines; When programs too "intelligent" start taking over the machines: Is this the end of AutoProg? — The HACTRN
nativeit 2y ago
That was interesting, it added a good deal of context to topics I was familiar with on a surface level. Thanks for expanding on that.