There's been a lot of talk lately about Swift's relationship with dynamic runtime features. Since I've been developing in Swift for almost two months, I'm perfectly qualified to comment on it in depth, and that's what I'm now going to do (sorry).
First off, I like Swift's syntax a lot. Trailing closures are a thing
I didn't know I needed, and while I have a few nitpicks about the language,
overall I'm really enjoying using it.1 That said, I've found myself
adopting a few strange habits when writing Swift that I'm not sure are good best
practices, but they do seem to be the way that Apple wants Swift to be written. The biggest offender, and my least favorite feature:
[In the old days] There were lots of switch statements. To add, for instance, a copy (or
whatever) implementation to a particular view, you’d have to edit your event
dispatcher to know about that particular view and its copy function. Making
changes required making changes in various places.
- Oldie Complains About the Old Old Ways
enums are very powerful, but Apple's sample code uses them for so many things.2 I've found myself
enums in most of my ViewControllers. It not only looks ugly, but just feels wrong.
Some apologists... [would say] that
it's the programmer's fault for using it in this way... My own view is that
the behavior that you see a tool being used for is the behavior that that
Brent, and many others, seem concerned about Swift's current relationship with
dynamic features. While I don't dismiss the "old guy complaining about the
new ways" effect, I never like to discount the opinions of long-time, seasoned platform developers. They've seen these kinds of things play out before. I haven't run into most of the other issues and concerns that Brent has brought up, but I have had to write more than a few
switch-case statements, which is more than a few too many.