I think stay sharp in the tech industry, you have to be in a constant state of
uncomfortableness. If you think you know everything and/or aren’t always trying
something, you’ll lose your edge fast as your ability to notice trends and
adapt atrophies, and when the Really Big Disruptive thing happens you’ll be
unable to find your legs.
It’s easy to be a little uncomfortable - constantly asking yourself "what’s
under this?" and "how does this work?" is the healthy curiousity you need that
will save your bacon when production inevitibly fails at 4 in the morning.
Better understanding the systems you work with is a good habit that pays dividends.
However, it’s not enough to know only the systems you’re paid to know. Your
company may have been on the cutting edge once, but is it now? How would you
know if you’re missing out on some really helpful tools or technologies? This
can be a drawback with working on Unix-like systems - they’re stable,
effective, and boring, but that means new concepts take a while to shake out
everywhere (if at all), and with the variety of systems it’s easier to cling to
POSIX tools like a life preserver. If you think of how long it took for the
boolean type to end up in C, you know that you can go a long time with niceties
folks using other systems take for granted.
Once a year I try to take a quick spin in an ecosystem I’m totally unfamiliar
with, and for the holiday break this year (truncated to just a few days for
reasons I can’t get into) I decided to take a look at the Apple Developer ecosystem.
I Should Cocoa
Now for the longest time I’ve kept away from the NextSTEP stuff (Cocoa, Objective C, etc.),
and stayed within the comfort zone that is the Darwin core (UNIX/BSD).
You can treat a MacBook Pro like a really pretty terminal emulator for years,
and you’ll probably be fine (I certainly managed, and I know many people who
have also done the same). But ignoring all the other parts of the ecosystem
means I’m not able to play with the fun graphical bits of my computer, or sell
premium fart button apps in the App Store.
What I wanted to learn first was the Swift programming language. I’ve heard Swift grouped in with Go and Rust as a
next-generation systems language. The basic syntax and control flow isn’t
crazy, but I’ve not done a whole lot with it besides basic Hello World stuff. I
need to wrap my head around how they’ve extended enumerations ("it’s like C,
but flexible" sounds a little terrifying), and I’ve had some problems with the
documentation (which I’ll get into below).
Of course, using the Apple ecosystem pretty much requires Xcode IDE. While it’s using LLVM under the hood, I imagine trying to do all the wrangling
for apps without Xcode is an exercise that’s only worthwhile if you’re doing
app work full time (and even then, it looks like Xcode is the well-worn
path). As a Vim die-hard, it was a little hard letting go to work in
Xcode, but it turns out that a lot of the behaviour that I’ve augmented
Vim with (via plugins) is out of the box functionality with Xcode. The
playground was pretty neat, and handy for learning Swift, as it
continually executes and displays the output to the side.
My main problems with Xcode are the screen clutter (I’m used to just a few
terminals displaying what I need) and how it consumes so much of the system
resources that it basically runs standalone on my older Mac. The refactoring
tools are really good, but their only appears to be out-of-the-box support for
Objective-C and Swift (although I suspect this could be extended). Problems
aside, after several days I found myself enjoying Xcode, and I’m wondering how
to get some of that functionality into Vim.
After getting my feet wet with Xcode and Swift, I figured it was time to build
an iPhone app. I’ve seen enough 12-year-olds hawking their apps, so I figuring
that this should be a cakewalk. However, this is where my Unix background slams
into the wall. I’ve done a lot of OO-programming, but I don’t often work with
the UI (often sticking with HTML output, which is easily manipulable in a
terminal). I managed to get an app partially done, and with any luck I’ll find
the time to finish it and drop it in the App Store.
I was still hitting some mental roadblocks while trying to get a basic
application out the door, and at this point I figured the problem might be with
the documentation in Swift. I still like Swift, but after looking at the API
docs I still couldn’t see how everything would fit together, and there was too
much "give you the fish" and not enough "teach you how to fish." So that’s when
I decided to take a look at Objective-C, which I figured might be the Rosetta
Stone to me grokking how to really work with the built-in frameworks.
Jumping into Objective-C seemed to be the trick. I forget where I heard the
anecdote, but there’s a line of reasoning that the C-style languages have
survived this long because the documentation has to be more in-depth.
Objective-C may be a superset of C, but to use its power requires learning a
lot of new syntax and behaviour. That said, the docs were a lot meatier on the how-and-why.
A bite from the forbidden fruit
It’s worth bringing up the bit about "diminishing returns." After working with
any system after 10 years, digging deeper and deeper into its guts, the work
you’ll put in to better understandin better yields less and less reward.
Spending a few days learning more about macOS has been more beneficial than if
I’d spent my time reading some GNU coreutils source code. It’s easy to get a
little over-specialized, so it’s good to spend a few days a year getting
outside of your comfort zone.
I’m still a big believer in open systems - if you can’t fix it yourself, you
don’t really own it. And that’s where I get uneasy after spending some
time in the Apple ecosystem. It’s a walled garden, but a really good walled
garden. There’s a lot of thought put into the interfaces of their frameworks,
and they’re solving real problems instead of continuously re-inventing the
wheel. It’s not hard to make a simple program that looks good. After getting a
whiff of the kool-aid, I can confirm it smells mighty delicious.
I’ve taken a quick look at GNUStep, and while it
addresses the Cocoa aspect, it says right on the tin that they’re not striving
to be an operating system. In classic bazaar fashion you’re expected
to cobble together the parts yourself. But having looked at the macOS
experience a little more deeply, I can see a big part of the appeal is that
macOS supplies you with decent default programs. tools, docs, and frameworks
right from the start, and for many people they will happily use these Good
Enough defaults. An open-source operating system using the Linux kernel,
GNUstep, and good default programs seems like a great idea - I wish I could be
the person to start something like that, but I think that’s a project for
someone with some time.