3 ms·

Early chemists gave cutesy names to chemicals, like "vitriol", "salt", and "cholesterol". Today we know the proper descriptive names for these substances, of co

by feoren 4y ago

Early chemists gave cutesy names to chemicals, like "vitriol", "salt", and "cholesterol". Today we know the proper descriptive names for these substances, of course. Vitriol's correct name is "sulfuric acid". Salt's correct name is "sodium chloride" Cholesterol's correct name is "(1R,3aS,3bS,7S,9aR,9bS,11aR)-9a,11a-Dimethyl-1-[(2R)-6-methylheptan-2-yl]-2,3,3a,3b,4,6,7,8,9,9a,9b,10,11,11a-tetradecahydro-1H-cyclopenta[a]phenanthren-7-ol". That's not a name! It's a serialization of a molecular structure! See, the problem is that what's "descriptive" is opinionated, and a hot topic for bikeshedding. It's like the argument between natural and artificial primary keys. If you go with natural primary keys, expect managers to bikeshed exactly what's in there and how it should be encoded. They'll change all the time. Your "name" turns into an encoding of the object itself. If you call your computer "OaklandDev19InTheBasement" then what happens if you move? What happens if you get more than 100 dev computers in the Oakland basement? How many arguments are you going to have about whether it's the proper place to put some service that may not be "devvy" enough? Some people are hitting this, but most of these can be broken into different functions: Identity: always meaningless, always. Finding a service: if this is hard, you need a directory. You need this anyway, even with descriptive names. If you need a directory, can you automate it?

shkkmo 4y ago
Of the three you mention, only "cholesterol" was actually named by an early chemist [0]. "Oil of vitriol" was first mentioned by an alchemist almost 1000 years ago but the term "vitriol" already existed to refer to some metal sulfates. "Salt" is much much older. [0] https://en.wikipedia.org/wiki/Michel_Eug%C3%A8ne_Chevreul https://en.wikipedia.org/wiki/Michel_Eug%C3%A8ne_Chevreul
- feoren 4y ago
  > first mentioned by an alchemist I was really hoping we'd all be mature enough to not have this petty argument over when people studying the properties of chemicals stopped being called "alchemists" and started being called "chemists". What year was that, exactly? Exactly. I need an exact year, so I don't make this "mistake" again, please. Because otherwise, I think "early chemists" is a perfectly accurate description of early humans studying the properties of chemicals.
  - whatshisface 4y ago
    The transition was gradual but did happen, and on one side you had a lot of pseudo-religious beliefs and on the other you had experimentation and the scientific method.
    - feoren 4y ago
      And this distinction is important enough to you that you'd like everyone who refers to pre-20th century humans who studied the properties of chemicals as "early chemists/alchemists", and if they don't, you're going to correct them? Even if it's irrelevant to their main point? That's the discourse we want on here? Everyone had pseudo-religious beliefs back then! Can we not talk about "early astronomers" who were studying the movements of stars and planets, if they also believed in other weird shit? Who cares if they were studying the stars in order to sacrifice goats at better times?
      - shkkmo 4y ago
        > you'd like everyone who refers to pre-20th century humans who studied the properties of chemicals as "early chemists/alchemists", "Alchemist" has a specific meaning, and it is not synonymous with "early chemist". Robert Boyle was clearly an early chemist and predates Isaac Newton, who was an alchemist. There is no temporal hard line in the sand, the distinction is made based on methodology and goals. The two terms aren't necessarily mutual exclusive (as with the astronomy / astrology distinction you allude to), but that doesn't mean you can conflate them. > Everyone had pseudo-religious beliefs back then! Perhaps, but that doesn't mean there aren't relevant distinctions to be made about their beliefs and methodologies. While this distinction is important, it is also irrelevant to my main point. "Vitriol" predates that alchemist and is arguably more of a word that arose than a name that was given.
serverholic 4y ago
Even if it’s imperfect, a descriptive name is quite nice because at least it gives you a hint as to what the service does. I find the comparison to cholesterol to be a bit ridiculous. Your argument seems like a case of “well technically this strategy is imperfect so we shouldn’t even try.”
kerkeslager 4y ago
There are so many straw man arguments in this post it's hard to play them apart. > Early chemists gave cutesy names to chemicals, like "vitriol", "salt", and "cholesterol". Today we know the proper descriptive names for these substances, of course. That's not what happened, and nobody is saying that the chemical serialization is the "correct" name. The reality is that originally we didn't know the internal structure of these chemicals or understand how they functioned: referring to something as an acid didn't matter because we didn't understand how acids worked. The naming grew as our understanding of the function grew. But, critically, the old names are still useful in some contexts, because the chemicals serve different functions in different contexts. Nutritionists don't necessarily need to know that Vitamin C is an acid, and they certainly don't need to know the exact chemical structure of cholesterol. In fact, it's telling that your chemical structure actually is just one form of cholesterol, because cholesterol is a group of chemicals, not one chemical. More fundamentally, naming the structures of chemicals is different from naming services, because chemicals don't change. Sulfuric acid will always be H2SO4, and it will always react the same given the same conditions. That's not true of services. > See, the problem is that what's "descriptive" is opinionated, and a hot topic for bikeshedding. Sure... but the answer is just "don't do that". If you spend 30 hours a week arguing over whether something is a "adapter" or a "converter" that's a waste of time, because those terms are both pretty similar. No one is saying that's a good idea. That doesn't mean that we should just throw up our hands and name the object "SamuelLJackson", it means we should give things the most descriptive name we can come up with in, say, 30 seconds. Which, for something that changes objects from one format to another, isn't SamuelLJackson. Part of the problem I'm seeing here is that people seem to be concerned that name changes are a waste of time. That's true to some extent, but having to figure out what a poorly-named entity does is a much larger waste of time. And if it isn't, I have to ask, why is changing names taking so long? Perhaps it's a lack of tests? Poor editor tooling? Whatever it is, fix whatever is making your names hard to change, don't give up on descriptive names.
- feoren 4y ago
  > The naming grew as our understanding of the function grew. Yes! That's exactly it! You have accidentally made my point exactly. The name grows as the understanding of the function grows. And your understanding of what a given service or application should be doing is always growing and changing over time. So if your name is an encoding of the function, it will constantly change and grow, until it's as ugly and useless as Cholesterol's "true" name. > Nutritionists don't necessarily need to know that Vitamin C is an acid, and they certainly don't need to know the exact chemical structure of cholesterol. Yes! That's exactly it! Your CRM program doesn't need to know that your spell-checking service is also a translation service, and your international logistic program doesn't need to know that your translation service is also a spell-checking service. So the name "TextCheckerTranslator" is partially irrelevant to both. And what happens when you add a third function to it? It now can also do OCR. So now your CRM program, which only cares about the "checker" part, needs to be re-compiled or have its config changed because it now needs to call the "TextCheckerTranslatorOCR" service instead. Every downstream service has to be changed because of changes that have nothing to do with them! Just call it "Wordsmith". > More fundamentally, naming the structures of chemicals is different from naming services, because chemicals don't change. Sulfuric acid will always be H2SO4, and it will always react the same given the same conditions. That's not true of services. Our understanding of chemicals changes, just like our understanding of which services should do what (and what that means) changes. But either way, if services are more likely to change, then all the more reason to use artificial names for them (rather than trying to encode all their purposes). > Sure... but the answer is just "don't do that". If you spend 30 hours a week arguing over whether something is a "adapter" or a "converter" that's a waste of time, because those terms are both pretty similar. No one is saying that's a good idea. That doesn't mean that we should just throw up our hands and name the object "SamuelLJackson", it means we should give things the most descriptive name we can come up with in, say, 30 seconds. Which, for something that changes objects from one format to another, isn't SamuelLJackson. Absolutely spot on. I spent about 30 seconds coming up with "Wordsmith". It does something with words. I agree the word should not be completely divorced from its use. SamuelLJackson would be a good name for a service which takes boring text and liberally inserts creative swear words into it. > Part of the problem I'm seeing here is that people seem to be concerned that name changes are a waste of time. We all treat "hiding details" important in code. If every part of my code depends on every other part of my code, then one change will mean 100 changes. The answer isn't "well, just make sure those 100 changes are super fast, and ignore the constant thrashing in your git history". The answer is standard programming practice of sharing only the details that are relevant to others.

by feoren 4y ago

shkkmo 4y ago

Of the three you mention, only "cholesterol" was actually named by an early chemist [0]. "Oil of vitriol" was first mentioned by an alchemist almost 1000 years ago but the term "vitriol" already existed to refer to some metal sulfates. "Salt" is much much older. [0] https://en.wikipedia.org/wiki/Michel_Eug%C3%A8ne_Chevreul https://en.wikipedia.org/wiki/Michel_Eug%C3%A8ne_Chevreul

feoren 4y ago
> first mentioned by an alchemist I was really hoping we'd all be mature enough to not have this petty argument over when people studying the properties of chemicals stopped being called "alchemists" and started being called "chemists". What year was that, exactly? Exactly. I need an exact year, so I don't make this "mistake" again, please. Because otherwise, I think "early chemists" is a perfectly accurate description of early humans studying the properties of chemicals.
- whatshisface 4y ago
  The transition was gradual but did happen, and on one side you had a lot of pseudo-religious beliefs and on the other you had experimentation and the scientific method.
  - feoren 4y ago
    And this distinction is important enough to you that you'd like everyone who refers to pre-20th century humans who studied the properties of chemicals as "early chemists/alchemists", and if they don't, you're going to correct them? Even if it's irrelevant to their main point? That's the discourse we want on here? Everyone had pseudo-religious beliefs back then! Can we not talk about "early astronomers" who were studying the movements of stars and planets, if they also believed in other weird shit? Who cares if they were studying the stars in order to sacrifice goats at better times?
    - shkkmo 4y ago
      > you'd like everyone who refers to pre-20th century humans who studied the properties of chemicals as "early chemists/alchemists", "Alchemist" has a specific meaning, and it is not synonymous with "early chemist". Robert Boyle was clearly an early chemist and predates Isaac Newton, who was an alchemist. There is no temporal hard line in the sand, the distinction is made based on methodology and goals. The two terms aren't necessarily mutual exclusive (as with the astronomy / astrology distinction you allude to), but that doesn't mean you can conflate them. > Everyone had pseudo-religious beliefs back then! Perhaps, but that doesn't mean there aren't relevant distinctions to be made about their beliefs and methodologies. While this distinction is important, it is also irrelevant to my main point. "Vitriol" predates that alchemist and is arguably more of a word that arose than a name that was given.

serverholic 4y ago

Even if it’s imperfect, a descriptive name is quite nice because at least it gives you a hint as to what the service does. I find the comparison to cholesterol to be a bit ridiculous. Your argument seems like a case of “well technically this strategy is imperfect so we shouldn’t even try.”

kerkeslager 4y ago

There are so many straw man arguments in this post it's hard to play them apart. > Early chemists gave cutesy names to chemicals, like "vitriol", "salt", and "cholesterol". Today we know the proper descriptive names for these substances, of course. That's not what happened, and nobody is saying that the chemical serialization is the "correct" name. The reality is that originally we didn't know the internal structure of these chemicals or understand how they functioned: referring to something as an acid didn't matter because we didn't understand how acids worked. The naming grew as our understanding of the function grew. But, critically, the old names are still useful in some contexts, because the chemicals serve different functions in different contexts. Nutritionists don't necessarily need to know that Vitamin C is an acid, and they certainly don't need to know the exact chemical structure of cholesterol. In fact, it's telling that your chemical structure actually is just one form of cholesterol, because cholesterol is a group of chemicals, not one chemical. More fundamentally, naming the structures of chemicals is different from naming services, because chemicals don't change. Sulfuric acid will always be H2SO4, and it will always react the same given the same conditions. That's not true of services. > See, the problem is that what's "descriptive" is opinionated, and a hot topic for bikeshedding. Sure... but the answer is just "don't do that". If you spend 30 hours a week arguing over whether something is a "adapter" or a "converter" that's a waste of time, because those terms are both pretty similar. No one is saying that's a good idea. That doesn't mean that we should just throw up our hands and name the object "SamuelLJackson", it means we should give things the most descriptive name we can come up with in, say, 30 seconds. Which, for something that changes objects from one format to another, isn't SamuelLJackson. Part of the problem I'm seeing here is that people seem to be concerned that name changes are a waste of time. That's true to some extent, but having to figure out what a poorly-named entity does is a much larger waste of time. And if it isn't, I have to ask, why is changing names taking so long? Perhaps it's a lack of tests? Poor editor tooling? Whatever it is, fix whatever is making your names hard to change, don't give up on descriptive names.

feoren 4y ago
> The naming grew as our understanding of the function grew. Yes! That's exactly it! You have accidentally made my point exactly. The name grows as the understanding of the function grows. And your understanding of what a given service or application should be doing is always growing and changing over time. So if your name is an encoding of the function, it will constantly change and grow, until it's as ugly and useless as Cholesterol's "true" name. > Nutritionists don't necessarily need to know that Vitamin C is an acid, and they certainly don't need to know the exact chemical structure of cholesterol. Yes! That's exactly it! Your CRM program doesn't need to know that your spell-checking service is also a translation service, and your international logistic program doesn't need to know that your translation service is also a spell-checking service. So the name "TextCheckerTranslator" is partially irrelevant to both. And what happens when you add a third function to it? It now can also do OCR. So now your CRM program, which only cares about the "checker" part, needs to be re-compiled or have its config changed because it now needs to call the "TextCheckerTranslatorOCR" service instead. Every downstream service has to be changed because of changes that have nothing to do with them! Just call it "Wordsmith". > More fundamentally, naming the structures of chemicals is different from naming services, because chemicals don't change. Sulfuric acid will always be H2SO4, and it will always react the same given the same conditions. That's not true of services. Our understanding of chemicals changes, just like our understanding of which services should do what (and what that means) changes. But either way, if services are more likely to change, then all the more reason to use artificial names for them (rather than trying to encode all their purposes). > Sure... but the answer is just "don't do that". If you spend 30 hours a week arguing over whether something is a "adapter" or a "converter" that's a waste of time, because those terms are both pretty similar. No one is saying that's a good idea. That doesn't mean that we should just throw up our hands and name the object "SamuelLJackson", it means we should give things the most descriptive name we can come up with in, say, 30 seconds. Which, for something that changes objects from one format to another, isn't SamuelLJackson. Absolutely spot on. I spent about 30 seconds coming up with "Wordsmith". It does something with words. I agree the word should not be completely divorced from its use. SamuelLJackson would be a good name for a service which takes boring text and liberally inserts creative swear words into it. > Part of the problem I'm seeing here is that people seem to be concerned that name changes are a waste of time. We all treat "hiding details" important in code. If every part of my code depends on every other part of my code, then one change will mean 100 changes. The answer isn't "well, just make sure those 100 changes are super fast, and ignore the constant thrashing in your git history". The answer is standard programming practice of sharing only the details that are relevant to others.