SoylentNews is people
SoylentNews
from the a-word-means-just-what-I-choose-it-to-mean—neither-more-nor-less dept.
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:07PM (3 children)
False. There are cases in which you state the problem to them and let a compiler/interpreter/transplier/virtual machine transform that into (assembly) instructions.
Let me introduce you to declarative programming [wikipedia.org]
https://www.youtube.com/watch?v=aoFiw2jMy-0
(Score: 2) by istartedi on Saturday December 17, @12:31AM (2 children)
It's an illusion. You're still telling the computer to do something. Your explanation is self-contradictory, although I can see why you don't see it that way. As much as people who are in to things like declarative and functional programming hate to admit it, there is no practical computing without memory, without state, which you change... by *telling the computer to do things*.
Appended to the end of comments you post. Max: 120 chars.
(Score: 2) by c0lo on Saturday December 17, @01:18AM (1 child)
It is not ME that tells the computer to do things, it is the thing that stays between me and the computer memory/state that does that - that is the one which instructs the computer.
Speaking generally, I'm coding. And this becomes relevant in the context of TFS, namely
If I am to use the ASM, I'll be using instructions to express my code.
If I'd be to use an imperative programming language to code, I'll be using instructions most of the time, but I might use descriptive elements. E.g. the good old DIMENSION DMYARRAY(42) in FORTRAN 77, which is a statement that the compiler will use to layout the access to the memory (which was NOT dynamically allocated) on my behalf.
If I am to use a functional programming, I'll be stating the problem when coding and let the interpreter or transpiler or compiler or whatever do its magic.
When I'm coding a template in C++ and use metaprogramming techniques, the means I'll do that will be a ungodly awful mixture of "instructions" and "descriptions" that can't even fit in clearly in either imperative or descriptive programming - I guess this is why the "C++ template metaprogramming" needed a special paradigm on its own.
And this even not considering that one can write source code just for the sake of source code, that will never be transformed in instructions and executed - "statement" will be still applicable in that case, "instruction" won't ever.
https://www.youtube.com/watch?v=aoFiw2jMy-0
(Score: 2) by coolgopher on Saturday December 17, @12:49PM
I'll add to this that when I'm coding in Rockstar [codewithrockstar.com], I'm writing lyrics...