HyperCard, Visual Basic, Real Basic, and Me

When the Mac first appeared it was a revelation. A computer with a powerful, consistent user-interface (with undo!) that allowed users to figure out most programs without ever reading a manual.

I can remember back in 1984 sitting outside the Hayden-Allen Tank (a cylindrical lecture theater on the ANU campus that tended to house the largest humanities classes and many featured speakers) playing with a Mac on display while Apple reps inside introduced the Mac to a packed house. (My friends and I figured we’d rather spend time with the computer than watch a pitch.)

How did undo work? It wasn’t immediately obvious.

When we quit an application or closed a document, how did the program know we had unsaved changes? We checked, if the document had no changes, or the changes were saved, the computer knew.

We were hardcore math and CS geeks but computers had never, in our experience, done these kinds of things before so it took us a while to reverse-engineer what was going on. It was very, fucking, impressive.

But it was also really hard to do with the tools of the time. Initially, you couldn’t write real Mac software on a Mac. At best, there was MacPascal, which couldn’t use the toolbox and couldn’t build standalone applications, and QuickBasic, which provided no GUI for creating a GUI, and produced really clunky results.

To write Mac programs you needed a Lisa, later a Mac XL (same hardware, different software). It took over a year for the Mac SDK to appear (via pirate copies), and it was an assembler that spanned multiple disks. Eventually we got Consulair-C and Inside Macintosh but, to give you an idea, the equivalent of “hello world” was a couple of pages of C or Pascal most of which was incomprehensible boilerplate. The entire toolbox relied heavily on function pointers, really an assembly-language concept, and in some cases programmers had to manually save register state.

No-one’s to blame for this — Xerox provided much cleaner APIs for its much more mature (but less capable) GUI and far better tooling — the cost was a computer that ran dog slow, no-one could afford, and which actually was functionally far inferior to the Mac.

The first really good tool for creating GUI programs was HyperCard. I can remember being dragged away from a computer lab at ADFA (where a friend was teaching a course on C) which had been stocked with new Mac SEs running HyperCard.

For all its many flaws and limitations, HyperCard was easy to use, fast, stable, and forgiving (it was almost impossible to lose your work or data, and it rarely crashed in an era when everything crashed all the time). Its programming language introduced a yet-to-be-equalled combination of being easy to read, easy to write, and easy to debug (AppleScript, which followed it, was horribly inferior). When HyperCard 2 brought a really good debugger (but sadly no color) and a plugin architecture, things looked pretty good. But then, as Apple was wont to do in those days, Apple’s attention wandered and HyperCard languished. (Paul Allen’s clone of HyperCard, Toolbook for Windows, was superb but it was a Windows product so I didn’t care.)

Eventually I found myself being forced to learn Visual Basic 3, which, despite its many flaws, was also revolutionary in that it took HyperCard’s ease of use and added the ability to create native look and feel (and native APIs if you knew what you were doing, which I did not). With Visual Basic 3 you could essentially do anything any Windows application could do, only slower. (HyperCard was notably faster than VB, despite both being interpreted languages, owing to early work on JIT compilers.)

After using VB for a year or two, I told my good friend (and a great programmer) Andrew Barry that what the Mac really needed was its own VB. The result was Realbasic (now Xojo) of which I was the first user (and for a long time I ran a website, realgurus.com, that provided the best source of support for Realbasic programmers). Realbasic was far more than a VB for the Mac since it was truly and deeply Object-Oriented and also cross-platform. I could turn an idea into a desktop application with native look and feel (on the Mac at least) in an evening.

When MP3 players started proliferating on Windows, I wrote an MP3 player called QuickMP3 in a couple of hours after a dinner conversation about the lousy state of MP3 players on the Mac. By the next morning I had a product with a website on the market (I distributed it as shareware; registration was $5 through Kagi — RIP — which was the lowest price that made sense at the time, I think Kagi took about $1.50 of each sale, and I had to deal with occasional cash and checks in random currencies).

Over the years, I wrote dozens of useful programs using Realbasic, and a few commercially successful ones (e.g. Media Mover 3,  and RiddleMeThis) and an in-house tool that made hundreds of thousands of dollars (over the course of several years) with a few days’ effort.

Today, I find Xojo (which Realbasic rebranded itself to) to have become bloated, unstable, and expensive, and Xojo has never captured native look and feel in the post-Carbon world on the Mac, and anything that looks OK on Windows looks like crap on the Mac and vice versa, which undercuts its benefits as a cross-platform application. Also, my career has made me an expert on Javascript and web development.

So my weapon of choice these days for desktop development became nwjs and Electron. While web-apps don’t have desktop look and feel (even if you go to extremes with frameworks like Sproutcore or Cappuccino), neither do many desktop apps (including most of Microsoft’s built-in apps in Windows 10). Many successful commercial apps either are web apps (e.g. Slack) or might as well be (e.g. Lightroom).

I mention all of this right now because it closes the loop with my work on bindinator — anything that makes web application development faster and better thus helps desktop application development. I think it also clarifies my design goals with bindinator: I feel that in many ways ease of development peaked with Realbasic, and bindinator is an attempt to recreate that ease of development while adding wrinkles such as automatic binding and literate programming that make life easier and better.

node-webkit

C3D Buddy 2.0 in action — built in an evening using node-webkit
C3D Buddy 2.0 in action — built in an evening using node-webkit

I don’t do very much desktop software development these days, and I’ve become increasingly frustrated with Realbasic (now Xojo), so the prospect of forking out $500 for an upgrade that may or may not be usable did not fill me with glee. Furthermore, as the years roll on, there’s more and more functionality tied to the web that desktop-centric development tools struggle to work with.

I was dimly interested in a thread on Hacker News this morning concerning a workflow for developing desktop applications with node. Turns out that the workflow was mostly to do with things like angular and jade, which I’m not especially keen on, and not so much with the actual desktop stuff — the heavy lifting for which is all done by node-webkit. So I started looking into node-webkit.

I like a tool which has you up-and-running in about three paragraphs.

It goes something like this:

Download an appropriate node-webkit binary. (Disappointingly, the Mac version is restricted to 32-bit.)

  • Write an index.html file. (The sample “hello world” app calls node inline.)
  • Write a package.json file. (The documentation suggests it’s like a “manifest” file, but really it’s more like a configuration file.)
  • Zip this stuff into a file into an archive whose name ends in .nw.
  • Double-click the archive.
  • Voila, your app works.

After working on this for about fifteen minutes, I knocked up a bash script (which I turned into a .command file, allowing me to double-click it in Finder) which does the archiving and then launches the file in one step. (It does leave dead terminal windows lying around, and it doesn’t quit the app if it’s still running. I think I may build an app for building apps if I do much more of this.)

And to build a distributable application you can simply put the archive in the application bundle (on the Mac) renaming it “app.nw” or name the file package.nw and put it in the same directory as the application (for those benighted platforms that don’t have bundles). One minor annoyance is that it’s not clear exactly what needs to be changed in the Info.plist file to fully customize your application.

So what is node-webkit? It’s essentially a version of Chromium that puts node.js alongside the DOM in your web pages, along with a few custom HTML and DOM extensions that let you do things like handle platform-native file requesters).

I should note that it’s a potential security nightmare as it stands. There’s no sandboxing (that’s kind of the point), so deploying an app that loads your banking website and then watches you press keys is totally doable. That said, it’s a desktop app so it can also delete all your files or encrypt them and hold them hostage.

Anyway, I had a lot of fun this evening rewriting a utility application I originally wrote in Realbasic a few years ago. It probably took me about twice as long to write it as it took me to do it in Realbasic. Part of that is I know (or knew) Realbasic very well, and I don’t know node very well. Another part of it is that Realbasic is almost always synchronous while node is almost always asynchronous. Writing code that spelunks a directory tree asynchronously is a lot more complex both conceptually and in practice than doing so in linear fashion, but the payoff is quite impressive — despite running an “interpreted” language, a task that took significant time in Realbasic (loading and displaying hundreds of thumbnails) happens in the blink of an eye.

One of the things that’s especially intriguing about node-webkit is that it gives you control over the browser you normally don’t have (e.g. window placement, file system access) — these are a constant usability sore-point in the project I am currently working on (which is a web app that is replacing a suite of desktop apps). It would be so much easier to get a lot of the things we want to do working smoothly using a hybrid desktop application built on top of something like node-webkit — it’s kind of a lemma of Alan Kay’s observation that anyone who wants to write really good software needs to build hardware — anyone who wants to write really good web apps really needs to build the browser.

The github repo for my project is here. It’s not a very general-purpose application; if you don’t use Cheetah 3D it’s completely useless.

Realbasic and Visual Basic

More than anyone except Andrew Barry, I am responsible for the creation of Realbasic. (This doesn’t reflect particularly well on me, it just means that Andrew pays, or paid, more attention to my whining than most random people.)

In the mid-90s, Andrew and I had both been involved in software development across multiple platforms for some years, and both of us were annoyed by glaring flaws in most development tools. I had gone to work for Andersen Consulting and been forced to develop a very ambitious multimedia project using Visual Basic 3, a development tool I found both admirable and horrible in pretty much equal parts. It was obviously inspired by HyperCard, but good in ways that HyperCard was bad (it created native UIs) and bad in way that HyperCard was good (it was horribly unstable, the language reeked).

Andrew and I would often shoot the breeze about dev tools and at some point I opined that what the Mac really needed was something like Visual Basic that didn’t suck. So Andrew created CrossBasic which became RealBasic. Anyone even casually acquainted with the two products will know that Realbasic owes more, architecturally, to MacApp and Java than Visual Basic. E.g. from the beginning there were “folderitems” which strongly resemble the object wrappers Apple’s frameworks use for filesystem objects. Similarly, all visible controls are subclasses of Canvas, which is the base graphical class in Java. Indeed, CrossBasic originally allowed you to compile programs to the JVM. Worst of all, in Visual Basic prior to .NET you essentially use simple variable types except when doing file i/o. In Realbasic you define your own classes and subclasses (including being able to subclass internal classes seamlessly). All of this was part of Realbasic 1.0.

Why bring this up now?

Well, it’s a long time down the road. Andrew left Real software after finishing Realbasic 2 (I think it was 2.1.2 at the time, which was for a long time the “golden” version of Realbasic). A few months ago, I answered a question of Stackoverflow about “which languages supported nice language feature X” and mused in my response that not only did Realbasic support it but that it supported many, many nice language features you don’t expect in a “BASIC”. I then got critical feedback based on Realbasic’s having started life as a “clone” of Visual Basic.

So I’m setting the record straight. Realbasic was never a “clone” of Visual Basic. It wasn’t an inferior copy, but a superior re-imagining. Just as Visual Basic stole ideas liberally from HyperCard while being dramatically superior in many ways, Realbasic stole ideas liberally from Visual Basic while being dramatically superior in almost every way. (E.g. it never put developers through DLL hell, even under Windows.)

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

Realbasic Attempts Suicide

Greetings,

I’m writing to let you know about some important changes we are making to REALbasic.

On April 14th, we will introduce REALbasic 2009 Release 2. At that time, we will be reducing the price of REALbasic Professional Edition to $300, a 40% reduction from its current price of $500. We will also be reducing the renewal price from $250 to $150. That means when you renew in the future you will be saving 40%!

Wow. Sounds pretty good. Maybe a smart move in a recession, and perhaps they’ll gain more customers (moving up from the $100 “standard” version to the $300 “pro” version).

We have been talking to a lot of Personal Edition users, as well as people evaluating REALbasic, and we have been researching software pricing.  We have determined that $300 is a more appropriate price for REALbasic Professional Edition. It will likely mean that more people will purchase the Professional Edition which helps to grow the REALbasic community.

Another reason we are doing this is to make it easier to provide REALbasic editions for each of the three major types of users: hobbyists, part-time developers and full-time developers. The Personal Edition is designed for hobbyists and students, and the Professional Edition is for part-time developers. For full-time developers, we will be introducing REAL Studio.

REAL Studio, which will be introduced with REALbasic 2009 Release 2 on April 14th, will provide features that full-time developers need:
-A license key that can be installed on any number of computers or operating systems to make development and testing easier
-The Profiler for optimizing code performance*
-IDE Scripting for build automation*
-Remote Debugging*
-A REAL Server unlimited connections license
-Priority technical support
-New licenses will come with 12 months of updates, rather than 6 months

Wait a second. The asterisks mark features I already get now, all of which are pretty useful. (note that there are four, not three, items)

Three of these features were previously in the Professional Edition. Along with the price drop for the Professional Edition, we are moving these features to the Studio Edition. REAL Studio will be priced at $1495 with renewals priced at $749. However, we are offering all Professional Edition users a free upgrade to REAL Studio. And you can renew your license for up to two years at the current renewal rate of $250. But you must do this BEFORE you upgrade your license to REAL Studio.

So, basically, I can get a “free” upgrade to Studio if I want to continue getting remote debugging and profiling (among other things) which I already paid for — but when my subscription comes up for renewal it will be tripled in cost, or I can watch my existing license be gutted and the worthwhile parts of it moved to “Studio”.

Well this seems like a strong incentive to abandon Realbasic as quickly as possible.

Post Script

Apparently there were howls of protest about Real removing remote debugging from Realbasic Professional, so it’s going back in. This leaves IDE automation and Profiling as features that existing Pro customers will lose if they do not take the “free” upgrade. (Why do I put “free” in quotation marks? Because you’ll end up being stuck paying 3x (or 5x) as much for future upgrades.)