mkale.com

WWDC 2014 brought many exciting announcements for developers, but for me the most interesting was the new programming language, Swift. To me, this immediately removes any desire I once had to write utility code in Objective-C. For the next couple years, it will still often make sense to write UI and Cocoa-touch facing code in Objective-C, especially if you intend to target iOS devices prior to iOS 7 (or OSX prior to Mavericks). Where are we with languages today?

For UI code, I still belive in writing to the platform's native API. This means Objective-C or Swift for Apple platforms, Java for Android, C# for Windows platforms. For utility code, libraries, business logic, and other non-UI code, we have several options. For casual, home, or tinkering projects, from modeling data, generating this blog, automating rote tasks, parsing log files, and moving bits around, I still love Ruby or Python. Ruby has a greater mindshare among non-scientists and though I find python to be a more elegant language, it's hard to argue with the success of Ruby. For most tasks they exist at a similar level and are for my purposes equivalent. Ruby also has just enough of Perl's "just get it done" attitude to be a very effective language. In many ways it's a greater joy to program in Ruby than anything else.

For library code that's going to ship on client devices though, it's too bad that there is no common langauge that can easily target iOS, Android, and Windows Phone. (Honestly, I'd settle for a language that hit the first two.) C++ comes close: support is excellent on iOS but calling C++ code from Android requires a tedious JNI bridge and the complexity of compiling separately for many target CPU architectures. For large libraries it may be worth it but for the code I tend to write I find it easier to do a translation port over to Java for Android (and C# for Windows). If you leave the object models and code structures the same, translating utility (i.e. non-UI) code across languages is not very difficult. But it does require typing everything twice and keeping changes in sync. There are also some javascript solutions which are promising but still involve too many dependencies and are more complex than I'd like. Maybe in another year or four this will change.

I prefer C++ if I also plan to use the library from Linux or Windows on the desktop. Otherwise, I plan to start using Swift for code destined for Apple platforms. I'm going to be porting the Apple-platform utility-code to Java anyway for Android, so I might as well get started using the new Apple language for Apple platforms. If we're lucky, Apple will open-source Swift and we'll see an implementation targeting Linux or Windows and I can begin to write all my library code in Swift. (If we're really lucky I'll be able to target Android too but I'm not holding my breath on that one.)

I have of course completely ignored web and internet-server code. This is not where I spend very much of my time so it's likely that my opinions would change with some more experience. But for very simple web projects, PHP may still be a good choice. Its server requirements are light and it's easy to throw something together that works. But for any project that goes beyond a couple files and a few pages, I would probably use Rails. There are many compelling alternatives to Rails though and I would like to spend some time in the second half of 2014 exploring them. Maybe my language state of the world 2015 will have some better or different options here.

It's, as always, a great time to be a programmer.