[tlug] "Go Considered Harmful"

["Curt J. Sampson" <cjs@example.com>]

(I apologise for not earlier setting a new subject line for this thread.)

On 2020-08-30 01:10 +0900 (Sun), Benjamin Kowarsch wrote:

> Subrange types were a Pascalian innovation. I don't know of any curly
> braces language that adopted them. Do you know of any?

Not off-hand. But given a choice between the two, algebraic data types are
more useful to most programmers, I believe.

> And type safety has never been a concern of C languages and their
> descendants either. Why would Go be any different, considering that
> it came from the same folks that gave us C.

Because the whole point of the language was to fix many of those problems
with C, which I think it does pretty successfully. It added automatic
memory management, for example, which seems to be anathema to most C
programmers. I am not familiar enough with the type system to tell you if
it really fixes the type safety issues with C, but it certainly looks as if
it does.

My complaint is not about lack of type safety, but the lack of
expressiveness in Go's type system that prevents you from using type safety
in many common situations.

> Once upon a time there were Dykstra, Hoare and Wirth preaching
> type safety and their teachings had weight.

Well, I wouldn't say that they were really teaching type safety, more they
were suggesting (at least in Dijkstra's case) that programming is indeed a
mathematical discipline and, if not approached as such, will leave you in
the same place as if you decided to do civil engineering without using
numbers. (Put in another way, the idea of programming "without writing
code," as so many systems over the years have claimed to do, is nonsense;
you are creating mathematical expressions and if you think you're not,
you're simply going to create poor or even nonsensical ones that the
computer will execute as best it can anyway.)

What those folks really believed has often been misinterpreted, of course.
For example, many people consider Dijkstra to be strongly against the use
of GOTO (due in no small part to a headline chosen by Wirth). But if you
want to see what Dijkstra really felt, you can read his own words, both
in that very letter:

    The exercise to translate an arbitrary flow diagram more or less
    mechanically into a jumpless one, however, is not to be
    recommended. Then the resulting flow diagram cannot be expected to
    be more transparent than the original one. 

and as quoted directly in various places in Knuth's "Structured Programming
with go to Statements"[1]:

    Please don't fall into the trap of believing that I am terribly
    dogmatical about [the go to statement]. I have the uncomfortable
    feeling that others are making a religion out of it, as if the
    conceptual problems of programming could be solved by a single trick,
    by a simple form of coding discipline!

    ...

    I showed this example to Dijkstra, cautioning him that the go to
    leading into an iteration might be a terrible shock. I was extremely
    pleased to receive his reply [31]:

        Your technique of storing the value of up in the order counter is,
        of course, absolutely safe. I did not faint! I am in no sense
        "afraid" of a program constructed that way, but I cannot consider
        it beautiful: it is really the same repetition with the same
        terminating condition, that "changes color" as the computation
        proceeds. 

        For the time being I could not agree mare with your closing
        remarks: if the economies matter, apply "disciplined
        optimalization" to a nice program, the correctness of which has
        been established beyond reasonable doubt. Your massaging of the
        program text is then no longer trickery ad hoe, it is perfectly
        safe and sound. 

And, summed up by Knuth:

    Indeed, Dijkstra's original article which gave Structured Programming
    its name never mentions go to statements at all; he directed attention
    to the critical question, "For what program structures can we give
    correctness proofs without undue labor, even if the programs get
    large?" By correctness proofs he explained that he does not mean formal
    derivations from axioms, he means any sort of proof (formal or
    informal) that is "sufficiently convincing"; and a proof really means
    an understanding. By program structure he means data structure as well
    as control structure.

And, of course, for a really good investigation of both GOTO and efficiency
vs. readability, see Guy Steel's classic paper, "Debunking the 'Expensive
Procedure Call' Myth, or, Procedure Call Implementations Considered
Harmful, or, Lambda: The Ultimate GOTO."[2]

> And then came people like Linus Thorvalds who thinks he is smarter than
> all of them put together and he rants to his cult followers against all
> that which Dykstra, Hoare and Wirth stood for, even calling them idiots.

Well, Linus's attitude is just part of a long-standing tradition that
started in the '60s and continues even today. It's hard to fault him too
much for it; it takes considerable independent research and iconoclasm to
go so far against the cultural grain, and that's not really to be expected
of someone who's merely reimplementing yet again an existing system with
more than two decades of history.

> Dykstra is dead and forgotten now....

Certainly not by all. I even have a separate fortune cookie file devoted
just to him.[3]

> They also failed to produce a new generation of people to continue
> their cause. The notable exception from that tradition is Ada but that
> has other issues that are at odds with their cause.

Well, _they_ may not have been the ones directly to produce the new
generation, but it still was there, coming mostly out of a certain side of
the more mathematically-oriented functional programming community. From ML
in 1973 through Miranda (a commercial product!) in 1985 to OCaml, F#,
Haskell, Rust and many other languages today, research on and
implementation of type checking systems and control flow structures has
continued and their fruits become easily available to the general public.

> The industry is now ridden with people who think type systems
> and strong typing are something that belongs into a museum.
> 
> Go reflects that long lasting trend. Sadly.

I don't think I agree with that. As I mentioned above, I am not convinced
that Go's type system isn't "strong" in the sense that it doesn't make it
deliberately hard or impossible to violate the type constraints that you
can state in the language; it's simply rather unexpressive, even by the
standards of research in the 1970s and the better languages available to
the public in the 1980s.

On 2020-08-31 01:48 +0900 (Mon), Stephen J. Turnbull wrote:

>  > Once upon a time there were Dykstra, Hoare and Wirth preaching
>  > type safety and their teachings had weight.
> 
> Yup.  The programs and languages that followed their teachings were so
> weighty they sank in the quicksand of real problems without a trace. ;-)

Well, only if followed blindly. See Knuth vs. Dijkstra above.

> Oh, no, you don't.  Before Linus came Richard (Gabriel, 1989).  
> https://www.jwz.org/doc/worse-is-better.html, read the whole thing,
> but pay careful attention to paragraphs containing the word "virus".

I think that what Gabriel misses in that paper, or at least doesn't really
make clear, is that writing "real" programs is almost invariably about
making _engineering_ decisions.

Engineers (in which category I do not include most of the people who call
themselves "software engineers") use "worse is better" all the time; in
fact, it's a mark of engineering skill. But they use it not because they
don't know how to make a design "better" or are just too lazy to do so, but
because they do risk analyses and cost-benefit analyses and, find and use
ways of mitigating risk introduced by lower cost and "worse" techniques,
and in the end produce a product that will work reliably in the conditions
for which it's designed. No engineer builds a structure that won't fail;
they build one that won't fail given certain conditions, and, more often
than not, provide systems to help maintain those conditions.

If "software engineers" would admit that all their code is broken, but
understand _how_ it's broken and build not only code but systems to manage
the brokenness, we'd be in a much better state right now than we are. But
just try going to your next iteration meeting and saying, "I have committed
this broken code and I suggest we release it because...." You'll be cut off
right there before you can explain why it's perfectly safe to release. So
you pretend that it's not broken, even if you know exactly how and why it
is, and that comes back and bites the team later when someone else doesn't
realize that to change the code to do X they need to fix some of those
broken things.

> OTOH, python -m this is shorter (though later, Peters, 1999).

Yes, and also unfortunately half nonsense, that even Python doesn't follow.
Consider even "implicit is better than explicit." I doubt many Python
programmers, on seeing

    y = a*x**2 - b*x + c

would ask you to change it to

    y = (a*(x**2)) - (b*x) + c

much less tell you to abandon the use of `flag=None` in function argument
definitions, `from m import f` statements, and always write `print("...",
file=sys.stdout)`.

And "special cases aren't special enough to break the rules"? Given the
"rules" that programmers are usually adhering to, this is utter rubbish, in
my experience usually leading to code that trades clear expression of what
it's trying to say for appeasement of the consistency hobgoblin.

(Reference [1] below is paywalled; please contact me by private e-mail if
you would like a copy of the paper or any of its paywalled references.)

[1]: https://dl.acm.org/doi/pdf/10.1145/356635.356640
[2]: https://dspace.mit.edu/handle/1721.1/5753
[3]: https://github.com/dot-home/unfortunate/blob/master/share/fortune/dijkstra

cjs
-- 
Curt J. Sampson      <cjs@example.com>      +81 90 7737 2974

To iterate is human, to recurse divine.
    - L Peter Deutsch