Swift Inexperience

My two cents on David Owens’ take on Swift Experiences.

In the section on Modern Syntax, David makes some points that could be valid in some contexts.

The example that’s showing the modern syntax for sorting an array of strings *is* fraught with ambiguities and complexities.  But this is a shortcut syntax, intended to be used in cases where those ambiguities and complexities aren’t a problem.  If the definition of the types isn’t obvious, then I think you shouldn’t use this syntax.  It’s a decision left up to the programmer.

Generics are an awesome feature for building collections, and a terrible idea for almost anything else. I like typed collections. I like that when I pull an item out of a collection, the compiler and IDE know what it is.

Operator overloading is great when the result is clearly what you would expect it to be (meaning, for example, that adding two items yields a third item that is what you’d expect to get when you add those two items), and a terrible idea otherwise.

Some of the items in his “A Lot More to Say” section are not design choices, but implementation problems that have no doubt arisen because they shipped the language a year too early.  The slow, buggy compiler, and the poor debugger anyway.  Those will get fixed.

 I’m still on the fence about reflection; the ability to have objects opt-in to reflection reduces some of my concern, but I do miss the ability to reflect on anything. On the other hand, I’ve seen that feature mis-used so many times that I’m not sure taking it out of the toolbox is such a bad thing.  The ability to change an object’s behaviour at runtime is both cool, and a nightmare to debug when it’s some library doing it in a way that’s affecting your project.

Our usage of the Objective-C language today is based on a lot of convention, that has developed over a long time. You absolutely can write strange, obtuse, terrible Objective-C code, but we don’t, because we know better.  With Swift, we don’t have that experience yet.