But... I... like... the... PAIN! Our secret addiction to 'free' APIs Yahoo! is killing off several services to focus on "search, communications and digital content", it's said. Wait, Yahoo! has a search engine? Who knew? What Yahoo! won't have in the very near future is a developer favorite by the name of Yahoo! Pipes. Yahoo! Pipes has always been something of an odd duck, not just within the …
This post has been deleted by its author
On a similar note Facebook appear to be giving app developers notice to update to their new API. Developers must make changes to request the old API - and apparently it will only be available for a transition period of 2 months.
One of the benefits of an OO world was supposed to be the potential for provision of parallel version interfaces to avoid rewrites every time the current object interface changed.
Unfortunately, we're not living in an OO world. But that isn't even the problem. The issue is that solutions to these sort have already been devised a long time ago, but the new wizbang generation of developers dismiss 'old tech' out of hand because it's old, preferring instead to reinvent the wheel over and over again. Ultimately, these reinventions are of lower quality than the older stuff for the same reason... New developers insist that they know better than older developers and so go onto to make the exact same mistakes that old developers did.
Now where's my cane.... and get off my lawn ya damn brats!
*strokes beard thoughtfully while sucking on a Werther's original* Abstraction of interfaces to avoid hard dependencies on third party software is a concept that predates OO by some considerable time span. It is as applicable to attempting to make an application run on both X and MS Windows in 1992 as it is to switching web apis in 2015. It's just that the latest crop of young whippersnappers are too lazy and too caught up in instant gratification to craft around such pitfalls..
Abstraction of interfaces to avoid hard dependencies on third party software is a concept that predates OO by some considerable time span
Here's a computing-folklore debate: how far back does it go?
Clearly abstraction in software development was a concern in some sense at least as far back as LISP (1958), and arguably for FORTRAN (original design 1954, implementation a couple years later) and AUTOCODER (first implementation 1955). AUTOCODER, for example, introduced the idea of assembly macros, which are certainly an abstraction mechanism.
But when did programmers start saying, hey, it'd be a good idea to create interfaces that abstract away from implementation details in other components, to insulate us from changes to those components? According to El Wiki, JOVIAL introduced the idea of separate data definitions used by multiple components (the "COMPOOL") in '59. Early FORTRAN and COBOL had some concept of modularity (FORTRAN subprograms and COBOL programs), but there wasn't much abstraction - it was basically a matter of "switch control flow and fire some data at the recipient and hope our definitions match".
Simula introduced OO encapsulation in the late 1960s. So we can probably say that the idea of using abstraction to insulate a program from changes to its partners originated in the mid- to late-1950s, and was elaborated during the 1960s.
So, roughly speaking, we can say that programmers who haven't learned that are about half a century behind the state of the art.
On a similar note Facebook appear to be giving app developers notice to update to their new API. Developers must make changes to request the old API - and apparently it will only be available for a transition period of 2 months.
Again? I did Facebook devslopment in a previous life... The old API was replaced with FQL, then the transition to iframes and the removal of FBJS.. Then FQL was replaced with graph... Somtime around then, authentication was switched to oauth2 etc...
Never again!
Actually, it's reports of its life that are an exaggeration.
Nothing I use anywhere is based on Silverlight. No web site I use makes any mention of it. I'm sure there are some out there, but they're beyond my horizon. It might as well be dead for all I see of it.
Nothing I use anywhere is based on Silverlight. No web site I use makes any mention of it.
Thanks! I always find your personal anecdotes are compelling evidence for the general case. Indeed, when faced with any question, I simply ask myself, "What does Monett say?".
The API was merely a route to the underlying data feed. Twitter's "API" was actually a connection to the tweet firehose - the users were thus making money (or VC funding) from mining somebody else's data.
There won't be an "open source equivalent" because the data behind the API was the point.
It's about time that folks stopped treating Facebook, Google, Twitter and all the rest as part of the fixtures and fittings of the Internet (like DNS is) and realise that they are actually commercial services - albeit very pervasive ones.
This post has been deleted by its author
While I can't see FB going anywhere soon, there's a hell of a lot of website using FB as an authentication mechanism. I'm sure FB reaps in too much personal info from these auth requests to shutter that service but as you say, it's still not a good thing to rely on services like FB for this sort of thing.
>"build it (or buy it), ruin it, shut it down" business strategy
Except for the only value add thing the company has done in the last decade which was to buy a big stake in a Chinese company which at one time comprised of almost the entire value of Yahoo. Good thing Jerry spurned Microsoft huh?
While Yahoo! happens to be an egregious example of the bizarre "build it (or buy it), ruin it, shut it down" business strategy, but it's hardly alone.
a) Yahoo! is currently in the process of self destructing. Every feature it had that was easy to use and a boon to the community is now an ugly, crufty, unuseable mess, the result of "new vision". It says something when a Yahoo Group, formerly one of the most simple and intuitive web resources ever launched, cannot be used without inducing a migrane and a homicidal rage in anyone with a conventional screen/keyboard. I can't imagine how much worse the whole thing is on a phone because I am in no way tempted to so much as try that route to madness.
2) The quoted line needs tightening. Lose either the "While" or the "but" after the comma.
I learned this lesson twice, thrice, um...
The first was the biggest. When GeoCities disappeared and all of the stuff hosted there ceased to be. Some of it is on archive.org. A fair amount... just disappeared. Forever.
The second? Smaller. If you are browsing YouTube and you see a song you like that isn't an official or Vevo release, I'd recommend you download it, 'cos it may not be there the next time you look for it - either region locked or simply taken down.
Third? I used to use Google Reader. Thankfully Google's infrastructure is a convenience for me, rather than a necessity. Yes, it would hurt - Maps, Translate, and Docs all have uses and I use them a fair bit (even if just wandering around places I'll probably never ever visit in streetview); but if those went, I'd get over it. Maybe, even, Apple Maps or Bing's effort might get its game together...though I won't hold my breath.
As was pointed out above - any "shiny" that uses an external website for core parts of its functioning will go right back on the shelf. It simply doesn't make sense to put your reliance in the hands of a potentially capricious third party. Changing the API or removing the product? To them it's a business decision. A cost/benefit analysis. They care not how important it is to you. Never forget that.
Developers keep 'falling for it' because
1. A service or API gets launched in a blaze of publicity
2. The senior director who thinks they know all there is to know about technology reads about it
3. They insist that it is built into the product
4. The developers present all the reasons why this is a very bad idea
5. The senior director insists it is built into the produce
6. The developers get on with it
7. The senior director boasts to the other directors that yet again they're ahead of the technological curve.
8. Three years pass and the API is pulled
9. The senior director blames the developers for wasting company resources.
10. the developers produce the email trail.
11. The senior director shuts up about it.
12. Go to 1.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
