>>101568992
>Change my mind if you can.
Functions can't preserve state. They can only take input and produce output.
You can't even code an editor to write functions with just functions.

The keyboard you're using to type the code for your functions? You'll need to track the state of whether the key is up or down, the transition between those states and keep a timer to for auto-repetition while you hold down backspace to wipe out your last stupid ten mistakes and start over.

>>101569317
What about pointers.

>>101568992
thyre nice in GUIs, where each widget is basically an object in visual form

>>101569317
I hate oop muchly, I just write a mixture of imperative and functional. I'm free from any actual responsibilities though, so I can write my shitware however I want.

>>101569317
op never mentioned pure function haskeler autism
any state can be a parameter for a function, or functions could access globals

>>101568992
yea but it just werks unlike whatever the fuck you are doing

>>101568992
>Functions are really the only way to cope with the potential complexity of large programs.
OOP is just functions + state. It is the logical evolution of imperative programming. You are not smart, you are just a simpleton.

>>101569317
>Functions can't preserve state.
Not strictly true.

>>101569440
>thyre nice in GUIs, where each widget is basically an object in visual form
Or you could just construct a function that covers the GUI state logic. Maybe I'm biased from writing HMIs/OITs but I do it all fundtionally/logically and every industrial plant that I've worked on relies on that method.

>>101569317
>>Change my mind if you can.
A valiant effort, however
>You can't even code an editor to write functions with just functions.
Is not correct.

>>101569934
You are far too clever by half.

>>101568992
People's lives, including yours, are routinely entrusted to C++. E.g. when flying or when in hospital. Programs routinely made by the top engineers on the planet in Object-Oriented languages. You have found a way to do it better?

>>101569546
But then you'd want to group state together into bigger state. Maybe some way to initialize that state so you make functions for it. Maybe you can derive some useful value from the state so you put that in a function. Maybe you want to ensure the state always has some property so you write functions to interact with it while preserving it. Maybe you dynamically want to use the same state but with slightly tweaked set of functions, so you pointers to which functions should be used as part of the state itself.
That's a class

>>101568992
Some things are better written as a function
Some things are better written as a class
When in doubt do what rust is doing because it has the best design

>>101569934
OOP is function bound to state in a mutable mess of side-effects that provides no benefits nor solves no problems simple immutable clojure can't.

>>101568992
i kind of like oop. and i kind of like plain old c. heck i'll even admit i kind of like python, and even javascript.
i just hate every single other person remotely related to any aspect of computer science or programming whatsoever and don't wish to communicate with or put up with any of their shit.

>>101569317
What an idiot.

Reminder: If you're doing functional programming outside of very niche circumstances/professions, you're wasting your time. There are unironically people on this board who will shout "MUH SIDE EFFECTS" while using memory unsafe languages. OOP is fine for 95% of use cases, if you fuck it up, it's a skill issue.

>>101568992
Hating OOP is the midwit trap. OOP is just common sense.

http://lispm.de/genera-concepts
>Genera doesn't draw any boundaries around itself. It is customizable and extensible by design. Unlike most software, it has an open architecture; you can change anything that is part of Genera. In fact, we encourage you to take advantage of this and to build your applications as extensions of Genera.
>The extensibility of the system is possible thanks to both its modular design and its implementation, using highly flexible, object-oriented data structures called flavors. Any data object defined by a flavor or class can be customized or extended cleanly.
>Object-oriented data structures are at the heart of symbolic processing because they allow abstract descriptions of data and operations in terms that fit well with the application. The data objects are essentially models of the real-world objects they are implementing. Thus programming uses a problem-solving vocabulary that matches the terminology of the problem domain.
>Data-level integration means that memory contains structured data objects, not merely uninterpreted bits. This ensures that programs automatically share the semantics as well as the objects and makes it impossible for one program to misuse the data structures of another.
>Each data object contains knowledge of its own type. For simple objects, some of this type knowledge is captured in hardware tag bits. Data objects in the object-oriented Flavors and CLOS languages also know their own types and the generic operations that apply to them.

OOP at a macro level, DOD at a micro level.
OOP helps me break my program into more manageable chunks based on functionality. DOD lets me get better performance out of the hot code path and is simpler to deal with in a local context (but not a whole-program context, which is why I don't use it at a macro level).
Simple as.

>homecooked shitware <6000 loc
not software engineering that aint

>>101575636
All is fine and good until ur 5 level inheritance chain needs some fundamental change because requirements change or u made a mistake. Refactoring that shit is a nightmare even debugging, go through any java stack trace all this flexibility and clean code will make u go insane.

I like Gos oop concept keep it simple and stupid also don't inherit more then one level, repeating urself a few times a bit is fine