But bejesus, this drives me nuts! If I know the double quotes function even exists, then Google should know I actually want to use it as intended - it shouldn't decide "yeah, but maybe you'd like these irrelevant results too!"
Regardless, I basically just always search with verbatim on. Google is mostly useless otherwise.
Normal queries are tailored to your personal filter bubble. You can't see what other people see from same search, and if you're doing SEO or just trying to find who tends to come top in results for something you have a lot of history looking at, you can't tell who comes top for other people.
Verbatim searches are for those easy tasks when you know literally, exactly, what you’re looking for.
Something tells me that a lot of folks on HN are being let down by Google in this area. I don’t mean it in a bad way, I want to identify these issues to help everyone. I wish the UI of search wasn’t so textually-bound.
Is there such a thing as an augmented reality search engine? You search like you do at the library, or when you lost your keys. But for data and virtual objects, they lose out - their evanescence creates a perception gap. There is no correspondence with physical objects, etc. We are getting better with haptics, however.
Rainbows End[0] is a future society I’d choose to live in, especially right about now.
Anyone have any good book recommendations?
[0] Vernor Vinge
Just now I had to give up trying to look up "the term for fans that are paid actors" and variations.
Asking on Reddit or Stack Overflow would be faster than Google's search engine for some things now.
It's a little confusing because fo how Google implemented some of the operators. The boolean + operator in many cases is used in the same way as AND, but Google originally used it to let users to force a specific word to be present in a search result.
So a search for Fish +Chips was a search for both words, but 'Chips' MUST be present. The equivalent search today is Fish "Chips". It's a little annoying because it requires typing another character, and it it is still not always respected.
Deprecate: "express disapproval of."
Depreciate: "diminish in value over a period of time."
I kind of cringe when other developers say "deprecated".
Edit: Versioning and not removing APIs is kind of the way to go, so you don't break client apps that possibly can't be updated easily or at all. "Depreciated" is a far better word to use with a far better outcome. AWS versions their APIs, they don't remove old ones. "I disapprove of using this API and we're taking it away at some random date" vs "this isn't the latest API, use the current one for new development" seems like a pretty stark difference in thinking to me. YMMV.
It is deprecated -- it's use is disapproved of, you should stop using it. In the future it will go away but for now it works, so you can use it, but its use is discouraged.
Depreciated doesn't make any sense -- the value of the deprecated API does not diminish over time. It works, until it stops working. It's on or off. It doesn't work less and less every month or anything. It currently still works completely, but is deprecated -- that is, discouraged. At some point in the future, it will stop working, completely.
the rest of us don't just kind of but REALLY cringe when people say "depreciate" when they mean "deprecate". They are different words, "deprecated" is the right one, it is intentional, it is the word.
Sorry, you are the one using the wrong word.
And that is absolutely the wrong way to approach API development. An API that is being sun-setted should never be removed, because older clients could still use it but sometimes can't be upgraded to newer clients. Removing a v1 API breaks those clients and it's a shitty thing to do to users. Yeah, people should be building NEW things with it, but there's no reason to look at the v1 API with "disgust" as "deprecated" implies - It's simply an older version that should remain functional, if your system is worth half a shit. AWS doesn't terminate older API versions, they just create new versions. Or you can be like Facebook and "deprecate" stuff and just shut it down before your official shutdown date, or not give any notice at all - that's REALLY a fun culture to work in, I guess, for them. "deprecated" is a really negative word, and doesn't even really translate to anything good in terms of software development. It's my opinion that "depreciated" is a far better word and far better outcome when used in software development instead of "deprecated". YMMV.
And I understand you disapprove of the word "deprecated" being used to refer to API that is discouraged, usually because it will be no longer supported/going away in the future.
But that doesn't change the history of the word. The word "deprecated" is what engineers have been using, intentionally, for several decades.
"Depreciated" is a mistaken variation. Even if you think "deprecated" has unfortunate connotations, it still doesn't make "depreciated" right. "Depreciated", as you said, means losing value over time. That is, 10% a year or something. Deprecated API does not "lose value over time".
The word "deprecated" has historically been used to mean that certain API (again, likely a method or function, I don't mean network api specifically) is now discouraged, it's use is disapproved of. Usually becuase it will be going away in the future. Arguments about whether this is the right way to do API change are entirely separate to this historical and current usage, where API change often IS done this way, and it's what the word is used for.
You can have opinions of how you'd like to people to handle API change over time, but that doesn't chagne the fact that "deprecated" is the word engineers have meant to use for decades. If you'd like to advocate for a differnet word and/or different practice you can -- but all "depreciated" has going for it is it sounds confusingly similar to "deprecated", it is not the word you are looking for.
> Not to be confused with Depreciation.
> In several fields, deprecation is the discouragement of use of some terminology, feature, design, or practice, typically because it has been superseded or is no longer considered efficient or safe, without completely removing it or prohibiting its use.
> It can also imply that a feature, design, or practice will be removed or discontinued entirely in the future
https://en.wikipedia.org/wiki/Deprecation
> In accountancy, depreciation refers to two aspects of the same concept: first, the actual decrease of fair value of an asset, such as the decrease in value of factory equipment each year as it is used and wears, and second, the allocation in accounting statements of the original cost of the assets to periods in which the assets are used (depreciation with the matching principle)
https://en.wikipedia.org/wiki/Depreciation
> In economics, depreciation is the gradual decrease in the economic value of the capital stock of a firm, nation or other entity, either through physical depreciation, obsolescence or changes in the demand for the services of the capital in question.
https://en.wikipedia.org/wiki/Depreciation_(economics)
Depreciation has nothing to do with what we're talking about, it's not the right word. Deprecation is the word that has been used for decades for API whose use is discouraged, often because it will not be supported in the future. You can argue that a new term is needed, but that's your argument not a historical usage, and there's no reason you need to limit yourselves to words that sound confusingly similar to "deprecation".
Technically, it doesn't have to be because it's going away, although that is common. I think it always means there's a better recommended way to do the thing, but sometimes the deprecated way doesn't go away.
Typo corrected.
It means the feature still works, but will be removed in the future or is no longer supported. There also be may a new implementation of it that the developer would like you to use, hence the warning that it's deprecated.
Depreciation implies a rate of change over time, which isn't the case. Today we deprecate feature X, and in two years we plan remove it. It never depreciates.
Often though it’s used when the feature is already removed, i.e., it’s not only best practice not to use it, but also impossible with that version.
2) If you were to always maintain backward compatibility, how is "depreciated" in any way an accurate term? If the old API continues to work indefinitely, its value stays the same.
If APIv3 has a `/foo` endpoint that is deprecated, usually I take that to mean that the developers discourage its use, and likely plan to remove it in a future version (say, APIv4 or APIv5). `/foo` will never be removed from APIv3, because that would be a breaking change, and so if I'm willing to stay on v3 forever, that's fine, but in the (likely) event I will want to take advantage of new features at some point in the future, I'm doing myself a disservice by using /foo because it will make the migration harder.
There is at least one case where I think "deprecated" is clearly, inarguably, the right word: when the developer wants to remove a part of an API (say, because it is a large maintenance burden), but it's also committed to stability, so they won't remove that api until some acceptably small number of users are using it.
"Depreciated" is absolutely the wrong term, because it implies that the value is less, when the intent is to communicate "this is still fully functional, but you are warned away from it because it is targeted for future removal." Deprecated.
de == away
prek == ask
We tend to use the terms "déprécié" (~depreciated) or "déprécaté" (~deprecated but not valid French).
On the other hand, "deprecate" seems to also translate to "mark as obsolete" according to https://www.wordreference.com/enfr/deprecate
I guess both terms make sense but I would keep using "deprecated".
Same browser, different overloads.
Left the default search engine as Bing, but only because Duck Duck Go is useless for geographicly local search.
One day I actually DID need to find something local and so I dutifully typed my search into the FF url bar and hit enter. My default search is DDG but my brain stroked off for a second because the results that came back were 100% what I was looking for and I thought I was on Google. Give it a shot again, they're getting better.
I'll try again though as your sibling comment suggests it's improved.
The + (formerly used to force a term to be present in the result) and ~ (also find synonyms) operators have been deprecated.
Google now advises to wrap the word in quotes instead of using the +. Google will also automatically look for synonyms without the use of ~.
I have seen 'AROUND(n)' mentioned in many other places working as a proximity operator in Google, but I don't believe that is true and haven't found it to work in any logical way.
Also the use of parentheses to nest queries is not necessary in Google. It is actually required for Bing on complicated queries though.