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!
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.