3 ms·

I agree with the author on choosing the right tool for the job, 100%. But I think that obj c is less and less the right tool. Just my 2 cents. With respect to

I agree with the author on choosing the right tool for the job, 100%. But I think that obj c is less and less the right tool. Just my 2 cents. With respect to the point about header files. Of course you can have an API in swift either by having your class conform to a protocol or using visibility modifiers. Also the point about verbosity, the benefit is often in reading others code and being able to quickly grok it. Swift also has a number of functional methods (map, reduce, etc) that are really nice for this. I agree stability and compile times were an issue, but I think they’re getting to a fairly good place now. And lastly I like the additional protections swift offers when working in a large team with varied skill levels. Just because the author has been able to avoid crashes, it does not mean this will be the case for a junior dev on the team (and code reviews can miss some things).

dinkblam 3y ago
> Swift also has a number of functional methods (map, reduce, etc) that are really nice for this. writing functional extensions for base classes in ObjC takes like an hour and every seasoned ObjC programmer has those extensions in his toolkit/library anyway. so that doesn't sound like a killer argument for switching to Swift.
- happytoexplain 3y ago
  This is unrealistic. Tons of "seasoned" ObjC programmers will take one or two orders of magnitude longer than an hour to write home-grown replacements for all the functional methods, and they frequently turn out limited in some way, or at least less performant. Maybe you're implicitly arguing that those developers are irrelevant to the conversation of Swift vs ObjC, and I would disagree there too. Languages need to strike a balance between catering only to the most highly experienced and specialized developers, and hobbling themselves to be "idiot proof".
- KerrAvon 3y ago
  The problem with map/reduce/etc in ObjC is twofold: - Objective-C doesn't support generic value types for function arguments - Objective-C can't optimize away method calls and therefore value boxing What that means in practice is that you can't write a generic version of map/reduce/etc without it being very slow even for things that should be very fast. If you want one that works efficiently for value types like integers, you must write a specialized version for each type. (I have written and sometimes use for convenience ObjC map/reduce/etc implementations.)

dinkblam 3y ago

> Swift also has a number of functional methods (map, reduce, etc) that are really nice for this. writing functional extensions for base classes in ObjC takes like an hour and every seasoned ObjC programmer has those extensions in his toolkit/library anyway. so that doesn't sound like a killer argument for switching to Swift.

happytoexplain 3y ago
This is unrealistic. Tons of "seasoned" ObjC programmers will take one or two orders of magnitude longer than an hour to write home-grown replacements for all the functional methods, and they frequently turn out limited in some way, or at least less performant. Maybe you're implicitly arguing that those developers are irrelevant to the conversation of Swift vs ObjC, and I would disagree there too. Languages need to strike a balance between catering only to the most highly experienced and specialized developers, and hobbling themselves to be "idiot proof".
KerrAvon 3y ago
The problem with map/reduce/etc in ObjC is twofold: - Objective-C doesn't support generic value types for function arguments - Objective-C can't optimize away method calls and therefore value boxing What that means in practice is that you can't write a generic version of map/reduce/etc without it being very slow even for things that should be very fast. If you want one that works efficiently for value types like integers, you must write a specialized version for each type. (I have written and sometimes use for convenience ObjC map/reduce/etc implementations.)