Mac Text Editors

One of the most baffling gaps in Mac third-party software is programming-oriented text editors with autocomplete. Now, obviously there’s XCode, vim, and emacs (which, being free, are all something of a problem for would-be competitors), and a bunch of cross-platform tools like Eclipse and Komodo, but XCode is really oriented towards Cocoa development and is kind of like using Microsoft Word to edit a shopping list, while the others are all non-Mac-like (and kind of suck anyway).

The Mac heavyweight text-editing champs — BBEdit and TextMate — have many great features, but don’t do autocompletion very well or at all, respectively. (There’s some kind of third-party hack add on for TextMate, but you need to compile it yourself and few seem to be able to get it working.) A lot of Unity developers were using PCs or Virtual Windows boxes to run Visual Studio just because it has an autocompleting text editor that doesn’t suck — that’s how bad it was. (Now that Unity runs on Windows their lives have gotten much easier, which is a pretty sad statement.)

Before you scream at me about how, say, Subethaedit has some kind of autocomplete support, or mention Coda (which has OK autocomplete support) or Espresso (which may one day have halfway decent extensible autocomplete support but right now is a work-in-progress), go and try Visual Studio or, if you’re allergic to Windows how about Realbasic. Realbasic‘s built-in text editor has autocomplete that doesn’t suck, e.g. it recognizes context, knows about intrinsic language constructs as well as library functions and the stuff you’ve declared, and doesn’t incorrectly complete stuff you need to fix constantly or fail to offer “function” when I type in “fun” in a .js file.

I will say this: TextMate’s macro facility is truly awesome (you can type swi->TAB and get a switch statement template, and then tab through the bits you need to change, almost like a context-sensitive-in-place-dialog-box), if this were paired with a proper autocomplete system (like RealBasic’s) it would be the best I’ve seen and then some — maybe 2.0 will have this — but right now the situation on the Mac remains pretty dismal.

Realbasic Alternatives

So, you want to develop apps quickly and easily but you are sick of Realbasic’s subscription model, or are annoyed by the forced switch to “Studio”. What to do? The latest news from Real Software has me thinking (again) about what I should do rather than continue to use Realbasic, and here are the alternatives I’ve come up with.

XCode — Free (Mac). On the downside, you can’t deploy on Windows (or Linux, if you care). On the upside, actually supports all Mac UI widgets properly, has far fewer stupid bugs, can actually load images with alpha channels, produces apps which you don’t need to be ashamed were created with Realbasic, allows you to deploy on the iPhone, and actually has pretty good tools for building web apps.

Cocotron looks to offer the Holy Grail of cross-platform development. Develop your apps in XCode and Cocoa and simply compile to Windows. I haven’t tried it yet, but it certainly seems intriguing and it appears to be under pretty active development.

Unity — $199 and up (Mac/Win as of 2.5, also iPhone/Wii). On the downside, doesn’t produce standard desktop apps. On the upside, very good for game and multimedia development (far better than Realbasic); generally superior performance to Realbasic; your programs can run in web browsers, the iPhone, and even the Wii; one license allows you to code on both Mac and Windows; actually has a superior GUI for OO development than Realbasic (once you get your head around it); supports three languages (Boo, C#, and JavaScript), each of which is an easy move for RB coders; no subscription model.

BlitzMax — $80 (Mac/Win/Linux). Very fast, modern BASIC with full cross-platform GUI support (available as a $30 add-on). Designed with 2D game development in mind, but perfectly capable of being used for app development. Downside: bare-bones IDE which does not include visual GUI tools or handle bindings between UI elements, events, properties, and code. Visual GUI tools (which do do these things) are available from third parties.

Python — Free (Mac/Win/Linux). Python is not only a ridiculously nice language, it’s also hip and cool and highly marketable. It’s kind of like JavaScript without the negative associations (but also without the ability to run in Web browsers). For GUI development, Tkinter looks interesting and PythonCard actually seems pretty compelling.

Java — Mostly Free (Mac/Win/Linux). Well, Eclipse is pretty nice, and I assume that by now it’s probably possible to produce vaguely decent UIs. I’ll need to look into this. Java is definitely not my favorite language, but it’s very marketable.

Netbeans — Free (Mac/Win/Linux). Free and open source IDE and runtime that lets you code in Java, JavaScript, Ruby, PHP, C/C++, and (shortly) Python. OK that sounds too good to be true. (I downloaded 6.5 and messed with it a bit. It falls under the category “I guess it probably seems pretty neat if you think Solaris is pleasant to use”, so — yeah — too good to be true.)

Web-based — Mostly Free, and some amazingly good, cheap stuff (e.g. Coda). On the downside, you can’t deploy standalone desktop apps via the web. Oh wait, you can. And you are living with whatever functionality you get from browsers (i.e. JavaScript, canvas, Flash, etc.). On the upside, web apps are where the action is. And there’s always Cappuccino and Atlas.

Adobe AIR — Free? (Mac/Win/Linux). Essentially a runtime that bundles Webkit, Flash, and other functionality, allowing you to build web apps that run like applications (including being able to avoid the usual sandbox restrictions). Of course, you’re essentially trapped inside the functionality provided by Webkit (and Flash, if you choose to use it).

Flex Builder Standard 3 — $249 (Mac/Win). On the downside, produces non-standard (Flash-like) UIs. On the upside, your software runs inside browsers (OK, not on iPhones, but neither does Realbasic); you don’t pay a subscription, and Adobe will provide free bug-fixes even for outdated versions of its software. Also, Flash-like UIs are all the rage anyway, and at least you’ll have a consistent user experience on all platforms. Oh, and ActionScript 3 is not going to be hard to learn for Realbasic developers.

Runtime Revolution — $49/$249/$499 (Mac/Win/Linux). On the downside, produces non-standard (sometimes ugly) UIs, and the language is a bit outmoded (although nice in many ways). On the upside, there’s no subscription model.

Qt SDK — Free or Expensive (Mac/Win/Linux). Built on top of the well-known Qt UI library. On the down side, requires you to code in C++. On the upside, produces robust, cross-platform apps. Builds skills that get you better paid jobs than RB experience. The free version is only useful for producing free apps, but that’s a lot of what I do with Realbasic. Correction: the free Qt version can be used for proprietary apps. (And frankly, no-one cares if you open-source a RB Project.)

Lazarus — Free (Mac/Win/Linux). Very interesting looking open source recreation of Delphi. If it works it could be fabulous — I love Object Pascal (although it’s hardly a popular language these days). It appears to let you compile both native Cocoa and X11 apps on OS X.

It’s worth noting that it’s not easy to replace Realbasic for cross-platform development. I can whip up a cross-platform utility with a native UI in Realbasic with almost ridiculous ease, and that’s simply not true for any of these options.

I’ll probably end up keeping an active Realbasic license for as long as I make money from contract programming with it. But, I’ll be moving all the projects I can move, along with any new projects, away from Realbasic ASAP. RiddleMeThis, for example, may well be rewritten using web technology, with desktop deployment via Adobe AIR or something similar.

Other Useful Links

Wikipedia’s compilation of RAD tools

Microsoft’s “Express” (i.e. free) development tools

Unity 2.0

Unity 2 has been out for a month or so now, and I’ve gotten my head around most of the additions (everything except multiplayer, basically). It’s a bit of a mixed bag (I’ll probably write a more thorough review for MacApper) but the nutshell version is this:

The new UI support is at once great (in that it lets you do all the stuff you really need to do fairly easily) and disappointing (in that the architecture is pretty much a horrible kludge). In essence the UI code is all stateless procedural drawing code versus a library of widgets. There’s no proper event support, widgets don’t have an independent existence or retain state. (E.g. you can’t ask a button if the mouse is currently over it.)

The new UI code works, is pretty, and is fairly easy to use, but it’s kind of architecturally lame and the code to support a UI is unnecessarily complex and high maintenance, or you need to write your own state-ful abstraction layer. By comparison, Director offered two UI options — a clunky looking, incomplete, but otherwise functional set of widgets for basic interaction which could be dragged onto the timeline, and a platform-native plugin that let you build “proper” windows with standard controls, but which was completely un-integrated with the rest of your app.

So, on the good side, the new UI code works, looks good, and is integrated fairly well with everything else (cosmetically) … i.e. your UI widgets don’t look 10 years out of date or live in their own Window. On the bad side, writing UI code is unnecessarily tedious and you’ll end up reinventing all kinds of wheels… But it does seem like you could write a bunch of wrapper code for all this that could make it not suck (whereas there was simply no way to fix Director’s UI issues).

Enough on that topic.

The terrain engine is similarly great (the terrain drawing tools are simply awesome, the results look fabulous, and it’s all very easy to use) and incomplete (terrain doesn’t work with blob shadows, the terrain shader is kind of limited, and the lightmapper won’t take into account trees or other geometry in the scene, so while your terrain can cast shadows onto itself, it can’t receive shadows from objects, such as buildings, placed on it.

Several notable deficiencies in Unity remain: undo is still unreliable at best; UnityScript is still not JavaScript (which would be OK if the differences from JavaScript were properly documented, but they’re not); and there’s still no set-breakpoint-and-step-style debugger.

Note: Unity 2.1 addresses all the concerns discussed here except for the architecture of the UI system.

Creating an Application in Five Minutes

It used to be really hard to build a new application. If you find a copy of the original Inside Macintosh there’s a “roadmap” application which is, in essence, the sketch of a minimal Mac app (actually, it’s not even that, because it doesn’t implement multiple windows, or a bunch of other things). This simple text editor program occupies four large pages of commented source code, and figuring out what it all means will involve many trips through the first three volumes of Inside Macintosh.

Writing applications for the Amiga and Windows wasn’t much (any?) easier. Note that I say “writing applications” and not “programs”. Writing computer programs had been really easy up until then…

E.g. almost everyone who had used a computer knew you could do something like:

> 10 PRINT "HELLO"> 20 GOTO 10> RUN

on a computer in a department store and the screen would fill with “HELLO”s and the computer would kind of lock up until a salesperson unplugged it or (and this would be astonishing when it happened) typed CTRL-C.

It was even pretty easy to write a program for a mainframe computer. Something like:

include void main (){ printf("hello"); }

could actually be turned into a reusable executable fairly easily. (You also needed to type some arcana to compile it.) Shell scripts were even easier.

But it took a long time for graphical user interfaces to actually simplify the task of programming, and there were many missteps and dead ends along the way.

Probably the first truly easy-to-use GUI programming tool was HyperCard. HyperCard was so easy to use and so good at what it tried to be (and so oddly implemented) that it has never really been bettered. Even the various attempts to clone HyperCard (notably Toolbook, SuperCard, Runtime Revolution) ever succeeded in making a completely live development tool (i.e. where using your program and developing your program were seamless acts). Indeed, I would suggest that a web-based HyperCard clone is a true killer app.

Various less ambitious but more conventionally useful imitations of HyperCard, notably Visual Basic and Delphi, appeared, as did class libraries which allowed you to subclass a bare-bones application and its components, such as MacApp, PowerPlant, and MFC. Today, most of our development tools are spiritually derived from Visual Basic and its brethren, i.e. HyperCard with a sharp line between “development” and “use”, or MacApp and its brethren, i.e. a class library which assumes you’ll be writing a “totally general” app, where “totally general” means “something a lot like a common office app”. Some of our development tools are more primitive than either, but let’s not discuss Perl, PHP, et al here 😉

What all this means is that you can write “hello, world” using a GUI-based IDE in about fifteen seconds, except that it takes 15s to launch your development environment, and about 30s to five minutes to compile and run it. Versus getting the same thing done instantly in UNIX or on a Commodore 64 twenty-something years ago.

I’ve recently started using a new Mac-based game development tool called Unity and it’s interesting … amazing even … to realise that in many ways it’s closer to HyperCard than Visual Basic. You do need to explicitly save changes (probably not a bad thing). You can create a 3d game application (well, you know, the gaming equivalent of “hello, world”) in about thirty seconds. There is no sharp line between playing and development. It still takes fifteen seconds to launch the IDE and 30s to compile, but…

Game development just got a little more interesting.