A Trifle Absurd

Trifling with PyObjC

Having tinkered with PyObjC enough to start liking it, I decided to try rewriting my Objective-C Trifle prototype in Python. In one hour I had it working. Admittedly, my little prototype didn’t do that much, but I was still impressed. My experience over the last few days has confirmed this: I’m more productive in Python than in Objective-C, even when the Python code I write does almost nothing but call Cocoa APIs.

But if I write Trifle in Python, and Trifle becomes a successful project, I’ll be stuck writing and maintaining Python code for a while. Do I really want that? Python is a relatively nice language, but it’s far from ideal. Part of me wants to push ahead further and program in a Really Nice Language—thus my dalliance with Io.

The trouble is, though, there’s a relative-maturity issue. If I wrote Trifle in Io, I’d have to spend time improving Io’s Objective-C bridge, filling in some of the gaps. If I used Python instead, I wouldn’t need to do any of that, because PyObjC has it covered.

Besides, how do I know that Io would be a Really Nice Language anyway? It seems nice, but I haven’t used it enough to know. And if Trifle winds up with a plugin model, well, there are a lot more Python programmers out there than Io programmers.

Simple Syntax and Popularity

In my last post, I failed to mention that I was talking about my favorite languages. I’m a Lisp lover, a Smalltalk sympathizer, a Scheme supporter. I choose to program in these languages whenever I can. In that respect, I don’t care if they’re popular or not.

I do find it striking, though, that no language with a simple, regular syntax has ever achieved mass popularity. If a simple syntax is a huge win for a language (witness Lisp macros or Smalltalk closures), why haven’t any of these languages taken off?

I answered that question (last post) by waving vaguely in the direction of readability. Several Smalltalkers found that dubious (see the comments and James Robertson’s post), and I suspect they’re right. In any case, readability probably depends more on the programmer writing the code than the language they’re writing in.

I’m still intrigued by the larger issue, though: Why is it that no simple-syntax language has ever become popular?

Must Different Things Look Different?

Consider Lisp, Smalltalk, APL, and Forth (or their offspring such as Scheme, Self, K, and Factor). Each has an extremely simple and regular syntax, and uses that to supply powerful constructs (e.g. macros in Lisp, compiling words in Forth). Each has been around in some form for decades. Each has a small and highly enthusiastic user community. Each has been used to build powerful, useful, and interesting software. But none has ever gone mainstream.

The same simple, regular syntax that gives these languages much of their power is also the number-one turnoff for Average Programmers approaching them. “The syntax is just too weird!”, they say. But is that the real reason? The syntax may be unusual, but it’s not arbitrary, and its simplicity makes it easy to learn. And plenty of languages with arcane and tricky syntax have become popular—take Perl, for instance.

Or take Larry Wall, Perl’s creator, who argues that Lisp’s uniform syntax is a deficiency, because “people like things to be visually distinct…”. In other words, languages like the ones above are confusing because they make different things look the same. (I’d say Perl’s error lies in the other direction: making the same things look different. But that’s beside the present point.)

Of course, the reason these languages make everything look the same is to give the programmer power to decide what should be the same and what should be different, without introducing syntactic cruft. But perhaps Larry Wall has a point: that very power exacts a price, and the price is that a person reading code has to work harder to understand it.

An example: In Scheme, there’s no visual distinction between a function call and a macro call, yet there’s an enormous semantic distinction. That blurring of the lines can be used to great effect in the creation of DSLs; it can also bite back, such as when you don’t realize something is a macro, and try to pass it as a function argument.

So, these languages are often more elegant and concise than their mainstream counterparts, but they also require more mental effort to decode (especially when reading other people’s code). I suspect this is the kernel of truth behind the idea that these languages are only for Smart People. But even Smart People would be better served by a language that didn’t require that extra effort. Is it possible to escape the dichotomy of expressiveness versus readability?

(Update: posted a follow-up.)

PyObjC

Kragen Sitaker reminded me of PyObjC as another Cocoa-friendly way to script. I’d heard good things about it, but hadn’t tried it, so I finally downloaded it and fooled around with it a bit. (For those who haven’t heard of it, PyObjC is the Objective-C bridge for Python.)

PyObjC is an impressively complete bridge: for instance, KVC and KVO work without fuss. You can build an entire app (in deployable-bundle form, no less) in Python, either using provided XCode templates or standalone py2app setup scripts. The only weakness I’ve found is an occasional thinness of documentation, which is counterbalanced by an abundance of example programs.

Python isn’t my favorite language in terms of the language itself, but the Python community consistently shines in delivering libraries and bindings that Just Work. PyObjC looks like another example of that.

Core Data

Since I’m writing a database-ish desktop app, I gave Core Data a spin. It offers persistence and undo almost for free, along with extensive and configurable UI bindings.

If Trifle had a data model of any complexity, Core Data would be a good fit. As it is, though, items and tags are so trivial that it’s just as easy to implement them myself. The manual way opens the door for features that Core Data can’t handle, like autosave. And I still get to use a lot of Cocoa power, such as Cocoa Bindings.

Focus

I’m going to focus on one (and only one) programming project for a while. With my effort spread among several projects, it’s hard to see visible progress, and that’s discouraging. Also, I haven’t had time to spare for other stuff I like to do, like playing music.

I’ll tackle Trifle first, and put Overleaf and the (still nameless) language-design project on the shelf. Trifle was the first of these I started, so I think it should be the first one to get pushed through to usable reality. Plus, it’s probably the easiest of the three projects, at least for now: I’m starting with a dead-simple item-and-tag model, and it should be straightforward to build a little app around it.

Once Trifle has its first public release, I’ll start working on Overleaf again. The language project may simmer a while longer, though I’ll definitely keep my head in the game by reading LtU and such.

Rebooting GTD

I’ve been using a GTD-based system for organizing my time and my stuff, with a few ideas from elsewhere thrown in (like the daily log). It’s worked really well—I’m more organized and productive now than I have been in years—but, like any system, it gets a little rusty over time. So I’m oiling it by rebuilding my lists from scratch, and trying a few new ideas.

On the computer, I’m using TextEdit to keep lists (as simple RTF files). It’s lightweight, fast, and simple, but still has nice extras like hyperlinks between documents (see Format/Text/Link). Long-term, of course, I want to use Trifle for this, but TextEdit has been a surprisingly capable tool.

No doubt the Hipster PDA is too well-known now to be truly hip, but that doesn’t bother me. I loved the idea when I first heard it, but didn’t think I’d have a use for one. Now I’m thinking it might be handy for stuff like my daily log, a calendar, out-and-about errands, and things to tell Elizabeth. We’ll see how it goes.

F-Script vs. Io

I want to whip up a quick prototype of Trifle with a Cocoa GUI, so I need a good interactive scripting language. Unlike in Overleaf’s case, performance doesn’t matter, but the Objective-C bridge does. F-Script and Io stand out as the best bets.

I’ve raved about F-Script before, so I won’t add much except to say that its accompanying tools just keep getting better: now there’s Core Data Explorer, which lets you browse and query Core Data objects at runtime. Unfortunately, you still can’t create new classes, which hobbles F-Script for application development.

Io, on the other hand, is a complete, self-contained language, with a nice syntax and several interesting design features (actor-style concurrency, high-level macros). Not surprisingly, though, its Objective-C integration isn’t as good as F-Script’s: for example, you can’t yet call an Objective-C method that takes a pointer to a pointer. Still, Io is actively maintained and has attracted a community of developers.

Abstracting Linear Values

I mentioned a little while ago how linear values can be a pain to program with. You often have to pass extra arguments around and declare new variables for intermediate values. But what if you could abstract that work away? Toward the end of How to Declare an Imperative (page 23), Philip Wadler shows that you can easily build monads atop linear values.

I’m not a huge fan of monads, but this is an ideal use for them: threading state through behind the scenes. And if you have a use for linear values that isn’t easily expressed in the monadic style, you can just revert to using linear values directly — something you can’t do in a system that has monads baked in at the bottom.

Rewriting Overleaf in Scheme

I’m rewriting (most of) Overleaf in Scheme. I resisted the idea at first, ’cause I didn’t want to have to write a Scheme-to-Cocoa bridge. But then I noticed that my existing (Objective-C) code doesn’t interact with Cocoa much at all, so I could get away with creating a few stub functions in C and calling them via a normal Scheme FFI.

Why switch languages? Objective-C is a frustratingly low-level language; my plans for rearchitecting Overleaf would have involved rewriting a lot of the existing code anyway; and using an interactive language will make testing and debugging far easier.

Why Scheme? It’s higher-level than Objective-C in almost every way; it has several good implementations available; it’s a language I’m likely to use for other projects; and it puts my money where my mouth is regarding the usefulness and advantages for high-level languages for real-world application development. Plus, it’s fun.

The big question mark is performance. I’m hoping to employ the classic strategy of writing everything in Scheme, profiling, and then dropping down to C for the bottlenecks.