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.
The only reason anyone cared about Objective-C was for Apple development. Otherwise it would be as popular today as Delphi or Eiffel, for instance. Nothing wrong those object-oriented languages, just no particular business need for them.
Now Apple wants to replace Objective-C with Swift. Apple is probably going to get what it wants with its own developer base, just like MS managed to "convince" its developer base to abandon VB-6 in favor of C#.
I donno. "development shops that cling to fading paradigms do [die]." Obj-C is a perfectly good tool. Fortran and COBAL as still used all over the place. The only way Obj-C dev shops are going to die is if Apple makes it so (and I have no doubt they will). But I think this fundamental argument is flawed if not downright wrong.
It's nice that there's a programming language debate where the future has been entirely settled. Thanks infoworld!
"There's no way to catch it!" cried Tom, with exceptional angst.
You do not need a more approachable language for iOS core components. Sure, that may be good for people creating end-user applications. But people who won't learn C because it's too hard are not quite the kind of people you want working at the heart of your operating system.
"I decided I could write something better than everything out there in two weeks. And I was right." - Linus Torvalds
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.
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.
I don't know how this idea started, but only a non-programmer could think Swift is more approachable than Objective-C. Swift is way more complicated and has more fundamentals that must be understood.
let versus var
optionals, including implicit and explicit binding
differences between structs and classes (value versus reference)
generics
different ways of specifying parameters, including named and unnamed parameters
property declarations, including a multitude of shortcuts
The problem is, if you don't learn most of the syntax in all its variety, you'll have a hard time understanding any random code you come across. Learning by example helps make a language approachable.
> 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'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.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
"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."
Not if you want to write something that compiles on other platforms. With Android/iOS being based on Linux/BSD it could very well make sense to write the back end of your app in C/C++ and only then branch into a different language as required by the GUI framework and other required proprietary APIs you'll be using.
But then I shake shake shake it off.
FYI, I'm an iOS developer who uses a mix of languages, including Ob-C, every day. My coworkers and I met Swift with a mildly positive reaction - it's a decent, if imperfect, effort. It's not the second coming of Christ, but it definitely isn't a bad thing to try to modernize some of Ob-C's age-related shortcomings. The notion that we'd re-write code just to use it is utterly laughable, but we could certainly see ourselves using it to start a new app, or maybe at our next jobs.
The OP, though, sounds like a marketing intern wrote it. To add a little historical perspective: our apps are a riotous mix of C and C++ (for Android portability) and Ob-C. We chose to do it this way, within the last 3 years, so this is not a legacy issue. Both C++ and Ob-C were, at one time, meant as "replacements" for C, and we know how that turned out.
Swift may very well become the preferred language over Ob-C within, say, 5 years, for Apple-specific development. But the breathless "it'll replace C!" rhetoric is just silly. Over the coming decades, C will surely fade, but it will be replaced by other, newer, even more amazing tech, not just Swift.
As a former ios app dev, swift is better than obj-c as obj-c is terrible. If you look in any obj-c book, they will compare obj-c to c++ in an attempt to show why its better. In every example I've seen, its not.
So, mature, third-party, solid, stable, best-in-class, tried-and-true libraries that are the standard foolproof way to do "X" (choose from many "X"s) will all re-write themselves from C or C++ to Swift, and then keep themselves in sync with the mainline library, right?
C and C++ will continue to be used in iOS apps for the same reasons that so many (of the better...) Android apps color outside of the approved Java lines and use C/C++ using the NDK.
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'
Predictions are like assholes; everybody has one.
Table-ized A.I.
In a world of programming for multiple platforms, a single vendor language has absolutely no applicability any more. Even Microsoft have realised this.
Having tried Swift, I just don't think it compares favourably with choosing either C++ or C#. Even Microsoft now understands the need to have cross platform support for their development tools.
Who wants to learn a language that exists for the benefit of the profit of a single greedy vendor, who happily takes a third of your revenue? Are you really that stupid?
I don't get the comment about embedded development. I have never seen an embedded apple platform, and given the rise of Linux, I don't ever expect to.
"but development shops that cling to fading paradigms do"
That is not my experience, the shops who jump on the train too soon usually do, however.
The Language Wars - they seem to arise over and over again, like The Crusades.
It's always somebody advocating for a new one (Swift?) or somebody defending a previous new one that ended-up only occupying a niche (Rust?) who launch these and their tiny little perspectives always prevent them from seeing the horizon and remembering how BIG the coding language world truly is; While C and C++ dwarf these obviously superior new languages, there are other huge language bases they are forgetting like COBOL and FORTRAN which, while ancient, are STILL far more popular than the newest ones.
There's also my favorite one which ALWAYS trumps all of them: assembly language - which is the ONLY one that can be used to do ANYTHING and even create all the others (wink)
I have nothing for or against Swift – but the article lost all credibility for me when it claimed that a big "advantage" for Swift was that it would eliminate the need for separation between specification (.h) and implementation (.c) files.
For large, real-world projects, separation of specification and implementation (or "public declarations/members" and "private declarations/members") is crucial for keeping the complexity and maintainability of the code under control. Having a file that consists of (mostly) specification and another that consists of (mostly) implementation is a feature, not a drawback - it means developers who want to use a module's public interfaces don't need to wade through mountains of private implementation details just to browse through the public interfaces.
Compared to that advantage, the disadvantage of having to repeat a function or member prototype twice (once in each file) is minor, especially given that the consistency of the two prototypes will be checked by the compilation toolchain.
Since Jobs' dead, Apple finds it more difficult to get away with this kind of stupid things.
Now they only can rely on their market share size and their captive developers greed (or desperation to make a profit). Maybe they will succeed with this one, but I predict ZERO uptake of Swift outside (w)Oz Land. So, go ahead. If you want to go even deeper inside the rabbit hole Swift looks like a good option. The rest of us will be out there still doing C and C++ (and Python, and Java, and -God forbid- PHP).
I just can't decide on which loosing horse I should all my money!
Jokes aside, anyone who knows a little bit about the history of Apple should be careful not to put too much efforts in one of their 'projects'. At least develop the core of your applications in C or C++ and use the proprietary technology just for GUI glue code. Unless we're talking about another fart app that requires zero know-how and programming effort anyway.
The NSA does not code in SWIFT, they go straight for barebone assembly because that is the only way to address the secret built-in backdoors in the baseband processor of all those devices...
really dude... no one ....
People keep bringing up the Swift in context of system programming, but so far I haven't seen any concrete info about features of the language which make it even suitable for the system programming.
The thing is, even C++ was/is used for system programming, but its C++-ness is so castrated that it is hardly can be called C++ anymore.
I personally do not see any reason to replace C with another language, which I can't use to its fullest. On top of it, lots of C extensions are needed to make the system development efficient: code/data section assignment, untyped/unchecked memory access, memory/IO barriers, assembler intrinsic. None of that is part of C standard - all of it are vendor/compiler extensions. While Swift documentation is devoid of the similar features.
P.S. If Apple folks want to push the Swift into the embedded area... Good luck. Even C++ still struggles. Higher-end embedded system require proof of validity and literally all of the solver software is C-only. Most static/dynamic code analyzers - C-only too.
All hope abandon ye who enter here.
"The huge memory leaks that a programmer can have in Objective-C are impossible in Swift". He clearly hasn't actually worked with Automatic Reference Counting (ARC) environments. What this really means is that the Apple shills promoting Swift don't see the need to create tools for finding memory leaks while simultaneously making memory management a black-box operation that is hard for the engineer to debug.
You only have to look at Obj-C code snippets for trivial things like string concatenation to realise what a horrible experience it is. So it's no wonder that Swift is so popular given that it resembles more high level languages like Typescript, Ruby or Python. That said, it's still as proprietary as its predecessor. Nobody but OS X devs will want to touch it unless it becomes a cross platform tool.
It's the start of the 2nd machine age, and we need a new high level programming language that encorporates the 3 laws for all robotics, while enableing additional lws, but the three laws should always be included as the default for everything. They could be programatically turned off, but it would have to be intentional.
No accidental robots doing things to harm humans.
Think about it.
The future favours cross-platform apps
Korma: Good
Comment removed based on user account deletion
If scripture has any bearing, time and chance happeneth to them all!
Tracy Johnson
Old fashioned text games hosted below:
http://empire.openmpe.com/
BT
Can Swift meet the performance of Obj C? Is it easier to use? Is there much of a learning curve? Does it save time? Is it it simpler?
Why would I learn objective-c (which I already learned and loath) or Swift, when I can code in C#.
Sure objective-C will be nice for a fast thin layer between a big game and the OS.
Many consumer apps already exists.
The big white space now is enterprise apps. You watch, C# is going to own the enterprise app market thanks to Visual Studio 2015, open source .NET, and Xamarin.
With CrossOver you can run MS Visual Basic programming applications on Mac and Linux, if you want to purchase CrossOver Mac or Linux use promo code ( WEAVEME ) and save 25% off the retail price!