A Trifle Absurd

A Taste of Ruby

My allergic reaction to hype and personal distaste for keyword block delimiters (do…end) has kept me away from Ruby, but I gave it a try the other day and you know what? I like it.

I had some minor XML-munging to do, so I started writing a Python script. But none of Python’s plethora of XML-parsing possibilities was simple or convenient, even though what I wanted to do was extremely simple. Grumbling in frustration, I decided to give Ruby a try.

Scant minutes later, I had a working script, despite never having programmed in Ruby before. The code was simple and clear, and easily extended to cover a parallel XML-processing task. That’s the kind of initial experience that will bring me back for more.

Where to Go from Here

I’ve been wondering whether to keep programming or switch careers (see my last post), and I think I’ve found a way to do both.

I like working as part of a team, and I missed that as an indie developer. So I’m going to get a programming job.

I like balancing programming with other creative work, and I missed that in my former days at Microsoft. So I’m going to make time for writing and music around whatever job I get.

That’s the news in brief; now back to some ordinary, minimally-introspective blogging.

Concurrency is Coming

This iMac I’m using is my last uniprocessor computer. After decades of predictions about parallelism, the multiprocessor machine is finally going mainstream. And now that multiple cores fit on a single chip, they’re going to multiply at a Moore’s-law pace.

So it’s about time we figured out how to do concurrent programming. OS-process parallelism can spread the load over a few cores; OS-thread parallelism can do a bit more; but how is your app going to handle a couple dozen cores a few years hence? Shared-state concurrency as practiced these days isn’t going to cut it. (But you’ve heard this already…)

We’re starting to see programming languages that take that challenge seriously. Erlang is the best-known example, though there are others: Haskell (with STM) and Oz come to mind.

In a few spare moments (my nearest equivalent to “spare time”), I’ve been hatching up ideas for a little highly-concurrent language of my own. I doubt anything will come of it before I ship Trifle, but then, who knows? I might add something to the towering babble of computer languages.

Learning Takes Time

I often feel that Trifle is progressing at a snail’s pace. Shouldn’t I have gotten more done by now? But in my clearer moments I remember that I’m not just developing an app, I’m learning a new platform (Mac OS X), framework (Cocoa), and language (Objective-C).

Learning takes time. There’s no getting around it. I’m not just talking about the direct time it takes to learn something, but also the false starts and fruitless investigations that go along with it.

Last week I thought up a couple of different ways to handle custom columns in Trifle. I picked a solution and spent several days coding it. This week I realized that it was the wrong choice; the other way would be simpler and easier. So I had to rip out the work I’d done and start over.

Or take Core Data. Trifle is an awfully database-ish app, so I had to investigate whether Core Data made sense for it. I’ve learned quite a bit about Core Data now, in multiple stints, but it still isn’t the right choice for Trifle.

I could call that wasted time, but it isn’t, really. It’s just part of the overhead of learning to operate in a new environment. Besides, learning is one of my favorite things to do. Maybe that’s what attracted me to programming in the first place: there’s always something new to learn.

I (Still) Want an Editor

I want a Mac-native text editor that supports:

• syntax-aware automatic indenting
• syntax-aware search (project-wide, both “find definition” and “find all uses”)
• arbitrary programming languages
• proportional fonts

Is that too much to ask? Apparently, yes. I haven’t found a single editor that implements all four. TextMate can’t handle proportional fonts. SubEthaEdit can’t indent intelligently. XCode isn’t extensible. Et cetera.

All this is reminding me why I started working on Overleaf. Too bad I don’t have time for it right now. Maybe I’ll get back to it in the sweet by and by after I ship Trifle.

Breaking a Retain Cycle

Today I came across a retain cycle that Cocoa’s usual conventions can’t break. Trifle’s collections keep their items in an NSMutableArray, and items keep their collections in an NSMutableSet. Since Cocoa collections always retain their members, this creates a cycle.

I toyed with the idea of allowing the cycle, and then breaking it with careful manual deletion. But that’s way too easy to get wrong, especially with the undo manager in the picture.

An NSValue can contain a nonretainedObjectValue, so I could store NSValues in the set instead. The NSValues would be retained, but the collections inside them wouldn’t be. The extra layer of indirection would be a bother, though.

NSHashTable is a better answer. It’s a non-object data structure that provides the same functionality as a mutable set, but lets you specify whether to retain/release member values. The only catch is that I’ll need to write a few simple methods to expose it to key-value coding (search for “unordered” in Tiger’s release notes to learn more).

Of course, life would be better if I didn’t have to spend time thinking about retain cycles. Cocoa does a decent job papering over the limitations of reference counting, but I’d still rather have real garbage collection.

Update: An even better solution for this problem is to use toll-free bridging. CFSetCreateMutable(NULL,0,NULL) gives me a non-retaining set that I can just cast to NSMutableSet and use.

Scripting Automated Tests

When using AppleScript, most people see GUI Scripting as a last resort: it’s a lot nicer to say “select first collection” than “select row 1 of table 1 of scroll view 1 of splitter group 1.” But the very qualities that make GUI Scripting unattractive—such as fragility, and dependence on explicit mouse and keyboard actions—make it a great tool for automated testing. I don’t even have to wait till Trifle is scriptable: I can write tests now.

AppleScript, though, is far from my favorite programming language. Thank goodness there’s appscript, a bridge that lets you use Python to script AppleEvents. Appscript can’t paper over all the oddnesses of AppleScript, but life becomes much easier with all of Python at my disposal.

For instance: I can drop down to the Objective-C level to verify something using PyObjC. I can use any of several test frameworks. And I can verify saved Trifle documents using Python’s XML support. This is Python’s sweet spot: libraries to connect to just about everything.

Mode Mitigation

As I mentioned yesterday, table-centric apps seem to be stuck with a modal interface. But most of them try to mitigate the mode problem, so you’re not left double-clicking on cell after cell to get into edit mode.

A few examples are in order: Spreadsheets let you enter edit mode via any printable keystroke. Mori lets you arrow between rows while staying in edit mode. OmniOutliner lets you edit text with a single click.

Wait, if OmniOutliner just lets you click once to edit text, is it still modal? Yes. Several alphabetic characters are used as select-mode keyboard shortcuts. For instance, pressing E in select mode switches to edit mode, rather than typing an E. And other keys behave differently depending on where you are: pressing return in a note inserts a line break, but pressing return in a header creates a new header. But on the whole, OmniOutliner does a fine job of mitigating the modal mess.

And mitigation may be all we can hope for. Editing tables in Word is basically modeless, but that causes trouble on its own. There’s no distinction between selecting a cell and selecting all the text in a cell, so there’s plenty of opportunity for misunderstanding between user and application. Maybe we’re stuck with modes after all.

Modes of Table Editing

There was a time when editing text entailed switching between command mode and edit mode. But we’ve moved on (except for a few stalwart vi users), because modal interfaces suck. So why do table-centric applications like Excel and iTunes still use modes so pervasively?

For one thing, there’s a conceptual difference between selecting a cell and selecting the text inside a cell. In an iTunes playlist, you delete a song by selecting a table row and pressing delete, but you delete a song’s genre label by selecting the text in the genre cell and pressing delete.

A mode switch also makes a convenient transaction boundary. In Excel, switching out of edit mode triggers recalc. In most table-based apps, leaving edit mode records an undo action.

I can see why modes persist in this context; there’s no easy way to get rid of them. I keep thinking there must be a better way, though. Moving from the block cursor to the insertion point helped eliminate text editing modes. Is there a similar innovation that can save us from table editing modes?

Choosing an Embedded Language

Evidently I’m doomed to have to choose among programming languages over and over again. This time I need a language for Trifle’s rules. The qualifications:

• Abstraction mechanisms — not just simple expressions.
• Simple, approachable syntax — People with only a smidgeon of programming experience should be able to do basic things with it. (There will be a dropdown-list UI wrapper for those with no programming experience.)
• Sandbox security — rules will be saved in Trifle documents, and I don’t want macro viruses on my hands. Those who need more power can hook into Trifle via AppleScript or another external scripting language.
• Small and embeddable — in particular, a clean and usable C interface.

F-Script and Tcl fail the syntax test; regrettably, so does Scheme. AppleScript isn’t sandboxed (plus it’s just a little too funky for its own good). The plausible prospects, as I see them, are Lua, Io, and JavaScript.

Lua was made for this scenario. It’s tiny, easy to compile, and simple to embed. Somehow, though, it always manages to rub me the wrong way. For instance, the distinction between dot and colon for accessing objects constantly trips up folks coming from other languages.

Io was inspired by Lua, but emphasizes simplicity and regularity of syntax (perhaps to a fault). I find it very attractive, not least because Io expressions look an awful lot like spreadsheet formulas. But it has a small user base, and still hasn’t quite hit 1.0.

JavaScript is the elephant of this bunch (or would that be the rhino?). It’s probably bigger than Io or Lua, but it’s available in a standard Mac OS X library (WebKit), so I wouldn’t have to ship it. The syntax is full of C-isms, but it’s so widely known that wouldn’t be much of a problem. And the security sandbox is heavily tested.