If procedural programming is so superior then why does every University teach OOP and every major organisation that...

If procedural programming is so superior then why does every University teach OOP and every major organisation that writes new software (not maintains old shit software) use OOP?

Other urls found in this thread:

eptacom.net/pubblicazioni/pub_eng/wirth.html
youtu.be/rX0ItVEVjHc
twitter.com/AnonBabble

Because OOP is actually good no matter what the autists on this board will say.

Precisely.

a. Because they are academic retards who get off on abstract concepts with shit real world applications, with zero experience in real programming projects
b. Because all new graduated were taught by a and can't into proper programming, therefore companies are forced to use them in OOP projects since paying triple the salary to a C programmer to do the same job is out of the questuon to investors

who tf ever said that procedural is superior? For a quick shell script, maybe.

FP 4lyfe

If oop is good.
Well. Give me a list of what it actually provides the programmer?
Even Wikipedia is vague on what OOP is supposed to provide. Because you've spread yourselves thin. People now think that any use of member functions mean you're doing OOP.

>Many people tend to look at programming styles and languages like religions: if you belong to one, you cannot belong to others. But this analogy is another fallacy. It is maintained for commercial reasons only. Object-oriented programming (OOP) solidly rests on the principles and concepts of traditional procedural programming (PP). OOP has not added a single novel concept, but it emphasizes two concepts much more strongly that was done with procedural programming. The fist such concept is that of the procedure bound to a composite variable called object. (The binding of the procedure is the justification for it being called a method). The means for this binding is the procedure variable (or record field), available in languages since the mid 1970s. The second concept is that of constructing a new data type (called subclass) by extending a given type (the superclass).
>It is worthwhile to note that along with the OOP paradigm came an entirely new terminology with the purpose of mystifying the roots of OOP. Thus, whereas you used to be able to activate a procedure by calling it, one now sends a message to the method. A new type is no longer built by extending a given type, but by defining a subclass which inherits its superclass. An interesting phenomenon is that many people learned for the first time about the important notions of data type, of encapsulation, and (perhaps) of information hiding when introduced to OOP. This alone would have made the introduction to OOP worthwhile, even if one didn't actually make use of its essence later on.
>Nevertheless, I consider OOP as an aspect of programming in the large; that is, as an aspect that logically follows programming in the small and requires sound knowledge of procedural programming.
eptacom.net/pubblicazioni/pub_eng/wirth.html

>implying graduates know how to program
There are people that wants to pursue software engineering that, after 2 years, still struggle with the basics of computer programming.
They literally cry that C++ is too hard and they wish they could do python all day long.

I say what OOP mainly adds is the idea of world modeling. That's core to all of them.
Most propose it's real-world modeling. That's broadly what's taught too.
But that's one of the most stupid ideas around.
If you knew c++ you'd have sympathy. It's not the language for the problems they face. They're CS students. They don't have performance concerns and they're taught to not think about platforms usually.

People say that when you can't do something, you become a teacher.

But anyways, I think OOP is better when developing in plural, while procedural it's best when you are developing alone.

Since, one of the bases of OOP is "incapsulating"(English is not my main language) where you don't need to know the implementation to use a class, while in procedural programming, you need to know how the functions(?) operate between eachoter

>you need to know how the functions operate between each other
Procedures sure. Functions no.
Also OOP encapsulation isn't being done anymore. Graph out your class hierarchy if you only do proper message passing (requirement for encapsulation) and you'll quickly see how Java and the like don't facilitate this at all.

But that's wrong
You don't need to know how a function does something to use it
You still need to know "what" a function does before using it, but same goes for objects and their methods

Take in consideration this example:

I'm developing a browser, I'm assigned with developing the parser for CSS.

In procedural programming you would need to know what parseCSS() returns, in OOP you could just implement a parser object witouth knowing how the other parsers work: parser.renderCSS()

OOP is procedural.
OOP is extremely good at letting *anyone* write code in a project and also have that code stricken from the project at a later date.
Businesses need to work around the real problem that pajeets and literal retards write code for their projects.

Unless this is a point about autocompletion (which is very silly). You're missing the fact that any method called on an object must leave you aware of the relative state of the object. If this is represented by types you're left with compile time errors if you've made the wrong assumption. If you have methods on an object you'll be left with runtime errors. And of course not every interface will have you handle types in this very safe manner. Things like math for instance don't have explicit order of computation because the intent varies. But if we consider parsing and sanitizing data these steps could be made separate with no risk of anyone forgetting to sanitize due to type safety.
Functional have stronger guarantees for what you touch follows the api provided usually. To replicate this in oop you'd probably have some system that declares methods invalid for calling at compile time to check that those calls aren't made when they can't be made.
I'm not aware of languages that do this.

People use and teach OOP as glorified structs

Why would a parser do rendering? How do you write renderCSS() in OOP without knowing what your parser does?
You're missing the full story. We start with a CSS file, readFile() to get a byte or character stream, parseCSS() to get an AST, and renderCSS() to use that AST.
In OOP, we start with a CSS file, a FileReader with read() to read bytes, a Parser with parseCSS() to return a CSS object, and a Renderer with renderCSS(). You need to know how CSS object is structured.
This is fundamental to programming. You need to know how your data is structured. There is no getting around that. This is "data > code".

>implying procedural and OOP are even meaningfully different
autism

So, sure game developers know how every functions operates? No, someone makes the math, and someone makes the renderer, I was trying to say this

And this has nothing to do with OOP.
What are you proposing here? That subsystems can't be abstracted in procedural languages?

No, I'm saying OOP is far more abstract and "useful" in group projects. GROUP.

>If procedural programming is so superior

Nobody says that

Yes I know that's what you're saying but your motivation doesn't hold up. That's the problem.
The reason you've presented is the abstraction for subsystems. Your idea is probably that it's easier to present an interface and then work to it for part of the group while the implementers work on the other side of the interface.
Which can easily be done in any language I can think of.

If I were to look for ups to OOP here it's that if you have developers separately developing the same thing an interface usually gives you a very simple switch for the different implementations. Of course that's hoping the compiler devirtualize your functions or performance doesn't matter. And I'm sure anyone can think of simple code edits to make this work trivially in other languages. In C you might link a different file for instance.
But it's not as trivial as sending down a different object that shares interface obviously. That's hopefully just ~two LOC change. Admittedly linking a different object is just changing your build flags but I prefer working in code.
>oop is far more abstract
I know you're just barfing words now but this absolutely doesn't help group projects if it were true.

>nobody says that
Not trying to pass value judgment but here's the engine director at insomniac games and recently joined unity to get their engine performing decently.
youtu.be/rX0ItVEVjHc
If you follow along with this he's detailing procedural programming. Not even functional. (though confusion on that can be forgiven)

OOP simplify management of code monkies.
>every major organisation that writes new software (not maintains old shit software) use OOP?
And you're blind

People use all paradigm all the time for they serve different purpose.

OOP is procedural programming... Are you fucking dumb

I'm confused by why you people say things like this.
The implication is using procedural programming but NOT OOP in contrast to procedural programming with OOP.
OP is asking why someone would not do OOP but still procedural programming.

How is this so hard to understand? When did you last talk to a human being?

When shit goes wrong and you need debugging or expand the functionality, you absolutely need to know the data flow
I work with old and new systems (SQL Java js ts Scala) and every day curse the people who do oop for oop sake. Simple functions that could been implemented in half a screen instead go back and forth between 4 files.

Myself, I never once declared a class in my life apart from uni exercises

>Simple functions that could been implemented in half a screen instead go back and forth between 4 files.
Yes, I'm not crazy!

Because autists be autists. You should always use paradigm and language best fitted for your needs.
Need something that will just run and perform a specific task? Procedural.
Need something complex that require state retention? OOP.
Need to write something for parsing some data and return some other data, all without maintaining an internal state? Functional.
Mind you that use cases for those paradigms often fall to more than one of them.

This shit happens all the time. I'm refactoring an old java codebase right now and there's so much stateful spring shit everywhere that could just be pure functions

Functional programs can persist state....

They just do it in a way that abstracts away the state such that you can do fucking magic.

OOP introduces ceremony of classes and couples the data with how it's processed. Saying that OOP is exactly equivalent to procedural is to imply that OOP is a superfluous and unnecessary abstraction. It is an unnecessary abstraction to the Von Neumann architecture of computers, which is about data flow and instruction routines, in contrast to objects interacting in a modelled world. Thus I assert that procedural is a better abstraction than OOP as to how computers fundamentally work.

OOP is essentially a form of procedural. It's essentially procedures grouped into instantiable objects.

You mean functional, and well, that's actually what powers basically every production concurrent / distributed system right now. And that includes multicore applications. Maybe they're not ALL written as pure functions, but the stuff that runs in parallel and maybe not in a set order so it can run FAST with no delays? That's usually functions.

>People use and teach OOP as glorified structs

What else is there to it?

I smell the awful odor of "god object" up to here.

If your reasoning holds true I shouldn't have to learn how data structures work because there's the STL to do the work for me.

use mixed paradigms depending on what you're doing. it isn't that difficult. purely functional, purely OOP, pure anything just sucks and single-paradigm code is just for academics to jerk off to