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

41–45 of 45 posts

Re: API Half-lives

#41

Post by perigrin »

mst wrote: post #31
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 :)

You forgot Fortran, BASIC, SQL, x86 Assembler, HTML, HTTP, TCL, Python, Ruby ... 15 years ago was 1996, we've got a lot of crap to purge.

Re: API Half-lives

#42

Post by 6ren »

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…

You don't think there's a benefit to XML formats that have an XML Schema, so you can do automatic data-binding (at least in Java, with JAXB)?

There are also many visual XML mappers (mapforce, biztalk mapper, stylus studio, IBM and Oracle integration products)... but truly, these are enterprise-expensive tools which I think are only used in the enterprise (with its more complex data and, some say, unnecessary corporate inflexibility).

While it's true that disruptive tools tend to start at the bottom (e.g. with startups) and bubble up, the complex data needs of the enterprise have to be addressed in some way, either by sticking with conventional tools, or the new tools growing in ability. The common consensus seems to be that if JSON's ecosystem developed a schema language, a "JSLT" etc etc, it would be just as ugly as the XML ecosystem (i.e. ugliness is partly due to irreducible complexity) ... and we already have one.

I wonder if the technology development path might be similar to Twitter, iterating quickly with agile, featherweight Ruby, then switching to Java only when scaling demanded a heavyweight solution: start with light JSON when the needs are straightforward; move to XML when complexity demands a heavy solution. For many wildly successful startups, that might not happen, and JSON might remain perfectly fine; just as many startups stay with Ruby.

Re: API Half-lives

#43

Post by mechanical_fish »

rue wrote: post #30
mechanical_fish wrote: post #15

Earlier quoted context omitted.

I'm not sure I'm reading your sentence correctly, but the scary truth is that many, many brand-new businesses are initially built on top of half-assed hacks. By design! That's what all this "minimum viable product" talk is about. The canonical example might be Twitter. There's absolutely no question that their initial Rails-based infrastructure was not up to the task of running Twitter. But it was up to the task of r…

> But it was up to the task of running Twitter for a few thousand users, […] (Tens of thousands, actually, perhaps hundreds?)

Absolutely. I'm postulating a very conservative lower bound here.

(And, obviously, a very rough approximation of the actual history. If we could see Twitter's Git repository presumably we'd find that the service actually went through dozens, perhaps hundreds, of performance tweaks as it grew.)

Re: API Half-lives

#44

Post by bryanh »

6ren wrote: post #42
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…

You don't think there's a benefit to XML formats that have an XML Schema, so you can do automatic data-binding (at least in Java, with JAXB)? There are also many visual XML mappers (mapforce, biztalk mapper, stylus studio, IBM and Oracle integration products)... but truly, these are enterprise-expensive tools which I think are only used in the enterprise (with its more complex data and, some say, unnecessary corporat…

I think you make a good point, there are definitely complex situations that call for Java-esque and enterprisey tools. However, having a simple solution often trumps complex solutions when you just want to "get things done"™.

I suppose it boils back down to the most appropriate tool. Are you selling to enterprises? Use SOAP. Everyone else? Use REST/JSON.

Re: API Half-lives

#45

Post by 6ren »

bryanh wrote: post #44
6ren wrote: post #42

Earlier quoted context omitted.

You don't think there's a benefit to XML formats that have an XML Schema, so you can do automatic data-binding (at least in Java, with JAXB)? There are also many visual XML mappers (mapforce, biztalk mapper, stylus studio, IBM and Oracle integration products)... but truly, these are enterprise-expensive tools which I think are only used in the enterprise (with its more complex data and, some say, unnecessary corporat…

I think you make a good point, there are definitely complex situations that call for Java-esque and enterprisey tools. However, having a simple solution often trumps complex solutions when you just want to "get things done"™. I suppose it boils back down to the most appropriate tool. Are you selling to enterprises? Use SOAP. Everyone else? Use REST/JSON.

Yep, as simple as possible, no simpler. (NoSQL is another example)

I think a central source, like a database, needs to cater for every possible use in general (which the relational model does); but if you're doing something very specific, it's crazy wasteful to do it with full generality.

I am curious if someone can work out how to make a simple API that is also fully general (I think it has to be equivalent to the relational model - but it's early days yet).

Post reply on HN