Thank you for putting your real world scenario out there too. I think you made some pragmatic points about life of application developers depending on other companies libraries and I am curious to see more debate on that point of view.
On Tue, Jul 12, 2016 at 12:00 AM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jul 10, 2016, at 7:48 PM, Rod Brown <rodney.bro...@icloud.com> wrote: > > > >> On 11 Jul 2016, at 12:33 PM, Jonathan Hull <jh...@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. > > 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 > > > - > - > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution