On Tooling

I started coding in two ways. When I was 13, I tried a little bit of C. I didn’t get very far, in fact I wrote something like this before I got confused and bored:

Basic C program — Hello World.

The other way I tried was using iWeb  — A visual WYSIWYG editor for making websites. I of course hacked around with the CSS and HTML it spat out. But I ask you — can you guess which one I enjoyed more?

Tools + language, not just the language itself, makes a developer productive. And somewhere, I feel we lost that. Tools can make up for flaws in languages, but can also enhance productivity for languages that are just fine.

Yesterday as I went to write some Swift 3 code in Xcode 8.1, the editor crashed. A restart of Xcode didn’t fix it and I was unable to even use autocomplete to fill out some nontrivial block syntax.

screen-shot-2016-11-05-at-6-54-22-pm

Adding insult to injury, I certainly can’t refactor my stuff either! In fact, try use anything from Xcode 8’s (7, or 6!) ‘Refactor’ menu and you’ll get this depressing dialog box.

Error message stating Xcode can’t refactor Swift

We’re on year three of Swift. Version 3. And the tooling still sucks. 

I was just at Microsoft Ignite here in New Zealand, and I have to hold Microsoft up as the company that does Tooling so well. I spent a few years doing .Net as a student, and quite frankly, I loved it. C# is a solid language to work in, with lovely OO and Functional (LINQ) capabilities and around it, a bunch of awesome tools such as Visual Studio, intellisense, ReSharper and more!

I spent the week quite frankly being quite jealous of the tooling. From VS you can publish directly to Azure and all sorts of other things. And then even Azure is a brilliant collection of tools that intertwine and integrate better than a plate of linguini.

Typescript, Microsoft’s new is actually leading the way with something they call a language server protocol, meaning as long as your editor speaks the protocol, you get all the features like intellisense and autocomplete. Even Rust is following. Such innovation. Wow.

In the other camp, our frenemies in Android land have Android Studio which is superb, and they love to bemoan Eclipse, which is still better than Xcode. Sure, they have to put up with Java, but since Java 7 it’s been quite nice and 8 just came out and it looks great too. Heck, even PHP has been good since v5.

You might say “Oh I’m too good for IDEs, I just use Vim”. Sure.. but wanna try tell me you have no vim plugins? Exactly. Tools.

Look, I’m not trying to have a go at language innovation (it’s great!), but this obsession we have with building new languages such as Swift and it’s features just has to be be matched with the innovation of tooling as well. Refactoring, renaming, style checking, unit testing and more must come with a new release. Rust is doing well with errors. Elm is following suit. And one could argue Go has had notable influence in its focus on really fast compile times and standardised syntax formatting (by way of the gofmt tool). Why is Swift lagging?

Sure, the official line seems to be “it’s on the list”, but I’d argue we could have at least got class renaming before several versions of Swift. It’s great they’re adding new features from other languages — but it’s not great that it is at the expense of the surrounding developer experience. With that said, do Apple really expect us to commit to Swift? How about for the Server and other places?

Still not getting it? How about this: since we like to call ourselves engineers, let’s take a more direct metaphor from our Civil Engineering friends. Swift is a new type of material, but we have nothing to mold or shape it with. Tools and materials go hand in hand, and we’ve forgotten that. It’s no different with Software Engineering.

Hey Chris Lattner. Love your work, but how about next year we don’t get a week-long migration process and instead get some better Swift tooling?

Don’t forget, Tools + language, not just the language itself, makes a developer productive.

¯\_(ツ)_/¯


/rant So that’s my current thinking on this topic. What are your thoughts? Leave a comment or ping me on Twitter — I’m @samjarman.

Microsoft Ignite – First Impressions

Hi All, This week I'm in Auckland, New Zealand speaking at, and attending Microsoft Ignite.

I thought I'd write a quick post to talk about my first time in this historic MS event. This is the 21st(!!!) event of it's kind in NZ (formerly TechEd) and my gosh it's a polished, slick event now.

I walked into a massive room surrounded by screens and orange.

img_8808

 

 

 

 

 

 

 

The keynote was a series of speakers all talking about various cool technologies Microsoft has. It doesn't take sherlock Holmes to realise that I'm more of an Apple guy, but anybody in their right mind should be able to recognize cool tech when they see it. There were demos of Chat bots, meeting room/whiteboard devices, machine learning and more!

Some of you might not know, but for 2 years, I was actually a part time, during study and summers, C#/.Net dev a few years ago... so a lot the tooling is quite familiar to me (and I actually like). Stay tuned for a rant about tooling in a future post.

The rest of the talks seemed super polished and I got to do my talk yesterday afternoon too. It was titled the Future of Apps and described the transition from Apps to Services with many devices being able to offer interactions with users for a given service. More on that in a future post.

I also got to try out the HoloLens... and that was seriously impressive. I did a couple of Computer Vision and Mixed Reality courses at University so it's really cool to see it in practice and so polished - it's definitely not an easy task. I'll talk more about that in a future post too*.

Anyway, Ignite is pretty darn cool. It's definitely a different crowd to what I'm used to (fewer hipsters and a bit more enterprise vendors) but once you get through that, the code and demos during the talks is awesome and I'm quite enjoying my self so far.

If you're also at the conference, feel free to come say hi - I'm @samjarman - just tweet me and we'll arrange something.

Take care,

Sam


*Boy, I've promised so many posts. Joy...

Update: Posts are now viewable at SamJarman.co.nz/Blog

Three Reasons Why Instant Apps are Coming to iOS

Android recently introduced a concept called Instant Apps. They’re pretty cool.

Suresh Ganapathy introduces Android Instant Apps. Android Instant Apps evolves Android apps to be able to run instantly, without requiring installation. With Instant Apps, users can open your app simply by tapping on a link, even if they don't have the app installed.

Instant apps are small portions of an app that is downloaded on demand in order to display and process information in a more rich way than a website could. Say you’re browsing for shoes online, but now want to buy. With an instant app, you could jump into the app, look at a 3D model of the shoes, choose sizes and buy with Google Wallet. Neato.

Rich. Fast. Awesome Experience.

I think this is coming to iOS. And here’s my evidence:

  1. Apple has a ecosystem for extensions now. We have the ability to create extensions for Siri, watchOS, tvOS, Push Notifications, today widgets and more! It’s not hard to see another one being added there for instant apps.
  2. Apple is training us. Apple likes to train devs. They trained us with Size Classes so they could introduce iPad Split screen. They trained us with extensions so they could release more. They like to hint and train. I think the big hint right now is the extensions ecosystem but moreover the frameworks way of thinking about code. Small, modular code that has it’s own networking layer, security and other goodness would fit perfectly into what is required, technically, for instant apps. A few storyboards for display, an API client and some access to personal data via an app group and keychain. Done.
  3. It’s the natural extension of Universal Links. Apple, once again, hinting/training us to think this way have actually shown us the mechanism of how our app will be called when it comes time to display the rich content. Being able to deep link from a website to a portion of an app you don’t even have yet would be a awesome user experience, especially if implemented properly.

In conclusion, I’m positive app extensions are coming to iOS. I think we could see this as early as iOS 11, or maybe even 12. Whenever the time, if you’re an iOS Dev, it’s time to learn some extension programming. If you’re a consumer or an onlooker, prepare for something cool. Something amazing. And something probably better than Android will ever be able to do.