My point is that you are completely ignoring an entire class of risk that has a real-world $$$ cost. Every time I have to use a framework under this proposal, I am now completely at the mercy of the author. In the case of open source frameworks I can at least make a fork, but for closed source frameworks (often from large companies where us using their framework has been negotiated by the bosses) you have now just added weeks to my development cycle while I wait for big-company-who-doesn’t-really-care-that-much to update their stuff. (sure I can work on other things during that time, but delaying a launch isn’t free)
Are you offering to explain to my boss/client why I can’t add the feature in a reasonable timeframe like I can with Objective C frameworks? That it may not even be possible now in Swift even though the Android guy just did it in a few hours?
Do you know what I am going to tell my boss/client? "Don’t use Swift for frameworks” and “Try to avoid partnering with companies that have Swift frameworks”. "It is too much of a risk". "We are giving them too much control over the future of our product…" I mean, it even affects the prices that companies can charge for crappy frameworks. If I am asking for a bunch of features that I NEED them to add to provide a basic feature, that affects negotiations/price (vs a world where I can add it myself if needed). Sealed-by-default gives them leverage.
To use your bridge analogy, which is better in the case that you haven’t provided a bridge for me:
1) I build my own bridge knowing that I will need to maintain it periodically (usually on a predictable schedule)
2) Have everyone wait for 6 months (loosing $ the whole time) while I plead with you to build the bridge for me.
By definition, the least thought through frameworks are the ones most likely to need workarounds, but under this proposal, they are also the ones we will be unable to fix. I think some people think that this proposal will make them fix those frameworks or make them disappear… but they are often from big brand name companies, who don’t care that much because tech isn’t their main business. In my experience, we can get the changes we need, but it takes anywhere from 2 months to a year. Being able to patch in a stop-gap while we are waiting is very important for the health of the business.
For example, I had a recent client that called me in a panic (unfortunately I have somehow gotten a reputation as someone to call for impossible tasks) because they had a demo they needed to show for a potential multimillion dollar deal and it just wasn’t working. The tech they had used as a base wasn’t doing what it was supposed to… and the fixes were 3-6 months away (the demo was a week and a half away). I would call the support guy for the tech, and they would tell me “that isn’t possible yet. Just wait for the update”. I would call them back a couple of hours later saying “If someone else asks, here is how I did it…” Was that code beautiful? No. Did I get all the features in that demo working? Yes, with something like 1 hour to spare. The demo went very very well.
Should I have let that deal fall through because it wasn’t the “proper” ideological way to write code? Sometimes things just need to get done and there isn’t another way…. A few people have suggested that these types of concerns aren’t relevant, but I find them very relevant to my everyday life. This is the first proposal with the ability to actually cost me (and my clients) money.
I am completely ok with needing to type “unsafe” (or similar) to acknowledge and take responsibility for my actions in those situations. I understand those modifications might break when the framework is finally updated in 3-6 months (hopefully we can even remove them at that point). Just don’t “safety" my clients out of business by making working around bad frameworks impossible.
One last analogy. At a restaurant, they might be afraid I would cut myself with a sharp knife. They don’t force me to wear mittens or otherwise make using knifes impossible. They give everyone butterknives, but I can always get a real knife if I ask for one. If I order steak, I don’t even have to ask… they just bring me a real knife. This is how Swift has been and should continue to be IMHO. Prevent me from subclassing accidentally, but if I acknowledge the risk, let me do it. “Safe-by-default” != “Impossible-by-default”
Thanks,
Jon
P.S. This discussion is reminding me of one of my favorite blogs. He often talks about the tension between doing things right, and actually getting out there and doing things. Here is a good/relevant article:
http://prog21.dadgum.com/87.html
···
On Jul 10, 2016, at 7:48 PM, Rod Brown <rodney.brown6@icloud.com> wrote:
On 11 Jul 2016, at 12:33 PM, Jonathan Hull <jhull@gbis.com> wrote:
It is pre-breaking in that it is the exact same code that doesn’t work in both cases (only in the pre-breaking case, a bunch of other code also doesn’t work). I know it feels different because it “was never possible” vs our change being the cause, but it is one of those things like me giving you $5 or giving you $10 and later taking back $5. As humans we are loss averse so we devise strategies to hide the loss from ourselves.
I completely disagree with this.
Not providing someone something due to risk of breakage is not the same thing as “giving it and taking it away”. We don’t build bridges out of spare parts and tell people “We build it but we expect it to break at some stage, so use with caution.” You either build it correctly, or you don’t let people cross the bridge. At All.
This isn’t about “loss averse”. This is about risk management.
Where does the line lie on risk? That’s ultimately something the core team will have to decide.
-
-