Re: [tlug] "Go Considered Harmful"

[Benjamin Kowarsch <trijezdci@example.com>]

On Mon, 31 Aug 2020 at 15:32, Curt J. Sampson <cjs@example.com> wrote:

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.

Well, I did not pick this example, you did. I only commented on your example.

 

> 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.

Go is certainly improving upon C, sure. But it is also a language for a different

purpose. The purpose of C is system implementation, Go is more of a scripting

language, certainly not a system implementation language.

 

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.

I was only commenting on how you framed the example you chose.

> 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.)

The Dykstra/Hoare/Wirth school is about correctness but type safety is

an important tool to achieve that goal and they promoted that, too.

 

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]

When I mention Dykstra, Hoare and Wirth, I am absolutely not thinking of

this GOTO "controversy" at all. It is a sad thing when their school of thought

is reduced to that.

This is like defining Quentin Tarantino's movie work by the incident that he

once walked out of an interview within minutes of that interview having

started because he didn't like the question he was asked.

 

> 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.

I agree, but my point was not so much about faulting Thorvalds, it was about

the fact that the people who young developers are looking up to as role models

in our time are not like the earlier generations from McCarthy, Naur, Rutishauser

to Dykstra, Hoare and Wirth who were role models that had more sensible things

to say back then.

> Dykstra is dead and forgotten now....

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

:-)

 

Unfortunately, you are also an old fart (just like I am), haha.

> 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.

Of course we cannot fault them for not having successors who do not have

as much clout in the (meanwhile much larger) industry and who are not as

influential. But I was describing a long standing trend of mediocrity in this

industry and the fact that this trend is being exacerbated by the role models

this industry now has.

 

> 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.

Go has a reasonably good type system *for a scripting language*.

And therein lies the problem. The mere fact that Google invests that much

effort into a glorified scripting tool, not into a proper system or application

development language (whichever), that is the problem.

Everything is a script nowadays.

There is no more design, no more preparation, no more planning.

People like to sit down and start coding before they have even heard

out what their customer has asked them for. It is this trend, that

software development is a kind of game you do on your sofa

with popcorn and coca cola that is the problem.

One of our teachers (at engineering college) explained to us

the difference between an engineer and a tinkerer

"The engineer thinks first and makes thereafter,

the tinkerer makes without thinking."

Scripting languages are the ultimate _expression_ of this.

Convenience is rated over all else, because they want to sit

down on their sofa with popcorn and coca cola (or red bull)

and have some entertainment value, preparation would

diminish the entertainment value.

Real engineering doesn't work that way, and tools used in

real engineering are designed with preparatory work

having been done prior in mind, not for entertainment

value.

regards

benjamin