Comment by klodolph | Hacker News Reader

Comment by klodolph | Hacker News Reader

Parent Full thread

This is a cultural issue much more than a technical issue. I can relate to both sides. "I want to be able to patch anything myself," versus "I want to be able to reliably reason about how my module works."

The rhetoric on both sides can quickly get stupid. This is one of the major ways in which languages are divided. Ruby folks are used to being able to monkey patch everything, and Python folks tend to avoid it even though they can. JavaScript programmers are divided on the issue: should you add a method to Array.prototype, or is that just asking for trouble? I've certainly seen my own fair share of bugs and crashes caused by programmers substituting types where they shouldn't, and seen my fair share of frustrating limitations in sealed modules that should just expose that one method I need, dammit.

Objective-C leaned towards the "go wild, do anything" approach, which grew quite naturally out of the minimalistic "opaque pointer + method table" foundations for object instances. One of the reasons that you make such a choice in the first place is the ease of implementation, but in 2015, writing your own compiler is easier than ever. So Apple is quite naturally considering application reliability as a priority (since they're competing with a platform that uses a safer language for most development).

Unfortunately, it's a cultural fight where one side or the other must necessarily lose.

Because I have no experience with Swift, could someone more informed explain this to me? How would my subclassing an Apple-provided class and overriding its methods affect anyone but me? In Python, if I write:

    class MyRequest(requests.Request):
        def get(self): do_something_stupid()

then my coworkers can still use `requests.Request` itself without getting my bad behavior, and if they find themselves looking at a flaw in my code, they know not to blame the upstream author. What's different about the Swift situation?

I'm kind of horrified at the idea of an OOP language that wouldn't easily let me override a parent class's behavior. If I break something in the subclass, it's on me to fix it. That never reflects poorly on that parent class.

Sure, it only affects you. The problem is that changes to superclass can now break your code.

For example, perhaps right now the function looks like this:

    def get(self, url, method='GET'):
        ...

    def post(self, url):
        self.get(url, method='POST')

You override get, to add some additional functionality. All is fine.

Then somebody realizes that the original code was silly, and rewrites it:

    def get(self, url, method='GET'):
        if method != 'GET':
           print "DEPRECATED!"
        self.request(url, method=method)

    def post(self, url):
        self.request(url, method='POST')

It seems to do the same thing, and probably passes all the same tests. But suddenly, now your code doesn't get called for post requests and your additional functionality breaks in a mysterious way.

Perhaps its still your fault for doing a bad job subclassing, but its going to look like its the fault of the person who fixed the parent class.

> changes to superclass can now break your code

The same exact thing happens when using composition.

When a point release of the operating system breaks your app, the user doesn't care (or understand) whose fault it is, they're just ticked off. Apple cares about that.

How is that different from your code not working because of an Apple bug (which they take months or years to solve in some cases)?

The end result is still a broken app (just due to a different reason), and the user will blame either the third party programmer or Apple, and mostly usually the programmer.

Part of the reason why it's hard to fix bugs that people have worked around is because the fix often breaks the workarounds. Which causes a problem for Apple either way; either they can leave the bug in and let everyone work around it, or they can fix the bug and break all of the myriad apps that use the workaround. Depending on the circumstances, they can actually put workarounds into the frameworks to preserve bugs for apps linked against older versions of the SDK or for apps with specific bundle IDs, but not every fix is amenable to that kind of solution.

Which is to say, there's a good argument for the idea that reducing the ability to monkey-patch framework classes will make it much easier to actually fix bugs in the frameworks.

>Part of the reason why it's hard to fix bugs that people have worked around is because the fix often breaks the workarounds.

That was a problem for Microsoft, Apple, from all we publicly know from their releases, never treated that as a problem. They went ahead with the fixes even if it broke previous workarounds.

If an OS upgrade breaks lots of programs or even one heavily used program, chances are users will blame Apple, not the developers of said apps.

Also, part of the reason that it takes them long to fix certain bugs may be concerns about seemingly internal changes breaking applications. They cannot refactor methods (rename or even change an argument list) in any class they ship because someone, somewhere, might override one of its methods.

In that light, I think the change makes sense. Of course, Apple could just add private/sealed to all their classes, if only just before shipping, but why make the typical choice more work to write than the exception?

>If an OS upgrade breaks lots of programs or even one heavily used program, chances are users will blame Apple, not the developers of said apps.

The user just knows said program doesn't work. And it's not necessary that an OS upgrade will break lots of programs that a user has, it can break this or that program in subtle ways, or classes of programs (e.g. those using the X api) of which a typical user will have only few installed.

E.g. if it breaks third-party camera apps, users might not normally have 5 of those, to see that they all break at the same time, but just 1 additional on top of Apple's (if that).

The user knows the program worked yesterday, before (s)he upgraded the OS. Correlation is not causation, but I think you will get more hits googling "<OS> update breaks <application name>" than googling "<OS> update uncovers bugs in <application name>" for whatever currently used choices you pick for "<OS>" and "<application name>".

Users don't always use all of their apps apps every day. If you go to the app 20 days after updating the OS, good luck remembering the OS update 3 weeks ago and deducing it was that which broke it.

Especially since, with the ability for apps to upgrade automatically, many don't even keep track when this or that app was updated.

Of course it usually is even more obscure, e.g. the bug only affects PART of the app's functionality, a part which you might have not invoked in your last run before the OS update. So, another deduction for many would be that that feature works intermittently because it's not coded well, etc.

Besides, even when the user can deduce that the OS broke the app, they don't complain to Apple, but to the software maker "fix your app", "where's the update release?", etc.

Users even blame us when the App store fails to download updates and leave 1-star reviews

The difference is that in that case the bug never makes it out to the end user.

Apple writes a new API. It has a problem. You try to adopt it, it doesn't work. You don't just ship that, you do something else.

Unpleasant, but doesn't hit the user.

You missed the obvious fact that the bug change might happen to an API you already use. It doesn't have to be a new API -- just a new release of it by Apple.

So the problem remains: you can't easily extend the class with your own fix to bring out a bugfix release for your app.

If you're the final user of an API, then yeah, go for gold and change whatever you want.

But if you're working in a team (or contributing a patch to a Github project), and you override something crutial like String.subtring(), then things could get out of hand.

As pcwalton points out above, allowing (potential) dynamic dispatching behavior for every method is a significant performance drag, especially when (as with Swift) you won't be supplying a JIT to devirtualize and inline at runtime.

I don't really agree that JS devs are divided on this issue, though of course it's a huge community and I could just be talking about my corner of it. But we saw what happened when two libraries wanted to alter the same built-in. Polluting the global namespace and altering built-ins is a no-no.

It was very divided 4-5 years ago, predominantly when underscore and jQuery were both champing at the bit to be the top utility library. It's shifted towards not monkey patching, but it's not not absolutely decided for many developers.

It was very undivided 8 years ago - it was common knowledge to never, ever override the prototypes of built-in objects. In fact, a major reason that JQuery won out over Prototype & Mootools was because the latter two monkey-patched built-in prototypes, and as a result were incompatible with each other or with any other library that overrode built-in methods.

IIRC, this was an interview question at Google when I applied in 2008, and I think one of the reasons I got the job was because I was aware of all of the pitfalls of it.

I managed to skip using underscore, but from a quick glance through the library, isn't the reason it's called underscore because it provides '_' as a namespace for all the utility functions, rather than altering Array.prototype the way Prototype did?

I read the underscore source code a few years ago. My memory may be failing me, but I don't think it altered any builtins.

When you control all the source, being dynamic is stupid.

When you're coding against a closed-source, external, 3rd party platform, being dynamic is really helpful.

Simple as that, IMO.

(From a distance, Swift sure does have a strong C++ vibe.)

Reply on news.ycombinator.com