Swift Standard Library Signaling

The Swift standard library is small at best. Apple's documentation provides a starting point for understanding it. However, it does not cover the standard library in its entirety. For the curious, a more comprehensive look can be had over at SwiftDoc.org.

Popular programming languages of the past 20 years have tended to incorporate a large standard library. Consider, for example, Java and Python. Both have a batteries-included philosophy. On the other hand, older languages that made it big, like C and Fortran, tend to have small standard libraries. This distinction may be attributed more to the time when they were developed (in terms of hardware capability, especially memory & disk capacity) than anything else. It should also be stated that Java (with the JVM) is more than a programming language; it is a platform unto itself.

So, why in 2014 did Apple decide on such a limited standard library for Swift? Is it a function of the youth of the language? The standard library has evolved and slightly expanded over the past (nearly) year since Swift was released. It may very well expand in the future. There is a more obvious rationale for explaining Swift's anemic standard library than its youth though.

Let's consider other modern languages with tiny standard libraries. JavaScript was purpose designed to run within the confines of a web browser.  Since it piggybacks off of an existing platform with an extensive API (albeit retroactively designed for it), its standard library can remain relatively slim. In a similar vein, languages that run on the JVM, like Clojure and Ceylon, can take advantage of Java's extensive libraries and don't need large standard libraries of their own.

Swift was designed to work with Cocoa and Cocoa-Touch, also therefore piggybacking off of an existing comprehensive platform. By not including a large standard library, Apple is indicating to developers that Swift is expressly designed for its platforms. "Well duh," you might say. But sometimes corporations develop new languages that they hope to eventually have adopted by the wider world beyond the gates of their platform. Wasn't that Sun's hope for Java? Isn't that Google's hope for Go and Dart? They figure being in control of a language widely adopted across the entire computing world is only to their benefit and will lead to additional developers on their platforms.

Perhaps Apple is so large and influential that it has no such concerns. Or, perhaps Apple's need to work within the confines of its existing software technology trumped these pursuits. Or, most likely, perhaps Apple simply prefers to keep its language technology proprietary as a competitive advantage.

In some sense, Swift is to Cocoa as Clojure is to the JVM and JavaScript is to the web browser (as we know, it eventually broke free). Yes, it may be open sourced in the future, and there may be alternative implementations (see Silver for example); but Swift's small standard library is Apple signaling that it was not made for the world, but instead the enclaves of iOS and OS X. As developers, we have to fill in the gaps. If you head over to GitHub, you'll find projects that do just that – provide fundamental functionality in pure Swift (without utilizing Cocoa) that is usually provided by a standard library. I have two such projects in the data structure space: SwiftGraph and SwiftPriorityQueue.

My 2014 in Side Projects

Inspired by similar posts, I decided to recount my last year in side projects. This is helpful for me because it puts the year in perspective, and perhaps hearing about some of these projects will be interesting for other people.

First, what is a side project? To me, a side project is any work that is not your main source of income. That's not a great definition, because reading a book would therefore be a side project. When it comes to side projects, perhaps it's more apt to say, as Justice Stewart did about obscenity, "I know it when I see it."

chess.dart

In early 2014, I ported chess.js from JavaScript to Dart. I had previous experience with chess programming both in graduate school and through one of my oldest still active side projects. chess.dart began as a line for line translation of the original JavaScript source code, but evolved into something more. Initially, the Dart version was several times slower than the JavaScript version (largely because it relied on maps, as in the JavaScript version, rather than custom classes). I was lucky enough to have one of the godfathers of Dart, make contributions to the project that refactored it in a more Dart-like fashion. Of course after this software maestro touched the project, it significantly outperformed its JavaScript counterpart.

I haven't had much of a reason to work on chess.dart since it reached feature parity with the JavaScript version. It even passes all of the same hundreds of unit tests. I have ideas for future projects based on it, but what really delighted me was its use by Anders Forsell in chessboard.dart and chesschallenge. Both of them are really awesome projects that show off the power of Dart and web components. Anders wrote a couple blog posts about them.

Dart for Absolute Beginners

Dart for Absolute Beginners took about 9 months to write and came out in the early summer, published by Apress. It was the first book (and I believe remains the only) written about Dart designed for people learning it as a first programming language. I believe in the book and it has been very well received by reviewers. One reviewer recently called it, "...one of the best introductory texts on computer programming in general; bar none."

Writing the book by myself was a lot of work, but Apress provided a ton of editorial support. Everyone at Apress was pleasant, professional, and helpful. I think we put out a great product. Being a beginners' book, I stuck to core concepts that will not become outdated as the language evolves. However, I did manage to stick in an interview with the founders of Dart, Lars Bak and Kasper Lund. That chapter (chapter 18) is a real gem that even experienced programmers will enjoy.

I created a 12 hour video series based on the book for Apress, but its current status appears to be in limbo after a reorganization of the company. I'm as in the dark as anyone about what will happen to the series, and I am anxiously awaiting some kind of resolution regarding the matter (it was a lot of work to create!). For some reason it seems like you can buy it on Springer's website, although I haven't yet received my advance...

Kopec's Chess Camp 2014

My dad is a well known International Master in chess. He had run fairly successful chess camps since 1994 (with a dedicated business partner, NM Hal Terrie) but took a five year hiatus prior to this year's camp. He asked me to basically run the camp this year from an administrative perspective including marketing, book keeping, handling registrations, medical forms, insurance, making/mailing the brochure, etc. We held the camp at the beautiful New Hampton School near Lake Winnipesaukee in Eastern New Hampshire. While the numbers weren't huge (there's a lot of chess camp competition these days that didn't exist when my dad was a pioneer two decades ago, and the location was a bit remote), everyone had a great week.

Crump

I started working on an 80s style arcade game over the summer to help me learn Swift as part of the Summer of Swift. I used Tiled to edit the levels and the well made JSTileMap to render them with SpriteKit. I got to the point where I had a pretty cool concept and working gameplay. However, once I encountered a rendering bug, I kind of gave up on the project as other work took my time and the contest seemed to be fizzling out (was there even a winner declared?). The (currently showing a black screen) repository is still up - maybe I'll get it rendering again when I have a little more time.

Splip

Splip is an iPhone app I released in the early fall for turning a photo into two encrypted negatives that can only be recombined to view the original when you're in near geographic proximity to the person you shared one of the negatives with. It's a cool concept and the app store version totally works (using email to send negatives and Multipeer Connectivity to recombine them) but I'm not sure there's much of a market for it.

Restaurants

Restaurants is a native Mac Yelp API client that's super fast and integrated with OS X features like Continuity and Maps. I released it in November and it's been selling pretty well. It made it as high as #4 in the top grossing apps in the Lifestyle category on the Mac App Store (which doesn't take much apparently). I wrote a blog post about my experience writing it in Swift that was pretty popular (at least as far as this blog goes!).

SwiftGraph

SwiftGraph is a graph data structure library written in Swift that I created in a few days in November. It recently got a positive mention on a major iOS dev blog. Although it's not battle proven or fast, I did a lot of best open source project practices when making the library - like including copious in-source documentation, unit tests, and a fun example program. I attribute the recent interest in it to these factors.

A side note about SwiftGraph is that despite recently getting about 30 stars in a 24 hour period on GitHub, it never showed up in GitHub's trending Swift repositories. I think the algorithm they use favors projects that already have hundreds of stars, which leads to a lot of inertia. The trending page on GitHub is a place where open source projects get a lot of exposure. It's sad that its cards seem stacked against young projects. There are projects that only have 5 stars in the past 24 hours that show up in the trending 24 hour section. I emailed GitHub about what it takes to trend and they replied that they don't reveal their algorithm - I think it would be great if they were more transparent about this.

Crafting a Course

I took a job as adjunct faculty at a local community college. I'll be teaching an advanced Java class and a database course next semester. It's a side project because it won't be my main source of income, that will still be consulting projects, but I figured it would be fun and provide some great teaching experience (and maybe even inspiration for my next introductory programming book). My boss there asked me to redesign the database course I'll be teaching, so I spent some time doing that this Fall. I'm coming into it with a lot of enthusiasm and excitement. I hope the students feel the same way.

So, that's my 2014 in side projects. Back in my Dartmouth days, we might've called a blog post like this a giant "self call" which is a negative term. But to be popular in tech they say you need to master the humble brag, right? It was quite a productive year for me with regards to side projects, but I hope to exceed it in 2015. With that regard, I rather do a few less and have them be as successful as Dart for Absolute Beginners, than necessarily do as many as I did in 2014.

Incidentally, if you have potential consulting projects that are related to anything covered in this post, do get in touch with me through Oak Snow Consulting. I'm pretty booked for the next couple of months, but let's get the conversation started if there's a good fit.

My Experience Building a Small Mac App in Swift

I dabbled with a Mac Sprite Kit game over the summer and was generally pleased with the experience. The last couple of weeks I put together a small full Mac app(Restaurants) currently under review on the Mac App Store (Update: now released) written largely in Swift. Here are a few notes from my experience. As you read them, please keep in mind that the last Mac Cocoa app I built was in 2003 (pre Cocoa Bindings even!). Since then all my Cocoa programming has been iOS. Also keep in mind, while I have a formal CS graduate education, I am a very applied guy, so I might not always get the theory parts/terminology right here.

Cocoa Bindings
Having not built a Mac Cocoa app since pre-Cocoa Bindings, I was amazed with how convenient this technology is (and a little disappointed that it never made its way to iOS). It relies on KVO/KVC of course, which feels like a bit of a hack in Swift (make sure to use the dynamic keyword). It would seem that there is a lot of room for improvement/new innovation in Swift with more advanced versions of property notifiers like didSet/willSet taking the place of KVO/KVC somehow (although I haven't yet figured out how). Ultimately everything did "just work," including doing Bindings between Swift interface elements with Swift objects that have properties which are Objective-C objects, which speaks to how well the two languages really do integrate.

Objective-C Integration
Speaking of Objective-C, the library for interacting with Yelp used in Restaurants is written in Objective-C. I modified it a bit as I worked and once again it was impressive how things "just worked" when called from Swift. Clearly this language was designed for that purpose. The bridging header is short and simple enough, but like dynamic, it also feels a bit hacky.  Once when I created it manually (and even setup the project settings correctly I thought), the linker didn't recongnize it. It seemed like only when Xcode created it for me, was everything setup correctly (yes I specified the name of the bridging header). It could be that I made a mistake in the project settings - but I do think things should be more automatic. Can't the bridging header be created for us at build time when Xcode detects the project has a mixture of Objective-C and Swift code in it?  Ah... first world problems.

Sometimes it was unclear to me as a Swift newbie how some Objective-C method parameters should be provided from Swift as far as type signatures go. Better hints in Xcode would be helpful.

Optionals
Although I've worked in a lot of different languages over the years, I never have worked in one that made such extensive use of optionals (Haskell has maybe - feels like sorta the same thing to me, but I only did Haskell for a few months). Do optionals make the code safer? Yeah it feels like they do - a little bit - although I still created errors for myself occasionally by unwrapping nil optionals - so clearly we can't completely protect ourselves from ourselves. But I also now have an inoordinate amount of boilerplate if let statements.

The big problem with optionals though is interacting with the Cocoa frameworks. I feel like Swift was designed for most variables to be non-optional, non-nullable values (I could be wrong of course) and optionals are supposed to be the special cases. But instead, due to having to work with the Objective-C Cocoa frameworks, almost everything is an optional. It's annoying - the boilerplate is annoying, the unwrapping is annoying, and the cognitive overhead of deciding what should be !, ?, etc. is annoying. Personally, while I feel I fully grasp the concept and I appreciate the safety, it hasn't been worth the loss in productivity for me when dealing with Cocoa.

Syntax
There have been a lot of comparisons saying "it's like this or that language." For me, someone who has spent the last few years programming professionally in C, Objective-C, Java, Dart, JavaScript, Python, Ruby (so mostly C-like languages except the latter two) but with significant exposure to some more academic languages, Swift doesn't quite feel like any of them. It does feel fresh. It does feel like an amalgamation of some of the best ideas of each. Just the lack of @ symbols and headers makes it more compact than Objective-C (and I like Objective-C a lot). I honestly think it's the optionals again that stops it from being perfect for me. It feels like there are too many ?s, !s, and if lets littering my code. Frankly I think that sort of stuff is what makes a language a bit hard/not fun for a beginner to grasp (and I'm the author of an absolute beginners programming text and do teach beginners professionally so I know something about this - this might be the only opinion of mine here that shouldn't be taken with a grain of salt).

Philosophy
Like every mainstream new language out there, Swift tries to bring the best of the functional world to object-oriented programmers. I think it largely succeeds. I'm even worried the community is going too far in the functional direction. I'd like to see more of an emphasis on the object-oriented features of Swift in the future. On a day-to-day basis, that's the world I think/work in, and I think that's true for most Mac/iOS developers. It's great to see the energy, enthusiasm, and contributions of the functional folks who have gotten involved with Swift. I look forward to taking advantage of it. However, my work is so much more about building intelligent class hierarchies than it is about building cool recursion tricks (ha that sounds awful and debasing - didn't mean it that way!).

Also, I appreciate the dynamacism of Objective-C. Like many have said, Swift feels more like C++ (and my understanding is that its method dispatch is more similar to it than Objective-C (please correct me if I'm wrong)) than Objective-C. Maybe we need that for the speed advantages, but that's awkward when we have to deal with these huge Objective-C frameworks all_the_time. I saw someone propose on the Apple developer forums that the dynamic keyword should be default. No, I don't think we want that slowness by default. I think what we want is to take full advantage of new, better ways of doing things, than what we had available to us in Objective-C. But we're handcuffed by Cocoa. I think Swift won't start to really have its own voice/come into its own until we have Apple frameworks written in Swift.

Bugs
I had Source Kit crashes. I had weird, unexplainable errors. I had bad syntax highlighting. Generally things got slightly better over time but some of them I still can't explain. Unfortunately it's not very easy to explain how to reproduce all of these bugs in Radars. I feel like it would be helpful if it was easier to just share full projects with the team somehow. Here's a radical idea - what about adding a built in screen capture video tool in Xcode that could also send your source code (with your permission of course) straight to Radar. Too much potential for hackers maybe?

Working on a small app, I didn't encounter some of the slow compilation issues that a lot of other people have. In general, I found the actual compiling/running process to be pretty pain free.

Community
The Swift team at Apple has been awesome on the Apple developer forums. Some cool sites have popped up on the Web like sososwift.com and others that aggregate high quality material. However there's also been a lot of negativity, which is understandable given how invested some people have become in the language given the obviousness of its future as the premier Apple sanctified language. A lot of the tastemakers who are updating their Cocoa books for Swift have been particularly vocal. I appreciate that - I wrote a book about Dart starting when it was still in beta and nothing is more frustrating than changing something big when you're going to print. But that language faced relatively few changes/bug issues compared to Swift in its early development (they also made the first public beta release a full 2 years before I started, so it's not a fair comparison).

Swift has attracted an interesting combination of long time Apple developers, brand new Apple developers, and people from the functional programming world. Sometimes it feels like these three groups are speaking Greek to each other. There are regularly code snippets on the Apple developer forums that I, a long time developer, don't fully grasp without careful study. We need coding standards, and we need more direction from Apple regarding conventions and style. We need more sample code. We need the first few books by the people most invested in Swift to come out from the major publishers. Then we'll see where the cards fall and which of these groups will get the most pull in the Swift world.

Anyway, that's it for now. I will not be doing my next big client project in Swift, but I will continue to use it in my personal projects. I also posted this on the Apple developer forums.

Network Connection Required

One thing I see time and again in mobile app development is bugs caused by syncing a local persistent data store with centralized data on a server accessed via API calls. An incredible amount of software development time goes into making the sync process smooth, elegant, and robust. Yet, in a mobile world with nearly-always-on network connections, we need to ask ourselves if the effort makes sense for all apps, especially for MVPs (Minimum Viable Products) of apps focused on content consumption.

Why is sync hard? Generally, it's a matter of the server and the client having radically different data store technologies. The translation that needs to mediate that disconnect can be complicated. A common scenario is for a mobile app developer to use a BaaS (Backend as a Service) like Parse. To take the example and run with it, Parse has an arguably excellent, easy-to-use API. Yet once the mobile app pulls data down from Parse, which will be in the form of Parse objects (PFObjects), he needs to translate it into a format suitable for storage in something like Core Data or SQLite.

This translation needs to happen in two directions (SQLite -> Parse and Parse -> SQLite). Further, consider the situation where the client accesses the application from two different devices simultaneously. Perhaps device one makes changes to the same piece of data as device two in their respective local data stores, and then both are synced with the Parse data store. Which revision should take priority? There are solutions to this problem (of course), and they're not necessarily complicated - but they are intricate when one considers corner cases.

Parse together with SQLite was just one example - perhaps the server-side is using an ORM wrapping around MySQL and the client-side is using Realm. Perhaps the client-side is just using NSUserDefaults... It really doesn't matter. The bottom line is it gets complicated. So complicated in fact that the well-known and highly regarded Mac/iOS developer Brent Simmons wrote a "diary" about his experience implementing sync for the note taking app Vesper.

Is it worth it? I don't believe so for the majority of apps, especially when they're in the get traction phase. It's not worth the potential bugs and it's not worth the development time. What's the alternative? Keeping the local data in a more flexible in-memory store - essentially a cache - and requiring a network connection to do any content creation.

The advantage here is that it takes away a step in the translation process. After the data is deserialized from the remote server, it can be used instantly and we're not beholden to worrying about multiple devices. The copy on the server is always the canonical copy when it's the only permanent data store. If the user tries to post a comment/post a rating when not connected to the net, we simply tell him he needs a network connection. Keep it simple. It's not ideal, but in a content consumption app, it's probably a minor annoyance rather than a deal breaker.

This doesn't work for apps that feature long form content creation (such as a note taking app like Vesper - or perhaps a video sharing app). They need something robust that ensures even if the network connection dies the user will not lose his work. But for apps that are all about consumption of content not produced by the user, or where the user's data input will never be more than a short blurb, perhaps the syncing madness is unjustified. I rather the user have the risk of once in a blue moon losing a star rating than be subject to a crash-prone MVP.

It goes without saying that as apps move from the MVP phase to the "we have more resources" phase, syncing becomes a much larger priority. The point here is that early on, sometimes syncing is just too much of a distraction.

Put a Date on Your Blog Post

There's nothing more irritating than reading a blog post, looking for a date, and being utterly unable to find a trace of one. There's a good reason for associating a time-stamp with a piece of writing, and that's context.

A lot of writing is a product of the time period from which it was created. That time period encompasses trends, motifs, and current events that fluctuate. Understanding those fluctuations helps one understand the motivation and biases of the author. It also informs an understanding of the author's conclusions and opinions.

Can you imagine reading Joseph Conrad's Heart of Darkness, not knowing it was published over a century ago, and questioning where the author's racial attitudes come from? No, because every book is dated and therefore you don't have to ask yourself that question. Knowing when it was published, helps you better understand Heart of Darkness through your understanding of the world from whence it came based on your outside knowledge.

Now consider a blog post about a technical subject, politics, or science. Its value is directly correlated with the context from which we understand it. We may not have any prior knowledge of the author, so that's a piece of context we may have to go without. He should at least give us a date!

Will Caffeinated Beverages One Day Be Judged Like Cigarettes?

How was it not obvious to generations of people that taking part in an activity that fills one's lungs with something other than air (smoke) might not be healthy? Actually, it was obvious to some, but the majority chose to live in ignorant bliss and not think through the issue. The public chose to be so ignorant that the tobacco industry had the gall to create corporate sponsored health studies showing the safety of cigarettes.

Never mind that there were obvious signs of smoking's unhealthiness that didn't need a study (or cancer) to become apparent. Didn't people have friends who were smokers who's voice changed? Who's exercise capacity diminished? Who coughed nastily?

Americans are now waking up to the dangers of refined sugar. It's not a secret that sugar is responsible for most of the current public health crises in America. Eat a lot of sugar, and you may very well get a chronic disease. Stop eating sugar and that disease may go away.

What do refined sugar, caffeine and tobacco all have in common? They all became widespread in Western society after the age of exploration (in other words their widespread use in the West is fairly recent, occurring over the past five hundred years and becoming pervasive in the past two hundred). They were all once trade commodities that wars were fought over. They are all addictive. And they all have had centuries of profit seeking corporations pushing them on the public.

Is caffeine as severe a drug as nicotine? Probably not. It may even have some health benefits (actually nicotine has some health benefits too). What it certainly does do to most people is raise their heart rates. That's obvious. Everyone knows that. It also, when taken in excess, makes a lot of people jittery. It probably doesn't give people cancer, but is it a good idea for people to drink several cups of caffeinated beverages a day and perpetually keep their heart rates unnaturally high and possibly affect their nervous systems?

Is a cup of coffee as bad as a cigarette? Almost certainly not. Doing either once in a while probably isn't a big deal. Will it one day be discovered that drinking a lot of caffeine, which has obvious side effects that everyone knows about, is connected with the development of a chronic disease. Maybe. This is not health advice, but for the record, I don't drink caffeine and I encourage all of my family not to either, although they don't listen.

A Time When Having No Business Model is a Business Model

The New York Times has a fascinating account of Google's purchase of Waze.  Waze does not make a significant profit.  The purchase by Google is clearly a strategic acquisition.  It seems increasingly common for large American technology companies to purchase small startups for incredibly high prices  for one of two reasons:

Niche
The startup provides an important technology missing from the company's portfolio.  This technology may serve a distinct, but important, set of customers (including developers); or the technology provides an important service for all customers.  An example of this would be Apple's acquisition of Siri in 2010, or Facebook's recent purchase of Parse.

Mindshare
Despite not having a business model (or at least a profit model) the startup has managed to attract a large base of followers.  This was the case with Facebook's purchase of Instagram in 2012, and Yahoo's purchase of Tumblr in 2013.  It was not as if Instagram held the keys to some incredible patented algorithm that Facebook's engineers could not figure out.  It simply had amassed a large amount of users in a space that Facebook was already interested in.  It remains to be seen in Four Square's case, if attracting a significant amount of loyal/influential users is as meaningful as the raw total number accumulated.

Anecdotally, it seems mindshare trumps niche when evaluating the size of these purchases.  The latter mentioned examples are an order of magnitude larger in dollars than the former.  Waze may check both the niche and mindshare boxes.

Of course, companies always made strategic acquisitions of unprofitable colleagues.  What is new is the incredible evaluations used when relatively tiny (but attractive) tech startups find their way onto the acquisition block.  This creates a whole new landscape for successful entrepreneurs to traverse.  One where acquiring users (or technologies) maybe ultimately as valuable as acquiring dollars.  So, perhaps it is not that these startups have no business model - it is just that they have no profit model.