3 ms·

This is a beautiful distinction (one that I'm aware of), but which appears to have been lost today. Consequently, these terms are now used interchangeably, lead

This is a beautiful distinction (one that I'm aware of), but which appears to have been lost today. Consequently, these terms are now used interchangeably, leading many people to conflate these two processes. However, this distinction is indicative of how getting a computer to do something has two components: 1. Figuring out what needs doing, and 2. Expressing this in a form that the computer can carry out. Thank you for the Grace Hopper quotes!

eXpl0it3r 8y ago
The distinction is lost because in many cases it doesn't hold relevance anymore. You don't need to write flow-charts, state or class diagrams before you start writing code. Todays tooling allows for more iterative approaches and also leaves room for making syntax errors without having to wait hours and days to get "compiler" errors. But I agree it's still interesting to know of the distinction and know that both can require slightly different skillsets. So when you have someone that is very good at planing and has the experience to layout complex systems in advance, you can assign them an architect title, while someone who knows a programming language inside and outside, you might be better off keeping them in the "driving" seat.
- kazinator 8y ago
  The point here is that when higher level languages were introduced, writing the higher level program was understood to be part of "programming"; and its compilation or interpretation became "automatic coding". Another thing worth paying attention to in Grace Hopper's paper is this: higher level program code is in fact called "code", but specifically "pseudo code". That which we call "pseudo code" today doesn't execute. But we sometimes remark that certain high level languages are almost like "executable pseudocode". At that time, the task of the compiler/interpreter writer was to take "pseudo code", formalize it more precisely so that then the machine could "automatically code" from "pseudo code" to "code".'

eXpl0it3r 8y ago

The distinction is lost because in many cases it doesn't hold relevance anymore. You don't need to write flow-charts, state or class diagrams before you start writing code. Todays tooling allows for more iterative approaches and also leaves room for making syntax errors without having to wait hours and days to get "compiler" errors. But I agree it's still interesting to know of the distinction and know that both can require slightly different skillsets. So when you have someone that is very good at planing and has the experience to layout complex systems in advance, you can assign them an architect title, while someone who knows a programming language inside and outside, you might be better off keeping them in the "driving" seat.

kazinator 8y ago
The point here is that when higher level languages were introduced, writing the higher level program was understood to be part of "programming"; and its compilation or interpretation became "automatic coding". Another thing worth paying attention to in Grace Hopper's paper is this: higher level program code is in fact called "code", but specifically "pseudo code". That which we call "pseudo code" today doesn't execute. But we sometimes remark that certain high level languages are almost like "executable pseudocode". At that time, the task of the compiler/interpreter writer was to take "pseudo code", formalize it more precisely so that then the machine could "automatically code" from "pseudo code" to "code".'