The Situation (Day 3)

I got the last of the stuff packed up to return to my ex-employer - a development board, some debugging boards, a dedicated LCD screen, a power supply, a couple of microphones, some cabling, my keys, some shoe strap for grounding myself when I was working on the lab floor (so stylish!) On Friday I will be returning these items and picking up my final paycheck. The exact contours of our financial situation will be clearer.

I went to the gym again last night for a brief cardio workout. It often feels hard to drag myself to the gym, at whatever time of day or night – it’s too late, I’m too tired, I have too much to do, the kids are being obnoxious, the sink is full of dirty dishes, whatever. But I always feel better afterwards. So I’m going to try to keep that up, at least in the short term.

Today, I got my résumé up on the Michigan job bank web site, and looked at some positions posted in the area (within commuting distance). I can do it all online, except that I’m required to report to a service center in person.

There are some employers in Saginaw offering embedded software development positions. That’s encouraging. They are automotive-related. I have a relevant experience. I will have to find out whether their requirement of an EE degree is a firm requirement, and how much they might pay.

Yesterday, I filed the paperwork to take a lump-sum distribution from my 401K account. It’s not ideal. I’ve been feeling guilty for many years that I don’t put nearly enough into retirement accounts or other more accessible savings. I’m not the only one in that situation. But maybe I should just allow myself to feel better, at least for a moment, that I put enough in there to keep our family afloat for a while. My wife has been looking into the situation with food assistance. That could really help with our “burn rate” while I’m looking for work.

Between unemployment compensation, food assistance, and my 401K, I should be able to cover our basic expenses, including health insurance through COBRA, for a while. We are trying to figure out exactly how long “a while” might be. But it seems that it might be long enough that I can actually think about what job I might want to take, instead of jumping into the first thing I can get. It’s never good to have to be forced to make decisions out of fear. I might even be able to do some self-retraining, and so open myself up to some different possibilities.

I have been thinking about what it might take to get into iOS development. I’m well-positioned to learn something like that. In 2008 I bought in iPod Touch with the intent of learning to develop for it, but I just didn’t put time into it. Well, maybe now I’ve got a little time. I’d certainly no longer be an “early adopter” – not a pioneer, and so hopefully wouldn’t wind up with any arrows in my back. But on the downside, there are a lot more experienced developers for the platform that started earlier and so I can’t start out as a fish in a small pond, as I did with Newton development back in 1993.

I’d have to pick up Objective-C, which seems quite feasible given my background in learning programming languages. I’d have to pick up the iOS APIs. It might seem odd that I don’t already know Objective-C well, since I’ve done a lot of development on Apple platforms. In truth, I’ve dabbled in Objective-C a little bit, going back to playing around on the NeXT environment. The bulk of my experience writing code for Mac was pre-MacOS X, using THINK C and CodeWarrior. The code I wrote for Mac OS X consisted of drivers, which are written in C++ using the IOKit framework, and a ported GUI for the Qt framework. Some of the details escape me a little bit, since it’s been almost ten years, but it was in C++, not Objective-C.

I was thinking it might even be worth it to head to a training program, like one of the week-long classes offered by the Big Nerd Ranch. That kind of thing is often good for networking as well as learning. We might be able to arrange for my wife to get enough child-care support that she could spare me for a week. But the price is more than a little daunting – five grand for the Beginning iOS class. I’d still have to buy an iPad and airfare, and maybe a week’s worth of food. I’m not sure we can swing that. Could I learn most of that with an iPad and a book? Sure, but the whole point of the class is that it’s a defined, blocked-out chunk of time, and there is support to help you get through pitfalls quickly. And there’s the networking.

I’m also, in general, wanting to fulfill a long-held dream that some of the last twenty years of progress in language design – and micro-controllers – might lead to some real improvements in the toolchains for embedded systems and drivers. I do this informally whenever possible, at whatever level I can – replacing straight DSP assembly code with macros, to let me write less code and make the solution more self-documenting; modeling hardware registers with C++ classes, to take advantage of constructors in initializing them and setting up things like polarity and “don’t care” bits and masks that rightfully belong in a class, not a #define. I’ve been able to use Haskell, Scheme, Dylan, Ruby, and Python “in anger,” in my work – usually to put together a prototype, or write a script to churn through some data, or test a numeric algorithm that will be re-implemented in C or C++. But I haven’t been able to ship code for an embedded system written in these languages, except sometimes for generated C or C++ code. I’d like to see that change.

Hell, I haven’t even been able to embed an interpreter since I developed a survey engine for the Newton, or when that system was ported to WebObjects, using GNU Kawa as an embedded interpreter. In the embedded space, that’s still not common. And so I keep seeing Greenspunning, where developers write their high-level logic in some kind of data-as-program – in C or C++ – in what is essentially an ad-hoc interpreter. Templates would be bad enough, but sometimes, it’s even done with macros (shudder).

If they were writing in something like NewtonScript, it could really be data-as-program. The “script” for a given survey is basically an elaborate compiled data structure, with functions for determining run-time branching right in there with the strings and symbols – effectively, a domain-specific language.

This approach basically cries out for writing the application as a library, and driving it with real “business logic” running on an embedded interpreter for Lua, or even better, Squirrel, or Guile, or …something! Something other than yet another realization of Not Invented Here! Just because we’re writing embedded code, does it mean we can never have nice things? I’m not talking about DSP code that has to service a DMA interrupt in a tiny, fixed time-slice. I’m talking about slow, event-driven code. That includes GUI code.

That might be starting to change. I’ve been encouraged by the existence of Commercial Users of Functional Programming. I’ve been encouraged by what’s going on with Haskell, and companies like Galois. The adoption of Scala looks very promising, so I’m conducting a little investigation into Scala, and writing up some notes. And, trying to plan the rest of my day.