A short while ago I posted this rant about a incompetent programmers and a good friend posted the following comment:

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 Guild of Incompetent Programmers (GIP) is a group of programmers who are doing it wrong. Even though the GIP as a name, entity or organization is not very well known, most people have encountered one of its members or at least work produced by one of its members. There are a lot of sister organizations like the Guild of Incompetent Designers and the Guild of Database Bullies but for now though, I am just going to talk about the GIP.

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 a new form of markup language that I just invented. It stands for Your Mother’s Fucked Up Home Brew Markup Language. Actually, I only invented the acronym as the credit for the actual language specification goes to the International Guild of Incompetent Programmers.

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.