8 ms·
I find this "falsehoods programmers believe" format of making pointed claims that you intentionally don't clarify to be unhelpful and obnoxious
by koala_man 2y ago
I find this "falsehoods programmers believe" format of making pointed claims that you intentionally don't clarify to be unhelpful and obnoxious
- IAmNotACellist 2y agoThe following list contains only falsehoods: 1. You're wrong 2. Okay, you're right 3. Okay maybe you're right or wrong but certainly not both
- efitz 2y agoYou’re doing it wrong. “Falsehoods programmers believe…” articles are designed to make you THINK about problematic assumptions. They are not like the 10 commandments and they are not decrees of absolute truth.
- Dylan16807 2y agoSaying a thing and then saying the opposite, without elaborating, is not good at making you THINK. This list is doing it wrong.
- Izkata 2y agoYep, the original "names" one was mostly written so negating each of the points gave you the exception you needed to handle. Even the cases written with both were done on a way it was obvious the negation didn't apply universally, so both worked.
- homebrewer 2y agoNow imagine how much time could have been saved globally if one person spent half an hour writing a short description of why each point is false instead of making hundreds (or thousands) of people spend hours thinking about and researching every one of them. You're probably left with more knowledge in the end if you're not spoon-fed by the author, but how many of us need really deep knowledge of the TCP inner workings?
- ryandrake 2y agoI look at "Falsehoods programmers believe..." articles as a good source of test cases. If I'm parsing a date (don't do that), I'm going to look at "Falsehoods programmers believe about dates" to help build out my list of unit tests for that function. Same for names, street addresses and so on.
- kranuck 2y agoYeah I stopped with 5 and 6 and will never give the slightest care what this person has to say ever again.
- hnlmorg 2y agoI’m pretty sure originals that defined this format did have examples and citations. But I do agree that some of the later entries have felt a little lazy.
- 9dev 2y agoRight, I was about to comment that. One of the first ones I remember was this one, about addresses[1]; or this one, about names[2]. Both provide examples and information, which is the only thing making the whole article useful. [1]: https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/ [2]: https://shinesolutions.com/2018/01/08/falsehoods-programmers-believe-about-names-with-examples/
- koala_man 2y agoI remember the address one. It was fantastic and I loved it. I wish they were all that helpful.
- tenebrisalietum 2y agoFalsehoods falsehood-list makers believe. 1. That said items are falsehoods in the first place. 2. That said items are necessarily interesting or noteworthy. 3. That a list is necessarily the best format to present said items. 4. That they may speak for the involved parties beliefs.
- IshKebab 2y agoI agree. This isn't even a good one of those lists. It's more like "dubious pedantry to make me feel smart about my TCP knowledge". 1-4. Yes we know about the 2 generals problem. And yes we know what "reliable" means in this context. 5-6. This is just stupid. 7. Obviously not true. Nobody thinks this. 8-9. The reasons for and flaws of Nagle's algorithm are well known. 10. This isn't even true. Most of the time you don't need to care about it. That's the whole point of abstraction. You need to care about it if you are doing extensive performance optimisation, but usually you aren't. 11. Again untrue. You can think of TCP as a two way pipe. Again that's the whole point of abstraction. 12. Not sure exactly what they're trying to say here but again it's very well known that TCP and UDP are pretty much the only protocols that are likely to work on the internet. 13. Ditto. We all know why so many protocols are "over HTTPS", e.g. DoH. 14. This isn't a technical point. 15. Dunno what this is talking about but I'm guessing it's along the lines of "a byte is 8 bits", i.e. it is actually true in the modern world.
- raggi 2y agoYep, I work on low level networking software professionally and this post is largely meaningless dribble and is probably motivated by grandstanding. It’s like an engineer who says “how does a screen show black” and then says “nope” to every response. It’s maybe a way to make people think, but beyond that the negativity and grandstanding of it is ultimately a turn off for many receivers which eventually either then has them bully others this way or deters them from the field, depending on how it affects them. There are far better teaching methods that work better for everyone and teach faster and result in higher accuracy and retention.
- yazzku 2y agoThe author probably doesn't understand the answers very well themselves.
- randomdata 2y agoDoesn't the author basically admit that when he prompts someone else to write "falsehoods programmers believe about TCP"? After all, if the author did have the understanding himself he could do it himself. The reset of the writing just laments the pain of using products that make incorrect assumptions – continuing in same lamenting from the quoted segment he includes. It almost has nothing to do with TCP at all, so it is not clear where the parent comment here got the idea that it was trying to teach something about it.
- cubano 2y agoUhhh....how does the screen show black?
- shermantanktop 2y agoEach of the pixels is actually a little shining eye which watches your every move. When the pixel’s eyelid closes, that pixel turns black. That’s why they call it putting a display “to sleep.”
- 2y ago
- numpad0 2y agoI think the original "names" and subsequent "addresses" were useful in that a conclusion(that programmers should embrace defeatism and refrain from parsing or evaluating or even trying to separate them into fields) can be drawn, and the lessons learned were slightly more specific than often realized...
- lovecg 2y agoI believe the article that started it all is https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-... - crucially every entry is self-explanatory, which is a point that a lot of the subsequent “Falsehood…” list authors miss.
- subarctic 2y agoEven that could benefit from including a counterexample in almost every point.
- EGreg 2y agoI saw this one first, but seems patio11 was first: https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time https://infiniteundo.com/post/25326999628/falsehoods-program...
- School-Cotton 2y agoI wonder what he means by France having a “weird” naming system in common use. As far as I can tell, the traditional French naming system works exactly the same way as the traditional American one (except that it’s more common for French people to have several middle names rather than zero or one, but I don’t think that’s too rare in the US either). Maybe he’s referring to the fact that some last names are two words (e.g. Marine Le Pen), but I don’t think that’s very common… Anyway, it could be anything, so I wish he’d said!
- thayne 2y ago> I don’t think that’s too rare in the US eithe Anecdotal, but the only people I've met in the US with more than one middle name are people who originally came from another country. Although, I wonder if maybe that is enforced by the fact tha legal forms and similar typically assume you only have first, last, and optionally a (single) middle name.
- Paradigma11 2y ago
- gweinberg 2y agoThis. If these lists contained things that programmers actually believed and explained why they are false, they might actually be useful. It's hard to imagine an unsupported assertion that an ambiguous statement is "false" and yet its contradiction is also "false".
- adrianmonk 2y agoI don't think you're taking into account the context or intended audience. It's a casual forum message posted in reply to someone else's message. They have not written a "falsehoods programmers believe" article. They have proposed that one ought to be written and have given a starting point for what it might cover. They offered their list to "get the ball rolling", confirming that they don't see it as a finished product. They sent it to other readers of the same forum, who might be expected to have more knowledge of this topic, not to whoever runs across it on the front page of HN.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- ahazred8ta 2y agoPreviously: "falseoods programmers believe about X": https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=falsehoods%20believe&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
- niobe 2y agoI agree, this article was uninsightful.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- sassy_quat 2y agoFalsehoods considered harmful.
- thayne 2y agoI think these lists are often primarily intended as humorous, and perhaps a way to get you thinking about exceptions, not as a way to teach you more about the topic.
- khana 2y ago[dead]
- Uptrenda 2y agoI noticed that too and thought I was missing something. Some cool resources that are actually decent for network programming: https://beej.us/guide/bgnet/ https://beej.us/guide/bgnet/ -- Covers what abstractions the OS provides for network programming and the guarantees that are possible. https://www.madwizard.org/programming/tutorials/ https://www.madwizard.org/programming/tutorials/ - This is the very first ever good tutorial I read on socket programming. It's OG winsock. Introduces network programming from the most basic level. Aimed at C. When you understand these guides you'll learn that how you structure your entire programs networking depends on whether you want to use blocking or non-blocking sockets. If you go with blocking you'll probably be using threads or processes. Otherwise you can't do any other work. With non-blocking it will be more about polling sockets and eventually you might end up with something resembling an event loop. Until you come towards to the current approach to networking which is mostly async await -- an event loop works with non-blocking sockets, watches them for changes, and passes data from them to event handlers. There's a lot more that can be done on sockets to effect things like how data is flushed, how TCP errors are handled, and so on, but its a good start.