Mailing List Archive
tlug.jp Mailing List tlug archive tlug Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tlug] "Go Considered Harmful"
- Date: Mon, 31 Aug 2020 17:44:08 +0900
- From: Benjamin Kowarsch <email@example.com>
- Subject: Re: [tlug] "Go Considered Harmful"
- References: <firstname.lastname@example.org> <CADR0rnf86TcHyrFsTwfPPy-NN_Ucnm4zEasNxkOSH0E_7YxbqQ@mail.gmail.com> <email@example.com>
On Mon, 31 Aug 2020 at 15:32, Curt J. Sampson <firstname.lastname@example.org> 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 differentpurpose. The purpose of C is system implementation, Go is more of a scriptinglanguage, 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 isan 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":
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 :
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
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."When I mention Dykstra, Hoare and Wirth, I am absolutely not thinking ofthis GOTO "controversy" at all. It is a sad thing when their school of thoughtis reduced to that.This is like defining Quentin Tarantino's movie work by the incident that heonce walked out of an interview within minutes of that interview havingstarted 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 aboutthe fact that the people who young developers are looking up to as role modelsin our time are not like the earlier generations from McCarthy, Naur, Rutishauserto Dykstra, Hoare and Wirth who were role models that had more sensible thingsto 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.:-)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 haveas much clout in the (meanwhile much larger) industry and who are not asinfluential. But I was describing a long standing trend of mediocrity in thisindustry and the fact that this trend is being exacerbated by the role modelsthis 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 mucheffort into a glorified scripting tool, not into a proper system or applicationdevelopment 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 heardout what their customer has asked them for. It is this trend, thatsoftware development is a kind of game you do on your sofawith popcorn and coca cola that is the problem.One of our teachers (at engineering college) explained to usthe 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 sitdown on their sofa with popcorn and coca cola (or red bull)and have some entertainment value, preparation woulddiminish the entertainment value.Real engineering doesn't work that way, and tools used inreal engineering are designed with preparatory workhaving been done prior in mind, not for entertainmentvalue.regardsbenjamin
- Re: [tlug] "Go Considered Harmful"
- From: Curt J. Sampson
- Re: [tlug] From an enthusiast TLUG follower
- From: Stephen J. Turnbull
- Re: [tlug] From an enthusiast TLUG follower
- From: Benjamin Kowarsch
- [tlug] "Go Considered Harmful"
- From: Curt J. Sampson
Home | Main Index | Thread Index
- Prev by Date: Re: [tlug] From an enthusiast TLUG follower
- Next by Date: [tlug] Flies, honey and vinegar
- Previous by thread: [tlug] "Go Considered Harmful"
- Next by thread: Re: [tlug] "Go Considered Harmful"