8 ms·

> For one thing, the initWithDependency: method ignores its argument! Yes good, callout, I edited the code to fix this mistake > Does the class even need to d

> For one thing, the initWithDependency: method ignores its argument! 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.

lapcat 3y ago
> 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. 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.

lapcat 3y ago

> 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. 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.