Learning the Language, Part 2
So, shortly after I wrote yesterday's post (half a year ago), I decided to try C++. I know C moderately well (though I'm rusty), and C++ pretty much has everything I'm looking for… robust GUI libraries, tons of third-party libraries, a billion books and resources.
And C++ isn't all that "old school"… lots of useful features have been added to the standard libraries, like greatly improved string handling classes and garbage collectors. The OO features of C++ let me abstract away a lot of the more painful bits I remember from C. I worked through a beginner's book on C++ and felt oddly at home and awkward at the same time. It's been a very long time since I've had to deal with memory management. C++ has really improved it, with all the standard libraries having hooks to integrate your own garbage collector, etc. But in the end, it didn't really stick. I think, like many of the languages I've dealt with, the overhead of learning the language combined with trying to learn the GUI libraries at the same time puts me off.
Then, aside from my own projects, I'm dealing with another factor. My 10-year-old son wants to write video games. Has wanted to for some time, in fact, and we've dabbled with Scratch and Etoys, both of which are built on top of the Squeak Smalltalk environment. Scratch is pretty cool, with its drag-and-drop programming elements... it worked really well for teaching my son basic programming ideas. But it was really limited. Arrays didn't get added to the language until we'd been using it for a few months. It just can't write "real" games.
Keep in mind, we're competing with Flash games here. When I was a teen, we all tried to write games. But my Apple //e was competing with the Atari VCS and other Apple games. And I paid money for some Apple games that looked like they'd been written by teenagers, some of them written in Apple BASIC. So it wasn't a large leap to get from basic programming skills to something that could reasonably compete with home video games. Cabinet games were something else, but they had dedicated hardware, and even Atari proved that they couldn't reproduce Asteroids or PacMan on the VCS in a way that felt anything like the arcade games. But my son has had a PS1, GameCube and now a Wii in his house. He has a wealth of Flash games he can play for free. When he wants to write a game, he wants to write at least something of the quality of N64 Mario Bros.
So we jumped to Etoys, which isn't as elegant as Scratch and has a much steeper learning curve, but is still very drag-and-drop, visually oriented. This was pretty cool, really... a sprite on the screen was an object, and it had scripts attached to it, so the whole object-oriented, messaging paradigm was clearly illustrated for my son. And it had better collision detection, the ability to create and destroy objects on the fly, and so on. But we still ran into limitations... Etoys could get really slow. The collision detection wasn't reliable (I uncovered a bug in it). And the developers made it clear that Etoys is meant to teach concepts, not to produce finished works. Combine that with Smalltalk being a dead-end for all of my purposes, we ended up dropping it.
Which leads me to these last few weeks. I finally gave in and started learning ActionScript 3 to write Flash games. The Flex SDK, which includes the compiler and libraries, is Open Source. ActionScript 3 is a flavor of ECMAScript, making it a brother of JavaScript... these are useful languages to have to further my career. It's a "real" language with a vast, professional core library. All I had to do was figure out how to write ActionScript code and compile Flash without an IDE on Linux. (That's a tutorial for another day... it's amazing how most Linux tutorials assume you know something about building Flash already when they talk about using the Flex SDK compiler without an IDE.)
I found a robust game library, Flixel, which does a huge amount of the heavy lifting, such as automating motion, collision detection, and so on. Flixel is great, and there are utilities available for it, even on Linux.
I generally consider Flash on the Web to be mostly evil. But I think of Flash as being a perfect platform to deliver games... I don't have a problem with that at all. And now I'm teaching my son to write games in a language that doesn't have any limitations... it can do what all of those games he likes do, because it's the same platform. He can freely share games with his friends (something Scratch and Etoys weren't so good at).
I won't lie... ActionScript and the compiler have their oddities. But the language is both a career skill and useful to teach my son, so it's a win all around for me.
Learning the Language
I've been stuck for blogging. Mostly because I have a handful of half-finished posts that keep me from blogging about anything else. Time to clear them out.
I've run into a odd crisis of sorts. Professionally, I'm a Unix systems administrator. But not a fill-in-the-blank, push-the-button sysadmin… I write lots of utility code, I analyze system problems with lsof and strace. I understand a lot of what's going on under the hood. I've done a fair amount of software development in and around the systems administration stuff.
I started out on this path planning to be a developer. And in fact, my current job title is Software Developer (even though the job can be more sysadmin than development). I started programming computers in middle school (not many forty-somethings get to say that), and I progressed from Apple's BASIC to Borland Turbo C on a MS-DOS box. In college, I had to learn a little Pascal and Modula II (I dislike "teaching languages"), as well as being exposed to Lisp and Prolog. But C was pretty much my go-to language, and there wasn't a great deal of that GUI stuff going on yet.
During college (which came a few years after High School), I started working for an ISP, my "career" skill-set started focusing on systems administration, and Perl and Bourne Shell became my go-to languages. I still wrote in C for school (a simple Unix shell, networking code, lots of stuff), but Perl did everything I wanted for my personal projects without the overhead of that "complicated" C stuff. I dabbled with C++, but I was really just writing C while taking advantage of the IO stream system… I never really learned the OO stuff.
But career-wise, I figured, I'm a systems administrator, Perl and Bash are all I really need. I looked at Python, but I didn't really like it, and the joy of learning a new language has faded for me… it just gets frustrating when I think, "I already know how to do this in Perl, why am I trying so hard to figure it out in Python?" And I think the big thing there was that Python wasn't bringing enough value to the table… sure, it was supposed to be better at OO (OO being required, instead of an optional tack-on like it is in Perl), and easier to maintain with larger projects. But it was still an interpreted scripting language… it was adding a second hammer to my toolbox, and while it might have been better suited to certain tasks than the hammer I already had, learning to use it took far longer than just applying the less-ideal first hammer. So I abandoned it.
But over the last few years, I've run into a problem. I need tools that are not in my toolbox… primarily, I need a good platform for building GUI applications. And to complicate that, I want something that's as cross-platform as I can get. I have a couple apps I'd like to develop that I want to share with people, and I don't want to tell the Windows users to take a leap.
Thing is, Perl can be kind of slow with a GUI, it's difficult to distribute to novice Windows users, and really… for all my love of Perl, I still think of it as a little utility language. I don't like writing big apps with it.
So then what do I do? Java? I've not had good experiences with cross-platform Java apps… getting them to run in Linux has often been a pain, and very few Java apps look good. Some look amazing, but considering that most don't, I'm guessing that making it look good, and/or like a native app, is rather difficult.
I've been learning Haskell on the job, but I'm not finding Haskell to be suitable. It has a lot going for it, but two big strikes against it (for me), aside from the steep learning curve, are that the size of the third-party library selection is small and often "experimental", and my code wouldn't get distributed very far… there are plenty of folks who aren't going to install a Haskell build environment just to compile my code. To top that off, Haskell doesn't do much for my resume… Haskell programmers are not in demand.
Six months after I wrote the above, it's still complicated. There aren't any good, cross-platform choices. The languages I find attractive aren't good at being cross-platform, and the languages that are good at cross-platform fall under the "slightly evil" heading. Tomorrow, I'll tell you what's happened since and which "slightly evil" I've chosen, albeit with the best of intentions.