Rob Pike on Object Oriented programming
C'mon kids. Not again.Tools in your toolbox.  Use them as you wish based on whatever criteria fits the moment and the project.I made hundreds of thousands of dollars with a program I wrote in 8051 assembler.  To be fair, it was part of a larger hardware solution.  Still, the UI portion of the code was all assembly language.It wasn't until well after the product was in the market and selling very well that I converted it to C.  I did so mainly to make it easier to maintain and expand.Could this have benefited from OO?  Who cares?To add insult to injury, the workstation portion of the solution was written in --sit down-- Visual Basic!  Yeah! VB.  Did it matter that it wasn't Visual C++?  Nope.  Was it ever converted to VC++.  Are you friggin kidding me?  Nope. It was making plenty of money as it was.Plenty of other projects were done using other languages, such as APL, Forth, Lisp and, yes, C++.My point is that none of this really matters.  People have gone to the moon without OO.  Whole banking systems have been run without OO.  OO has its place.  And, when applied correctly, it can be a lot of fun to work with.Digging through one of the links in the posted article there's an article that suggests new programmers should be taught Python without the OO stuff. What? Crazy.Every new programmer needs to start with C.  In fact, I am convinced that every new programmer needs to start with C and be tasked with writing an RTOS on a small memory-limited 8 bit processor. And then write several applications that run within that RTOS.Then give them a budget of n clock cycles and m memory bytes and have them create a solution for a particular problem that barely fits within these constraints.I would then expose them to Forth and ask that the re-write the same RTOS and applications.Then I'd move them up to Lisp.From there move into one of the OO languages.  My first OO language was C++, but I suppose today I might opt to teach someone Java or something like that.  Definitely not Objective-C.  Keep it simple.The above progression will expose a new programmer to tons of really valuable ideas and approaches to solving problems.Then I'd get serious and ask them to write something like a genetic solver on a workstation in all of these languages and optimize each solution for absolute top performance (generations per second) first and absolute minimal memory footprint as second batch.  Lots of invaluable lessons in that exercise.Now you have a programmer that can identify which technology to use under what circumstance and for what reason.  This is a programmer who knows how to get a 100x or 1000x performance gain out of a piece of code or how to get something done 10x faster at the expense of raw performance.  Here's a programmer who understands exactly what is happening behind the code.And, in the end the most important thing still is data representation.  You can make a program 100 times harder to write if you choose the wrong representation for the problem being solved.  Just like the first article points out:  search a small table and the "hacker" solution is almost trivial.