Live data from Hacker News

Phrases in computing that might need retiring

sicpers.info

221–230 of 291 posts

Re: Phrases in computing that might need retiring

#221

Earlier quoted context omitted.

Regarding DevOps, a major aim was to embed operational concerns into all stages of development. In that sense, it was a massive success; a developer cannot anymore just say "here's a binary that I made on my machine, make it work in production", throw it towards ops and sign off.

> Regarding DevOps, a major aim was to embed operational concerns into all stages of development. In that sense, it was a massive success... I strongly disagree here. If it was such a success, then why are there devops jobs at all ? If it was meant to signify that developers should share responsibility on deployments and integrations, what's the role of a "devops engineer"? It seems to me that self-proclaimed devops…

DevOps is like what happened to DBAs, now devs get to do another role while still being responsible for their other roles without extra compensation while eliminating a whole job (ops or dba).

Re: Phrases in computing that might need retiring

#222
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 became a marketing term, but no longer sells designs, languages, etc. OOP alone used to be hot. Now it is either just assumed, or eschewed, or considered ambiguous. We’re getting there with FP, too. OOP…which kind? FP…which kind?

Please note that the author never specifies that their context is marketing or management. They instead use a far broader term, “computing”. It would be very difficult for huge swaths of developers to do their job without using OOP and other attendant terms.

Re: Phrases in computing that might need retiring

#223

I was expecting "master" and "slave" to show up since I've seen that argument being made ( https://www.eetimes.com/its-time-for-ieee-to-retire-master-s... ), but I have a hard time taking it seriously. I agree about AI though. The rush to exploit the phrase as a marketing term has killed it's original meaning. Once we actually have AI we're going to need something else to call it. I've always kind of liked the distin…

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.

Re: Phrases in computing that might need retiring

#224
post #124

Earlier quoted context omitted.

It's not one-sided though. Debt is often a very useful tool. You take on debt now because you can do more productive things with the money that will be worth more than the payments you have to make on it later. This is an extremely apt description of technical debt. Often times people will make bad decisions about what debt to take on, and the same is true for technical debt, and often times people will overestimate…

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

Re: Phrases in computing that might need retiring

#225
post #15
post #8

Strong disagree on "technical debt" Rather, the entire world is built on it and there's some level of acceptance required, but we definitely need a shorthand phrase for "we're doing something stupid that will save us time now and make us hate ourselves a year from now" Edit: thinking on it, also "devops". It's really job title for "sysadmin but paid and owned by the software department to keep ITs fingers out of ever…

Right, and "debt" is a beautiful word here. It accurately describes receiving the value today, but then owing that time back, with interest, in the future.

I prefer "tech investment"! It's more positive ;)

Re: Phrases in computing that might need retiring

#226
post #8

Strong disagree on "technical debt" Rather, the entire world is built on it and there's some level of acceptance required, but we definitely need a shorthand phrase for "we're doing something stupid that will save us time now and make us hate ourselves a year from now" Edit: thinking on it, also "devops". It's really job title for "sysadmin but paid and owned by the software department to keep ITs fingers out of ever…

Strong disagree on your strong disagreement.

As the term has been corrupted, it just means "Code that isn't the way I would have done it."

You won't have to fix it a year from now -- you'll just be cursing at having to understand it.

And eventually, management will become convinced that everything has to be thrown out and rewritten; maybe it'll even be true.

Re: Phrases in computing that might need retiring

#227
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 that structs fit this definition but they are missing type dependent namespaces for functions/methods and the fact that you can define fields and methods to only be accessible within their type dependent namespace, not outside of them.

Re: Phrases in computing that might need retiring

#228

Earlier quoted context omitted.

Do you think women and girls don't want everyone's attention to orbit around them ?

For women online in particular I'm pretty sure lots of them would rather enjoy less attention on them personally. Too much it not pleasant for _them_. I'm thinking in particular about friends who are content creators, minding her own business and receive comments on her look, insults, sexist comments, unsolicited dick pics, rape and death threats,... I'm sure sexism has nothing to do with that. OK I'm done on this to…

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?

Re: Phrases in computing that might need retiring

#229
post #7

If this were a comment on HN, I would give it one of my rare downvotes. It's dismissive and negative without any compensating value or positivity. Maybe suggestions of terms to use?

Wait...you took TFA to be entirely serious? Try re-reading the 2nd paragraph.

Re: Phrases in computing that might need retiring

#230
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?

I've observed the same for at least the past 20 years: most people who are working as programmers can't or won't write object-oriented code, nor will they write functional code. For whatever reason, even if they're working in a language like Java that's fundamentally object oriented, they'll write primarily procedural code (mostly static functions accessing datatypes with no functionality besides getters and setters): either they don't understand that there's an alternative, or they see some benefit in it.
Post reply on HN