> See, the scope and purpose of something changes faster than its name can.
There's your problem. Create libraries that aim to do one thing and do it well. Once you release your project and have users that depend on your code, you owe it to them to maintain it in the original scope. If you have an urge to change your project's scope so much that the name should change, create a new library with a better name instead.
p.s. Obviously does not apply to brand names, which need to be distinctive.
> Create libraries that aim to do one thing and do it well.
That's nice and all, but once you combine that with giving them descriptive names, you're going to have a list of hard-to-distinguish projects like:
- css-min
- css-polyfill
- css-inline-min
- css-inline-polyfill
- css-script-min
- css-script-polyfill
- etc.
Good luck clarifying what you're talking about. And of course, people will start using acronyms for all of them, and now you're back at cryptical names, with the added benefit of all the names sounding and looking similar. Or, of course, have inaccurate or inconsistent names.
And then I didn't even get to the part where your categorisation turns out to not match the eventual scope, and they'll need to be split into css-server-min, css-client-min, etc.
And then someone makes a package to combine all of them, and then someone makes a package that combines that combining package with another combining package, and then the author of `css-script-polyfill` deletes the repo, and we're dealing with another leftpad
I can't be the only one that just includes any dependency with a permissive license? `git subtree` is so ridiculously easy for the larger dependencies and 90% of these projects are sub-500 lines in a single file, just include them.
> you're going to have a list of hard-to-distinguish projects like:
What's hard to distinguish? These are projects that do something with CSS. If you don't need css, you skip them. If you need a polyfill, you only look at polyfill ones to see what you need.
Now, let's imagine your list is "creatively" named like
- shelob
- arcana
- custard
- escalope
- virtuocsso
- jester-css
- etc.
Ah yes, this is so much easier to distinguish, isn't it?
They're hard to distinguish in the sense that a colleague might ask something like "hey can you publish a new version of css-script-min" and you accidentally publish a new version of "css-min" or "css-inline-min" or whatever instead.
A name is usually not enough to determine which library/framework is best for you. This is the _illusion of transparency_ that the author talks about. How would you rename React and Angular such that developers could tell at a glance which one to use? If it's going to require further investigation from the user's part, better to give the project an opaque name to make it clear that further investigation is necessary.
Also comes back to the thing of "products end up modelling the organisational structure".
If it's painless to create new internal products within your company & there is operational support for it, you're more likely to spin up a sister "EmailNotificationService" alongside "SmsNotificationService".
If you have to jump through hoops to get sign-off and business cases etc and eitherways it's the same team responsible for both, people are more likely to say "let's just put the functionality in here"
> Create libraries that aim to do one thing and do it well.
This is a thing people like to repeat over and over again, but just really isn't actionable. The world is very high dimensional, it's always a judgement call what to cluster together and call "one thing". Especially in software where everything is made up and is constantly changing.
People often like to refer to things like unix tools etc as doing one thing and doing it well, but all those tools have grown a ton of command line args, and have backwards compatibility issues that prevent them from doing their job "well" in the modern era. So people write new tools or just hardcodes a ton of command line flags into aliases by default. Many default settings on unix tools are awful. Why does grep not use regex by default? Why doesn't echo support newline escapes by default? Which tools use color by default?
Reality is a mess, and it's an illusion that you can do "one thing"
Aim is the problem here. Many projects are built and maintained by people who have a use case.
It may well fit that use case to add one extra feature to the library rather than creating a new library.
I suspect that many of the examples provided (such as the Django project) evolved over time. It can also often be the case that once an implementation is done it becomes obvious that it actually does something very different to what you originally set out to do.
In theory, it makes sense that you would just create a new library with a better name, but if the original product has been on GitHub long enough to have amassed followers and a significant number of stars, they may be hesitant to have to ask those contributors to re-add the new repo.
Exactly. Don't just cram functionality into the closest thing at hand without any thought and you won't have to worry about scope creep ruining the name of that thing.
If you want to make new and different things, just do that.
There's your problem. Create libraries that aim to do one thing and do it well. Once you release your project and have users that depend on your code, you owe it to them to maintain it in the original scope. If you have an urge to change your project's scope so much that the name should change, create a new library with a better name instead.
p.s. Obviously does not apply to brand names, which need to be distinctive.
p.p.s. Rich Hickey talks about this here: https://www.youtube.com/watch?v=oyLBGkS5ICk