Hacker News Reader

Comment by lapcat | Hacker News Reader

> Curious, which part of that Objective C code doesn't make sense to you?

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.

View on HN

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

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

Reply on news.ycombinator.com