Brad Larson on using Swift for robotics
I’ve been following the linked blog because I’m really interested in the usage of Swift in environments different from the typical Apps. And because using it for robotics seems pretty cool.
The post gives some conclusions about the rewrite of the project in Swift, and has some really interesting points. I recommend you to read it.
I would like to highlight here some things that really liked while I was reading it. Now.
However, I have only become more convinced over time that there should be the ability to specify error types in the Swift 2 model.
I’ve already talked about what I don’t like about the error handling system in Swift and after this months people seem to just confirm it.
You can do it in Objective-C
Could I have done this in Objective-C? With blocks, yes in most cases. Swift just makes this easy, so I started thinking about problems in a different way.
This is a great way to put it. Yes, it’s completely true that Swift makes things easier, the language seems to help you to write better code. But almost all of the ideas that we are using in Swift could be used in our beloved Objective-C, even with some ugly syntax.
I really like that Swift makes writing some things more confortable, but if we still have to write in Objective-C we can bring those new techniques back to our old code.
It’s about the oportunity
This rewrite gave us the opportunity to completely rethink the design of our application.
Starting something in Swift gives you the opportunity to rethink the designs. But that doesn’t mean that you have to overuse Swift features just because. For example, don’t create thousands of protocolos just for the shake of using the cool protocol extensions.
In the other hand, you should really use this opportunity. Not just try to rewrite your Objective-C code in Swift, being disappointed by the current limitations of the language or by the strictly typed compiler.
Embrace the change, keep and open mind. But also take it easy and don’t go too far just because you can.
## Let your code decide
Instead of trying to plan out some grand architecture and figure out how we were going to reuse code, we just started writing. It was only at the point when we felt like we were repeating ourselves that we stopped and thought about extracting the common code from these sections.
Another great thought that I’ve been taking about, and a critique that I usually find in our current way of developing software. Being too focused about trying to find a good design before hand, without even knowing what we are looking for.
Don’t waste more time discussing hypothesis without trying them. Let your code speak, don’t force it.
In another post from the same project in which they talk about PLIST in Swift, one of the conclusions is this amazing sentence:
- Instead of spending more time thinking about clever ways to use shiny new features, I should spend some time thinking about what problems I had to solve.
You don’t know how much I love this words. Go and read the entire post. Really worth it.