Codenames are good identifiers when lots of projects exist.
There are more software projects now than EVER.
I welcome Splorg, Chizzel, Rapunzel, Brap, Titoid, and Chungus - I don't care as long as it's good.
Programmers and software developers lost the plot on naming their tools
541–550 of 563 posts
Re: Programmers and software developers lost the plot on naming their tools
#542That glorious day when I explained to my boss what wiki is and that we should have one internally, he fired "viki" into google, with smoothly honed muscle memory clicked first result..and got full screen of poon.
What was the first result? Mine is Rakuten Viki, a streaming service focused on Asian dramas that aren’t like what you described.
That was in the 2000s. Google was heavily SFW-ified since.
Re: Programmers and software developers lost the plot on naming their tools
#543GNU's version of Yacc is called Bison. Pine Is Not Elm (even though that was never an official acronym). UNIX was UNICS which was a pun on MULTICS. I couldn't for the life of me tell you what dd stands for. nano is a copy of pico which was the "PIne COmposer". Postfix is a completely opaque portmanteau of post (as in mail) and "bug fix". C++ is "C incremented", and C is the successor of B, which is the successor of B…
> Yacc is called Bison
And when they named ‘Yet Another Compiler Compiler’ something tells me they weren’t being deadly serious.
Re: Programmers and software developers lost the plot on naming their tools
#544Earlier quoted context omitted.
Used to be that Ruby's "rubygems" library had an alias "ubygems" so that when invoking ruby with the -r option (to require a library) you could say "ruby -rubygems". Sadly, they seem to have removed this alias library sometime around Ruby 2.4.
It was removed because rubygems was made to be required by default so it was now useless. The stdlib still contains `un.rb` though: https://github.com/ruby/ruby/blob/d428d086c23219090d68eb2d02...
Wow, I did not about un.rb. Looks cool though.
Re: Programmers and software developers lost the plot on naming their tools
#545I 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.
Go.
Re: Programmers and software developers lost the plot on naming their tools
#546Earlier quoted context omitted.
Case in point: @testing-library (the JS one for React, Vue, etc.) Besides, this type of overly generic names makes it harder to search relevant stuff, which makes them more annoying to me than silly names.
They also make things hard to talk about. When you mention testing library in an ordinary conversation without @ signs and dashes, people won't know whether you're talking about the concept of a testing library or a specific one.
The other day I was trying to tell someone to use prettier, the specific program, and they thought I meant the generic concept of code formatters
Re: Programmers and software developers lost the plot on naming their tools
#547the problem with technical software names is that they are either too long, too pointless, do not die when underlying tool goes through re-incarnation(looking at you angular) or worse, too important to be wasted on a lesser quality project (looking at you react-router).
in my company, we have a tool whose technical name was four word long, and has just as much cognitive load as any technical name.
one of my biggest contribution to that project was to Name it.i gave it a simple name, with zero relation to tech or any software
and suddenly our PMs, Managers, Users can pronounce it and can actually type it correctly and of course recall it's name flawlessly.
so, at least from my experience, having a small, easy to pronounce name is more important than having technical name.
Moreover having a name with all of the qualities is definitely desirable, but there are many projects in world and not that great names. and many Great names (looking at you, Vue.js) are either already taken or beyond my naming skills
Re: Programmers and software developers lost the plot on naming their tools
#548Earlier quoted context omitted.
tar zxvf Is burnt into my brain. One of my earliest Linux command line experience required untaring zipped tars. So yeah that xkcd is "not funny" to me in that sense. Of course I couldn't tell you pretty much any other use without a man page.
z requires it's compressed with gzip and is likely a GNU extension too (it was j for bzip2 iirc). It's also important to keep f the last because it is parametrized and a filename should follow. So I'd always go with c (create) instead of x (extract), as the latter assumes an existing tar file (zx or xz even a gzipped tar file too; not sure if it's smart enough to autodetect compress-ed .Z files vs .gz either): with c…
Like I said, I was operating on a lot of zipped tars. Not sure what you are replying about.
The other commenter already mentioned that the xkcd just said "valid", not return 0 (which to be fair is what the original non xkcd required so I guess fair on the mixup)
Re: Programmers and software developers lost the plot on naming their tools
#549I'll die on the proverbial hill that the absolute worst instance of this has always been GIMP, which could have perhaps eaten Adobe's lunch MANY years ago. It was and perhaps still is, a solid competitor to Photoshop, but any unfamiliar grownup is, quite reasonably, going to never ever ever trust anything to do serious work with a name like that.
GIMP has god horrid UX, there's no way it could have eaten Adobes anything. There's lineage of FOSS apps that stick by the "we're not X, we're different from X." mantra. The discomfort, frustration and unintuitiveness you're feeling from using our app? It's just you! No, that's not bad design and bad UX! its simply because we are different! We aren't X (Photoshop), we just do things differently here!". GIMP is quinte…
For what it's worth, we're trying to encourage more feedback from designers and users to make GIMP better. We have a public repo dedicated to UX/UI discussions: https://gitlab.gnome.org/Teams/GIMP/Design/gimp-ux/-/issues
We've implemented a number of items from the issue posts once consensus was reached, and we hope more people will participate and help improve GIMP further.