You say OOP is about hiding mutable state. Isn’t it about encapsulating mutable state? Maybe it’s just a matter of wording – but “hidden”, in my dictionary, means that it’s totally out of reach. Encapsulated state (again, in my dictionary) can be modified, but only through controlled operations.

When I was writing my comment in the rudimentary comment box the text just kept growing and growing. Suddenly, the pink borders of that box began flashing with fluid rainbow color gradients. At that point I realized that I should probably dedicate a new post to this subject.

The Short Answer

If I want to stay inline with mainstream terminology and common wisdom than I should absolutely have used “encapsulated” and in fact, it was exactly the word I was looking for but could not find. Instead, I used the rather blunt “hidden”. It is also absolutely true that often the state that I was talking about is still modified using methods or something like it (I tend to prefer message). However, after pondering this question for a bit, I really think at that point I do meant hidden so let me show just what I’m talking about.

The Long Answer

Just for kicks, let’s see what the general consensus has to say about OOP:

Object-oriented programming (OOP) is a programming paradigm that uses “objects” – data structures consisting of datafields and methods together with their interactions – to design applications and computer programs.

Thank the Lord! There is no mention of class or classes in there. I’ve never edited the global consensus before but if I ever see a mention of one of those words for this particular definition then that’s going to be the first time. For the rest, the definition is just shit. It sounds like something an anthropologist would jot down when he saw a few programming monkeys doing it in the wild.

If I would be to give a redefined definition of what I said in a previous post than it would be something like:

OOP is about programming with objects, only objects and doing it with messages.

But I’m not going to do that. Instead, I’m going to show the following class:

class Operation : IExpression
{
    readonly IEnumerable<IExpression> expressions;

    public Operation(IEnumerable<IExpression> expressions)
    {
        this.expressions = Enforce.NotNull(expressions, "expressions");
    }

    public string Compile(IDictionary<string,object> context)
    {
        return new Sequence(this.expressions).Compile(context);
    }
}

Hopefully that makes some sense. It is just a simple class that resembles something that can be compiled into code. In my case, I’m using it to compile to SQL but the pattern is more generally useful. For me this resembles an acceptable piece of OOP and I would argue that the state is completely hidden. Of course, if I put some expressions in there as a client than I know that they ought to be in there somewhere but that is not the point. If I pass an instance of Operation to someone else then he or she would have absolutely no knowledge of what state that object is carrying. The only thing they can rely on is that it probably knows how to do its job and that it has a Compile method that converts it to a string using a IDictionary<string,object> instance.

Continuing with the human analogy, you generally don’t know what mutable state another human has. You can make some assumptions about it but you can never really know. The only thing you can do is to ask them about it. Even then, they might not want to tell you or in other circumstances they might lie about it so that information is not really something to depend upon. The only thing left to do is to just have them do it and see what they make of it. If you are really insecure about the outcome you can even have multiple people do the same thing concurrently and use the result that suits you most. This solution translates beautifully to software too.

Another problem is that trying to mutate human state – either for better or worse – doesn’t always work. Not everybody likes to learn new things and it also takes a dedicated effort of some form to imprint any kind of paradigm. This is generally annoying but it does mean than an human instance can be easily fed to the next operation. Translated to objects it means that instances should not be forthcoming with regard to mutation of their internal state. In other words, they should offer little opportunity for outside forces to mess with their internal state. In fact, it should be hidden as much as possible because one of the Meticulous Laws tells us that: “The less the internal state of a particular instance resembles the messages it can send, the more useful it is.”

Hide the state! Pull the lever!

Sorry, I just could not help throwing a Dwarf Fortress reference in there (be sure to support the toad if you like it). Somehow though, I feel that hiding the state is on par with the importance of pulling a lever (or not pulling a lever for that matter) in Dwarf Fortress. The future of the fort or in our case, the code depends on it. Hiding stuff is important.

For me, one of the big problems with encapsulation is that I’m now seeing shit like this:

class Expression
{
    IList<IExpression> expressions = new List<IExpression>();

    public IList<IExpression> Expressions
    {
        get
        {
            return this.expressions;
        }
        set
        {
            this.expressions = value;
        }
    }
}

There is usually some other class involved to do the probing of the internal state using the convenient (but wrong) external access methods. And I’m still being nice, usually, the fuckers don’t even bother to include properties and/or to adhere to the C# style conventions. They usually write a bunch of nonsense Javafart or VBShit (or something like that). Usually, this code consists of an humongous amount of getThisMotherfucker or setThatMotherfucker methods that don’t have anything to do with OOP or encapsulating state for that matter. Let alone hiding state. For most, encapsulation means wrapping it with yet another class with absolutely no behavior defined at all. It’s just a bunch of getters and setters passing values all over the place. For me, “encapsulation” is somewhat on par with “data structures consisting of datafields and methods together with their interactions” (from the general consensus definition for OOP). I don’t like it because it’s not strong enough. People are easy to get the wrong impression and thus make a mayor fuckupage of the code.

Functional, OOP and Prototyping

There is this interesting dual between FP (functional programming) and OOP. In FP it is all about data. First, analyze the data, then model the data and then start to build your awesome functional library on top of data. When a new operation on the data is requested you are able to smack that bitch in no time but if the data changes, you are fucked because you more than likely have to change a lot of your function definitions. Now look at OOP. You are analyzing the data, modeling the data and then start to build your awesome objects on top of that data. When a new piece of data is added there is no problem, you stuff that in some class, somewhere. However, whenever you a new operation is requested your’re fucked because you suddenly got to traverse your well defined hierarchies of classes to facilitate for this new functionality. To me, the dualism in this is striking and it actually affects the way you have to think.

After a lot of fail, I found out that there is usually absolutely no need for class hierarchies. Just forget them. If you just consider an object a little piece of functional (immutable) data with accompanying operations then you’re all set. The only time you need to think about classes proper is when you are refactoring duplicate code. Sometimes, an abstract class here or there can do wonders for your code base. Otherwise, there’s little use for them – use interfaces instead. There is also a lot more in common between functional and object oriented programming than might be apparent at first sight.

For me, the only real OO programming language is Smalltalk. It is not just because of the OO optimized syntax but mainly about the fact that it is objects all the way down. Everything, literally everything is an object. Down to the lowest bits of code, everything is an object and everything is done with messages. And even when you’ve hit the bottom, it goes even further because the specifications to Smalltalk (aka “The Blue Book”) are written in Smalltalk too! Unfortunately it’s very niche but it still remains as an excellent study object. A lot of techniques are applicable to more pragmatic programming environments and the inner workings of the Smalltalk machine itself are well described in the Blue Book and worth studying and/or trying out in your environment of choice.

I’m practical though and consider C# a very reasonable compromise. With C# 3.0, a lot of work was done to move C# into the functional slice and with 4.0 we get to enjoy the dynamic slice of the cake as well. That said though, why I am I even ranting about this obtuse Smalltalk in the first place? Well, it mainly has to do with cloning or copying objects to generate new variations. Another thing that one might notice if he or she would browse the Smalltalk code is that there are a lot of operations but not a whole lot of getters and setters. In fact (and not only in Smalltalk), classes really do tend to hide their state rather than just encapsulate it. A lot of classes that actually do something useful accept a few parameters in their constructor or factory messages and offer a range of operational messages in return. Usually, the actual state that is used or stored isn’t clear and it really doesn’t matter because everything useful can be done with operational messages. By this, I mean messages that actually do something useful with the matter at hand instead of bluntly returning the value that is stored inside. Of course you’ll find some getting and setting but these are never important for that actual problem at hand and usually have to do with a more user friendly way of initializing the orchestra you’re directing.

So WTF Is The Point?

I know there is not really a point in the rant so far. I’ve babbled somewhat about functional and object oriented programming but what am I really trying to say? Well, it’s actually very simple:

Mutable state is the spawn of the devil

Mutable state really is evil and more importantly: often unnecessary.

Programming without mutable state is bliss and this is where functional programming comes in. This school of thought has always avoided mutable state and global state (very evil this! beware of danger!) and they might be able to learn us some things. Not least on how to actually get anything useful done with this style of programming.

IMHO, you really need to understand a bit about FP to do decent OOP but especially in the future. Nowadays, programmers can still be somewhat lazy and don’t worry about multi core processing too much but in the future this will simply be not possible anymore. If you insist to write your code in an imperative matter, utilizing mutable global or even local state all over the place, then you will have a hard time adapting to the new paradigm. Functional code (without side-effects) is the future. Microsoft is slowly adapting its community by introducing facades in the form of Linq, Parallel Extensions, Reactive Extensions and maybe even F# itself. By way of these, developers are slowly eased into more functional programming styles without even having a clue. Java has had Scala for a long time and I know that were I programming in a Java oriented environment, this would be one of my favorite puppies.

Learning a bit of functional programming WILL (and I don’t like to shout) make you a better programmer

Wrapping up

I can endlessly continue with this stuff but the long answer is getting long enough. In the end I’m getting more and more convinced that I really meant hidden (versus encapsulated) in the first place even though in that particular post, “encapsulated” would probably have been better. There is nothing inherently wrong with exposing the state to be modified by external sources using a logical operation or some other means of encapsulation as long as it is perfectly clear that state is modified. I like it better though when objects expose better and improved objects with new state and characteristics by themselves without me having to mutilate their state. I also like to use objects as seeds for new objects but maybe that’s just me.

With the fast garbage collectors that we have today, I’m fighting for more mapping and less mutilation. I’d rather have a new fresh copy of some kind of object with my desired properties than the same object with some kind of internal state mutilated according to my wishes. When I get a fresh object I’m free to do whatever I what with it. When I get the same object modified, some other motherfucking object might be hanging on to it causing all kinds of strange things to blow up whenever I try to do something remotely interesting with my latest toy. It also explains why I’m totally in love with IEnumerable. It’s powerful yet it doesn’t allow for people to easily screw up.

In OOP, imperative programming and mutable state remain important and allow us to do useful and powerful things but they should be the exception rather than the norm.

The members of the GIP can be summarized with the following qualities:

• big design up front (BDUF)
• can only do it imperatively and love global state
• do not use the right tool for the job
• think OOP is all about classes
• solution over problem
• are clueless about our field
• shy away from learning
• cannot use anything but the shredder

The GIP as a whole is a group of developers and programmers who enjoy in reinventing the wheel over and over for every problem they face. It might be any combination of sheer obliviousness and/or an angst for new things and threading on unfamiliar territory. Or it might be something else altogether. Anyway, they are doing it wrong and because of this they cause themselves and the rest of the world a lot of problems in the process.

Big Design Until Fail

Big Design Up Front (BDUF) is a software fail of global proportions. This probably means that global economy is involved as well so it’s not a particularly small problem. What amazes me is that I still see cool young people trying to do BDUF when they are fresh out of college (or still learning) but this probably means that a large part of the teaching staff are members of the GIP too. Another explanation might be that these people are so afraid of the actual typing in of code that they try to create a sort of a safety net: if the actual coding fails they will at least have the big design to show for their efforts.

BDUF fails because it is part of some bureaucratic dance that is performed to make one or more people that have absolutely nothing to do with actual development happy. Another way of saying this is that BDUF is just a waste of time. The actual big design is unfortunately useless once you’re ready to start coding. Although, to be fair, on rare occasions it will hold until the first customer review.

To be clear: there is absolutely nothing wrong with doing design or trying to get to know a problem domain with some other means than code. Things just get ugly when solutions are designed with some other means than code. It’s comparable to the idea of building and assembling every component of the metaphorical bridge (on site) 1:1 before building the actual bridge. No engineer in his right mind would even consider this.

Important!

Note that I’m not comparing the actual craft to building a bridge. This would be like saying that writing a book is like building a bridge. Although it would be an interesting philosophical discussion to investigate how far these do align it think most people would agree that writing a book is somewhat like writing a song but nothing like how we actually construct a building or distribute the song. For now though, I am going to leave the rabbit hole of software development metaphors for later and continue with the rant.

The Imperative Way

It is not that everybody is doing it. Imperative programming is sometimes required, frequently handy and also sometimes the clearest way to express a solution. Imperative programming in itself is not necessarily bad or wrong but the unwillingness of some people to look into these other paradigms is striking and almost offending. Often, this is exactly the same group of people that just love the global state container, write their stuff in 600+ line of code chunks and feel strangely comfortable when there is a list of 100+ global variable declarations on top of their module, class or whatever top level their using. Unfortunately though, these people are also completely unaware of the impact and consequences that making heavy use of global mutable state (and also local mutable state) may have:

• threading issues (requires locking)
• hard to trace bugs (requires debugging and stepping)
• hard to (automatically) test
• poor orthogonality
• readability most likely suffers

Threading issues and hard to trace bugs make the code hard to scale and maintain. Setting up the code base in such a way that lots of mutable state is involved usually implies that testing stuff in isolation quickly becomes difficult or at least very annoying. This in turn often leads to poor orthogonality and an overall poor design which will quickly evolve to a monolithic piece of code that no sane person would like to work on. On top op that, it will also have lot of broken windows all over the place. Now imagine a gigantic pile of shit, which is somewhat the same. Would you like to work on that?

A Rock and a Stick

A lot of this is in a separate post but as it also has to do with the unwillingness to learn and the unawareness of those that came before us (history of our field) a few things can still be said. One of the things that I have trouble comprehending is why someone would not be interested in learning about technology, concepts and ideas that are relevant to his or her field of experience. If you can tell me your ideas about games or movies, why can you not tell me the equivalent about the field of your profession? This is the knowledge and experience gathered throughout the times that actually enables us to make our living. More and more of that knowledge becomes available everyday and is should be readily accessible for everyone (and that means everyone).

Nobody can be expected to know everything but you should be able to formulate what interests you in your field of profession. Who are your heroes? What are you experimenting with? Who do you admire? What magazines or blogs do you read or who’s feeds are you subscribed to? (feeds? what’s a feed? you’re a feed!) Most of the people have not even considered these questions for themselves so there is no reason why they would have an answer. So with a blank stare and thoughts about food or females they continue on their merry way. Rock and stick at the ready.

OOP: Look Ma – No Classes!

Once upon a time, I thought I could handle the big stuff. I was a rock and stick programmer who mastered the rock as well as the stick. But, I was insecure. Until now, on a small scale, my simple creations turned out reasonable well. Yet, how do these really big programs and systems work. How can they work? How can someone develop and maintain them with a team of people? How can some actually reason about them without resorting to a bunch of code?

Then, I found a job pretty much in my technological hot spot of that time and proudly went out with my polished rock and stick for an interview. I was excited to get the job but quickly found that the simple rock and stick that my education thought me to use so well were not very useful for constructing solutions to real-life problems. Also, I found that the guidelines on how to construct blueprints for the things I was to build were not really applicable. I really tried and my first project went actually pretty well but that was only because I was the only one working on that with full control over everything that went on with it. Doing a little bit of work after-hours was an easy way to pull stuff right back on track and way in front of the schedule. Even if it meant sucking up bad decisions made a few weeks earlier.

So, what does all this stuff have to do with Object Oriented Programming? Well, it was exactly during that time that I found there was something lacking with the whole concept. Of course, I was thought everything about class, interface, override, static, private, virtual and a whole host of other useless stuff and also all the shit about polymorphism and that other important concept that I always forget about (just call it polyotherfuckism, it does not matter). I knew all that religious shit by the letter but eventually found out that none of it really matters. It’s all just shit. Forget, all those fucking keywords. You know what OOP stands for right? Object Oriented Programming. That means programming with fucking objects. Who the fuck would have thought that huh?

For a while I’ve been trying to convince my colleagues that OOP is about objects rather than classes but somehow that shit does not sink in very well. They always come up with contrived class hierarchies involving animals or vehicles but unfortunately not one of my projects involved those kinds of entities or such a perfect mapping from example to real-life. Strangely enough, nobody ever turns up with the human analogy even though that one makes the most sense. It just proves that these people do not understand the fundamentals principle to OOP:

Hide mutable state in objects (and everything is an object)

You see, that is not too hard. Just hide the fucking state. Make sure that nobody is mutilating something that is not his or her own. Actually, the part in brackets is the real definition but unfortunately that is too vague for the people who are the target of this rant. To them, I can offer the following consideration to make it extra clear. How would you feel if I asked you: “can I chew on your fingers for a while please?”

A lot of object oriented programming languages do not even have classes to begin with. Instead, you just define an object globally that has the properties for a large group of other objects and clone that mother fucker for each new instance that is required in a local scope. It is much more to the how nature works which has mothers (mutual parents) and local variations (trapped in a scope like a valley, mountain top or cave. These are prototype based languages. Sometimes though, it is possible to affect all clones of some object even after they have been instantiated (like in current JavaScript) but while quite powerful, it allows people to easily construct their favorite class based inheritance adapters on top of the language thereby foregoing the much more powerful and arguably more natural prototyping. This is like adding Asian treats to Caucasian Europeans after they are born. A powerful, strange and dangerous concept indeed.

Object oriented programming is not about classes. It is about objects and hiding mutable state within objects to send around as packages to some other part of the system. Objects should not go about mutilating other objects. Instead, they should offer a set of operations that either are safe to call every time you feel like it but ideally offer some kind of mutated version of the truth that cannot be changed but can be used to create a new future truth. Classes have nothing to do with OOP and everything to do with code re-use. Prototyping is king and interfaces rule. Favor composition over inheritance and for the love of God, please forget class hierarchies.

Don’t tell me what to do!

If you want something, say what you want. Do not tell me how to make it or you will regret it later and try to blame it on me. It’s that easy. To stick in another fucking analogy: if my car makes a stupid noise I go the garage and say: “get rid of that fucking noise.” I do not say: “change this part and that part and maybe that part and then check that and then also that that motherfucking other piece of shit that’s supposed to be working in tandem with that other piece of crap…”.

I do not tell them what to do. I tell them what the outcome should be and let them figure out the path to arrive there. And this shit is true not just for people, it also holds up when your coding. Treat objects like people. Make them responsible for their tasks and depend on them to do the right thing. You’re the orchestrator making stuff dance or perform to your will. Don’t try to be the dictator.

If you are someone in charge of managing developers please know that we are only here to please you. But please tell me what you want, not how want to have it done. Otherwise, hire some monkeys.

YMFUHBML is designed to fuck up your mind and your XML parsing techniques. Whether your using XmlReader, XmlDocument or some other standards based solution, YMFUHBML is guaranteed to break it because, believe it or not, in one document it manages to break two important rules that are associated with real XML documents (there might be more discrepancies but these two annoy me the most):

• XML documents should have a single root node
• Attributes consist of name-value pairs

Not too hard now is it? I though so too but apparently some people (like the designer of YMFUHBML) even manage to screw this simple stuff. Take a look at the following horror which resembles a response message that I had to accept a while ago:

<status>ok</status>
<message>the request has been successfully received</message>
<file file.001>
foo
bar
quux
</file>
<file file.002>
baz
</file>

And yes, those are the complete contents of the response I get. Now to be honest, parsing this is not hard but my pet peeve is with the fact that some people who should know better mistakenly think this is XML when it is actually YMFUHBML. Where the single root node we all know and love? And what the fuck is that file stuff supposed to be?

If you’re not going to adhere to what XML is supposed to be then why the fuck are you using those motherfucking tags to add structure? Please, stop doing stuff like this that because it is wrong and gives the impression that you are a business developer who maybe should consider moving to another field of profession.

XML is so simple yet every time I hear that someone is going to give me some XML to consume I get YMFUHBML instead. In the end it all boils down to common problems like people reinventing the wheel and not using the right tool for the job which is causing a lot of unnecessary friction and annoyance.

Programmers in Disguise

If you consider yourself a programmer (maybe even a good programmer) then consider this: how many of the great people in our field do you actually know? For example, do you know who Jim Gray was? Alan Kay or Adele Goldberg perhaps? Martin Fowler? Edsger Dijkstra maybe? Yukihiro Matsumoto a.k.a. Matz? Why the Lucky Stiff? Guido van Rossum? Simon Peyton Jones? Alonzo Church? John Backus? Anders Hejlsberg? Not to mention a whole host of other giants. Most of them still active today. Note that I was about to link all those people to their respective pages but that was just starting to look like a giant search engine lure. If you really want to know more about them then I recommend Google videos. You’re abound to find some other interesting links too to start your research with.

Who doesn’t know about Douglas Engelbart with the Mother of all Demos in 1968!. Shame on you if you have not seen this before.

Some of the people I talk to and that pretend to be programmers haven’t even heard of these people. Now, that’s not too bad in itself. Knowing these guys doesn’t make you a better programmer but it does show something about the passion you have for the field that you are working in. It’s not whether you know them or not – it is about the desire you have to learn about them (you can abstract this to it’s not whether you know [A; B; n] or not – it’s about your desire to learn about [A; B; n]). Most of the times, they just shrug their shoulders and off they are, on their merry if-while-case away.

Often, I encounter this attitude with business people who know a little bit about programming. Maybe they programmed a VB app in the 90′s or maybe they know either the SQL Query Designer or (everyones favorite) FrontPage just a little bit too well. Sprinkle that with a suit and smooth talking skills and you have yourselves a business programmer. Usually, these guys are living in an ancient world where only while, if statements and global state seem to exist. The unfortunate fact is that they somehow seem to be able to get things done without any respect for the art (or craft if you insist). I can only use the words of Prince (as I ironically like to call him) when I say that those dudes still party like it it’s 1999. In fact, it’s even slightly worse but unfortunately that’s the best I can come up with so I’m being lenient.

A lot of times, these are the same guys that breed giganormous if-trees of loop, more if, while, more loop, case (we’re talking some serious VB here), even more while, more if, even some more if, another while, yet another while, yet even more if and then another case for good measure all in some humongous monster of donkey eating, steel shitting angry pile of smelly thing that those dudes like to call Sub.

Sometimes they even dare to call it a Function but at this point it doesn’t even matter anymore. You could just as well call it SmellyPileOfCrap Foo and nobody would even care. It would not even be that bad but the worst part is that all of this is copied meticulously over from another +6000 line method that does exactly the same as the other one except for one or two lines that are apparently not worthy enough to be duplicated. But then again, things only get really interesting when you find the same pile of crap duplicated across a bunch of other piles of shit. It’s like finding a cake of shit with other kind of shit sprinkled on top and then finding that same cake four or five times more in unsuspected places all scattered in something that resembles your house. It’s all one big fantastic crapfestaciacious vision of crapunholiness.

Just Being Pragmatic

Oh my sweet Jesus, do I like to talk about being pragmatic? Hell yes! See, you weren’t expecting for me to answer that question did you? You just assumed I was asking one of those fancy so called rhetorical questions? Well let me tell you sonny: assumption is the mother of all fuck-ups! And yes, I am aware that this quote is from an incredibly bad movie.

Still though, there is something magical about being pragmatic. Just look at the fucking definition that Google gives us:

pragmatic
A pragmatic way of dealing with something is based on practical considerations, rather than theoretical ones.
A pragmatic person deals with things in a practical way.

You know those agile guys? They are being pragmatic. You know what? Those functional guys? They are being pragmatic too. Just in a crazy mathematical kind of way. Those Ruby guys? Pragmatic. Python? Pragmatic. Lisp fanatics? Pragmatic. Unix kernel hackers? Pragmatic. The absolutely waziliously huge PHP community? Just being pragmatic (well maybe not all of them).

Looking at the definition, that sounds like something a business person would love. It even goes so far as to tell us that a pragmatic person deals with problems “based on practical considerations, rather than theoretical ones“. Now what’s not to like about that from a business perspective? In reality though it means a bunch of so called coding craftsmen working their ass off with the simple tools they have. From my perspective, it’s like watching a bunch of cavemen trying to rebuild the Twin Towers with a rock and a stick. The only unfortunate part that I am one of those cavemen.

So apparently, at least from this perspective, being pragmatic means behaving like a software cavemen and treat everything with familiar tools: a rock and a a stick. Or respectively, in our case, a while. and an if. The sad conclusion is that most of the industry is either not doing it or we are doing it wrong.

Those business people should like being pragmatic too but unfortunately they don’t think being agile is cool. They also don’t like someone hacking on their precious code. I can’t tell them a piece of code is shit anymore. I have to tell them that it is not exactly what I would’ve written. Even if the piece of code is something I wrote myself a few weeks earlier. They like guys who are being pragmatical by throwing a bunch of copied while and if loops at a problem until the problem seems to be solved. Then, when a few weeks later the issue regresses it is registered as new and solved by throwing yet another rock and stick, doing the lucky dance and hoping that no new bugs crop up.

The powers that be once told me to implement a look-ahead search for one of our websites. Unfortunately, the look-ahead would need to function with a particularly awkward set of columns and I knew this wasn’t going to happen with our current setup. First, I tried to convince them to building a set of indices for that particular set of columns so we could get to the results more efficiently. The fact that stuff would not be real time was just too much. Then, I tried asking for more raw power but in the end, the reply I got was a casual: “Google can do it too, so we can too”. Now that is being pragmatic I tell ya. Those so called pragmatic guys I mentioned before should take a page from his book and just take a look at Google.

Bonus

In fact, there’s another useful abstraction that I think of now that I’m writing this. If you are wondering whether some [A; B; n] is the right thing to do, ask yourself this: what if everyone did [A; B; n]? If the outcome is a positive vision then its probably the right thing to do.

In other news, a big post is coming up soon. I just don’t know about what it is going to be yet.

Over the course of last year, the amount of games and the time I played that console grew larger and larger and now it’s definitely the most played console in my house. At least, until three minutes past five yesterday. After spending the last few days achievement hunting together with my brother we managed to unlock the infamous red ring of death.

Before that, I was hoping (but never fully confident) that my Xbox would be devoid of any problems. Sadly, I was wrong and it seems that the buzz around the failure rate of Microsoft’s console is not entirely unjustified.

The good news is that I can send it back to Microsoft for repairs for free. The bad news is that repairs will take two to three weeks and I’ll be damned if my two days old copy of GH5 has to gather dust for all that time.

So this afternoon, my brother will pickup a new Xbox and we will just transfer the HD from the broken one as it has to be removed before sending it anyway. In the end this means that we will have two Xboxes but that’s not a problem. We’ll just put one at my parents house and use that for backup in case the new one decides to bail out too.

And the good stuff doesn’t stop there because they also released this awesome music video! Always a sucker for these upbeat dance tracks I really dig it and somehow find the slow-mo editing (or whatever they call that) strangely exciting. By the way, this effect looks especially great on the background layer with Tinkerballa (Amy Okuda) who is mesmerizing even when she is not dancing so hot.

$(document).ready(function() {
  $('.with-default').focus(function() {
    if($(this).val() == $(this).attr('default')) {
      $(this).val('').removeClass('with-default');
    }
  }).blur(function() {
    if($(this).val() == '') {
      $(this).val($(this).attr('default')).addClass('with-default');
    }
  });
});

Now fingers crossed that it works…

First, the guitar. After playing maybe a total of four or five hours, the day after the game arrived, the strum button started making this horrible and annoying squeaking sound. Sometimes it seems to quiet down only to get really annoying again half a minute later. It is still usuable but I have to turn up the volume of my sound system pretty high in order to not get distracted by the squeaking. It is worst when alternate strumming which is unfortunate because I really drove myself to perfect the technique whilst playing GH3.

Next up is the drum kit. After reading about (but luckely not encountering) the problems with the RB drum kit I had pretty high expectations of the GHWT drum kit. Turns out these where misplaced. It looks and feels great (especially the sound and bounce on the pads) and works beautifully with Rock Band. However, after exactly one week, during “The Hand that Feeds” (on RB, using the GHWT kit) the green drum pad stopped working completely. At first I thought it might be just a temporary glitch so I tried with the GHWT disc but (not surprisingly) the green pad still wasn’t working. 

So now I am not happy at all (and that is putting it mildly). The guitar controller is so annyoing it is almost unplayable and the drum kit is so broken that it is unplayable. But not only that, I also loose a good deal of my spare time dealing with support and sending the stuff back. This is what annoys me the most of all because that should’ve been time playing the game.

Ah well, fortunately though the Rock Band instruments are still working perfectly (even the flimsy kick pedal is still going strong) which is admittely not something that I expected a while ago when I first started playing. Now I can only hope for the same kind of luck with the Rock Band 2 controllers – if that game ever arrives in Europe that is.