Why is /g/ against OOP? I haven't worked on huge projects and have no idea how to organize them but the idea of combining functions and data in logical units seems like a good idea. Why is making all functions global a better idea? Proper abstraction is always better and more powerful in anything.
/g/ isn't a person.
The backlash against OOP is because it's inappropriately applied to problems.
OOP isn't bad on principle, and can be useful or even beautiful, but overuse by idiots leads to the tremendous bloat we have today.
Trendoids latch on to the criticism and declare OOP universally bad, just like every programming paradigm that's behind the curve of hip/rockstar tech.
I absolutely love OOP. I also love functional programming, though I admit I'm mediocre at it at best, and my current job (at a medium sized reverse engineering/porting/development project) doesn't leave me that much room to work on my functional skills yet. That project is using OOP with quite a few really nice patterns and principles. It's great, and life is pretty good right now.
I find that most people who are really against any given thing here are most likely quite inexperienced. I remember being very strongly for some things yet strongly against others when I was first starting out, though there are things I'd still rather not touch again, like PHP and JS. I got my very first few grey hairs while working with PHP, and JS (and Java for that matter) are the only languages that have succeeded to make me angry.
Recently, I heard someone talk about "friction" in programming, while he was laying out some ideas for a language he'd like to make, and it really got me thinking. The language, principles, methods and whatever else should be chosen by how much they help you achieve the task at hand. If I need to make a website, the language of choice is not going to be assembly, while both Python and C# look like valid options (Python is fast, fast, fast to write, but may not run as fast, while C# is fast and fairly secure, but takes ages to write and pretty much ties you to microsoft, for example). If I need to make a game, then it's possible, but not likely that a GC'd language is going to quite cut it. It all depends on the scope and aims of any given project.
> making all functions global
OOP is not the only way to organize functions.
If you want to hear some anti OOP stuff, here's a basic reading list.
>the idea of combining functions and data in logical units
Is a shitty definition of OOP. I think the problem is that things like polymorphism and multiple inheritance can't solve every problem - even though OOP was thought to be the savior of the programming world in the '80s/'90s.
Positive: It allows some beautiful solutions to most problems and provides the best way of organizing and managing functionality.
Negative: The people that use OOP try to apply it to everything and this can lead to sloppy design.
Part of the problem is that OOP is generally done very badly.
If you want to experience good, solid OOP, check out Smalltalk, Common Lisp's CLOS and Metaobject Protocol, and Erlang.
message passing and breaking systems into self-healing, fault tolerant units is more fundamental, but hey, we can just uninvent all the cool stuff after being blasted with mediocre shit for years, right?
oop is nice when applied to one datatype with multiple functions where the data may not be exposed to the user of your class (for safety for instance).
otherwise other things might be less complex and a better solution.
So. Many. Opinions.
This is hardly an objective study, but rather the angry rantings of someone who simply prefers to do things another way. The arguments are so weak that you could take them all, turn them around, and just slap on a different title; "why functional sucks". I'm >>45209038, happily learning functional (albeit very slowly), and I say they both have their pros and cons. There is no silver bullet in programming, and people are never as smart as they think they are, as most people come to realize every time they have to read through something they've written, but not seen in a couple of weeks.
You do not need a constructor to print hello world in java.
You can theoretically program java procedually by just making everything static and using classes as namespaces, which is sadly highly ugly. I wish it offered a cleaner alternative to do both.
C++ bolted on an object system and a bunch of other crap while still being backwards compatible. C++ is to C as Common Lisp is to Lisp.
>typical class-based OOP
More like morass.
>I haven't worked on huge projects and have no idea how to organize them
There you go then.
I've seen enough >500,000-line C++ projects for one lifetime, thank you.
>but the idea of combining functions and data in logical units seems like a good idea
What you really mean to say is grafting state mutation functions onto state.
I agree with Joe Armstrong on the matter:
>I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.
>If you have referentially transparent code, if you have pure functions — all the data comes in its input arguments and everything goes out and leave no state behind — it’s incredibly reusable.
Note that OO does not preclude referentially transparent methods.
A collection is a great example where OOP is more appropriate than other paradigims.
Let's take a tree for instance: Obviously, you can write loads of functions which all take the root as parameter, but is that really better than hiding the root behind a class?
If you give the user the power to modify the nodes directly then you also give him the power to break the assumptions that your functions make, for instance that no duplicate keys are allowed in a tree map.
I agree with the first post that OOP is highly overused and applied to lots of problems that aren't really suited for OOP. A major cause of this is that many programmers believe that they need to remodel real life, as shown in your image, which often results in a terrible disaster because it simply is not possible in most cases.
(This presentation brings up some good arguments against remodelling reality: http://www.slideshare.net/cellperformance/data-oriented-design-and-c)
>Scheme (Scheme was invented to explore the conjecture that objects can be represented fully as closures)
That's sort of bad advice if you want to really explore OOP, unless you plan on building your own object system from scratch.
Most people can't do proper OOP, because proper OOP is not taught in schools.
For example, using existing taxonomies like animals, cars or vegetables (like >>45210430
) is terrible idea.
OOP is about abstracting behavior. And existing taxonomies are not.
Square/Rectangle problem is clear example of existing taxonomy failing in OOP.
Nah, doesn't ring a bell.
Of course OOP is fine though. What's bad is the realization of it in 98% of cases where it is used. Classes, multiple inheritance, the whole taxonomic shitpile.
It's odd. I generally like statically-typed languages, but I feel that OOP languages should be more or less prototype-based. Nice and direct, no bureaucracy, no pleading with the compiler. Also acceptable are Go's method receivers, which are just as straightforward and to-the-point as method definitions in prototype-based languages.
Not him, but I think he referred to
>For example, using existing taxonomies like animals, cars or vegetables (like >>45210430
>) is terrible idea.
and he's likely asking for an example.
Still, I don't see how his question follows from what I said.
I said not to use existing taxonomies. The opposite to that is to create new taxonomy for given problem domain. It has nothing to do with OOP not being useful.
Apart from that, GUI is also a nice area to apply OOP because it increases usage simplicity.
Imagine having to use some sort of GUI library that requires you to pass all types of underlying data into the functions - that wouldn't be the easiest to use.
>C++ is to C as Common Lisp is to Lisp.
common lisp was an effort to reconcile the numerous dialects of lisp that everyone was spewing everywhere.
it had to be large otherwise people would complain that it didn't have the features they wanted and continue writing totally unportable programs.
it was a politics issue.
I now imagine creating a Windows Phone app without OOP and the MVVM pattern...
Nonononoononono just no. Specially if I'm working with a designer and he's writing the XAML.
If for anything, it's good for separation of concerns. I'm not heavy metal in functional programming, but some sfutt just can't be as elegant as in OOP.
So, out of all of the paradigms there are, which ones comprise the minimum set of paradigms necessary to learn in order to cover the broadest amount of problems?
OOP and functional seem obligatory.
It's almost as bad in other languages. The only defining feature of OOP these days is inheritance and inheritance is used correctly so rarely that it's not even worth including. Every other feature of OOP is done better by using records and protocols/typeclasses.
>Objection 1 - Data structure and functions should not be bound together
They don't need to be bound together in OO
In Java for example, Math is a class containing functions but no constructors.
If it isn't appropriate to put data structure and functions together, then don't do put them together.
OOP is useful. I like to create interfaces for even the simplest scripts.
For example, today I had to create a system to store data in MySQL.
So I created a class into which I inject a reference to RowProvider type object.
Objects implementing this interface need to have 2 methods that return data. How do they o it is not important to me. I am just injecting reference to objects using this interface.
Thanks to this, I can have mulltiple systems providing data and I don't fukcking care about anything other than them implementing this interface. I know everything is going to work fine as long as I implement these two methods properly.
Meanwhile some autist would rewrite the database integration every time he tried to adapt a new data source.
OOP is nice but muh sperglords read wikipedia and two blogposts and they think they know everything about it.
How is that different from defining functions to do what you want and using them? You don't need to worry about how they're implemented and can change them all you want so long as the arguments passed can stay the same.