Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programmers and software developers lost the plot on naming their tools

lr0.org

Post reply on HN
Print view View original

11–20 of 563 posts

Re: Programmers and software developers lost the plot on naming their tools

#11

Post by lr0 »

the__alchemist wrote: post #7

If the community followed the author's guidance, we would have names like "Generic LLM wrapper 690" ("GLW690" if following the early programming language conventions.) or "Github clone with a different ideology 11"

Not at all. You don't name by category, you can name by function or approach. PostgreSQL isn't "Generic SQL Database 47" it's the successor to Ingres (Post-Ingres-SQL). If your "LLM wrapper" does nothing distinctive worth naming, maybe don't publish it. But if it specifically handles streaming, call it something like "llm-stream-client." If it focuses on prompt templating, "prompt-template-engine." The name encodes the actual value proposition.

I actually stated this on the post, but let me reiterate, I think that naming things in somehow fun way is totally okay as long as it stays relevant to what the tool actually does (you can have this achieved by play wording suffixes (Mongo"DB", Open"SSL", Ma"git" are good examples, all are better than elephant, dog, and beaver).

Re: Programmers and software developers lost the plot on naming their tools

#12

Post by dietr1ch »

marifjeren wrote: post #4

There is actually a good reason not mentioned, not to name tools by their purpose: - the purpose will change Your "silicon-valley-bank-integrator" tool will eventually need to be updated to do something else. Or your "login-page-config-service" tool may eventually do more than just logins. Using gibberish or mythological names gives a nice memorable name that doesn't lead (or mislead) you to believe it does a particu…

Also, being too precise and succinct about what the tool does ends up in a race for the name in competing implementations.

Project names should be unique enough to allow them becoming their Id,

- It allows to find the project.

- It allows the project to change, extend it's scope or narrow it.

Having an Id is really important, making that Id related to the project's original intention is nice, but secondary. (as long as it doesn't change enough that it becomes misleading).

Re: Programmers and software developers lost the plot on naming their tools

#14

Post by formula1 »

One issue with package naming is competition. One of the great things about OSS or software in general is people can take inspiration from other projects that do the same thing. Personally I've ran into deciding which casting library to use

- runtypes - https://github.com/runtypes/runtypes

- zod - https://zod.dev/

- ajv - https://ajv.js.org/

AJV and runtypes use the naming convention that the article suggestions. It's named is derived from how it's used. Zod on the other hand seems to come from left field.

Personally, I built a simple caster called "ShallowCaster" before choosing to move to a library as things got move complex but I think a problem is that as competition increases the "generic" naming becomes more difficult to find.

I suppose an option is to include the author name for each package such as "json casting from google" or "@google/json-casting" this way all packages can use the descriptive naming while not conflicting

Re: Programmers and software developers lost the plot on naming their tools

#15

Post by jameshart »

> naming things after random nouns, mythological creatures, or random favorite fictional characters is somehow acceptable professional practice. This would be career suicide in virtually any other technical field.

Really? Have you specced a microprocessor lately? Seen what pharmaceuticals are called? How polymer compound materials get named?

Re: Programmers and software developers lost the plot on naming their tools

#16

Post by TOGoS »

the__alchemist wrote: post #7

If the community followed the author's guidance, we would have names like "Generic LLM wrapper 690" ("GLW690" if following the early programming language conventions.) or "Github clone with a different ideology 11"

Maybe, and I would definitely prefer this to the random-generic-word practice. "illuminate" is some part of Laravel, but I can't remember what it is, just that "that's not even a noun; they just picked that word for $whatever_crappy_subsystem because it sounds nice" and being even more annoyed at the whole thing because of it.

Re: Programmers and software developers lost the plot on naming their tools

#17

Post by dietr1ch »

lr0 wrote: post #8
marifjeren wrote: post #4

There is actually a good reason not mentioned, not to name tools by their purpose: - the purpose will change Your "silicon-valley-bank-integrator" tool will eventually need to be updated to do something else. Or your "login-page-config-service" tool may eventually do more than just logins. Using gibberish or mythological names gives a nice memorable name that doesn't lead (or mislead) you to believe it does a particu…

"purpose will change" argument actually proves the opposite point. When a tool's scope expands beyond its name, the descriptive name tells you something went wrong. But even if so, if you have to rename "login-page-config-service" to "auth-config-service" it is not really a big deal, renaming will be much cheaper if you're renaming to descriptive names. Most importantly though, I wouldn't optimize to avoid renaming (…

> renaming will be much cheaper if you're renaming to descriptive names

Idk, renaming things that shipped is a PITA.

Say you wanted to rename `fish` to `a-decent-shell`. - Packages in all distros would need to be renamed. - Configuration for all systems using/having fish would need to change. - Scripts would need to change, from the shebang to the contents if necessary. - Users would need to understand that they now need to search documentation using the new name. - Documentation would need to be migrated to new domains, sed-replaced, and reviewed.

All this migration would require some synchronized, multi-step process across multiple distros and deployments.

I'd rather have a name that works as an Id.

Re: Programmers and software developers lost the plot on naming their tools

#18

Post by andrewmcwatters »

notepad0x90 wrote: post #9

Yeah, this is a bit relative. Use microsoft tools/products (especially cloud/office) that came out in the past decade and you'll appreciate every other naming pattern. My subjective view is that names should be exotic, flamboyant, unique and generally wild when it comes to tools. sticking your company's name as a prefix into everything (or the flagship product's) is confusing and only hurts you.

[dead]

Re: Programmers and software developers lost the plot on naming their tools

#19

Post by ctoth »

> There’s an odd tendency in modern software development; we’ve collectively decided that naming things after random nouns, mythological creatures, or random favorite fictional characters is somehow acceptable professional practice. This would be career suicide in virtually any other technical field.

I'm charmed by the lack of truth in this beautiful sentence. Top of mind for me, at least.

Re: Programmers and software developers lost the plot on naming their tools

#20

Post by NotGMan »

>> Early programming languages followed similar logic: FORTRAN (Formula Translation), COBOL (Common Business-Oriented Language), BASIC (Beginner’s All-purpose Symbolic Instruction Code), SQL (Structured Query Language), I believe Lisp stands for list processing. The pattern was clear: names conveyed purpose or origin.

"names conveyed purpose or origin.": no they don't. If I use the authors example of the two people talking: as if saying "BASIC" instead of "Cobra" explained the meaning anything better to a person who never used BASIC.

I've been programming for 15 years+ and never used basic due to my age and I never know, until today, that BASIC stands for "Beginner’s All-purpose Symbolic Instruction Code".

Why? Because I don't need to know and it doesn't make the usage of BASIC anything different.

Post reply on HN