blog-header-image-size-48
Error-free Automation Built on Swift

(Republished from Spring 2017)

1o2wrxlg3z2m4f1u5owxscg

At PassiveLogic we undertook an interesting experiment early in 2016 to refactor some of our C-code to Apple’s new systems language Swift. This experimental project proved successful, and we decided to make the bold move of rewriting our whole code-base in Swift.

It may seem like an unusual move to adopt a new language for a systems-critical startup. It was a decision that was carefully considered. The harsh reality is the go-to systems languages C and C++ are approaching middle age, and it shows.

For the last couple decades, we’ve seen programming languages evolve rapidly in response to the demands of rapid prototyping, web and application development, and the rising complexity in parallelism and client-server architectures. In contrast, systems languages have moved very slowly. This conservatism, in part, has been the source of their durability. But extreme conservatism isn’t the business of the tech industry or startups. During the last decade, the surrounding tech market has been increasingly looking towards higher-level languages to increase development velocity and competitive edge.

The Cost of Code

The deeper PassiveLogic got in the development of our next-generation control platform, the more C and C++ felt like an anchor. It wasn’t just the speed of coding or programmer happiness… the final decision was far more business-critical. After all, initial coding is really limited by the speed of your brain, not your fingers. That alone is not a reason for a language move. This was proved to me by one of our developers who far out-ran a python programmer using plain old C — he is the mythical 10X programmer who can knock it out of the park. So language efficiency is important, but it’s not the most important factor.

In fact, the most important decision in language selection is the business decision. Because the cost of programming doesn’t end with the initial implementation where the developer typically draws the line of done-ness… that point where you think: “I did it” and reach for a high-five. No, the cost is the long term relationship with that code through unit-testing, debugging, field testing, finding all of the edge cases in production and the accumulated technical debt that the next guy will have to shoulder for years to come.

Even when your startup passes the valley of death, it is common to see companies languish with products stuck in technical slow-motion. They can become so technically indebted that all engineering resources are consumed chasing bugs instead of building more value for the customer. We’ve all seen it happen.

Why Swift

The challenge is how do you enable your developers and address the larger business goal? Enter Swift. Swift is the first systems language that really addresses this hole in the market. Its goal is to be the programming trifecta:

  1. Productive high-level language syntax
  2. Inherent Safety and Security
  3. Fast low-level C like speed

The first two are effectively new to systems programming. Yes it’s true C++ has been bolting on more productivity over time, but it can’t shed its bad habits, safety risks, and indeterminate behavior. Just take “null” for example, which by some analysis causes 25% of software bugs. The null trap isn’t even possible in Swift. If you add things like bad typecasts, mis-matched enums, memory issues, incomplete case statements, and the like… one robotics company found that 40% of the bugs in their issue tracker couldn’t have even occurred using Swift.

Valuable? Absolutely. But the effect can be multiplicative. I watched one young programmer struggle with complex pointer bugs in C for weeks trying to nail down his unit tests. That was a lot of debug time and brain suck that could have focused on productive thinking and thoughtful feature development.

And the challenge is worsened by the fact that the average C++ programmer is in his 40s. Partly because the age of the language, and party because it takes that long to master. This presents an on-boarding challenge for hiring young talent. Swift doesn’t eliminate this, after-all its a new language, and has evolved rapidly. But architecturally, its a pruned tree aligned with current computer science thinking and bares a lot of resemblance not only to the C family, but modern scripting languages… making it feel familiar. It doesn’t hurt that smart developers look for fun opportunities, like learning a cutting-edge language.

These advantages together with Apple’s backing have pushed Swift into the top 10 ten programming languages in just 2 years rising faster than any language in history. Community matters.

Swift Challenges

Some of the challenges we expected. Adopting a new language comes with a learning curve. And some were discovered as we got deeper into development.

On the face Swift is deceptively C-like and obvious, but then it sneaks in ideas like value-types, declarative programming, and functional architecture into the mix in ways that experienced programmers might bang their head while trying to understand the sometimes very subtle paradigm shift happening below their feet. Once everybody is on-board, these changes come with well-reasoned purpose and pave the way for safer programming… but it extends the learning curve. Swift’s on ramp is easy at first, but has a few discontinuities.

Swift is also a big language. Taking the duck-typing simplicity out of a high-level syntax like Python… is a good move. Strict and static add safety to large projects. But it also leads to an explosion of types in Swift, each with their own method and protocol universe. In the process, it loses some of the intended simplicity and flexibility causing you to hunt down “how do I that same thing in this instance”. It doesn’t always feel as orthogonal as it should.

Finally, while the move from Swift 2.2 to 3 was mostly straightforward, it did spend resources. One of our team members develops on Linux, for it which it was a rougher road of developmental versions, foundation class incompleteness and build system limitations. Luckily, with Swift 3.0 stabilized, those issue have past and we are seeing many of the benefits unfold.

Conclusions

Our experience with Swift has been a positive transition. Our developers are enjoying working in the language, and where we have had rough spots it been refreshing to see how quick and engaged the community has been in improving these issues through better syntax, architecture, library and semantic updates with each new version.

PassiveLogic is developing the the first fully autonomous platform for buildings, built on digital twins from the ground up.

Previous post
11 / 11
Twitter%20X