"The random number generator keeps giving me a floating point number and I need integers from 1 to 20. It took me a long time to come up with this solution, so I thought I'd share it here."

It was more or less the right solution (though I don't know why they abandoned Flixel's random() function to call on Math.random() when they both do the same thing), but it struck me... dealing with random numbers is a beginner's problem, and I dealt with it long before I was doing graphics programming, or even had libraries outside the core language to work with.

And this is where it occurs to me that I have it easy learning ActionScript. I already know the fundamentals. I can't imagine how intimidating the vast Flash library must be to someone who doesn't take for granted the knowledge of how to generate a random number from an integer range.

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.

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.

On the way out of Twist a week ago, Nathan (our 9-year-old) saw some bright orange yarn… orange and blue are his school colors (their mascot is a tiger), and he wanted to make a scarf for a teacher.

So last Saturday, we dropped by Twist to knit and I bought him a couple skeins of Cascade wool yarn in bright orange and a darkish blue. Borrowed the round "hat" weaving looms out of the library and Mona, one of the Twist regulars, taught him how to knit on the loom. We abandoned that little bit of work and left the looms behind, and Sunday I bought a set of "long" ("double-rake") looms at Michael's, since he wanted to knit a scarf, and the Knifty Knitter double-rakes are set to a smaller gauge than the round "hat" looms, which is more appropriate for the worsted weight yarn he picked. I also ordered the Knitting Loom Primer from Amazon Sunday afternoon, and thanks to Amazon Prime's two-day shipping and the book shipping from the Oklahoma warehouse, it arrived yesterday.

So when I got home from work yesterday, Nathan had the book out and had started the scarf by himself. He wasn't far in and was having trouble with getting the wrapping right, so I helped him set it straight and he knit three rows before deciding to play a board game. But he enjoyed it, and likes how quickly it goes, and he's making big plans to make all kinds of things and to learn to knit on needles. I'm just hoping he finishes this project.

While we played the board game, I started a hat with the other skein of yarn that matches his scarf. There are a lot of neat patterns and techniques in the book (dang, you can purl, increase/decrease, cable knit and even do Fair Isle patterns… the makers of knitting looms are under-marketing them) and I figured it was a good idea to get ahead of Nathan a bit, so I could help him when he tried something more advanced and had trouble. And he's more likely to finish his work if he sees me finishing something similar. So I'm making a hat, and I've got another small Christmas project I want to knock out, so my own hat is on-hold for awhile. Which is cool.

He can explain the Three Act Model and the sequence of rise, climax and denouement, and how conflict is required to build this sequence of dramatic tension and release. Of course, like any parent, I wonder if he really understands it, or just recites what he's been told.

His new gifted class teacher is well-connected to other such teachers in our district, and some of them got together and had their students read the same book, Chasing Vermeer, a mystery. They then started an inter-school discussion of sorts on a blog set up for the purpose. The first blog post to which they were to respond asked, "What makes a great mystery?"

Many of the responses were the kind of thing you expect from the upper grade school levels: "One that I can't put down," "One with a great cover," "One that keeps me guessing." A few were moderately insightful, but few really grabbed hold of something that explains how to write a good mystery. But here's that proud parent moment, over which you may roll your eyes if you wish… my son's response:

I think what makes a good mystery is:

1. a key item or number
2. characters who normally don't like each other work together
3. no one except main characters know about crime/theif

Chasing Vermeer involved numerical clues, so he focused on "number" there, but #1 hit up on the essential MacGuffin. But #2 is the big one for me… right there, he defines part of a good mystery as creating conflict. Not just the primary conflict of solving the mystery, but secondary conflict between two main characters who don't get along. Sure, he was prompted by the content of the book, but he identified this aspect as being important. I haven't read the book, but I'm guessing that #3 is a source of tension and possibly direct conflict. The big difference between his response and most of the other responses is that his response addresses concrete elements of story and while the others are much more general.

So I have some confidence… he is actually understanding something of the theory he's been taught. Now, I'll grant you, he's been taught a lot more than the usual fourth grader. They did study rise and climax in class, but he and I have looked at some of his favorite movies and books to identify and understand the story elements at work.

On the other hand, he needs to work on that i-before-e thing.