I co-host a podcast called Debug with my friend Rene Ritchie. It’s an interview show and we chat with our guest about either the topic of the day or their career. Mostly we cover careers, the arc of technology, their role in forming it, and how they feel about it all now.

At it’s worst Debug is someone incredibly smart and remarkably good at what they do recounting how they came to particular decisions (both in life and in technology) and reflecting upon their reasoning. Invaluable knowledge that has been hard earned and they’re passing it on to listeners. Tuning in to Debug is being a fly on the wall during a casual conversation with some of the smartest people in software. That’s the bad news.

At it’s best Debug captures an oral history of one the greatest transformative moments in technology. People like Don Melton, Nitin Ganatra and David Gelphman have all been on the show and been remarkably honest about a famously secretive company. I don’t even want to start counting the number of ex-Apple people who’ve been on the show. Suffice to say if you really want to get a window into how Apple works: Debug is it.

With the exception of The Record and the upcoming App: The Human Story I can’t think of other attempts to try to capture this history. It’s important because it’s impactful. Not because of the notion that the world will be remade in the image of Silicon Valley idealists but because there are kids out there who really love their Angry Birds pillow.

I would like to spend more time focused on making Debug better. Not a podcast you listen to on your way to work. An oral history of the development of technologies that are changing the world.

So, you might have seen this coming. Consider sponsoring Debug by getting in touch with my friend and all around ace, Jessie Char. She can be reached at her first name at neat dot fm. I’d be more explicit and helpful but, come on, that’s really not asking too much.

Also, if you’ve been on the show and have said things we’ve cut and really don’t want them to be public get in touch. We can work something out.

I’ve known my friend Gus for a long time now and he’s always been an ace. Gus is the kind of fella that will tell you straight up if you’re being a dummy.

Gus is not a dummy.

He’s just released Acorn 5 and it’s really quite something. If you love to draw or design buy it. If you enjoy software — go buy it.

There’s an attitude to Acorn that is unique. It’s friendly and flippant while being extremely competent. Under the “Bézier Stuff” menu you’ll find incredibly well implemented and easy to approach tools for addressing what’s normally a fussy aspect of vector graphics. And the Shape Processor is a lot of fun too.

If there’s one thing about Acorn I cannot stand it’s that I didn’t write it.

Go buy Acorn 5.

Brent Simmons has been writing a Swift Diary covering his attempt at using Swift for a project he’s working on. In Swift Diary #11 Brent writes:

My main problems with Swift are:

• Collections of protocol-conforming objects don’t work as I need them to.

• No KVC.

• No equivalent of NSClassFromString.

There are a lot of reasons why KVC (Key-Value Coding) is valuable on Apple platforms. First, Interface Builder, XIBs, and CoreData all depend upon it as their foundational technology. Not to mention all the other parts of Cocoa that leverage it (like the often troublesome but sometimes really useful bindings) and all the supporting code that’s been written with the flexibility of the Objective-C model in mind. Being able to easily translate a JSON feed into Objective-C model properties was a real strength. Ideally we’d be able to do the same with Swift. Currently we can’t do that. The double edged sword of strict type checking and static dispatch has rendered fundamental approaches to building software for Apple platforms difficult at best and impossible at worst. Neither AppKit nor UIKit could be built with a strict Swift base.

Second, there is no equivalent of NSClassFromString. Frankly, that’s fair enough. There isn’t a Swift equivalent of runtime.h either though and that would be really nice to have. Ideally I’d like to be able to lookup classes, structs, enums and types and to have them well represented in a manner that can be interpreted at runtime. I’m aware of the annoyance and largely undocumented (there’s documentation but @properties were different at one point) results of using @encode. Some manner of querying the type system and interacting dynamically with it would be terrific. I seriously doubt that the internals of the Swift compiler don’t use sizeof or even offsetof from time to time. Now, that’s probably too low level given the potential for Swift objects to not be contiguous in memory with their vtables and properties but in a modern language introspection should be a first class feature. Let us lookup and allocate classes and structs and address their properties or fields in a dynamic fashion.

Protocols. Brent found himself a position where he had to copy an array of objects from one type to another type in order to satisfy the the Swift type system. With a collection of objects, all of which conform to the same protocols, it isn’t possible to return such a collection directly. Brent concludes:

The best way I’ve found to deal with this is to map it.

return messages.map { return $0 as NodeRepresentedObject }

That seems crazy. I’m using map to create an array whose members are absolutely identical to the original array. And if it would let me do that, why not allow my original solution? (Or at least the second solution?)

It is crazy. It allocates a new copy of the collection at the very least. This coercion is required because Swift prefers static dispatch over dynamic. Even in the case of protocols.

Protocols are an interesting case. Structs could be considered pretty much static. They are a collection of things and we’ll pass them by copy and they’re just like a giant CPU natural entity like an integer or a float. Classes can work in static environments. C++ and Java both have pretty static dispatch. So that’s cool, right? (Nobody who isn’t in a position to recompile their entire stack from top to bottom thinks that but, hey, open source and corporate backend peeps can wave their flags here.)

A protocol is an agreed upon method of communicating between two end points. The sender and receiver don’t need to know anything about each other except that they have agreed upon a protocol. This notion flies in the face of the strict type checking of Swift. Protocol conformance (the ability to adopt a lingua franca) is subsumed by a Type, which is the strict description of Swift entities.

Every time you send a message to an Objective-C instance (call a method on an object) the runtime looks it up. There’s a cache and a lot of really fancy optimizations that make it go really fast. Really, if your application is spending a lot of time in objc_msgSend then I’m impressed. Protip: You’re likely dealing with a collection and drop down to CoreFoundation and you’ll gain speed there.

A Protocol is anathema to the Swift language. I know. I watched that session too and it really was compelling. A protocol that can’t behave as an arbitrary communication line between two disparate object lay-outs isn’t really a protocol. It’s a straight jacket.

That’s what Brent was bucking against. He wanted to express something completely natural — he had a collection of instances that could all be addressed in the same manner. He wanted to vend them as such. He properly advertised their abilities and then the compiler balked. The compiler balked because, without coaxing, it was incapable of producing the code that would have solved his issue.

So Brent was forced to make a copy, on every call to his accessor, of a collection. And this in the name of efficiency and speed.

My proposal for Protocols in Swift is this: default to the Objective-C dynamic dispatch method. If objects respond to the protocols then that’s great. If not then error out or flat out explode. Hell, post a warning if you really feel strongly about it. In the cases where Protocols are usable now then make that a fast path. You can do both dynamic dispatch on objects that conform and static dispatch when you’re sure, as you are now, that static dispatch will work.

Protocols should work as you’d expect them to work: if an instance says it conforms to a protocol then it should be able to be addressed as such. If that can’t or won’t happen then we’re not dealing with protocols. We’ve dealing with compile time contracts. That’s a very different, and far more boring, thing.