Monday, June 30, 2014

Swift First Impressions

Hiking the Pacific.
Earlier this month, Apple announced a new programming language, called Swift. It's designed to be fast, safe, modern, and interactive.

Swift is big news since it was unexpected. I haven't been this excited to learn a new programming language since Sun released Java in the mid-1990s.

Java and Swift both took about four years to develop. But, Swift is already more mature than Java 1.2 was two years after its initial release. Sun used to have an office down the block from the Apple Campus at Mariani One. When I started working at Apple, in 1998, we joked that we could hear the Java API's deprecating across the street in the Sun building. I do not imagine many Swift APIs deprecating anytime soon since they're based on, and bridged to, Cocoa's Objective-C APIs. (Coincidently, Java 1.2's codename was Playground which is the same name of Swift's interactive coding environment.)

Getting My Feet Wet

Last week I created a couple simple Cocoa Swift apps for both OS X and iPhone. It was a piece of cake. To this day, I still love that I can drag between my code and my UI in Interface Builder to link up ivars (outlets) and functions (actions).

I spent most of this past Saturday getting up to speed on Swift. I read the docs and watched a few tutorials including the Introduction to Swift, Intermediate Swift, and Swift Playgrounds videos from WWDC 2014. So, after hiking half a dozen miles along the Pacific, yesterday morning, I decided it was time to dig deep into Swift.

What to Code?

I wanted to write an algorithm requiring a fair amount of trial and error without much mental heavy lifting. For me, the answer was string parsing. I once spent a long time coding, testing, and debugging Java (Eclipse with the WOLips plugin for WebObjects) to parse SMS text messages for newspaper classified ads:
My Tweet Storm Swift Playground
Sell  (Item name)  ($Price)  (ZIP code)  (Item details)

For my first real Swift task I reverse engineered Dave Winer's Little Pork Chop algorithm which lets you send out a tweet storm. Basically, Little Pork Chop breaks up blocks of text longer than 140 characters into tweet size chunks.

Swift and Powerful

In a nutshell, Swift's Playground is worth its weight in gold. The Playground's interactivity is powerful. Typically, I write a few lines of code, compile it, and then run it. I would never recompile an app after writing every single new line of code. But that, effectively, is what Playground does for me. It kept me focused and my code clean. I caught my syntax and logic bugs in real time as it displayed my variables and loop counts. Even better was that my infinite loops were immediately visible in the sidebar. I can see myself writing all my algorithms in Swift's Playground before copying them to my projects.

Swift Playground Gotchas

On the flip side, it doesn't seem possible to step through code, so loops execute until they terminate. Once a loop completed I could see what happened by examining the value history or using Quick Look.
Quick Look into an array and then into each element.

Another wrinkle I encountered was trying to get the character at a string index. The best solution I came up with was fairly ugly:
var currentChar = String(Array(subTweet)[indexOfCurrentChar])
This might be due to the fact that an index into a string array element, which is usually equal to the number of bytes, doesn't hold true if you're using UTF encoding where each character may require multiple bytes. If that's the case, then I need to write my own String indexer. Please let me know if I'm off base.

Free Code

It took me about two and a half hours to code and debug my tweetstorm algorithm in the Swift Playground. Am I getting Swift? Yes, I most definitely am, but I'm probably still using old coding patterns while I learn the slick new modern Swift syntax.

One final piece of Swift beauty is that you can download my Tweetstorm Swift Playground and run it for yourself in Xcode6-Beta.


3 comments:

Matt Gibson said...

Re: the string indexing: you're exactly right, it's because strings are stored more like linked lists of characters now, because characters aren't always the same width.

My hunch is that Apple don't provide their own String indexer (yet?) because they know a general indexer will be quite inefficient, and they want you to think about the specific algorithm you're using and see if there's a better way.

Joe Moreno said...

Thanks for that validation comment. It's interesting to be part of a new language while it's still being developed.

Matt Gibson said...

Yup. I'd update to the latest beta, though, if I were you—your Playground wouldn't work for me, so I guess there have been some changes along the line. (Of course, today of all days, you may want to wait for the next version to appear! :) )