+1. I will merrily skip any submission with a sensationalistic headline, together with those that read like "Why you need to stop doing X, and do Y instead". I don't know how everybody else feels about this, but I'm sick of stupid headlines on HN.
I understand they help to sell, but I decided to cut down dramatically on the amount of time I spend reading about shit some random guy on the Internet thinks I absolutely need to {stop,begin,avoid} doing, and this rule of thumb helps quite a bit.
Sad to say, I guess that the vast majority of the stuff we read won't make our life appreciably better.
That being said, one might sure find entertainment value in a certain kind of submissions.
At least it's better than the "Man Creates Language to Rule Them All" they used for the Julia article. That one still makes me cringe when I see it. For what it's worth, it's not the article author who picks these headlines – there's some editor who does that.
It's been a few years now since they started with the ridiculous headlines. I think the writers (mostly) do a pretty good job, the headlines are left to people whose job is entirely making attention-grabbing, link-bait titles.
I'm an Apple user, but reading an headline like this makes me lose interest in the article almost instantaneously (it could be about Go or Rust or whatever, and I'd have the same reaction).
Thanks for the pointer, I will give the story a chance.
"Google unveiled a language called Go in 2009, and though it was designed by some of the biggest names in the history of software design—Ken Thompson and Rob Pike—it’s still struggling to gain a major following among the world’s coders. But Swift is a different animal. When it’s officially released this fall, it could achieve mass adoption with unprecedented speed, surpassing even the uptake of Sun Microsystems’ Java programming language and Microsoft’s C# in the late 1990s and early 2000s."
I didn't note any mention of the fact that Objective-C and now Swift are (to a first approximation) the only ways of writing apps for Apple's major products. Go is struggling? They're comparing it to Java, a language intended for universal use, and it hasn't been released yet?
"...an enormous number of programmers have an immediate reason to use Swift. Today, hundreds of thousands of developers build apps for iPhones and iPads using a language called Objective-C, and due to the immense popularity of Apple’s consumer gadgets, these coders will keep building such apps. But Swift is a significant improvement over Objective-C—in many respects—and this means the already enormous community of iPhone and iPad developers are sure to embrace the new language in the months to come."
It's kind of irrelevant. Yes, Swift will become quite popular overnight because it will soon be the defacto way to write iOS and Mac apps. Go is struggling because it hasn't found its "reason to be" with most people. Of course this doesn't mean that Swift is better than any particular language. If Google adopted Go on Android, for example, its popularity would surge
Is it even possible to take wired seriously anymore? After a couple of years of seeing stories like this pop up I think I finally understand what it's like for my wife (getting a PhD in genetics) to read the breathless science headlines I used to frequently show her.
> Chris Lattner spent a year and a half creating a new programming language—
That's not as bad as JavaScript, but most good languages take longer than that.
Swift doesn't look bad as such to me at a quick glance, just not novel. It's a "why-bother?" language rather than a "ack, no!" language. If C# version 1 was "The Microsoft proprietary version of java" is Swift v1 "The Apple lock-in on current practices" ?
It's an officially sanctioned language for the apple ecosystem, meaning the bar has been lowered to "is it better than objective-c?", rather than "why bother".
Well, precisely. But there are a number of existing languages that would also be better than objective-c. And they had the benefit of pre-existing.
Like with C#, a language "officially sanctioned language for the ... ecosystem" is not going to be a radical experiment, it will reflect proven wins.
So it seems that apple made the decision that the benefits of rolling their own take on the current state of the art outweighed the costs associated with rolling their own.
Or rust, D or go which you mentioned elsewhere. None of therm are ideal, all of them are > ObjC
You could have an open ecosystem where all of them exist. That you don't is an indication of how "Apple's purposes" diverge from programmers' purposes.
Or you could write your iOS app in C, or C++, or Python, or... In all cases, you'll be calling objc_send a lot, and that's the problem. A Swift class can subclass an Objective C class, and implement Objective C protocols; good luck with that in a language with an incompatible object system.
Apple isn't stopping anyone from using those languages; it's just that adopting them would make very little sense; using existing APIs and third party libraries would be horrendous.
I don't have much experience in writing iOs apps, but the impression I always had is that the language is not nearly as important as it seems, to that end.
Regardless of the language, the important (and most difficult) part is getting used to iOS framework, the patterns and models it uses, not to mention all the UI widgets and how they interact with each other.
I don't think Swift will make it easier to deal with all that, regardless of how well has been thought out.
It's also incorrect; he says he started it about four years ago, though it was just him for a while.
> It's a "why-bother?" language rather than a "ack, no!" language.
The thing is, what is the alternative? They needed easy ObjC interoperability (all the APIs and third party libraries are in ObjC, and will be for a long time), and thus a compatible object model. That would knock out most alternatives on its own. Even if they were willing to compromise on that, and go with more heavy-weight interop, they'd basically be looking at adopting Rust, which isn't finished, or maybe D.
EDIT: On the age thing, by the way, it's also reasonably clear that Swift isn't finished. It should be usable by the time Xcode 6 goes out of beta, but ObjC isn't going anywhere anytime soon, and I expect Swift will continue to evolve for a while yet.
It seems to me that swift is about as good as the other trending languages around (rust, go) as well as the nicer older languages (c# and um...) which is plenty nice. It's not going to convert erlang, haskell, or ocaml users. Now if apple does open source it down the road it could be truly wonderful. C#'s success cross platform, thanks to mono, has been largely despite microsoft.
From looking through the article, and what's available online (Apple page and Wikipedia), it looks like they took most of what folks like about interpreted languages and just moved them into a compiled form, married to a decent debug / testing environment.
It also has a bit of Perl, in that its written so that patterns conform better to English speaking patterns. For example, they use the "let" keyword to do constants like:
let appleSummary = "I have \(numberOfApples) apples."
and they use Javascript-like simple concatenation operators like:
str = "hello,"
str += " world"
And like Perl, I also like that associative arrays / dictionaries are top level:
let people = ["Anna": 67, "Beto": 8, "Jack": 33, "Sam": 25]
After that, it mostly looks like standard evolution. They've taken many of the top, or high use programming patterns of the current day for i-products and rolled them into libraries or main functions to speed up development.
It could be good. I do like Javascript and Perl, which look like they had a child with Objective-C. And that article has a point that its only main competitor is Obj-C, which is not much of a fight. Now if they'll only allow you to develop and build on non-Apple hardware.
I think let for bindings actually comes from ML. It looks a lot like what you get when you try to take what you can from functional languages while still being an imperative language.
I don't consider the "let" example to really be very Perlish. The real power of Perl in it's natural expressiveness is to more closely map speaking, and thus thinking patterns to how the algorithm is represented. For example, postconditionals, which allow a single statement to be conditional based on a condition that immediately follows it. This is a natural way people express themselves ("do X if Y" or "do A unless B"), but it is wisely restricted to a single statement as the alternative is less common, less clear. The fact that swift's let statement sounds like common English when spoken aloud is only superficially similar to Perl, IMHO.
Additionally some sort of hash/associative array/map data structure at the top level is (thankfully) common at this point.
I haven't followed swift too closely though, so maybe there's other stuff that I would consider more aligned with the spirit of Perl.
Wow, had no idea that this was a personal "skunkworks" project by Chris! Very impressive (and gratifying for him, I'm sure) to have such a thing embraced by the highest levels of management.
Swift is a neat looking language. I haven't gotten to play with it yet, but I have read Apple's "The Swift Programming Language" cover to cover and I come away with a few concerns.
My biggest issue with Swift is that there often seem to be too many ways to do things. I'm fine with having options, but when there are literally 4 or 5 different ways to accomplish the same things it's going to require development shops to come up with rigid standards about how to do things. Many shops aren't going to know that this will be an issue until later, when trying to integrate the work of different developers / teams on a large project.
The upside of this level of flexibility is that it allows you to quickly port code from nearly any language into Swift since it supports the features of almost every modern language. The downside, of course, comes when starting a new project: you have a lot of decisions to make about how functions will be called, objects instantiated and referenced, etc. If you don't make those decisions up-front, peoples' preferences will take over and you'll get a lot of spaghetti code. I'm not looking forward to starting a project in Swift, that's for sure.
From a technical perspective, I have no complaints: Swift is flexible and powerful without being weighed down by the kludges that Objective-C forced you into. But I definitely see small dev shops having a big advantage with Swift in the beginning: it'll simply take the big guys too long to get their act together.
Yeah but I get it with libraries: you've gotta provide compatibility so preserving old ways of doing things is fine. With a new language like this, it's just making one of the biggest problems with Objective C even worse.
Apple has never cared about backward compatibility. They kill off libraries and APIs like unwanted kittens. Yes, it makes everyone sad when they do it, but the API still goes into the burlap bag and then into the pond. They continue to break software with each now OSX release.
It's likely to become part of the LLVM open-source release sooner or later. Of course, it'll be missing half a standard library unless you use GNUStep/Cocotron; currently in practice ObjC functionality is used heavily. It'd be a start, though.
Thanks for this! I couldn't find one without it wanting me to pay when I looked in the middle of last week. I don't do native iOS/cocoa so I felt it'd be kind of skeezy to have work pay for it.
Pretty bold headline, fortunately the story was decent. With that said, as someone who develops JavaScript for a living Swift is very inviting. I've tried and failed many times to wrap my head around ObjC, but it never stuck. In messing with Swift the last couple of weeks, I find myself pretty comfortable and happy the barrier-to-entry is rather low.
I believe it will be possible (I'm expecting Apple to open source it after it is out of beta as they do with their LLVM changes) and that it could then be used on any platform LLVM supports. That doesn't mean that I think that it will be widely used, the Objective C compatibility won't be very helpful. It does integrate cleanly with C but C++ libraries need to be wrapped in C/Obj-C at the moment.
I do like Swift and it quite possible it will be used on other platforms but I'm not convinced. I haven't really checked out Rust and Go properly yet but compared with C/C++ Swift might be tempting for a new project on other platforms.
In theory yes, but in practice no. It's constructed around a solid core of the Objective C object model and runtime. Rudimentary open source versions of these exist, but they are _very_ rudimentary. The value in those technologies is all concentrated in the Coacoa and Coacoa Touch libraries and frameworks, which are proprietary to Apple.
Trying to use these technologies on another platform would be like trying to develop software using the core of the Python language with none of the standard library or external libraries (imagine they were implemented in another language you couldn't port). Or like implementing just the C# language on another platform, without any of the .NET libraries. It's possible, Mono did just that, but they had to re-implement almost the entire .NET infrastructure from scratch, a task many orders of magnitude greater than just duplicating the language itself.
> In theory yes, but in practice no. It's constructed around a solid core of the Objective C object model and runtime.
Not sure I agree. You won't be making a Cocoa UI in it or anything, but if they open source the compiler and modifications to the Objective C runtime, along with the standard library (which is really light right now; you have to use Cocoa for very simple things), it should be useful enough, with GNUStep.
This is quite a weird idea, really. Even if Swift were open sourced (and it looks like it may be at some point: http://article.gmane.org/gmane.comp.compilers.clang.devel/37...), would it _really_ be all that dramatically useful on, say, Android? Good luck making your GUI app through the JNI. There are a few Objective C apps on Android, but they're pretty much universally games (there's a Spritekit port).
It doesn't really change the story for developing cross-platform apps at all.
I know, I'll create another programming language. Now you have N+1 problems, none of which address the systemic problems with the Apple ecosystem. The problem was never JUST Objective-C (although it sucks pretty hard). Apple is REALLY struggling for a win here.
He who dies with the most cash wins? It's definitely a nice position to be in but money obviously doesn't think up new products.
What was the last true innovation from Apple? I claim it was the iPod. The miniaturization of music. Everything since the iPod has been purely derivative of that miniaturization theme.
They've ridden the "Miniaturize all the things" wave hard (and successfully) by adding more features like accelerometers, GPS, faster chips, more colors, etc. to keep the fanboys horny but nobody has been really impressed with a new iDevice for quite some time. Apple is getting stale.
Apple needs a new hardware win that shows that they haven't exhausted their idea bank AND that they still have the marketing savvy to make people want what they've got.
Apple has NEVER been a software company. They are definitely struggling if Swift is the best new things they could come up with.
am i the only person who hates the fact that i have to pay $100 pa for the right to put my own software on my own iPad - language be damned? @#$#@ that. i'm taking my tablet needs somewhere that let's me feel as though i've purchased it, not borrowed it from Steve...
64 comments
[ 0.20 ms ] story [ 82.7 ms ] threadI understand they help to sell, but I decided to cut down dramatically on the amount of time I spend reading about shit some random guy on the Internet thinks I absolutely need to {stop,begin,avoid} doing, and this rule of thumb helps quite a bit.
Sad to say, I guess that the vast majority of the stuff we read won't make our life appreciably better.
That being said, one might sure find entertainment value in a certain kind of submissions.
Thanks for the pointer, I will give the story a chance.
"Google unveiled a language called Go in 2009, and though it was designed by some of the biggest names in the history of software design—Ken Thompson and Rob Pike—it’s still struggling to gain a major following among the world’s coders. But Swift is a different animal. When it’s officially released this fall, it could achieve mass adoption with unprecedented speed, surpassing even the uptake of Sun Microsystems’ Java programming language and Microsoft’s C# in the late 1990s and early 2000s."
I didn't note any mention of the fact that Objective-C and now Swift are (to a first approximation) the only ways of writing apps for Apple's major products. Go is struggling? They're comparing it to Java, a language intended for universal use, and it hasn't been released yet?
"...an enormous number of programmers have an immediate reason to use Swift. Today, hundreds of thousands of developers build apps for iPhones and iPads using a language called Objective-C, and due to the immense popularity of Apple’s consumer gadgets, these coders will keep building such apps. But Swift is a significant improvement over Objective-C—in many respects—and this means the already enormous community of iPhone and iPad developers are sure to embrace the new language in the months to come."
That's not as bad as JavaScript, but most good languages take longer than that.
Swift doesn't look bad as such to me at a quick glance, just not novel. It's a "why-bother?" language rather than a "ack, no!" language. If C# version 1 was "The Microsoft proprietary version of java" is Swift v1 "The Apple lock-in on current practices" ?
Like with C#, a language "officially sanctioned language for the ... ecosystem" is not going to be a radical experiment, it will reflect proven wins.
So it seems that apple made the decision that the benefits of rolling their own take on the current state of the art outweighed the costs associated with rolling their own.
Which ones, exactly, would be better for Apple's purposes?
Or rust, D or go which you mentioned elsewhere. None of therm are ideal, all of them are > ObjC
You could have an open ecosystem where all of them exist. That you don't is an indication of how "Apple's purposes" diverge from programmers' purposes.
But you do, at least for two of them (D doesn't seem to support ARM yet).
Here's Rust: https://github.com/rust-lang/rust/wiki/Doc-building-for-ios
And here's Go: https://bitbucket.org/minux/goios/wiki/Home
Or you could write your iOS app in C, or C++, or Python, or... In all cases, you'll be calling objc_send a lot, and that's the problem. A Swift class can subclass an Objective C class, and implement Objective C protocols; good luck with that in a language with an incompatible object system.
Apple isn't stopping anyone from using those languages; it's just that adopting them would make very little sense; using existing APIs and third party libraries would be horrendous.
Apple isn't stopping anyone, and Apple certainly isn't encouraging anyone from using any language that doesn't issue forth from Apple.
Regardless of the language, the important (and most difficult) part is getting used to iOS framework, the patterns and models it uses, not to mention all the UI widgets and how they interact with each other.
I don't think Swift will make it easier to deal with all that, regardless of how well has been thought out.
> It's a "why-bother?" language rather than a "ack, no!" language.
The thing is, what is the alternative? They needed easy ObjC interoperability (all the APIs and third party libraries are in ObjC, and will be for a long time), and thus a compatible object model. That would knock out most alternatives on its own. Even if they were willing to compromise on that, and go with more heavy-weight interop, they'd basically be looking at adopting Rust, which isn't finished, or maybe D.
EDIT: On the age thing, by the way, it's also reasonably clear that Swift isn't finished. It should be usable by the time Xcode 6 goes out of beta, but ObjC isn't going anywhere anytime soon, and I expect Swift will continue to evolve for a while yet.
It also has a bit of Perl, in that its written so that patterns conform better to English speaking patterns. For example, they use the "let" keyword to do constants like:
and they use Javascript-like simple concatenation operators like: And like Perl, I also like that associative arrays / dictionaries are top level: After that, it mostly looks like standard evolution. They've taken many of the top, or high use programming patterns of the current day for i-products and rolled them into libraries or main functions to speed up development.It could be good. I do like Javascript and Perl, which look like they had a child with Objective-C. And that article has a point that its only main competitor is Obj-C, which is not much of a fight. Now if they'll only allow you to develop and build on non-Apple hardware.
Also "+= " on strings extends beyond just JS (it works in C# too) and likely several others.
Whichever more modern language you're familiar with, you'll probably see an echo of it there.
Additionally some sort of hash/associative array/map data structure at the top level is (thankfully) common at this point.
I haven't followed swift too closely though, so maybe there's other stuff that I would consider more aligned with the spirit of Perl.
My biggest issue with Swift is that there often seem to be too many ways to do things. I'm fine with having options, but when there are literally 4 or 5 different ways to accomplish the same things it's going to require development shops to come up with rigid standards about how to do things. Many shops aren't going to know that this will be an issue until later, when trying to integrate the work of different developers / teams on a large project.
The upside of this level of flexibility is that it allows you to quickly port code from nearly any language into Swift since it supports the features of almost every modern language. The downside, of course, comes when starting a new project: you have a lot of decisions to make about how functions will be called, objects instantiated and referenced, etc. If you don't make those decisions up-front, peoples' preferences will take over and you'll get a lot of spaghetti code. I'm not looking forward to starting a project in Swift, that's for sure.
From a technical perspective, I have no complaints: Swift is flexible and powerful without being weighed down by the kludges that Objective-C forced you into. But I definitely see small dev shops having a big advantage with Swift in the beginning: it'll simply take the big guys too long to get their act together.
This is my biggest issue with the Apple libraries in general. It's an artifact of the software's bloodline running back to the 80s.
I don't like the comparisons to Go in this article. I'm an iOS developer who has dabbled in Go, and I'd actually argue the opposite.
For me, there is little reason to immediately switch to Swift. I can still use ObjC, and in fact, I'd expect problems when switching to Swift.
Go, however, had many incentives to learn. Easier deployment, speed, concurrency, etc.
As usual, Wired has over simplified the argument
Also a $100 entry ticket to a beta IDE/compiler might hinder said adoption.
https://developer.apple.com/swift/resources/
Of course, in practice, current development with Swift is mostly pretty dependent on Cocoa, but there's no inherent reason it has to be.
I do like Swift and it quite possible it will be used on other platforms but I'm not convinced. I haven't really checked out Rust and Go properly yet but compared with C/C++ Swift might be tempting for a new project on other platforms.
Trying to use these technologies on another platform would be like trying to develop software using the core of the Python language with none of the standard library or external libraries (imagine they were implemented in another language you couldn't port). Or like implementing just the C# language on another platform, without any of the .NET libraries. It's possible, Mono did just that, but they had to re-implement almost the entire .NET infrastructure from scratch, a task many orders of magnitude greater than just duplicating the language itself.
Not sure I agree. You won't be making a Cocoa UI in it or anything, but if they open source the compiler and modifications to the Objective C runtime, along with the standard library (which is really light right now; you have to use Cocoa for very simple things), it should be useful enough, with GNUStep.
Swift will be used as a competative advantage or lock in, depending on your level of scepticism.
It doesn't really change the story for developing cross-platform apps at all.
What was the last true innovation from Apple? I claim it was the iPod. The miniaturization of music. Everything since the iPod has been purely derivative of that miniaturization theme.
They've ridden the "Miniaturize all the things" wave hard (and successfully) by adding more features like accelerometers, GPS, faster chips, more colors, etc. to keep the fanboys horny but nobody has been really impressed with a new iDevice for quite some time. Apple is getting stale.
Apple needs a new hardware win that shows that they haven't exhausted their idea bank AND that they still have the marketing savvy to make people want what they've got.
Apple has NEVER been a software company. They are definitely struggling if Swift is the best new things they could come up with.
Where's the hardware?
<crickets>
https://www.gnu.org/philosophy/free-sw.html https://www.fsf.org/blogs/licensing/gplv3-lockdown http://faif.us/cast/2014/jun/19/0x47/