OOP was a mistake

OOP was a mistake

Other urls found in this thread:

quellish.tumblr.com/post/126712999812/how-on-earth-the-facebook-ios-application-is-so
twitter.com/NSFWRedditVideo

sorry, we'll go back to one big file full of GOTO statements

>overengineering

That sounds like what some cademia monkey who has never made a single dollar would say

>OO is the only alternative to unstructured programming

>le epic functional programming maymay

kill yourself kid

>strawman false dichotomy

>He hasn't heard of imperative programming

>var was a mistake

>calling something a meme means it is bad

>goto is bad
When will this meme die?

>mfw doing my first project with OOP and it kinda looks like that
>mfw I'm loving it

>try non-OOP language
>it's just a bunch of simple functions

Or you could do things properly by seperating data and functions. Of course, in some cases you'd need to pass pointers/references around when functions modify data, however in practice you end up doing that already in OOP (and often needlessly so, actually)

>thinking "non-OOP" language means some meme like Haskell or Lisp and not a sane language like C

I'm not sure what that model is designed to solve but something tells me without OO it would be a much less well abstracted system.

do you know anything at all?
look up literally any fucking glib library and tell me how that is better than proper fucking Object abstraction.

purely imperative is garbage.

Also to all the functional memers out there. Good functional languages, like haskell and rust are very Object oriented.

fuck off you literal retards.

>OOP and FP are the only forms of structured programming
C would like to have a word with you.

>Haskell is object oriented
Learn your memes before you spout them. Haskell doesn't have state so it doesn't do objects and message passing.

>seperating data and functions
>"do things properly"

When did this shit meme start? The programming world RAN to OOP to get away from fucking spaghetti code and impossible to trace bugs. If you look at professionally designed, pre-OOP APIs they were basically trying to encapsulate code and data without having the benefit of OOP features at the language level.

If you think OOP was a mistake then your understanding of OOP is the mistake. Learn how to do it right. There are a lot of shit OOP examples out there, but the programmers who produced them would make even more complicated and buggy code without OOP. They wouldn't magically produce clean code thanks to Meme 2.0.

I'm going to be brutal here: a lot of people writing code shouldn't. Something I've noticed about recent changes in languages and the pushing of meme paradigms is they're both trying to address programmers who shouldn't be programming. You want a beautiful, clean, documented design? Hire someone who knows what he's doing. You want spaghetti? Hire Pajeet.

But something you'll notice is that the guy who knows what he is doing is trying to encapsulate code+data even in a non-OOP language.

>doesn't have state
>high performance

Choose one and only one.

The world ran to oop because win32api is an abomination. Oop is overused. It is best for shit that is clearly hierarchal, polymorphic, and event driven like guis, but pajeets insist on making everything oop because that's all they know or remember.

>separate data and functions
>separate things that aren't distinct

even the authors of that book refuse to teach from it anymore because the approach is so outdated

>data and functions
>aren't distinct

Could you elaborate?

of course there's state in the memory of a haskell program, but a haskell programmer doesn't work with state.

They refuse to teach it because MIT's undergrad CS program isn't about theoretical computer science but how to connect different software together. As a result of the shift in focus, MIT teaches Python in its intro course.

The book is still a good introductory book to theoretical CS as it has always been.

In most programming languages including C you can treat functions as data and pass them around. C doesn't have the ability to construct functions as new data on the fly to pass around, but C++ does and many other languages do. You should totally read SICP though.

>he thinks windows is the world of computing

OOP concepts date to the 1960's. The Apple Toolbox API was not OOP because 128K of RAM, but was clearly organized that way with "managers" and data structures you were generally supposed to treat as opaque. NextStep had a fully OOP OS in the 80's, and the rest of the UNIX world was running that direction.

By the late 80's / early 90's Mac languages were already wrapping Toolbox with OOP frameworks. In the 90's everyone of importance was doing the same with Win32.

>pajeets insist on making everything oop because that's all they know or remember.

Global data structures that any code can touch are a bad, bad, BAD idea once you move beyond an 8-bit CPU with a few KB's of RAM.

And truly "stateless" languages make many tasks unnecessarily convoluted while taking a shit on performance. RAM is state, and maintaining the illusion of "stateless" means copying anything that's touched.

I see what you mean now. I'm not the original posted, but I think he specifically meant coupling of data and functionality.

As in, this group of data, let's say a person, is coupled to its walk functionality. Sometimes this makes sense, but a lot of the time it doesn't but is done anyways.

>but a haskell programmer doesn't work with state.

That's an expensive illusion that seems neat for small tasks, and is shit for large projects.

>Sometimes this makes sense, but a lot of the time it doesn't but is done anyways.

Give an example that's non trivial.

I find that the larger the project, the more important and useful it is.

I don't see how explicitly controlled state makes larger projects worse. It's great looking at code and knowing exactly what it can't do.

Where did I imply stateless was good? My pic was a book that teaches a little bit of imperative, functional and oop.

And I never said OOP was invented after win32api. People flocked to it because of win32api's evils though. OOP didn't become big until the early '00s.

Not to mention saying win32api is oop is disingenuous. Do you really think this is oop?
RECT WindowRect; // Grabs Rectangle Upper Left / Lower Right Values
WindowRect.left=(long)0; // Set Left Value To 0
WindowRect.right=(long)width; // Set Right Value To Requested Width
WindowRect.top=(long)0; // Set Top Value To 0
WindowRect.bottom=(long)height;
hInstance = GetModuleHandle(NULL); // Grab An Instance For Our Window
wc.style = CS_HREDRAW | CS_VREDRAW | CS_OWNDC; // Redraw On Move, And Own DC For Window
wc.lpfnWndProc = (WNDPROC) WndProc; // WndProc Handles Messages
wc.cbClsExtra = 0; // No Extra Window Data
wc.cbWndExtra = 0; // No Extra Window Data
wc.hInstance = hInstance; // Set The Instance
wc.hIcon = LoadIcon(NULL, IDI_WINLOGO); // Load The Default Icon
wc.hCursor = LoadCursor(NULL, IDC_ARROW); // Load The Arrow Pointer
wc.hbrBackground = NULL; // No Background Required For GL
wc.lpszMenuName = NULL; // We Don't Want A Menu
wc.lpszClassName = "OpenGL"; // Set The Class Name
RegisterClass(&wc);
DEVMODE dmScreenSettings; // Device Mode
memset(&dmScreenSettings,0,sizeof(dmScreenSettings)); // Makes Sure Memory's Cleared
dmScreenSettings.dmSize=sizeof(dmScreenSettings); // Size Of The Devmode Structure
... Out of comment space

My main criticism of OOP is that you sometimes have to pass a command through multiple classes to get anything done. For example, for a school project we had to create an OOP ATM program. All user interaction was through a GUI form. So for example if you entered an account number, the GUI form handler for that action called a function in an ATM class, which called a function in a bank class, which called a function in a customer class, which called a function in an account class. That function then had to pass its return values back the way it came. Trying to debug this was horrible, because there were like five different functions where failure could be happening. Whereas the whole point of functions in the first place is to isolate things so it's easier to track down failures. Maybe this was a poor implementation of OOP ideas, but it definitely shows how OOP can make things overly complicated when used needlessly.

>It's great looking at code and knowing exactly what it can't do.

I know that MyWidnowClass cannot fuck up MyVolumeIOClass while still having state within instances of those classes.

>And I never said OOP was invented after win32api. People flocked to it because of win32api's evils though.

People were flocking to it BEFORE Win32.

>Not to mention saying win32api is oop is disingenuous.

I didn't. I said *** Apple's *** Toolbox engineers were thinking about code+data encapsulation (though there are certainly examples where that's not the case), and by the 90's OOP frameworks were wrapping / hiding both Toolbox and Win32.

Missed on both points. Did you even read my post?

who cares, it all bits in the computer anyway :^)

The premise of my post is that you're full of shit in regards to oop's popularity in the 90's.
>apple a dying company was doing oop in the 90's
>in the 90's oop was big!!!!!!!#####
I wanna see some of these mainstream 90's win32api oop frameworks. Saying oop was big in the 90's is like saying Haskell is big now.

>Implying glib isn't an implementation of OOP in C

I'd say that any data that is useful in more than one context should be separated from its functionality.

One set of examples would be simple data types like strings, lists, dates, etc. It doesn't make sense to try and think of every possible use case for these since they're so flexible.

At my work, we have business objects that handle their own functionality. The problem is we also have other representations of the same data such as data transfer objects. These objects all have the exact same data, but different functionality (i.e. validation vs. serialization).

To help with code re-use, you can do two things
>shove every possible function into the data definition
>define various modules with functionality that can manipulate the data, each separated by the use case

I've started doing the second option in personal projects where data is just passed around and transformed and it's quite nice. I don't have to worry about classes doing too much or having too much inner complexity. Just a bunch of functions that take an A and return a B (where B can possibly be A).

Although this is a tangent, I this also works nicely to eliminate a lot of the private mutable state that necessitates OOP-like designs.

>he GUI form handler for that action called a function in an ATM class
>which called a function in a bank class
>which called a function in a customer class
>which called a function in an account class.

Why the fuck would you have a customer and account class in a hierarchical relation? Why is account even a class instead of a structure? OOP is designed to be used with logical, hierarchical relations. You made multiple illogical relations using OOP, and you're criticizing OOP for your code being unmanageable? That's like asking your waiter for a spoon, and then complaining it's not sharp enough to cut your food.

>structure

probably java friendo

And I know that my AddNewLogEntry literally can't do anything but append to the log. I also know that any database function literally can't do anything unrelated to the database.

Of course any static language can make at least some guarantees, but the more guarantees, the better.

That's what the assignment required. If it was up to me I probably would have used structs.

C++, actually.

Me again, I realized I started arguing regarding side effects rather than state. Though the two often go hand-in-hand

There is nothing wrong with OOP.

>ITT: Rejeej has never worked in a large project

typical oop project:
>lets refactor
>again?
>yes

typical non oop project
>how is the design going?
>what do you mean design, the software was ready yesterday.

go to bed pajeet

pure oop is textbook waterfall development

Not an argument.

Honestly it would be worse without OOP.

Not saying it shouldnt be better but its the truth.

>C would like to have a word with you.

I would rather not recompile a giant ass project by dozens of teams cause one asshole made a change near the bottom.

>separate things that aren't distinct
Retard.

You clearly don't know anything about linking, do you?

Yeah, I have also migrated in that direction.

If, to take the previous example, you just have a "walk" function that takes anything, and returns a thing with an updated position, you inmediately solve the redundancy issue, and don't have to worry about superclassing "person" and "duck", introducing a hierarchy that will eventually fail, or some other such OOP hack.

Honestly the worst part isn't the UML diagram so much as that most OOP languages don't make all the boilerplate implicit so you end up with five lines of logic and 100+ lines of comments and useless syntax.

>function that takes anything, and returns a thing with an updated position

I'd go for an interface (or rough equivalent) in this case. Lest you get a bug when someone tries to make a string walk.

>Thinking writing asm for a mostly unspecified VM is sane.

>Java doesn't have structs

Wait, wot? Really? How do you define your own data types then? What if I want to create a Color datatype that's four Bytes and a String? I have to create a whole Java class?

>I have to create a whole Java class?
Yes. Forced OOP.

>whole class
Well in C++ a class and a struct are literally the same thing, only difference is that structs are public by default. So I don't see why a "whole class" is such a big deal compared to a struct. I assume Java allows public accessible member variables in classes, so that should work more or less like a C/C++ struct. However, I do know Java is pretty bad for user-defined data types since it doesn't include operator overloading.

OOP IN THE OOL

>The premise of my post is that you're full of shit in regards to oop's popularity in the 90's.

I lived through the 90's kid. Every major platform shifted to OOP either directly (i.e. NextStep) or via frameworks that wrapped older APIs (Mac; Windows).

Now go do your homework.

>I'd say that any data that is useful in more than one context should be separated from its functionality.

So you think data should be separated in the use scenarios where separation means completely different parts of the code base can fuck each other up?

>One set of examples would be simple data types like strings, lists, dates, etc.
>It doesn't make sense to try and think of every possible use case for these since they're so flexible.

These are all objects in modern languages and for good reason. The fact that you believe this means the designers have to "think of every possible use case" reveals a lack of understanding about OOP. The point of OOP is that you do not know every possible use case. The language features allow someone to extend existing objects to new use cases, or substitute completely separate objects via interfaces, all without breaking the code base.

>At my work, we have business objects that handle their own functionality. The problem is we also have other representations of the same data such as data transfer objects. These objects all have the exact same data, but different functionality (i.e. validation vs. serialization).

Though sometimes there's a legitimate reason for having the same data in two different classes, it sounds like the original designers coded to classes instead of interfaces, thereby painting themselves into a corner of needing separate class hierarchies for the same data.

>To help with code re-use, you can do two things
>>shove every possible function into the data definition
>>define various modules with functionality that can manipulate the data, each separated by the use case

You don't understand the point of OOP at all.

I do not concur with: * Account number handled by ATM. This gives the ATM a chance to sanitize and verify the data.
* ATM asks Bank to find Customer. Bank has a chance to further inspect and verify the request, and also check for fraud (i.e. time and location analysis).
* Customer gets the Account since a single Customer can have many Accounts.
* Now you can ask Account for whatever you want.
* You should not have to transverse this every time. At this point Account should be associated with an ATM Transaction so Account can be called directly.

Why make it this complex? What would you do with code that does not have these layers when:

* A hack is discovered that needs to be blocked up front.
* The Bank needs to be alerted that a fraudulent Customer is trying to do something.
* Fraud on an Account needs to be blocked/reported without harming any other Accounts.
* There's a global change the the Bank's account numbers but customers need to be able to use their old numbers and that is detected via something like account# plus customer PIN.
* A Customer's Accounts are linked and should be accessible from either number with unified reporting.
* Entirely new Account types are added.
* Two Banks merge and Customers need to access all Accounts from any ATM.

Every single challenge can be answered by modifying the code at one layer without modifying or compromising the other layers.

That's the point.

I've been saying that since the mid 1980s. Nice to see y'all catching up finally.

When goto ceases to be bad

quellish.tumblr.com/post/126712999812/how-on-earth-the-facebook-ios-application-is-so

>java

hehe nice bait amigo

goto is fine

t. just wrote a patch containing two gotos in a single commit, two times in a row

>sane language like C
>no namespaces
>unsafe memory handling
>many C libraries still end up as ghetto OOP