C++ to ActionScript

One of the sneak peeks at Adobe MAX 2007 Chicago was a C++ to ActionScript translator by Scott Peterson. This was the most interesting of the sneak peeks for me in part because I was a C++ developer for 12 years (until 3 weeks ago) and because of the implications of the translator.

First check out the video here:
http://youtube.com/watch?v=0hX-Uh3oTcE

During the demo he showed:

• A C++ XSLT library turned into ActionScript
• A fractal program from C++ to ActionScript simulating green threads using ActionScripts asyncronous calls.
• Doom 2 running in Flash.

How does it work:

1. C/C++ code is translated to ActionScript 3
2. AS3 code is compiled into a SWF
3. Run the code on Flash/AIR
   

What does it mean:

• Easy porting useful open source C++ libraries/programs to ActionScript to run on the browser.
• Porting interpreters for languges like Ruby, PHP, Lua, Python, Smalltalk. ... to run on Flash.
• Writing your own DSL using ANTLR and porting the C code to ActionScript without having to write an ANTLR target language. I recently wrote a shunting yard algorithm Lexer and RPN parser in ActionScript for an Excel like language where this would have saved me some time (but not the fun of writing my own Lexer/Parser).

Scott Peterson, if you ever read this and want an alpha/beta tester I have two projects in mind:

• An AIR Subversion client.
• Porting the Squeak Smalltalk core to AS to match the Vista Smalltalk in Silverlight project.
  

What is Thermo?

Yesterday at Adobe MAX 2007 in Chicago, I had the pleasure of seeing a sneak peak at a potential future product of Adobe's codenamed Thermo. I'm a developer and not a designer and have never worked with a designer, but I can see the appeal of the product. Plus it is technically cool.

During the demo they took a UI mockup drawn in Adobe Photoshop with layers. Thermo converted that mockup int MXML. The converted MXML had new "graphics" tags that will be added to the language. The graphics tags draw (as you may guess) graphics primitives (boxes, lines, etc), text, images, etc. While not interactive yet, the mockup can be compiled as a Flex application.

Then the magic comes in. Graphics items are selected and turned into controls. For example a box with some text in it was turned into text input. Relatively simple yes, but the compiled Flex app was now interactive. Next they turned a row of Album images with a drawing of a scroll bar in it into a scrollable list of albums. Thermo took the images given to populate the list and could add data, import new images, or just duplicate the images so there was something to scroll.

Interaction was added to the application in the form of a rollover on the albums that zoomed in and showed the title and artist. Overall it was an impressive show of the transformation of graphics to an application.

The "Flex Roadmap" session shed some light on what might be going on behind the scenes in MXML for Thermo (and any other Flex development). From what I hear skinning a control isn't easy (I haven't done so) but the future version will make it easy. They will split the controls into a MVC like architecture with a Skin, Controller, and Model.

The Model encapsulates data, the controller behavior, and skin all of the UI. The skin is all done in declarative MXML using the graphics tags (including transitions). During this demo they showed how to skin a list control to look like a standard list, list with icons, behavior, turning a list into tabs, turing a list into an accordion.

I'm looking forward to the future of Flex.

Shifting Gears to Adobe Flex and C#

Times change and so do jobs. I'm starting a new job in two weeks working with rich internet applications - Microsoft SQL data store, C# middle-ware, and Adobe Flex GUI. None of which I have any professional experience but I'm eager to learn.

So what this means is that Squeak, Erlang, and Rails take something of a back seat while I learn the technologies for my new job. I plan on dabbling in Erlang and Rails for being the middle-ware for my own personal projects.

Meanwhile, I wrote a Sudoku solver in Flex for my algorithm analysis class.

http://www.arcanearcade.com/Flex/Sudoku/Sudoku.html

Overall I really like the Flex framework thus far. It is nice to know that Flash 9 has a 90% browser penetration, so it makes for a reliable platform for distributing my own Flex applications. The applications look really nice as well - as a Windows application developer I've always found most web applications not quite up to snuff.

New Life For Squeak's UI

One of my sole complaints about Squeak is its ancient looking user interface and a lack of a standard GUI interface builder. There are a couple of the latter and the community knows about the former and is working to correct things. A squeaker named Gary Chambers is poised to commit some excellent UI improvements:

Go here to see more images.

There is a UI mailing list for Squeak discussing this and other UI improvements.

Reflections on the Demise of Dolphin Smalltalk

The Smalltalk community lost one of its vendors this week. Dolphin Smalltalk threw in the towel. While reading this post, I reflected on Dolphin's developers and lucky13's comments on Dolphin and open source.

This all reminds me of my first encounter with smalltalk over 10 years ago. I had been a professional C++ developer for a little while and was curious about the origins of object oriented development. After doing a little digging I became interested in learning Smalltalk... until I saw the price tag.

At the time the only Smalltalk implementations I could find on a quick internet search cost hundreds or thousands of dollars. I was interested but not that interested, so I dropped the idea and it has taken years for me to return.

It is hard to win over developers to a new language and even harder when they have to fork over vast sums of money for the privilege. Look at the popular languages for the last few years (Ruby, Python, PHP, Java, Erlang, even C/C++), with all of them the first hit is free. Even Microsoft seems to have caught on in recent years; you have been able to get free versions of Visual Studio for a while and before that there was a command line C# compiler available for free.

While I have often paid for a development tool or library, it has only been after my first free hit. The only reason I have purchased Microsoft Development tools is because of the market pressure for a developer to work in that environment (it is where I make my living, even if C++/MFC/etc. aren't the "best").

I don't think that Smalltalk will die but there are lessons to learn in gaining the hearts of alpha geeks that Smalltalk can learn.

Squeak Smalltalk First Impressions

As mentioned before, I decided to learn Smalltalk and was interested in Croquet and Seaside. This made the choice of Smalltalk implementations clear - Squeak. So I head on over to squeak.org and download the latest version.

The first thing I notice is that the color choices in the UI are... unexpected and the UI appearance is circa 1980 (I opened a few windows and menus as an example, this isn't what you see at first):


It doesn't bode well when your first impression of a development environment leaves you not wanting to make anything that looks like the environment. But I press on and start playing with the environment.

Smalltalk/Squeak isn't like other languages. Instead of getting a compiler and using your favorite text editor, you are given a whole environment to learn all at once. Squeak is your IDE and just about your whole OS. Smalltalk doesn't use the file system in a conventional sense. Instead everything is stored in the .image file that is essentially a snapshot of the running virtual machine.

Here is a brief translation of the tools you need to know:

• Code Editing - Class Browser, there are several to choose from (default, Refactoring Browser, OmniBrowser, Whisker Browser, etc). The default squeak image
  
• Saving Code - Not needed, everything is saved in the image and changes file. You can file out/in code.
  
• Source Code Control - Monticello (or digging out the changes)
  
• Unit Testing - SUnit
• Basic Tools
  

Here is a good place to start for more information on squeak: http://wiki.squeak.org/squeak

Here is a nice programming tutorial in Squeak: http://squeak.preeminent.org/tut2007/html/index.html

Here is an excellent tutorial:

Which Smalltalk?

There are many Smalltalk implementations to choose from but because of an interest in both Croquet and Seaside, my primary choice would be Squeak. Squeak runs on many platforms (I'm on Mac OS X 10.4), is one of a few implementations of Smalltalk that runs Seaside and is the only one (that I know of) that runs Croquet.

Here is an abbreviated list of Smalltalk environments available:

• Squeak - A free cross-platform Smalltalk environment. That I'll talk about more in a later post since I'm using it as my development enviornment.
  
• VisualWorks (Cincom) - A cross platform Smalltalk environment with a free community and commercial editions. They support Seaside (in a big way), look better than Squeak (IMHO), provide great community support with tutorials documentation and screencasts, and have visual GUI editors. The only thing stopping me from using them is that Croquet runs on Squeak and I just want to learn one Smalltalk environment for now.
  
• Dolphin Smalltalk (ObjectArts) - A Windows only Smalltalk environment. There is a free community edition and commercial editions. The product looks nice and has a native look and feel.
  
• Vista/Silverlight Smalltalk - Smalltalk running in Microsoft's Silverlight. Pretty cool and cross-platform through Silverlight.
• GNU Smalltalk - POSIX version of Smalltalk. Unlike the others in this list, GNU Smalltalk is less an all encompassing environment and working with it should be more familiar to most developers than the standard Smalltalk way of doing things.
  
• Other versions - There are several other versions of Smalltalk available.
  

Why Smalltalk?

In my first post, I mentioned interest in Ruby, Erlang, and Smalltalk. It is easy to understand why the first might be of interest given the large amount of press they have been getting lately. But you may get to the last and ask:

"Why on earth would you be interested in Smalltalk? That ship set sail 30 years ago and hasn't been popular since the 80's. Think you can find a job using that language buddy?"

Popularity and finding a job aren't my motivators for learning Smalltalk, but I do have several other motivations:

• Historical - Smalltalk was one of the first object oriented languages (Simula beat it) and as such forms the foundation of much many modern languages. I might learn Lisp for the same reason.
• More dynamic than even Ruby - As well as having the equivalent of Ruby's duck typing (you send "messages" to objects in Smalltalk), Smalltalk programs can be changed while the program is running.
• Seaside - An interesting web development framework.
• Croquet - A peer-to-peer 3D environment similar in concept to Second Life. I'm planning on writing my master's thesis on "Peer-to-Peer Collaborative 3D
  Content Creation" using Croquet.
• Interesting Environment - Smalltalk is more than a language, it is a complete environment and closer to an IDE or even an OS where you can reprogram everything including the compiler on the fly. More on this later.

I may never make a living (or even a single penny) with Smalltalk, but I think it has valuable lessons to teach me.

Introduction

I've put off making a blog for a long time, mainly because I didn't have anything I wanted to talk about. Now that I'm embarking on a voyage of discovery on the shores of software development, maybe I can find something interesting to talk about. At the very least I can use the blog as a development log of sorts for my own use. But first, a little about me.

Software development isn't new to me, I've been a professional code monkey for 12 years now. My paying gigs have mainly mainly been in C++Windows, Linux, and Mac OS X programming with a few ventures into Java based web development. In my private time I have played with Perl, Python, and Ruby. I've dabbled in other areas of the industry including technical support, product management, and plain management. I even got an MBA before I learned that management really isn't for me because my passion is programming.

My voyage began recently with a rekindling of my love for development. First I taught a class on software specifications at the local university and then I decided to go get a Masters in Computer Science. These events in turn have ignited an interest in dynamic, functional, and concurrent programming languages; mainly in the forms of Ruby, Erlang, and Smalltalk. More on these in more focused posts later.

My intention is to post at least once a week to capture what I have learned or thought about. I have some catching up to do since I started over a month ago, so there will be a flurry of initial posts.