3 ms·

My experience is the opposite: using Swift for Apple ecosystem development basically removed all of the benefits that Swift the language offered. It’s clearly d

My experience is the opposite: using Swift for Apple ecosystem development basically removed all of the benefits that Swift the language offered. It’s clearly designed as a general purpose language, and its adoption mostly curtailed by this reputation.

ChrisMarshallNY 5y ago
I’ve been using Swift to develop Apple software since 2014. I’ve released quite a few apps, written with it. Before that, I used ObjC. I’m extremely happy with Swift. As far as adoption goes, many large codebases are likely still ObjC; simply because of hysteresis. Major architectural shifts take a lot of time, money and risk. That’s one reason I don’t feel that much urgency to jump on the SwiftUI/Async stuff (but I like what I see). I’m interested in shipping, and shipping is almost always a couple (or more) steps back from “the bleeding edge.” In my experience, there’s not much of a downside to waiting for tech to mature and stabilize, other than not having jargon on my CV. Swift was unusual for me. I started learning it, and releasing apps in it, right away. It was a gamble, and it paid off. There’s lots of folks that are probably just getting started with Swift, now.
- eyelidlessness 5y ago
  To be clear, I quite like Swift and did from day 1. Granted I’ve only tinkered with it. What I didn’t like was interacting with Cocoa APIs. I found it difficult to use Swift’s protocols and structs in a FP style, because Cocoa isn’t designed that way. I imagine this has gotten a lot better since, particularly with stuff like Swift UI. That said, I’d personally find Swift more compelling to use as a server language.
  - ChrisMarshallNY 5y ago
    Cocoa uses classic MVC, and actually started from NextStep (last century). UIKit smoothed it out a bit, but it’s still MVC/OO, under the hood. SwiftUI was developed from the ground, up, to use FP concepts, and things like Protocol-Oriented Programming. I’m looking forward to learning it, but the fact that most of the Apple world runs on tech from a design that was developed in the 1980s, should be an object lesson in the structural integrity of “classic” OO, and the MVC pattern. We rubbish the past at our peril.
    - eyelidlessness 5y ago
      > We rubbish the past at our peril. It’s not as if functional programming is newer or untested. The reason most of the Apple world continues to use these paradigms is because the codebases which do continue to exist. Inertia alone would keep ObjC around for another 20 years, and the software industry is almost totally rewrite-averse. Anyway, the rest of your comment is exactly what I’m talking about: Swift and its value propositions just don’t match up with the things it has had to interop with. I’m hoping Apple actually dedicates resources to SwiftUI documentation and adoption, and that gradual uptake is enough to stop worrying about fitting Swift to highly stateful OOP APIs that weren’t designed for it.
      - ChrisMarshallNY 5y ago
        > It’s not as if functional programming is newer or untested. It's not about maturity. It's about suitability for the purpose. FP is probably not ever going to be easier to use, but it is safer, and can be used to safely implement algorithms of greater complexity than other paradigms. It needs to be coupled with a reactive, event-driven system (that has state, but the state can be hidden in end nodes or a model), in order to deliver a great UX; which, at the end of the day, is what this is all about. You can't have UX without state. It's all about where the state is maintained, and how many copies of it need to be made, as the program executes. For example, say we have a checkbox that reflects/controls the state of a variable in our calculation. The on/off state is important. If it is on, let's say that we will introduce a compensating coefficient. If it is off, that coefficient is not applied to the function. The state is not a part of the function, so it doesn't make sense to incorporate it (or even knowledge of the existence of that state) into the function. Nevertheless, it is a crucial component of the user experience, and needs to be maintained somewhere. The best bet may be to try to keep the state in the checkbox object, itself, and query it at runtime, or use a messaging system to be informed of state changes. I've always found a central model to be annoying. If the UX is at all complex, the model can get crazy, and turn into a richly productive bug farm. Federated/franchised state can have its own issues, like when there's a lot of interaction/dependency between state nodes. That can get crazy, too, and difficult to debug. So far, no one has come up with a perfect pattern, but I kind of like the idea of a "composer" pattern, that queries federated states, and "weaves" them together, at runtime, as opposed to a model that sends directives out to a set of nodes. The issue that lots of folks have with OO, is polymorphism. That is not really the same thing. It can make discovering an algorithm difficult, as functionality can cascade through a whole bunch of levels, and debugging can be a real pain in the butt. If anyone has had sticky CSS specificity issues, they have an idea of what it can be like to grope around in a polymorphic codebase. Protocol-oriented programming is not a panacea, either. This is especially true, when mixed with polymorphism. I wrote about a strange issue I encountered, here[0]. But polymorphism isn't bad. It's just a tool, and we don't use a nailgun as a hammer. Like so many tools, people have tried to shoehorn it into unsuitable configurations, and refuse to consider other, more suitable tools. I see FP proponents, doing the same thing. Swift is nice, because it has a rich toolbox, allowing us to select the right tool, for the right job, without having to do complex linking games between libraries of different languages. [0] https://littlegreenviper.com/miscellany/swiftwater/the-curious-case-of-the-protocol-default/ https://littlegreenviper.com/miscellany/swiftwater/the-curio...
- coldcode 5y ago
  In my last job until I retired this year, I spent 5.5 years writing only Swift at a large (not FAANG) company. It took the entire mobile team about that time to retire most of the Obj-C codebase(s). Swift is by far my favorite language despite having spent decades with C/C++/Java and Obj-C. I am still writing Swift despite being retired but as part of my art generation work now.
  - eyelidlessness 5y ago
    > I am still writing Swift despite being retired but as part of my art generation work now. Anything publicly available? I’m always looking for more generative art!
    - coldcode 5y ago
      twitter @digconart not selling yet, but there is lots there
  - ChrisMarshallNY 5y ago
    > I am still writing Swift despite being retired but as part of my art generation work now. I've been "retired" for four years, and work more, every day, than I ever did, as a grunt. I write Swift 7 days a week. I really like the language.

ChrisMarshallNY 5y ago

I’ve been using Swift to develop Apple software since 2014. I’ve released quite a few apps, written with it. Before that, I used ObjC. I’m extremely happy with Swift. As far as adoption goes, many large codebases are likely still ObjC; simply because of hysteresis. Major architectural shifts take a lot of time, money and risk. That’s one reason I don’t feel that much urgency to jump on the SwiftUI/Async stuff (but I like what I see). I’m interested in shipping, and shipping is almost always a couple (or more) steps back from “the bleeding edge.” In my experience, there’s not much of a downside to waiting for tech to mature and stabilize, other than not having jargon on my CV. Swift was unusual for me. I started learning it, and releasing apps in it, right away. It was a gamble, and it paid off. There’s lots of folks that are probably just getting started with Swift, now.

eyelidlessness 5y ago
To be clear, I quite like Swift and did from day 1. Granted I’ve only tinkered with it. What I didn’t like was interacting with Cocoa APIs. I found it difficult to use Swift’s protocols and structs in a FP style, because Cocoa isn’t designed that way. I imagine this has gotten a lot better since, particularly with stuff like Swift UI. That said, I’d personally find Swift more compelling to use as a server language.
- ChrisMarshallNY 5y ago
  Cocoa uses classic MVC, and actually started from NextStep (last century). UIKit smoothed it out a bit, but it’s still MVC/OO, under the hood. SwiftUI was developed from the ground, up, to use FP concepts, and things like Protocol-Oriented Programming. I’m looking forward to learning it, but the fact that most of the Apple world runs on tech from a design that was developed in the 1980s, should be an object lesson in the structural integrity of “classic” OO, and the MVC pattern. We rubbish the past at our peril.
  - eyelidlessness 5y ago
    > We rubbish the past at our peril. It’s not as if functional programming is newer or untested. The reason most of the Apple world continues to use these paradigms is because the codebases which do continue to exist. Inertia alone would keep ObjC around for another 20 years, and the software industry is almost totally rewrite-averse. Anyway, the rest of your comment is exactly what I’m talking about: Swift and its value propositions just don’t match up with the things it has had to interop with. I’m hoping Apple actually dedicates resources to SwiftUI documentation and adoption, and that gradual uptake is enough to stop worrying about fitting Swift to highly stateful OOP APIs that weren’t designed for it.
    - ChrisMarshallNY 5y ago
      > It’s not as if functional programming is newer or untested. It's not about maturity. It's about suitability for the purpose. FP is probably not ever going to be easier to use, but it is safer, and can be used to safely implement algorithms of greater complexity than other paradigms. It needs to be coupled with a reactive, event-driven system (that has state, but the state can be hidden in end nodes or a model), in order to deliver a great UX; which, at the end of the day, is what this is all about. You can't have UX without state. It's all about where the state is maintained, and how many copies of it need to be made, as the program executes. For example, say we have a checkbox that reflects/controls the state of a variable in our calculation. The on/off state is important. If it is on, let's say that we will introduce a compensating coefficient. If it is off, that coefficient is not applied to the function. The state is not a part of the function, so it doesn't make sense to incorporate it (or even knowledge of the existence of that state) into the function. Nevertheless, it is a crucial component of the user experience, and needs to be maintained somewhere. The best bet may be to try to keep the state in the checkbox object, itself, and query it at runtime, or use a messaging system to be informed of state changes. I've always found a central model to be annoying. If the UX is at all complex, the model can get crazy, and turn into a richly productive bug farm. Federated/franchised state can have its own issues, like when there's a lot of interaction/dependency between state nodes. That can get crazy, too, and difficult to debug. So far, no one has come up with a perfect pattern, but I kind of like the idea of a "composer" pattern, that queries federated states, and "weaves" them together, at runtime, as opposed to a model that sends directives out to a set of nodes. The issue that lots of folks have with OO, is polymorphism. That is not really the same thing. It can make discovering an algorithm difficult, as functionality can cascade through a whole bunch of levels, and debugging can be a real pain in the butt. If anyone has had sticky CSS specificity issues, they have an idea of what it can be like to grope around in a polymorphic codebase. Protocol-oriented programming is not a panacea, either. This is especially true, when mixed with polymorphism. I wrote about a strange issue I encountered, here[0]. But polymorphism isn't bad. It's just a tool, and we don't use a nailgun as a hammer. Like so many tools, people have tried to shoehorn it into unsuitable configurations, and refuse to consider other, more suitable tools. I see FP proponents, doing the same thing. Swift is nice, because it has a rich toolbox, allowing us to select the right tool, for the right job, without having to do complex linking games between libraries of different languages. [0] https://littlegreenviper.com/miscellany/swiftwater/the-curious-case-of-the-protocol-default/ https://littlegreenviper.com/miscellany/swiftwater/the-curio...
coldcode 5y ago
In my last job until I retired this year, I spent 5.5 years writing only Swift at a large (not FAANG) company. It took the entire mobile team about that time to retire most of the Obj-C codebase(s). Swift is by far my favorite language despite having spent decades with C/C++/Java and Obj-C. I am still writing Swift despite being retired but as part of my art generation work now.
- eyelidlessness 5y ago
  > I am still writing Swift despite being retired but as part of my art generation work now. Anything publicly available? I’m always looking for more generative art!
  - coldcode 5y ago
    twitter @digconart not selling yet, but there is lots there
- ChrisMarshallNY 5y ago
  > I am still writing Swift despite being retired but as part of my art generation work now. I've been "retired" for four years, and work more, every day, than I ever did, as a grunt. I write Swift 7 days a week. I really like the language.