A project for an image processing Cocoa app last year ran into some difficulty when images produced had small color differences compared to the results of previous versions. We had changed most of the infrastructure as we ported this former Photoshop plug-in. We had to consider many systems as possible culprits. Did the colors shift on loading? During format conversion? During processing? Converting for display? Or when saved to disk? Did the format of the image file matter? Did Photoshop do something Cocoa wasn’t doing? It was a slog, but that last one proved to be the right question.
Long ago I gave some off the cuff, first impressions about Swift. Since then there have been several upgrades to the language, but I have only recently found myself trying it out. Specifically, I decided I had the time and inclination to implement Conway’s Game of Life. I wanted to try Swift on as a language, see how hard it makes me work to get to the bytes, and see how efficient I could make my code. Life’s matrix of cells provides a good substitute for the kind of byte by byte programming I often need to do and gave easy measurement opportunities by timing the updates of the life matrix, AKA ticks. What did I learn?
I decided to jump right into Swift without doing any research into the writing done over the past month so that my opinions were not colored. My background is in the C/C++ and, lately, Objective-C of which I’ve become quite fond. I approached Swift with the hope that it would provide the same kind of power I’ve found Obj-C/Cocoa to have, but with some modern newness brought in from other successful languages. It is too early, and the tools are too fresh, for me to draw conclusions on how useful it will be for production code other than that it does look promising.
TL;DR after the jump wherein I detail experiences with the Xcode playground and a small Swift based iPhone app.
It took only about a ten minute glance over the language docs to be able to port my C code to Swift
Explicit control of nil behavior such as when to require non-nil objects
Enums are first class types along with classes and structs
The beauty of every callable block being a closure: global functions, nested functions, class methods and traditional lambda style closures
Syntax shortcuts when they make sense like leaving off get for a readonly calculated property or return for one line closures
Tools: the playground, compiler, all are early versions and have problems; but we know that, and that’s why we will be shipping Obj-C apps for a while
The syntax is a step back from the terseness of Objective-C towards the explicitness of C++ (Python users are laughing right now; and yes Obj-C names are wordy, read that as “readable”, but the syntax mostly stays out of the way)
No headers; wade through the implementation to find the declarations you need (somehow Swift’s type declaration file avoids this)
I don’t think I like the declaration style var x: Int = 4 which reads like “assign something to SomeType” to me
It took some fumbling to figure out how to define outlets and actions in my first Cocoa Touch app (where are these language extensions documented?)
This is a gentle reminder that you are not forced to limit yourself to any app’s built-in features when you work on Mac OS X thanks to Services with an assist from Automator. I recently utilized Automator’s Run Shell Script action to create a needed function in Xcode’s text editor.
My problem is that I follow a style guide that limits line length to 80 characters. I usually don’t have trouble with this. Xcode will show a gutter line to help prompt me to break my lines around the limit. But when editing multi-line comments it becomes a pain to reflow the new text. Other editors can do this without my help.
Last time I wrote about doing imports of large data sets when using AFIncrementalStore to handle server synchronization I thought I had made an end-run around it, finding a technique which was compatible but faster. I was wrong.
Before I begin, this is not a knock on AFIncrementalStore which does its job well overall. It was my first use of this library, and I have no trouble recommending it for certain uses cases.
After my last post, when I started to test more thoroughly and use the imported data, I saw strange things. Mostly that meant my objects relationships were not what I expected. I’m fairly sure I had seen these relationships created as they should be, but in the fog of the battle which was my work on this feature, I can’t say for certain. My bad. (more…)