Swift Vs. Objective-C: Why the Future Favors Swift

snydeq writes: InfoWorld's Paul Solt argues that It's high time to make the switch to the more approachable, full-featured Swift for iOS and OS X app dev. He writes in Infoworld: "Programming languages don't die easily, but development shops that cling to fading paradigms do. If you're developing apps for mobile devices and you haven't investigated Swift, take note: Swift will not only supplant Objective-C when it comes to developing apps for the Mac, iPhone, iPad, Apple Watch, and devices to come, but it will also replace C for embedded programming on Apple platforms. Thanks to several key features, Swift has the potential to become the de-facto programming language for creating immersive, responsive, consumer-facing applications for years to come."

Comments

Uh...

[EmeraldBot]

Since when is embedded programming associated with "immersive, responsive, consumer-facing applications"? I don't think Swift is going to replace C anytime soon in that department.

Re:Uh...

[Entrope]

More to the point, who outside Apple develops embedded software for an Apple platform?

Unlikely

[msobkow]

It is highly unlikely that Apple is going to rewrite all that GPL and BSD code at the heart of iOS with Swift. As long as those core projects are based on 'C', they'll stay in 'C'.

Re:Unlikely

[Feral Nerd]

It is highly unlikely that Apple is going to rewrite all that GPL and BSD code at the heart of iOS with Swift. As long as those core projects are based on 'C', they'll stay in 'C'.

Precisely, that's what wrapper code has been for since I started coding back in the early 90s. It always cracks me up when people let fly gold nuggets like "...the Python implementation of OpenCV...". As far as I am aware, nobody rewrote all of OpenCV in Python, they created Python bindings which is a fancy way of saying they created a Python wrapper for OpenCV. Programmers don't always realise that the API's they are using are actually wrappers. I used to use a C++ Linear Algebra library but because I just installed it with yum or apt-get I didn't pay it much thought. it wasn't until I tried to compile it for an embedded computer that I realised the thing was actually a wrapper for a Fortran 77 library that was ported to Fortran 90 and then given a C++ wrapper and that made it a bit of a bitch to compile (largely due to the fact that I didn't know squat about Fortran). Apple will provide Swift wrappers for at least some of the C/C++ libraries and the ObjC stuff if that's necessary (never used Swift myself so I don't know how well ObjC libraries integrate into Swift). Any other approach would have Apple's developers busy doing nothing but rewriting and debugging ported code for the next decade at least. What interests me is how far up shit creek will a developer be if he/she realises that they need a C/C++/ObjC library for his Swift application?

On iOS platforms.

[FireballX301]

The future favors Swift only because Apple is going to phase out use of ObjC. That's it. Arguing about languages is silliness when Apple will likely force you into using Swift for iOS9 compatibility in the next 12 months.

Re:On iOS platforms.

[Dog-Cow]

How should Apple be able to force you to use one or the other?

should or could?

Apple can easily do both.

should: because Apple says so, and they control the App Store. Apple doesn't have to give a reason other than deprecation.

could: compiled swift code looks different than objective-C code. It also links against the swift runtime and not the objective-C runtime. It's not hard to tell the difference.

Swift is destroying Rust.

[Anonymous Coward]

The important thing to remember here is that Swift is absolutely destroying Rust.

Rust has been nothing but hype so far. Many Ruby on Rails hipsters have rallied around it, but they haven't actually managed to produce anything useful with it.

Anything that can be done using Rust can be done better by using C++.

C, C++ and Go are the dominant languages on Linux. Rust has made no inroads here.

C++ and C# are the dominant languages on Windows. Rust has made no inroads here.

Now that Swift is seeing tremendous uptake within the iOS and OS X sphere of influence, Rust has even less of a chance than it had before.

I think that Swift will be seen as the final nail in Rust's coffin. Swift has provided developers with productivity, while Rust has provided them with false hopes.

We're seeing a convergence on exactly three languages: C++, C#, and Swift. Every other language is becoming a minor player compared to these Three Giants.

Re:Swift is destroying Rust.

[EmeraldBot]

The important thing to remember here is that Swift is absolutely destroying Rust.

Rust has been nothing but hype so far. Many Ruby on Rails hipsters have rallied around it, but they haven't actually managed to produce anything useful with it.

Anything that can be done using Rust can be done better by using C++.

C, C++ and Go are the dominant languages on Linux. Rust has made no inroads here.

C++ and C# are the dominant languages on Windows. Rust has made no inroads here.

Now that Swift is seeing tremendous uptake within the iOS and OS X sphere of influence, Rust has even less of a chance than it had before.

I think that Swift will be seen as the final nail in Rust's coffin. Swift has provided developers with productivity, while Rust has provided them with false hopes.

We're seeing a convergence on exactly three languages: C++, C#, and Swift. Every other language is becoming a minor player compared to these Three Giants.

According to the TIOBE Index, Java has more usage than all three of them put together. I'd hardly call it a "minor player".

Re:Swift is destroying Rust.

[lucm]

We're seeing a convergence on exactly three languages: C++, C#, and Swift. Every other language is becoming a minor player compared to these Three Giants.

Baghdad Bob, is that you?

Re:Swift is destroying Rust.

[TWX]

I suppose it depends on what you want to do with it, and what you see Java's future as a wholly-owned subsidiary of Oracle is.

I was studying programming in college when the hype for Java began. We were using C and C++. What was true then still holds true today, in that in C/C++ you can write operating systems and conventional programs, but in Java you are limited to conventional programs. Java has the theoretical interoperability feature between OSes and hardware platforms, but in practice there's a lot of customization to make programs actually do this, and if one has to write versions for several platforms, it's not a whole lot more burden to compile those and distribute binaries instead of Java runtimes.

As for servers, I've always liked the mindset of putting as little as possible on the production server beyond what its job is. Hell, the idea of statically-compiling everything to allow one to eliminate libraries, let alone compilers on the production box, appeals in that if someone does break in there's a lot less they can do once on there. Java for server-side applications flies in the face of that, there are more general-purpose tools on the server rather than less.

I'm aware that I'm not in the majority for this stuff, and I didn't make programming my profession anyway so perhaps even I should be taken with a grain of salt, but it seems like in this speed to push features we've taken steps backward in real system security, and we're being bitten in the ass by it with ever increasing frequency. The very choice of programming language appears to be fundamental to that.

Re:Swift is destroying Rust.

[viperidaenz]

There's a shit load more "conventional programs" than there are operation systems
Java also solves your libraries and compile problem.

Last project I worked on the build server was Windows 2008, my dev PC was Windows 8.1 and test and production ran Linux. I don't even think prod was x86.
No cross-platform issues at all with ~ 100,000 lines of code.

Re:Swift is destroying Rust.

[goose-incarnated]

We're seeing a convergence on exactly three languages: C++, C#, and Swift. Every other language is becoming a minor player compared to these Three Giants.

Wait, what? Swift is basically statistical noise at this point. "Dead" languages like ML and Pascal are higher in the tiobe index than swift is. It may become a force in the future but it's nowhere near that now.

Swift is not ready to replace ObjC

[Anonymous Coward]

> 8. Swift supports dynamic libraries

The swift runtime is a static library (written in C++11) and linked in every executable, everytime there's an update to swift (runtime) you need to recompile all your code (see Apple's swift blog, first entry). This is why swift cannot be used for system API / libraries, at least until they have a stable runtime that can made a dynamic lib (like Obj-C is). But it being C++, I don't know if that ever gonna happen.

I disagree

[SuperKendall]

I've done Objective-C since before the release of the iOS App Store, and Swift almost full time since Apple released it last year...

Some of the things you mention beginners do not have to use (generics, and struts for example). To keep things simple to start with, they could just use classes instead.

I will agree that optionals might be a bit rough on the beginner - but perhaps not as starting from nothing, the concept of a bucket that holds a value instead of just using the value directly, would not be so foreign...

You also mention different ways to specify params, and shortcuts - but I see those as a major plus. You can just pick a level of detail that makes sense to you and work with that, until you feel comfortable with reducing further the syntax you use.

I think the function syntax is one of the cleanest and easiest styles to understand... I believe a few other languages have this form also, but in swift you just say something like "a function named takes in these params, and outputs those params" So it looks like:

func myFunc (a:String, b:Int) -> (a:String, b:Int)

it's just so balanced that you can have any number of things in or out.

There are a few things I think make Objective-C less approachable.

The separate header files, and the heavy modern use of private categories to define most internal properties confuse people as to where they need to define things.

Simply more verbose syntax all over. I like verbosity myself, I love named parameters... you get that with Swift though with a lot fewer characters typing.

Part of that extra syntax in ObjC is the shorthand to make arrays like @[] and @(value) to make NSNumbers... but in Swift Integer is treated the same as String, both are first class objects that you can do things with so it's more consistent. That in particular is I think a large benefit for newcomers.

I'll start using Swift

[SpaghettiPattern]

I'll start adopting Swift as soon as it has an active community on most commercially interesting platforms. E.g. all UNIX derivatives, Windows, z/OS and Mac of course. When I have ample choice of programmers to hire. Not interested in technologies exclusively centered around one supplier.