Slashdot Mirror
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."
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.
"Set a man a fire, he'll be warm for the rest of the night. Set a man afire, he'll be warm for the rest of his life."
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'.
I do not fail; I succeed at finding out what does not work.
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.
It's nice that there's a programming language debate where the future has been entirely settled. Thanks infoworld!
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".
"Set a man a fire, he'll be warm for the rest of the night. Set a man afire, he'll be warm for the rest of his life."
Objective-C was ahead of its time. It uses messaging for communication between Objective-C, and using "the runtime" (a tiny virtual machine that is embedded into each executable) messages are resolved to a function pointer. Other compiled languages use static dispatch, vtable dispatch (allows overriding) or in-lining. However, messaging gives an advantage in that it affords features that are available in higher-level 'interpreted' or 'managed' languages:
The above features allow all kinds of useful things like Aspect Oriented Programming, instrumented objects at runtime (eg for object-relational-mapping), Cocoa's elegant property observers, etc. Another advantage is that Objective-C is close to the bare-metal so its very easy to take advantage of the above, while dropping back to raw C (or C++) as needed for performance tuning, which given the 95-5 rule is not too often.
Contrast these dynamic features, with C++ which fills another niche. Now the industry has had 30 years to forget how useful these features are, so Swift uses static and vtable dispatch. Given a virtual machine, with just-in-time compilation this is no problem, but as a compiled language it means forfeiting the above. Swift allows the above if a class extends a Cocoa Foundation class, but this problems are:
I'm surprised more people didn't raise concerns about this.
If it acquires resources on instantiation like a duck, then its a shared_ptr<Duck>
What is Swift written in?
It is built with the LLVM compiler framework included in Xcode 6, and uses the Objective-C runtime...
So... C. Ok, we're done here.
No wait. One more thing. It's the Objective-C runtime. Which means Objective-C programs will just keep running, as they ever have.
Swift and Objective-C code can be used in a single program, and by extension, C and C++ as well.
The new language can't supplant the old one while the old one exists in the same environment. More to the point, compatibility with Objective-C, C, and C++ was an explicit design goal. So you can just pack up all the bullshit about taking over the world.
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?
lucm, indeed.
> 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'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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
Do not look into laser with remaining eye.
And we know from experience that WHENEVER somebody uses terms like "language <XYZ> is the future", it is inevitably baseless speculation, and often rests on the false belief that some single programming language, or any single technology for that matter, can actually be the "best" one.
Brooks said it best, There is No Silver Bullet
File under 'M' for 'Manic ranting'
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.
I'm a minority race. Save your vitriol for white people.