OOP

What makes CLOS so good exactly? I hear people talk very highly of it, but I'm a lisp newbie and haven't gotten into that part of things yet

OOP is great when you don't see how you could fp the respective code section. Keeps the mess in check.

I'm of the mindset that whatever you can be most productive with is what you should work in, but the needs of the team outweigh the needs of an individual. I prefer to write functionally. But if everyone else on the team worked best in OOP, I would oblige. It's going to slow me down maybe a little bit at first, but once you're working in a project long enough, it's easy to adapt. That said I definitely always use functional programming anytime I can.

Erlang is better. The "messages" in OOP should have been asynchronous.

It's utter shit

it's bad in theory, and even worse in practice

Does OOP define synchronousity?
I never knew.

im not impressed
i like some stuff that c++ has over c like enum class and compile-time stuff like constexpr and various casting but i honestly dont see the point in creating objects to perform the same tasks instead of sensible code
also fuck namespaces and name mangling

abstraction, indirection, and encapsulation are all bad for performance, in terms of both real-time and cache hits.
It's better to have well-structured data be a part of your API.
I'm intrigued by Jai, which supposedly aims to be the best of both worlds.

The only ones who have gained from OOP are the ones who sell books explaining you how to use their shit paradigm in 500+ pages.

youtube.com/watch?v=QM1iUe6IofM
youtube.com/watch?v=IRTfhkiAqPw
youtube.com/watch?v=V6VP-2aIcSc

Attached: 1548129473452s.jpg (125x93, 1K)

Attached: 1518735753030.jpg (500x600, 60K)

Attached: 1518735860516.png (1948x858, 152K)

What is the difference between OOP and normal programming?
Please help a brainlet.

The code that sent us to space wasn't written using OOP back then, so why the fuck would we need it now for anything?
It is necessary to make inefficient projects quick in a world where good programmers are very scarce and hardware permits inefficient bloated programs, we are living on a dystopia.

en.wikipedia.org/wiki/Procedural_programming

>normal programming: want a banana, use a function to get a banana
>OOP: want a banana, get a gorilla holding the banana and the entire jungle with him

>normal programming
Normal programming is OOP. What you are thinking about is functional programming.

>Normal programming is OOP.
You wish, Rajeesh.

Attached: 1401078609981.png (800x287, 189K)

Self-taught programmer here.

My tendency has always been to use classes only when my data has deep structure to it (like a list of list of lists) and also when the structure may possibly need to change a lot during development.

I suppose instead of classes though I could just write more functions to act as accessors, so if the structure of the data changes I'd just have to rewrite the accessor, similar to dealing with classes.
But is it worth it to avoid OOP, or is it acceptable to just use OOP in such cases?

I do think, look at some examples, that OOP is used excessively in the industry. But doesn't it still have some special cases where OOP is a nice clean solution?

Nice thumbnail

>Subhuman
>fleas = 14;

Attached: 1381507679641.gif (250x250, 993K)

>top programmer language on gitcuck by order
>javascript
>java
>python
>php
>c++
>c#
>c
>ruby

only 1 of them is functional, and even that is trying to replicate parts of oop because its an ancient language.

the code that sent us to space was meant to do one thing, it was code that was not meant to be maintained, it was embedded code. No shit you don't want to use an OOP language when you are working with 50s tech and have like 16kb memory where every bit counts.

When you work with any project of significant size, one that has a relevant lifetime, and is also meant to support additional components being added to it without making the thing's maintenance cost go through the roof you'll either use OOP or a non-OOP approach that mirrors it.

Project architecture is important

Attached: 1525834108959.png (275x226, 140K)

don't forget the 3 billion

>Normal programming : Banana Ban = Banana_init() returns the banana like a little bitch

>OOP : GorillaFactory Gorfact;
try{
Gorfact.import_jungle();
Gorilla Harambe = Gorfact.build_gorilla(new GorillaBlueprint( new IQ( (float)GorillaFactory.DEFAULT_IQ ), new contract() );
Harambe.Gib_banana(new BananaFactory().Banana(this,Harambe,this, Nullptr),this, new BananaThrower (Harambe.getHand( Gorfact.Str2Hand("right")) ) ; #TODO : fix left-handed gorillas causing segfaults
}
except Exception
{
ErrorLogger Errlog = new ErrorLogger( new Datastream (System.get_defaults()));
Errlog.print("shit's fucked yo"); #TODO : fix this
throw;
}

throws BananaException with the force of a thousand suns, covered in the gorilla's shit for added protein

Attached: Bad_ending.jpg (460x460, 22K)

>The code that sent us to space wasn't written using OOP back then, so why the fuck would we need it now for anything?
brainlet of the day away goes to you

> It's pretty much required for any project of a non-trivial size
you mean team of a non-trivial size.
that's the whole point of OOP. getting a billion brainlets working together.

no, project
large projects still need to be maintainable even when you're a solo dev

IMO, OOP is great for when you are representing real life stuff in code. For (simple) example if you are going to do a computer simulation for a ball in space with a certain velocity ect. Then representing that ball as an instance of a class makes a lot of sense. Though when it comes to something purely virtual like for example a compiler, web server ect. Code that represents itself basically, does not need to be programmed in a OOP manner. Though "objects" like structs may be very useful for example when a thread is created on a webserver to contain information about the thread. Though that is more of a collection of data than a proper class.

the amount of cherrypicking and pitting simple implementation vs needlessly complex implementation in this thread holy fuck

yes but also, a large enough project implies a long time to generate, people forget pretty quickly, within a month you are basically a different person provided you're constantly working on different things. also it's a lot easier to maintain when you divide your shit into lots of discrete pieces. although you can do all this with non-oop languages like C just by having a good directory structure and separate files for your source.

ultimately like you said, it's easier to use OOP to get less experienced people to not fuck shit up by throwing them into a containment section. But if they ever get out or aren't put into it to begin with without knowing how to use the ideas properly and why they are there in the first place it goes very wrong very fast

top fucking kek m8

Very good.
Everyone should learn how:
P - principles of
O - object
O - oriented
P - programming
works.

>#TODO : fix left-handed gorillas causing segfaults

Attached: 1521424591993.jpg (228x221, 11K)

this
almost nobody does it right and you get stuck with procedural programming, but with slower development times and ossified structures because of the objects

please break down your arguments into small ideas that can be formed into a cohesive argument and reused later

It's funny cause it's (bool) true.

Attached: cruise.jpg (700x700, 106K)

Any time someone starts an argument about it in here I come to the conclusion that they don't actually know what they're talking about, and instead just read that one Djikastra quote about it.

You're right, not even all OOP proponents are in agreement what OOP really is.

I once visited a lecture from a software engineer working in the industry showing OOP. He started with a 150 line program in one file that was working fine, but apparently it was bad code because it wasn’t extensible and unit testable enough. Two hours later he ended with a monstrosity with 20 classes spread over 15 files that did the exact same thing. Is this the power of OOP?

Procedural programming

it's great when done properly, but most "devs" write procedural code with classes

read POODR and you'll get it

Imagine thinking that the most difficult and complex thing humans have ever done was the space race meme.

Was it ISS or waifu generator?

It's shit

Yeah that's called overengineering, he was shit

If coffee+cream+sugar is not a multiple of sip, the result of running this program may be that the mug has a negative amount of contents. Rather than being a value, sip should be a function which takes the mug as a parameter, thus preventing undesired behavior.

This coffee mug may have been designed by an idiot.

I'm saving this for shitposting purposes hope you don't mind

Mostly the difference is in how methods belong to generic functions rather than classes.
It means that you can write methods that take as arguments differing sets of other objects. Suppose you're writing an application for making noise and you have objects like drumstick, cowbell and guitar, now you can write a generic function with three methods that each implement the sound for when one kind of object is hit with another.
hit(drumstick, cowbell)
hit(cowbell, guitar)
hit(drumstick, guitar)
It also enables you to do all the first-class function things with methods, like mapping a method over a sequence of arbitrary objects. (map #'update *objects*) is what you'd put in the main loop of a game.
Also, in CLOS, a class can inherit from multiple superclasses, and the circle-ellipse problem doesn't exist because an object can change its class.

Then there's the systems for auxiliary methods and whatnot that I've not dealth with, but which enable stupid amounts of control in comparison to just message passing.

Attached: 1475096351858.jpg (622x1000, 87K)

I think you’re the only one correct here.
If classes have some real-world representation it’s useful (e.g. ‘BeltConeyor’ class which has member of class ‘Motor’ inherited from ‘Conveyor’).
If there’s no such relation it’s often just tedious and unneccessary. Especially when devs start making up ambiguous concepts (wtf is a ‘LoggerHandler’ or ‘SortingManager’) that are hard to decypher.

APIs can be an exception where you present some resource to a user as if it were a physical thing

Attached: procedural.png (425x438, 210K)

OOP is not about representing things, but about sending messages
Not thinking in terms of classes helps a lot.

The only thing I use objects for is data structures. Otherwise I use free form functions.

OOP is nice, I don't know what these people's problems are but I think its because they think some horrible code they read or wrote is what OOP is. It's sad really.

it's fine but not on its own

All I can say is that Java-style OOP with interface spam is absolutely disgusting.
Never really had any issue with OOP in other languages, well-written OOP can be very comfy and intuitive to use.

I like this guys take on oop
youtu.be/0iyB0_qPvWk

>implying we went to space

Attached: math_fren.jpg (680x521, 63K)

this desu.

It's funny how even the Linux kernel reimplements a lot of features that C++ has in the standard.

This must really make the OOP-hating anime-posting cross-dressing Cnile trannies seethe when they realize their most treasured crown jewel of C engineering has to ape OOP in order to solve certain problems.

C++ chads literally live rent free in Cniles' heads. This is fact.

OOPs

Object Oriented Programming and its consequences have been a disaster for the human race

Attached: wudder.jpg (960x540, 115K)

a best, but it's not as strong as functional nerds

It works well since it makes source code discoverable, extensible, replacable, maintainable and so on.
The only thing holding it back is that the code running is still prodecural, which works well in many cases, but not really for things like UIs.
Luckily, most languages that support OOP also support (the useful) functional patterns, so that's no problem.

You might want to consider how programming for aerospace technology is incredibly different in both practice and cost compared to business software.

There are rules and regs that dictate how testing will be performed, when it will be performed, and how many times. That's how you create software for these types of machines. It's vastly different than how you create profitable software.

For instance, have you ever heard of a business performing a formal verification of their SW? No, I didn't think so.

People talking smack at OOP have never worked a day in their life

>code for a single purpose that we never used ever again wasn't oop

yeah sounds about right

Is Go more of a natural extension of a C programmer's tools? It seems like the compiler and garbage collector seems to trivialize most of the complications of C, at a minor cost in total memory usage and requiring a runtime.

Theory and praxis is often too far apart.
Inheritance is necessary in a few situations but completely overkill in most situations and that is why it is hard to write about.
Mostly, it is just a nicer interface and libraries should care about nice interfaces.
In C++, you often see graphical libraries make a base class and then you enherit that so you only change a few things.
That's fine.

RAII is a better model than garbage collection.

This. Also forced garbage collection is the worst decision a language can make, in my opinion.

RAII tree destruction is fucking slow, if each node is calling a destructor, which is calling destructors... I can't believe people do this.
I use C++ but for a lot of my data structures I write a small GC for ease of maintenance and reasonable performance.

destructors are optional, not everything needs one

oop is enforcing human logic in programs, it's the worst paradigm of them all.
opp is the epitome of anthropocentrism, it's a retarded idea but it makes proud the corporate worker thinking his work is valuable because it's (((neatly))) designed and (((complex))) because real life is complex.
developers don't talk WITH a computer, the computer talks to them and it's our job to write fast, efficient AND optimized FOR them, NOT us.
It's inthinkable for an engine engineer to not optimize the way engine behave to loss thes least energy possible, it MUST be the same with software dev and it's ok if it drastically reduces the number of people who can enter the field.

I don't give a shit if it slow down progress as a whole or if your shitty SME exists purely because nodejs is a thing, they're part of the problem.

Multiparadigm with optional OOP and functional elements like FCFs is the only reasonable option.

Using objects and encapsulating data and methods together is perfectly fine and natural.

Centering your entire programming around an idealogy where you thing about how "Nouns interact with verbs" is retarded. Inheritance where making changes to a subclass has weird hard to debug results in inherited classes is retarded, this is something that Go gets right.

Use objects, encapsulation, structure your code around modules, enforce consistency between modules with protocols or interfaces and throw the rest of the shit that comes with OOP out the window.

It is good if you are not a dumb brainlet.

>Inheritance where making changes to a subclass has weird hard to debug results in inherited classes is retarded
i think you're just bad

OOP is good if you have a lot of data that has at least something in common.

So you can change the behaviour of all the common stuff on a single place without having to manually ctrl+c ctrl+v every single corner which will increase the chances of doing mistakes..

OOP makes reading code much easier.

What is common logic functions and lambdas?