I was like 15 when I learned programming. VB6 was my first experiment. Later on I went on learning C++ on university. And C# on my first work. Then one day I came across C (a flavor known as Dynamic C used to program rabbit micro controllers) on one of my jobs. Once I grasped the concepts on VB6 I never really had a hard time jumping from one language to another. I could easily move the concepts from language to language. And then I learned smalltalk. Somehow it felt (and sometimes still feel) like hitting a wall. I decided to learn that because I read somewhere that if you wanted to truly master OOP you need to give that a shot. Turns out that is true.

It’s all in the mind.

There are several programming paradigms out there, and while OOP is probably one of the most abused words in the technology arena, I’ve found that is also one of the most misunderstood paradigms. At least in my experience. I considered myself a decent OO developer and even had some cool projects listed on my resume. Why then, did I had problems when starting with smalltalk?

The paradigm bridge

As I continue to find code that’s supposedly OO using procedural techniques, often wonder how is it that we don’t realize this. Even worse, we still believe that we are writing OO code and try to apply OO design patterns which often leads to convoluted code. To explain my theory behind this i would like to take a walk through history.

Imperative programming

In the beginning there were this monolithic creatures that walked over the hardware. They view of the world was a simple one: you start on line 1 and then continue executing line after line until you find a GOTO instruction, then you jump to whatever the GOTO points you to. On each line you have to explicitly command the computer on how to do whatever you want. This paradigm is called imperative programming. Even in this day and age you can find some people that still writes code like this for line of business applications (I have).

Procedural programming

At some point in time, Edsger Dijkstra wrote a letter explaining how this instruction (GOTO) was making code harder to understand and maintain. I’m not sure if this was what lead to the notion of structured programming but the concept certainly gained popularity around that time. When applied to imperative programming we got what’s called procedural programming. This is nothing more than a decomposition of an imperative program into a series of smaller programs, procedures, which are called from the main program. With this came a lot of new control flow structures like switch, while and for, to replace GOTO statements. One of the most representatives languages of this paradigm is C.

Object oriented programming

On the 1970’s Alan Kay and the people at Xerox Palo Alto Research Center came out with smalltalk. I was a very concise language (all of the smalltalk reserved words can be written down in 1 card) which ran on a virtual machine and introduced a new paradigm: Object oriented programming. It basically stated that any program could be represented as a series of objects, little programs which communicate with each other sending messages. This was so easy to reason and write that using smalltalk many kids created impressive stuff, even for today.

Mix and match

As OOP started to gain popularity, some people tried to implement the OOP paradigm on languages that were already familiar to a lot of people. So C being wildly popular, became the default choice for this experimentation. The results are C++ and Objective C. I believe that the idea was to reuse the familiar syntax on the new paradigm. And it looks like that was the same reasoning behind Java and C#.

Drinking all in the same glass.

The problem with this, IMO, is the way this languages are taught. You can do the experiment yourself: look for a course on C++, Java or C# and look at the contents table. Most of the time they start with all of the structured programming keywords (the ones inherited from C) before even touching the notion of an object. Most of the courses out there are effectively teaching structured programming and then try to introduce the student to OOP without explicitly telling him. These are 2 different paradigms that require a different mindset. The ‘switch’ keyword concept is not even present in the OO paradigm. It is not needed. Yet the student just learned it as part of the same language so he assumes that it’s safe to use it. Even worse he assumes that’s the way to go. He is having 2 different drinks in the same glass. How can we expect him to distinguish between one paradigm and the other?

Learning and moving forward

Looking back I now understand that before smalltalk I was using an structured programming approach, with some OO features. This limits the benefits of using OO. Learning smalltalk force me to finally switch to a completely OO mindset, which is awesome. I’m still learning, and feels like there’s still a long way to go, but hey, at least now I’m aware of it.

Alternatives any one?

I’ve been thinking on alternative teaching approaches to overcome this problem but still don’t have anything solid. How would you solve this matter?