Introducing Phil Nash, Developer Advocate for C++, Objective-C and Swift tools
Phil Nash has joined us recently as a Developer Advocate for C++, Objective-C and Swift tools. Here we talk to Phil about his experience and interests and introduce him to all of you.
Twitter: @phil_nash
Blog: levelofindirection
GitHub: philsquared
A: Hi Phil, and welcome to the JetBrains team! Let’s talk about you. Can you please share a bit about yourself?
P: Hi Anastasia. Thanks for having me here. A bit about me? Well, I’ve been programming since I was 9. Like most who came of programming age in the early 80s, I started with various versions of BASIC on 8-bit home computers (ZX-81, ZX-Spectrum, Commodore-64, BBC Micro and others), but within a few years progressed on to assembler (mostly 6502 – but later 68000 on the Amiga, then 8086 on PC). In the early 90s I went for my first programming job, writing C & C++, which I prepared for by reading a book on C the night before. Somehow I managed to bluff my way in – but I hadn’t been there long before I realized I knew more C++ than anyone still there. That was the start of my C++ journey. It started on MS-DOS, but as the 90s progressed I naturally fell into Windows – which I did exclusively for the rest of the 90s.
A: What’s your background as a developer? I know you did C++ on Windows for a very long time. How did you end up doing iOS development in Objective-C and now Swift?
P: In the 2000s I changed things up a bit. The signs were there that C++’s heyday was coming to an end and I thought I should either learn other languages, or see which industries C++ would remain strong in. I started with the latter and moved into embedded programming – specifically mobile comms – where I stayed for about five years. It was a good experience and I’m glad I did it, but I also learned that embedded-programming was not for me. So I branched into banking, where I’ve mostly stayed until now. During that time, though, I also moved on the “other languages” front. First C#, then Python, then D and F#. At home I’d switched over exclusively to Macs, so I was interested in learning Objective-C, but it wasn’t until the iPhone AppStore launched that I gathered sufficient motivation to get past the initially steep learning curve!
I took three weeks off work to learn Objective-C and the iPhone SDKs (it wasn’t called iOS yet) and wrote my first app – a turn-based strategy game based on the classic board game, Risk.
It was initially quite successful – at least for a spare-time project – enough that I kept going with it. If I’d kept up that momentum, who knows where it would be today. Unfortunately I was still working at a bank and that was when the credit crisis hit! 80-hour weeks suddenly became the expected norm and I had to take on extra responsibilities – so there was no time, nor space in my brain, for outside work.
By the time I was able to pick it up again it had really got left behind. It was also hard to maintain and extend, due to being my first iPhone app – and first Objective-C codebase. I was learning as I went and it showed! So I started adding tests and doing significant refactoring. By this time I also started giving talks on Objective-C – hoping to help others past that initial learning curve too – it gets much easier on the other side.
A: Let’s talk about C++. The language has been here for many years. Do you think it will stay for long? Are the new standards valuable enough to help it compete with other modern programming languages?
P: When I first started worrying about the decline of C++’s dominance, the “modern languages” that were taking over were Java and C# – and I’ve since worked with both – especially C#. When the next standard kept delaying, that decline seemed to accelerate. At the time I thought there must be another systems language ready to take over. That’s when I got interested in D – which started as a reboot of C++ – dropping C-language compatibility (but retaining binary compatibility). D2.0 was being worked on by Andrei Alexandrescu – a well known name in C++ circles – and looked very promising indeed. But D didn’t get the traction that I thought it deserved. In the meantime C++11 finally arrived and the community re-energized around it. It actually started looking somewhat modern again (even beating Java to gaining lambdas)! That in itself was enough to kickstart the so-called “C++ renaissance”. But what really did it, I think, was the switch to the “Train Model” for future standards: a new standard every three years, containing whatever is ready at the time – along with the idea of separate TSs (Technical Specifications) – allowing those features not ready for standardization to still be implemented consistently, if experimentally, by compilers. C++14 really cleaned up the language in the wake of C++11 – and C++ is continuing that progress. We’re already looking ahead to C++20 and beyond.
Along with a huge surge in committee membership and participation, it seems all the blocks that led to the C++0x impasse have been removed and the community is more alive than it has ever been. So, while C++ may never again reach the overall dominance it enjoyed in the 90s, I believe it will remain a popular, widely used language for a long time to come.
That said it will always be hampered by its legacy back to the 70s – via C – which itself was rooted in the constraints of the 60s. Some isolated features have been deprecated or completely removed, but in general C++ can fundamentally only grow larger and more complex. And now we have some very interesting new systems languages gaining traction – notably Rust, Go and Swift. C++ is going to have to share the limelight, even in its own wheelhouse.
A: What’s your opinion about the upcoming C++17? Looks like some people in the community are disappointed with how it’s going.
P: I count myself among those who were disappointed when news first broke of what would not be in C++17. Let’s face it, we were all expecting to see Concepts (finally) make it in. And Modules. I think Modules have the potential to transform the way we use C++ – and solve two of the biggest problems with the language today (build times and fragile dependencies). We were hopeful of other features too, such as coroutines. But when the news dropped I think many of us were wondering if anything actually made it in!
But on reflection there do seem to be a lot of nice features coming. I think a lot of us were taken by surprise that structured bindings, a form of specialized pattern matching, made it in at the last minute, for example. string_view, variant and uncaught_exceptions are going to make a big difference as well. None of these are headline features, but they all contribute to cleaner, more efficient, code-bases in ways that C++ still sorely needs. And, at the end of the day, I see this is a victory for the Train Model. If we were still using the C++11 approach we wouldn’t be getting a new standard at all in 2017. Maybe we wouldn’t have even had C++14. Yet here we are, now, enjoying C++14 and looking forward to to C++17 very soon. And C++20 is closer than it sounds! Plus the TSs mean we can actually start playing with features like Modules and Coroutines already in most compilers.
A: Swift for the Curious – I was surprised when I saw this topic from you at ACCU 2016. Could you please share with our readers your opinion of Swift? Do you think Swift is our future in some areas?
P: By now this should be less surprising. I was already doing Objective-C, but had also branched into other languages like D and F# – and had my eye on Rust and Go. The idea of a thoroughly modern language for iOS and Mac development was exactly what I’d been wishing for – but never thought we’d actually get it. I was very excited when Craig Federighi announced it onstage at WWDC two years ago.
The first release was very promising, but still had a few rough edges and shortcomings. Swift 2.x plugged a lot of those – especially on the error-handling front. I usually describe the Swift 2.x solution as “checked exceptions done right” – although it’s a lot more than that. Swift 3.0 plugs even more – but has also been a big clean-up effort, removing inconsistencies, dropping legacy naming (when mapping framework functions in from Objective-C) and getting as many source-compatibility-breaking changes out of the way as possible. Swift 3.0 should now be a lot more stable in terms of language changes – most planned changes now are purely additive. This means that many projects, especially larger ones, that have been holding back should now start to adopt Swift. There’s a lot of love in the community for Swift and I think it has a bright future – certainly on Apple’s platforms – but even beyond. IBM are heavily investing in Swift on Linux now. They even have an Open Source web framework written in it: Kitura.
As a language, Swift draws on many features found in languages like Rust and Go. But it also has a lot in common with JetBrains’ own Kotlin. Both are pragmatic languages that borrow a lot from the functional world without committing to being a functional programming language.
A: Your personal blog says, “All problems in computer science can be solved by another level of indirection.” That’s quite an interesting principle. Could you comment on it?
P: This is the famous quote from David Wheeler and refers, in general, to our use of abstraction to solve problems. It is most commonly associated with the use of pointers or references, but is more general than that. I particularly like Kevlin Henney’s modification, where he adds, “except for the problem of too many levels of indirection.” I’ve touched on the problems of over-abstraction in a talk I give about Simplicity, for example here.
I was quite surprised when I found, some years ago, that the domain name was unclaimed – so I quickly took it. Of course I had to also register extralevelofindirection.com – which just redirects to levelofindirection.com (and I never get tired of pointing that out).
A: You are an author of Catch, an open source unit test framework for C, C++ and Objective-C. Could you please share the main idea behind it? How is it different from other popular unit testing frameworks?
P: So if you go back to when I was testing and refactoring my first iPhone app, at the time there was only really one test framework in town: OCUnit – which was still a third-party framework with poor integration. It was such a pain to use that I started toying with the idea of using a C++ test framework via Objective-C++. Objective-C++ is a bridging language that allows you to mix C++ and Objective-C in the same source code. So I started evaluating C++ test frameworks – including some I’d used before – but still didn’t really find anything I liked. In particular they all seemed complex to use and hard to set up. I started to get that feeling familiar to most developers, “how hard could it be? I could knock something up in a weekend!”. So I started playing with some ideas for my own test framework – written in C++, but fully compatible with Objective-C too. I had some specific ideas in mind, such as using natural C/ C++ expressions instead of the set of ASSERT_xxx macros that are usually found – but still wanted to capture values of the left-hand-side and right-hand-side independently. I was trying to do it with multiple macros at first – which was horrible. Then I saw Kevlin Henney achieving the same thing with expression templates and I realized that was the way to go! I also borrowed his idea of Sections (although he originally called them Dividers) and they became key features of what became Catch. But it was two other features that probably contributed most to its popularity: (1) it’s header-only – and a single file at that, and (2) in general everything is simple to use and low-friction. You can download the file from GitHub and start using it in real code in less than a minute!
More recently a few other great frameworks have been appearing that have many, if not all, the same advantages. So the competition is heating up – but I’m happy about that. I think everyone benefits. That said I’ve now started on Catch2, which drops support for pre-C++11 compilers in favor of a much simpler, easier to work with codebase internally – as well as support for things like threads.
A: How do you see your responsibilities as a Developer Advocate in JetBrains? What are you planning to start with?
P: I like that JetBrains uses the term “Advocate” instead of the more common “Evangelist.” Advocate implies (to me, at least) a two way relationship. As well as representing the company and its products to the community I’ll be representing the community to the company. So staying part of the community is a big part of it – and that’s something I love! That includes continuing to give talks at conferences, meetups, and other events – and I have a few lined up already – writing more blog posts – both to my personal blog, as well as the official JetBrains blog now too – and continuing to maintain my open source software – especially Catch and Catch2. JetBrains are smart enough to realize that for me to stay relevant I need to keep up a healthy ratio of real coding. In addition I’ll be doing screencasts and webinars that are more focused on the products themselves.
A: Let’s talk about tools now. What do you usually use? When did you first learn about JetBrains tools?
P: I’ve been a long time user of Visual Studio on Windows (back from when it was just the Visual C++ IDE) – and before that Borland C++. On the Mac I’ve been using XCode, but when AppCode first launched I was keen to try that out too as I was already familiar with ReSharper from my C# days. I’ve also been a user of TeamCity for a few years and was a factor in us using it in my previous role – where I was also promoting ReSharper C++ when that launched. So in a way I’ve been an advocate for JetBrains products for a few years already. I’ve had my eye on CLion since it launched but only started really using it more recently as I’ve been writing Catch2 with it exclusively. This works really well because the CMake project can be used to generate other build system projects, so is ideal for cross-platform development – even when using compilers that CLion itself does not yet support (such as Visual C++).
A: Could you share your favorite feature in CLion, AppCode or ReSharper C++? What do you most like about them?
P: My previous role involved quite a large, complex, code-base – over a million lines of code, split across about 40 projects. It was a Visual C++ solution so I tried ReSharper C++. Having reliable code navigation across all that was a huge win. Similar tools I’d used before hit more limitations when dealing with template specializations and overloads. Closely related were the refactoring tools – especially Rename – which, again, worked reliably. What I like most about these features is that they reduce friction when working with the code-base. We often talk about how much time is saved but that’s not necessarily a good metric. When most of your development time is spent waiting for builds, stepping through code in a debugger, writing emails and talking to other developers, actual coding time is a small part of an average day overall. But when you are “in the zone,” having things at your fingertips instead of minutes or seconds away makes all the difference.
A: Thanks for the interview, Phil. We wish you all the best at your new position and look forward to working together!
Follow and ping Phil on Twitter and feel free to catch him at conferences and ask your questions.
Subscribe to CLion Blog updates
