On Jun 5, 2014, at 11:18 AM, Mark Bernstein < email@hidden> wrote: • support for polymorphism. In C++, we dispatch on the type of the operand: […] ObjC doesn't do this, which complicated writing Visitor patterns among other things. Where does Swift land?
It supports C++-style function/method overloading based on parameter types, although strangely this isn’t pointed out in the book. I’m pretty certain it also allows ‘overloading’ based on the keywords on the function arguments, since that’s required for the Obj-C method bindings — for example it has to allow both doSomething(String, xxx: Int) and also doSomething(String, yyy: Int) as separate functions, because they correspond to -doSomething:xxx: and -doSomething:yyy in Obj-C. Delegate protocols are full of methods like this.
• the beefy switch statement is interesting, but I think lots of sentiment views switch() as a code smell. What’s its motivation?
Switch with pattern-matching is really, really, _really_ powerful. It’s widely used in functional languages (and also Go, to a degree.) It lets you take polymorphic data whose exact type you’re unsure of, and process all the different possibilities. (Optionals are just one common case of this.) It can also take data that can come in different combinations and split up the combinations by pattern-matching. Functional-language tutorials always have examples of this where you recursively do stuff with lists or trees, and handle all the different cases (head, tail, leaf nodes…) as separate cases in a switch.
The code-smell aspect of a switch is that it can sometimes be a sign that you should create a class hierarchy and implement each case as an overridden version of a method declared in the base. That’s definitely still applicable in Swift, but it’s just one specific misuse of switch.
• the language is billed as offering better runtime performance, presumably because it's easier to optimize than ObjC. However, it does accept a number of performance hits, such as range-testing array references. I'm finding it a bit difficult to imagine that optimizations can make up for these; what am I overlooking?
There are code optimization techniques that can detect & remove redundant range checks. I haven’t kept up with this stuff, but I imagine that after nearly two decades of work on JITs for Java, they’re pretty advanced.
Also, there are compiler flags that can disable arithmetic-overflow checks.
• the language appears to encourage inner classes and inner functions. My sense of the community is that inner classes are now thought to be a code smell in C++ unless they're trivial functors or comparators. What am I overlooking?
I don’t know about nested classes; are those even supported in Swift? It just seems like a namespacing thing. But nested functions/closures are pretty major in any language that supports them (viz. _javascript_). Since C++ hasn’t had lambdas until very recently, I don’t think the community has really had a chance to get used to them.
• All top-level definitions are implicitly visible to clients -- private and protected members are coming in the future. No header files, no formal declaration of external interface. This strikes me as an odd choice It’s not a choice; access control just hasn’t been implemented yet, according to the team.
• The language has been touted for its performance, but it's not clear that it's been designed for runtime speed the way Go (say) was designed for compilation speed.
Really? I expect at least C++-level performance since most of the overhead of Obj-C is missing. And at some point the optimizations should be able to overtake C++ since the compiler doesn’t have to worry about pointer aliasing. The language has been touted for its accessibility to younger programmers, but the book is clearly pitched to pros, the frameworks are certainly pitched to pros, and a language that features generics, tuples, and functional programming so prominently is not going to be especially easy to teach. What am I missing?
The book is impressively well-written and has a ton of examples. But I did notice that it moved pretty quickly, which I appreciated; I can imagine that some of this was due to having deadlines to meet. I can see how it could be expanded to have a shallower learning curve.
I don’t think this is going to be especially hard to teach. A lot of it is just _different_ to people who’ve gotten really used to C and Obj-C. People made similar statements about Smalltalk when Xerox was developing it, and yet PARC had great success bringing in middle-school kids to work with it.
(I’m realizing this week that the time I’ve spent in the past few years dabbling in ‘oddball’ languages like Scala, Haskell and especially Go is paying off big-time now; most of the new concepts in Swift are things I recognize from those languages and have at least some familiarity with.)
—Jens |