[flagged]
You appear to be complaining about some anecdotal experience of yours. Exactly how many different teams have you been on where this happened?
It should be noted that the article author has been a lone developer since 2016 and hasn't belonged to or "held back" any teams during that time.
In any case, rewriting existing, working code is usually a bad idea regardless of the language, so if that's what you were aiming for on your team, it wouldn't be surprising to meet resistance on that.
> Objective C actively makes it harder to do such best practices
Completely untrue.
Here is the Swift code:
class Dependency1 {
}
class Object1 {
private let dependency: Dependency1
init(dependency: Dependency1 = Dependency1()) {
self.dependency = dependency
}
}
@interface Dependency1 : NSObject
@end
@implementation Dependency1
@end
@interface Object1 : NSObject
- (instancetype)initWithDependency:(Dependency1 *)dependency;
- (instancetype)init;
@end
@interface Object1()
@property (nonatomic, strong, readonly) Dependency1 *dependency;
@end
@implementation Object1
- (instancetype)initWithDependency:(Dependency1 *)dependency {
self = [super init];
if (self) {
_dependency = dependecy;
}
return self;
}
- (instancetype)init
{
return [self initWithDependency:[[Dependency1 alloc] init]];
}
@end
In other words, the sheer verbosity of Objective C will make even the most disciplined developer start cutting corners to reduce effort, which ultimately leads to codebases which are messier, harder to test and less flexible.
And finally, looking at the example above, is it really true that Objective C is easier to learn and understand than Swift? The code forces you to learn:
* What is an NSObject?
* How to create a private category on an class
* What does "alloc init" do, and why is it different than "new"?
* What is the difference between `self.dependency` and `_dependency`, and why does one let me change a "readonly" property?
* Why would `super init` return nil, and what does that mean?
For sure Swift also has its share of nuance, but I feel like the Objective C nuance is just baggage, while the Swift nuance opens the door to a richer feature set.
[edited] updated code for correctness
Maybe try actually writing code in Xcode.
And maybe write your comments in a text editor and finish them before you post...
* Creating a header and implementation for each object
* Using a private category to keep a variable private
* Implementing multiple constructors because you can't have default variables.
Can you suggest a more concise way to accomplish any of the above?
For one thing, the initWithDependency: method ignores its argument! (Also it's unclear why it needs 2 blank lines just to jack up your line of code count.)
Does the class even need to declare -init? That's 6 more lines of code added for no apparent reason.
In general, everyone acknowledges that Swift is more terse and Objective-C is more verbose, so if your main complaint is just the number of lines of code, that's not particularly interesting.
Yes good, callout, I edited the code to fix this mistake
> Does the class even need to declare -init?
You are basically making my point. Its totally normal engineer's reaction to look to erase this boilerplate by removing the dependency injection, or using a singleton. Overtime, those decisions make the codebase worse. In Swift, you simply don't have to make this tradeoff.
> if your main complaint is just the number of lines of code, that's not particularly interesting
Verbosity alone is a major problem - why would it be a good idea to use a language which takes more time to read and write to accomplish your goal? It's a disadvantage.
Another issue is a lack of expressiveness and a dumber type system. Stuff like union types and optionals all allow you to express your system in a more airtight way. The lack of these features leads to, you guessed it, more boilerplate in ObjC.
Ultimately, noone is arguing that you should rewrite your existing ObjC in Swift - if your code exists and works, leave it alone. But the article is arguing that Objective C is a "better" language for writing iOS apps, which doesn't make any sense for all the reasons above.
You made me look at two classes, totally out of context, that didn't even work with the first code presented. And I have absolutely no clue how they would be used, so I can't properly evaluate them.
The boilerplate is fine as far as I'm concerned; you were the one who was obsessed with the number of lines of code, and it seemed to me you were exaggerating them for no apparent reason, so that's why I was looking to remove some.
> why would it be a good idea to use a language which takes more time to read
I don't agree with that. A more verbose language can be easier to read.
> and write
It's premature optimization. Personally, I don't spend the majority of my time typing in code. I spend a lot of time thinking, designing, running, testing, debugging, etc. The time spent typing in the code is not a big worry for me. If Swift is faster to type, but the compiler is a lot slower, and the damn debugger doesn't even work, that doesn't seem like a good tradeoff to me.
> But the article is arguing that Objective C is a "better" language for writing iOS apps
I was actually arguing that Objective-C is a better language for writing UIKit iOS apps, which is a more specific claim, given that the underlying frameworks are themselves Objective-C, for the reasons explained in the blog post.
What's holding back the team is Apple.
Apple could open-source Swift and Xcode (both really need the help) and port the relevant bits to Android and Windows. They could release Metal to the world or throw in with Vulkan.
The fact that they haven't tells you that all Apple is interested in is keeping you captive.
The caveats are:
- Xcode indeed isn’t, but you can use sourcekit-lsp for Swift development with some compromises. The experience has really improved the last few months thanks to the Swift Server Work Group [3].
- Apple platforms have their own Foundation implementation and the open-source one is incomplete.