Desktop Development with Java

In my ongoing quest to find a long-term replacement for RealBasic (and preferably as many other random development tools and languages as possible) I’ve been investigating Python + wxPython (which seems to work pretty well but produces remarkably large, sluggish applications), Java + SWING (which, as you might expect of anything developed by Sun and built on top of AWT produces sluggish, ugly apps — on the Mac at any rate), and Java + SWT + JFace (which actually seems like it might not suck, but for which precious little documentation seems to be available outside of an insanely expensive — and somewhat outdated — book).

One of the big downsides of anything involving Eclipse is that there seems to be an “easy 35 step installation process”. WTF? It’s like Lotus Notes all over again. Aside from that, Eclipse is a remarkably fine piece of software, and since it’s built on top of SWT, indeed SWT’s raison d’être, this seems to me to give it front-runner status. Indeed, given Netbeans as an exemplar of SWING development, this is one more reason to avoid SWING like the plague.)

Eclipse’s features make Java’s horribleness tolerable… indeed almost not horrible at all. Hover over a classname and there’s its documentation (in useful form). Declare an object of a class you haven’t imported and it will offer to insert the appropriate line of code for you.  Seriously good autocomplete. Seriously good compiler feedback (errors are flagged inline like spelling mistakes in a word-processor). You still need to look at the resulting code, but really not bad at all. For all of Python’s virtues, it cannot offer anything like that kind of programming experience right now.

Tabs vs. Spaces

I found this article after googling “tabs vs spaces” — and I did that because I was reading an amusing (and apparently very old) treatise on How to Write Unmaintainable Code which seems mostly to be a litany of defects in C, C++, and Java as programming languages. Using tabs instead of spaces is listed as a way of writing unmaintainable code.


I use tabs for indenting, and have never really seen any reason not to. At my last job, there was a rather stern rule to use spaces, only, for indentation, and most of the code was indented by two space increments (I prefer four). I read Jamie Zawinski’s post in an effort to understand where the “anti-tab” folks were coming from.

I just care that two people editing the same file use the same interpretations, and that it’s possible to look at a file and know what interpretation of the TAB character was used, because otherwise it’s just impossible to read.

–Jamie Zawinski

Actually, I don’t really understand his position at all. Having said this, he then goes into technical minutiae about how to get emacs to automatically replace tabs with spaces when you save or somesuch.

Here’s my view. I like to indent stuff fairly clearly (as I said earlier — four spaces). I like to avoid typing more than necessary, and I particularly hate having to precisely type four spaces. I even more particularly hate having to backspace over four spaces. Now, sometimes when I paste code from somewhere else into my own code it will be indented somewhat randomly (e.g. if the person was using spaces for indentation and preferred two or eight space indents). In this case, depending on how fussy I’m feeling, I’ll convert the spaces to tabs or just get it roughly right (so its base indentation level is correct) and leave it alone.

Now there’s a simple test you can apply to either side of a question. What if everyone did things your way? Well, if everyone used tabs then everyone would see code indented just as they liked, code files would be smaller, and removing or adding a level of indentation would always require just one keystroke.

There are cases where tabs may cause misalignment, e.g. one post on the subject showed if you’re breaking out a function’s parameters because it has a lot of them, and you want to line up the second parameter with the first, then using tabs may ruin your alignment (but so does everything else), therefore use spaces — but this problem can be solved by using a less idiotic indentation scheme (indent all the parameters one level further than the function). Any problems caused by inconsistent tab preferences are just as true of spaces when using variable width fonts, which is quite common these days (oddly enough).

Here’s the (simplified) example:

    foo( int i,
         int j

This (potentially) breaks if indented with tabs (or a mixture of tabs and spaces, but no-one is advocating that) and editors with different preferences are used). (It breaks in lots of other situations too, which is why I’d write it this way:

        int i,
        int j

or if you’re one of those people:

        int i,
        int j

(I prefer the first option — but I don’t think the second option is stupid.)

The problems all seem to result from mixing spaces and tabs, which can be solved just as easily by converting leading spaces into tabs when you save as the reverse, and has all the other advantages listed.

I really don’t care that much — in my previous job I cheerfully adhered to the spaces not tabs rule. But I still thought it was stupid.

I have a feeling that the roots of this war lie in the whole emacs, vim, pico thing. Basically tabs are a pain in the butt for users of emacs and vim so they’re convinced it’s tabs and not their idiotic text editors that are the problem.

Post Script

One possible reason for such vehement preferences that just occurred to me is that many popular version control systems aren’t smart enough to ignore whitespace, so if Jill uses tabs and Joe uses spaces a whole bunch of badness will ensue. (Again, in my previous job there was similar angst over Mac classic vs. Windows / DOS vs. Unix / Mac OS X newline standards.) But this doesn’t mean one side is right and the other is wrong, just that for a given situation it may be a good idea to pick one or the other and stick with it.

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.

Software Abstraction Layers

I’m not doing much more than linking two interesting articles I read today. First I read this short piece on 10 Useful Techniques To Improve Your User Interface Designs (I liked this even though it was mainly typographic advice and really more about web pages than apps) and then this very interesting blog entry on Objective-J and Leaky Abstractions.

I’ve always been a bit leery of plugins and toolbox calls from within a given scripting environment. I would go to great lengths in tools as diverse as Authorware, Director, Visual Basic, HyperCard, and RealBasic to build stuff purely using the built-in functions rather than use a “simple” plugin or API call (Visual Basic and RealBasic both let you call the OS toolbox directly with a little extra work). I’ve never really understood why I’m like this, but I think it’s for much the same reason I always preferred Algebra to Calculus or Analysis. I don’t like hairy, open-ended problems. I like working within a well-defined space and treating its boundaries, even when those boundaries are porous, as being absolute.

Anyway, the second article essentially obviates the first article. The point of Cappucino (the class library for which Objective-J was initially developed) is to abstract out annoyances like using CSS to correctly place captions inside buttons or make your text fields look right on different browsers. This is how it should be. I like working in a Walled Garden, but only if the Walled Garden is beautiful. I want my buttons to look good, but I want them to be produced automatically.

Oddly enough, this little insight helps explain my tastes in all kinds of things, from software development tools (I can’t stand Runtime Revolution because it produces ugly user interfaces) to operating systems to programming languages to fields of Mathematics.

Anyway, it’s nice to know that there’s a way to suppress OS X’s text field focus hilite using CSS ( input:focus { outline: none } ). I’ll bear that in mind. And it’s also nice to know that if I learn to build web apps in Cappucino using Objective-J I won’t have to worry about that kind of stupidity ever again.

The Best Programming Language Ever?

I was having a conversation at work today about what people’s tastes in programming languages were and there was some discussion about human readability, which led me to mention HyperTalk. HyperTalk was the programming language used by HyperCard, it had the virtue of being incredibly readable and (unlike the similarly readable AppleScript) also very easy to write. I mentioned that “whenever you see — used to denote a comment, there lies the ghost of HyperTalk” to which someone replied, “like in HTML?”.

An HTML comment is denoted by “<!–” and “–>” (note that WordPress is screwing this up, I really do know what HTML comments look like) which seems like a non-coincidence. Tim Berners Lee invented HTTP and HTML using NeXT computers, which didn’t run HyperCard, but which were spiritually related to the Mac, and it’s hard to imagine that HyperCard wasn’t a major influence on the design of the web.

HyperCard has the distinction of being one of the most influential programs ever written, perhaps the most. (Bill Atkinson wrote HyperCard and MacPaint, two of the most influential programs ever written. Photoshop is, essentially, MacPaint running on modern hardware.) Paul Allen spent a fortune cloning it (Toolbook) and it was clearly a huge influence on Visual Basic. Director’s Lingo started out as a straight clone of HyperTalk. Even 3D Studio Max’s MaxScript bears its mark. If we assume that the web was directly inspired by HyperCard — a not unreasonable assumption — that makes it perhaps the most influential  program ever written.

HyperCard was amazingly nice to code in. HyperCard 2 had a modern debugger, there was a third party compiler (written in HyperTalk that could compile to assembler), and it virtually never crashed. By default, all state was preserved (in fact, if you wanted to write a conventional application you had to jump through hoops to create “empty” documents). The main failing of HyperTalk was its lack of support for OO and functional programming (it was internally an object-oriented message-passing architecture, but you couldn’t build your own objects). It would be pretty simple to bolt that kind of functionality onto it, but no-one has, and HyperTalk has largely passed into obscurity.

Surprisingly, there are three modern HyperCard clones still being maintained. Toolbook has focused on authoring CBT, while Runtime Revolution tries to be all things to all people, and SuperCard is Mac only. Unfortunately, all seem pretty clunky by today’s standards. (And, frankly, for all its virtues, HyperCard was a bit clunky even when it was new. It never allowed you to build proper user interfaces.)

It would be interesting to see HyperTalk updated to support modern language features OR something like HyperCard built on top of a modern language like Python or Ruby. The obvious thing to do would be to build a web-based IDE on top of Django or Rails.