361–370 of 406 posts
Earlier quoted context omitted.
Page rank. I thought git was named by Linus, and to the extent that it is named after him, it was self awareness of his reputation? 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.
Page rank is probably one of the more clever names out there. I didn't realize at first it was named after the founder, as it's a good description to how it works.
Hard disagree. Once you get to the advanced levels of any field, terminology being "accessible" doesn't really matter, but being precise does . Areas like philosophy and law actually suffer in my opinion when they overload common words with uncommon meanings, or descend into weird disambiguations that depend on suffixes. For example, in philosophy there's "contractarianism" and "contractualism", and trying to remembe…
You are absolutely on point with the contrast to Law; I have degrees in both subjects, and this has also been my experience.
Jargon exists for a reason. The deeper the field, the better the jargon needs to be to allow proper communication. The fact that we can communicate complex mathematical ideas in language at all is a minor miracle.
Earlier quoted context omitted.
These are names for products though, not programming concepts. A more accurate analogy would be calling a class a Kay template or calling a for loop a Lovelace construct. And it's great that we don't do that.
Lucky us, we have Booleans, Turing Machines, Bolzmann machines, Markov Chains, Liskov Substitution Principle, ISO 8601 dates, the MIT and BSD licenses (hat-tip to the GPL), and the wholly ambiguous concept of a "class" or "object-orientation"
As someone with a degree in pure math, I can tell you, we had Turing machines, Boolean networks and Markov chains coming out of our ears. These are not programming concepts; all of these people were mathematicians/physicians who lived before computers even existed. This is just reaffirming the point that mathematicians tend to name things after each other.
> Liskov Substitution Principle
Actually, this is the only instance of a "truly" programming concept named after a person that I know of. And by "truly", I mean that a mathematician does not benefit from knowing this (would probably even write it off as "trivial"). It really is about the art of designing programs. Well, at least it has "substitution" in its name. Not like a Noetherian ring, which is just the opposite of an Artinian ring :D
Licenses belong to law. And ISO is not run by programmers either (for Christ's sake, they have a standard for A CUP OF TEA). This goes to show how much of a polymath a programmer has to be. Reminds me of this fun little rant: https://www.usenix.org/system/files/1311_05-08_mickens.pdf
I think when people name things, unless they are very narcistic, should be having that sole purpose in mind.
This comment by xamuel relatably describes what people usually do when naming things https://news.ycombinator.com/item?id=24386695
> Rather, what really happens is that mathematicians are a community, and they refer to things in whatever way is convenient. Davis's colleague refers to such-and-such theorem as "Davis's Theorem" not because of some committee on naming, but rather because they were there at the conference where Davis announced the theorem, and everyone at said conference excitedly talked about "Davis's Theorem" for the whole rest of the conference because it was so exciting.
The arguments that say names should be self descriptive is only a part of the discussion.
There's the name overloading problem, where we only have a limited set of existing descriptor which can cause two object name to conflict.
There's the memorability aspect.
There's the homophonic / homographic problem where multiple names could be perceived differently.
There's the complexity aspect. The more complex an information, the harder it is to write an accurate name.
There's context aspect.
There's the extreme connotation aspect. Some words triggers extreme emotional response to someone.
There's the dependency aspect where people have been using a name for years.
All in all, naming things are hard problem. But the important thing is naming things should be done for the sake of naming things in mind. If naming things is done primarily for other agenda, like someone's glory, the result might be questionable.
Assuming that people are naming things for the right cause, problems that arise from names should not be attributed to naming process. For example the article author's problem might be simply caused by the complexity of the information referred by the name.
Edit: grammar and formatting
Earlier quoted context omitted.
Sure. So is Ford. But back in 1909, it was also the name of the guy who signed the patent. Whose company name was his surname.
>"where naming is more like branding" I meant it followed the branding pattern, so it happened the brand was derived from the name.
Earlier quoted context omitted.
Presumably because these exist: https://en.wikipedia.org/wiki/Photographic_filter
The point being made is that photoshop manipulates matrices and filters are circles made of translucent material you put on your camera; and in fact many of those photographic filters don't primarily filter light but rather distorts it in some desired fashion. "Transformations" would be much more accurate.
Earlier quoted context omitted.
Lucky us, we have Booleans, Turing Machines, Bolzmann machines, Markov Chains, Liskov Substitution Principle, ISO 8601 dates, the MIT and BSD licenses (hat-tip to the GPL), and the wholly ambiguous concept of a "class" or "object-orientation"
> Booleans, Turing Machines, Bolzmann machines, Markov Chains As someone with a degree in pure math, I can tell you, we had Turing machines, Boolean networks and Markov chains coming out of our ears. These are not programming concepts; all of these people were mathematicians/physicians who lived before computers even existed. This is just reaffirming the point that mathematicians tend to name things after each other.…
As a programmer, I would agree. So much so that I find it easier to remember the concept than the name.
But so it goes. People like their own name on things for masturbatory purposes and are willing to tolerate other people's masturbation to do it. At great cost to us all.
Earlier quoted context omitted.
Bloom filters prove OP’s point though. The first few times I heard the term, I wondered how a Photoshop filter to blur things could possibly apply to the problem. Maybe if it was called an exclusion filter it would be less jargony, I don’t know; naming things is hard.
>Bloom filters prove OP’s point though. 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".
Earlier quoted context omitted.
for example: operating systems, programming languages, human computer interaction, etc. Those topics might seem to have nothing to do with math but all of their components have mathematical underpinnings. Algorithms, data structures, complexity theory, and even the physics of end-to-end latency, colour perception, etc. There probably are some people out there, working in these fields with only a high school math back…
It is like saying Chemistry is a subfield of math, because at some point they use numbers to describe things (mass and such).... It is not. Applied Computer Science has as much common with math as Chemistry does with math. I view theoretical computer science as mostly self-masturbatory, to the point that is very very divorced from real life applications and is benefiting very little to us. Also the market has spoken…
You wouldn't have complexity analysis of algorithms, with which most of us don't need to directly involve ourselves, but you do apply its results when choosing an algorithm based on the knowledge that was originally obtained through that analysis. Or if you're not choosing your algorithms, at the very least someone who chose them for your platform did.
You probably wouldn't have lossless data compression (and an understanding of it) at its present level without someone having done mathematically-based work on things like arithmetic coding [1] and range encoding [2]. Again, you probably don't write that code yourself (I haven't), but it's there.
The list goes on.
A PhD degree isn't really a good investment in terms of just salary in almost any field that I can think of. That just means work that's closer to (and directly applicable for) direct revenue streams tends to pay better than work that's further away from them. That doesn't directly mean work that's further away from revenue streams is less valuable down the road; it just means there's less certainty about its ability to help generate revenue, and that there are more steps, more interim work and a greater financial risk involved. While most businesses don't, and shouldn't, bother, that doesn't mean they might not benefit at some point if someone else does it. "The market has spoken" is a shortsighted way of looking at these kinds of things.
Sure, there are areas of theoretical computer science that are more similar to pure maths in terms of abstraction and applicability, and which are pretty much a pure intellectual pursuit. They are very far from engineering or applications. But theoretical work in CS is broader than that, and some of it underlies much of what we have in the practical world.
It's also true that most of software development and engineering work don't really require involvement with much of the theory, partially because someone else is already doing that work within the platform, and partially because most business software is actually theoretically more or less trivial.
Still doesn't mean the theoretical side is useless, because not all software is trivial.
Hard disagree. Once you get to the advanced levels of any field, terminology being "accessible" doesn't really matter, but being precise does . Areas like philosophy and law actually suffer in my opinion when they overload common words with uncommon meanings, or descend into weird disambiguations that depend on suffixes. For example, in philosophy there's "contractarianism" and "contractualism", and trying to remembe…
I Disagree with you, in Computer Science we have things like: "Quick Sort", "Merge Sort", "Map", "Hashtable", "LRU", etc... etc... They are much more descriptive and easy to remember, even though the Algorithms can be complex themselves. Event the name "Boolean", could be changed to "Conditional"... and be even more readable. Also, Dijkstra algorithm can be generalized to "Shortest Path Algorithm" (there can be more…
It's rather that others start calling the concepts by the person's name when discussing the concept or algorithm, after it has been introduced by that person in an article or elsewhere.
It would be good not to accuse others of narcissism when there's actually no narcissism involved.
Edit: omitted part that wasn't constructive