Is procedural programming the root of all object oriented evil? [closed]

Well, I don't have any "studies" or "evidence" at hand, but I am pretty sure most of the problems with bad code don't arise because programmers "have learned the wrong methodology" before starting with OOP. IMHO most of the problems arise because there are too many "developers":

• who don't care about quality of their code

• who don't care about self-improvement

• who have never read any of the books you mentioned above

• or if they read the books, they don't know how to apply the contents to their own process

• who learned programming by <3 months of implementing some small games and utilities and then start to call themselves "professional programmers"

Fortunately, there are also a lot of other devs having an opposite understanding of their job and their craft. So IMHO the best way of bringing "good" OOP into an organization is having skilled senior programmers in your team teaching OOP to junior programmers on a daily basis, primarily by reviews and good examples. The methodology to "learn before OOP" is IMHO unimportant (though I expect a good programmer to have procedural, functional and OOP skills as well under his belt after some years of working in that field).

I think the problem is not so much people learning procedural programming first, but not learning object oriented design at all. I received my bachelor's degree in 2001. In my degree program, most of my classes were procedural, even though they were taught in Java at the end. I had one third of a semester learning LISP, and around one semester learning the mechanics of OOP, like how inheritance physically works, but not proper OO design.

Colleagues I've talked to who got their degrees in 2005 or later almost all had extensive training on object oriented design principles: design patterns, SOLID, etc. However, like me they had maybe one semester of a functional programming language, but no functional programming design principles.

I think most of the bad OOP code comes from people who know the mechanics, but never bothered to learn the design principles. I had to get the design principles through continuing education classes at work and my own self study. Not everyone has the motivation, but books (like the ones you mentioned), classes, and websites are out there for the taking.

As far as functional programming, I don't know anyone who learned it first. That sample size is probably too small to draw general conclusions. Unlike for OOP, information on functional programming design principles is still hard to come by in a manner that an average programmer can understand. People I know who can write clean and maintainable functional code mostly learned the design principles through a lot of personal trial and error and a handful of higher-level style guides like Twitter's Effective Scala.

Look at this question for an example of someone who had difficulty figuring out good functional programming design principles. Unfortunately, that's fairly typical of the result of someone trying to program functionally without guidance on design principles. There's no canonical "Clean Functional Code" book to point people to when they want to learn.

There is a vast number of programming paradigms, and each has its applications. Calling one inherently evil is not useful. Here is a list of interesting paradigms/language features

• unstructured programming, e.g. assembly
• imperative programming
• structured programming: conditionals and loops instead of goto.
• procedural programming: split the behavior into reusable subroutines.
• modular programming: put your definitions in separate namespaces, which increases re-usability and encapsulation.
• functional programming
  • higher-order functions: pass around references to functions
  • closures
  • pure functional languages: control side effects
• object oriented programming
  • dynamic dispatch: method calls are resolved at run time. This allows for polymorphism.
  • inheritance: share behavior between implementations
• declarative programming: say what you want, not how to get it

The most important of these are structured programming, procedural programming, and modular programming. Why do I put such an emphasis on modules? Because they are (a) absent in C (compilation units do not count), and (b) an important step between procedural and object-oriented code.

For example, the God Object is not primarily an object-oriented failure. Instead it's a failure to separate procedures into different modules, made worse by the fact that mainstream OOP languages like Java confuse classes with namespaces for procedures (any “static method” is not OOP).

There is no clear hierarchy between OOP and FP, because closures and objects are formally equivalent. However, an OOPer will miss dynamic dispatch, whereas an FPer might miss higher-order functions. The more important difference is however that FP tends towards declarative programming, whereas most OOP languages have imperative roots.

Learning to program is a good start for learning to program in an object-oriented manner. For example, subdividing a problem into smaller, unrelated problems is an important skill, which can be applied to PP, MP, FP, or OOP. One can produce decent “OO” code without actually using features like dynamic dispatch or inheritance (which is falling in disgrace anyway: use composition instead of inheritance).