Rob Pike

=== Analogy ===
https://interviews.slashdot.org/story/04/10/18/1153211/rob-pike-responds Here's an analogy. If you want to make some physical artifact, you might decide to build it purely in wood because you like the way the grain of the wood adds to the beauty of the object. In fact many of the most beautiful things in the world are made of wood. But wood is not ideal for everything. No amount of beauty of the grain can make wood conduct electricity, or support a skyscraper, or absorb huge amounts of energy without breaking. Sometimes you need metal or plastic or synthetic materials; more often you need a wide range of materials to build something of lasting value. Don't let the fact that you love wood blind you to the problems wood has as a material, or to the possibilities offered by other materials. 
The promoters of object-oriented design sometimes sound like master woodworkers waiting for the beauty of the physical block of wood to reveal itself before they begin to work. "Oh, look; if I turn the wood this way, the grain flows along the angle of the seat at just the right angle, see?" Great, nice chair. But will you notice the grain when you're sitting on it? And what about next time? Sometimes the thing that needs to be made is not hiding in any block of wood. 
OO is great for problems where an interface applies naturally to a wide range of types, not so good for managing polymorphism (the machinations to get collections into OO languages are astounding to watch and can be hellish to work with), and remarkably ill-suited for network computing. That's why I reserve the right to match the language to the problem, and even - often - to coordinate software written in several languages towards solving a single problem. 
It's that last point - different languages for different subproblems - that sometimes seems lost to the OO crowd. In a typical working day I probably use a half dozen languages - C, C++, Java, Python, Awk, Shell - and many more little languages you don't usually even think of as languages - regular expressions, Makefiles, shell wildcards, arithmetic, logic, statistics, calculus - the list goes on. 
Does object-oriented design have much to say to Unix? Sure, but no more than functions or concurrency or databases or pattern matching or little languages or.... 
Regardless of what I think, though, OO design is the way people are taught to think about computing these days. I guess that's OK - the work does seem to get done, after all - but I wish the view was a little broader. 
https://en.wikiquote.org/wiki/Rob_Pike 
https://groups.google.com/forum/#!topic/comp.os.plan9/VUUznNK2t4Q%5B151-175%5D object oriented design is the roman numerals of computing.
http://www.defprogramming.com/quotes-by/rob-pike/
=== Rob on oop ===
https://web.archive.org/web/20180814173134/http://plus.google.com/+RobPikeTheHuman/posts/hoJdanihKwb
https://web.archive.org/web/20180829092402/http://csis.pace.edu/~bergin/patterns/ppoop.html
https://web.archive.org/web/20180611102612/http://prog21.dadgum.com/156.html P1
https://web.archive.org/web/20180216135414/http://prog21.dadgum.com/93.html P2
https://web.archive.org/web/20180423032113/http://prog21.dadgum.com/218.html P3
=== Niklaus Wirth ===
niklaus wirth
=== comment 1 ===
OOP is just structs (or pascal records) that have been extended to have a hidden parameter sent into the procedure each time. Your object is just a struct being passed in as a parameter... It's just syntax sugar. Niklaus Wirth has commented on this in his infamous paper Through the Looking Glass. He discusses the hype of functional programming and OOP. What the Object Oriented idiots did was rename "procedure" to "method" and sell the snake oil (emperor in new clothes) as a new product, rather than just extending our existing procedural imperative structured programming.
Smalltalk inventor claims to invent something entirely new when in fact he has plagiarized procedural programming (messages are parameters) and pretended it's spanking new, when it's just building on the giant's shoulders. He gives absolutely no credit to the giants and the shoulders that he is standing on... he claims it's not procedural programming with extensions. 
What ends up happening in Plain C code is you pass around a lot of data structures, so OOP hides this and makes your code less verbose (at least in some OOP languages - in Java it in fact seems to make your code more verbose, ironically, but in theory it shouldn't).
Consider the following code:
cee_procedure(somestruct data, anotherstruct other, int number)
You pass the data structure around. Okay so what's OOP then? All it is, if you want to be a simpleton (and sometimes this is useful) is:
someStructures.cee_procedure()
See how the dot notation now allows you to pass around the struct without it being in a parameter. It's kind of funny. The int number is now located in the struct all as one struct in the OOP system, hiding these parameters and reducing verbosity (syntax sugar game). The "message passing" that demented Alan Kay has "invented" is just snake oil for "procedure parameters being passed in to the procedure (or function)". Do you see how snake oil salesmen get a hold of structured programming literature and reinvent the wheel? I recently purchased a wheel for my car that had snake oil sprayed on it which made the car go 50MPH faster. Truth! I speak of the truth.
The other confusing thing is functions vs procedures. In Cee language a void function is a procedure? Or everything is a function? The terms function and procedure continually get mixed up because no one has scientifically put rigor into this discipline ... We have "subroutine", "function", "procedure", "method"... How many bloody terms do you need to describe the same thing? So in functional programs a function doesn't have side effects (or at least claims not to, but in Lisp.... you can have side effects galore). Again this is discussed in Niklaus Wirth's article Through The Looking Glass. However, Niklaus Wirth has created UGLY caps lock programming languages that are over simplified - he has never gotten strings right. I'm in the process of writing some critical articles on Wirth and why people are using Go Language and delphi and other languages, instead of Wirth's oberon.
Ultimately the real reason we use programming languages today has nothing to do with OOP and everything to do with Strings. Cee language doesn't have easy to use strings, while python, php, perl, delphi, ruby, go language, all have strings. Even visual basic has strings. Imagine if visual basic had Cee language style pointers to chars. Who would have used VB? What if Ruby required you to use oberon style strings where you have to define up front how long your string will be ARRAY OF CHAR (1024)? Or required you to use pointers to arrays of chars. Who would use ruby? That's right Wirth needs to get a clue on the string front. Google after all, is just a bunch of strings.. of text... the internet is based on, you guessed it, strings.
Another interesting area of research is implementing the Relational Model into programming languages, which TutorialD intends to do (Date and Darwen) however they suffer the same problems as COBOL and SQL where TutorialD has become a verbose monster, with operator overloading hacks (which may be neccessary for the ultimate Type system that can do everything under the sun). DURO implements the relational model simply and is an interesting project to check out (by Rene Hartmann). The reason I bring up TutorialD and Date/Darwen is because they have written about OOP and tried to put rigor into the subject, defining the difference between a Class and an Object (what was the official difference? Are they just "types" with new snake oil language..).
Niklaus Wirth has also found out that OOP is actually just modular programming at run time (modules are design time separation of code into separate files) whereas OOP is heap allocation of a module! See the snake oil that the OOP offers you? Modular programming reinvented to be allocated at run time..
Apologies for this long Wall Of Text (I could write a book). I will compose this into a more formal computing science article or an informal one, if I get the time. (which I intend to). 
Dijkstra said Object Orientation was a "Bad idea" that could have only originated in... I won't say it. But Dijkstra was also a simpleton who thought that everything could be solved in Standard Pascal which was a castrated language that proved to be difficult to use in practice. In his later life Dijkstra seemed fond of Haskell but I don't think he did enough critical thinking about Haskell, since it requires you jump through hoops just to get work done (they're called Monads, written by someone who claimed to have Gonads).
Best regards,
Critic of OOP,
Critic of Functional programming.
Skeptic of idiocy in computing science.
But also a critic of the critics themselves (Wirth, Darwen, Date, Dijkstra)
=== links ===
dan saks
Category:Oop