haXe + Xcode

Note: I added a haXe Xcode project template to the haxeXcode.zip pacakge (5/5/2006)

It turns out that, with a bit of effort, you can turn Xcode into a solid haXe IDE.

First, Xcode can provide excellent code highlighting and auto completion for haXe. To enable them, you have to install haXe language support files. You don't need to go through the trouble of creating such files yourself -- go ahead and download the ones I created: haxeXcode.zip.

To install haXe language support, unzip the package, put haxe.pbfilespec and haxe.pblangspec in /Library/Application Support/Apple/Developer Tools/Specifications/ and restart Xcode (note: haXe code highlighting is only enabled for files ending with .hx). If you only want the plugin to be installed for your user account, make the root path ~/Library.



(To create the language definition files, I modified the script for generating Actionscript language tokens I found on mabwebdesign.com to parse haXe source and output haXe language tokens. I then modified the Actionscript language definition files provided with the original script to support the haXe language. As you can see, most of the work has already been done for me :) )

Second, the Xcode + MTASC trick I wrote about in a previous posting also works with haXe. You're probably too lazy to go back and read it, so I'll explain: if you call the haXe compiler from an Xcode shell script target, Xcode will correctly interpret haXe's error messages and point you at the problematic line in your code (tip: you can press Apple + '=' to jump to the error's location).



Here's the best way of setting up Xcode's build system for a haXe project:

- Create a new shell script target called 'build'.
- Edit the shell script to invoke the haXe compiler (example: "haxe compile.hxml").
- Create another shell script target called 'run'.
- Add the target 'build' to the new target's list of dependencies.
- Edit the 'run' script to open the generated swf (which you should embed in an html page) in Safari
(example: "open -a /Applications/Safari.app build/index.html")

When you set things up in this manner, if 'run' is your active target and haXe runs into a compilation error during 'build', Xcode will abort before reaching 'run' and Safari won't be opened, which would otherwise be a horribly annoying behavior. By my experience, this setup greatly speeds up development and testing.

Note: this is a new edit (5/5/2006). If you don't feel like going through all these steps yourself, you can install the haXe Xcode project template I created, which is included in haxeXcode.zip. Simply put the folder called "haXe Application" in /Library/Application Support/Apple/Developer Tools/Project Templates/Application and restart Xcode. Now, when you create a new project, you'll see "haXe Application" as an option under "Application." Just make sure to edit the "run" target's script to point at your location of the haXe executable. (The reason I chose to invoke Safari from a shell script is that the 'open' doesn't launch a new Safari process in case Safari is already running.)

Final tip: I set up CTRL-space as auto-complete key-combo. I use it all the time and it greatly speeds up coding.

Hope this helps! Let me know if you have any comments or suggestions.

haXe

The prevalent way to develop web apps these days is to use a server side language (PHP, Perl, Python, Java, Ruby, Erlang, C++, etc.) for backend logic, Javascript for browser (AJAX) logic and Flash/Actionscript to create swf's if you need vector graphics, animation and interactivity beyond that which AJAX can provide. This makes web development quite burdensome and complex. haXe was born out of a seemingly simple idea: it doesn't have to be this way!

If you were willing to put your aesthetic sensibilities aside, you could use Java to develop both both server side logic and client side applets. However, the JVM hasn't caught on as a platform for client-side development because the JVM isn't universally available (and it's a big download), and applets tend to be ugly and slow to start. (I'll reserve more articulate Java bashing for future posts :) ). Ruby on Rails has made progress in the one-language-for-all-needs direction with a cool new feature called RJS, which allows you to write Ruby code that Rails compiles into Javascript. However, there's no way to easily integrate SWF programming with ROR as far as I know. In addition, although I really like ROR, Ruby's speed is not exactly blazing and its lack of compile-time type checking has its disadvantages.

Enter haXe.

haXe is language with an open source compiler and a set of libraries that you can use to create all aspects of a web app: Javascript code, compiled SWFs and server side code. haXe has some great benefits: it lets you reuse code between all platforms; it eliminates the burden of shifting mental gears every time you work on a different aspect of your application; it makes it easy to write portable code that runs on all browsers and/or different Flash player versions; it has a very fast compiler; and, like most good things, it's open source.

haXe is also a very well designed language. Its syntax is similar to ActionScript 2.0's syntax, but haXe's type system -- a mix of static, dynamic and inferred typing (similar to that ML-derived languages) -- is far better than ActionScript's simple dynamic typing. From my experience using haXe, its type system is extremely helpful for catching errors early and developing maintainable code without sacrificing the flexibility of dynamic typing when you really need it. haXe's support for object oriented programming, closures, iterators, type parameters (similar to Java generics), enums (powerful variants types) and fully typed anonynous objects should convince you that haXe isn't a toy language by any means.

As you might have guessed, all is not perfect. haXe's server side features are not very mature -- but Nicolas Cannasse, haXe's creator, is developing them rapidly (and the Necko Virtual Machine, on which the server side code runs, looks pretty solid: Necko is supposedly 30x faster than PHP). The Flash 8 support is superb, but it's not clear when Nicolas will implement support for Flash 9. (Right now Flash 9 is in beta. I think Nicolas is planning to tackle Flash 9 support when Adobe makes the final releases.) In addition, the haXe community, although very enthusiastic, is much smaller than the various LAMP communities, so don't expect too many 3rd party libraries and tools (but you don't need such luxuries anyway: write your own!).

I've been mostly doing Flash development with haXe and I'm pretty impressed with its capabilities. I haven't used the Javascript compiler much, but it looks quite neat and I will probably use it more I have a greater need for AJAX. I also haven't touched server side features, which are the least developed aspect of haXe. I think that in a few months, when haXe is more mature, it will be an excellent language for all aspects of web application development.

Keep haXe on your radar. In the meantime, unless you're doing Flash development, go back to Ruby on Rails -- but don't forget that "haXe on Rails" ("haXOR," aptly suggested by a mailing list member) is around the corner.

Flash Programming

It's been a few years since I've done anything with Flash. I used to work a lot with Flash, and I like Flash, but I've been too busy doing C programming for my job to devote much time to Flash hacking. However, my interest in Flash has been recently rekindled by a cool project idea I had in which Flash would be a key component.

My interest in Flash is now almost gone.

Please don't get it wrong -- I don't have a pathetically short attention span. I'm still interested in the Flash player, which is a very powerful runtime for rich Web applications; it's the Flash IDE that I've abandoned almost entirely. Googling around, I have discovered an amazing wealth of open source tools for swf creation (osflash.org is a great starting point). The most impressive of these tools is MTASC, an open source Actionscript 2.0 compiler written in OCaml by Nicolas Cannasse. I have used MTASC to compile a very basic prototype for my application, and it works like a charm. The best feature of MTASC (beside the fact that it's open source) is its speed: MTASC leaves the Macromedia compiler in the dust, especially when you have to compile a non-trivial project.

MTASC also integrates really well with XCode, my IDE of choice. I discovered that when you call MTASC from a shell script target in XCode, XCode magically inteprets MTASC's error messages and points you at the problematic lines in the code. Combined with the Actionscript language definition files I found here, MTASC makes XCode an excellent Actionscript development tool. (I have tried using Eclipse + Ant but it was painfully slow -- at least on my G4 powerbook.) The only disadvantage is that XCode doesn't have a debugger, but it hasn't been a big issue for me so far.

MTASC has been fun for a while, but I already dumped it for a new tool. Not just a new compiler -- but a whole new language, haXe, created by none other than Nicolas Cannasse. I will write more about haXe soon.

Hello World

I decided to catch up with the times and start a blog about programming, technology, philosophical musings and basically anything that comes to mind. I have learned so much -- especially about programming -- from reading other people's blogs, so I wanted to give something back by sharing some of my knowledge with the rest of the world.
Plus, I've recently grown quite concerned with the shortage of time-wasting distractions made available to members of the modern workforce by the severely underutilized technology called the World Wide Web, so I decided I'll have to do my part to mitigate the situation by providing a worthwhile destination for my faithful readers as they stare at their browsers' hopelessly blank address bars contemplating whether Solitaire is about to make a comeback in their lives.

Enjoy.

This is me, at Fisherman's Wharf in San Francisco, with Alcatraz in the background: