Lets discuss Object Oriented Programming. The definition of paradigm and methodology:

• Paradigm - a typical example or pattern of something; a model.
  
• Methodology - a system of methods used in a particular area of study or activity.

The definition of each is quite similar. OOP may be a paradigm by Wikipedia's definition, however I'd posit that in practice OOP becomes a mere methodology, aka a way for "engineers" to mindlessly follow "principles" in order to try and write good code. Here's a quote from the CTO of Activision. Here's Paul Graham on OOP -- he says what I'd like to say, but said it first and better than I would. Here's Casey Muratori on OOP. Here's Casey again. Sony dudes on OOP.

The idea is that OOP is designed in such a way that it appears to give rise to good code. Take the OOP example my link github repository and look at main.cpp. Wow! That code is so readable! And here I think is where the problem surfaces. Sure, the concept of what the code is doing in theory may be clear, and it might be human readable and perhaps human related. These are all great things. However these are not the only criteria for what makes code good. Some more criteria are things like: can we reason about what assembly will be generated? Do we know what kind of impact this code has on compile time? Can we tell, at all, just by reasoning at-a-glance what the hardware will do when running this code? When OOP code is involved all of these qualities are lost in the mist of OOP-ey abstraction.

As an alternative I would say that OOP doesn't actually solve real problems. OOP presents a solution to imaginary organizational problems and tricks people into thinking they are being productive by solving organizational non-problems.

Take a look at the examples jjf and myself created. I'd say both OOP implementations are quite similar. I'd also say both OOP implementations are fairly canonical and would be widely considered as a pretty good standard OOP implementation:
Github repo of my imeplementation of OOP vs non-OOP of a CSV serializer for C structs: https://github.com/RandyGaul/oop
jjf's OOP implementation: http://puu.sh/q7HaQ/4df33d2501.7z

Pros of the non-OOP implementation:

• Super simple and easy to read.
  
• Trivial to extend and add more types.
  
• Not much code.
  
• The algorithm is laid out linearly in code. It's just right there, in front of you. No boilerplate.
  
• Solves exactly the problem of CSV serialization without attempting to solve any other problems. This adds code-reusability.

Some Cons of the OOP implementation:

• Lots of code for solving a very simple problem.
  
• Extremely tempting to solve-non problems, or create more problems that don't need to exist. Added a constructor? What about the copy constructor? Or move constructor? What about private and public, and encapsulation? Good OOP has to have encapsulation right? Also we should probably have some inheritance and polymorphism in there too. In the end I sacrificed performance for the sake of following OOP principles -- these principles let the OOP implementation be extended and scaled into the future! Right? RIGHT???
  
• Tons of functions all over the place. It seems like the algorithm was splat onto the floor and left there to congeal. Following code flow involves lots of opening and closing of different files and looking all around. It's just a mess.

Some immediate concerns may be that my OOP implementation was poor, or bad. Okay, how can it be fixed? Don't just tell me, go fix it. I have an open-source github page, so go make a pull request. I won't accept any unfair criticism of the presented source unless time is put into making an actual example for real discussion.

Another concern is that many cons of the OOP implementations here are that they are all C++-ey, riddled with C++ problems, not OOP problems. Well, same as my previous point -- I don't care unless you write up an example and create a pull request on github, or upload your own repository and share some code. Unless we have an example to work with criticizing the existing examples won't really get us very far.

In conclusion OOP sucks, everyone using OOP should stop, OOP code is bloated, usually has tons of dependencies, performs slowly, compiles slowly, is hard to modify and multi-thread, and solves many problems that don't really exist. Instead problems should be taken case-by-case where specific solutions are used to solve specific problems. One problem, one solution. Avoid "generic" code that attempts to solve many problems at once. Re-usable code is code that *isn't* generic (like the STB libraries), because people can figure out how to use it and solve the problem they have without worrying about extra bloat, extra dependencies, or extra bullshit.

I think you've taken a very simple, non-realistic task, and shown that when implementing it using OOP, it is harder to follow than a structured programming solution.

The linux kernel is written in C, not C++. But it uses OOP design principals.

I think that wins the argument right there, really. As much as there is an argument to be won. Some tasks lend themselves to OOP, other tasks don't. Both are turing complete.

jjf picked it, not me. I think it is realistic, I've seen this kind of code in a product that made a lot of money. All OOP programs are harder to follow than non-OOP programs. You didn't provide any reasoning as to how or why the Linux kernel should be considered OOP. I can just as easily say, no, it's not written with OOP style at all. I did google "linux kernel OOP" and in the first page this was the only relevant link (here), and I think everything this guy calls OOP is just a bunch of BS. Function pointers and "methods" do not make something OOP. That's silly.

I said everything I wanted to

TBF I was just adding to your FileIO idea, I think the case study is fair enough, but I would contend that you have to separate your structures and associated methods into their own files in your procedural program (perhaps their serializations functions could all be one in file, but either way) - or put the OO files together to make a fairer comparison (I prefer the former, as that makes the assumption that many functions/methods besides serialize are associated with the data).


I've built OOP programs in C and assembly using such constructs, It's not about the specific language tools you're using (you can ofc use classes and be programming in a largely procedural manner), it's about the way you're structuring your program and the extent to which you adhere to OO principles; that said I don't know if Linux strongly employed OO concepts or not.

---

I'll get to finer points later. such as enforcing consistency, scalability, and abstraction/performance

Well I'd say enforcing consistency is just in general a good thing, and not an OOP thing (as in a defining aspect of OOP that we can't get elsewhere). As for moving things into a single file... Generally this isn't how OOP is done. But, if you'd like go ahead and make a pull-request. You can edit the code directly in web-browser on github. I think it goes something like: fork -> edit -> pull request.

Mostly I'm just going to argue pro-OOP here cause you're so adamantly against it.

teehee
/endadhominem

Some things are better done by encapsulating code into objects. Some things are better done by encapsulating code into stand-alone functions. Some groups of related functions work well together and get grouped in packages. I think we all get this. The only point I think you really missed is that even OOP code is procedural as far as the CPU is concerned, and even the most procedural code is still OOP as far as the CPU is concerned. Paradox? No, because when it comes down to it even integers are objects whose 'class methods' are built into the hardware. So procedural code is still a procedure for working with objects. And OOP code eventually boils down to a procedure when the instructions get sent to the CPU. It's the same shit.

What's the evidence for OOP being a good thing? No one writes in Fortran anymore because to do so would be extremely wasteful of a programmer's time, and encapsulating functionality using classes and objects helps us think better, clearer, and faster sometimes. If OOP was bad, my language of choice, Python, wouldn't even exist. In python, literally everything is an object, even integers and floats. Despite everything being an object, most of the code I write is pretty procedural. So I disagree -- OOP is not bad itself, but any dumbass can take a good thing and abuse it to the point of fucking everything up.

Nevertheless, the kernel uses those methods over and over again, and whether you think it is OOP or not is irrelevant, because that style of design is considered OOP by the wider development community. Here's part 2: https://lwn.net/Articles/446317/

You're engaging in a bit of a "no true scotsman" fallacy here.

I haven't done very much work in the linux kernel myself at all, but one part I did look at was in the networking area, and it was passing socket information around. Because a lot of the concepts are abstracted away to very large degrees, using OOP techniques, it can be quite difficult to start learning and make modifications to the code. But what was being done in this area of the code was effectively polymophism, but without using inheritance on classes. There are sets of structures that represent UDP or TCP sockets, which have function pointers for how packets should be processed. The instances of the structures would find themselves going through this scheduler / processor, that would call the start/stop/continue functions that were pointed to by each flavour of structure, without worrying what underlying type the structure actually represented.

The linux kernel is amongst the largest and most successful software projects in the world, and runs on more devices than any other piece of software. It makes use of OOP design methods, whether you like to believe it or not. I suggest the wisdom of those involved in kernel development rather trumps your views, where you're effectively saying "it's good for nothing, ever, and anyone who thinks so is deluded".

As I said earlier, both styles are turing complete, and some tasks lend themselves to OOP and others don't.

Personally I've done very little OOP programming ever, but I'm not so arrogant as to write off the rest of the world's opinions due to my lack of experience.

Post has been edited 1 time(s), last time on Jul 21 2016, 9:44 pm by Lanthanide.

Just because the Linux kernel was wise and used polymorphism does not mean it involved OOP. Polymorphism existed before OOP. As for the comment on experience, these opinions I've gleaned from others with many years of experience, and a supplement to this is my own experience. If I were leaning only on my own experience I would probably still be stuck believing in OOP squabble.

Inheritance existed before OOP. Encapsulation existed before OOP.

OOP is about thinking of a program in terms of abstract "objects", and how they relate to both real-life intuition and to one another within code. This paradigm or methodology in conjunction with the typical "OOP principles" is what makes OOP itself.

Edit: As for the idea that OOP lends itself well to some things and not others -- I'd like to see an example of something that was well lent to OOP. I don't have one up my sleeve, maybe someone here does?

Post has been edited 1 time(s), last time on Jul 21 2016, 9:52 pm by CecilSunkure.

I've said it in the shoutbox, but I'll reiterate in a post. I don't think your problems are with OOP as much as they are with over-engineering and under-thinking. Some problems have structures that lend themselves to OOP solutions, other's don't. Some things are easier to understand and manipulate in a class and object structure, others aren't. Some things are better are arranged in hierarchies, other times it makes no sense to do so. Some things have similar things you would want to do with them, others don't.

Concepts like encapsulation, inheritance, and polymorphism are conceptual tools to solve problems. It's naive to pretend that they're the only way to solve problems, or the best way. I think the best approach is to learn the concepts and when to use them, and OOP has given us some useful concepts. It shouldn't be applied blindly, but a total disregard of all things OOP shouldn't be applied blindly, either.

Anyway, since this discussion has happened a bunch of times on the internet already:
http://c2.com/cgi/wiki?NobodyAgreesOnWhatOoIs
http://c2.com/cgi/wiki?DefinitionsForOo

http://c2.com/cgi/wiki?BenefitsOfOo
http://c2.com/cgi/wiki?BenefitsOfOoOriginalDiscussion

http://c2.com/cgi/wiki?AcceptableCriticismOfOoOnWiki
http://c2.com/cgi/wiki?OopArgumentsDebatesAndDiscussion
http://c2.com/cgi/wiki?ArgumentsAgainstOop

Post has been edited 1 time(s), last time on Jul 21 2016, 11:24 pm by Mini Moose 2707.

While I'd love to show you how very wrong you are, I've got too many programming projects already so no time to dispel any of this BS. Unfortunately a lot of it is caused by people writing shitty "specific solution" code that was so inflexible that when the requirements changed slightly the entire thing needed a rewrite. So I'll settle for saying I'll import a CSVHelper resource from NuGet and call it a day. That was easy I did what your thing did in all of... One using statement?

I get it, MVVM or MVC design patterns are hard. And all of those interfaces? Ugh! Can you believe connecting to a database requires I access it through a dataset in C#? How awful! That is, until I realized that the dataset was really like a queryable database all on its own, working naturally with LINQ and other advanced tools that could let me do things in a couple lines of code you couldn't dream of doing in 50 lines of C++. It's as simple as using a select statement. Wow so readable and easy to use.



No, it's not. You don't know what you're talking about and this statement illustrates it.

Classes are types. Every time you declare a class you've created a new type. It doesn't get any easier than that.

To be honest, this is insulting and I think you're missing the point. I don't think Cecil is arguing that his solution has a faster development time or fewer lines of code than importing a library and using it. That wasn't the point at all. Cecil knows a library can be brought in for this that easily does what he's doing. The whole point of the exercise was to roll solutions in different paradigms and compare them.

He means a type that be (de)serialized by his code. Declaring a new class/type/whatever doesn't automatically put it in there. (Okay. With certain libraries it does. We know.)

While we're deciding to do arbitrary tasks instead of a full and comprehensive battery, he's more than welcome to accept the challenge of turning the code into gui which does the same thing as the above. Also he needs to build it into an API.

Not so easy eh? See because I've attempted to do this with python and tkinter and the results were disastrous. His "superclean" procedural code breaks down when he's forced to more complex tasks that cannot (and should not) be done by a single algorithm. For instance manipulating files in C# is easy because you can add them to a List<FileInfo> object which contains a bunch of FileInfo objects. Each of these FileInfo objects contains valuable information on each file.

And he's dead wrong about OOP being burdensome and complex. You don't have to include things you don't need, and you can tailor specific objects to solve specific solutions. You're not required to over-engineer every solution.

Why in particular I HATE procedural code is because it becomes complex quickly, and if you have the type of mind that can break down problems into smaller ones, OOP seems as natural as breathing. It makes sense to break down big problems into smaller, self-contained problems that can each solve their piece of the puzzle. By constraining yourself to this natural mindset, you greatly improve your ability to debug, maintain, change, read, and share the code you've written. It's easier to write too. With fewer moving pieces on every object your write (encapsulation, anyone?) you can abstract your thinking about various objects and think more in the scope of what you are doing and less about its implementation details.

But hey maybe I'm wrong and Cecil can write his paper dispelling the OOP myth and collect his Nobel prize.

Post has been edited 1 time(s), last time on Jul 23 2016, 3:44 am by Sacrieur.

More from CTO of Activision here (was retweeted).

OOP is high cohesion writ large. Humans reason over objects, not properties.

Keep in mind, this is an idea that really started with the first compiler. Unfortunately, somewhere along the way a software engineer made a mistake and got a Business Development middle manager interested in "code with custom data types" (besides the native architecture instruction set data types) that could "increase efficiency" and "improve code production rates" and all that B.S., who then took the idea to his managers and before you knew it a decade had passed and the word had spread and somehow we got stuck with Java. Long story short, all the paradigms and stuff that suck are a result of the clusterfuck that is the preening and show-off-your-dick-manship that is Business Development, and if you listen to your B.D. folks who want you to write shitty code and they call it OOP then yes, hate on it. But just remember that sometime long ago a poor engineer had a good idea and called it "object-oriented" and those of us who support "object-oriented" code are probably thinking along the same lines as that guy. If only that poor engineer had kept his mouth shut around the B.D. department. Or you know, if the B.D. departments of the world required some minimal level of technical aptitude besides "know how to play golf, bullshit, and brown nose."

Moral of the story: pretend space magic is what makes your code work to your manager, and you're the only space pirate wizard who can control it.

I wanted a way to serialize basically the whole state of Chkdraft to JSON so I needed to revisit something similar to this problem, I ended up crafting a reflection library and building something where you need only list the field names and optionally apply annotations (e.g. "Reflected" if the field contains objects that are also reflected, or "Json::String" if you want the field to be quoted/JSON escaped) to customize behavior for that field.

Then you can very easily read an object from a stream/stream out an object like...
std::cin >> Json::in(myObj);
std::cout << Json::pretty(myObj) << std::endl;

This was only possible to do in a highly optimized way where I don't affect the size of objects (use only static constexpr's) and where I don't adversely impact performance (due to high use of templates and constexpr if's and such) with newer C++ features.

https://github.com/jjf28/CppRandomAccessReflection