+1 to this. Nowadays when I see some "Considered harmful" post on HN its tends to be some dude on his personal blog talking about how in his 2 years of programming experience JS framework X is bad and instead you should use JS framework Y. Instant red flag and I'm likely to ignore.
> The best programmers I know rarely see things as 100% good or bad.
And even if you do, it's still better to say "X is bad because Y" instead of a meaningless assertion like "X is an antipattern" or "X is a code smell".
But are the "best programmers" the best judges of such things. I often find they are not because they often understand their tools in a way that is incomprehensible to others. I've seen many junion engineers fizzle into disfunction because they are paired with "one of the best programmers". I've seen "the best programmers" adopt tools and patterns that cannot survive their departure because they are too complicated and too specialized for anyone else to own.
> rarely see things as 100% good or bad.
For me, I held this view most strongly when I was an intermediate programmer. I quickly moved into the "every tool for its job" phase after the "the things I learned with are best" phase.
But as I've become an advanced programmer, some of my opinions have become much stronger. For example (and this is just an example I don't want to argue about this) I currently see "the self initializing singleton" as pretty much a 100% bad pattern. This because my experience has taught me that not knowing when something is going to get setup is a weakness, not a virtue. This is an opinion I was actually incapable of developing as an intermediate programmer because I had not yet encountered the myriad of annoying bugs that come from ambiguities of initialization. I just respected the "ease" and "cleverness" of the pattern.
> I've seen "the best programmers" adopt tools and patterns that cannot survive their departure because they are too complicated and too specialized for anyone else to own.
That was not the kind of developer I was thinking about.
> But as I've become an advanced programmer, some of my opinions have become much stronger
I don't mind strong opinions at all. What I mind is extremism, and how terms like antipattern and code smell contributes to it.
You called the singleton pattern you described a "pretty much 100% bad pattern", then went on to explain your experience and opinion in a humble way. I think that's a great example of a strong opinion which was not "extreme".
I tend to like the phrase "Strong opinions, weakly held" to describe that sort of "best programmers". Through experience they have come to hold certain ideas, and will express them strongly, but are willing to describe why, and also accept that they aren't universal, mostly rules of thumb i.e. they aren't dogmatic.
The entire concept of a "code smell" is something which is often but not always bad, so I'm not sure why rarely seeing things as 100% good or bad would lead to you avoiding the phrase.
I mean, "often, but not always bad" was what "code smell" was originally supposed to mean: Patterns which may have a valid reason, but which in the common case show some bad design or lack of understanding.
But that's difficult to distinguish and act upon, so the meaning seems to have morphed into generic "bad thing you should never use".
Intentionally ambiguous: the phrasing is specifically meant to suggest that it’s assumed non-universal and might not apply to all circumstances. If you embrace that ambiguity it’s a good antidote to the “considered harmful” problem and may well be less annoying.
- "Bad smell" immediately invokes disgusting sensory experiences. It's intended to be ambiguous but it's not used this way.
- "Anti-pattern" is also ambiguous, because patterns have some bad uses, and anti-patterns have some good uses.
- And "Considered harmful" is also ambiguous. To consider something harmful is not the same as it being harmful, you're just considering it.
These phrases are used automatically and intend to sound authoritative about something being bad, period, despite their historical nuance and ambiguity. And frankly they're all disgusting and annoying at this point.
They show the author is more into clichés and clickbait, than substance.
Is it though? Like, if I see a lot of nested "ifs" with "returns" sprinkled around, I'm getting "icky" vibes way before I intellectually know what is wrong.
Like, I don't think you can get away with just typing "code smell" in a CR. That's lazy but the gut reaction to some code can be a useful starting point.
I kind of feel this way sometimes, but some business or even non-business logic will require some inherent minimum amount of cyclomatic complexity. And there is only so much you can do to hide it or spread it around; depending on the specifics it may actually be better to put the whole ugliness in one place
I guess that is why it’s a smell and not an anti pattern, but I work in a codebase with a lot of this kinda stuff and as much as I hate the complexity required to read it, I’ve been around long enough to know why all those ifs are there and even added a few myself.
If it's in a language with guaranteed tail recursion optimisation and it's idiomatic in that language (these two things often go together) then fine, seems reasonable, Go With God.
Otherwise, nope, I don't care that "I checked and it's optimised correctly". We do not write optimiser dependent code in my house, write something that won't explode messily when we change target or upgrade the tools or whatever and now it stack overflows.
Erase it and do it iteratively like any sane person!
Kidding aside, I'm more talking about the kinds of large procedures common to C++ codebases. These involve many sequential state changes which leave lots of opportunities for not initializing things and the like when the right set of conditions are met. The more paths available through this kind of code the more likely it becomes we'll create a bad one and fail to anticipate the conditions which trigger it.
You should write a blog about this. You could call it "Examining falsehoods programmers believe about the unreasonable effectiveness of 'considered harmful' for fun and profit."
When I see a "Considered Harmful" post, I still click on it, expecting to find satire since it's such a cliche at this point. I'm almost universally disappointed.
> Typically, “considered harmful” essays gets written because someone has an axe to grind, and they feel like making that grinding process both public and dogmatic.
Well and concisely put. I agree.
Personally, what bothers me most about "X considered harmful" essays is the unspoken subject of the sentence. Who is it that considers X harmful? The title is structured to imply a broad consensus that is well beyond the point where anyone could possibly disagree with it. They want you to read it as "X considered harmful by all experts you should trust", but it's almost never that. The author is making up an authority, then telling you the authority is on their side.
What really tickles me about this “X Considered Harmful” title is that in its first famous appearance, it was an editor who rewrote the title of Dijkstra’s letter which was something like “A case against the Go To statement.” So in that original case, it was clear that the author of the letter was the person/authority in question.
Now, to me, one isn’t supposed to use that passive voice title for one’s own writing unless you want it to be taken as a joke.
Djikstra never wrote anything titled "Goto Considered Harmful". His paper had an entirely different title, and some publisher made up that title and published it with that title, without asking Djikstra first.
"...except this one.", right? ;) (Certainly you anticipated this response.)
Kidding aside, Fortini's tongue-in-cheek answer is the best one to such silliness. Certainly advice is neither absolute or contextless. I'd say that to suggest otherwise, especially in online discussion, is to act in bad faith.
Certainly "considered" is already doing the job of pointing out it's an opinion, not natural law.
As even the OOP states, Dijikstra didn't choose this title, though. Niklaus Wirth did. From a different reference:
> Finally a short story for the record. In 1968, the Communications of the ACM published [...] "The goto statement considered harmful," which in later years would be most frequently referenced, regrettably, however, often by authors who had seen no more of it than its title, which became a cornerstone of my fame by becoming a template [....] But what had happened? I had submitted a paper under the title "A case against the goto statement," which in order to speed up its publication, the editor had changed into a "Letter to the Editor," and in the process he had given it a new title of his own invention! The editor was Niklaus Wirth.
I dislike "your anti spam idea will not work because" lists more. They're an FAQ of reasons people say "won't work" when they just mostly mean "does not please me" or "invokes regulation and/or finance ie costs and I'm here for free"
It's fine to be opposed to regulatory or cost models but saying won't work masks the real issue: don't want.
I see, so, people explain why an anti-spam idea won't work and in fact it doesn't work, but you feel both the people who've explained why it won't work and the universe we live in where it didn't work are wrong.
Some of them won't work. It's true. Many even. But the list is huge and includes ideas which would reduce spam but demand regulatory engagement which nobody wants to discuss seriously, or financial consequences. Fundamentally I've always felt it's dishonest, disingenuous to combine things you don't like with things which won't work.
It's been used as a put down by the email cabal for over two decades. Ietf grey and whitebeards. It's just a mechanistic formalism to define an ingroup and an outgroup now. I whine about it on mail related lists and forums from time to time and have done since it first emerged. Dealing with bad ideas is important, putting new entrants into the problem space off by being patronising is really asocial.
The irony is that centralisation of mail into a parallel cabal of Google, O365 and a small number of others is probably altering the surface of email problems by ignoring the list, and doing what they do, for money, and under regulatory pressure.
Many of the "it won't work" mob are now finding running a full stack, ipv6 enabled SMTP sender next to impossible. Dkim and spf won't stop reputation agents dismissing them as "bad"
As someone who wrote a Considered Harmful essay which ended up on the front page [1], allow me to disagree.
"X Considered Harmful" lets the reader know very precisely what it is they're about to read: a warning about a particular pattern or behavior that is common but tends to backfire. This goes for all meme-ified headlines ("X I love you but you're bringing me down", "Unreasonable Effectivenes of X", etc etc)
It's important to bring nuance to a discussion rather than taking an extremist position, and I think that's the author's main gripe. But nuance also adds confusion and waters down the message. Sometimes it's better to stake a clear position at the outset, and then address the nuances.
You can't just have balance; you have to balance balance with imbalance, balancedly [2]
I don't buy it. It is still absolutely distasteful to reach to the nearest cliché as a bait. This much-abused phrase falsely implies one man's personal take as a broad consensus. (Also see karatebot's excellent point[1] in this thread.)
If your "clear position" truly has any legs, it will stand without having to resort to "harmful" clichés as a lure.
There are many truthful things written, many with legs, but attention economy makes it so, that they are often overlooked, no matter how good their legs. However, further escalation is not going to improve the situation.
It's not about being "not that bad". Unless you really know what you're talking about, it is simply "good internet manners" to not sleep-walk into such an overloaded cliché. Most readers on the internet are in a hurry. If you're putting something out with such a heavy-handed headline, you jolly well be right.
The point is, we have to do our part in resisting the impulse to add to the pile-of-poo (which is most of the internet).
I authored a "Considered Harmful" essay against another "Considered Harmful" essay. [1] I knew about this essay when I wrote mine, and I still wrote mine.
Why? Because the author of this essay is a hypocrite. He specifically disclaims his own essay from consideration:
> For example, a piece titled “‘Considered Harmful’ Essays Considered Harmful” would very likely be a case of using the “considered harmful” format to draw attention for its own sake. We will ignore such essays in this commentary.
But in so doing, he claims that using "Considered Harmful" to draw attention to the essay is fine. That's why I used it, and it worked. [2]
He also says they are typically used by someone with an axe to grind. This is true. To combat this, I took a mellow tone in my essay, as compared to the inflammatory post I originally wrote on the same topic. [3]
And yet, he transparently has an axe to grind against "Considered Harmful" essays because he does not allow nuance:
> It would therefore seem obvious that the only intelligent course of action is to abandon their use entirely, and instead look to more constructive forms of essay writing in the support of debate positions.
Basically, he says that use of "Considered Harmful" essays must be abandoned completely because they don't support their intended positions well.
If so, why did he write one of his own? Is it parody or actually serious? I can't tell.
But sometimes, "Considered Harmful" is the best way to express something. In that case, use it. But IMO, you should only do it after careful consideration, like what I did for my essay.
Don't hamstring your writing by restricting your expression, and don't be a hypocrite. But do be careful and mellow.
the paper was written at a time when public safety warnings were first mandated to be put on consumer products, stuff like "smoking considered harmful" on a pack of cigarettes. It was a clever and winking reference to the zeitgeist, just as hyperventilating about tone is today, something like "Wirth and Dijkstra were guilty of privilege escalating themselves to microaggress against FORTRAN programmers"
Goto is a perfectly good command in moderation. So, the first instance of “Considered Harmful” was harmful; the pithy title combined with the famous author has resulted in a disproportionate response (the total loss of this perfectly decent bit of syntax).
It was only harmful to the people that read the title and not the actual letter. Dijkstra's take was much more moderate than most people seem to think it was, and the title wasn't even his.
Yeah, the angst about goto is misplaced. Dijkstra was mostly talking about control flow jumping all over the program, ie spaghetti code.
So it's funny when people rigidly adhere to the goto ban while simultaneously littering a bunch of tiny single use functions and classes all over their supposedly well-designed code.
They are only equivalent to a very limited goto, not the unlimited sort that Dijkstra's letter was primarily about.
A continue or break can be replaced with this:
while (some_cond) {
if (whatever) continue;
if (whocares) break;
}
=>
while (some_cond) {
next:
if (whatever) goto next;
if (whocares) goto after;
}
after: ...
EDIT: added break into the above, forgot to earlier
Note that it stays within the same scope or, in the case of a break, would just escape that scope. The sort of goto Dijsktra wrote about would let you do things like this:
void foo() {
while(some_cond) {
next: // how did we get here again?
...
}
}
void bar() {
goto next;
}
Many control flow instructions can be expressed as other instructions. The idea of the article was to promote higher level, less ambiguous and less ubiquitous instructions.
Sure, you can express a for-loop in terms of goto. But when you read a for-loop, there are many things you're guaranteed won't happen that could with a goto. In that sense, it takes less attention to make a good for-loop. And a for-loop iterating over a collection also takes less attention than one with a manually-crafted iteration check.
That's the whole point of the article: lower-level instructions should be wrapped in higher-level instruction, more specialized and with less footguns.
When I got my very first introduction to computers and programming as a middle schoolkid in the early 90s India ...
I got home the set of textbooks for BASIC programming language from the institute -- the classes had not yet started. So I knew next to zero about programming and barely touched a computer.
I sat down and read through the books. They were all well-written and most of it made sense (whatever I could make sense of -- having never written a program before)
All commands seemed to have some logical names : LET, IF ... THEN ..ELSE, FOR, PRINT, INPUT, etc.
But one command stumped me.
GOTO.
I was not a native speaker of English and wondered if it is an obscure english word.
(My mind defaulted to sounding it as a single word, "lotto" with a G)
I read the explanation and that sounded okayish -- make the program execution jump to a line number specified after the GOTO command.
But what the hell was "GOTO" -- why did they name it that -- I had no clue.
It took embarassingly long for me to realize that it was a rare command (the only one perhaps?) in BASIC language that is not a single English word but simply a combination of the simple words 'go' and 'to' :)
So I have a special place in my heart for this command :)
I recently had to work with a small FORTRAN IV code base from the early 1960s where all control flow is done with gotos. That's what Dijkstra was arguing against, not the moderate modern use.
> Goto is a perfectly good command in moderation. So, the first instance of “Considered Harmful” was harmful
You're fighting yesterday's battle, and you're siding with the losing side. The ideas from this article have been the trend for new programming language innovations for several decades now, and it has yet to cause any harm.
I might be a bit too young, having mostly worked with Java-and-higher languages...what is a good usecase for goto? Most of the languages I use don't even have an equivalent syntax.
1. Sometimes more efficient code (state machines can make really good use of this pattern)
2. There is no structured programming equivalent or no good structured programming equivalent within the language.
For (2), you see it a lot in the Linux kernel (and similar) code where it's utilized for early exits. Where a language like Go might use a defer statement or Java and similar might use a try/catch/finally and exceptions, C would put a bunch of clean up statements after one or more labels at the end of the function before the single return. Which label you go to (if you use more than one) would depend on how far into the function you've gotten.
> 2. There is no structured programming equivalent or no good structured programming equivalent within the language.
My emphasis. C is barely younger than Dijkstra's letter, and by comparison to a modern language it is impoverished when it comes to structural flow control. Still, you won't find modern C programmers arguing that they don't see any use for while loops, or that switch is pointless because they could just use longjmp.
It's fairly fundamental in languages, just hidden behind syntactic sugar like if/else and try/catch/finally. Outside of those it can be useful for de-duplicating cleanup and exit code from a function.
it's tricky because the kind of situations where goto is helpful are usually frowned upon, but sometimes they are unavoidable. like large nested state machines that you need to jump around in or skip parts of. this was more common with C.
when used properly it should be really obvious what it's doing, where it's going, and shouldn't produce any weird side effects. jumping into another function or module or file isn't good.
If we get enough people writing about "considered harmful" using the very words "considered harmful" as a kind of counter, will we see the next level in form of those being "considered harmful"? ("considered harmful"^3, or perhaps ch-ch-ch?)
This writeup is not backed by data and looks to be the author subjective opinion. I had a chance to read some "considered harmful" essay that where more convincing. In the end it boils down to the quality of the content, and the source is likely to be a better hint than the title.
I hate to see some low-quality articles which just repeat some extraordinary good documents. All these examples I have seen in a short period of time such as one week.
