This week has been all about learning, and specifically about watching videos to learn. Mostly because this week is Apple’s big WWDC conference. The list of developer-specific stuff they’ve announced this week is perhaps slightly larger than usual (including a new programming language called Swift — more on that later), and I have been watching a ton of talks pouring out of San Francisco in video form. (Special thanks to Apple for releasing them so expediently!)
Normally I am fairly un-enthusiastic about watching videos to learn. I’m much more of a do-er than a view-er. I’ve got to be working with the code in order to absorb a new programming language, so the Swift videos in particular have been somewhat frustrating. I did spend most of Tuesday with the OSX 10.10 and Xcode 6 betas, and Swift specifically, but after spending a lot of unnecessary time tripping over syntax, grammar, (and copious crashes) decided to go back to videos (and getting some actual work done).
My impressions of Swift are pretty mixed. On one hand, I love that they’re trying to make a language that is simultaneously more accessible and also less prone to bugs. That is as fantastic and commendable as it is self-serving. On the other hand, I’m not yet convinced it’s going to be an instant switch for me. I had lots of little niggling problems with the syntax. For example, I’m not sure the benefit of declaring strongly typed variables using generic keywords (var
and let
). In the c-based syntax languages I know and love, you declare the variable with the type. So in swift:
var view = UIView()
vs Objective-C:
UIView *view = [UIView new];
Now, the first example isn’t ambiguous or anything, but how about this one:
var views = UIView[]()
This is how you declare an array of UIView
objects. I do like that it will always (and can ONLY) be an array filled with UIView
objects, but I do think it’d be incredibly easy to miss the brackets. Overall though, most of the problems I had weren’t with the language itself, but with the tools, which I think are just not ready yet. I mostly agree with Austin Zheng when he says (from the comments of his 2048 port to Swift): “Xcode is as unstable as always. The background compiler/code analyzer kept on crashing and restarting itself. Xcode was functional enough to allow the project to be brought to some state of completion. The debugger is horribly broken though.”
All my video learning this week actually started on Monday (while waiting for the WWDC keynote to start) with watching Facebook’s video on building the paper app. This is also the one in which they announced their open-source animation framework pop. (And was recommended to me to learn about why it might be useful.) At an hour and a half, it’s a long video, but worth watching not just for the pop stuff (which is absolutely interesting, particularly if you already use Core Animation in your code), but for a multitude of other insights into how Facebook writes it’s apps. (There is some seriously interesting iOS engineering going on over there, something I did not expect given their history and track record, particularly in the quality department.)
Finally, yesterday (after fully maxing out on more WWDC videos), I randomly stumbled onto a talk about SpriteKit and grid-based games. The first half of the talk, by Scott Kim goes into great detail about several different kinds of grid-based puzzle games (on iOS specifically). He more or less breaks the talk into categories organized by gesture, which I think is an arbitrary distinction. (I’ve talked before about how I think the best games provide both tap and drag control schemes that are not incompatible.) Otherwise I think he does a really great job with the topic, and while it’s nowhere near comprehensive, it’s a very nice introduction / survey of the topic. This is very close to a talk that I’ve been thinking seriously about writing. (I first mentioned this idea in a previous blog post.) But since I haven’t (yet) written my taxonomy of grid-based games, Kim’s talk is, at the moment, much better than mine.