Live data from Hacker News

Dynamic Swift

mjtsai.com

51–54 of 54 posts

Re: Dynamic Swift

#51
Perspective: I both develop in Swift and manage a team of 5 iOS engineers (including me). The majority of our project now is in Swift, including over 8 dynamic modules/frameworks and 10's of thousands of lines of code (all that to say it's not a small project).

I have to agree that there are some pain points with Swift:

- I developed a persistence layer (not Core Data), and had to rely on a "translation layer" that all clients must implement in order to use it. It ends up being about 100+ lines of glue code for each model we want to persist. Not ideal. - Retrieving data from API services and converting the data (JSON) into models results in a lot of glue code... A ton it. - I've frequently had to hack my way around the lack of Generic Protools (using base classes instead). - Compile times suck. Feels like I've been thrown back a decade in this regard.

Despite these issues, not a single one of us would go back to objective-c. Overall, the velocity of our team has only gone up since we started using Swift:

- Type safety and Optionals have removed an entire class of bugs in our app, freeing up more time to write features. - Generics have added a level of clarity to the code base that wasn't even possible before. - The code base is easier to understand, easier to maintain and easier to modify. - Oddly, the need to write Unit Tests and use Swift has literally "forced" us into protocol-based programming...a good thing IMO. I'm seeing much better software architecture as devs can't lean on automatic mocks, forced instead to create protocols and keep classes/types separated and injectable. To be clear, it's more difficult to write that kind of code, but the quality of code has gone up since we switched to Swift.

I've noticed that some of the complaints about the lack of dynamism in Swift don't seem as valid. For example: Responder chains. This is easily done using a protocol (something we did for deep linking within the app).

Other issues, like observability, can be solved by things like React, and using Observables. Not only is React more powerful than KVO, but it's obvious where it's being used in the code base (because you're using an Observable).

I can't deny that there are places where having dynamism would certainly remove a lot of glue code. But my experience is that the "old guard" (me included, really) relied too much on the dynamic nature of objective-c to solve problems that could have been better solved in another way.

While I would like to see dynamism come to Swift, I would NOT want to see it imported wholesale from objective-c, but instead conservatively placed and annotated in such a way as to say to those of us who use it: "Here be dragons...proceed at your own peril".

Re: Dynamic Swift

#52
post #36
post #29

Earlier quoted context omitted.

> Responder Chain Protocols, or even a superclass. > NSUndoManager Closures. Even Apple has moved away from target/selector for new APIs in favor of blocks. > Key-Value-Coding/Key-Value-Observing/Cocoa Bindings An equivalent is easily implementable in pure Swift, see ReactiveCocoa's PropertyType/MutablePropertyType, and I'm sure someone has packaged something similar as a µframework so that you don't need to add all…

It doesn't sound like you've read any of the articles. There are details and tradeoffs and limitations found by the people talking about them. And there is a massive knowledge vacuum because if there is a good solution, it's not something that is obvious and well discussed by Apple. Ignoring and dismissing them doesn't make them actually go away. Here's two on just the Responder chain: http://inessential.com/2016/05/…

I've read those articles, but I still don't see why you need dynamic features to implement the responder chain.

UIResponder can have implementations of all the methods that return NO. You override whichever you want to, and return YES. Then, instead of checking if a selector exists and then invoking it, the system just calls the method, and if it returns NO, it moves on to the next responder in the chain.

What am I missing?

Re: Dynamic Swift

#53
post #36
post #29

Earlier quoted context omitted.

> Responder Chain Protocols, or even a superclass. > NSUndoManager Closures. Even Apple has moved away from target/selector for new APIs in favor of blocks. > Key-Value-Coding/Key-Value-Observing/Cocoa Bindings An equivalent is easily implementable in pure Swift, see ReactiveCocoa's PropertyType/MutablePropertyType, and I'm sure someone has packaged something similar as a µframework so that you don't need to add all…

It doesn't sound like you've read any of the articles. There are details and tradeoffs and limitations found by the people talking about them. And there is a massive knowledge vacuum because if there is a good solution, it's not something that is obvious and well discussed by Apple. Ignoring and dismissing them doesn't make them actually go away. Here's two on just the Responder chain: http://inessential.com/2016/05/…

I also agree with chris_7 that I'd prefer NSUndoManager to use blocks rather than selectors.

Re: Dynamic Swift

#54
post #15

Earlier quoted context omitted.

The Objective-C old guard has had a very hard time dealing with Swift. For a couple years now, every 3 months they have another blog post hand-wringing about what they used to do in Objective-C, how they can't in Swift, with the implicit warning this is worrisome and _needs_ to be reimplemented in Swift, or Swift isn't a serious contender long-term. Most of the of the community seems to have moved on, with the unders…

> That matches exactly with my experience being pressed into service writing Rails code for a couple months - the development experience felt like the Stone Age compared to Swift, even if I could write a method ~20% faster Me, too. At work, I am on two different projects at the moment: an SDK and application written in Swift, and a run-of-the-mill Rails app. Going back to the Rails app is frankly gut-wrenchingly bad.…

Absolutely agree. I have only one or twice used method swizzling, but when I have used it it has absolutely saved my bacon in the face of nasty platform bugs. Fighting fire with fire, so to speak.
Post reply on HN