Comment by mikeash | Hacker News Reader

Comment by mikeash | Hacker News Reader

Parent Full thread

The thing is, you end up depending on algorithmic complexity whether or not it's guaranteed. There's simply no way around it. If this API changed to an exponential or factorial running time, almost all users of it would be completely broken. Since the running time isn't guaranteed then it hasn't technically broken any API contract, but pretty much the only way not to be broken by this change is not to use the API.

That means that if there's no explicit running time guarantee given, your alternatives are to either not use that API at all, or depend on the running time you can observe or guess at.

Since people write APIs to be used, the former is obviously not what's intended. So it's pretty reasonable to consider any API without an explicit running time guarantee to have an implicit one along the lines of "this won't get vastly worse" because your only other choice is not to use it at all.

I think you're alluding to a generic, implicit promise of reasonable performance. I definitely think this is a valid assumption to make, so you are right to point it out. Any API function needs to have reasonable performance, or else there is no point in using it and it is not serving its purpose. It is very true that people write APIs to be used, and if their performance is unreasonably slow, they won't be used. This makes complete sense.

If your argument is that the String implementation change constitutes "unreasonably poor performance," as in...for most normal use cases, then that makes sense. I disagree with it, but it makes sense to argue that if you think that is what's happening. That goes beyond the implementation vs. contract discussion, and maybe that is the real issue many people have. Maybe some feel like the performance hit will affect so many use cases that are common for String, that it is an unreasonable performance change.

I have no opinion about this particular change, as I haven't looked into it much and I haven't done any Java in a while. I'm just pointing out that there is something of an implicit time complexity guarantee with any API, so the lack of an explicit API contract isn't enough to say that code which breaks due to a change is at fault.

Reply on news.ycombinator.com