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 22:49:56 +0900
- From: "Stephen J. Turnbull" <firstname.lastname@example.org>
- Subject: [tlug] "Go Considered Harmful"
- References: <email@example.com> <CADR0rnf86TcHyrFsTwfPPy-NN_Ucnm4zEasNxkOSH0E_7YxbqQ@mail.gmail.com> <firstname.lastname@example.org>
Curt J. Sampson writes: > > 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. Oh, I thought he made it clear in the caricature that he led with, which failed to make it to the level of satire. "Although that may only be obvious if you're [an economist]." > But they use it not because they don't know how to make a design > "better" or are just too lazy to do so, That's the "ultimate computer virus" remark. That short letter is remarkably deep (at least from the social science point of view). > 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, Indeed. I think that is *implicit*, but YMMV. It's useful for you to make it *explicit* here. ;-) > > OTOH, python -m this is shorter (though later, Peters, 1999). > > Yes, and also unfortunately half nonsense, You sir, are obviously not Dutch. More seriously, the Zen of Python is not about coding, but rather about language design. Programmers, and maybe even engineers, are going to be violating the Zen in their code all the time. The world is not "simple", it's usually even "complicated". If you're writing a program that does "real work" (rather than automating your messy paperwork shuffle), most likely your implementation is going to be "hard to explain", but that doesn't make it a "bad idea". On the other hand, when you're designing a language, you don't want the programmers who need to deal with domain complications to have to deal with unreadable language constructs whose semantics are hard to explain. Compare the masterpiece of unified obfuscation that is the Common Lisp "do" special form with Python's pair of "while" and "for". > that even Python doesn't follow. Consider even "implicit is better > than explicit." Quote much? :-) python -m this | grep is your friend. > 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)`. "Explicit" does not mean "eschew defaults." All of those are quite explicit. Except for "None" in "flag=None", which typically doesn't tell you anything about what the default means. What this koan means is "the default must be obvious to a typical practitioner who is not a language lawyer" and "don't depend on context hidden in a state variable". (Especially a dynamically-scoped variable.<chortle/> And what was that you were saying about "parser state" and Plain Old Python Functions? ;-) > And "special cases aren't special enough to break the rules"? The best thing about the Zen is that it's like the Bible: there's always a verse to justify what you wanted to do anyway. That one is immediately followed by "Although practicality beats purity." > 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. You don't program enough Python! Drink the Kool-Aid Curt! Drink! I don't think the rules are the problem. I think the problem is the programmers, and the dire scarcity of software engineers, especially among project managers. Steve