A Trifle Absurd

Introducing Overleaf

I’ve named my new editor Overleaf. I figured it should have a typography-derived name, so I glanced through a glossary of typographical terms, and Overleaf sounded the best. Plus, no one else seems to be using it.

I continue to dig Cocoa as a development platform. Where else could I bootstrap a syntax-coloring editor in a week and a half with no prior knowledge of the framework? Overleaf doesn’t do proportional fonts or indenting yet, but it colors Scheme code nicely (and keeps colors in sync, too).

Google really changes the game for coming up to speed on a new platform. Today I needed a way to keep track of a set of indices, and reluctantly concluded that I’d have to write my own. But then, while Googling for something else, I came across NSIndexSet, which is just what I need. NSIndexSet isn’t yet referred to in Apple’s main collections documentation, so I didn’t know it was there; Google to the rescue once again.

Programming Proportionally

Why are we still stuck using monospaced fonts to edit code? Proportional fonts would often be better, but virtually nobody uses them, ’cause you can’t ever get things to line up right.

Autoindenting editors can already figure out where to indent a line. Add a little more behind-the-scenes calculating, and they could support proportional fonts while still indenting nicely. That is, assuming you had a convenient rich-text display and editing system… like Cocoa, for instance.

So my Cocoa experiments have turned into a project. I started out bemoaning the lack of a Cocoa editor with Scheme autoindentation support, and now I’m building a proportional-font-aware code editor. I’ve just passed from the initial euphoric “Hey, this could work!” phase to the reality-check “Hmm, this means I’ll have to do that, and that, and that…” phase. Still, Cocoa does all the heavy lifting, right?

F-Script

I’ve been learning a little Objective-C and Cocoa to get acclimated to my new platform. Objective-C is an odd beast: C plus a dash of Smalltalk is an unlikely combination. Surprisingly, though, it seems to hang together well — I think I’d enjoy programming in it, which is more than I could say for C++. (Though I might sing a different tune by the time I’ve written as much Objective-C code as I have C++ code.)

The dynamic message sends and introspection capabilities in Objective-C, coupled with the Foundation framework (with classes like NSArray, etc.), got me thinking that it would be straightforward to write a Smalltalk-ish scripting language that’s just a thin wrapper around the Objective-C object model. I even thought I might hack something up along those lines. But then I discovered that this language already exists, and it’s called F-Script.

F-Script gives you direct access to Objective-C objects and the Cocoa frameworks using a Smalltalk-style syntax augmented by handy array operations inspired by APL and its kin. You can’t create new classes, but you can do just about everything else. (Jonathan Rentzsch gives a good demo.)

As befits its Smalltalk lineage, F-Script also includes a good object browser. Not only that, you can inject F-Script into any running application (via F-Script Anywhere) and rummage through its live objects.

MzScheme or Gambit?

After a front-end-first hiatus, I’m working on the Trifle back-end again. I’ve been combing through various bits of Scheme code I wrote a while back and sorting out what I can use. Most of it was written for MzScheme (of the PLT Scheme family), though some of it was for Gambit Scheme 4.0. Now I need to pick a Scheme and run with it.

MzScheme has the benefits of popularity: more libraries, a helpful mailing list, and good tools (like DrScheme). Gambit has an optimizing Scheme compiler built for speed; anecdotally, at least, it produces much faster code than MzC (MzScheme’s “barely optimizing compiler”).

But what if Trifle could run under both MzScheme and Gambit? Given my needs, it’s surprisingly plausible. Take concurrency, for instance. Both support cheap, abundant threads (scalable to the thousands), but MzScheme uses the Concurrent ML model, while Gambit uses mutexes and condition variables. They aren’t as far apart as they seem, though: MzScheme’s async-channels and Gambit’s vector ports are thread-safe streams with similar interfaces. Erlang-style message passing would look almost identical in either Scheme, and a simple shell of an abstraction would make them the same.

I have to admit that I don’t have a compelling reason to make Trifle portable (yet), so there’s no point in doubling my testing effort by supporting both. Still, this means I can choose Gambit in confidence, knowing that if I need to switch Schemes later, I can.

Links about Links

Philip Wadler’s nascent programming language design effort, Links, is beginning to generate some buzz. There was a day-long Links meeting in Edinburgh last week (the agenda includes links to slides). Norman Ramsey attended the meeting, but thought (as did others, I’ve heard) that “different participants seemed to have wildly different goals”. He thus tried to summarize the various proposed goals. Wadler himself has been chronicling others’ reactions to the Links proposal on his blog.

After some discussion of Links sprouted on LtU, Wadler was invited to guest-blog there. He’s only posted once so far, but that post has spawned a new discussion thread of its own. (There was also another Links thread on LtU back in February.)

How to Write Parallel Programs

I tracked down a library copy of How to Write Parallel Programs (out of print, full text online) after seeing Bill de Hóra mention it alongside SICP. It’s not the landmark book that SICP is, but it’s a great read.

I’ve never had a taste for David Gelernter’s nontechnical writings, but his technical stuff is consistently good: not just the above book (written with Nicholas Carriero), but also Programming Linguistics (with Suresh Jagannathan), a quirky and illuminating book about programming languages. Unfortunately the latter is also out of print, and a quick search didn’t turn up an online text. Too bad, because I’m not the only one singing its praises.

CS books like these bend and stretch your brain but remain fun and accessible to read. Too bad there aren’t more of them.

Switching Machines: A Usability Nightmare

I just got back from a trip to Idaho, where I helped my parents switch to a new(er) computer. My parents are smart people, but they aren’t geeks, and I can’t imagine how they could have done this without geek assistance.

Take the simple(?) task of copying files from one machine to another. How would they have done it? Floppies? Nope, too many files are bigger than floppy-size these days, and no non-geek understands things like multi-volume zip files. CDs? Nope, the old machine is too old to have a CD burner. A simple two-machine network? Let’s see what that would involve: installing a network card in the old machine, procuring a crossover Ethernet cable to plug the two machines together, and rigging some simple network settings in each machine’s control panel. That’s what I actually did, and for me it was easy; for them, needless to say, it would have been impossible.

And that’s just one aspect of switching machines. Take another problem I ran into: the new machine would dial up to the net just fine, but then hang up after a couple of minutes. The solution involved the modem initialization string; right there, you’ve lost 95% of folks, not because they’re not smart, but because they aren’t versed in computer arcana, and don’t want to be.

After years of talk about usability, we still manage to make the most basic tasks inaccessible to the normal user. Get a clue, folks: there are a lot more computer users like my parents than there are like us.