5 ms·

> It's not enough for a program to work, it has to work for the right reasons. Code working for the wrong reasons is code that's going to break when you least e

> It's not enough for a program to work, it has to work for the right reasons. Code working for the wrong reasons is code that's going to break when you least expect it. This reminds me of the recent discussion of gettiers[1]. That article focused on Gettier bugs, but this passage discusses what you might call Gettier features. Something that's gotten me before is Python's willingness to interpret a comma as a tuple. So instead of: my_event.set() I wrote: my_event,set() Which was syntactically correct, equivalent to: _ = (my_event, set()) The auto formatter does insert a space though, which helps. Maybe it could be made to transform it as I did above, that would make it screamingly obvious. [1a] https://jsomers.net/blog/gettiers https://jsomers.net/blog/gettiers [1b] https://news.ycombinator.com/item?id=41840390 https://news.ycombinator.com/item?id=41840390

HL33tibCe7 2y ago
Your font and/or eyesight might need attention!
- settsu 2y ago
  Tell me you're a 20-something engineer without telling me you're a 20-something engineer.
  - HL33tibCe7 2y ago
    Wrong
  - lcnPylGDnU4H9OF 2y ago
    The implication being that older programmers would be entirely unconcerned with one's eyesight and the effect that reading a small font could have on such? Somehow that seems a bit backwards. People don't know what they have until it's gone.
    - PaulHoule 2y ago
      Developing presbyopia was the first time I thought "getting old sucks". I am doing an accessibility audit for an application at work right now and I was tasked with getting things up to the WCAG AA level but I found that I had huge amounts of unused white space, even viewing it at 1024x768 desktop, and jacked font sizes up not to the "large type" levels of AAA but substantially larger which I think is easier for everyone, given the size of the UI controls information density is not going down a whole lot.
- maxbond 2y ago
  You know what, I do use a small font size in my editor. I like to see a lot of code at once. And if memory serves I spotted this in the browser, where I do the opposite. I'll have to look into hyper legible monospace fonts. Or maybe I'll just use Atkinson and deal with the variable spacing.
- nomel 2y ago
  My editor uses a different color for comma and period.
csours 2y ago
I was expecting to find the word Gettier in the text. My comment on that Gettier post: Puttiers: When a junior engineer fixes something, but a different error is returned, so they cannot tell if progress was made or not. https://news.ycombinator.com/item?id=41850429 https://news.ycombinator.com/item?id=41850429
praptak 2y ago
So we have an analogy: accidentally working app : correct app :: Gettier "not knowledge" JTB : proper knowledge JTB Is it possible to backport the program analogy back into the realm of philosophy? I'm dreaming of a philosophy paper along the lines of "Knowledge is JTB with proper testing".
hansvm 2y ago
One pattern that eliminates a lot of such bugs is never using any name that's a keyword or common name in any mainstream programming language. The existence of `def set...` in your code was already asking for trouble, and you were unlucky enough to find it.
- maxbond 2y ago
  I agree, but this is a method on an object in the standard library! https://docs.python.org/3/library/asyncio-sync.html#asyncio.Event.set https://docs.python.org/3/library/asyncio-sync.html#asyncio.... Could've been called fire() or activate(), perhaps. This is also the kind of problem lints are really good for. I wouldn't be surprised if there was an lint for this already (I haven't checked).
  - hansvm 2y ago
    Oh that's annoying.
- bobbylarrybobby 2y ago
  This is ridiculous, not having access to a set() method is just silly. Also I'd imagine that most languages use another language’s keyword for functions to name a callable variable, func being (I'd assume) a particularly common name. match is a perfectly good name for the result of a regex search... etc etc. The real issue here is simply that python didn't camel case its built in class names; then this would only be a problem if you violated case conventions and named your method Set() (or mistyped the case as well).
  - hansvm 2y ago
    Those are perfectly good names, but it's also incredibly easy to avoid a few hundred words. `f` or `predicate` or what have you are easy names for functions as arguments, and something like `maybe_match` or `maybe_parsed_username` is more likely to represent the results of an arbitrary regex. You absolutely don't have to follow every piece of advice you read, but I'll argue for it once more anyway. My guiding principle is that I make mistakes from time to time, and those mistakes are incredibly expensive when they hit prod. If two things need to change in tandem then I'll derive one from the other in code (or at an absolute bare minimum put comments in both locations warning that they need to be changed in tandem, though with modern language features that's rarely necessary for any reason nowadays) (guaranteeing they actually change together). If I don't need the result of a function call I'll still give it a name and explicitly discard it (adding redundant bits of information for future readers -- indicating that I ignored the result intentionally and also reducing future git blame search time in case the result is ever valuable or the API changes). When a chunk of data has some constraints beyond being an arbitrary primitive I create a wrapper type (free at runtime in any system language) to let the compiler double-check my work. Those are all small things, but with a short library of such patterns the code I write is almost always correct if it compiles, and none of those habits are particularly hard to develop. Not using potentially reserved words, similarly, reduces the chance of certain errors. Kind of like the swiss cheese model in aviation, you add one extra (fallible) layer of redundancy against bugs like foo,set(). Since it's a cheap mitigation, it's one I follow unless I have an amazing reason to do otherwise. Yes, Python could have named things differently, but that ship has sailed. If I'm using Python (and it winds up being a good choice a few times a week currently) then I have to work around those design issues.

HL33tibCe7 2y ago

Your font and/or eyesight might need attention!

settsu 2y ago
Tell me you're a 20-something engineer without telling me you're a 20-something engineer.
- HL33tibCe7 2y ago
  Wrong
- lcnPylGDnU4H9OF 2y ago
  The implication being that older programmers would be entirely unconcerned with one's eyesight and the effect that reading a small font could have on such? Somehow that seems a bit backwards. People don't know what they have until it's gone.
  - PaulHoule 2y ago
    Developing presbyopia was the first time I thought "getting old sucks". I am doing an accessibility audit for an application at work right now and I was tasked with getting things up to the WCAG AA level but I found that I had huge amounts of unused white space, even viewing it at 1024x768 desktop, and jacked font sizes up not to the "large type" levels of AAA but substantially larger which I think is easier for everyone, given the size of the UI controls information density is not going down a whole lot.
maxbond 2y ago
You know what, I do use a small font size in my editor. I like to see a lot of code at once. And if memory serves I spotted this in the browser, where I do the opposite. I'll have to look into hyper legible monospace fonts. Or maybe I'll just use Atkinson and deal with the variable spacing.
nomel 2y ago
My editor uses a different color for comma and period.

csours 2y ago

I was expecting to find the word Gettier in the text. My comment on that Gettier post: Puttiers: When a junior engineer fixes something, but a different error is returned, so they cannot tell if progress was made or not. https://news.ycombinator.com/item?id=41850429 https://news.ycombinator.com/item?id=41850429

praptak 2y ago

So we have an analogy: accidentally working app : correct app :: Gettier "not knowledge" JTB : proper knowledge JTB Is it possible to backport the program analogy back into the realm of philosophy? I'm dreaming of a philosophy paper along the lines of "Knowledge is JTB with proper testing".

hansvm 2y ago

One pattern that eliminates a lot of such bugs is never using any name that's a keyword or common name in any mainstream programming language. The existence of `def set...` in your code was already asking for trouble, and you were unlucky enough to find it.

maxbond 2y ago
I agree, but this is a method on an object in the standard library! https://docs.python.org/3/library/asyncio-sync.html#asyncio.Event.set https://docs.python.org/3/library/asyncio-sync.html#asyncio.... Could've been called fire() or activate(), perhaps. This is also the kind of problem lints are really good for. I wouldn't be surprised if there was an lint for this already (I haven't checked).
- hansvm 2y ago
  Oh that's annoying.
bobbylarrybobby 2y ago
This is ridiculous, not having access to a set() method is just silly. Also I'd imagine that most languages use another language’s keyword for functions to name a callable variable, func being (I'd assume) a particularly common name. match is a perfectly good name for the result of a regex search... etc etc. The real issue here is simply that python didn't camel case its built in class names; then this would only be a problem if you violated case conventions and named your method Set() (or mistyped the case as well).
- hansvm 2y ago
  Those are perfectly good names, but it's also incredibly easy to avoid a few hundred words. `f` or `predicate` or what have you are easy names for functions as arguments, and something like `maybe_match` or `maybe_parsed_username` is more likely to represent the results of an arbitrary regex. You absolutely don't have to follow every piece of advice you read, but I'll argue for it once more anyway. My guiding principle is that I make mistakes from time to time, and those mistakes are incredibly expensive when they hit prod. If two things need to change in tandem then I'll derive one from the other in code (or at an absolute bare minimum put comments in both locations warning that they need to be changed in tandem, though with modern language features that's rarely necessary for any reason nowadays) (guaranteeing they actually change together). If I don't need the result of a function call I'll still give it a name and explicitly discard it (adding redundant bits of information for future readers -- indicating that I ignored the result intentionally and also reducing future git blame search time in case the result is ever valuable or the API changes). When a chunk of data has some constraints beyond being an arbitrary primitive I create a wrapper type (free at runtime in any system language) to let the compiler double-check my work. Those are all small things, but with a short library of such patterns the code I write is almost always correct if it compiles, and none of those habits are particularly hard to develop. Not using potentially reserved words, similarly, reduces the chance of certain errors. Kind of like the swiss cheese model in aviation, you add one extra (fallible) layer of redundancy against bugs like foo,set(). Since it's a cheap mitigation, it's one I follow unless I have an amazing reason to do otherwise. Yes, Python could have named things differently, but that ship has sailed. If I'm using Python (and it winds up being a good choice a few times a week currently) then I have to work around those design issues.