Latest articles

V12s And The 640k Show Horse

"I've been commissioned to design a roadway for the city, and I've come up with a great design! It assumes that everyone has V12 cars...But come on, V12s have been around forever. Isn't it way past time that all those 4-cylinder owners finally upgraded? I'll be dammed if I'm going to compromise my wonderful design and take slightly more development time just to cater to the few people still living in the stone age."

Hypothetical, obviously. But it demonstrates exactly why programmers who trot out the "640k should be enough for everyone" show horse to defend their consumer-whoreism approach to development piss me off. (Well, that, and the fact that Gates never actually said it.)

I'll certainly grant that there are legitimate uses for 64-bit and multi-core. But this whole attitude of "Something that doesn't emit 64-bit is useless" and such has gotten ridiculously out of hand. Most people and programs don't need 64-bit or multi-core. Sure, a few do. And sure, many things can be better with 64-bit or multi-core - but they don't fucking need it. The notion that they do is a load of high-octane V12 bullshit.

This is the point where I inevitably get a bunch of crap about "But that's all the stores sell!" So what? Is that all that's in common use? Of course not. I don't know about you, but I develop for the hardware that people have, not hardware they might get if and when they decide to go buy something new (nevermind the second-hand eBay...maybe you've heard of it?). And when I optimize something to run well on the lower-end, guess what? It'll still run even better on the V12s. Even moreso since mine isn't one of the inevitably three or more programs on the user's system that all simultaneously believe their optimizations can rely on having at least of couple cores to their self.

And of course there's embedded software. You know, that stuff that the self-centered "waste loads of resources, because my time is more important" programmers always seem to forget exists. Embedded 32-bit and/or single-core devices are going to be around for quite awhile longer. Even the ones that don't stay 32-bit or single-core are still typically going to lag behind desktops, laptops and servers. Even aside from that, there's still power drainage and battery life. All of which leads me to another reason for software developers to cut the consumer-whore crap:

True story: A certain OS developer kept making each version more bloated than the last. They did it because they were Moore-worshipers, plus the bloat led to more hardware sales, which 90% of the time, were pre-packaged with their OS. Then they continued that with OS "Big Panoramic View 6" which completely fucked up their ability to compete in the emerging netbook and tablet markets: Ie, devices which were, guess what? Low-powered! Ah ha ha! Stupid fucks. So...are you behaving like Microsoft?

Read more

Newsflash: "Whenever the hell I get around to it" means "3 years"

Well, I've gotten the hell around to it. Whee!

I've moved this not-a-blog from to my own web space. And I've switched from WordPress to TangoCMS in the process. Also, comments are back on ("Whee!" again). is a great site. I have nothing against it. The reasons I moved this away, though, are (most important to least important):

  1. I've had very little time for homebrew lately, and consequently, most of my posts have nothing to do with homebrew. So I felt it was inappropriate and inconsiderate for me to keep this site hosted there.
  2. I wanted to re-enable comments, but require CAPTCHA for it.
  3. I don't particularly like WordPress.

I'll probably be posting more frequently again now. I had been avoiding making posts for awhile because of #1 above. (Triple "whee"?)

Read more

Star Trek 2009/XI/Crappy-Non-Googleable-Name First Impressions

Originally posted: May 9th, 2009

Just what the internet needs, another random Joe's worthless opinion on it:

(Disclaimer: I've always liked Star Trek, fuck, I even liked the animated series. So it's not like I'm a trek-hater that, unsurprisingly, hated it.)

Saw the first two scenes. Roughly ten minutes. That's it. That's all I could actually take.

First Scene: Worst directing and camera work in movie/film/television history. Seriously. Words like that get tossed around a lot. But I really, truly mean it. In fact, I can actually say that the old Hana Barbara cartoons had better directing without resorting to hyperbole. I can't believe I can say that, but it's true.

Even Paul Greengrass (Of The Bourne Supremacy/Ultimatum Butchering) knows how to properly frame up a subject. People hate Michael Bay, but he can do it too. Hell, even Uwe Boll can fucking do it. But somehow JJ Abrams can't. Instead, he sets up the absolute worst shots humanly possible (this, in addition to the same paint-mixer-as-a-tripod-syndrome Greengrass suffers from), does it all deliberately, and still tries to call himself a director. What the hell is going on at Paramount that this guy has managed to secure a job?

Second Scene: BAM! Product placement in the face! In Star Trek. Yes, that's right. Product Star Trek. And you thought Minority Report was fiction. Take a good guess what company I'm never buying a phone from...

Icing On The Shit Cake: Granted: I love "Sabotage". Question: What the fuck is it doing in Star Trek?

Read more

This is what years of web-development and tax-season stress have done to me...

Originally posted: April 14th, 2009

After falling into a lake 5 miles southeast of the much more well-known Jusenkyo spring, I now turn into a foul-mouthed anthropomorphic walnut every time I get splashed with a three-week-old coffee/martini blend that was mixed by a near-sighted ambidextrous midget wearing a striped goatskin bikini and chanting "I'd like to see a ferret on THAT" in Swahili. Needless to say, this happens CONSTANTLY, and I'm frankly growing quite tired of it.

Read more

Code Snippets Vs DRY

2010.10.24: Update: Umm, yea, so turns out Haxe does have a much simpler syntax if you just need a default getter/setter. Didn't realize that when I wrote this. But I do still think people should be careful not to let code snippet support become a substitute for proper DRY.

Originally posted: March 25th, 2009

Code snippet support in an editor can be very useful, but it does seem to carry a certain risk of discouraging advancements in DRY practices. For example, I was just working on a Haxe class (I refuse to use the goofy "haXe" capitalization) that has 14 (and that number is growing) accessors like this:

private var _assetBaseUrl:String;
public var assetBaseUrl(get_assetBaseUrl, null):String;
private function get_assetBaseUrl():String
    return _assetBaseUrl;

Might not seem like much to someone who's accustomed to Haxe, but that's an enormous amount of code just for a single privately-writable, publically-read-only member variable (For the record, Haxe has the ugliest, most verbose accessor definition syntax I've ever seen). Considering I have 14 of these (so far), just in this one class alone, that's a lot of mess.

Of course, this is where the code snippet users come in and say "Just use a code snippet!". I don't know for certain, of course, but I can't help suspect that the existence of code snippets is part of why Haxe's creators allowed the accessor syntax to be so verbose in the first place. And considering that most of those differ only by name and type, well shit, so much for the idea of "Don't Repeat Yourself"!

Contrast that with the same code in C#:

private String _assetBaseUrl;
public String assetBaseUrl()
    get { return _assetBaseUrl; }

Or better yet, D programming language:

// getter is defined in a utility module I wrote
mixin(getter!(char[], "assetBaseUrl"));

And holy crap, all of a sudden we have actual DRY!

Problem is, code snippets tend to get used as an excuse to ignore DRY (it's really only about one small step above outright copy-and-paste coding). If the early programmers used editors with code snippet support, we probably wouldn't even have functions today.

Of course, I'm not suggesting that we get rid of code snippets, or stop using them. We just shouldn't be considering them a proper substitute for real DRY.

Read more

Putting the "Engineering" back into "Software Engineering"

Originally posted: September 16th, 2008

(I wrote this a while ago, but didn't post it for some reason. So I'm posting it now.)

I've been very vocal about my distaste towards many of the features of various dynamic programming languages (at least for the purposes of any non-trivial program). Recently, while reading the first chapter of "Practical Cryptography" (by Niels Ferguson and Bruce Schneier), it occurred to me that authors' explanation of "The Evils of Performance" was very relevant to my opinions of these languages.

In that first chapter, the authors stress the importance of security being made the single top priority. They make this point by looking at security as an engineering discipline. As they point out, good engineering has always been about making safety and reliability the primary concerns. No other concern should ever be optimized to a point where it could interfere with safety or reliability.

The authors go on stating that, in the same way, the computer industry needs to prioritize security far ahead of efficiency. To illustrate, they present the explanation: "We already have enough fast, insecure systems. We don't need another one."

I'd argue that in computer programing, reliability deserves a similar status ahead of efficiency. Just as in other forms of engineering though, this doesn't just mean placing reliability ahead of the actual product's efficiency. This also means placing it ahead of the efficiency of the development process itself. We already have enough unreliable software being churned out.

Which brings me back to dynamic programming languages: The reason I so strongly dislike many (albeit, not all) of the characteristics of these languages is because they treat short-term programmer productivity as a holy grail (sometimes even stating it as the single primary goal), while allowing good engineering principles like reliability to fall by the wayside. The real irony, though, is that maintaining an unreliable program is itself a drain on programmer productivity, thus hijacking any long-term productivity gains. So for any non-trivial project, these languages would have been more productivity-friendly by going the engineering route and making design decisions that focused on aiding the creation of reliable software at a reasonable speed rather than potentially buggy software at rapid speeds.

Read more