I wanted to make a totally off-of-normal-topics entry regarding what I consider to be the greatest television show of all time.

It just so happens there is a very aptly timed xkcd sort of on the same topic (at least the “I can kill you with my brain” part).

Carly and I have been watching the first (only) season on DVD again, and each and every episode has me bursting forth with some form of “MAN! This is the best TV show EVER!” or another.

It continues to amaze me that Fox pulled this off the air, I’m pretty sure that THAT was a crime against humanity.

Sigh.

Avdi Grim has begun a thought-provoking series surrounding the idea of sustainable software development – specifically targeting Ruby as an example.

With some of the recent discussion surrounding “monkey patching” in Ruby, I think that the timing seems about right, for some serious thought to be given about the long-term effects of maintaining Ruby-based code-bases, should prolific “monkey patching” continue to be used haphazardly by many of the libraries, plugins, gems and other code that makes (sometimes critical?) modifications to the underlying core language classes.

Nick Sieger has crafted a thoughtful response to Avdi, which includes the quote:

[Monkey patching is] still a basic part of the Ruby programming culture, like it or not.

While Nick is totally correct, and Ruby does give you the power to shoot, maim and otherwise pillage and murder yourself in a bazillion different ways – that doesn’t take away the fact that it is still an incredibly powerful, elegant and syntactically beautiful programming language.

At the risk of sounding like a trite broken record (for the 485,000 time), I think that once again it boils down to using and choosing the right tools for the job. If the consequences of Ruby’s dynamism (among whatever other consequences) outweigh the positive benefits that a Ruby solution provides – then choose a different tool.

You can complain about the verbosity of a language like Java all you want (heck, I know I do at times), but I come back to Java sometimes after working with Ruby for a few months, and I’m all of a sudden thankful for strict, static typing, always knowing what I’m gonna get.

What continues to irk me are the folks who seem completely hell-bent that their way is the only One True Way™.

I was in a job interview the other day (company name shall be kept confidential) at a place that does extensive software development in many languages including Java, C, C++, Perl and PHP (at the very least). Near the end of the interview, we were discussing different languages, and I mentioned how sometimes I really enjoy the dynamic typing facet of Ruby, as opposed to the statically typed facet of Java. At this statement, one of the interviewers piped up to tell me that the fact that I enjoyed dynamic typing at times was “the most brain-dead thing” he’d ever heard anyone say.

It seems so strange to me, to be on the receiving end of an insult like that, coming from a company that performs extensive development in PHP (which is not only dynamically typed, but also weakly typed, as opposed to Ruby which is strictly typed).

At any rate, all of that comes to some sort of summary that everyone should already know by now:

1. there is no silver bullet
2. think before you choose your tool/language/whatever
3. don’t hate the unknown simply because it’s unknown
4. don’t call someone brain-dead if they sometimes enjoy a programming language that is dynamically typed, it hurts their feelings
5. read Avdi’s series on sustainable development in Ruby.

I’ve just been doing some reading up on some various Java documentation – and came across the list of new language features in Java 5 (yeah – I know, we’re at 6 now).

At any rate, I came across this gem about static imports, copied verbatim from Sun’s online documentation:

So when should you use static import? Very sparingly! Only use it when you’d otherwise be tempted to declare local copies of constants, or to abuse inheritance (the Constant Interface Antipattern). In other words, use it when you require frequent access to static members from one or two classes.

So that begs the question, why bother adding static imports as a core language feature at all, if the documentation basically says (in PR Speak to English, with apologies to John Gruber):

We have wicked awesome new language features including static imports! But FOR THE LOVE OF ALL THINGS GOOD, DON’T USE STATIC IMPORTS, IT WILL TURN YOUR CODE TO SLOPPY CRAP!

Thanks, Sun. Next time, add some language features that we have your blessing to actually utilize.

Note to Sun: I like closures, and if you build them into the language, try doing it using syntax that doesn’t suck (I’m looking at you, generics).

On my way to the airport in Calgary on Sunday, I drove past a billboard for Q9 Networks that said:

Our data center client lists reads like a who’s who of Calgary businesses. Are you in it?

Marketing like this has always bothered me. It makes me want to flip the bird in their general direction, because climbing past the drivel it reads like this:

If you’re not hosting in our data center your company sucks.

Peer pressure for the enterprise. I thought we got past that in tenth grade?

Note to Q9 (this one’s free): Hire better marketing people.

One thing that I love about Seth Godin is his unceasing efforts in trying to make companies see that they need to treat their customers with respect. This is made evident again in a great little piece he wrote about Apple’s $200 iPhone price drop that the mediawenttotown on.

He talks about a bunch of things Apple could have done to make the early adopters “ok” with the fact that they were just out $200. But then he goes on to say:

The key is to not give price protection to early buyers (that’s unsustainable as a business model) but to make them feel more exclusive, not less.

I wish more corporations would take the route of doing everything in their power to make their customers feel respected. To make their customers feel like they have a choice and could take their business elsewhere (even if they can’t take their business elsewhere).