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

531–540 of 563 posts

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

#531

Post by jchw »

KurSix wrote: post #485
jchw wrote: post #195

Sometimes I am baffled at what gets onto the frontpage at HN, reminding us all that the people who vote stories and the people who comment on them are less of an overlapping group than you might think. I can understand the desire to have names that are more descriptive, but to claim we have "lost the plot" while holding up names like "awk" is contradictory at best. It sounds more like this person just had a personal…

I don't think the core argument is a vendetta against whimsy

Fine, but then my critique moves over: the article should do a better job of conveying what the argument is and why it matters.

It opens with rms complaining about the names in the emacs ecosystem not being descriptive enough. OK. But the author argues (in these comments) that their argument isn't against names that aren't descriptive, it's just that the name ought to be relevant, and the reason why is because that is more professional.

Now I am paraphrasing so maybe I am not understanding the argument correctly, but I don't think that strengthens the case for this at all. If anything, it begs the question... why? (And I'm not sure rms would particularly buy this argument either, given that he beckons from hacker culture and seems perfectly happy to break social conventions. rms does not hit me as someone who is highly 'professional' in a traditional sense. This is not an indictment.)

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

#532

Post by robocat »

bgar wrote: post #232

>http-request-validator is infinitely superior to “zephyr” Is it though? How are you going to differentiate between 10 different variations of http-request-validator repos on GitHub? I think both have their downsides, but making the name super generic sounding is arguably worse. What I don't like about names like zephyr is that they're purely marketing-driven; people end up picking a zephyr over a http-request-valida…

> don't even get me started on people naming their projects random Japanese words

But words help us learn. How many times do you notice a connection between some word from your childhood and an adult concept or place? And they're not random, people choose things because of many hidden reasons, but random is rarely the case.

Many of us love the story behind a word - as shown by many of the comments here reflecting on the cultural history behind our tool names.

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

#533

Post by Umofomia »

kixiQu wrote: post #97

I believe strongly in this counterargument: https://medium.com/better-programming/software-component-nam... Small summary: external identifiers are hard to change, so projects will evolve such that they are not accurately descriptive after time. (Less discussed there, but: In a complex or decentralized ecosystem, it's also the case that you come across many "X Manager"/"X Service"/"X State Manager"/"X Workflow Servic…

I totally agree with this, and will add that another benefit of whimsical names is discoverability. If your project is named plugin-update-checker and I want to find documentation on it, it's likely going to be buried in a bunch of other irrelevant search results about plugin update checkers in general. If it was called SocketToMe instead, I'm going to find much better search results.

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

#537

Post by 1vuio0pswjnm7 »

plorkyeran wrote: post #98

> grep (global regular expression print), awk (Aho, Weinberger, Kernighan; the creators’ initials), sed (stream editor), cat (concatenate), diff (difference). Even when abbreviated, these names were either functional descriptions or systematic derivations. If you asked someone unfamiliar with unix tools what they thought each of these commands did, diff is the only one which they would have even the slightest chance…

"It's ridiculous to complain about "libsodium" and then hold up "awk" as a good name."

I never really understood what was "wrong" with the NaCl library that it needed another version that does not have the string "nacl" somewhere in the name

I also remember Google named some heavily promoted non-cryptography project "NaCl" subsequent to the NaCl library's release making any searches for "NaCl" biased toward Google's software

I still use original NaCl, e.g., for CurveDNS, tinysshd, dq and dqcache, not libsodium

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

#538

Post by ndarray »

> Your HTTP client, cli utility helper, whatever library is not a consumer product.

> (...) Every person who encounters your “fun” name pays a small tax. Across the industry, these taxes compound into significant waste

Devs who build FOSS utilities owe you, or the industry, absolutely nothing. As someone who lists Noam Chomsky under "Some works I recommend engaging with", you sure seem to think capitalists are entitled to people's free work, to the point where you start making demands.

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

#539

Post by groos »

DSMan195276 wrote: post #277
groos wrote: post #167

Earlier quoted context omitted.

Fine. Name it sodium-crypto.a or sodium.crypto.a or whatever. The author's complaint does hold water.

You can, but then the names get needlessly long and one of the things we generally like (especially for command-line programs) is names that are short and easy to type. If we're going to make this argument then why not call the unix tools `concatenate`, `difference`, `stream-editor`, etc. Those are way better names in terms of telling you what they do, but from a usability standpoint they stink to type out. Libraries…

Short names are a figment of the age of teletypes when you had to repeatedly type things out. This hasn't been the case for at least 3 decades. Most good shell+terminal combinations will support autocomplete, even the verbose Powershell becomes fairly easy to use with shell history and autocomplete, which, incidentally, it does very well.

If you are repeatedly typing library names, something is wrong with your workflow.

Niklaus Wirth showed us a way out of the teletype world with the Oberon text/command interface, later aped clumsily by Plan 9, but we seem to be stuck firmly in the teletype world, mainly because of Un*x.

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

#540

Post by rswail »

a96 wrote: post #433
rswail wrote: post #346

Earlier quoted context omitted.

> ed commands are very similar to vi commands at heart vi was build on top of ed. Ed was the Unix line editor, which is why all the commands after a colon have the form of "start,endcommand", eg "1,$p" would list all the lines of a file on your tty/decwriter. 1,$s/findexp/replace/g would s ubstitute all examples ("g") of findexp on the lines 1 through EOF

And these all pretty much came from an era before glass display were (affordable) in computers. A terminal was roughly a keyboard and a printer attached together, or a typewriter cut in half. Paper. No cursors. No arrow keys. Mostly after punched cards and mostly before transistors. And that was only a few decades ago, there's people still alive that have used these machines. Funny that they are still some of the mos…

FFS, I'm not that old. I'm 61.

I started out at school in 1977 on a PDP-11 with 16K of RAM, 3 ASR-33s connected by 20ma current loop. We also had a VT-52. All running at 110baud. No valves, all transistors and ICs. That system was already outdated.

Punched/mark sense cards were still around.

Two years later we had a PET, Apple-II, and a TRS-80.

Teletypes have been around since the 1940s.

Cut the false history crap when it's easily found online and elsewhere.

Post reply on HN