I Don't Know Swift
robnapier.net
robnapier.net
Swift isn't a language that opens your mind like Lisp or Haskell, but it seems like it is a language that can reset a career.
Things have probably changed significantly from then, but I do remember it being slow. Compared to today's generation who get frustrated when a webpage doesn't appear within about 3 seconds, they would lose their mind if they were transported back to 1995 (with the general speed of everything being slower).
One's career is built more on knowing the ins and outs of the significant collection of frameworks provided by Apple, not the language. The language can be used to explore new design patterns and implementations, but it's really the API that makes it capable.
I think Swift is as much a barrier to entry as Objective-C (i.e., not a very big barrier). The hard part is knowing the APIs available, when to use them, how to use them, and how not to use them. That has not been reset with the release of Swift; in my experience with the language so far.
So yes, you do need to know the Cocoa APIs. That's extremely important for developing applications today. But the applications of tomorrow will be developed using APIs we don't have now, APIs that are based around idioms and design patterns that will be developed over the next year (or few years) as people explore Swift and figure out what they can do with it that's different from Obj-C.
Apple will undoubtedly define many of the idioms and design patterns themselves. But there will be many that emerge from the community, from experiments that people do and open-source libraries they write.
I don't believe that languages influence API design very much — unless they are of a fundamentally different paradigm, which Swift is not.
Most of the iOS concepts I see new developers struggle with are related to architectural decisions not informed by language design. For example, the biggest thing I see new iOS devs struggle with is reusable table/collection view cells: the concept of cells moving into a pool once scrolled off-screen and re-used was made for performance reasons, new developers often attach model state to their cells and end up with all sorts of bugs. This is not a language issue.
APIs are where the majority of the learning is. For example, if you try Reactive Cocoa (or Swift RX), you are going to be thinking about your app design in a completely different way. Same thing applies to auto-layout, device trait collections, layer-backed view hierarchies, and so on. These concepts are not likely to be influenced by Swift, and these are the things that really matter.
That said, I do see Swift eventually dropping message-passing-heavy APIs (NSNotificationCenter, target:selector patterns) in favour of more strongly typed APIs. But most developers should not find the transition jarring.
As it stands though, it's just another walled garden. Aren't developers tired of those yet? Even microsoft started opening up .NET a lot more. Who, in 2014, creates a new programming language and thinks it's a good idea to lock in the developers to Apple products?
Maybe the language will be a revelation and it'll be implemented by volunteers on Linux and what not. But until then, what's the point?
Tell me, iOS/OSX developers, why bother? I want to know why people think it's a good idea to learn Swift at this point (other than purely for technical curiosity which is great).
Learning Swift really isn't a big deal.
If you want to make something, then just make it. If you need to learn something that might not be permanently useful: so what?
Really, the knowledge you learn when developing an app is not "wasted" because the language is proprietary. The important parts will relate to design and architecture, not implementation details such as language used.
Once you are a competent programmer you don't really "learn" new languages, anyway. You just jump in and use them, then look up reference when you get stuck. It's a trivial thing in the scope of building an application or a game.
> Maybe the language will be a revelation and it'll be implemented by volunteers on Linux and what not. But until then, what's the point?
What's the point of developing in Objective-C? For practical purposes it is a proprietary language. Yet it is used by many people and used successfully. The point is to build something that will be used.
Your argument applies equally to many successful languages and development environments. I don't think Swift should really bother you, considering what it is designed to replace.
Often I feel that learning a new language is more like learning a local dialect or slang than a truly new language. Some languages are very different, but I'd wager that if you're looking to learn swift you've probably worked with another very similar language before.
Sure there'll be some stumbling blocks, but you can get to a point of "this works, but probably isn't the best or fastest way for this language" fairly quickly by trying things and copy-pasting errors into google.
> If you need to learn something that might not be permanently useful: so what?
Indeed, and unless it's a really poor language you'll probably take something useful away from it. Maybe it'll be a language-feature that saves a lot of boilerplate that makes you wonder if you can implement in your own favourite language. Maybe it'll be an awesome package manager or module structure. Maybe it'll just be fun or make you think more about how different approaches work for different situations.
It is still in Beta and still in flux at the moment (language not just implementation).
Plenty of people write software for Windows using .NET, which happens to be the main fashionable system to use on Windows, and isn't typically popular on Mac OSX. But this does not make .NET rubbish - it just happens to be designed for Windows and isn't natively available on Mac OSX from Apple. Does this make .NET and associated languages "bad" or "not worth learning"?
Just because Mono is available on other platforms thanks to the huge effort from the community does not necessarily mean it would be a good choice to use for a cross-platform product, as the real journey and path of the platform is still in the hands of Microsoft. This is the same as Java used to be. But it didn't stop people writing plenty of software in Java, thanks to the main platforms supported by the Java VM. Did this make Java "not worth learning"?
I suppose Apple doesn't really need to care about making a language for other platforms. From the perspective of developers on Apple platforms, the need for a cross-platform language/system would seem redundant. As other posters have mentioned, the niche Objective-C language has found plenty of developers, and that's typically available on Apple devices (unless you count GNUstep). Does this make Objective-C "not worth learning"?
And remember that just because Swift is on one platform doesn't mean you CAN'T do cool things with it. It just means that you can only do them on one platform. That is in Apple's best interests. Does it really need to be available on every platform to be usable?
For example, they don't serve pizza at my local Chinese takeaway. This doesn't stop the food there from being great. And it doesn't make pizza less delicious when I buy it from elsewhere. But I'd be foolish to complain about the lack of pizza from the Chinese takeaway and refuse to eat the lovely Chinese food they serve there. Chinese food and pizza are both delicious, and they're only available from different places, but that doesn't diminish their taste.
I suppose the witty solution to the problem you face is to just learn C or C++ and do cross-platform stuff with that.
First of, Microsoft does support the development of .NET and associated components. It is definitely not an active support relationship, but MS answers the questions Mono developers have and has provided some help for the Moonlight project. Furthermore, it seems Microsoft is making an effort to make ASP.NET on Linux more attractive.
Having said that, it doesn't even matter what Microsoft does with .NET. If Swift stays 'closed' as it is, you can use it to develop Mac and iOS applications. If .NET stays 'closed' as it is, you can use your .NET experience to develop Windows desktop applications, 'Windows Store' applications, web applications and services, client side web programming, Windows Phone apps, apps for iOS and Android with Xamarin, Linux desktop applications, and even operating system development or protocol verification if you're an adventurous academic. All of these things are being done right now by people, and good tools exist for those things. I realize that people on HN don't like Microsoft's lock-in or tools, but experience with .NET does give you access to a very diverse set of areas to program in.
Now I'm quite convinced that Apple will open source Swift (they appear to have informally confirmed they'll be doing exactly that [1]). And then its basis on LLVM will make sure that it can be used in other places as well. But I doubt Swift's uptake outside of Apple apps will be bigger than Objective-C's simply because, unlike Microsoft, Apple won't use or promote Swift anywhere for anything else than Apple apps.
The point is that 'openness' of a language itself does not matter much for the value to learn it. It depends on how much you can do with the language. Even if you assume "You can never use Swift outside of Apple's context" and "You can never use .NET outside of Microsoft's context" are both true (which they are not), Microsoft's context for .NET is much broader than Apple's is for Swift.
[1]: https://twitter.com/mxweas/status/474581160454942721
[2]: Of course one can argue that developing Mac+iOS applications itself presents more value than all of the .NET things I mentioned combined. But that was not the point of this discussion.
I don't mean to be argumentative, but the Roslyn compiler is open source right? I'm genuinely curious.
Microsoft's context for .NET is only broader due to community effort and NOT due to Microsoft's active help. When .NET first came out, was it as widely usable on all those platforms and for different types of applications? No, and that's exactly the position that Swift is in right now. In a few years time, there might be a community effort for Swift on different platforms, but look at the success of GNUstep and the libraries surrounding it; there is not wide adoption by any means yet Obj-C remains popular.
A large portion of the list of applications that you mention are typically Windows platforms - Windows desktop applications, Windows Store applications, web applications on Windows servers, Windows phone apps. Replace the word "Windows" with Apple or iOS and you get the complaint that the parent mentioned. It's entirely a point of view problem, ie you don't get iOS/Mac OSX developers complaining about new language features in T-SQL when SQL Server is not available for iOS/Mac.
I suppose the same complaints were made against .NET all those years ago - "why bother learning it? I can use the libraries and languages I already know!". It is a poor complaint to make really, as the effectiveness of a language or library does not depend on it being open source, eg. Java (years ago), the Win32 API, MFC, Carbon, Cocoa, C++ (does the committee steer itself based on our suggestions we just throw at them?). Their success and use has happened on closed-source platforms and with closed-source devices, but it's entirely irrelevant in the same way that adoption of an open-source language is, surely?
It would be interesting if Apple does open source Swift, but as you say they won't promote Swift outside Apple apps (in the same way that I can't see that much marketing material from Microsoft encouraging us to use Mono on Linux; ie, Microsoft doesn't promote .NET use outside Windows platforms either). But that doesn't stop an army of C# developers existing. It would be interesting to know how many of the C# developers use that language because it is available on multiple platforms (perhaps we could have a poll?). I would think that very very few developers are using because they know it is cross-platform to some extent ("I'm going to use C# and .NET for my Active Directory MMC snap-in page because I can attempt to compile it on another platform!"); in fact, C# and .NET jobs mention Windows development 98.9% of the time don't they?
I just thought that refusing to even take a look at a language due to it not being open-soured was a bit of a foolish thing to do or complain about, and to be upset that a language (designed by a company for its own operating systems and own devices) was not available on other platforms and OSes was a bit of an odd complaint to make too!
EDIT: I have reread this and it sounds quite harsh! I don't mean it to sound harsh. I did not know that Microsoft has opened up the .NET system a bit; I was more attempting to highlight that the original parent's comments was a bit whiney for no reason, and I wasn't meaning to pick a quarrel with you btw. Apologies!
You're most likely going to be gluing API calls together and that's where you'll spend 80% of your time: Learning APIs. Even then this is more likely looking things up in documentation or googling for answers on StackOverflow. Whether you glue them with Python, Ruby, Objective-C, Java, Swift, etc. it really doesn't matter.
If a new programming language is your only gripe then you have a way bigger problem on your hands when it comes to writing applications :)
I suspect Peter Norvig would disagree with you there -- http://norvig.com/21-days.html
> You're most likely going to be gluing API calls together and that's where you'll spend 80% of your time
For certain problems this is the case, and you can get away with writing Python/Ruby/etc in Swift syntax.
For other problems it isn't the case. Choice of language does matter; if it didn't, would Apple have invented Swift in the first place?
At least in parts of his essay, Norvig is talking about learning a new language when one already knows how to program. For example, where he says:
In 3 days you might be able to learn some of the syntax of C++ (if you already know another language), but you couldn't learn much about how to use the language. In short, if you were, say, a Basic programmer, you could learn to write programs in the style of Basic using C++ syntax, but you couldn't learn what C++ is actually good (and bad) for.
I think that rather depends on the language and your past experience. Most programmers with experience in mainstream languages will indeed require a substantial investment of time to learn a radically different language like Haskell.
But swift isn't radically different paradigm shift like switching to a purely functional language like Haskell from a life spent writting c++.
I think your confusing learning functional programming with learning a "functional programming language." The "functional" part takes longer then the "programming lanague" part.
I'm sure that swift is of great interest to people who need to write iOS apps, and who like to use modern languages.
The article mentions that Swift wasn't tested by building a nontrivial application prior to release. It's worth mentioning that Java was tested this way: Sun built HotJava.
I don't even see any downsides. A thriving third-party tooling ecosystem would only serve to lure more developers, resulting in more applications and increased hardware and software revenue. It's not like Apple currently makes money selling its development software to developers.
[1]: http://alcatraz.io/
Well, I also got the Air because it's such a fantastic laptop, after years of using corporate Dell bricks.
That's a weird way to start an article. I was hesitant to read the rest. And the rest of it was a mixed set of odd arguments, e.g. "I predict with great confidence that Swift will be TIOBE’s language of the year."
I have no idea why would I be interested on your prediction on a not-very-useful index.
I don't even understand his argument: he is complaining that normally languages are evolved in small circles before publishing, and says that Swift has come naked, half-baked, to the world but then also remembers to say it isn't even released (!)
Just seems like he didn't even know where he was going with this article.
The rest of it is the main point.
Given that it's likely to be very very popular, and nobody can claim to be an expert, you can be one of the most knowledgeable people in the world about it by getting in now. Want to be the author of a very popular framework in a very popular language? Write a framework now in Swift.
Write a framework in Swift if the abstractions it introduces are considerably better and more conceptually complete than the existing tools.
Otherwise you're not really improving things, just piling on more crap for people to learn.
Because it's a prediction about internet, community, and people's behaviour, based on the previous knowledge about languages. Not based on the knowledge of Swift. It's a commentary about people jumping on the language that is likely to be pushed very hard by Apple - whether it's ready and useful or not.
Seems like a fairly clear point... What I don't get is why making that point needed the "I know more ObjC than you do" preamble.
(PS the code is super messy right now. I'm in the "hack away" phase, cleanup will come later.)
So you are happy to write a long comment here in exchange for karma, and are excited to blog later in exchange for eyeballs, but won't submit radars to improve your tools because Apple isn't paying you?
Shameless Plug: Check out www.LearnSwift.tips if you're trying to learn. It was born out of my desire to learn Swift and is just a simple curation of resources, tutorials, code samples, etc to learn Swift.
What other new(ish) language in this day and age does not support this? You have closures in e.g. Haskell, Java, C#, Rust, C++, JavaScript, Python and Ruby. You have destructuring/unpacking support for tuples/lists or something similar that can be used for multiple return values in e.g. Haskell, Rust, Python and Ruby. I think there will be destructuring in future JavaScript standards and I don't know about C#. I think a new language that doesn't support these things would be disappointing.
So a function definition might look like:
() -> (Int, String)
Edit: Tuples can also have named parameters, so something like this is possible:
() -> (index: Int, name: String)
//Where x is a tuple returned from the above function
x.index
x.nameThe return type does have to be defined though so there isn't a way to have a variable return type. I suppose you could return something of "Any" type but would you really want to?
Forcing developers to use a language with as much baggage as ObjC couldn't continue, particularly when compared to the much preferred web languages. ARC and Storyboards were big changes but with the amount of headaches developers have suffered dealing with the App Store, they needed something exceptional to keep old talent and bring in new I believe.
I'm excited to see how fast Swift can be baked, but just judging from HN / Reddit it is earning Apple a lot more developer love than any time in recent memory.
Or perhaps it is just words from the wise?
I've found a fun exercise while learning Swift is to re-write Objective-C examples line by line and see how much terser you can make them. The end result is usually worth it, and when it breaks it's always insightful.
So if you are planning on making iOS development a "career" then learn Objective-C first. If you are creating your own startup or playing around then learn Swift first.
So, in my opinion it is words from the wise - I'd still recommended focusing on Swift for experienced developers jumping into iOS development, but understanding the ObjC underlying just about everything one will do in Swift is important.
If I were starting a new project tomorrow, I'd still use ObjC. If someone where working for me, I would encourage them to learn ObjC for now. Swift isn't going anywhere, but neither is ObjC, and the path from zero to app is still easier in old ways I think.
Well there are optionals. I think everyone ran into issues with optionals and syntax.
Protect their turf? If anyone is going to benefit from this its people that already know iOS/OS X frameworks and only need to learn a new language. Arguably, that didn't even mean much when the first iOS SDKs came out years ago.
Swift is still half-baked. No, make that quarter-baked. It is not newbie friendly. Vast areas are undocumented, the IDE is even more unstable than usual for Apple, the compiler crashes constantly (I probably crashed it more than a hundred times just in the first week), the standard library is lacking, etc. etc. All of this makes it pretty difficult for veterans to work with. If you're new to iOS, or god forbid new to programming in general, you're going to have an extremely difficult time.
Virtually all the sample code is in Objective-C. Discussions assume Objective-C. The APIs, though translated to Swift, are still rooted in Objective-C. Trying to follow all of this without knowing some Objective-C is going to be tough.
In a year or two, when the language is solidified, then going straight for Swift will probably be viable. But right now, it's a terrible choice for anyone new.
It has nothing to do with trying to protect our turf, and that's rather insulting. I feel no need to protect my turf, because as an arrogant dickhead, I feel secure in the knowledge that I will still be a better programmer than 90+% of the folks out there no matter how much good advice they get. I've never even heard of anyone remotely competent deliberately giving out bad advice to protect themselves.
1. Will Swift be cross-platform or is it going to be strictly for MacOS X and iOS app development?
2. Will Swift apps run on older versions of OS X and iOS? I've seen differing opinions (e.g., http://stackoverflow.com/questions/24001778/do-swift-based-a...)
It would make it a no brainer language to use for a mobile app, because you could kill two birds with one stone. To date however, apple has made no comment about cross platform development
Knowing apple, I feel that they would have an off the shelf solution that you could just push code to. Almost like a parse type solution, integrated through Xcode.
However, it doesn't have much of a standard library as part of the language itself at the moment, being heavily dependent on Cocoa stuff. GNUStep/Cocotron could presumably be used.
2) Yes; Swift apps run on iOS 7 and up, and MacOS 10.9 and up. There currently seem to be some bugs which turn up on iOS7 but not 8 or vice versa, but Swift is quite buggy in general at the moment, and this will probably be cleaned up.
I imagine it's a twofer, learning Swift AND learning the iOS bits.
I don't mind paying money for a solid learning resource. Thank you.
(IBook related to learning the language) https://itunes.apple.com/us/book/the-swift-programming-langu...
(Further resources) https://developer.apple.com/swift/resources/
- Download the ebook that describes how to use the language. You can get it as an iBook or a PDF, or just view the documentation on the developer site. The ebook is really approachable and will show you how to do most things in the language.
- Learn a little bit about Foundation and UIKit so you can use the Cocoa APIs. You can build command-line applications in Swift without touching any of the Foundation stuff, but without it you won't be able to do that much.
- Go to Github and look at some of the projects people are doing. Check out their code for ideas as to what to do/what not to do, or how to solve problems that aren't discussed in the book.
- Watch the Stanford iOS Intro videos to become acquainted with the iOS way of doing things http://online.stanford.edu/course/developing-ios7-apps-fall-...
- Start coding some projects and just learn as you go. It seems as if you know enough programming fundamentals to jump right into it with some basic intro material. Do check out my site www.LearnSwift.tips as well.
"If you’re reading my blog, there’s a decent chance that I know more about Objective-C than you do. I have opinions about it. You should take them seriously even if you disagree. "
It's confusing when trying to understand his point and in all fairness I don't think it added to it.
Even the title is a bit self-serving after reading the opening paragraph, "I don't know swift" can be loosely translated into, "I don't know it so it must be new."
He makes a good point that we can help grow swift into a better "fully-baked" language by contributing.
I think the article would have been much better without the first paragraph. I think there would be less confusion amongst readers and would have set a lighter tone.
Most likely a lot of people have already told them that Swift being limited to one platform is a massive mistake and if they're not listening to that I'd rather just give up on them now.
Otherwise, we might just get stuck with something half-baked that never had a chance of growing up before widespread adoption.
I claim that Swift is very good selection of more modern stuff on the tried and tested base. It doesn't even depend in GC and VM. It's great in its conservativeness.
The most glaring problems exist in the IDE support for the language, not the language itself. There is minuscule risk of Swift not gaining widespread adoption amongst iOS and OS X developers.
Considering the volume that recruiters have to handle, they also cannot check everything for validity, so they are probably the wrong persons to rant about.
So? Neither do I, and since it's a language for one specific platform, chances I will are not that high.
What's the big deal with it, that there are so many articles about it?