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.

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.

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.

Why I Chose Haskell

I’m trying to build an application to sell, with the highly practical goal of making a living. So why on earth would I pick a wacky academic programming language that hardly anybody uses?

Because I need leverage. I’m developing Trifle on my own, so I need the most powerful tools I can find. Haskell is a very powerful and high-level language: my code works sooner than I expect, and is shorter and simpler than I expect.

Because it fits the situation. Of the various high-level languages I had to choose from, Haskell was the best fit: it has an Objective-C bridge, an active user community, and decent performance.

Because I can. At a regular programming job, the language choice would be a given, handed down from on high (like many other choices). One of the biggest benefits of working independently is getting to make my own decisions. I think Haskell is the right choice, so I’m going to use it. Where else would I get that opportunity?

Choosing A Language, Again

Making Trifle a commercial app gives me another language dilemma, the four contenders being Objective-C, Python, Scheme, and Haskell.

Objective-C just doesn’t cut it: it lacks type safety, garbage collection, and a REPL. There are ways to mitigate those problems, but ultimately, I want a higher-level language.

Python is out of the picture—I can’t hardly develop a closed-source app if I have to ship the source to run the app. (It might be possible to ship just bytecode, but that’s still a rather mild form of obfuscation.) Besides, try as I might, I just can’t muster much enthusiasm for long-term coding in Python.

Scheme is more promising: I’d have several compilers and interpreters to choose from, I could use real macros, and I might even be able to re-export it as a scripting language for Trifle users. But I’d have to build my own Objective-C bridge.

Haskell, to my surprise, is the winner: it has an existing Objective-C bridge, and would likely run faster than most Schemes. On top of that, it’s one of my favorite languages; I’m eager to build a real application in it.

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.

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.