It has been about 2 years since I wrote this, and I'm not impressed by it. First, I have become interested in functional languages and type inference. Second, C is mostly procedural but does have function pointers, which are nearly a form of first class functions, which gives C some functional abilities. I feel the the benefits of functional languages far outweigh those of object oriented languages, all other things being equal, which they rarely are.

Object oriented vs. procedural programming

I'm not the best person to be discussing the matter, in light of the fact that I'm only a sophomore in CS at Purdue and I don't have a huge basis of experience with which to attack above made claims. On the other hand, I consider myself a somewhat well-informed and generally reasonable person, and I think there are some things to point out. Note that when I talk about procedural languages, I'm mostly referring to C (I believe it's fair to say that many others are also), but respected procedural languages like Pascal and Perl will generally have the same facilities.

My response to the OOP paradigm and those who push it as a universal good is this: Object oriented programming has limited applications (it is not universal) and can encourage certain design flaws. Procedural programming has percieved weaknesses in structure and function because some programmers who use it are disorganized and dysfunctional. I'm not talking about anyone in specific, but Microsoft comes to mind.

ESR(Eric Steve Raymond) isn't everyone's hero or anything, but he does have respect in the hacker community. I would like to make the following quote from The Art Of Unix Programming by ESR:

The OO design concept initially proved valuable in the design of graphics systems, graphical user interfaces, and certain kinds of simulation. To the surprise and gradual disillusionment of many, it has proven difficult to demonstrate significant benefits of OO outside those areas. It's worth trying to understand why.
Read the section yourself (web address below) to see the details, but the general point (or one of them) is that object oriented design tends to pile things on top of each other so that a large project can become a pile of layers that do not necessarily correspond to anything. In short, OO can lead to overcomplication. This is a point that needs bearing out in detail, which ESR has already done, for which reason you might want to look at the book.

The most prominent argument for OOP, at least from my experience, is that it is inherently structured and organized; I submit that OOP is only a tool for structure and organization, which can be misused or ignored. The more general design principle is modularization, which says that code should be written in well seperated pieces. Modularization is a simple tool which is available in almost any language; OO languages provide objects explicitly for this purpose (and others), but the exact same thing can be done in C. The most common way to this is is to provide a seperate header file and employ good taste in design (see orthogonality, other design concerns in The Art Of Unix Programming) so that those using that interface (even if you created it) do not need to concern themselves with the internals. In short, if you can structure and organize a module properly, it should be just as affective as designing the same module with object orientation.

For me, the 'bottom line' is much more general:

  • Procedural programming provides power and flexibility (enough rope to hang yourself with).
  • Object oriented programming facilitates certain (good) design practices and has logistical advantages in some situations.
  • Function programming offers an extreme amount of expressive power and flexibility, but offers it in a very safe, orthogonal manner. Functional programs for complicated programs tend to be dramatically shorter than equivalent programs in object-oriented or procedural languages. Therefore, it will be dismissed as magic by otherwise sane people.
(Do you like how I snuck functional programming in there without mentioning it in the top part? More on this after my pants.) This 'bottom line' is not saying much; I think that's perfectly alright! I think it is unwise to draw strong conclusions without a lot of strong evidence and the absolute necessity to declare a 'winner'.

Other points

Exemplary use of C: I think it is fair here to point out that the original Unix system was entirely rewritten in C, at a time when assembly was in vouge. Unix is a fairly large system, and is written entirely in a procedural manner. Modern Unix or Unix-like systems such as Linux, *BSD and The Hurd are all written in C; there is so much high-quality C code flying around that I would think very carefully before declaring that large projects should be done in an object-oriented language.

Procedural programming and the learning process: Another objection I have to OOP is that it enforces good design, rather than encouraging it. Forcing a programmer to do things a certain way does not mean that he will do them well in that way, or that he will learn to do things that way in general, only that he will one task that way. We (the CS students at Purdue) are prime candidates for jobs in systems programming, so I find it a little disturbing that the ideas of modularization and good design went nearly untouched during the first year of our training here, in favor of having to learn three programming languages and get through calculus 1 and 2. The basic principles of design and taste are more important than knowing whatever languages are in vogue. But I digress; in short, OOP does not cause programmers to learn good form any more than holding a piece of string makes it straight.

Programming paradigms versus individual languages: When discussing procedural programming versus OOP, I (and many others, I'm sure) think largely in terms of C versus C++, Java, Python, et cetera. It is reasonable to choose C to represent procedural programming because it is very well known and respected among procedural languages, and it is one of the cornerstones of modern programming.

On the subject of speed and efficiency, I have nearly nothing to say. This is something else that ought to be handled on a basis of individual languages. It the case of C vs. C++, I have no knowledge on which to pass judgement; I can only guess that C++ would show very similar speed, since it is close to the hardware in the same manner as C. Among VM centric (Java, Parrot, .NET) and interpreted languages, each has it's own performance defeats, but I don't intend to be an expert on them until I need to be.

Functional Programming: This writeup (and two others) used to be in object oriented vs. procedural programming until I had them moved; that said, it doesn't make much sense to get functional programming involved in the argument. I've taken a look at lambda calculus and poked around Scheme, and I can easily tell that functional languages have a very clear purpose, and I have no idea what it is. If someone could give me a quick rundown, I could add it here.


I've tried to make this writeup more general and clear; let me know if I've missed something big.