6 ms·
So were PHP and goto statements. How influential something is has nothing to do with how good it is.
by wyager 11y ago
So were PHP and goto statements.
How influential something is has nothing to do with how good it is.
- vezzy-fnord 11y agogoto is just a mnemonic for jmp. It's the primitive from which all higher level control flow is ultimately derived. It isn't harmful, and it's used a lot even in C.
- duskwuff 11y agoYou're missing the reference - Dijkstra wrote a famous letter on GOTO in 1968 which was published as "Go To Statement Considered Harmful": https://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF https://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF In context, it was a piece advocating against the use of GOTO to the exclusion of all other control structures (e.g, 'for' or 'while' loops, etc).
- vezzy-fnord 11y agoI appreciate you thinking I'm a buffoon who was born yesterday and hasn't heard of EWD215, but it appears your reading comprehension is, to be charitable, iffy. wyager's statement, involving PHP (for which there is not a famous "considered harmful" essay to the best of my knowledge, though there is "A Fractal of Bad Design") and goto statements, was a rather clear implication that both constructs are innately harmful in an attempt to counter n0us' assertion that influential/popular technologies imply a high quality. There was nothing said about using goto statements in presence of structured programming, but merely goto as an intrinsic badness. This is a common belief cargo culted by a many naive commentators and XKCD readers who do not realize that all control flow is derived from goto, and moreover that even in some languages with structured control flow it is still useful, e.g. for resource cleanup and breaking out of nested loops.
- garrettgrimsley 11y ago>Be civil. Don't say things you wouldn't say in a face-to-face conversation. Avoid gratuitous negativity. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- vezzy-fnord 11y agoMy statement was neither something I wouldn't say face-to-face, nor gratuitously negative.
- hderms 11y agoIt comes off as unpalatable, to say the least. You were assuming malice in the other poster and then went on a minor tirade without sufficient prompting.
- asveikau 11y agoThe comment being replied to was also rather uncivil by a certain definition, assuming the commenter was unfamiliar with what is by now very cliched literature and explaining it in a somewhat condescending tone, as if to a child, when in truth there was a very substantive point being made.
- hyperpape 11y agoIsn't that more aptly stated as "implemented with" not "derived from"?
- vezzy-fnord 11y agoAssuming a von Neumann or modified Harvard architecture where execution advances from an incremented program counter, I'd say derived from, though it may be that the former is more appropriate. It is certainly not universal, I do not make that claim.
- hyperpape 11y ago
- mortehu 11y ago> [goto] is the primitive from which all higher level control flow is ultimately derived I'm pretty sure you cannot implement conditional branches using unconditional branches as a building block. Unless you count indirect branches, which goto usually doesn't support.
- taeric 11y agoNot that I'd recommend it, but sure you can. Just allow modification of the code to include where you want to jump to. :) Scarily enough, I think this used to actually be somewhat common place and is why many functions were not reentrant.
- ska 11y agoThat largely misses (Dijkstra's, originally) point. How control flow is implemented at a low level (e.g. jmp/lngjmp) is a completely separable from how it should be exposed in a language. Wearing a c programmers' hat you may say "absolutely", a scheme programmers' hat, perhaps "no way". Horses for courses after all.
- vezzy-fnord 11y agoThat's a more nuanced position than the one that is commonly understood, however. Though, you are always bound to your architectural model, so exploiting it more directly is not innately bad. Layers tend to be leaky. Wearing a Scheme programmers' hat, call/cc isn't any less of a landmine.
- Retra 11y agoIt's a matter of scale. If you're trying to compute absurdly large numbers, you'd be a fool to use addition, even if it is fundamental to some other operation you want to use. Goto is problematic not because it can't be used effectively, but because it won't be. Because it doesn't encapsulate a powerful enough abstraction to make computers smarter or programs easier to write and understand. If you have to write a goto, you can drop into assembly. Don't add it to your high-level language, because it doesn't add anything there, it just gets in the way. "It's the primitive from which all higher level control flow is ultimately derived." There are a billion alternative primitives from which you could derive all the same things. Goto is not special. And it is so primitive, it is not hard to write something else and have a compiler translate it. You shouldn't need goto anymore than you should need access to registers.
- jrcii 11y agoThe PHP bashing on this site is untenable. PHP has no intrinsic properties which stop a good programmer from writing elegant code for web applications. It's a tired discussion, I know, but the most you can say is that it's frequently abused. The oft cited "Spectacle of bad design" essay has been credibly rebutted point-by-point by other authors.
- pizza234 11y agoIt's hard to take seriously a statement about an article, where even the referenced title is wrong. It's not nit picking - it shows how one didn't even took them time to read and understand the article; it's "fractal" of bad design, and it's named so for a specific reason.
- mamcx 11y agoWhen some insist to use C++/JavaScript/PHP/MySql/Mongo/etc (tools with bad design/complexity/bug-prone/etc flaws) with the excuse that is possible to use them "well" if only we are more "disciplined" and "pay attention"? When bad tools are bad, discipline is not the answer. Is fix the tool, or get rid of them. Why developers understand that if a end-user have a high-error rate in one program is a problem with the program but when that happend with a language/tool for developers... not think the same??? "Good programmer" is almost a keyword in this context as "someone with the experience with for workaround and avoid the pitfalls that a tool is giving to him, plus also do his job" when is better if "someone that can concentrate in do his job". Of course, workaround the pitfalls of tools is unavoidable in a world where "worse is better" have win. But why persist on this?
- AnthonyMouse 11y ago> Of course, workaround the pitfalls of tools is unavoidable in a world where "worse is better" have win. But why persist on this? Because the unstated alternative is a false choice. It would be nice if all of the code written in poorly designed languages would disappear and be replaced with code in better designed languages, but that isn't realistic. Migrating a large codebase to a different language is very expensive and introduces fresh bugs, less popular languages aren't supported by all platforms and libraries, and large numbers of people have made significant time investments in learning languages that are popular even if they aren't very good. So the old languages aren't going away. Given that, it's better that we teach people the pitfalls of the things we're stuck with, and improve them with things like std::unique_ptr in C++ or safer SQL APIs that discourage manual parsing of SQL statements, than to pretend that there is no middle ground between continuing the tradition of bad code and the fantasy of rewriting essentially all existing code from scratch overnight.