Live data from Hacker News

Never trust a system that seems to be working

twitter.com

341–350 of 376 posts

Re: Never trust a system that seems to be working

#341
post #327

As I and others have previously pointed out [1] foone uses they/them pronouns and feels particularly frustrated when their posts get featured on HN, because users here seem unable to honor this simple preference of theirs. It looks like they deleted their tweet out of frustration with todays latest round of misgendering. I hope people on HN will learn to respect all members of our community. Yes that involves not ass…

Quoted post unavailable.

Doesn't that broadly seem like a problem? Given the preferred pronouns here are "they/them", which is what people ought to be using if they don't know, the problem stems from people inherently assuming "he/him" for any technical work. That's a problem beyond just trans/gnc issues.

Re: Never trust a system that seems to be working

#342
post #341
post #327

Earlier quoted context omitted.

Quoted post unavailable.

Doesn't that broadly seem like a problem? Given the preferred pronouns here are "they/them", which is what people ought to be using if they don't know, the problem stems from people inherently assuming "he/him" for any technical work. That's a problem beyond just trans/gnc issues.

Given that for non-city dwellers, interactions with transgenders are rarer than rare. Given that the assumption that anything non explicitly female is male is still very common. I suspect foone will be dealing with this issue for longer than they’d like.

Re: Never trust a system that seems to be working

#343
post #318

Earlier quoted context omitted.

My favorite was C code that was roughly (all functions and variables h: int bar; ... foo() { if(bar) { doX(); else doY(); } } Note that uninitialized globals in C are implicitly zero-initialized. doY() had been broken for years but nobody ever set bar to be true; doX() was nevertheless being called. Setting bar to zero caused the buggy doY() to happen. Setting bar to one seemed to work, but would occasionally segfaul…

You're missing the } and { around your else, btw. I'm only mentioning that because I immediately saw it and got ready to read a horrifying story involving the text "#define else".

oh gosh I am.

Re: Never trust a system that seems to be working

#344
post #315
post #262

Earlier quoted context omitted.

They also seem to hate Factorio itself, which is the reason that while they play it and tweet about it so much, they mangle its name. I don't understand it, but everyone is free to remove what they want from their own Twitter I guess.

FWIW re the mangling: According to foone, the reason they blank out the name is to avoid it showing up on searches for the game (automated or otherwise), which they say has led to a subset of fans of the game sending them transphobic comments because of the past drama and the presence of a trans flag on their twitter page. But as you say, people can do what they like.

That is not the reason I had been told and I can't easily check this (can't search -- that's the point). It is not unlikely that I have been led astray.

Re: Never trust a system that seems to be working

#345
post #325

Earlier quoted context omitted.

Quoted post unavailable.

Seems they're tired of people in HN threads misgendering them, and have already tried diplomatic solutions. You can find it if you go straight to their profile. I honestly haven't seen anything like that in this thread, but maybe I'm not looking hard enough...

No post body was provided.

Re: Never trust a system that seems to be working

#346
post #35

If your code has side effects, it only ever seems to be working. ---- > the newbie says "aww, why isn't it working?" > the intermediate says "yay, it's working!" > the expert goes "hmm, why is it working?" I've also seen this as My thing isn't working and I change X and now I get error J instead of error K, so now I have to change X back because it's still not working. Where K is a "better" error than J, such as K =…

Working with beginning programming students, "Yay, now we have an error message that makes sense" has become my catchphrase.

Or its close cousin: "Yay, now we have a different error message!" When something is totally broken and you have no idea why, this is a promising signpost.

Re: Never trust a system that seems to be working

#347
post #318

Earlier quoted context omitted.

You're missing the } and { around your else, btw. I'm only mentioning that because I immediately saw it and got ready to read a horrifying story involving the text "#define else".

oh gosh I am.

I thought that was the bug on my first read. Naming collisions suck.

Re: Never trust a system that seems to be working

#348

Just want to note that the novel noted in the first post, The Moon Is A Harsh Mistress , is a great read. I think I read it after seeing it recommended in Mary Robinette Kowal's Lady Astronaut series, but it's a nice balance of technical and science fiction with politics, almost like a condensed version of KSR's Mars Trilogy. It's mostly (not entirely) devoid of the more typical Heinlein sexism/objectification.

It's been a long way since I've read it, and it certainly had an interesting theme of politics and oppression. What bugged me was the description of the resistance movement: it pretended to be cleverly divided into cells, but ultimately the computer knew everything so it was pretty questionable security theater, and it didn't seem the book was particularly self-aware of that fact.

Re: Never trust a system that seems to be working

#349

Earlier quoted context omitted.

Also issue with golang (+ protobufs) where you can't distinguish a populated zero value from the default "not present" value.

Thats why JavaScript has both undefined and null!

Do we really need to differentiate between undef and null?

Re: Never trust a system that seems to be working

#350

This is why 4-20 mA is a common signaling standard in industrial automation. 4 mA means zero and 20 mA means one. 0 mA means broken transmitter !

Also issue with golang (+ protobufs) where you can't distinguish a populated zero value from the default "not present" value.

C# linqs method - first or default has the same problem
Post reply on HN