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]
[tlug] "Go Considered Harmful"
- Date: Mon, 31 Aug 2020 15:04:04 +0900
- From: "Curt J. Sampson" <firstname.lastname@example.org>
- Subject: [tlug] "Go Considered Harmful"
- User-agent: NeoMutt/20170113 (1.7.2)
(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": 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 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." > 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. > 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  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.) : https://dl.acm.org/doi/pdf/10.1145/356635.356640 : https://dspace.mit.edu/handle/1721.1/5753 : https://github.com/dot-home/unfortunate/blob/master/share/fortune/dijkstra cjs -- Curt J. Sampson <email@example.com> +81 90 7737 2974 To iterate is human, to recurse divine. - L Peter Deutsch
- Re: [tlug] From an enthusiast TLUG follower
- From: Benjamin Kowarsch