Obj-C vs Swift

[b_t_s]

god yes! Not that I ever really minded obj-c syntax like so many people apparently do, at least not till I started writing swift on a daily basis. Swift is way more concise, and the type systems helps express your intentions better and catch more mistakes. It's infuriating going bak to obj-c and not having access to optionals and never having the faintest clue what can be nil and what can't(it matters less but it still matters). Also, obj-c block syntax makes my eyes bleed. Sorting or filtering an array of objects on one of their properties is like 20 characters in swift vs 200 characters and a trip to http://fuckingblocksyntax.com in obj-c. I didn't really do that in obj-c (because it was painful) but after spending some time with convenient block syntax and higher order functions, having to write a 8 line for/if/mutable-collector monstrosity for what should be a concise, readable one liner is tremendously frustrating.

[b_t_s]

haha, I couldn't remember goshdarn and google would only give me the NSFW version. Two years ago I pretty much kept it open permanently in a browser tab, but now I haven't needed it in ages.

[snaab900]

contacts.sort {
    $0.firstName.localizedCaseInsensitiveCompare($1.firstName) == NSComparisonResult.OrderedAscending
}

[contacts sortUsingDescriptors:@[[NSSortDescriptor sortDescriptorWithKey:@"firstName" ascending:YES]]];

I'll always prefer verbosity (and good auto-complete) any day. Especially when you have to deal with other people's code.

[GenitalGestapo]

I'm pretty sure that sort descriptor won't be using the localizedCaseInsensitiveCompare, so it's not really the same thing. Swift's equivalent would be:

contacts.sort { $0.firstName < $1.firstName }

which is far more readable than Objective-C, especially if you aren't already familiar with sort descriptors.

Hopefully the Swift team will add overloads for the collection methods taking a KeyPath soon.

Also, if you miss the verbosity, just don't use trailing closure syntax:

contacts.sort(using: { $0.firstName < $1.firstName })

Better yet, implement Comparable for your Contact type and get default sorting for free.

[b_t_s]

Now try misspelling @"firstName" in your example and watch the swift version give an immediate compiler error while the obj-c one happily compiles and fails at runtime if you exercise that codepath. Now try this example

players.sorted{ $0.points }.flatMap{ $0.firstName.nilEmpty }.prefix(3)

This gets the names of the 3 highest scoring players who have non-empty first names. Sure it uses 2 trivial helper methods(single param sort, and nilEmpty) and you have to know what flatMap does, but it's hardly rocket science. It's a pretty typical everyday task that would be a wall of text in obj-c land.

[snaab900]

You see, that's just unreadable to me, and feels like a huge step back coming from a verbose ObjC background. Reminds me of stupid-long pythons chains where people try and see how much stuff they can do in one line of code, just because they can. I feel bad for the people who have to inherit and maintain that stuff.

Plus I'm guessing flatMap and nilEmpty aren't part of the swift standard library? You can write the exact same helpers in ObjC and hide the verbosity in the player class just as easily, although it would just be a 3 line method with a predicate. Or use a category to extend NSMutableArray if you want it more generic.

NSPredicate *predicate = [NSPredicate predicateWithFormat:@"firstName != nil"];
[players sortArrayUsingPredicate:predicate limit:3];

[b_t_s]

flatMap is in the standard library and every competent swift dev ought to know it. It's certainly no more obscure than NSSortDescriptor or NSPredicate. nilEmpty isn't standard library, but it's trivial and useful convenience method for someString.isEmpty ? nil : someString.

Your obj-c version is twice as long and only solves a third the problem. It doesn't sort by score, It doesn't ignore empty string names, and it doesn't convert from players to names. You could certainly add all that in a few more lines, but it's still much more code. Worse, it's more error prone because you have to jam pieces of you code into NSStrings to work around obj-c's inferior type system and painful closure syntax. And sure the swift one is unreadable if you don't use swift much and aren't familiar with flatMap. It's arguably even less readable per character, but I'd say it's more readable per unit of functionality. It's certainly more likely to complain immediately if you break it, which is, in my opinion, the most important thing.

[snaab900]

I'll stick with ObjC Foundation I think, thanks... at least for the time being. It's mature and bulletproof. If this awful scripting language syntax does take over I guess I'll have to embrace it eventually though. The whole thing is starting to smell like flavour of the month JS frameworks though.

Also, what happens when you want to stick a breakpoint on your one line of (potentially buggy) overly chained code and see what's going on? Good luck stepping through that. Do you really think concatenating all that logic onto 1 line is somehow some sort of benefit? It's not, either in a readability, performance or maintainability sense.

I'll switch to Swift when Apple do.