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.
> 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.
> > The naming grew as our understanding of the function grew.
> That's exactly it! You have accidentally made my point exactly.
No, you just ignored the point I made later about it being contextual.
> > 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.
1. ...but your CRM service does need to know that your spell-checking service is a spell-checking service, and your international logistic program does need to know that your translation service is a translation service.
2. Your spell checking service shouldn't also be a translation service, and your translation service shouldn't also be a spell checking service. If you violate single responsibility principle, then "Play stupid games, win stupid prizes" applies. Naming is the least of your problems in this situation.
> Absolutely spot on. I spent about 30 seconds coming up with "Wordsmith". It does something with words.
Well, maybe until you're better at it, spend more time.
> I agree the word should not be completely divorced from its use.
Then you disagree with the OP.
> 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.
Again, play stupid games, win stupid prizes. If every part of your code depends on every other part of your code, don't do that.
> 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.
Surely what the thing you're calling does is relevant to you?
I think we have very different situations in our mind as we go bath and forth like this. It'd be fun to discuss this further over beer, but I think we've mostly hit the limit of what we can do in a HN thread. I'm picking the one major thing you said that I disagree with most:
> Your spell checking service shouldn't also be a translation service, and your translation service shouldn't also be a spell checking service.
I just want to stress how tremendously inflexible that is, and just how heavy of a decision you have to make any time you implement a new feature. This sounds like all the negatives of microservices (or DLL hell if that's your deployment model) with none of the positives. Boundaries are fuzzy! I have written a spell checker before. Later I needed an auto-complete service. Turns out: serendipity! I could implement auto-complete easily by simply implementing a separate error model that didn't take off points for "deletion errors" at the end of the word. And as a bonus, it was "fuzzy", so if you typed "Arnold Shwarz" it would suggest Schwarzenegger even though you missed the 'c'. The difference between the Spell Checking Service and the Fuzzy Autocomplete Service was one class of about 10 lines.
If you immediately set out with the mindset "your spell checking service shouldn't also be an autocomplete service" as if this is some sort of wisdom (it really, truly isn't), then you're hamstringing yourself from getting these kinds of easy wins. And maybe you decide autocomplete is close enough to spell-checking to warrant being in the same service, but your colleague might not, so now you needlessly argue over it. It shouldn't be a big decision! Just write it! So auto-complete goes in the service, but it's really close to feature X, which involves vectorizing words, which is the basis for a translation service. Now your spell checker is also a translation service. But what have we really lost? Who gives a crap that Wordsmith now has an extra feature? Nobody who was using its old features; they don't have to change at all.
> > I spent about 30 seconds coming up with "Wordsmith". It does something with words.
> Well, maybe until you're better at it, spend more time.
Needlessly nasty. Maybe I don't want to have a beer with you after all. Come on Wordsmith, I think you're beautiful just the way you are.
> If you immediately set out with the mindset "your spell checking service shouldn't also be an autocomplete service" as if this is some sort of wisdom (it really, truly isn't), then you're hamstringing yourself from getting these kinds of easy wins.
It's not "immediately setting out with a mindset", it's looking back on coming-up-on-2-decades of software development experience and noting that every time I think bolting a second responsibility onto a unit is an easy win, that decision comes back to bite me. It seems like an easy win now, but everything you change in that area of the code from now on needs to consider two different, disparate responsibilities it needs to maintain.
If you're seeing this as an easy win, it's likely that your software didn't see much use that played out the problems, or you didn't stick around long enough to see the problems arise, or someone else did the work to fix it and just didn't tell you.
> Nobody who was using its old features; they don't have to change at all.
Not yet, but if you assume they'll never have to change, you're going to have a bad time.
What's the longest you've ever worked on a codebase? Have you ever been the sole developer on a large codebase, where you had to pay for your own mistakes?
> Needlessly nasty. Maybe I don't want to have a beer with you after all
I don't think it was nasty at all. If you'd spent more than 30s on it you'd know that "wordsmith" already means "a skilled writer" and thus doesn't match the function of the tool you are describing. Names that appear to describe the function of a thing but don't are IMHO, the one of the worst kinds of bad names. You're better off with something that is either completely divorced from the underlying functionality or describes it correctly.
> 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.