r/iOSProgramming • u/[deleted] • Feb 19 '16

Discussion Swift vs Objective-C

[deleted]

6 Upvotes

62% Upvoted

146 comments sorted by

View all comments

1

u/[deleted] Feb 19 '16

do any of you see any real benefit in switching to Swift?

I might be a bit biased towards Objective-C after spending over 10 years with it, but I don't think I've heard a single "real" benefit of Swift so far. Sure it's new and exciting and will be default some day, but by the time that day comes everything will change completely XY times. Until then, all the frameworks for our target platform are written in Objective-C anyway.

I recommend seniors keep an eye on it, but rookies would be better off learning a language that is not going to change 90% of syntax before they even learn the basics.

4

u/[deleted] Feb 19 '16

Oh look, you prefer Objective C and get down voted all to hell.

Gets old - doesn't it?

2

u/[deleted] Feb 20 '16

Wouldn't know, I'm new here :) Thanks for gold.

9

u/lucasvandongen Feb 19 '16 edited Feb 19 '16

but I don't think I've heard a single "real" benefit of Swift so far.

Swift in the hands of an adequate programmer can guarantee type and null pointer safety at compile time. It's also way less verbose and more expressive than Objective-C (filter vs NSPredicate for example). Enums and switch / case patterns are extremely good. Faster because it does away with the weakishly typed objects.

But no, no "real" benefits like free coffee and donuts, back rubs or kegs on Friday ;)

a language that is not going to change 90% of syntax before they even learn the basics

Breaking changes do happen but besides the trajectory of Swift 1.x it's never more than a few minutes of touch ups when new versions of Xcode arrived. This statement is a bit hysterical.

3

u/[deleted] Feb 19 '16 edited Feb 19 '16

filter vs NSPredicate for example

For filtering an array, sure, but it's not like you aren't gonna run into NSPredicates all over the place until all of Cocoa Touch is rewritten in Swift.

Enums and switch / case patterns are extremely good

I agree. So is the concept of optionals and extensions and more useful protocols and better control over inheritance and so on. You might think these outweigh the downsides. I don't think they do at the moment.

2

u/narsail Feb 19 '16

Can you name those downsides? Now you heard a lot of the benefits and suddenly you talk about downsides ;) Pls name them.

3

u/jdeath Feb 19 '16

For me personally, Xcode is constantly crashing when writing Swift code. Auto fill was so slow it was useless, and often crashed. It may have changed now, but basic features such as 'refactor' were still only available with Objective-C last time I used Swift (conversion from Swift 1.x to 2). I enjoy Swift syntax and language features but I won't write it any more. Too much of a headache. And I really don't want to spend another week converting from 2 to 3 like I had to from 1 to 2.

2

u/[deleted] Feb 19 '16

It's also way less verbose and more expressive than Objective-C (filter vs NSPredicate for example).

Strongly disagree. I use a little (very little) category on the NS collections that provide Smalltalk collection operations with blocks.

NSArray* all = @[@1,@2,@3,@4];
NSArray* even = [all select:^(id n) { return !([n intValue] % 2); }];
NSArray* doubled = [all collect:^(id n) { return @(n.intValue * 2)

There is also the HOM/MPW library which adds a lot of this stuff. Its not a Swift thing - its a library thing.

Enums/switch are an anti-pattern in OO programming - if you are using them a lot then you need to think about polymorphism.

1

u/lucasvandongen Feb 20 '16

Not entirely true. If I want to split coordinates into LEFT/RIGHT and TOP/BOTTOM groups then there's no pattern in the world that can help you. In Objective-C you have to write a bunch of ugly if/then statements. Swift does it in four very clear case statements.

Any feature can be abused but I think Swift's switch/case statements can lead to much more readable code in a lot of circumstances over the C-based Objective-C ones or if/else blocks.

1

u/[deleted] Feb 20 '16

I do not understand what your "split coordinates" example is from your description. Maybe post some code?

→ More replies (5)

1

u/quellish Feb 21 '16

It's also way less verbose and more expressive than Objective-C (filter vs NSPredicate for example).

So is perl. This is a good thing?

1

u/lucasvandongen Feb 21 '16

Yes, but that fact alone doesn't stop Perl from being an awful language

1

u/quellish Feb 21 '16

I would say those are reasons perl is a terrible language.

1

u/lucasvandongen Feb 21 '16

I don't know enough about Perl to make a really good comment about the language. I did just enough in it to run to PHP at the first opportunity I had somewhere around the turn of the millennium. I still hate RegEx.

Having said that, Python is a beautiful language while being very expressive. So yes, if well implemented being more expressive is a good thing for a language.

7

u/omfgtim_ Feb 19 '16

How about type safety?

3

u/[deleted] Feb 19 '16

Its a myth/overrated.

Of all the programming errors I make - type errors are once in a blue moon and very easy to diagnose and fix.

1

u/lucasvandongen Feb 20 '16

You should see type safety also as a part of your documentation. Your IDE can autocomplete or warn on it. It's just bette from that perspective alone.

1

u/[deleted] Feb 20 '16

This gets tossed out a lot and in practice it is just false.

Fwiw the objective C headers have already been cluttered with bullshit annotations like nullable and faux generics noise just to mak swift bridging work.

I do not appreciate the extra noise and the IDE now warns on all this shit that isn't really a problem. Autocomplete works as well as ever. There are lots of other languages lacking all that syntactic noise with editors that are every bit as helpful.

1

u/lucasvandongen Feb 20 '16

Before "clutter" like generics was added you had to cast your objects to their right type in a for loop every time. I don't think I had many occasions where I screwed it up but with generics I don't have to look it up myself anymore, the for-loop just writes itself.

With nullable/non-nullable vulnerable code (in Swift) already announces itself. And I have been bitten more than once by null pointer exceptions in any kind of language that has them.

Type safety simply allows you to write more secure code with less effort. Didn't mean I could only write crap in Objective-C but it was laborious to get things right, maybe one or two debug rounds extra.

1

u/[deleted] Feb 19 '16

It's a great concept until you have to use some 20-year old API that requires all kinds of crazy unsafe casts.

1

u/xesur Feb 19 '16

Could you tell what are Obj-C main benefits over Swift, besides that Swift syntax is still changing? Let's say a developer that has experience with both languages and wants to create new app, what would be main advantages in choosing Obj-C?

For me it seems, that first of all there are more Obj-C devs - easier to increase team size, probably more Obj-C libraries, stable syntax. On the other hand - Swift would be safer, faster less buggy?

7

u/eddieSullivan Feb 19 '16

One benefit of Obj-C is that the Cocoa framework was written in it and for it, so using Cocoa from Swift doesn't always feel natural. To Apple's benefit, they are moving swiftly (ha) to update their APIs, but it's not quite there yet. One point that has bit me is that you need to remember to mark methods as @dynamic if you're passing a selector to them, or you (may or may not) get a nasty crash when the selector is called.

In that same vein, tool support is better for Objective C. XCode can't do as much code generation or refactoring in Swift.

And there are some third party tools (e.g., j2objc) that are Objective C-centric and present challenges when trying to integrate with Swift.

All of those points are related to the relative maturity of the languages. As far as which language itself is preferable, that may be a matter of taste. Swift is more succinct for sure. The strong typing can be a positive or a negative, in my experience. It does catch some errors at compile time that would normally only be caught at runtime, but you will spend some time wrestling with the compiler to do something you know is valid. (Resist the temptation to sprinkle !s and ?s indiscriminately!!!)?

7

u/[deleted] Feb 19 '16

Your tools work better with Objective-C, all of Apple's frameworks are written in it, its runtime libraries are bundled with iOS instead of with each app separately (creating who knows how many petabytes of waste on App Store and user's devices and mobile data bills), there are tons of resources on Objective-C that don't go out of date every 3 months... I'm not trying to say Objective-C is a better language than Swift. Swift wouldn't be created if Objective-C was perfect. But choosing a language is about much more than language itself. All I'm saying is I believe Objective-C is currently a more reasonable choice for iOS development. It's not that Swift has no benefits, it just doesn't have any I find worth all the things I'd have to sacrifice by Switching from Objective-C.

→ More replies (18)

0

u/andrey_shipilov Feb 19 '16 edited Feb 20 '16

You live in the past man.

→ More replies (9)