Object Oriented Programming is exceptionally bad

I quote Edsger Dijkstra (1930-2002), a great Dutch programmer and writer:

Object-oriented programming is an exceptionally bad idea which could only have originated in California.

The 3 promises

Object Oriented Programming (OOP) is promising us:

  1. hide implementation details
  2. optimal reuse of code
  3. hiding state, combining code and data

In my experience Object Oriented Programming Languages are no better at #1 and #2 than procedural languages. And #3 may seem logical as we have data and code. This code manipulates the data that should be in a well structured and preferably standardized format. But combining code and data is in my opinion not always a good idea (more on that later).

Accidental obfuscation

Unfortunately these are the characteristics of many OOP code bases I have seen:

  1. hard to learn
  2. many lines of code
  3. low performance

In most cases we do not need IoC, LSP or even SOLID. We don’t need castles built of (Java) classes. We don’t want to read 10 different classes and interfaces to understand often trivial implementations. Programming is hard enough without people accidentally obfuscating what is going on.


Nobody complains about OOP like Zed Shaw in the above video from exactly 17:24. Click the image to play the video from that point (takes about five minutes).

Use. Less. Classes.

While Object Oriented Programming may lead to the characteristics described above, software (developers) should focus on achieving the opposites:

  1. easy to learn
  2. few lines of code
  3. high performance

The world seems to realize this nowadays. We see that new non-OOP languages like Rust and Go are emerging, while established OOP languages like C++ and Ruby are struggling. Also, make sure you watch Jack Diederich “Stop Writing Classes” talk from PyCon 2012:


Definitely a video worth watching.  Click on the image above to start the video.

Where we really take it too far

You may argue Object Oriented has its place in some software niches. But in the database world (administrative applications) it has not. A database record is not an object. Data should not (and can not) be abstracted. Object Relational Mapping and object oriented data API’s are taking OOP way too far.

You cannot make abstractions to anticipate on future (data model) changes. How are you going to abstract missing data? Or added data? Versioning an API is fine, as long as the API is not exposing data. Behavior can be versioned and the versions can co-exist. But versioned contracts on data and it’s structure do not make sense to me.


Mixing code and data is not always a good idea. OOP is based on this idea. Therefor do not apply OOP without some critical thinking first.

Further reading

Much more has been said about OOP and it being a bad idea. These links are in no particular order:

If you feel like learning about this somewhat controversial point-of-view, then I recommend you to read the list above.


David Beazley’s concurrency demo on PyCon 2015

pycon_2015David Beazley did an amazing live demo on Python Concurrency on PyCon 2015 (Montreal, last month). Lucky for us it is available on YouTube! I must say, that once I started watching the video I was hooked! I simply could not stop watching for the entire 45 minutes.

Python concurrency methods and their performance characteristics

In the beginning of the video David types in a Fibonacci socket server and shows the audience how socket programming works. That is already quite impressive (as he talks and types at the same time). Then he evaluates several approaches to Python concurrency: threads, processes, co-routines combined with the select call and finally co-routines combined with the select call and threads.

The performance characteristics of the approaches are shown by running a concurrency test and then a “requests per second” and a “response time in seconds” performance test. David clearly explains which role the GIL plays on the concurrency of co-routines and also where you see the (operating system) overhead caused by threads and processes.

In the questions he says that you should follow the best practices on concurrency and he specifically names “don’t have shared state” and “use functions”. See the talk by clicking on the video below:

Thank you, PyCon 2015, for sharing this video with us!

Best practices and the joy of programming


When I was about 16 years old (1996) I was programming object pascal (Delphi). In that language I wrote a calculator program to convert a number from decimal to binary. While implementing this functionality I found out that I could make this code generic, such that you could give it any base (2 for binary, 8 for octal, 10 for decimal and 16 for hexadecimal) and convert the numbers back and forth. This was an extremely satisfying experience and it felt like I created a thing of beauty, like I discover a secret or maybe as they call it “a programming gem”.

Since nobody uses Delphi anymore (you may want to try Lazarus though), I rewrote the code into Python for any beginner to understand.

def convert_base(s,b,nb):
	# character set
	# function to convert int to string
	def int2str(n,b):
		if n==0: return ''
		return int2str(n // b, b) + c[n % b]
	# function to convert string to int
	def str2int(s,b):
		if s=='': return 0
		return str2int(s[:-1],b) * b + c.index(s[-1:])
	# filter invalid characters
	s = ''.join([k for k in s if k in c[0:b]])
	# convert string and return
	if s=='': s = '0'
	s = int2str(str2int(s,b),nb)
	if s=='': s = '0'
	return s

I can’t imagine anyone will feel the same satisfaction reading this code as I did writing it in 1996. Let me explain why. In 1996 we did not have the Internet yet, or Stack Overflow, where all the programming questions you may dream of are already asked. You would typically learn everything from books, both the how and the why, and you could not cut corners by Googling the answer. So there was no guarantee, unlike now, that with proper research you find the most “Pythonic” implementation.

You could even turn this around. Nowadays we know so good how things “should” be done, that there is little room for innovation. If you come up with a different approach to a known problem it quickly dismissed as “wrong” and “not a best practice”. On one hand this may be a sign that the software industry is maturing. On the other hand it may be crippling, because we now have generation of programmers who have no clue why things are the way they are. They can’t argue the motives of their choices any further than it being a “best practice”.

I can think of plenty examples, but the most striking is when I was implementing “default routing” in Symfony2. It is considered a “bad practice” by the Symfony author, hence removed in the second version (and I implemented it again). Hardly any programmer I’ve met can properly argue why it makes sense that it was removed (but they all tend to have an opinion). I guess that proves the point.

How to win a senior programmer job interview

This post will give you 3 advices that will help you to win any job interview for a senior programmer position. It does not matter that you can’t program when asked during the interview, just follow these simple advices and you are one step closer to being a rockstar software developer earning big bucks!

Advice 1: Learn the Fizzbuzz answer

Most interviewers ask the same question to measure programming skills: program Fizzbuzz. It is a very popular, but extremely tricky assignment that even the most skilled programmers fail at. Just learn the code in the required language by hearth and you will fool any interviewer. Note that you really don’t have to understand the code as the explanation of what the code does is given in the assignment.

Java implementation (Fizzbuzz)

public class FizzBuzz {
	public static void main(String[] args) {
		for (int i = 1; i <= 100; i++) {
			if (i % 15 == 0) {
			} else if (i % 3 == 0) {
			} else if (i % 5 == 0) {
			} else {

PHP implementation (Fizzbuzz)

for ($i = 1; $i <= 100; $i++)
    if (!($i % 15))
        echo "FizzBuzz\n";
    elseif (!($i % 3))
        echo "Fizz\n";
    elseif (!($i % 5))
        echo "Buzz\n";
        echo "$i\n";

Python implementation (Fizzbuzz)

for i in xrange(1, 101):
    if i % 15 == 0:
        print "FizzBuzz"
    elif i % 3 == 0:
        print "Fizz"
    elif i % 5 == 0:
        print "Buzz"
        print i

C implementation (Fizzbuzz)

#include <stdio.h>

int main (void)
    int i;
    for (i = 1; i <= 100; i++)
        if (!(i % 15))
            printf ("FizzBuzz");
        else if (!(i % 3))
            printf ("Fizz");
        else if (!(i % 5))
            printf ("Buzz");
            printf ("%d", i);

    return 0;

Advice 2: Learn the “100 to 1” answer

A very smart interviewer has come up with an alternative to the popular FizzBuzz assignment called “100 to 1“. Probably because the FizzBuzz answers got really easy to Google. The assignment is to print a count down from 100 to 1 using a “for” loop that has a loop variable “i” that starts at 0. This blog has gotten exclusive access to the secret answers to this very hard and brand new assignment. Use them in your benefit!

Java implementation (100 to 1)

public class HundredToOne {
	public static void main(String[] args) {
		for (int i = 0; i < 100; i++) {

PHP implementation (100 to 1)

for ($i = 0; $i < 100; $i++)
    echo (100-$i)."\n";

Python implementation (100 to 1)

for i in xrange(0, 100):
    print 100-i

C implementation (100 to 1)

#include <stdio.h>

int main (void)
    int i;
    for (i = 0; i < 100; i++)
        printf ("%d\n", 100-i);
    return 0;

Advice 3: Failure defense and contract extension

If you make a mistake, then don’t worry. Claim it is due to test anxiety. Another great defense is that you could not solve it, because you rely heavily on your favorite IDE. If that does not work, then you can say that the assignment seemed so trivial to you that you could not believe it was the actual assignment and you were looking for the hidden “difficulty”. One of these will work every time, guaranteed!

Some people have commented that they are worried about being outed as an impostor as soon as they won the job. Don’t be! By the time you are “up to speed” you are already earning big bucks for a few months and you have passed your trial period. Also, by posing humble, showing your effort and indicating that you are having trouble “adapting to the working environment” or “finding your spot in the team” you can probably achieve to win a contract extension.


It is important to realize that you can become good at winning a senior programmer job and also that being a great programmer is not always the easiest way to win it. Be aware that there may be some luck involved as not every interviewer asks the right questions (the ones above) or is sensible enough to buy your defenses (if you even need these). Don’t be discouraged if you do not succeed at once. There are enough companies eager to hire senior programmers, so you can have many chances as they interview anyone who sends them an impressive CV.

Let me know if it worked for you! Or maybe don’t… as I would become really depressed if it did (as this is a satirical post). 😉

10 reasons why PHP is better than Python

“There are only two kinds of languages: the ones people complain about and the ones nobody uses” – Bjarne Stroustrup,

People wonder: Did he really say that? Yes, he did. If you wonder who Bjarne Stroustrup is: He created the C++ programming language. Many people believe that Python is “pretty cool” and PHP is “really bad”. But as we all know, there is truth in the saying:

It’s a poor carpenter who blames his tools.

I believe both good and bad software can be written in any language. And I should probably also quote Joel Spolsky who calls “language wars” a “fruitless debate”. But nevertheless, if you program in PHP and run into one of these Python “evangelists”, then the following list may come in handy.

10 reasons why PHP is better than Python

  1. Python hosting, hard to find and expensive, while cheap PHP hosting is everywhere.
  2. Python cannot be mixed with HTML (needs a template library), while PHP can.
  3. Python has no proper encapsulation (private keyword), while PHP has.
  4. Python is hardly used in the real world, while something as big as Facebook is built on PHP.
  5. Python has a great community, but it is not comparable to PHP’s.
  6. Python has some books and tutorials, but PHP has way more of them.
  7. Python does not have the live docs (famous forum-like reference manual) like PHP has.
  8. Python does not have a steep learning curve, but PHP is still easier to learn.
  9. Python indentation for code blocks is prone to errors, while PHP uses curly braces.
  10. Python lexical scoping is a mess (‘global’ and ‘nonlocal’ keywords fix this), while PHP behaves as expected.

To wrap up

PHP has come a long way. Today it is a mature language that executes fairly speedy. Agreed that it has some quirky naming of it’s built-in functions, but hey.. that’s the price you pay for backwards compatibility.

Hint: Make sure to also check out this page on Python.org that is a good reference when comparing Python to PHP.