Hacker News Reader

Comment by Cyph0n | Hacker News Reader

I guess Swift still isn't widely adopted inside Apple. Or it could be that CareKit was started before Swift. Anyone know for sure?

View on HN

The sample app is written in Swift, https://github.com/carekit-apple/CareKit/tree/master/Sample/...

Apple has publically recommended Objective-C code to not call Swift libraries, but rather advises Swift calling Swift frameworks or Swift calling Objective-C frameworks.

Ah, I see. That makes sense.

Oh I didn't know that. It still seems weird. Objective-C has always been hard for me to read and yet I love reading code—especially Apple's—so I guess the struggle will continue. Even if that means I can't really contribute to this.

runOnSentencesAsMethodNamesDidNotAppealToYou ?

That's the best bit, and makes reading blocks of code incredibly efficient. You can observe a method being called like

  [table allowsMultipleSelectionDuringEditing:YES]

And even though you might not remember that UITableView method, once you read it you immediately know what it does, often saving you a round trip to the docs.

> often saving you a round trip to the docs

that's optimistic

those methods rarely do exactly what you think, they can be an overloaded version of another method

and more frequently there is another method with a similar method name, or one is singular and one is plural and it becomes very inefficient because the method names look the same, the exact reason why the english language has spaces and punctuation to begin with

Well duh, obviously. They're not going to concatenate entire paragraphs of documentation into the method name. Like so many things it's a matter of degrees. If the method was called table.multiSel() then you'll be more likely to need to consult the docs.

It's not optimistic in my experience. Much of the time when doing code review or bug hunting other people's code, it's less about knowing exactly what a particular method does, as much as being able to rapidly estimate your way to relevant areas.

If nothing else, verbose names can make it faster to ignore irrelevant code.

Where was that?

To further expand on Apple's recommendation to not make Swift libraries just yet — It's also an matter of compatibility. You could certainly make a Swift framework, but given that Swift as a language is changing every 6 months or so right now, it doesn't make sense to make a framework using Swift.

You could easily hold up another project if you haven't changed your Swift code to the latest, or the opposite is true as well: Your Swift framework is up-to-date with the latest language, but the app using your framework is not, etc.

Reply on news.ycombinator.com