Live data from Hacker News

Phrases in computing that might need retiring

sicpers.info

271–280 of 291 posts

Re: Phrases in computing that might need retiring

#271
post #231

Earlier quoted context omitted.

Same (re: master / slave)... At a previous job, a coworker presented a compelling argument for removing "whitelist" and "blacklist" terminology from our codebases / jargon. Even though the etymologies of the words don't describe them as being based on race / racial judgments, their first recorded usages were in the 16th-17th centuries, when mass enslavement was in full swing. Setting aside the historical context, the…

Purely from a clarity standpoint, I'm in favor of killing off whitelist/blacklist. They just introduce an extra step in figuring out what something is—whitelist usually means stuff to allow, blacklist is stuff to deny, but I at least have to dig that up from memory since white/black don't mean that at all. Exclude, allow, deny, ignore, block, etc. are all more obvious, and in many cases more descriptive. In most case…

> whitelist usually means stuff to allow, blacklist is stuff to deny, but I at least have to dig that up from memory since white/black don't mean that at all.

Isn't that true for most words/phrases? No words inherently mean anything. We assign meaning to them. I suppose that if enough people settle on a replacement for 'whitelist' and 'blacklist' those words will be limited to history, but right now it will mean being forced to remember multiple phrases for the same thing since others will certainly still use the current terms.

In the context of your own use/code it doesn't matter much, but every mail provider (just one example) will be dealing with blacklists that describe themselves as such and incoming requests from people looking to be whitelisted which means they'll still have to take whatever steps are needed to recall what those words mean, and must still be trained on the meaning of those words, all while still having to remember not to use those words in their own writing/code/documentation and having to remember what new words they should replace them with/translate them as.

Maybe there is too much jargon in tech in general, and I certainty don't object to efforts to reduce it, but I don't see it as saving anybody much time/effort in the near term.

Re: Phrases in computing that might need retiring

#272

Earlier quoted context omitted.

My followup question is why you felt the need to claim that the answer to an empirical question is something that you haven't verified empirically?

100% you are a dude.

My guess is that HN is mostly men, so you're likely to be right, but probably for the wrong reasons.

Re: Phrases in computing that might need retiring

#273

Earlier quoted context omitted.

Same (re: master / slave)... At a previous job, a coworker presented a compelling argument for removing "whitelist" and "blacklist" terminology from our codebases / jargon. Even though the etymologies of the words don't describe them as being based on race / racial judgments, their first recorded usages were in the 16th-17th centuries, when mass enslavement was in full swing. Setting aside the historical context, the…

I've always felt the more compelling reason is that a blacklist is never a list of black items. The amount of times I've seen a blacklist used as a list of users that are denied a restriction (i.e. double-negative -- able to do something) is too many.

> I've always felt the more compelling reason is that a blacklist is never a list of black items.

Why assume it's the items that should be black and not the list itself?

Really, blacklists have nothing to do with the color of lists or the items. It's from the 1400s when "black" was used to mean "censured or disgraced". We see that in phrases like "Black Mark" (as in "a black mark on your record") where at least the mark presumably had a color (“a black cross or other mark made against the name of a person who has incurred censure, penalty, etc.,”).

In that context it makes perfect sense for a blacklist to be a list of things which are being penalized/censured and for an opposite list to be described with the opposite color.

Re: Phrases in computing that might need retiring

#274
post #231

Earlier quoted context omitted.

Purely from a clarity standpoint, I'm in favor of killing off whitelist/blacklist. They just introduce an extra step in figuring out what something is—whitelist usually means stuff to allow, blacklist is stuff to deny, but I at least have to dig that up from memory since white/black don't mean that at all. Exclude, allow, deny, ignore, block, etc. are all more obvious, and in many cases more descriptive. In most case…

> whitelist usually means stuff to allow, blacklist is stuff to deny, but I at least have to dig that up from memory since white/black don't mean that at all. Isn't that true for most words/phrases? No words inherently mean anything. We assign meaning to them. I suppose that if enough people settle on a replacement for 'whitelist' and 'blacklist' those words will be limited to history, but right now it will mean bein…

that first paragraph is peak Hacker News lol

Re: Phrases in computing that might need retiring

#275

Earlier quoted context omitted.

My followup question is why you felt the need to claim that the answer to an empirical question is something that you haven't verified empirically?

100% you are a dude.

What rules you used to infer my sex from the text of my comment?

Re: Phrases in computing that might need retiring

#276
post #124

Earlier quoted context omitted.

Your description is apt when you are talking about an analogy between technical debt and personal debt. For companies, whether to use debt or equity to finance their balance sheet is just a technical decision. Either way, you have to pay the cost of capital. (Ie even if you finance your project from equity and not from debt, it still has to be better for your shareholders than just giving them the necessary capital b…

I get why Technical Equity is a better term, but very few % age of the population really understand what Equity means, while debt can be explained to a 5 year old

Yes. Though I wouldn't even say it's a 'better term'; just because the metaphor might hold slightly more water in some highly technical sense, doesn't actually make it a better term. ;)

This reminds me: if you went to a farm and actually 'picked the low hanging fruit first', they would likely fire you. The fruit higher up on the tree typically ripens faster, so should be picked first. (But the phrase as a metaphor is fine, and everyone knows what it's supposed to mean.)

Re: Phrases in computing that might need retiring

#277
post #202
post #84

Earlier quoted context omitted.

I agree, and I love the metaphor too, but you have to admit that something about the metaphor isn’t reaching peoples’ brains the way a good metaphor does. A good litmus test here is to ask someone, “what if I told you that technical debt was originally a good thing?”... Like “Yes! Let’s go and get some technical debt, it will be great!” And so, can you understand why it might have started out that way? People who rea…

Simply because it's a lot nicer to say than "my predecessor did dumb stuff". Especially when the predecessor is still around and outranks you.

The predecessor or old self did dumb stuff because of being pressured to deliver something quickly and had to cut corners. I don't see how he'd be offended that now it's time to go back and do it properly.

Re: Phrases in computing that might need retiring

#278
post #96

Object-Oriented Programming: "Luckily the industry doesn’t really use this term any more" Wait really? What world are they living in? Am I just out of touch or something?

OOP is pretty well defined. 99% of the time it means type dependent namespaces. Class A.foo and Class B.foo both represent separate namespaces in which a field or method foo can be defined, the name space is directly tied to a type. In Haskell every function is defined in what amounts to be a global namespace. This is particularly annoying when you have records that share the same attribute names. You might argue tha…

I love how the well-defined starts with a definition I've never heard for OOP.

Re: Phrases in computing that might need retiring

#279
post #244

Earlier quoted context omitted.

By that, then, you mean undefined. It once meant that three features appeared: encapsulation, inheritance, and constrained runtime binding. Any time it is used without implying those, it is just more or less noise. That said, OO has become a niche technique: it fits certain problem spaces well, others very badly. Any big enough system will have some parts that could meaningfully be described as mostly OO. But there i…

I think we have to look to Alan Kay for an original definition, since he invented the term, and according to him, inheritance is not a necessary part of object orientation. In Smalltalk (and various Lisps), inheritance is something that is created from objects and messages, not a fundamental feature of the language. In [one place]( http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay... ) he defines it as "OO…

This is the fruitful definition of OOP to me. None of that Java Corporate insanity
Post reply on HN