Over at ACM.org, Bertrand Meyer has a bone to pick regarding the use of 'statement' instead of 'instruction' when it comes to code:
I harbor no illusion about the effectiveness of airing this particular pet peeve; complaining about it has about the same chance of success as protesting against split infinitives or music in restaurants. Still, it is worth mentioning that the widespread use of the word "statement" to denote a programming language element, such as an assignment, that directs a computer to perform some change, is misleading. "Instruction" is the better term.
A "statement" is "something stated, such as a single declaration or remark, or a report of fact or opinions" (Merriam-Webster).
Why does it matter? The use of "statement" to mean "instruction" obscures a fundamental distinction of software engineering: the duality between specification and implementation. Programming produces a solution to a problem; success requires expressing both the problem, in the form of a specification, and the devised solution, in the form of an implementation. It is important at every stage to know exactly where we stand: on the problem side (the "what") or the solution side (the "how"). In his famous Goto Statement Considered Harmful of 1968 (in this very venue!), Dijkstra beautifully characterized this distinction as the central issue of programming:
Our intellectual powers are rather geared to master static relations and our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.
The author gives examples of the difference between instructions and statements, and concludes by saying:
So, please stop saying "an assignment statement" or "a print statement"; say "an assignment instruction" and so on.
At least he said "please."
[We can no longer use terms such as "master/slave" for fear of offending somebody - but what are your pet peeves in your own profession? JR]
(Score: 2) by c0lo on Friday December 16, @11:01PM (2 children)
He may have a point (well, he's entitled to have one) but this point of his is pure unadulterated rubbish
Functional programming is mainly descriptive, the paradigm is "declarative programming", one states the constraints (describing them as functions) and the only instruction is "now solve this mess for me".
The "program is the execution of a set of instructions" denotes an "imperative programming" mind set, good enough for assembly level and C, but programming extends beyond just that.
And don't get me started about meta programming and C++ templates or the philosophical extensions of the type theory [wikipedia.org]
https://www.youtube.com/watch?v=aoFiw2jMy-0
(Score: 2) by Rich on Saturday December 17, @10:04AM (1 child)
If you read his journal entry, you will see that he precisely makes the distinction you mention: Something "stated" like an expression is a "statement", he only complains about the name of these imperative steps. You can still have a complete program out of statements, but then it's a functional or declarative program.
Thinking a bit, even the word "instruction" might be etymologically suboptimal: With the original meaning from lat. "struo" vs. "mando" (order, commit), "command" might be preferrable. Breaking "mando" down further, we get "manus", hand, which fits really nice for digital computers.
(Score: 2) by Rich on Saturday December 17, @10:27AM
Haha. Meyer already said "command". Wonder why he didn't stick to that. OOSC 2nd Ed. (1997) p. 447 §13.3 INSTRUCTIONS The object-oriented notation developed in this book is imperative: we specify computations through commands, also called instructions. (The word “statement” is commonly used in this sense but we will steadfastly avoid it since it is misleading: a statement is an expression of facts, not a command.)