The only awkward thing about the rules is that it doesn't seem very much like Minecraft when you cannot mine or build.  You can't even explore a deep cave, because you are required to travel far enough to find a new biome every day.  But having seen his first two episodes, I decided to give it a try and have found it to be rather fun.  One night, when I realized that the sun had nearly set and I hadn't found a defensible cave to shelter in, I found myself on staking out a hilltop and defending it on all sides.  It brings a whole new dimension to the game when night no longer means shutting yourself up in a fortress and mining for diamonds while you wait for dawn.  Now you're holed up in a cave, and it turns out the cave has a back-door...  you're not allowed to place blocks, so you can't just wall up the entrances... you have to stay alert and keep an eye on both of them.  I did find that I used Paul's rules about digging to the best effect a couple of times... you can mine stone one layer deep, dirt two layers, and sand/gravel three layers.  So more than once I have dug trenches across cave openings, figuring that's nearly as effective as building a wall.  And things get tricky when you need wood, can't carry it with you, and discover that you need to shelter in a desert, where there are no trees.  Or you want to make a new sword before your current one breaks, but you can't find stone anywhere near your chosen shelter.

I have also decided that TNT is not a "block" so long as I don't use it as an obstacle...  if I've gone to the trouble of collecting (and carrying around in my very limited inventory) that much sulfur, then I should reap the rewards, whether it be blast-mining or blowing up skeletons.

I think the hardest part about this mode of play is seeing really neat mountains or cave openings and being unable to stop and explore them.  I've taken to marking these sites with torches on the ground in an "X" pattern so I can see them with my map viewer later and go back to explore them later.

But all this has me thinking...  the goal is an arbitrary 14 days.  The distance to cover each day is "reach a new biome" which really isn't difficult. If I just set off running in the morning, I can usually reach a new biome well before noon and have plenty of time to search for shelter.  In fact, when I encounter a desert biome, I usually keep running for the next biome to find better shelter.  And "take off running" is good advice when you want to get an early start... it seems the best defense against creepers is a good sprint.  Even if they're hiding up ahead, they like to hide just off your path... if I'm already running, I can usually pass them fast enough they don't even explode, or they explode so far behind me I don't get hurt.

But that's all I'm doing... sprinting from biome to biome, with no ultimate goal but to survive an arbitrary number of days.  I find myself thinking I need more of a goal, and it would be great if I was trying to reach a specific destination, say, the King's castle, to warn him of an invading army.  The faster I get there the better, so when I reach a new biome in early morning, I can't decide to use the rest of the day to explore and find a good shelter.  A deadline would mean I'd be pushing as far as I could before sundown forced me to ground.  I might even decide to keep travelling through the night to make better time.  I would take more risks, and meaningful conflict makes for a more interesting game.

That has me imagining a pre-built map...  someone would have to intelligently lay out the destinations and goals.  But that would add the opportunity to add way-stations... wouldn't it be great if I knew that, if I can just make it a little farther before sundown, there's supposed to be a pre-built shelter stocked with supplies?  And it would give me an opportunity to acquire weapons and armor I'm not able to build on my own while travelling?  It would be fun just to discover unexpected man-made structures along the journey.

Even if there was no story behind it, just having a series of concrete goal posts to strive for would make this set of "Iron Man" rules even more fun.  I might have to start making that map.

Day/Night cycle

My first inclination is to say that the day/night cycle is too short. Ten minutes is not a lot of time to rush outside, scan for creepers, then run to your building location. I'm building an arched bridge across a bay channel (between the spawn point and my fortress; the closest mountain was across the bay, darn it), and I spend nearly 10% of my day avoiding creepers and swimming out to the work site before I even get to work. (Creepers swim, darn it again!) I could have built a shelter closer to the build site, but then all the monsters would congregate around the build site, making it harder to get started. As it is now, at least I can dash across the courtyard and jump into the bay and no more than one or two creepers follow me. But then I have to take time to repair the fortress where I missed a creeper hiding around the corner and it blew up part of the wall. Sometimes, I think I get maybe five minutes to build out of a 20-minute day cycle.

Now, here's why I think maybe the cycle isn't too short. It creates pressure, and causes me to think about things other than "how does my bridge look?" Maybe what I need to do is mine a tunnel under the bay to the work site. Yet, if I had a tunnel from the fortress to the spawn point, I wouldn't be building a bridge across the bay! But that's an example of the kind of thinking the pressure creates. And conflict is what makes Survival mode work... it just has to be the right balance of conflict.

I would at least like the day/night duration be an adjustable setting. I don't want to use Peaceful mode... I want the challenge of working around the monsters and the dark. I just don't want to spend more time dealing with the challenges than I get actually building my bridge.

Water, water everywhere?

While I think water behavior is improved from Classic (a single block of water is an infinite source that will fill every open space it can reach up to sea level), it's gone too far the other way. If I'm digging a shaft under a massive body of water (the "ocean") and accidentally breach the ocean floor, the water only flows in for seven blocks, petering out and apparently soaking into the ground. My entire tunnel isn't flooded… it isn't sudden death or a mad swim for the surface for our adventurer. It's just a short struggle against the current to drop a block into the flow, then carry on as before.

If I dig a level trench below sea level from the bay to my moat, I expect it to fill my moat. But it won't even fill the trench. I see that this is a difficult problem programmatically. A clearly finite source of water should not increase in volume. But it's not possible to calculate the volume of the "infinite ocean"... how do you efficiently determine if the water in question is attached to the infinite ocean or not?

I really miss Classic's water mechanic when it comes to intentionally flooding an area. It's just so cool to open a dam and watch the water flow and fill everything. To fill a cave with water in the current game takes a lot of deliberate and difficult work. (You basically can't... my swimming pool looks still on top, but below the top layer, water is continuously falling down to the bottom of the pool. Jump in and you have to swim up a waterfall to get out.)

I wonder if there is a compromise to be found, but I can't figure out how it ought to work. And I do like finding waterfalls and small streams in caves that haven't filled up the entire cave. Maybe if flowing water found no place to go after three or so blocks it would start filling the space. This would still create new water blocks, but it wouldn't create an unlimited amount of water if you poured it down the side of a mountain.

Over the next few posts, I'm going talk about things I'd like to see "fixed"... not new things I'd like to see in the game, but existing game mechanics that affect game play as a whole. Having played the game for awhile, I'm looking at what keeps my interest, what starts to be boring, and what I think would make the existing elements create a more compelling game.

Mob drops

There has to be more of a reason to fight monsters (hostile mobs, apparently "mob" is short for "mobile") other than "they're in the way". The peaceful mobs (cows, pigs and chickens) drop more useful items than the monsters do. Cows give me leather for armor, pigs give me pork-chops for healing, and chickens give me feathers to make more precious, precious arrows.

Spiders drop "string", and while string is extremely important to us bow-toting, shoot-monsters-from-a-safe-distance rangers, once I have a bow (and a backup bow) and a fishing pole, I don't need more string. (The new "Dispenser", which can fire arrows as part of a trap, requires a bow, so string's long-term demand just went up some, if the dispenser proves useful as a "survival mode" tool... though I suspect the dispenser is more of a novelty item for pure "survival".)

Creepers drop sulfur, which I can use to make my own explosives (TNT). Dropping sulfur is logical, but TNT isn't all that useful to me. (Maybe I just haven't found the right use. It can be used to make clever traps, but enough TNT to kill a mob destroys the landscape, which lowers its value for me a lot. It's not often I want to make huge gaping craters just to injure a few monsters.) Again, coming up with a more useful recipe for sulfur would make it more valuable. Something like a grenade, though don't call it that; a small, explosive "fire bomb" made of sulfur and coal that you can throw at monsters would be useful and not replicate an existing weapon.

Skeletons drop arrows and bones... that's nice, but I can kill a chicken and get two feathers from which I make eight arrows, which beats the two arrows a skeleton might drop. Bone is logical, and useful for survival, since it can be converted to bone meal and used as an instant-grow fertilizer on wheat (used to make bread, which heals).

And zombies drop... feathers!? Yeah, chickens may be harder to hit, but they don't hit back. It costs more arrows to kill a zombie than the feathers it will drop, and if I want to fight zombies with a sword, I wouldn't be looking for feathers. (I know others don't play this way, but I look at my sword as a last-resort weapon, for those rare times I run out of arrows and I am forced to fight hand-to-hand.)

For the most part, I don't find any reason to fight most of the monsters in the game. Only spider works well in that regard... early in the game, I realized that I was going to have to go out with my wooden sword and hunt down some spiders if I wanted to make a bow to better defend my home with. (At the time, I didn't know how to make leather armor, didn't know I could make a stone sword, and didn't know I could eat raw pork for healing and didn't know how to cook it, so some of that was the thrill of playing the game for the first time and not knowing how to play "right".  Now days, by the time I attack a spider, I've got leather armor, a stone sword, and cooked pork in my pocket.)

Maybe if the bow wore out like all the other tools and weapons, then I'd have a reason to gather more string.  But zombies and skeletons not only drop resources I can get elsewhere, there are safer ways to get those resources. (Killing a pig is much simpler than killing a skeleton for fertilizer, and provides more healing for less effort than bread does anyway.) The creeper is the only source of sulfur, but I really don't find TNT to be in great demand. And it's not like I have to hunt creepers to get sulfur... they willingly run up and explode next to me nearly every time I set foot out my front door, in order that I might have a plentiful supply of sulfur. And holes in the ground.

I think this is the key.  Monster drops that are both useful and not duplicated by another item or source in the game. If zombies were the only source of feathers, that would change things a lot.  (Not that they should drop feathers in the first place, and that would probably make arrows much scarcer.)  I keep coming back to the spider/string example in my head... it made the game really fun, knowing that I was going to have to meet two or more spiders face-to-face in order to make a bow.

One thing complicating the monster drops is that skeletons and zombies drop stuff when they die from exposure to the sun. Wait in your house for the monsters to burn up, then run out and collect arrows and feathers for free. Just watch out for the creepers. If the monsters are going to drop more valuable stuff, this automatic drop may need to be eliminated.  Make the mobs a little smarter so they avoid the more obvious "mob grinders"… they shouldn't be stupid enough to keep running into cactus that damages them until they die, and maybe they should be smart enough to get out of running water.

So the monsters need to drop more valuable stuff. I shouldn't spend, on the average, more resources killing monsters than what the monsters drop, or the monsters should be dropping something I can't get any other way. The risk-versus-reward needs to have a much higher potential payoff.

Hm. Okay, so five years ago, I was working for Company B and I wrote a lot of utility code in the five years I was there. So I moved to Company E, and I quite wisely took none of the code I wrote for Company B with me because that would have been illegal. (Note: This is a fictionalized account of my career.) But here in Company E, I find that I need a script that backs up a server. I wrote one for Company B, but I can't legally reuse that code at Company E (if I had a copy of it), because the copyright for that code belongs to my former employer. So I decide to write that code from scratch. Yet... based on my personal coding style, form following function, and having actually written a solution for this exact problem once before, the code I write for E is very, very similar to that which I wrote for B.

Setting aside the unlikely event that anybody would realize that I did this, is that copyright infringement? In light of the photo infringement above, it seems to me that this is basically the same thing. I recalled the copyrighted work that someone else owns and attempted to reproduce it, claiming ownership of the reproduction for my new employer.

I think this happens on a practical basis regularly in computing, but we don't really think about it. Yet I think, technically, it's a violation of copyright. Imagine a world in which a software developer not only had to deal with "non-compete clauses", but had to deal with not being able to reproduce any code he has written in the past for another employer. That would certainly "break" the development world. Previously, I mentioned that I feel like a lot of my utilities and code snippets are the embodiment of my programming knowledge... this is the converse (inverse?) situation. When I write that backup script, I'm not copying a previous work, I'm embodying my knowledge in physical form. Is there really a difference between my writing a shell-script menu loop from memory and copying that menu loop from a library snippet? I don't think so... except the latter is faster and less error-prone, therefore more pleasant for me as well as cost-effective.

I consider programming to be capable of "artistic expression". A good programmer recognizes and delights in elegant code and elegant solutions. But I'm not convinced that all code should be subject to copyright in the way that fiction, non-fiction, music, etc should be. At a basic level, we have a "useful article" issue... the pattern for a basic kitchen chair is not subject to copyright, because a chair is a functional article, a "useful object", and copyright does not allow for protection of function, only expression.

There is only one way to write a Bash for-loop. The variable name can change, the data looped over can change, and the steps between the top and bottom of the loop can change... but the basic structure of how a for-loop works is fixed. Nobody can claim copyright over it. At what point does your "useful article" for-loop quit being "common" and become a protected "expression"? This starts to feel more like patent territory than copyright... at what point is a program innovative enough that it's not unintentionally reproducing hundreds of other programs written in the same situations? When is it not just a "dump" of programming knowledge but an actual novel creation?

But in the course of doing all of this, I inevitably write code in one place that I have a use for in the other. Case in point, I have a bunch of remote backup scripts I wrote to backup my server and all my workstations to local disk, keeping N days worth of changes, etc. I worked out the whole scheme on my own time, have tested it extensively on my own systems and have been using it for over a year. When I needed to back up my new work laptop in the same way (because it's the only machine I have at work now and it's never on the "work" network when the backups run), the obvious solution was to just copy over the software I'd already written, tested, debugged and proven. It's a much more robust solution than the quick-and-dirty backup another admin wrote to back up our webserver. (That one isn't backing up the MySQL database properly. I need to convert it over to my script.)

So ownership here is easy... I wrote it on my own time, it's mine. I can slap my copyright on it and license it for my company's use out of the goodness of my heart. (My annoyance at reinventing a wheel I already invented saves the company money. I could justifiably rewrite that code from scratch on company time, as there's no obligation to give the company the fruits of my personal labors for free.)

But what about the other way around? What if I wrote that backup software on company time? Traditionally, that's work-for-hire and is owned by the company. Being that our company lacks any specific agreements to the contrary, that's is the legal situation where I work (unwritten, informal agreements don't really count in copyright court). Yet, to the seasoned developer's mind, it doesn't make sense to look at the work I've done and have to recreate it from scratch in order to use it from home. Culturally... do developers pay attention to copyright law and the employer's ownership of their code for little utilities? My experience is that they don't.

I think this also works out in the employer's favor... an experienced developer doesn't just take with them code they wrote on the job when they leave, they bring with them all of their favorite little utilities that they've written on past jobs, that they wrote in school, that they wrote on their hobby projects. And often, when they move on, they leave copies behind. The tech support guys use a script I initially wrote over ten years ago when I worked for an ISP. It doesn't look much like the original script, but it has ten years of improvements on it. I wrote it because I needed it, but I've used it at every company I've worked for and passed the current copy on to others in my department. When I move into a new job, I bring with me a whole library of tools that make my job easier, and often make others' jobs easier.

The irony is that if we strictly followed copyright law, treating work-for-hire code as something I can't take with me, and treating any code I wrote on my own time my property and unusable at the company (without paying me a licensing fee), I think the computing world would be in a world of hurt. I'd feel crippled every time I moved to a new employer. (Much like I felt at Company B, when they told me Emacs was not approved software and I'd have to use the "original" vi.) Taking the time to recreate some of my basic tools would be a stupid waste of time... my previous employer would not benefit from it, and I would suffer for it, and I would be less valuable to my new employer.

I see writing these utilities as a lot like learning a new programming language or learning how to manage Sendmail... the employer can't stop me from taking that knowledge to my next employer. And part of that "knowledge," in my mind, is embedded in the code I've written. Quite literally... I have a whole folder full of snippets that I reuse, or use to remind myself how to do something. To me, those are "mine" in the sense that my knowledge of Perl and Unix are "mine".

I had played Minecraft Classic with my son on a multiplayer server ("multiplayer" = the two of us), and while it was pretty fun for awhile, I tired of it after only a couple of weeks. It was pure exploration and building. After awhile, the exploration got dull… it's a neat, randomly generated world, but it's all scenery. There's nothing to do but break up the scenery and build stuff. Once you've dug down to the bedrock (the lower boundary of the world), built a tower to the cloud ceiling with your infinite supply of blocks, found (and swam in) lava, and flooded a cave with infinitely-multiplying water, there's not much else to explore. You can find some neat "natural" caves, but those tire after awhile because they're just scenery. If you don't like building structures with a digital form of LEGO bricks (except you never run out or have trouble finding that one brick you need), there's not much else to do.

So I didn't have much interest in the newer, pay-for version. It had minecarts and track, and apparently had monsters, but that didn't sound like it was worth spending $15 to get more of what I'd already grown bored with. But my son insisted that he needed to try the new version (confusingly known as Minecraft Alpha, but now it's Minecraft Beta, etc… I guess the names are properly "Minecraft Classic" and "Minecraft") and spent nearly three weeks allowance on it after Christmas. And since he was playing it, I bought it and set up a multiplayer server to play with him again.

Wow… what a difference a few little changes make. First, you have no infinite supply of building material. You start the game on a beach, empty handed. It's just past dawn, and there's a day/night cycle that lasts only twenty minutes. That means you have only ten minutes before the sun starts to set… and when it gets dark, monsters come out. And it gets really dark. And empty-handed, you're no match for all the monsters that are going to come pouring down on your head. (They aren't called "mobs" for nothing.)

So the first order of business is to build a monster-proof shelter, and ideally get a light-source so you don't have to wait out the ten minutes of night in idle darkness. That means chopping down a tree and forming it into planks with your bare hands! Then you just need to build yourself a workbench, craft a wooden pickaxe, and go mine some coal to make torches. All before it gets dark.

The fruitless search for coal has led to many an adventurer's early demise. But that's okay, you'll be reborn on the beach where you started. In the dark. Surrounded by monsters. You're not going to do anything useful until morning, and you might as well get used to dying now.

Fortunately, when the sun comes out, half the monster types catch fire in the rays of the sun. The other half are a pain in the butt. One sneaks up on you and explodes. Took me a week of play to learn to recognize the sounds it makes when approaching… it sounds a lot like the player walking on dirt, and I thought those noises were me, or were noises the spider made while walking around. Nope, that's the Creeper, and he is my bane and nemesis. Especially because he likes to explode near my shelter and blow up the cool stuff I've built and make me waste time filling in holes in my defensive wall. Bah.

So there I've covered all the changes that turned a ho-hum "not quite a game" into something I can't tear myself away from. Day/night cycle, with night being dangerous, means you can't just build, build, build outdoors for hours. If you want to build an impressive stone bridge across the bay, you're doing it ten minutes at a time, keeping one eye on the sun and one eye watching for Creepers that have managed to survive. Forced to retreat to the safety of shelter for the night, you mine for limited resources… coal, iron, gold, diamonds. But you have to keep an eye out for the natural caves… monsters spawn in darkness, so it's likely that any caves you find will be full of monsters. So you craft weapons and armor out of the resources you've collected, including a bow and arrows made from the silk of giant spiders you've slain, in close combat I might add.

The game still doesn't quite have a goal yet… it's not finished. (Nearly a million sales and multiple awards and it's not even finished.) But even so, I find creating simple shelter and then turning it into a fortress, then a "livable home" (mine has a sun room, a sheltered patio with fire pits, and I'm working on building a swimming pool with underwater lighting), while searching for limited resources, exploring caves and fighting off monsters rather compelling.

It's fun in multi-player. You deal with supply shortages, have to coordinate activities ("We're short on pickaxes, you go chop some wood while I mine this iron ore."), explore caves ("Wow, check this out, I think it goes down forever. Hey, don't push me!"), and fight monsters together ("Lookout, Zombie!"). Or my son runs away from monsters while I fight them. Except Creepers. We both run from Creepers and fill them full of arrows from a distance.

Good times, man. Good times.

"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.

In fact, as we speak (so to speak), I (sorta) have no UFOs. This must be remedied.

I call this a teaser because... I don't have pics, but I promised you an update, didn't I?

Last night, I completed The Hat. The Hat is the first project I started in this round of knitting... four years previous, I knit a chunky scarf. During the knitting of The Hat, I completed the Rainbow Hat (seen earlier, to match the scarf), the Inappropriate Yarn Hairband, and one Giant Boot (of Indoor Felted Boot KAL fame). (KAL = "Knit ALong", remember?) During all this time, I have started completely over on the hat twice... I think I've knit enough rows to make the hat twice over. (I'll tell you about all that ordeal when I have pictures. Now I owe you two stories of woe about knitting. With circles and arrows on the back of each one to be used as evidence against me.) The hat has a couple flaws (I was not going to back up twelve rows to fix that mistake when I noticed it), but all in all I'm happy with it. It's warm on my head and just the right weight for wearing in my basement office, which is currently 66 degrees, something of a high point when the space heater isn't on.

Anyway, I'm caught up with this week's knitting on the felted boot (to keep pace (It's a "knit ALONG," get it?) I can't start knitting the next one until next Monday), but I've joined in a Beer Cozy swap... nice little circular work, shouldn't take long, and I figure I'll make at least two or three with different stitch patterns. And somewhere in there, I want to make some fingerless gloves/mittens out of the same yarn I knit The Hat (baby alpaca... nothing like spoiling oneself).

Maybe tomorrow I'll get out the camera and the sun and take some pics of the current projects. (You wouldn't know that I have a dual-light indoor strobe setup. Too dang much trouble to get it out, set stuff up, etc. Soon, I'm going to clear out the other half of my storage-room-turning-office and set up a permanent light tent to shoot this stuff. Then shooting decent pics won't be such an ordeal.)