I've lamented this for a long time, but on the other side, I doubt if mathematicians would ever get sufficient recognition if their names weren't immortalized thus, since they can't get patents on their works. They totally deserve recognition. Would you even remember Leonard Euler if his work was named factually? Most of us I guess have no idea who came up with sin/cos/exp/log etc. I'm glad for the names of these functions, but lament the loss of knowledge about the one (or many) who discovered them.
Longer names are a candidate .. along the lines of "Einstein's theory of general relativity". "Euler's relative prime counting function" .. but they too will likely, depending on familiarity, collapse over time.
edit: If I want to talk about distance in a curved space, we already have a well named "Geodesic distance".
That depends on your native language, though. For Non-English speakers sounds no different than 'Shell sort'.
I don't think it really "proves the point", though, except for the point that sometimes names are confusing. So maybe it would be nicer if someone had happened to consider whether a specific naming might be confusing, but that's not the same as "names that aren't directly descriptive are automatically bad".
[1]: https://en.wikipedia.org/wiki/Filter_(signal_processing)
I remember when Duff's Device was a neat trick; does anyone still use it these days?
Edit: a neat trick, not a bear trick.
rank (adj):
1. (of vegetation) growing too thickly and coarsely.
2. having a foul or offensive smell. very unpleasant.
3. (especially of something bad or deficient) complete
and utter (used for emphasis).Yes, I included that one as a joke. "git" is a British slang term. Linus once quipped that he names all his projects after himself.
https://en.wikipedia.org/wiki/Linus%27s_law
>In software development, Linus's law is the assertion that "given enough eyeballs, all bugs are shallow".
>The law was formulated by Eric S. Raymond in his essay and book The Cathedral and the Bazaar (1999), and was named in honor of Linus Torvalds. [...]
>Validity
>In Facts and Fallacies about Software Engineering, Robert Glass refers to the law as a "mantra" of the open source movement, but calls it a fallacy due to the lack of supporting evidence and because research has indicated that the rate at which additional bugs are uncovered does not scale linearly with the number of reviewers; rather, there is a small maximum number of useful reviewers, between two and four, and additional reviewers above this number uncover bugs at a much lower rate.[4] While closed-source practitioners also promote stringent, independent code analysis during a software project's development, they focus on in-depth review by a few and not primarily the number of "eyeballs".[5]
>The persistence of the Heartbleed security bug in a critical piece of code for two years has been considered as a refutation of Raymond's dictum.[6][7][8][9] Larry Seltzer suspects that the availability of source code may cause some developers and researchers to perform less extensive tests than they would with closed source software, making it easier for bugs to remain.[9] In 2015, the Linux Foundation's executive director Jim Zemlin argued that the complexity of modern software has increased to such levels that specific resource allocation is desirable to improve its security. Regarding some of 2014's largest global open source software vulnerabilities, he says, "In these cases, the eyeballs weren't really looking".[8] Large scale experiments or peer-reviewed surveys to test how well the mantra holds in practice have not been performed.
>Empirical support to the validity of Linus’s law [10] was obtained by comparing popular and unpopular projects of the same organisation. Organizations like Google and Facebook are known for their quality standards. Popular projects are projects with in the top 5% number of stars (7,481 stars or more). The bug identification was measured using the corrective commit probability, ratio of commits detected to fixing bug. The analysis showed that the popular projects had more bug fixing ratio (e.g., Google’s popular projects had 27% higher bug fix rate than Google’s less popular projects). Since it is unlikely that Google lowered its quality standard in it most popular projects, this is an indication of increased bug detection efficiency in popular projects.
Citation needed, especially for Facebook. The parts I saw are full of vile hacks, committed by an endless stream of new clueless devs --- young developers are of course better by the dictum of Mark Zuckerberg. I'm curious how his code looks or if he ever wrote anything substantial.
Common enough (though there's a diversity of pronunciation and spelling of the name), though for any practical purpose probably "edit distance" works better. (And Hamming distance would probably be better called XOR distance or something.)
Funny coincidence, there was a comment on HN the other day when someone called Euclidean distance "bird distance", and everyone agreed it was a great coinage. I think "Manhattan distance" is similarly evocative, and no less precise than any alternative.
Gaussian noise.
The list in physics could go on for quite a long time. Terms like "gaussian noise" are used as short versions to describe something that would need an entire paragraph if described in a verbose way, as if the reader did not understand the fundamentals of the concept.
At least Gaussian noise is easily googled.
Often the closest thing we do to the whole 'Thurston maps are Thurston-equivalent to polynomials, unless they have Thurston obstructions' thing is that we qualify our statements about programming entities by the programming language or platform to which the statement applies. So you might reasonably have a statement like 'A JSON value consists of an array of JSON values, a map of string keys to JSON values, or a primitive value', which sounds just as self-referential as the Thurston example, but because it's called a JSON value, not a Crockford value, it sounds less conceited.
But back in 1909, it was also the name of the guy who signed the patent. Whose company name was his surname.
I meant it followed the branding pattern, so it happened the brand was derived from the name.
> ... Thus, I thought dynamic programming was a good name. It was something not even a Congressman could object to. So I used it as an umbrella for my activities.
http://www.eng.tau.ac.il/~ami/cd/or50/1526-5463-2002-50-01-0...
Just because it's a common practice does not mean it's good.
In CS, no doubt, we often end up on the other end, where a single term means different things in different contexts and beginners may get confused at our reuse of terminology. Often the reuse gives some metaphorical understanding to the newcomer, even if it largely leads them astray in the details.