Node: Replace abort as a verb

Created on 16 May 2019  Ā·  15Comments  Ā·  Source: nodejs/node

Hello my fellow humans!

I've started to notice that the usage of the word abort in the process API can be a bit triggering, why don't we change it to something less harsh like halt or stop?

discuss

Most helpful comment

Just a friendly note that as this is a discussion that touches on issues of language, inclusion, and sensitive topics, @nodejs/moderation is keeping an eye on this conversation. I'm assuming that everyone involved will remember that these conversations work best when everybody engages in good faith, and also remembers that there are significant technical and policy reasons, as @addaleax describes, why changes like this may take a while and require an unusually high degree of deliberation. Thanks for your goodwill and patience!

All 15 comments

I’m not sure that we can entirely remove this kind of terminology – names specified in POSIX like SIGABRT or the C abort() function are provided by the operating system, not by us.

That being said, I wouldn’t mind thinking about what alternatives we could use, and maybe introduce as aliases (I don’t think removing the abort-style terminology is an option, out of backwards compatibility). We use abort in a few places in the public API, namely process.abort() and --abort-on-uncaught-exception, both referring to a SIGABRT-style hard crash, and request.abort() in HTTP.

I don’t think halt or stop would be ideal as alternatives for the first two, because I think a lot of people would perceive those as referring to ā€œsofterā€ process exits and not intuitively expect them to refer to hard crashes. terminate might be okay there? For HTTP, request.stop() sounds accurate and intuitive enough to me.

perhaps cancel or terminate? "stop" sounds like a graceful process imo

Just a friendly note that as this is a discussion that touches on issues of language, inclusion, and sensitive topics, @nodejs/moderation is keeping an eye on this conversation. I'm assuming that everyone involved will remember that these conversations work best when everybody engages in good faith, and also remembers that there are significant technical and policy reasons, as @addaleax describes, why changes like this may take a while and require an unusually high degree of deliberation. Thanks for your goodwill and patience!

It is even more dumb idea than replacing "f*ck" in comments inside Linux' sources with "hug". Absolutely no reasons to do this

@Antonius-S There are plenty of reasons to consider this change, including those stated by the OP. What isn’t clear is whether there’s a path to making those changes that is smooth (or justified) enough to merit the effort, disruption, and loss of a clear relationship between UNIX terminology and that used by Node. As a point of order, similar changes to address problematic word choices have been landed by the project in the past. Flatly stating there’s no merit to the proposal isn’t constructive. Are there concrete concerns you have?

@othiym23 I see completely no reason in doing this change. Maybe cause I'm not native speaker. Maybe someone could explain what's wrong with abort? Probably next step will be to replace kill with force close or daemon with foreground process?

@Antonius-S the key is interacting in good faith and moving the project forward. Someone opened an issue about terminology they don't like. It's fine to discuss this and it's fine to weigh the pros and cons.

To be fair I think "kill" to send a signal is terrible terminology (it's not what we're saying and it's literally to bring death) and we're just used to it at this point.

I don't think abort is likely to go away, mostly because:

  • Most its usage is completely is correct and not insensitive in context (unlike suicide which was removed for example from the API).
  • abort is used in *nixes like kill and it's a system call.
  • AbortController is the DOM API for aborting web requests (a relatively new API) and we might want to adopt that for web compatibility.

That said, I think discussing it is fine and in other cases it makes a lot of sense to change terminology where it is inappropriate - for example in the case of suicide which was removed from the cluster API (because it was both confusing and insensitive).

Proposing changes and discussing them is fine, but initiating changes without reasonable arguments is not (IMHO). Here I see just a very personal negative position towards a classic term (next will be to ask MS rename corresponding button on MessageBox to something less harsh?) ĀÆ_(惄)_/ĀÆ
Sorry for probably being hard but that story with Linux sources touched me too much. People were wasting efforts on useless word games instead of writing code.

People were wasting efforts on useless word games instead of writing code.

Not to sound too harsh, but unless it’s work that you’re doing yourself or paying somebody else to do, you kind of just have to live with the fact that other people’s priorities may not fully align with your own. In the past, Node.js collaborators have also on occasion decided to remove words that may be considered inappropriate in a professional context from its code base, like Linux did – it’s something that some people felt was important, and then did, because they wanted to spend their time doing it, and didn’t really affect anybody else.

That being said, I think this is not the place for a meta discussion about which kind of discussions we should have – it’s about one very specific piece of terminology, and imo it’s quite different from the Linux example, because this is about public APIs rather than internals and comments. (We do use the word abort in comments as well, but that’s changed rather easily.)

I think one thing that’s important to look at here is that, unlike in the suicide case mentioned by @benjamingr, we are unlikely to fully remove any of the instances of abort in our API naming out of backwards compatibility concerns.

We could rename these, and make abort an alias, but we would likely still have to provide some kind of documentation on these aliases indefinitely. I think I am in favour of doing this at least for request.abort(), because it doesn’t refer to standard terminology and cancel would seem like a word that fits just as well or even better; But still wanting to document the existence of the aliases while at the same time wanting to avoid the terminology seems like a hard problem that I don’t have a good solution for.

To my knowledge, abort has a specific meaning for *nix-s, meaning 'terminate and dump core'. Although, it is possible I am wrong, and that is only a meaning specific to Node.js.

Certainly, the "abort" methods in node, do exactly that, to my knowledge.

I've started to notice that the usage of the word abort in the process API can be a bit triggering

Did you notice this before or after recent events in the USA? I am probably wrong, but I cannot remember this concern being raised before, and Googling it does not seem to give anything.

English is a widely spoken language with rich local variations, and the open source community is much, much bigger than the USA.
I respect that there are people who may be triggered by the word abort, and they should be taken seriously. The word, however, has many meanings in different contexts and cultures and does not primarily relate to the termination of a pregnancy (which I just assume is what you mean people could find triggering, please correct me if I am reading too much into it).

Different cultures and people could see the meaning of the word very differently, isn't this giving an American (or at least western) minority understanding of it precedence over all others?

Comparisons to other words like "f!!k" really do not hold water since these words have clearly offensive and derogatory connotations.

@Fishrock123 As mentioned above – the C abort() function is standardized in the way you describe (except for not necessarily creating a core dump). request.abort() in the HTTP API is specific to Node.js.

Some dictionary history search shows this as being taken from the aviation term, which had its first know use in 1944, where it is now (to my knowledge) widely used. It specified as 'terminate prematurely', as so 'terminate' may not be an adequate one-word replacement. Source: https://www.merriam-webster.com/dictionary/abort

If it is used appropriately to its meaning I don't think this should be a problem for us. We certainly didn't adopt it and this meaning of it has solidified pretty well in english by now. My 2c, anyways.

@addaleax I'm not native English speaker, and i learned most of words from books, games and web.

abort as i understand it, means that the job is stopped leaving everything else "as is" at that moment. Actually, first thing that comes to my mind, when i hear the word is: "abort the mission!" that's used in A LOT of movies and games. Second one is learned from various APIs/frameworks/etc...

cancel usually means going back to state "zero", more or less (i would assume that cancel lets server know, that we want to go back to previous state). Aborting request, may leave server side in a "broken" state (depending on how that server will understand dropped connection), so, as i see it, abort is much better name for the method that "drops all data and destroys socket right away" (as it is described at https://nodejs.org/dist/latest-v12.x/docs/api/http.html#http_request_abort).

See https://www.merriam-webster.com/dictionary/cancel too.

Hey, since discussion has stalled on this I am going to go ahead and close this issue.

If anyone feels strongly about this staying open or would like to continue discussing this please feel free to reopen and revisit this.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

danielstaleiny picture danielstaleiny  Ā·  3Comments

stevenvachon picture stevenvachon  Ā·  3Comments

Icemic picture Icemic  Ā·  3Comments

fanjunzhi picture fanjunzhi  Ā·  3Comments

seishun picture seishun  Ā·  3Comments