SoylentNews

'Statement' Considered Harmful

posted by janrinok on Friday December 16, @01:44PM   
from the a-word-means-just-what-I-choose-it-to-mean—neither-more-nor-less dept.

fliptop writes:

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]

---

Original Submission

• Re:We're always telling the computer to do somethi Re:We're always telling the computer to do somethi (Score: 2) by c0lo on Saturday December 17, @04:16AM (3 children)

  by c0lo (156) on Saturday December 17, @04:16AM (#1282819) Journal

  a "statement" (to the best of my understanding) is a syntactic thingy whose value is in performing a mutating operation, and whose return value is syntactically inaccessible

  Apply your definition to a SQL select statement and explain the "mutating" thingy in the context, please.

  --
  https://www.youtube.com/watch?v=aoFiw2jMy-0

  Parent

  Starting Score:	1		point
  Karma-Bonus Modifier		+1
  Total Score:		2

• Re:We're always telling the computer to do somethi Re:We're always telling the computer to do somethi (Score: 2) by krishnoid on Saturday December 17, @04:58AM (2 children)

  by krishnoid (1156) on Saturday December 17, @04:58AM (#1282828)

  Unless you're outputting data to /dev/null, you're appending the result (and count) to an output (terminal screen, file, network socket, another database table for "select ... into"), whence shall not be the same as 'twere before.

  Parent

  • Re:We're always telling the computer to do somethi Re:We're always telling the computer to do somethi (Score: 2) by c0lo on Saturday December 17, @07:37AM (1 child)

    by c0lo (156) on Saturday December 17, @07:37AM (#1282840) Journal

    You may have a point. But then:

    • a "SQL select" doesn't cease to be a statement if you redirect the result to /dev/null
    • select sum(column) from... produces a result that most of the time is "consumed" by the calling code as a result of evaluating an expression (using your terminology)

    --
    https://www.youtube.com/watch?v=aoFiw2jMy-0

    Parent

    • Re:We're always telling the computer to do somethi (Score: 2) by krishnoid on Saturday December 17, @09:15PM

      by krishnoid (1156) on Saturday December 17, @09:15PM (#1282926)

      It's sort of splitting hairs, but I guess my point is that "statement" and "expression" are syntactically different in the grammar, and "instruction" kind of encompasses both of those. "Statement" is sort of like a sentence in that it has to stand alone, and "expression" is sort of like a phrase. Along those lines:

      • a statement is responsible at some level for what it mutates, if anything. printf(); for modifying an output channel, a = foo(); for variable modification. This breaks down with 1+2; which doesn't mutate anything.
      • An expression doesn't have control over what receives its result, and hence, what its result mutates. This breaks down when you consider non-pure functions or lambdas, or expressions like a=b+c which also produces a return value.

      In that regard, if the select statement is executed as-is as part of a stored procedure in a SQL dialect (or API call) that doesn't explicitly output results, then yes, it doesn't mutate anything (like 1+2; in C), unless the dialect's interpreter is counting the number of statements run as part of its statistics.

      Maybe "sentence" and "phrase" would be better than "statement" and "expression", but I'm not a fan of "instruction".

      Parent