Three years after my switch: Programming the Mac

“Actually I made up the term ‘object-oriented’, and I can tell you I did not have C++ in mind.”

– Alan Kay

It’s not three years, yet, but it’s not far away from it either. After a bit more than twenty years with PCs and Microsoft systems, and finally being able to afford a Mac, I went for a ‘fat’ Mac Mini in 2005, a few days after the release of Mac OS X 10.4 Tiger.

Several other Macs, including PowerBooks and an Intel Mac, followed quickly afterwards. And although Apple’s ridiculous secretiveness and their almost disgusting proprietary american attitude are sources of ongoing stomachaches for me, I am now looking at a significant investment in hard- and software for the Apple platform. The truth is that I love beautiful things, and it is hard to find more beautiful computer equipment and gadgets than those from Apple. It’s become a love-hate relationship for me, but so far my sense for beauty has kept me there.

Coming from the Microsoft platform with a background in system administration, system and software development and even in writing technical documentation, I did not just wanted to look at and use a beautiful machine, I also wanted to dive under the surface and program it. So I was looking for a way to write software on the Mac.

In my past, I have used quite a few programming languages and I even have written software commercially in Borland Pascal, PowerBasic, Xbase++ and sometimes even in C, when I absolutely had to.

But on the Mac, despite being championed by Apple, I ruled out Objective-C and Cocoa almost immediately.

The reason is quite simple: I just don’t like C, and that includes its close derivates C++ and Objective-C. These languages don’t work the way my brain works. I also do not want to write operating systems, and C, C++ and Objective-C just feel painfully backwards as application development languages.

The last language that I had learned on the PC was C#, so I tried out the open source .NET implementation Mono. It is great for programming server-side applications, but its GUI libraries are nowhere-near a level where you would want to use them to write Macintosh application that actually would be accepted by a typical Mac-user.

Java was the next alternative I looked at, but on the Apple platform, a few things are quite obvious: Java is a second class citizen at best. Apple is always months behind at delivering a current Java implementation, and Java just feels slow and not really at home on a Mac. Despite their original marketing noise, Apple just does not care for Java.

They now produce the same marketing noise for Python and Ruby, and I leave it to you to decide how trustworthy you find Apple’s promises of making these languages first class citizens on OS X.

Anyway. I took a look at Python, and I am still looking at Python. I have some reservations as to its syntax and naming conventions and the fact that it is not a compiled language. I like compilers and the fact that they check my code for a lot of problems -before- it can run. I also like the fact that compilers ultimately create programs that run much faster than traditional interpreters ever could. I know that Python comes with a ton of optimizations in this regard, but still, it leaves me with a strange feeling in my stomach and I have not yet decided if this is the way that makes me feel comfortable on the long run.

Then I stumbled over a little mutli-platform language called BlitzMax. It has a syntax derived from more advanced BASIC dialects and provides an object-oriented programming paradigm, if wanted. However, it is also possible to entirely stick to procedural programming. It has an own module for GUI development, which uses a Cocoa-backend on the Mac, so it fits in naturally. And BlitzMax was originally designed to write games, so it has some very nice multimedia capabilities and its compiler creates very fast code.

There is a strong and friendly community around the product, and there are great modules available even for more traditional tasks like data recovery programming. And whoever is not comfortable with the MaxGUI module can use the community alternative wxMax, which provides bindings to wxWidgets and a free carbonite offer code.

The biggest downside of BlitzMax is that is does not support multi-threading at this time and that it does not –want– to be a real application development language. Of course, you can do it with BlitzMax anyway. It is just that its creators only want it to be a great tool for game development, that is their only focus.

During my language odyssey, I also found a couple of products that compete in the same arena as BlitzMax. The most famous one being REALbasic, which has a gorgeous Integrated Development Environment and a strong collection of very useful modules and components. However, I just cannot stand the way how REALbasic forces me to deal with my code. You cannot EVER see your entire source code in REALbasic; you have a tree view to your left in which you can select a function, procedure, method or class, and then you only see this one piece of your code. You can also not just type something like “Sub mySub()”, you have to click on “New function”. That completely underwhelmed me and gives me the feeling that the system treats me like a somebody who needs training wheels on his bike, so I do not use REALbasic.

So where does all of that leave me?

My clear favorite is BlitzMax, being the language that just feels most natural to me. Unfortunately, it is not a killer tool for writing applications for the Mac. Its support for Cocoa is only basic, since it focuses mainly on games and added ‘normal’ GUI components only as an afterthought and only as far as it might be useful for games. However, if a beautiful game like “Eschalon: Book I” by Basilisk Games can be written in it, anything else should be possible as well.

Python is my second choice, but it does not attract me half as much as BlitzMax does. Maybe that is because my very first programming language was BASIC, and I’ve always loved it. Maybe no other programming language ever has evolved as much as BASIC did, from its early days as a slow interpreter with only a few commands to being a strongly typed, fully object-oriented compiled language that many of its derivates are today.

For me, the Mac is not as rich a development platform as the Windows NT-based family of operating systems is. Microsoft really supports developers, they provide a multitude of programming languages and tools themselves and they understand that ultimately the developers are the people that carry their platform. Without the strong developer community, Windows would not be where it is today. That is the thing from the Microsoft world that I miss most.

Apple, however, seems to suffer severely from the ‘not invented here’ syndrome, and they leave the impression that third party developers are a necessary evil at best and that in an ideal world Apple would be the only company writing software for the Apple platform. That attitude stinks, but it is not likely to ever go away. Just look at how they closed the iPhone and the iPod Touch for third party developers. If the forthcoming promised SDK does not significantly change this, the iPhone will soon disappear in history as yet another nice design study without any long-term commercial viability. People hate closed platforms, and I am amazed that all those smart people at Apple do not seem to be willing to accept that fact and respond appropriately by opening their stuff. But that is another discussion.

But from this perspective, it can only be a smart thing to use multi-platform development tools when developing for an Apple platform. It guarantees independence from Apple, and both BlitzMax and Python can give me that. In case the folks at Apple want to nail their platform shut, which is what they usually do one way or the other, it won’t hurt that much when some day I might decide to switch away from Apple.