Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

API Half-lives

gabrielweinberg.com

Post reply on HN
Print view View original

31–40 of 45 posts

Re: API Half-lives

#31

Post by mst »

SimHacker wrote: post #16

Speaking of software half-lives: "Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. Basically, a lot of the problems that computing has had in the last 25 years comes from systems where the designers were trying to fix some short-term thing and didn’t think about whether the idea would scale if it were adopted. There should be a half-life on software so old…

So after 15 years, software should have gone away.

Ok, then call me back when you've purged the world of C, lisp, Smalltalk and UNIX, and I'll give you a hand with perl :)

Re: API Half-lives

#32

Post by SimHacker »

perigrin wrote: post #29
SimHacker wrote: post #16

Speaking of software half-lives: "Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. Basically, a lot of the problems that computing has had in the last 25 years comes from systems where the designers were trying to fix some short-term thing and didn’t think about whether the idea would scale if it were adopted. There should be a half-life on software so old…

As I pointed out on Gabriel's blog. This quote is six (6) years old at this point. Even if it was arguably relevant at the time (Alan Kay giving witness to an internal transition period in the Perl community), I'm not sure how it's relevant now. Without specifics on which ideas Perl has that you feel don't scale, and how ... this is merely trolling by appeal to authority.

If the ideas in Perl scaled, don't you think there would be a usable version of Perl 6 after more than 10 years?

And Perl 5 is certainly on its way out: http://www.tiobe.com/index.php/paperinfo/tpci/Perl.html

When Alan Kay made his remark, Perl had just hit its highest mark in popularity. And it just this year hit its lowest mark. So I think you've been holding your graph upside-down.

Re: API Half-lives

#33

Post by SimHacker »

eCa wrote: post #22
SimHacker wrote: post #16

Speaking of software half-lives: "Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. Basically, a lot of the problems that computing has had in the last 25 years comes from systems where the designers were trying to fix some short-term thing and didn’t think about whether the idea would scale if it were adopted. There should be a half-life on software so old…

I would think that the number of big sites that is/were built on Perl (IMDb, Amazon, ...) would be a counter point to that. Of course, it's not the right tool for everything - far from it - but it is a Swiss army knife.

And the number of companies still using COBOL and FORTRAN prove what? As Dr. Turing's proof demonstrates, they're both swiss army knives too.

Re: API Half-lives

#34

Post by bryanh »

brlewis wrote: post #23
bryanh wrote: post #14

All API's are not made equal. Some may not be around in 2 years, some 10 years, but in the time you are forced to work with some of them, you might lose your sanity. I'm working with pretty much every type of API through my startup Zapier.com and some of these API's I wouldn't wish upon anyone except maybe the deeply masochistic coder. They suck. I suppose that's good for us. However, we aggregate data from many doze…

I mostly agree with you, but think XML is OK for a read-only API if your data fits RSS or Atom syndication.

Sure, its okay. But compared to the ease of JSON...

Re: API Half-lives

#35

Post by ajross »

mechanical_fish wrote: post #3

It is indeed vitally important to remember that external APIs are unreliable and temporary. The question to ask in any given situation, though, is: How much more reliable and permanent is the code you own and manage yourself? And at what cost? However high the odds are that the founders of a given startup will leave their company within five years, the odds that the people who built your in-house widget will leave yo…

ANSI C programs written in 1989 still compile and run unmodified on any modern 32 bit Linux or Windows box. C programs using the BSD sockets API from 1982 still work unmodified on Linux. Fortran77 code has an even longer pedigree and still builds in gcc. And while Common Lisp has seen a lot more library evolution, I believe most of its early incarnations still work in modern implementations.

I suppose you're right that any given code is unlikely to outlast its dependencies. But the corrollary to that is that successful code is, by definition, almost always going to outlast its dependencies.

Dependencies are hugely expensive. And it makes me happy to see someone try to explain that to the modern world of import-happy coders. Reuse isn't free. Solving simple problems with external dependencies can often be more work than it's worth.

Re: API Half-lives

#36

Post by dwhitty »

dewitt wrote: post #19

One of the things that we've been emphasizing at Google of late is to ensure that each API has a sustainable model prior to launching it. By that I mean, evaluating each new surface to verify that it provides value to all parties — the end users, the developers, and to Google (in roughly that order, but all are essential) — and that this value scales as the popularity of an API or platform increases. Over past years,…

Can you share your insider perspective on Steve Yegge's infamous rant on SOA at Google and Amazon?

https://plus.google.com/112678702228711889851/posts/eVeouesv...

Re: API Half-lives

#37

Post by chromatic »

SimHacker wrote: post #32
perigrin wrote: post #29

Earlier quoted context omitted.

As I pointed out on Gabriel's blog. This quote is six (6) years old at this point. Even if it was arguably relevant at the time (Alan Kay giving witness to an internal transition period in the Perl community), I'm not sure how it's relevant now. Without specifics on which ideas Perl has that you feel don't scale, and how ... this is merely trolling by appeal to authority.

If the ideas in Perl scaled, don't you think there would be a usable version of Perl 6 after more than 10 years? And Perl 5 is certainly on its way out: http://www.tiobe.com/index.php/paperinfo/tpci/Perl.html When Alan Kay made his remark, Perl had just hit its highest mark in popularity. And it just this year hit its lowest mark. So I think you've been holding your graph upside-down.

TIOBE is the phrenology of programming language discussions, and making changes in an established programming language is exceedingly difficult even when you intend to replace the existing version. See also Python 3000.

Re: API Half-lives

#38

Post by ufo »

SimHacker wrote: post #33
eCa wrote: post #22

Earlier quoted context omitted.

I would think that the number of big sites that is/were built on Perl (IMDb, Amazon, ...) would be a counter point to that. Of course, it's not the right tool for everything - far from it - but it is a Swiss army knife.

And the number of companies still using COBOL and FORTRAN prove what? As Dr. Turing's proof demonstrates, they're both swiss army knives too.

The Church-Turing thesis is not a proof - it is a definition of computability. (The thesis is that it is the reasonable definition. For all I know someone could come up with a new kind of computation that is stringer then turing machines and then we would have to redefine our notions.)

Re: API Half-lives

#39

Post by 6ren »

If there's demand for an API, one would expect competitors to arise; or at least, for someone to fill the niche left by an abandoned/bankrupted/acquired API... (unless it's a non-feasible business, e.g. giving too much away)

Then, the problem is the difficulty of integration: how hard it is to switch to another provider? In a mature industry, standards eventually arise that make switching easier, but not in the early days.

Re: API Half-lives

#40

Post by perigrin »

SimHacker wrote: post #32
perigrin wrote: post #29

Earlier quoted context omitted.

As I pointed out on Gabriel's blog. This quote is six (6) years old at this point. Even if it was arguably relevant at the time (Alan Kay giving witness to an internal transition period in the Perl community), I'm not sure how it's relevant now. Without specifics on which ideas Perl has that you feel don't scale, and how ... this is merely trolling by appeal to authority.

If the ideas in Perl scaled, don't you think there would be a usable version of Perl 6 after more than 10 years? And Perl 5 is certainly on its way out: http://www.tiobe.com/index.php/paperinfo/tpci/Perl.html When Alan Kay made his remark, Perl had just hit its highest mark in popularity. And it just this year hit its lowest mark. So I think you've been holding your graph upside-down.

I'm sorry I completely fail to understand how either of these remarks have any bearing on scalability?

How does the Perl6 project's ability (or lack of) to deliver a project to your undefined criteria for "usable version" have any bearing on the scalability of the ideas involved in either it or Perl5?

Second, in what way does a self-described popularity contest have bearing on the scalability of a language?

I would also love to hear how you would explain http://www.tiobe.com/index.php/paperinfo/tpci/Lisp.html which Alan Kay also talked about during that interview ... far more than the single quote he made about Perl. Note that according to the scale on both the Perl graph and the Lisp graph, Perl's lowest point is roughly equal to Lisp's highest point. The obvious explanation to me is that TIOBE score has almost nothing to do with Alan Kay's comments or opinions as expressed in that interview. So I don't understand what connection you're trying to imply exists here.

Perhaps you had your book on logical inference upside down?

Post reply on HN