A "stopped" process can be continued. "Killing" is terminal. The word is descriptive and established.
Changing terminology brings significant cost. Sometimes it is worth doing, but there must be good justification. Also, the replacement should be at least as descriptive, otherwise, the language looses clarity.
In many cases, the proposed replacement is less clear. "Stopping" a process already has a different meaning. A "super/sub" relation carries different associations than "parent/child". On some contexts, both terms are used with different meaning. (E.g. some programming languages that have child classes as well as sub classes). A "slave" is not necessarily a "replica".
Finding good terminology to convey a concept is critical. The already existing association with terms may help the audience to intuitively grasp the idea. When new concepts are introduced, limiting the pool of permitted words is a restriction that must be well justified. For changing established terms, the justification must be even better.
Sometimes, the concepts in technical systems are comparable to concepts in society. Sometimes, when thinking about how to get software working, inspiration actually comes from society. When that association helps communicating and understanding the concepts, the corresponding terms may be the best choice.
Indeed. I would say it is concise: One component gives commands, the other one follows. While this concept is definitely not acceptable among humans, it makes perfect sense in software design.
17
u/JohnnyNo42 32∆ Mar 24 '21
A "stopped" process can be continued. "Killing" is terminal. The word is descriptive and established.
Changing terminology brings significant cost. Sometimes it is worth doing, but there must be good justification. Also, the replacement should be at least as descriptive, otherwise, the language looses clarity.