(Execution) Termination bit, Alternation bit.

[Steven D'Aprano]

On Wed, 30 Dec 2015 03:07 pm, Rustom Mody wrote:

> By some coincidence was just reading:
> from http://www.wordyard.com/2006/10/18/dijkstra-humble/
> 
> which has the following curious extract.
> [Yeah its outlandish]
> 
> ----------------------------------------------
> I consider the absolute worst programming construct to be
> subroutine or the function. 
[...]

Rustom, your quote was (I trust inadvertently!) horribly misleading. I
thought this was said by Dijkstra, not some random crank on the Internet.

The comment from some random person Cleo Saulnier, who starts off with the
provocative comment that the *subroutine* is the "the absolute worst
programming construct", then goes on to sing the praises of Unix pipes.
What are small Unix programs communicating via pipes if not subroutines?

Functions are subroutines, but not all subroutines are functions.

It is fashionable to dismiss 1970s-style BASIC as a serious language, and
for good reason, but let's not forget that for all its problems, a large
number of programmers cut their teeth on it. BASIC is, in some ways, like a
machine language except with a friendly syntax. There are subroutines, but
you can jump into the middle of them, or out from the middle. There are no
functions, just jumps to the instruction you want to execute next. Only a
limited set of data types to work with.

I think every programmer would learn something from trying to write, and
maintain, an actual useful piece of code using only a BASIC-like language.
At the least, they would appreciate what a huge step-up it was to introduce
procedural programming.

(A friend of mine once worked under a manager who insisted that writing
functions and procedures was a terrible idea, that GOTO was vital, because
it was far more efficient to jump to a line of code than call a function.
And this was in the late 1990s.)

Cleo continues:

> I can prove how the subroutine causes all
> parts of our software to become coupled and as such cannot
> support this as the basic building blocks of software.

This is a remarkable claim, considering that one of the advantages of the
function is that it can, when used correctly, *reduce* coupling.

In non-procedural code, any line of code may be used by any other chunk of
code. You can jump to any line, and people did (because they had no
alternatives), consequently coupling was very high.

In procedural code, any line of code can only be reached from exactly one
place: the previous line of code. (Well, a few more, in specialised
circumstances: for- and while-loops, branches, etc.) Lines of code *within*
a procedure can only couple with other lines within the same procedure;
it's true that procedures can have high-coupling or low-coupling, but at
least you know that you can change the inside of a procedure as much as you
want, and so long as it accepts the same input and generates the same
output (and has the same side-effects) it will continue to work. That's
reduced coupling.


> Unix has pipes. These are queues. As data is piped, software on
> both ends of the queue can execute at the same time. As data 
> passes from one end of the queue to the other, there is no
> concept of execution point.

That's arguable. When I learned about Unix multi-processing, it was based on
a single CPU model: each process would run for a few ticks, before being
interrupted by the OS and the next process being allowed to run for a few
ticks. A sequential process that merely appeared to be parallel because the
CPU was so fast. Perhaps these days Unix is capable of actually running
multiple programs in parallel on separate cores or multiple CPUs?

As I said earlier, of course Unix programs communicating via pipes are a
kind of subroutine. We also have generators, and coroutines, and threads,
and other forms of parallel processing. The unsurprising reality is that
such kinds of code are *harder* to get right than functions with their
simple-minded stack-based sequential execution model.



-- 
Steven