Red Pill me on Object-oriented programming. There's a meme lately that considers it shit...

Red Pill me on Object-oriented programming. There's a meme lately that considers it shit, useless and a bad idea from the start. Is it kill?

Object capability in a programing language is nice, but object oriented programing ends up being shit

It is not kill, those memeing are just pajeets

It's nice to have the option to use it, it's a shit show when you are forced to use it.

oop is good
especially if you have strong foundation in programming
those who make it a meme just fails to understand oop
they protect their ego by making oop a meme

it's necessary for large scale projects

obv if ur programming experience is fizzbuzz and editing lua you probably dont get it

>it's necessary for large scale projects

corollary, it's largely unnecessary for small scale projects and introduces bloat and difficultly

Look to CLOS if you want an example of OOP done right.

ok so what is the best non-OOP language?

It's OK for getting source code reuse on large set of projects and minimizing/clarifying interfaces if done right.

It's rather poor for compiled libraries where the slightest fucking change breaks an API/ABI.

Is that the "install gentoo" of OOP?

ms-dos

Is Linux kernel a small project?

That's a systems software though, it may be difference. Then again it might be not and Torvalds may be an idiot. Or, when it started (1990?) it might had been too early for it in terms of public knowledge on OOP.

As always, depends on your needs. Sometimes you're gonna want C, sometimes you're gonna want Haskell.

There's also a bunch of languages that have OO mechanisms, but can also be written in different paradigms, or a combination of paradigms - Python, Ruby, Perl, etc.

>Torvalds may be an idiot
t. some asshat on a pachinko image board

Even if you use a procedural language like C for larger projects your code starts to mimics oop concepts, you might as well have it all.

Even if you use a functional language like Haskell for larger projects your code starts to mimics oop concepts, you might as well have it all.

You organize code into groups of related functions and variables. Wow, how revolutionary.
Don't fall for meme or dogma.

- OOP is just one of the suggestions in development. It obviously has its pros and cons here.
- OOP is not panacea.

But it does more than that though.

Bullshit that only neo/g/ and dumb college freshmen spout

It Haskell, it does not. OOP without state is just grouping functions by what they are vaguely related to.

Still C++
Nobody will force you to use objects

the Linux kernel is one of the few large-scale C projects to get anywhere close to its size, and it relies on extreme enforcement of a ton of ad-hoc rules by what is very nearly a cult.

Linus is right in that very little of what C++ adds to C is optimal or even useful for kernel development, but most of his spiel on the subject is just dogmatic grandstanding, which is kind of necessary at this point given the development structure of the project.

OO is good when you wanna make some nice cash for a quick buck.

But if you want to make something safe. You will have to return to functional programming, and use data type declarations instead of classes. You won't be seeing people use object orientation with Ada or Haskell when developing the software for their Cruise missile in the military for example.

common lisp is better

OOP is used in businesses. Learn OOP if you want to make money.

>Red Pill me on Object-oriented programming.

Object-oriented programming is only one possible means to accomplish a goal. OO is not the goal itself.

Here are some truly useful goals:

* Easily-reusable code. OO has class inheritance, which is a pretty good way of reusing code -- but there are other ways to reuse code also.

* Automatic execution of required code. If code MUST be called, why not set it up so that the code is called automatically? OO has constructors and destructors to do that -- but you could also design auto-execution of code outside of the OO paradigm.

* Easy, natural code organization and packaging. OO has classes, which can be used to package related code and data together -- but it's certainly possible to package things together without OO also.

* Polymorphism -- mapping the abstract concept of a "method" to the actual function to be called, based on the type of data you're acting on. Most OO languages do this (for example, C++ has "virtual" member functions) -- but you certainly don't need OO to perform that mapping.

All OO did was to create memes: standard ways of thinking to achieve desired goals.

OO gets a huge amount of credit that it doesn't deserve. All OO did was to create a standard reference terminology for solving problems -- it didn't actually solve the problems themselves. The solutions to those problems were already known well before OO was "invented". For example, people used to do polymorphism in C all the time with function pointers. Therefore, OO didn't "solve" the polymorphism problem at all -- it simply created a standard "meme" to talk about the problem and its solution, in a way that united everyone's frame of reference.

I remember what programming was like in the era before OO, and how little the introduction of OO really changed anything of significance. (Elderlyfag here.) Pic is mfw when OO came along and everybody got all hyperventilated about its "significance".

>cruise missile
>hasklel

lel

Not particularly. I found it pretty easy to use in a short time.

Lisp has been used in such contexts before, and I'm pretty sure Stroustrup published a guide to programming safe C++ for situations like this.

>mfw when
>when when
>>>/OFH/

Duh. No one invented OOP. What people did is formalize and jargonize established practices.

Object oriented programming is shit.
Not having classes is pretty bad though.

The only efficient method is to take a hard look at something and determine how to code it. For example, "user" would be a class containing data and fields, but if you're creating a static class for anything you should just go ahead and shoot yourself

Thank you. I am now that much more clearer.

desu nowadays functional programming is the latest meme paradigm
except its actually useful for most projects
thing is if you wanna go OO you have to design your entire project around or you might just not bother at all
with functional programming you can use a few concepts here and there and still profit massively from it.
in fact many languages nowadays have some FP stuff in them and it makes them better

thats not what OOP is. dynamic dispatching/binding ? liskov substitution? ever heard those terms ?

t. babbys first cs lecture
come back when you are above 3rd semester thanks

>dual monitors
>obviously from the 80's
guy is a fucking savage

>t. babbys first cs lecture
that's exactly why i used those you fucking retard. see what post i've replied to

Anyone have the photoshop with the extra long legs?

OOP is fine, the problem is when people try to shoehorn every problem under the sun into the paradigm. You don't need OOP for text munging or data analysis. Also it's easy to fall into bad habits like making one class with all the methods that holds all the data. All you've done at that point is write an imperative style program with a slightly smaller than global scope.

You're fucking kidding right? OOP exists so that projects can be easily handed from pajeet to pajeet.

Noobs always make nonsense classes without abstraction and C++ just has syntactic sugar that can never approach real OOP. Try Squeak and have a look yourself: everything on the screen is an object that you can find the code for interactively. EVERYTHING!

>Duh. No one invented OOP.

Yes, lots of people know that now.

But back in the 1980s, large numbers of people honestly believed that OOP was this great new thing that just recently got invented that will revolutionize the way we think about programming.

I think that's really the one thing that irritated me the most -- the widespread perception back then that OOP was some great new discovery. Fortunately, that idiocy mostly died down over the following years. But when I read comments in Sup Forums about OOP, I see some of the same kind of innocent confusion about OOP that I saw in such large numbers of people back in the 1980s.

Not everything, at some point, somewhere, your shitty little VM is breaking encapsulation and making syscalls.

encapsulate everything, make everything private unless it absolutely needs to be.

There. I saved you reading a thread.

>All you've done at that point is write an imperative style program with a slightly smaller than global scope.

True. But taking identifiers out of the global scope is a Really Good Thing to do, and if that's the only reason you're using a class, then that's still a damn good reason to use a class.

And, no, it's never "slightly smaller than global scope". A local scope is always a whole lot smaller than global scope.

Certain things are millions of times better when you think of your program as a Turing machine that starts at line 1 and just executes

classes are useful for wrapping your library in when you're done with it. Don't try to think of concepts within your program as actual objects because they aren't, they are 1s and 0s