REALBasic comes tantalizingly close to solving a real problem; with a few minor changes, it could become the next great development tool for GUI programming. But it’s not there yet.

Here’s my view on development tools for creating commercial software that needs to run on Windows and/or Mac (i.e., 99% of the desktop). There are some important axioms.

Axiom one. The universe of programming languages is more or less divided into two categories: programming languages with memory management built in (garbage collection, like Java, or reference counting, like Basic), and programming languages that make the programmer do the memory management (C/C++). Programmers are much more productive in languages that do the memory management for them. Over the last two years I spent a lot of time writing GUI code in C++ (using MFC) and a lot of time writing GUI code in Visual Basic. Know what? My time writing Visual Basic was ALWAYS significantly more productive. Other programmers who have used both environments extensively have always agreed with me on this point. Programmers who don’t agree with me have not used both. There are a lot of C++ only programmers who think of Basic as a toy language and disdain it. They think that they are cool coding jocks because they don’t need wimpy languages. Frankly, they are wrong, and I don’t have very much patience for people who get religious about tools and judge things that they haven’t used.

Memory management languages (Basic, Java) tend to be slower. This may not matter in the long run. However, as of now, there are still lots of examples where you can speed up code several thousand fold by writing some tight C++ to replace Basic code. As an example, I once wrote some code in Visual Basic to convert the contents of a rich edit box to HTML. It took about 10 seconds for a page of rich text. When I converted it to C++, I was able to use much lower level messages to the underlying rich edit control, and the speedup was profound: instead of 10 seconds, it took a few milliseconds.

But for most GUI tasks, which operate at “user speed” (most of the time is spent waiting for the next message from the user), there is no benefit to using C++. Given axiom one, my preferred development environment would usually be something like Visual Basic.

Axiom two. Users have expectations for what makes up a “professional looking” application. If you violate these expectations, they will feel like your program is a piece of junk. For example, on the Mac, they expect the menus to be at the top of the screen. And they expect that while they are editing text, the whole screen won’t flash, which means you absolutely have to use double-buffering. They usually expect you to use “native widgets”. When programmers try to reinvent their own widgets (viz. Netscape 6), users will think the program looks clunky. If you use the JDK, and your Windows application uses the Java coffee cup as its icon, users will think that your program is not professional. People are less likely to buy a product that looks unprofessional. I don’t know how many people have told me that they tried various applications which were written in Java and thought that they felt unprofessional. They were slow, they flashed a lot, their widgets behaved slightly wrong. Thus, there is a lot of value in giving software developers absolute control over the exact look and feel.

When you add in axiom two, and the need for speed in certain critical areas, I would modify my statement a bit, and say that my preferred development environment would be Visual Basic, with the ability to drop into C++ to do certain things. VB gives you at least two good ways to do this: through DLLs or through COM objects. COM objects that are also controls even give you the ability to define new user interfaces.

Now let’s talk about platforms. Windows has 90% or 95% of the desktop market. Macintosh has 5% or 10%. If you’re talking about office users, Windows is even more dominant; Macintosh has a bit more of the home users, but probably not even near 15%. What this means is that if you are a software developer, the only thing that makes sense financially is to develop a Windows version first. Then, you need to evaluate the cost of doing a Mac version. If that cost is only 10% more, it’s worth it. If that cost is something like 50% more, it’s not worth it. If I have a product that cost me $1,000,000 to develop, and 10,000 Windows users are using it, that’s $100 per user. Now if I have to make a Mac version, and it’s going to cost me $500,000 to port the Windows version, and the product is going to be just as popular among Mac users as Windows users, then I will have about 1000 Mac users. That means that my port cost me $500 per user.

This is not a good proposition. I’d rather spend the money getting more Windows users, because they’re cheaper.

What does this mean to you, a Mac tools developer? It means that your number one priority is making it possible for Windows developers to port to the Mac for less than 10% of the original cost. The big companies that have products on Mac and Windows (Macromedia, Quark, Adobe, etc) generally started on the Mac. That means that it was worth almost any amount of money to port their product to Windows, because the market was so much larger. The only big exception is Microsoft, which has several different portability layers that allow them to develop one product for both platforms. For products at Microsoft which already have portability layers (Project, Word, Excel), they can do a Mac version for less than 10% extra, so they do it. For other products (Access, FrontPage), the cost of a Mac port would be more than 10%, so they don’t do it.

An interesting point is that today, try as one might, there is just no great way to create a Mac port for less than 10% of the cost of the Windows original. Which is why not much stuff shows up on the Mac anymore, unless it’s strategic in some way (like the Real Media Player).

In my view, the “holy grail” of programming would be an environment which:

• allowed me to develop GUIs in a high productivity GUI environment like Visual Basic
• allowed me to drop into C++ and create COM objects for things which need to be fast or have a very particular look and feel

So far, this environment exists on Windows (VB with VC++), and almost on the Mac (REALBasic with CodeWarrior, although they are not glued together nicely with an architecture like COM Controls).

Now, if you want me to make a Mac port, I need the third thing:

• cost of porting from Windows to Mac is less than 10%.

Just because of the differences in fonts between Mac and Windows, I’m already going to have to lay out every dialog again (and swap the position of all the OK and Cancel buttons) and change words like “Directory” to “Folder”. So that uses up, like, 8%, which means that porting the code itself better be super-duper easy, like, 2% of the effort.

And REALBasic can’t do that today. But it is soooooooooo close, it’s painful. I want to be able to write code in VB on Windows, and have it just work in REALBasic. No complicated one-way conversion scripts, because when I’m coding and porting, I’m coding all day long. There CAN’T BE a conversion step, because if I find a bug in the original version, I can’t start again with the port.

I think that the number one priority for REALBasic would be to make it compile Visual Basic code directly. There are too many cases where REALBasic is gratuitously different from Visual Basic. As a small example, it lacks a SET statement, instead using LET to do SET, which removes the possibility of using default properties.

There are functions which have been in Basic since time immemorial, like LCase, which REALBasic calls “LowerCase” for absolutely no good reason… except to serve as an obstacle to porting to or from VB.

It needs to be able to do COM controls. I need to be able to set up an environment where I can code once for Windows, using VB and COM controls written in VC++, and have that code compile unchanged with REAL and CodeWarrior.

There are some cases where REALBasic includes a “neat” extra feature which somebody thought was cool, like “//” comments. These aren’t bad features, but they need to be turned off by default. That way, I can be sure that if I write my code in REALBasic, it’s going to work in Visual Basic later. Somebody needs to go over VB and REALBasic with a fine tooth comb, find every small difference, and fix them! The amount of work this will take is very small, which is why I said that REALBasic is sooooooooooo close.

There are other useful things besides pure compatibility: tools that take into account the fact that my code needs to run on both platforms. For example, since every dialog will have to be laid out twice, REAL Basic should have a tool that lets me manage two versions of the layout of each form automatically. It should detect when one version has changed and remind me somewhere that I need to change it for the other platform. It should have good #ifdef capability which is 100% compatible with VB. It needs to provide small compatibility libraries, for example, for parsing file paths, that I can use in VB for Windows as well, so that I have a chance of writing portable code.

And the prospective gains are HUGE. Visual Basic is the single best selling programming language in history, by a large margin. If REALBasic can get that cost of porting below 10%, a flood of developers will suddenly discover that porting to the Mac is worthwhile, which will hugely improve the sales of REALBasic. In the long run, it will also be shockingly beneficial to Apple, which has its own chicken and egg problem trying to get software for the Macintosh. If Apple has any sense at all (and they don’t), they would PAY REALBasic to be more VB compatible.