In functional programming most variable names are single letters, except for function names, they are either name of spices or animal parts.
Software component names should be whimsical and cryptic
281–290 of 339 posts
Re: Software component names should be whimsical and cryptic
#282The author seems to be talking about names for two totally different things, lumping them under the term "component." Whimsical project name? No problem. Whimsical type name within a project? Really bad idea. Whimsical variable name? Don't even think about it. The concept the author is missing is "convention." Whimsical project names fall within a well-understood and used convention. The convention for type and varia…
My 8 year old son names all variables after his friends.
Re: Software component names should be whimsical and cryptic
#283Earlier quoted context omitted.
It's _A_ truth, but it's a truth that is inextricably intertwined with a certain context. If your software components are services running in the backend of a large web service company, then their purpose is likely to mutate as time goes on. In that paradigm, I totally believe it tends to be true that you're better off giving up from the beginning and just choosing unique names from the get-go. Your system is more li…
I'm saying it's not just webservice monoculture. It predates the web . Which is a better name, MS-DOS or Linux? BCPL or Perl? Source Code Control System (SCCS) or Git? If a name is going to last a long time, and face a lot of different people, and have lots of relationships and sub-names of its own (e.g. "github"), then it's far better that it be short, unique, and memorable than that it be descriptive. There's nothi…
Maybe we're getting into semantics, but you're listing the names of full software products or outward-facing open-source projects. The world is rarely coordinating to refactor responsibilities between different software products, since now you're talking about trading functionality across company / organization lines. At that level, I'd definitely agree that software is clearly a bazaar, and a whimsical, cryptic name is at its best.
"Software component" has the connotation, to me at least, of being an inward-facing _piece_ of one of these products. It is but one component of a system, and thus it is to be understood by its function within that system.
I think in many domains, the best advice is to name those components helpfully, and to think about the component's role in the system. To start adding functionality to the component outside the scope of its name is to invalidate your design. There is no reason to bloat this component. You'd rather create a new component to handle the previously overlooked role in the system. This is made obvious when you take limiting cases, like designing a moon lander. Here, the software design must be purposeful and optimized, and it only needs to work once. In the opposite case, the component is a web microservice - a living thing managed by a 1-pizza team that always needs to be turned on. Uptime and speed of implementation are at a premium, and creative ways to add new functionality on existing systems are seen as a net good. Here, the article's advice might be good.
Re: Software component names should be whimsical and cryptic
#284As someone who's working on a project right now that's full of whimsical/cryptic names (project is called Sandman, modules within the project include Mystic, Hypnos, Lethe, Morpheus, Dreamer, and Lucid), this was validating to read. That said, if my project was anything more than a solo personal project, I'd only keep the Sandman top-level name and rename the modules to things like Parser, Server, Client, etc. to make them more maintainable by others. I keep them because I'm the only one working on the project and I quite enjoy the sense of Hollywood-hacker-montage they impart me when I'm debugging.
Re: Software component names should be whimsical and cryptic
#285This satirical video about microservices shows just how deep whimsical project names (and microservice architectures) can go. Displaying the user’s birthdate starts with BINGO (the service that knows everyone’s name-o) and ends with GALACTUS (the all-knowing user service provider aggregator) talking to EKS (Entropy Khaos Service), soon to be EOL’d by OMEGA STAR.
Re: Software component names should be whimsical and cryptic
#286Earlier quoted context omitted.
The tone of your post is unnecessary and not helpful to your point. I don't agree with the authors point but I can say that without being insulting or snarky. In spite of that, when did "making a database product" count as not "hard?" Building a database isn't "real software engineering™?" Since when was building "authorization microservices" easy? In the simplest case, sure. But authorization in general is a huge pr…
On the contrary, I assume making decentralized database products is very hard. And I don't doubt that authorization is a whole can of worms. My point is not that they're easy, but that they're the type of problems you are most likely to care about if you're building a web service. A web service. Not a moon rocket, or an MRI machine, or high frequency trading software, or computation fluid dynamics simulations, or a c…
When it comes to rockets, whimsical names seem to be much more popular. Most of them are named after mythical figures with SLS being a notable exception.
Re: Software component names should be whimsical and cryptic
#287There is this one man. He is great at marketing, and he once summed it up in just two sentences, but it's because he is so shockingly vain, vapid, and shallow that he is a genius at this art. "I try to step back and remember my first shallow reaction. The day I realized it can be smart to be shallow was, for me, a deep experience." I am not going to tell you who this is, but the point stands. The name should be easy…
I suppose "Lemonade" the insurance company is a good example of this.
Re: Software component names should be whimsical and cryptic
#288This is bullshit. I don't want dopamine hits. I want money for my code. And guess what increases the money I get from my code? Naming stuff consistently with their meaning.
Re: Software component names should be whimsical and cryptic
#289Earlier quoted context omitted.
I'm saying it's not just webservice monoculture. It predates the web . Which is a better name, MS-DOS or Linux? BCPL or Perl? Source Code Control System (SCCS) or Git? If a name is going to last a long time, and face a lot of different people, and have lots of relationships and sub-names of its own (e.g. "github"), then it's far better that it be short, unique, and memorable than that it be descriptive. There's nothi…
Maybe we're getting into semantics, but you're listing the names of full software products or outward-facing open-source projects. The world is rarely coordinating to refactor responsibilities between different software products, since now you're talking about trading functionality across company / organization lines. At that level, I'd definitely agree that software is clearly a bazaar, and a whimsical, cryptic name…
Moon landers all get names. Even moon landers that never made it past the design phase probably had codenames.
You've stumbled on yet another situation where you should give something a cute name instead of a descriptive name: If there will be many implementations of the same thing over time. Each generation of Intel processor, each sort algorithm (TimSort, thanks Tim), each rocket, each mid-sized sedan.
Now, do the individual software components within a moon lander get names? That depends! Are they re-used between landers? Are there many different implementations of the same component to choose from for each mission? The more affirmative the answers to these questions, the more likely it is the component will have/should have an actual name, instead of just being, say, "allocator.c".
There are just so many reasons you might want something to have an actual name. Competing implementations or historical implementations, userbase size, project longevity, researchability. And they're all subject to change in the future (and renaming sucks). I have a hard time faulting anybody for giving their little binary data format a name like "parquet", even if it's tiny and only used in one place by one other thing and might never have any users. Because it might end up used for a long time, or by many people, or in a period of competition with another implementation of the same thing. If any of those things comes true, you're going to be glad you didn't name it "Hierarchical Data Format".
Re: Software component names should be whimsical and cryptic
#290Author used to build authorization microservices, and now works at a company making a database product. Once again, somebody who works on some web service bs assumes that that's as hard as the world gets. If all of your software components are constantly changing their scope, it indicates you are doing a bad job of producing an up-front system design. If your experience causes you to scoff at the concept of producing…
Please don't cross into personal attack. Also, please don't fulminate in HN comments. https://news.ycombinator.com/newsguidelines.html
Isn't describing this comment as "fulmination" snarky, which is itself a violation of the guidelines? It's at least a shallow dismissal of their opinion, for sure.
How can you expect people to follow these rules when you yourself don't? Looking at your history, you[0] leave[1] comments[2] like[3] this[4] (shallow dismissals at best, and snark at worse) pretty[5] consistently[6]. What gives?
[0] https://news.ycombinator.com/item?id=32808611
[1] https://news.ycombinator.com/item?id=32807734
[2] https://news.ycombinator.com/item?id=32803087
[3] https://news.ycombinator.com/item?id=32799206
[4] https://news.ycombinator.com/item?id=32798437