Your statement is correct but misses the point - <AUTHOR> http://nibblestew.blogspot.com/2020/04/your-statement-is-100-correct-but.html?m=1 <comment><USER2> That's the problem with being pedantic. Pedants are correct, but they're not curious, and they don't care about learning something because they lack humility (humility is difficult to learn and rarely encouraged).

A discussion, an argument or a debate is not meant to be some sort of confrontation quiz, where people who demonstrate they're right can win an audience. A real debate, argument or discussion is when an audience can listen, and ask questions to better understand what everybody is trying to say. A debate is a distributed way of thinking. Human thought only exists through language, un-worded ideas always die.

This mentality stems from how people views how democracy works. The Socratic method thoroughly shows that having an argument is about helping each other communicate their point of view. And this is exactly how states like Russia are able to undermine democracy, by sowing confrontation and polarization.

What is horrible is when this sort of polarization happens in your daily life, or in science or at work.

<comment><USER3> The trouble is often the listener thinks the speaker is pedantic when the speaker thinks there's a very legitimate problem the listener is ignoring. Since we're using C(/C++) as an example, I'll take a bite out of the other page that just got re-posted today. [1] Is it "pedantic" to point out that &*p is undefined behavior if p is NULL? Or is it "pedantic" to point out that uint8_t isn't a substitute for unsigned char? Lots of people who see C as something resembling high-level assembly view arguments like this as pointless pedantry, often since they haven't really across cases where the distinction has mattered. Meanwhile those on the other side of the debate feel like they're not being heard and pull their hair out trying to get people to stick to the spec of the abstract machine rather than that of their hardware, because they think (rightly or wrongly) the next compiler version will likely break their code if the existing ones already haven't.

[1] [https://news.ycombinator.com/item?id=22848423](https://news.ycombinator.com/item?id=22848423)

<comment><USER4> Is it possible they would be served by a different standard where C is a high- level assembly? Although admittedly, "&*p" to me reads as 'load p' and therefore undefined behaviour

<comment><USER5> The literal sequence "&*E" is actually equivalent to E even when E is a null pointer. The spec explicitly points this out.

<comment><USER6> Why does the spec mandate support for useless bad code instead of banning it?

<comment><USER7> 1\. Probably backwards-compatibility.

2\. While you wouldn't write &*E by hand, it can easily arise from a macro expansion.

</comment></comment></comment></comment></comment></comment><comment><USER8> On a related subject, I do feel like there's been real, tangible moral harm done to our society by reinforcing the idea of debate as a competition in children. When we reinforce certain behavior, we shouldn't be surprised when that reinforcement extends to the rest of their lives.

When we turn debates into something that is "won" rather than something that is seeking a refinement of what we know as truth, we encourage people to use deceptive tactics: to appeal to straw men if they can get away with it, to distract from the issue if they can get away with it, to do whatever they can do to _win_. That's how you end up with blowhards like Ben Shapiro: people who are more interested in winning a debate by any means necessary and reinforcing their existing belief systems then discovering truth. You get a thrill out of "victory," but it is less than hollow when it's won by appealing to fallacious arguments: it actively works against our ability as a society to understand the concept of truth. And it is so easily abused by people with malicious intent.

<comment><USER9> As someone who grew up in different debate-club-esque environments, I agree wholeheartedly. I had to unlearn quite a few patterns of thinking and behavior—patterns that had been positively reinforced by most adults in my life—when I grew up.

For me, the most damaging effect was the separation of debate and decision making. In real life, if I advocate for a position—be it where we eat dinner or where my child goes to school—and I'm convincing, things actually happen. We have to go to that restaurant and my kid has to attend that school. Debates happen to inform a decision all parties are trying to make together.

As a kid, the opposite was true. Debate was about proving my intelligence in exchange for praise from my teachers, parents, and peers. It was an athletic competition in which our positions were our jerseys, in that we took them off after and went home.

I was reflexively argumentative for a decent period of time as a young adult before I realized the damage it caused to my relationships and how unproductive and dishonest it was.

<comment><USER10> I think it's Richard Dawkins who uses the word _discussion_ to contrast with the word _debate_ (used in the combative sense).

In a discussion, several parties with different perspectives work together to make progress toward truth, whatever that means in the given context. If one or more parties has their opinion changed, that's seen as productive.

In a debate, several parties plenty a points-based game (perhaps even literally), and if someone is seen to be changing their mind, they lose.

</comment></comment></comment><comment><USER11> Lots of programmers forget that they should also be engineers, and not only computer scientists (or wannabe computer scientists).

I can still remember how during the first programming class I took at uni 20 years ago the teacher told us that "engineering is all about compromises and especially about what compromises you should choose to make or not" (in that context she was talking about memory vs processor usage), and while I managed to barely pass her class that piece of advice has stuck to me ever since. Looking at things through the compromise lenses (for lack of a better phrase) would eliminate lots of misunderstandings rightfully pointed out by the OP in this article.

<comment><USER12> The failure of engineering in the presented hypothetical examples is a failure to understand the use case.

I say this because I remember a class I took in college where I built a chat application and the TA chided me for using a hashed message ID instead of using random number generation. I was concerned that eventually there would be collisions and that would lead a message to either be undelivered or delivered to two parties (depending on implementation). The TA said "yeah but that's an infinitesimal risk."

The problem with his view was that the intended user group would eventually see this failure occur. It's not an avoidable edge case, it's a bug that will impact the general use case. The failure could occur on an important message ("I'm gonna be at work late, can you pick up the kids") or a sensitive one ("I can't believe you cheated on me with our babysitter"), and the user would have no idea what happened.

The article mentions NSA hacking and aggressive computation on a small microprocessor, but those issues are both easily avoidable by the atypical user. Are you a spy? Don't rely on HTTPS. Are you building an embedded system? Learn how to use C++ instead of Python.

There is plenty of room within engineering to have sound practices that use computer science to mitigate edge cases. A problem arises when those edge cases don't affect the intended user, or are easily and obviously mitigated by the user choosing a better tool.

<comment><USER13> So would you accept that your solution is sound, from an engineering perspective, but could be considered overkill for a college class?

<comment><USER14> A sufficiently large and properly generated random number is as unlikely or less likely to collide than a sufficiently large hash.

However, using the random number is strictly simpler to implement, therefore it wins out from an engineering standpoint, unless you do not have access to proper RNG.

</comment></comment></comment></comment><comment><USER15> Hence the classic joke:

\</comment><comment>----

A man in a hot air balloon realized he was lost.

He reduced altitude and spotted a woman below. He descended a bit more and shouted, "Excuse me, can you help me? I promised a friend I would meet him an hour ago, but I don't know where I am."

The woman below replied, "You are in a hot air balloon hovering approximately 30 feet above the ground. You are between 40 and 41 degrees north latitude and between 59 and 60 degrees west longitude."

"You must be an engineer," said the balloonist.

"I am," replied the woman, "How did you know?" "Well," answered the balloonist, "everything you told me is technically correct, but I have no idea what to make of your information, and the fact is I am still lost. Frankly, you've not been much help so far."

The woman below responded, "You must be in Management."

"I am," replied the balloonist, "but how did you know?"

"Well," said the woman, "you don't know where you are or where you are going. You have risen to where you are due to a large quantity of hot air. You made a promise which you have no idea how to keep, and you expect people beneath you to solve your problems. The fact is you are in exactly the same position you were in before we met, but now, somehow, it's my fault!"

<comment><USER16> This comment will play extremely well on this website, which engineers frequent. And it's admittedly a great joke. But only tangentially relevant to the author's point.

The author's point is closer to the old adage of not shooting yourself in the foot. That is, however true your statement is, if it denies further thought it becomes a useless point.

<comment><USER17> So it's 100% a good joke, but misses the entire point.

</comment></comment></comment><comment><USER18> I see this incredibly often in medicine-- particularly from nurses, midlevels and patients when they don't have great relationship with the physician. Myself included (although I try to have a good relationship and communication I don't bat 100). People tend to latch on to what they know or think they know, and it's very hard to get them focusing on the more important issue that may be at odds with that. As an example-- I trained at a place where a patient disagreed with his doctor's assessment (something about lung fluid analysis). The patient cited a well-respected journal article that guided standard of care. But, the patient didn't realize something. The doc treating him _authored_ that article.

We see stuff like that routinely-- evidence gets misinterpreted and people get angry because their sources (but not their interpretation) may be excellent.

<comment><USER19> At the same time, it goes the other way too.

I cannot believe the number of doctors that I visited when I first got GERD, and all my questions were shot down while they prescribed PPI upon PPI. It only made my condition worse by the year.

Finally, I decided enough is enough, and did my own research, happened upon naturopathic materials, and experimented in a logical fashion (eliminating one trigger at a time, trying a new natural cure at a time) till I chanced upon probiotics - specifically Yakult which works best for me, and have been living a normal life since then.

The kicker is that if I had taken this approach from the start, my stomach and quality of life would have been much better from the start.

Sure, it's anecdotal, but it's a counter-example to your assertion which, frankly, smacks of derision for the thinking patient. You have to remember that doctors, like those in any other profession, come in a spectrum of qualifications, capabilities, and empathy.

<comment><USER18> Physicians are human and subject to their own biases and mistakes. I could go on about how helpful patient/nursing/midlevel input is and has been to me personally in my career. But the point I'm trying to make here is that the shallow vs deep thinking shows up in medicine at obvious points and causes problems.

<comment><USER20> We also have our own biases. That physician has probably seen 100s of patients who have self-diagnosed something that turned out to be wrong, whereas the physician is usually correct about diagnoses. In this instance, the self- diagnosis was correct and the physician was wrong, but I would bet this is the exception, rather than the rule.

</comment></comment></comment></comment><comment><USER21> The rationalist community has a kind of meta-rule that contributions to a debate should be at least two of {true, necessary, kind}. For necessary you can often also read useful.

Once you're out of high school debate club, it's a good principle that if the only thing in favour of a statement is "it's true", err on the side of not saying it.

<comment><USER3> Interesting that truth isn't a requirement, especially given we're talking about rationalists. In what situations do they welcome false contributions?

<comment><USER22> I think the idea is that it's forgivable to make mistakes, as long as you aren't also being unpleasant.

<comment><USER3> Edit: Sorry, I just realized I misread something. What I was pondering was what "necessary" meant in this case, but I think my brain is tired right now!

<comment><USER21> From [https://slatestarcodex.com/2014/03/02/the-comment-policy- is-...](https://slatestarcodex.com/2014/03/02/the-comment-policy-is-victorian- sufi-buddha-lite/) :

{necessary, kind}:

> Recognizing that nobody can be totally sure what is or isn't true, if you > want to say something that might not be true – anything controversial, > speculative, or highly opinionated – then you had better make sure it is > both kind and necessary. Kind, in that you don't rush to insult people who > disagree with you. Necessary in that it's on topic, and not only contributes > something to the discussion but contributes more to the discussion than it's > likely to take away through starting a fight.

{true, kind}:

> Annnnnnd sometimes you might want to share something that's not especially > relevant, not the most important thing in the world – but if you do that it > had better be both true and kind. No random interjection of toxic opinions > that are going to cause World War III. No unprovoked attacks.

(personal comment - the recent HN thread on castle Guedelon, where a bunch of experimental archaeologists are building a medieval-style castle, was perhaps not "necessary" or "relevant" on a tech forum, but it was kind in that I very much enjoyed the half hour I was reading about it. Since there were no false claims about castles on that page, I'd count that as "true and kind".)

For good measure, {true, necessary}:

> Nobody can be kind all the time, but if you are going to be angry or > sarcastic, what you say had better be both true and necessary. You had > better be delivering a very well-deserved smackdown against someone who is > uncontroversially and obviously wrong, in a way you can back up with > universally agreed-upon statistics.

</comment></comment></comment></comment></comment><comment><USER23> This is great. I would extend the things discussed in the article.

1\. Not everyone participates in a conversation for the same reasons. Some are here for rational purposes, others emotional purposes e.g. Getting an answer vs feeling accepted. Neither of these are wrong but being aware of that makes empathizing and filtering easier. We are social creatures and nothing we do happens in a vacuum.

2\. Being right and useful is a core part of many peoples identity. If we can't contribute in a relevant way and be right, we'll often contribute in an irrelevant way so that we can be right. Our reasons for participation are largely emotional.

3\. Communicating purpose is hard. Giving people the information and context required to decide when and how to act appropriately is hard. We often skip it e.g. in the discussion covered in the article at no time was the purpose covered. Why are we stating these things?

It's not culturally standard and perhaps next to impossible to do but starting a conversation by:

      - Clearly stating the purpose.
      - Clearly stating your view points.
      - Considering what you want to get out of the conversation.
      - Considering what information, arguments or data would be needed to change your mind (if you are willing to change your mind).

Would help make discussions be more effective.

I wrote something about this a few years ago if anyone is interested to read: [https://medium.com/@ioverthoughtthis/how-to-have-an- effectiv...](https://medium.com/@ioverthoughtthis/how-to-have-an-effective- debate-bb955c2c54fd)

</comment><comment><USER24> This article could be titled "Will people less smart than me shut the fuck up already? Part N of Infinity" I haven't been a fan of previous ones and this is no different.

People will always be wrong. And it's easy to say it's because they're not thinking about something clearly enough, because very often they aren't. I'm sure it's cathartic to complain about them on the internet, but it won't change anything. So either ignore them or help them.

Having productive conversations rather than just satisfying the human urges around disagreement is a life skill. Understanding how to identify when conversation is destined to go nowhere and exit it effectively is a life skill. This article could have chosen how to build and exercise those skills in the face of this kind of wrongness. But it didn't and neither have most the comments. It chose to pontificate on a root cause.

It doesn't do anyone a service by writing hypothetical stories about how and why every person wrong in a particular way came to be wrong. Yes, it's 100% correct that those assessments could be useful in finding a way to conversationally bride the gap, but in practice they're just used to make someone feel superior to the other person in addition to being right. It's a first step down the path that ends in political memes of the form "$OTHER_PARTY only believes in $BAD_IDEA because $INSULTING_BULLSHIT."

<comment><USER25> The problem is some of these debates have consequences that you would be forced to deal with (choice of language, framework, architecture etc.) and needless pedantry can be a huge blocker to adopting a better solution to the requirement at hand. At that point, either you can "exit" the debate and deal with the choices, or you can "exit" the situation in search of better co- workers. Both of them have real costs to you (which are not your doing).

I don't know what kind of life skills would help there. If you have any thoughts, I am all ears.

<comment><USER26> The kind of situation you describe happens... sometimes. Most of the time when you run into this kind of behavior, though, it's not in a situation with real consequences. It's somewhere like HN. (Have I seen this here? Yes. Have I _done_ it here? Let's just let that question pass, shall we?)

What do you do then? Call them on it, for the sake of the rest of the people in the discussion? Ignore it (don't feed the troll)? Call them on it once, then just walk away?

What do you do when _you_ are the one doing it, and someone calls you on it? Do you double down, or do you realize that you were being a pedantic jerk, and stop? Maybe even apologize?

And how do you tell where the line is between "valid nuance" and "pedantic irrelevance"?

There's plenty of room for life skills here. They may not help you in every instance of this kind of behavior, but they can help in many of them.

</comment></comment></comment><comment><USER27> I believe the difference here is between categorical and empirical thinking.

In each case the person replying is saying, "the _principle_ is violated by this counter-example, so the principle does not hold".

The author of this article _should be_ saying, "this isn't a principle, its a heuristic whose utility depends on context".

Ironically the author of this article misunderstands the point these replies are making and straw-mans them as much as he believes he's straw-manned.

They're not failing to capture relevance. They're taking a statement phrased categorically as a categorical principle, when it was an heuristic one.

This comes down to how people reason -- more mathematically-inclined people are often categorical thinkers; trying to reason in terms of universal principles & iterating on those until they are universal.

The goal of the person replying isn't (necessarily) to undermine the OP; but, to _helpfully_ offer a counter-example to evolve the principle until it holds.

It is a good strategy to arrive at general criteria for when, eg., GC is useful. In fact, this article is an exercise in that _because_ it replies to these counter-examples.

<comment><USER28> The author makes the point at the end that it's important to grasp the wider context.

The wider context is that people aren't expected to care so much about the specificity of their phrasing all the time.

The mathematically-minded would serve themselves better by ascertaining the category of the conversation and context at hand.

</comment></comment><comment><USER29> I've always assumed that somebody must have gone through classifying bugs like this in faulty debate (e.g. based on ancient Greek debating theory, or law, or logic as taught in philosophy?). By using well-defined terms to refer to the bugs, it would be way easier to call them out and mitigate them - as the amount of time wasted in FOSS collaboration with stuff like this is unbelievable.

Some egregious examples that spring to mind are:

* Trying to disprove a point by finding an edge case where it's not true - even if that edge case is entirely irrelevant (a bit like the complaints in the original post)

* Trying to disprove a point by exaggerating it to an extreme and saying that because it doesn't work in the extreme case, it must be false.

* Taking a point out of context and proudly proving it to be wrong... when taken out of its wider context.

* Making an entirely unrelated point which happens to be true, as a way of trying to prove an earlier point.

I guess the second one is a form of hyperbole (but is that the right term)? The third one could be called out as "taken out of context", and fourth is "irrelevant"... but it still feels like life could move on faster if there was a clearer taxonomy for these 'bugs'. (One could even provide the taxonomy as tags/reactions into your communication system of choice - like a more nuanced version of "+5 Insightful" or similar).

Edit: perhaps [https://en.wikipedia.org/wiki/List_of_fallacies](https://en.wikipedia.org/wiki/List_of_fallacies) is what i'm looking for, although it feels... cumbersome.

<comment><USER30> Yes, of course: "Fallacies".

But note there's also something I like to call the "Fallacy Fallacy": People read the wikipedia list and consider them some sort of universal natural law.

Case in Point: "appeal to authority". This can indeed be fallacious, within the context where these were formulated, which is probably academic publishing. If someone says they've created an HIV vaccine, it would be very wrong to start using it without clinical trials just because the inventor is some famous researcher.

If you try to apply the same to daily life and online debate, you're going to wither and die within a month.

Example: you're experiencing chest pain. What do you do? You see a doctor! Do you subject them to a quiz on heart disease, and do you re-run every trial that contributed to your treatment? Of course not -– it would cost trillions and take many lifetimes. Instead, you trust your countries certification scheme, and you trust the scientific establishment. Both are authorities.

When you return to your favourite restaurant, you are extrapolating expected future performance based on past experience. in other words: you trust them. Or in even otherer words: you consider them the authority on Fried Chicken and rely on that to guide your decisions.

There are only two ways to gain an understanding of the world around you as needed to do anything: direct experience, and what others tell you. The fraction of required knowledge that you can individually verify from first principle is probably somewhere below 1%. For everything else, you need to rely on other's direct experience, by continually fine-tuning individual measures of authority by comparing to direct experience where possible, and integrating with other sources where not.

<comment><USER31> Appeal to authority is not not deductively valid and thus it's logical fallacy.

On the other hand very little can be learned with deductive reasoning at once. Deductive chains in debate are very short and shortcuts must be used.

Authority can be used to weigh or prioritize evidence. If you are not doing serious research into the subject, authority is one heuristic that works extremely well.

For example, when two relatively ignorant layman debate in the internet and have limited interest or effort invested to get into the truth. Finding out that something is mainstream view among authorities in the field should end the argument for the time being for the lack of more information. Unfortunately the discussion usually ends with questioning that particular field, then the progress of the society as a whole. Scientists have been wrong before so .. they can also be corrupt ...

</comment></comment></comment><comment><USER32> Reminds me of one my all-time favorite bits of movie dialog, which I keep in my mental back pocket as a sort of reminder:

"Am I wrong? Am I wrong?"

"You're not wrong, Walter, you're just an _asshole._ "

</comment><comment><USER33> I think part of the problem is that school and college teach us to say "no" to something that's not always true. We're told a statement that's mostly true, and asked, "Is this true?" When we say yes, the professor says "No!" While a normal person, one with common sense, would say "Yes". This creates a habit of unnecessary attention to detail, nitpicking, and grasping at straws to come up with some reason why the other side is wrong.

<comment><USER31> Very true. Two very frequent argumentative errors in online comments are:

1) refuting argument with counterexample.

2) refuting causal argument with alternative cause.

Very few things in the world is universally true without exceptions or universal. Words _all_ or _everyone_ do not imply universal quantification (∀) in normal use of language.

<comment><USER34> Sorry, I can't resist being pedantic on a post about pedantry. The symbol you used translates loosely as "there exists an x"; I'm pretty sure you meant the upside-down A ("for all/every x")

<comment><USER35> Maybe the poster meant that the words don't imply ¬∃¬

</comment></comment></comment></comment><comment><USER36> I think there is a name to this: it's called dialectic/sophism. These arguers have no interest for the scope of the discussion, they just want to win the argument. I think it helps when you set the scope of the discussion clearly, at the beginning. edit: typo

<comment><USER37> "They just want to win the argument" is a good summary of what I understood from the article. There are people I regularly encounter who have to inject their opposition or correction to anything anyone else does or says, which feels like they are attempting to prove their superiority or correctness (but instead proving their failure to recognize the context of the original statement). Couching their point in the style "What about X?" instead of making a counter statement would be a more useful communication method IMO. (Edited to fix grammar)

</comment></comment><comment><USER38> From the article:

"The one thing that school trains you for is that being right is what matters. If you get the answers right in your test, then you get a good grade. Get them wrong and you don't. Maybe this frame of mind "sticks on" once you leave school, especially given that most people who post these kinds of comments seem to be from the "smarter" end of the spectrum (personal opinion, not based on any actual research). "

A similar sentiment by Paul Graham here: [http://www.paulgraham.com/lesson.html](http://www.paulgraham.com/lesson.html)

<comment><USER39> This is true, but as a counterpoint, most math and science exams in high school give you partial credit for trying to reason through the problem even if the final answer is wrong. I had one physics teacher who would sometimes give full credit even if the final answer was wrong due to an arithmetic error. She was awesome; I still think of her as an inspiring figure.

</comment></comment><comment><USER40> It appears that [https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good](https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good) is a very relevant concept here, and is the principle behind the rebuttals to the arguments in each section.

I feel that arguing for perfection is (arguably) part of a broader problem with internet discussion - and discussion in general. I've personally termed it "sniping" but there may be an existing agreed-upon term.

Essentially, this is when a commenter takes one flaw or issue in a larger and reasonably sound argument - and runs with it. In context, focusing on this flaw is "missing the point" as the rest of the argument does not rest on the assertion being "sniped". But - if you make enough noise about it - you may be able to confuse people into thinking otherwise, and making the argument seem fundamentally flawed.

<comment><USER41> I love snipers too.

I have some broad idea about a topic I am not experienced. I expose it and I have immediately 25 different objections.

I examine the objections and there are 5 really good I had never thought about.

That is amazing, the fastest feedback loop in the world. The only problem is getting affected by the feelings people expose when they reply. But with text is easy.

I do that on real life with Masterminds. You have to train people to be respectful with other people's ideas(they are not naturally). If you do, it is one of the most powerful tools in the world.

</comment></comment><comment><USER42> The Recurse Center (formerly Hacker School) has among their social rules one that discourages "Well-Actually's". Quite pleasant.

> A well-actually happens when someone says something that's almost - but not > entirely - correct, and you say, "well, actually…" and then give a minor > correction. This is especially annoying when the correction has no bearing > on the actual conversation. This doesn't mean the Recurse Center isn't about > truth-seeking or that we don't care about being precise. Almost all well- > actually's in our experience are about grandstanding, not truth-seeking. > (Thanks to Miguel de Icaza for originally coining the term "well-actually.")

[https://www.recurse.com/manual](https://www.recurse.com/manual)

</comment><comment><USER30> Interestingly, this particular flaw in reasoning (dare I say "fallacy"?) is far more prevalent in the the tech community. Being guided by Vulcan-like logic applied to completely neutral facts isn't just considered ideal but even achievable. Emotions, OTOH, are considered a weakness, as are any product considerations that cannot be expressed in SI units. Design/UI/UX are confused with "making it look pretty" in the same way that what's considered art is usually interior decorating and any actual art is considered pointless at best and another postmodern abomination at worst.

So it's no wonder that they'll frequently believe "I found this one remote outlier" to be a valid refutation of some argument. Because, in principle, it is: If you don't caveat for black sheep, Taleb is going to smack you over the head. And if you list black sheep, I'll spray-paint a sheep red and consider myself extremely smart. Soon, we'll have names for 16.7 million colours so you'll be on the losing side of this argument forever.

The "liberal arts" have their own weaknesses. Engineering can put a man on the moon or a nuclear bomb on Japanese soil and it's pretty well obvious that someone got done with their todo list this week. That other culture doesn't lack in achievements of similar magnitude, such as the rule of law or democracy. But these are hard to measure, are achieved gradually. It's near impossible to assign individual credit and therefore harder to implement a meritocracy.

Yet because they continually live in this sort of murky dialectic discourse, the humanities are far more comfortable with complexity. The tech community even more than the natural sciences has a fundamental problem with getting even close to considering the best possible opposing argument. Considering how great their believe in both the power of "rationality" and their ability to use it is, it's not even funny to see how lawyers, for example, tend to wipe the floor with them. Witness any discussion of law here or among tech-twitter, where dozens of ideas will crop up how to outsmart the law by being "clever" and owning a dictionary ("the contract said "Dollars", but didn't specify USD. I'll just pay in CAD")

</comment><comment><USER43> I recently received an email from my father with a link to a shady article about COVID-19. It was fairly long and contained lots of extremely technical medical facts. The article was difficult to immediately disprove, because it contained so much factual, yet irrelevant information.

I was able to explain to my dad why it was logically flawed, but it was impossible to convince the author that their article should be retracted. When I identified the source of the author's factual medical information, it was clear they had simply omitted the opening statements from a research paper that established the hypothesis was likely not applicable to the problem at hand. When I found the researcher, they were in the awkward position of defending their research from people attacking the factual parts of the derived article.

</comment><comment><USER44> I think I'm a great programmer because I know the difference between 100% correct and 99% correct, and refuse to call something 100% correct when it's not.

I think I'm a great _senior developer_ because I know when to compromise.

Notice that I can do both of those things at once without conflict. It's important to understand potential problems with a solution, as well as problems with alternative solutions, and pick one that seems the best at the time.

Many people on the internet are unable to do one or the other, and also feel the need to weigh in on a conversation for their own needs.

But not everyone weighing in is wrong. When someone says "You should always X", you will inevitably get someone saying that's false because it _is_ false, and it's important to understand when to break the rules.

</comment><comment><USER45> Neither statement have an agreed "context" from which the discussion is taking place, and flipping the statements may make the other seem irrelevant.

<comment><USER46> Not sure if you were serious or not but your comment seems like a nice example of what the article talks about

<comment><USER47> I don't think he's agreeing or disagreeing with the article, just providing a possible explanation for this behaviour. The two people arguing are ignoring the context, which is common in many debates. Especially with politicians - shift the context a bit and you're right even if what you're saying is unrelated to the original point.

<comment><USER48> The article chose pretty good examples, they are all of the form, "generally true statement" with a "specific, or even completely unrealistic, edge case disagreement". They all require no context to understand the exchange.

Debates, especially political debates, are purely about winning the debate. Context in a debate is particularly irrelevant.

<comment><USER49> I'm not sure I agree with "edge case disagreement". TLS, for example, has shown it's limits (e.g. CA hijacking) and was improved (e.g. CT). However, someone had to find those edge cases and discover the limitations of stated assertions: "2010 TLS was safe under the assumption that the CAs are not hijacked."

<comment><USER48> Ok. So, are you saying that we should stop using HTTPS and instead use HTTP? If you are not, what is your point? Is it not under the 100% correct but missing the point label this article is talking about?

<comment><USER49> Well, you could use HTTP over an IPSec tunnel with a pre-shared key (obviously distributed face-to-face), and that would have been resistant to a CA being hijacked.

However, nowadays, I believe with CT HTTPS is really safe. But again, someone had to nitpick on the security limitations of HTTPS for CT to be invented.

</comment></comment></comment></comment></comment></comment></comment><comment><USER50> What the author is saying sadly also applies to his own arguments.

And this is even worse:

"Dangling reference out of memory errors are rare (maybe 1 in 10 programs?) whereas regular memory bugs like use-after-free, double free, off by one errors, etc are very common (100-1000 in every program)."

In my opinion, this is a weak statement, it does not match my experience at all, and I've been programming at a professional level for about twenty years.

<comment><USER51> How have you seen dangling reference OOM situations in the real world?

Speaking for a python / Django stack, there's a very concrete reason that these are rarely seen in my experience. Code never lives long enough for it to matter. In any practical situation, workers are recycled at a furious rate. uWSGI will recycle a worker for many reasons, or for no reason at all.

There are plenty of apps out there where, if you changed the settings to make the processes fairly persistent, they would OOM on a regular basic. This might be the vast majority of Django apps out there.

But that's just it - no long trusts python enough to keep it running in the background forever. So OOM like this is a non-issue.

<comment><USER52> When code lives long enough. If your process is short living, you don't need any form of memory management at all, just allocate and terminate the process when done.

</comment></comment></comment><comment><USER53> It is more immaturity than education, though. Age makes most people appreciate diversity and act collaboratively, instead of antagonising.

<comment><USER54> I think you picked up some downvotes for saying it's age, rather than experience, that gets people to appreciate diversity and act collaboratively.

I hope that the irony of that (and my own comment), in regards to this article, is not lost on those who downvoted you.

</comment></comment><comment><USER55> Thanks for this, it seems a lot of discussions miss the point.

"You can achieve the exact same thing in C, you just have to be careful."

Of course you can. You can also drive at 160km/h safely or use an axe to chop onions in your kitchen "you just need to be careful" (with the subtle implication of "I can be careful, can you?". Narrator: no, you can't, you aren't as careful as you think)

And the other favourite of mine "HTTPS self-signed certs are useless, you're not authenticating the origin" while forgetting about the whole encryption thing. Yeah.

<comment><USER56> >> "HTTPS self-signed certs are useless, you're not authenticating the origin" while forgetting about the whole encryption thing.

The problem is that not validating the origin can make you vulnerable to a MitM attack. If the attacker can place themselves between you and the server, the attacker could intercept the real certificate from the origin server (containing the real public key) and then instead of forwarding you the origin server's certificate, the attacker could forward their own malicious certificate to you (containing the attacker's own public key) but pretending to be the origin server. Because the attacker's certificate would be self- signed, the browser cannot automatically authenticate that the certificate and public key provided actually belong to the (also self-signed) origin server and not some random attacker.

Then when the encryption begins, there will be encryption (that's true) but the encryption will happen between you and the attacker's machine and this is why it defeats the point.

<comment><USER55> It does not defeat the point if your attack vector is closer to your connection than closer to your server (e.g. untrusted connection). And in this case you can be your own CA and verify your own certificate.

It does not defeat the point because your regular HTTP server can be MitM in the same way so not having self-signed HTTPS because of that is moot.

So again, you're missing the point.

<comment><USER56> >> And in this case you can be your own CA and verify your own certificate

If you want encryption for yourself only when accessing your own website, sure you can add yourself as a CA in your own browser and then you also get he benefit of authentication... That is a very niche use case though; not a typical/general use case. Also where the attacker is located doesn't matter. If your browser doesn't have the origin server's CA added in its certificate list then the attack can also be done in close proximity to your machine (e.g. WiFi endpoint). So while not always incorrect, your argument is generally incorrect.

>> It does not defeat the point because your regular HTTP server can be MitM in the same way so not having self-signed HTTPS because of that is moot.

For a typical use case, you add almost no security by having a self-signed certificate compared to using plain HTTP. The only difference between an attacker who is able to carry out a MitM attack over HTTP vs an attacker who can do the same attack over self-signed HTTPS is a few additional lines of code in the attacker's software to proxy the fake certs; basically they can break it just as easily just by having better software. It doesn't matter at all where the attacker is located; whether closer to the server (like an employee of an ISP) or the user's machine (like near a WiFi endpoint).

</comment></comment></comment></comment><comment><USER52> The second statement isn't 100% correct because it's not 100% precise. Truth doesn't extend beyond precision. This is actually taught in school in physics classes when your answer is treated as entirely incorrect if it doesn't contain error estimation.

</comment><comment><USER57> There are two ways we can interpret these examples [0]. The first way is to interpret them as two propositions understood in the general context. I believe this is the interpretation that the author had intended. In this case, the objection is just crappy because it fallaciously attempts to refute "usually p" with "occasionally not-p". It is a failure to reason correctly.

So what's the cause of the fallacious inference? Well, in this particular post, the author chooses to focus on the case where the objector fails to appreciate (either though inability or through malice) the general context in which the original statement is being made. If I were to offer a diagnosis for what the author is aiming at, it is a lack of prudence [1]. Prudence, of course, presupposes humility [2] which some of you have mentioned.

[0] The second way is to understand that these examples in a specialized context that hasn't been articulated. Take the Python example. Let's say we've been given an excerpt from a conversation that had taken place at a company that specializes in embedded microcontrollers. A charitable reading would actually lend credence to the objection.

[1] Prudence in the classical sense as cardinal virtue, not its modern corruption.

[2] Humility also in the classical sense, not as some corruption of modesty or lowliness.

</comment><comment><USER58> This is genuinely one of the best posts I have ever read on here. Completely correct, very direct.

> In the real world being right is not a merit by itself

A lesson a lot of programmers could learn.

</comment><comment><USER59> This reminds me of a Rate My Professor hall of fame nomination I read years back. I've forgotten the phrasing so the below is heavily editorialized except the punchline:

> <Professor> could present everything there is to know about convection, > thermal transfer through metals, phase changes in liquids, and at the end of > the day you would still have absolutely no idea how to boil a pot of water.

</comment><comment><USER60> In the spirit of dialectic (thesis/antithesis/synthesis) it is precisely context which determines the "truth", "relevance" and "correctness" of any claim - to assume it a-priori is a framing tactic.

The premise "Garbage collectors are nice and save a lot of work." is true precisely for the set of problem-domains (read: contexts) for which GC is the solution. Outside of those problem-domains, "GC is not always nice and can create a whole lot of work." is also a true statement.

If you are arguing for any one of those two view-points without acknowledging the validity of the opposing view, then that tells us way more about your problem-domain than it does about the utility of GC.

When you are using a ruler to measure a table, you are also using the table to measure the ruler...

<comment><USER61> > If you are arguing for any one of those two view-points without > acknowledging the validity of the opposing view, then that tells us way more > about your problem-domain than it does about the utility of GC.

Your argument sort of reminds me of the "no free lunch" theorem in optimization: _" any two optimization algorithms are equivalent when their performance is averaged across all possible problems"._

It's true, but it's largely irrelevant. Not all problem domains are created equal: some are commonplace, some are obscure, and some are so convoluted as to be completely inapplicable in the real world.

I think a constructive rule of argument would be to state upfront when you happen to be standing in the "obscure" or "completely artificial" camps.

<comment><USER60> I am standing in the camp of my own actual problem-domain.

The "obscurity" and "artificiality" of which is largely irrelevant to me having to tackle it.

If you are arguing a view-point outside of _your own_ problem domain, then perhaps you should be upfront about holding a theoretical/academic view?

<comment><USER61> I assume you're back to garbage collection rather than dialectic. The key phrase I'd take away from your post is " _to me_ ".

<comment><USER60> I was addressing this point:

> I think a constructive rule of argument would be to state upfront when you > happen to be standing in the "obscure" or "completely artificial" camps.

Obviously it is "to me". On whose behalf do you speak?

<comment><USER61> I think you're assuming too much good faith on the part of the person making the argument. Sometimes people do find themselves legitimately standing in the 'obscure' camp (or even, say in academia, the 'completely artificial' camp). But it's often the case that a debator adopts a stance in one of those camps, without acknowledging where they're standing.

Sometimes it happens because of pedantry and sometimes because of incompetence, but it happens all too often.

<comment><USER60> All the same - "obscurity" is determined by context.

If you happen to be in the "obscure camp" (without knowing it) in which GC is a problem, not a solution - it sucks for you having listened to the OP.

</comment></comment></comment></comment></comment></comment></comment><comment><USER62> Yes, this is the ego. It's not about the information or the knowledge, but about being right and your opinion.

I'm sure we're all guilty of this sometimes, but it still makes comment sections a bit useless sometimes, because it's not discussing the subject itself.

This is why I love upcoming new technologies that everybody hates, they still have to proof themselves by using rational logic and there isn't much arrogance/ego surround it yet.

It's not good to think too much about yourself and how things reflect to groups of people and yourself, a lot of projection.

Anyway, iPhone rules! Android sucks. Happy Easter.

PS: I teach languages and a lot of people get stuck with looking bad. The ego is your enemy. Most good language learners just practice a lot and don't worry too much about looking bad.

</comment><comment><USER63> When I see people do this, I just think of the scene from the big Lebowski:

Walter Sobchak: Am I wrong? (Belligerently arguing a bowling rules infraction at league night)

The Dude: No you're not wrong.

Walter Sobchak: Am I wrong?

The Dude: You're not wrong Walter. You're just an asshole.

Walter Sobchak: All right then.

</comment><comment><USER64> I really felt this article.

Even when you take the time to outline the context, people still are eager to point out that extremely unlikely but possible situation where your statement may be false.

And then 99% of the meeting is debating how their objection is irrelevant.

So infuriating.

</comment><comment><USER65> Well, that happens for some of the comments, but not for all of the comments. You just have to write your comments well. If we just all wrote our comments well it would show the author how his post is pointless /s

</comment><comment><USER66> Being correct is really important sometimes. The blog's last example really hit home to me. For my last job I had to process six million records a minute on a shitty embedded CPU and Python (normally my go-to) completely barfed when I got to the domain-specific logic.

While pedants on the Internet can be frustrating, we shouldn't generalise when there are many situations where we should be both precise and relevant. HN encourages curious discussion and I think that's an apt description of the discourse that I enjoy most here. Precision can generate curious conversation.

</comment><comment><USER67> Pedantic point: a dangling reference is the same thing as a premature free. If we free(p) but then the pointer hangs around in the program and we use it, we have used a dangling pointer.

What this seems to be talking about is "semantic memory leaks": objects that are not reclaimed because they are reachable, and this reachability is unintentional.

For instance, suppose we process a stream of real time data which exhibits locality. Some items appear in it and are likely to appear again, but eventually disappear forever. We can put items into a cache to speed up processing. But if we don't expire the cache, it could grow without bound; the items that will never be seen persist in it, and new items keep being added.

That's a bug in the algorithm, not in the memory management. Memory management has nothing to say here; it has no idea about the parameters that drive the cache size or replacement policy.

Implementing cache expiry in this scenario has little or nothing to do with manual memory management. Manual memory management cannot just blow away any object it feels like based on it age or recency of access.

</comment><comment><USER56> The article alludes to an interesting insight that developers tend to quickly disregard messy reality in favor of idealized theory. Developers are particularly bad when the argument necessarily involves aspects of human psychology.

There is a very big difference between what SHOULD happen in theory and what WILL happen in practice - Arguments related to human psychology should never be discarded outright.

Saying that a particular tool is not suitable because the tool is too complex and there are too many junior developers in the company can be a very strong argument.

Or saying that a tool adds complexity to the project and that this adds unknown unknowns which adds risk is also a strong argument.

Or a common one I use when discussing statically typed languages is that it's incorrect to assume that people will use types correctly; statically typed languages prevent developers from mixing invalid types based on their definitions but it doesn't stop developers from using the wrong type definitions (wrong abstractions) to begin with!

</comment><comment><USER68> I think the real issues is communicating the correct point in a diplomatic way that wins people over. Lots of people might be making decisions on a feeling rather than a precise facts. This article reaches a bit too broadly from specific examples. There are lots of counter examples where you neeed to be correct, eg corona response, airplane design etc.

</comment><comment><USER69> I personally don't find some of these examples problematic at all. A discussion doesn't have to be so directed (relevant in a defined context) to be useful or interesting.

The first example might just end right there with no further discussion if the context is not expanded.

Discussions are beautiful like that, they start somewhere and can end up at a completely different place.

</comment><comment><USER70> People are naturally competitive and often antagonistic. But what are those discussions really about? In order to decide on a suitable programming language for a project, more methodic approaches are useful, like a list of requirements with ratings for each candidate. Debates usually just let the more stubborn and irrational participant win.

</comment><comment><USER71> I was somewhat disappointed to find a 2020 time stamp on this article. It could've been written pretty much word for word 20 years ago, and it still would've been reshashing mostly resolved arguments. To be clear, I think the problem is with the people still making the tired arguments, not this article.

</comment><comment><USER22> A discussion with started with the first statement and response, and then went on with the statements they listed under "ignores all the larger context of the issue" looks pretty decent to me.

It might turn out that the second person thinks one or more of the bullet points is false, and both sides might learn something.

<comment><USER49> I agree! I love playing devil's advocate. People tend to focus too much on "who is right" and get annoyed. For me, it's about learning. It's about challenging my and my peer's assumptions and finding what are the limits of the assertion.

The article is a good invitation to reflection, but an alternative title could be "let's discover the relevant context together".

<comment><USER72> It is much easier to play devils advocate then having opinion you advocate for. And it is overly easy to use devil advocate tactic to make it hard to keep original topic, to force people to go to lengthy tangents or otherwise prevent them to actually make the statement they were aiming for.

If I intend to discuss complex enough real world problem in good faith, especially one with unclear parameters, devils advocate basically makes it impossible.

<comment><USER49> I agree, but I would put it differently. It is a lot easier to advocate a conclusion with full control over the assumptions, than discovering the boundary assumptions where the opinion no longer holds.

For example, it is easy to argue for "HTTPS is more secure than HTTP". But what I am often interested in -- as a curious and skilled IT person, and not a lambda user -- is what attack models does HTTPS defend against. Remove assumptions one by one, when does HTTPS offer equivalent security to HTTP.

This is not just nitpicking, but extremely relevant for our profession. TLS has gotten under quite a lot of fire lately, so sooner or later, someone somewhere will discover those hidden assumption. I rather it happens on a public forum.

</comment></comment></comment></comment><comment><USER73> Reading this part about garbage collection:

 _Being able create things on a whim and just drop them to the floor makes programmers a lot more productive than forcing them to micromanage the complete life cycle of every single resource._

I realized... It would be REALLY nice to have a garbage collector for the physical things in my house. Even some sort of tried-and-true algorithm to direct me would be nice.

EDIT: (this actually started as a sincere though off-topic comment on my part)

I have observed during this "shelter in place" that one way to be organized around the house is to be around the house (in this case 24/7).

And now I have 3 algorithms to think on. I think it might be nice to be nagged periodically with a certain request from a certain direction. Part scheduled cleaning, part LRU, part where does that live, etc.

<comment><USER74> It is possible! Unlike in the programming world, true parallel garbage collection has been mastered for centuries in the physical world. However, there is of course no free lunch. You have to pay people to come over and clean your house.

Failing that, you can "write your own" by simply allocating a block of time every day to cleaning up. Doesn't get more "tried-and-true algorithm" than that.

<comment><USER75> Imagine though (all we can do in the current situation) that the garbage collector comes in at seemingly randomnpoints during the day and just as you're about to use the restroom goes in and locks the door behind them to clean the restroom.

<comment><USER73> At first I thought you were talking about your mom/spouse but then I realized it's a computer analogy :)

</comment></comment></comment></comment><comment><USER76> This reminds me of times I've left thorough comments on HN, only to have a single point of it debated. As if picking at that single point defeats all others. Seems to happen a lot to others I've noticed. I wonder if this has a name...

</comment><comment><USER77> I find posts like this to miss the point of one of the most important aspects of coding - that of technical leadership. It is the role of whoever is providing technical leadership to drive to clarity among all the participants in the conversation. This is not easy as the logic put forth by both sides is often slightly misaligned - hence this and many other like it.

If nobody takes responsibility for making sure this alignment is achieved, yeah, you'll get lots of 'missing the points.'

Sometimes this is called 'management,' and if you get really good at it you can even make it to 'upper management...'

</comment><comment><USER78> The article falls into the same error of misrepresenting opposing views.

<comment><USER48> Explain? To my mind, the article explains a problem, that two opposing views can both be technically correct, but one view is often useful and second, disagreeing opinion, is just contrary.

Your comment seems to fall into the second category: just contrary disagreement.

<comment><USER78> _Explain? To my mind, the article explains a problem..._

The article _seems_ to explain a problem, but what it's really doing is expressing some opinions, misrepresenting opposed opinions as strawmen and going meta to further attack them.

The criticism of the contrary opinions is not wrong, it's technically correct, just misses completely the point since it doesn't respond to the strongest version of the objections, just to the weakest ones.

<comment><USER48> These are not straw man arguments. I have actually dealt with all three of these examples in my career. The python one is particularly relevant to me, but I've had push back on running our API over HTTPS "because if they want to hack you they will anyway so why pay the extra cost".

<comment><USER78> Not three, four. No idea about Python text, I don't know what the https fuss is about either. But the other two things are not how I've seen them discussed, and I've seen them many times.

I'm in favor of GCs and guards. What I'm against is that some languages removed the _option_ to manage memory manually when it makes sense and disabling guards once the code is debugged. Those were the terms and, in that context, the objections make sense: there are cases when it's important to know in advance that the GC'd won't get in the way.

Java was the start of all that crap, with all sort of restrictions: every function must be a method, you can't precompile, no pointers, everything GC'd...

</comment></comment></comment></comment></comment><comment><USER31> >This is sadly common on Internet debates

Internet debates can be really good in very small, focused or closed forums where people have time to learn each other over time. Some mailing lists and tiny groups are phenomenal.

Debates that happen between strangers in a single point of time don't have the minimum requirements for a good debate. Without shared context, history and commitment to the debate it's hard to get any results even among people who try hard.

</comment><comment><USER79> The thing with the "correct" example posts listed is that they're not completely right. Stating an opinion, and then a fact right after only makes them partially factual and will always open room for more debate. "Python is trash, it can't handle the processing of big files like other languages can" isn't actually proving the _opinion_ that Python is trash

</comment><comment><USER80> Yes, sometimes it is simply a matter of scope. If you exclude or minimize some factors you will rightfully come to a different conclusion. So you most certainly have to agree on which factors are relevant and to which extent. Otherwise, every participant of a discussion might find a local optimum, where he (rightfully) thinks that his viewpoint makes sense.

</comment><comment><USER81> Maybe it's just me, but it seems that all the problems cited in the article are too much people with only a hammer seeing only nails

</comment><comment><USER82> Are there any synonyms or similar terminology for this type of behavior? I generally know it as "talking past each other".

[https://en.wikipedia.org/wiki/Talking_past_each_other](https://en.wikipedia.org/wiki/Talking_past_each_other)

</comment><comment><USER83> The article focuses on an issue that is very widespread on technical forums, and one that I find irritating. (It is a bit better here thanks to the good moderation, but you can still find examples among the comments for almost every article.)

To be specific, I mean comments a) that point out a flaw in an argument, often on narrow technical grounds, b) where a charitable reading of the original argument indicates that the writer would very likely have been aware of this flaw, c) that do not provide a revised version that _would_ be correct.

To me, such comments come off as dismissive - even insulting -, and because of this they almost never result in a good discussion.

Most often, such comments are also facile: It is easy to point out facts that hold in edge cases, but in software, as in every engineering discipline, any real world decision involves trade-offs. And as a practitioner, I find it very useful to learn how others have made trade offs on real world problems, exactly because edge cases are often not informative. Whoever comes forward to discuss their solution on such problems deserves praise, because they know that their decision is necessarily not perfect, and can be criticized. A good critique then amends the original statement to provide a better solution instead of dismissing it because it is not universally applicable.

This is not about pedantism (which is itself a highly subjective insult that never does any good) - a good comment on a minor point can be enlightening with the right context, and when respecting the original context.

I do not think this kind of destructive behavior is currently well covered by the HN guidelines, so here is a proposal of what I would add (@dang)

"If you want to point out an incorrectness in a statement, do not assume whoever made the statement was not aware of it - this often comes off as dismissive. Instead, attempt to provide a synthesis of the original statement and your criticism that would be correct from your point of view."

Using this guideline, here is how I would rephrase the examples from the article: \- "Garbage collectors work in many cases, but I have spent many hours dealing with dangling memory reference issues, so in this and that case I recommend instead..." \- "Note that TLS does not provide sufficient protection against nation state adversaries because... If you have to deal with this threat scenario, I recommend ..." \- "In performance critical scenarios, you can avoid paying the cost of bounds checking as long as you..."

</comment><comment><USER84> On HN you can click [-] to simply hide any statement that's beside the point ;)

</comment><comment><USER85> Anyone knows a non-technical version which conveys the same point as this article?

</comment><comment><USER86> To the https one... If the NSA stealing your server is a legitimate business risk, I suggest launching your secured server into space, they'll have a hard time sneaking onto your satellite without anyone noticing.

<comment><USER26> They'll have an easier time sneaking onto your satellite than you will sending out field service.

;-)

</comment></comment><comment><USER87> Something on the periphery of this article's theses on pedantry, that comes to mind, is the notion that everything anyone states has to cite some peer- reviewed paper that is published in a prestigious journal; otherwise it's useless.

"Source?" "Citation?" "Papers, please?"

Nobody is allowed to think aloud, lest they risk spreading disinformation, despite the utter and complete failure of occidental peer review systems (80% non-reproducible rate, etc.).

IMHO, this pedantic behavior also creates a Royal Society-esque gatekeeping environment that is hostile to individual a posteriori contributions, relegating them to "anecdata" status at best. That environment turns out to be also hostile to a priori knowledge creation in general.

</comment><comment><USER88> The statements the article object to look like informal fallacies: hasty generalization, straw man, availability bias.

</comment><comment><USER89> the conclusion of the post get's at vervake's idea of relevance as the basis of cognition:

[https://ieeexplore.ieee.org/abstract/document/8132809/](https://ieeexplore.ieee.org/abstract/document/8132809/)

</comment><comment><USER90> "You're not wrong, Walter, you're just an asshole."

</comment><comment><USER91> This blog post is 100% wrong. It's not about GC vs non-GC in today's universe where we have Rust that solves all these problems and more!

</comment><comment><USER92> Ah this reminds me of a fellow at work. He's always correct, and the worst type of correct: technically correct.

</comment><comment><USER6> Cool blog post. Let's go build some stuff.

</comment><comment><USER93> What is the point of this blog post? It appears to be about arguments in the Internet in general, but its implied point seems to be a rant against low- level programming.

<comment><USER94> Its arguments are perfectly correct, however it exposes the state of mind that has lead us to javascript "apps" eating gigabytes of ram because they instantiate Chrome 3 times.

Yep, there's a price to pay when you're afraid of low level programming. Sadly you make us all pay that price.

<comment> yoz-y That's quite a slippery slope though, from garbage collection straight to 3 instances of chrome.

</comment></comment></comment><comment><USER95> Must be more than one kind of programmer.

With a little discipline, the "100-1000" memory issues in 'every program' is a vast exaggeration. I write programs routinely with 0 memory issues. Just match every allocation with a deallocation, in the same module. Be responsible. As a habit, it pretty much cures the problem. In certain programming paradigms where its possible.

So, the author and I inhabit different programming paradigms. I knew that already. Because they rely on a GC and don't mind its weighty issues, I could guess what space they are in.

<comment><USER95> Yes I already know there exist folks who depend on GC utterly, never giving a thought to important issues of scalability or speed. They write all that laggy unperformant code requiring some huge programming paradigm so they can 'scale' to 100 nodes. Because their code only supports 10-20 clients per mighty processor. Instead of the 1000-10000 that straight code could eke out of a single machine.

What does my son spend his time with, at the average silicon valley startup? (He's been at half a dozen). Chasing down issue in the hodge-podge pile of mismatched services that somebody threw at their solution, than actually understanding their problem.

<comment><USER96> These two comments are a great example of statements that are (probably) correct but miss the point entirely. Thanks!

<comment><USER95> Maybe the title? But not the point of the article, which was basically a rant against an imaginary 'fool' that the author tried pinioning with their mighty intellect and specious arguments. Which were largely the same arguments (pedantic, true, missing the point) being 'lampooned'.

<comment><USER96> Your summary of the article is not consistent with its content.

<comment><USER95> Wow we read different articles.

The exaggerations, name-calling and chest-beating were the only common thread?</comment></comment></comment></comment></comment></comment>


Inside a Netflix Warehouse - <AUTHOR> http://www.chicagotribune.com/entertainment/chi-0804-netflixaug04,0,6424990.story

<comment><USER2> Netflix has deployed the largest "legacy adapter layer" business process that I can recall. This is a great example of how to start a business where the end-state model is dependent on things outside of its scope of control (or even influence).

When Netflix started in 1997, Most of its potential customers were using dial- up, and there was no way Hollywood would have allowed digital distribution anyway. So, they rode on top of some existing infrastructure: (1) the US mail system, and (2) existing laws that allowed physical media movie rentals.

My wife and I have been Netflix subscribers for years. However, most of our viewing is now done via the little Roku box, and physical disk delivery is of a much secondary importance (their streaming media is better than DVD but not as good as Blu-Ray).

Netflix is in this fantastic position of having a large customer base that can shift from its relatively high marginal cost* business model to its new, much lower marginal cost* * one.

* postage and manual labor.

* * I presume the movie studios are getting paid per-view?

<comment><USER3> About marginal cost, it's not obvious to me that postage both ways plus sorting is more expensive than bandwidth plus royalties. Given that postage gets more expensive and bandwidth gets cheaper, streaming should be cheaper at some point if it isn't already.

<comment><USER2> > bandwidth plus royalties

I think I've read that Netflix has an agreement with the studios where they pay per shipment rather than per DVD. So, having 1000 of a new DVD on hand costs little more than having only a few. The studios like it because it aligns Netflix's cost structure with their own (basically fixed), so agency costs are minimized.

I'm sure that Netflix pays less for bandwidth than Amazon sells theirs for. So, we can presume streaming a two gig movie (probably much less in reality) would cost much less than 30 cents -- postage one way for a DVD. Add in a few more cents for data center, etc. and they're still better off relative to postage.

<comment><USER2> According to Mark Cuban, I am very wrong:

[http://blogmaverick.com/2009/08/05/the-ultimate-movie- parado...](http://blogmaverick.com/2009/08/05/the-ultimate-movie-paradox- redbox-vs-downloads/)

</comment></comment></comment></comment><comment><USER4> The genius of their system is that most titles never ever get re-shelved because the software is smart enough to do the match-making.

""It's a lot faster than a traditional shelving system where you have to run around and marry up orders," says O'Handley. Dennys Torres, one of four original operators when the hub opened, in January 2002, can clock more than 800 discs per hour. The Scan Tomorrows move faster, set aside by the handful. Ship Discs get an envelope and a pair of stickers. "When we first started last year," says Torres, "moving 4 boxes was a lot." He indicates sets of long, narrow boxes filled with DVDs, some 320 discs in each. "We were taking long breaks, two-hour lunches. Now, it's all work; everybody moves at least 10 boxes a day."

From "90,000 DVDs. No Shelves." <http://www.fastcompany.com/magazine/74/netflix.html>

History of the Netflix Mailers: 1999 to 2005 (present version)

[http://money.cnn.com/popups/2006/biz2/netflix/frameset.exclu...](http://money.cnn.com/popups/2006/biz2/netflix/frameset.exclude.html)

</comment><comment><USER5> Their Philadelphia-area distribution center, where I get my Netflix DVDs from, is located in a place called "Southeastern, PA".

This place does not actually exist. That is, there's no city or town called "Southeastern". It's just a name for the particular post office they use.

</comment><comment><USER6> _The second thing I noticed was how, for a Web-based business, there were few computers -- maybe seven in the building,_

Don't let that mislead you. Make no mistake about it, this is a highly automated business with a lot of thought, design, analysis, and most likely, very tightly-targeted software.

With all the talk here at hn about cool stuff like algorithms, scaling, UI design, CPM, etc., etc., etc., I still spend over 50% of my time helping customers move shit from Point A to Point B. That's it.

It may sound old school and boring, but it's anything but. When you're doing so much volume, every little thing matters. And lots of those little things can be dramtically affected by good systems. Here's where you _have_ to get good or die trying. When the smallest mistake turns a 50 cent profit into a $100 loss, your systems must be on the razor's edge.

I bet the routing and error detection software in these warehouses is very sophisticated and handles outlying cases most people would never think of. Perhaps some journalist will take us on that trip with the next article :-)

<comment><USER7> Fat chance they'd let a programmer or systems designer anywhere near that place with a reporter :)

</comment></comment><comment><USER8> "Its biggest secret remains the warehouses themselves -- for two reasons. No. 1, each holds several million DVDs, not to mention expensive mail-sorting gizmos and dry-board posted statistics on how many discs were recently returned damaged, placed in the wrong sleeve or scratched. And No. 2, Netflix has grown leery of what happens when customers learn the location of a warehouse -- they drop off DVDs at the door."

This seems in-genuine for multiple reasons:

1\. Other articles I've read on the Netflix Inventory Control system indicate that there are almost _no_ DVDs in the warehouses, the vast majority are either at customers, or in shipment. So the "Several Million DVDs" is an unlikely claim.

2\. Expensive mail sorting gizmos? So? Are they afraid of theft? "Mail Sorting Gizmos" neither lends themselves to easy snatch and grabs, transport, nor resale.

3\. Dry-Boarded Stats on scratches, damaged, wrong sleeve. Doesn't sound like competitively useful information to me, particularly after data like # of Sleeves per hour (650-900) per employee, and interval of exercise (every 65 minutes) has been made public.

4\. Drop Off DVDs at the door - This is a bad thing, why?

Nope, My guess is that NetFlix is trying to delay the inevitable, which is unionization of their workforce by trying to keep the location of their shops confidential and avoid organized labor leaders paying their sorters/packers a visit...

<comment><USER9> Warehouse with million * untraceable, easily sold, small items worth $10 each. Security costs = $$$.

</comment></comment><comment><USER10> I loved this recent slideshow on Netflix culture: <http://www.slideshare.net/reed2001/culture-1798664>

<comment><USER11> Also see the HN comments here <http://news.ycombinator.com/item?id=740524>

</comment></comment><comment><USER12> Video of a Netflix hub:

<http://www.youtube.com/watch?v=CWA0LKfEv3c>

<comment><USER13> Weird. In this video they have people hand stuffing envelopes but in the original article they have a machine stuffer. I wonder, is the video just outdated?

</comment></comment><comment><USER14> Am I reading this right? It seems to say that every day, every disc that's currently is in stock is processed so that any that need to sent to customers can be pulled out for delivery. And my intuition tells me that would be crazy.

"Then discs are scanned a second time -- if a title is requested, and around 95 percent of titles get rented at least once every 90 days, the machine separates it and sorts it out by ZIP code. (The entire inventory of the building is run through this daily, a process that alerts other warehouses of the location of every one of the 89 million discs owned by Netflix.)"

<comment><USER15> I think I understand why.

If you DON'T scan the discs every day, then you need to organize them in some fashion so that they could be picked from the shelves when an order comes in.

If you DO scan them every day, then they can just go on the shelves in random order. The scanner will automatically pick out the discs that it needs to ship that day as they go through.

So, you pay extra for machines and labor to scan every day, but you save on the added cost for sorting equipment, as well as random-accessible storage units and people/equipment to locate and pull random movies from the stacks.

This makes even more sense if, as others have suggested, most of the Netflix inventory is deployed in the field at any one time, and not sitting on the warehouse shelves.

</comment></comment><comment><USER16> Surprisingly manual process - at least on the incoming side. I was interested to know how many discs are stored at one warehouse, but that is probably too specific for them to disseminate freely.

<comment><USER17> I'm surprised too by the manual process described in the article.

I wonder why it itsn't more automated, they could photograph the disc to see if it matches the sleeve for example. It seems like a terrible job to manually check the discs.

<comment><USER18> How quick and accurate is image matching? They can recognise the sleeve quickly but not, it seems the discs. OCR-ing movie titles from discs would be near impossible with any degree of accuracy.

Is there not a unique code/barcode around the central hole on the back though? Or could they overprint a barcode?

</comment></comment></comment><comment><USER19> _It's also the reason that the time of day you mail your DVD back has no effect on when you receive your next one._

Huh? Sure it doesn't matter if you send it before the last pick up of the day: Netflix will receive and ship a DVD the next day and I get the movie the day after.

But if I drop it off after the last pickup time (after 5:00pm for me), I get a DVD back a day later rather than the usual 2-day turnaround.

<comment> brown9-2 Huh? Of course Netflix can't pick it up from the post office if the post office hasn't picked it up from the mailbin yet.

What they're referring to is the fact that it doesn't matter if you drop you DVD in the mailbin at 9am or minutes before last pick up.

</comment></comment><comment><USER20> Interesting. I didn't expect Netflix to have a "fun" atmosphere like Zappos or anything, but it's funny to hear about a trendy web company with little, if any, character.

I wonder why the employees are required to wear the red Netflix t-shirts. It's not like they need to look presentable for customers or anything...

<comment> brown9-2 I would imagine that working as some sort of engineer in the corporate headquarters is worlds apart from working in the warehouse sorting DVDs, and that you couldn't draw inferences about one from the other...

</comment></comment><comment><USER21> This warehouse sounds like a job that is far too tedious for me. I'm glad they get full health insurance and a 40 hour work week though.

I can't wait until every title they offer can be streamed to the Xbox360. They have a great selection already, but it will make Netflix even better than it already is!

</comment><comment><USER22> similar story about the netflix warehouse in Hartford, CT. [http://www.courant.com/community/hartford/hc- netflix-0722.ar...](http://www.courant.com/community/hartford/hc- netflix-0722.artjul22,0,2929816.story)

</comment><comment> brown9-2 I've noticed this in other articles/media "trips" to warehouses before:

 _Forty-two people work here, nearly every one in a red Netflix T-shirt._

What is up with the shirts?

<comment><USER23> What they probably did was hand out shirts to the employees to look snappy for the visiting dignatary. Most companies I've worked for try to do the same. Some require higher "dress levels" when visitors are coming (like the current one says "no shorts & flip flops; use business casual" only on days when important-enough outsiders come by.

</comment></comment><comment><USER24> Heh, the onomatopoeia in this article really rescued it towards the end there.

</comment><comment><USER25> Does anyone know if Netflix is moving to a burn-on-demand model like Redbox?

</comment><comment><USER26> OK, so where is this warehouse? I doubt that they have kept the location secret for this long. (Also, who cares where it is?)

<comment><USER27> Fear of corporate espionage perhaps? Netflix seems to have perfected the system, maybe they don't want competitors snooping around.

That and ppl asking to drop off/pick up discs at the warehouse.

<comment><USER28> The story explains Netflix's reasons.</comment></comment></comment>


The Greeks really do have near-mythical origins, ancient DNA reveals - <AUTHOR> http://www.sciencemag.org/news/2017/08/greeks-really-do-have-near-mythical-origins-ancient-dna-reveals <comment><AUTHOR> Link to full Nature paper, "Genetic origins of the Minoans and Mycenaeans": [https://t.co/8hNao9XFTt](https://t.co/8hNao9XFTt)</comment>


Customizing and Running JupyterHub in Production at Tubi - <AUTHOR> https://code.tubitv.com/introducing-tubi-data-runtime-387e8651d08a <comment><USER2> Do you plan to open source the pandas-redshift connector too?

<comment><AUTHOR> Not sure how popular redshift is in the pandas community. Certainly, we'd consider open-sourcing it but not sure if it's better to add to pandas or as something separate.

</comment></comment><comment><USER3> Will Tubi come to LG WebOS?

<comment><AUTHOR> Working on getting Tubi shipped everywhere. Don't yet have a timeframe for LG WebOS as of right now.</comment></comment>


The Science Behind the Flamingo's One-Legged Stance - <AUTHOR> https://www.nytimes.com/2017/05/24/science/flamingos-one-leg-stance-muscle.html?rref=collection%2Fsectioncollection%2Fscience&action=click&contentCollection=science&region=rank&module=package&version=highlights&contentPlacement=2&pgtype=sectionfront&_r=0 <comment><USER2> Funny, I've just started noticing that I sometimes unconsciously stand flamingo style when at my standing desk. No idea why.

<comment><USER3> I do it to take the load off one leg when I'm standing for a long period of time. Of course that means my other leg gets twice the load so I wind up swapping legs pretty often.

</comment></comment><comment><USER4> I think this is a repost from a few days ago?

<comment><USER5> Yes and no. The story about the flamingo's one-legged stance was posted twice [1] [2], but it's not technically a repost as it was reported by The Atlantic [1] and by the authors of the study [2], not the NYTimes.

[1] [https://news.ycombinator.com/item?id=14416521](https://news.ycombinator.com/item?id=14416521)

[2] [https://news.ycombinator.com/item?id=14408786](https://news.ycombinator.com/item?id=14408786)</comment></comment>


Show HN: Increment/decrement counters using various front end frameworks - <AUTHOR> https://github.com/adrianmcli/omg-counters <comment><AUTHOR> Sometimes a hello world app is just too simple and a todo app feels massively complex. I started feeling this more and more as I tried out various frameworks, so I thought I'd compile a list of increment decrement counters to demonstrate simple state handling with a bunch of frameworks.

The examples aren't perfect, but it would be great to improve them and add even more frameworks to the list.</comment>


Luxbar: Featherweight, Responsive, CSS Only Navigation Bar - <AUTHOR> https://github.com/balzss/luxbar <comment><USER2> If it meets the guidelines, this might make a good 'Show HN'. Show HN guidelines: [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)</comment>


What America can learn from Nordic police - <AUTHOR> https://theweek.com/articles/918143/what-america-learn-from-nordic-police <comment><USER2> > In other words, in terms of controlling crime, America's gigantic mass > incarceration complex stuffed full of people serving decades-long sentences > is completely pointless.

Sounds correct. The giant incarceration complex is more about exploiting cheap labor than helping criminals become functioning members of society: [https://aflcio.org/about/leadership/statements/exploitation-...](https://aflcio.org/about/leadership/statements/exploitation- prison-labor).

> Increasingly, however, prison labor is being used in both the states and by > the federal government to perform work in both the private and public > sectors ordinarily done by free workers. Twenty-one states have statutes > that compel prisoners to work, and others enforce policies that penalize > inmates who refuse to work. Prison laborers are generally denied coverage > under minimum wage, unemployment compensation, workers_ compensation, > collective bargaining and other worker protection laws.</comment>


GoAWK: an AWK interpreter written in Go - <AUTHOR> https://benhoyt.com/writings/goawk/ <comment> kris-s AWK is such a cool little tool, great way to process log files (as shown in the article). Glad to see it still getting some attention.

It's kinda nuts how far the unixy idea of "just streams of text" has gotten us.

<comment><USER2> _It 's kinda nuts how far the unixy idea of "just streams of text" has gotten us._

As much as I agree that the tooling is, object-based tools would be _much_ nicer.

        for i in `ls`; do echo $i.size; done;

versus

        ls -la | awk '{print $5}'

I know which I'd prefer.

<comment><USER3> No, that's awful if you consider its implications. Just do:

      for i in *; do du -bs "$i"; done

<comment><USER4>
        > for i in *; do du -bs "$i"; done
        du: illegal option -- b
        usage: du [-H | -L | -P] [-a | -s | -d depth] [-c] [-h | -k | -m | -g] [-x] [-I mask] [file …]

_cool_

</comment></comment></comment></comment><comment><USER5> Awk in Lisp as a macro with Lisp AST syntax:

[http://nongnu.org/txr/txr-manpage.html#N-000264BC](http://nongnu.org/txr/txr- manpage.html#N-000264BC)

* Implements almost all salient POSIX features and some Gawk extensions.

* _awk_ expression can be used anywhere an expression is allowed, including nested within another _awk_ invocation. Awk variables are lexically scoped locals: each invocation has its _nf_ , _fs_ , _rec_ and others.

* _awk_ expression returns a useful value: the value of the last form in the last :end clause.

* can scan sources other than files, such as in-memory string streams, strings and lists of strings.

* supports regex-delimited record mode, and can optionally keep the record separator as part of the record (via "krs" Boolean variable).

* unlike Awk, range expressions freely combine with other expressions including other range expression.

* ranges are extended with semantic 8 variations, for succinctly expressing range-based situations that would require one or more state flags and convoluted logic in Awk: [http://nongnu.org/txr/txr-manpage.html#N-000264BC](http://nongnu.org/txr/txr-manpage.html#N-000264BC)

* strongly typed: no duck-typed nonsense of "1.23" being a number or string depending on how you use it. Only _nil_ is false.

Recently accepted Unix Stackexchange answer featuring awk macro: [https://unix.stackexchange.com/questions/316664/change- speci...](https://unix.stackexchange.com/questions/316664/change-specific- part-of-file-via-a-shell-script/316752#316752)

<comment><USER6> Cool, but why not use Common Lisp?

<comment><USER5> In 3.5 words: using isn't making.

</comment></comment></comment><comment><USER7> Lua and AWK. I'm inspired! I'm going to rewrite the Perl 5 interpreter in Go. Take that Larry. Just kidding.

I'm all for scratching an itch, but why rewrite all these well established tools?

<comment><USER8> I extended somebody elses programming language recently, then wrote a BASIC. Mostly to make sure that I understood lexing, parsing, and AST stuff.

While you're right this is reinventing the wheel it can make sense to reimplement old tools to improve safety, security, and to allow them to be embedded in new environments.

Have you ever run a fuzz-tester against (GNU) awk? I have. Even now you can segfault awk with bogus programs, for example:

[https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=816277](https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=816277)

No doubt this new implementation won't be perfect, but segfaults should be ruled out via rust/go/ML implementations..

<comment><USER7> Ha! My interaction with AWK throughout the years has been a fuzz test in progress. Very interesting link though.

On the other hand, I think what you're saying about expanding a well known tool's range of use in new environments makes sense.

</comment></comment></comment><comment><USER9> I also really like such posts. I have never written an interpreter. What do experts recommend i.e. how can someone without a formal CS background learn about write an interpreter? Any good sources, articles, or books? Thanks in advance.

<comment><USER10> Depending on how involved the language you are interpreting is, you might get by having only read chapter 6 of The AWK Programming Language[0] (linked in the article), which covers "Little Languages", including what it terms an assembler and interpreter.

If you are interested in more depth, either Crafting Interpreters[1] (mentioned in the article) or Writing an Interpreter in Go[2] looks promising. I've read more of Crafting Interpreters and really enjoy it, though it isn't yet finished. One of the aspects I really enjoy is that the language is implemented and re-implemented in different languages to gradually introduce lower level concepts.

Finally, this one may be a little more "out there" than what you are looking for, but if you are interested in designing a language more than the plumbing of an interpreter Beautiful Racket[3] is really good.

caveat: not an expert

[0]: [https://ia802309.us.archive.org/25/items/pdfy- MgN0H1joIoDVoI...](https://ia802309.us.archive.org/25/items/pdfy- MgN0H1joIoDVoIC7/The_AWK_Programming_Language.pdf)

[1]: [http://www.craftinginterpreters.com/](http://www.craftinginterpreters.com/)

[2]: [https://interpreterbook.com/](https://interpreterbook.com/)

[3]: [https://beautifulracket.com/](https://beautifulracket.com/)

</comment></comment><comment><USER11> Troff + pic + eqn ported to Go would be cool :>

<comment><USER12> Holy shit yes please. And grap.

</comment></comment><comment><USER13> I wonder if there's a file size + workload at which the coordination overhead of a parallel awk is low enough for an overall performance win.

</comment><comment><USER14> Nice to see another implementation, but I still hope the original one will be always kept alive

<comment><USER15> It the one used by all the BSD systems.

Recently there is an official Github repository with commits from Brian kernighan.

[https://github.com/onetrueawk/awk/commits/master](https://github.com/onetrueawk/awk/commits/master)

</comment></comment><comment><USER16> While I'm cool with writing other language processors in a new language (Lisp written in Cobol anyone?) I'm missing the value of this past the bragging rights.

There was a similar article about writing the LuaVM in Go, to package it in bigger Go applications. I've done lots of C based systems and bolted Lua on, so the Go version makes sense.

But is imbedding Awk into a program that gets done on a regular basis?

<comment><USER17> I believe in this instance it is the author wanting to level up on AWK and Go. The value is learning and fun.

An AWK interpreter written in Go is unlikely to be an improvement, except, well here is another blog post you might be interested in that has a similar sense of adventurous tinkering (it's about improving on grep): [https://ridiculousfish.com/blog/posts/old-age-and- treachery....](https://ridiculousfish.com/blog/posts/old-age-and- treachery.html)

That's from 2006 and the tl;dr was graybeards did things a certain way for a reason. And yet nowadays with have things like rg (and ag and a bunch of others).

<comment><USER18> I think my GP has an objection to it being shared and being on top when there is nothing to learn from this in terms of ideas (which I share) and not to people hacking away.

<comment><USER19> But now other people who are interested in Go can learn from it. Seems pretty much the point of HN - finding interesting things to learn.

</comment></comment></comment></comment><comment><USER20> Why do so many modern projects feel the need to include the language and/or the tech stack used as part of the project name? Is it a type of virtue signaling? Does "Go" or "JS" or "Swift" or "Node" make these project more attractive somehow to an end-user (even if the end-user is a programmer)?

<comment><USER21> Back it the day GNOME projects had a G somewhere, while KDE ones had a K, which now can be mixed up with Kotlin ones actually.

C++ projects used to add ++ as suffix, for example Rogue Wave Tools.h++ and Motif++ libraries back in the glory days of commercial C++ compilers.

So this fashion is already quite old.

<comment> black-tea But those are signalling compatibility with other tools. That's fine. It makes sense. But just imagine if someone posted about the original awk (which happens from time to time) and titled it "awk: a text processor written in C".

<comment><USER21> Thing is, we now have this thing that language X is not good for doing Y, so when one does post a software for doing Y in X, and it actually does a good job, it works as marketing material for language X.

Programming languages are software products as well, and their customers want to feel they have made the right choices sticking with their options.

</comment></comment></comment></comment><comment><USER22> party hard.

</comment><comment><USER23> should have just named it gawk tbh

<comment><USER24> Not sure if you're making a joke or unaware of [https://www.gnu.org/software/gawk/](https://www.gnu.org/software/gawk/) :)

</comment></comment><comment><USER25> I am hoping one day there is going to be an operating system, where every single tool is written in Go and everything runs in containers! Well done!

<comment><USER26> Why? GC is overkill for a good number of command line tools.

What advantage do you see in command line tool running in its own container? Given how important pipes are, that's going to be a lot of overhead punting data between containers.

<comment><USER27> Actually, _lack_ of a GC is overkill (in terms of control needed over memory) for most command line tools.

Having to manually track memory liveness C adds a large amount of complexity to tools like awk, sed, grep (which are already complex beasts themselves).

<comment><USER28> Many commands that only do a few things (perhaps not awk, since it runs full programs) don't need to free everything, since it will only allocate a few things and will soon terminate and free the entire process.

<comment><USER27> Nearly any command that you pipe into, or stream content out of, must to allocate and free memory in some non-trivial way.

Sure, those commands could just allocate and never free memory (a-la early C compilers, or the D compiler), but now any use-case that involves a large amount of data will leak noticeably. Not going to fly if you need these commands to be durable and efficient. And unix commands need to be both.

A GC gets you the freedom to operate on large streams for free, without having to worry about memory management (modulo optimization, but that happens later anyways, regardless of GC presence or not).

<comment><USER28> In some cases, yes. But not in all kind of programs. For example, my Farbfeld Utilities programs, are different how much buffers is needed:

* Some deal with only one pixel at a time, or sometimes two. No dynamic allocation is needed.

* Some deal with one scanline at a time, or sometimes more than one (but a fixed number) at a time. The same buffer can be used for each scanline.

* Some deal with the entire picture (such as those that distort the picture).

But one possibility can be that a program might load multiple pictures and each picture needing the entire picture at once, but does not use them simultaneously, in which case it is sense to free each picture after it is used.

(Or maybe I somehow misunderstood your message or something else.)

<comment><USER27> The point is, the default decision should be to not have to worry about memory management. Most application shoudn't, because they're not realtime operating systems, or in an environment where memory must be allocated statically.

Almost all unix command line utilities fall into this category. Having to worry about pairing your `free`s with your `malloc`s is a strict increase in cognitive overhead, which should have been spent on verifying the program's semantics are correct.

Messing up low-level memory operations, when you just want to worry about semantic correctness, potentially leads to bugs like RCEs, or dosing somebody with too much radiation.

<comment><USER29> Thankfully, these days, you don't actually need to choose between GC and manually matching up your `free`s with your `malloc`s.

There is at least some data that GC does have an impact on command line tools like this: [https://boyter.org/posts/sloc-cloc- code/](https://boyter.org/posts/sloc-cloc-code/) \--- More experiments like that would be great to crystallize the exact trade offs here.</comment></comment></comment></comment></comment></comment></comment></comment>