3 ms·

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 w

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".'