Computer Science Thread

Aside from slowdown in small programs that don't need it, why is OOP bad? Why do people imply "X fell for the OOP meme"? [spoiler]What do you think of OOP?

I could start ranting how CS is not science and how it doesn't belong to this board, but I'll take another approach instead:

Programming is not CS. Unless you are talking about mathematical optimization, i.e integer/linear programming. OOP is purely software engineering shit and belongs to .

Class inheritance polymorphism etc are usable design patterns that allow to make large programs with a lot of functionality. However I'm against it. I rather have decorator pattern with a few singletons to tie everything together. With OOP you can say Object A is a Object B I rather use Object C has an Object A and an Object B. This makes everything a lot more clear and readable. The old OOP paradigm is dying and we all know it.

I'm gonna reply to this thread because I disagree with the above poster and his claim that software development paradigms are not relevant to discussions of science and math.

OP, I have no qualms with OOP. It's main issue is that it is very easy to be sloppy, and that it shouldn't be taught until after prodedural programming.

I suppose you think single variable derivative calculus isn't math either?

>why is OOP bad?
It isn't.

>Why do people imply "X fell for the OOP meme"?
Because you are listening to /g/ memes.

it isn't though

OOP isn't bad. Retards using it for everything which is bad.

Defining a complex/quaternion/vector/matrix class and overloading arithmetic operators is nice to use. Creating sub-classes like sparse/triangular matrices is good.

Having factories that make factories that make factories that decorate ... w/e is godawful. Large class hierarchies are godawful. Wrapping functions in a class is godawful.

what do you mean after procedural programming?

what is there to "get" about procedural programming?
All programming is procedural programming.

if I write:
Clear();
a = 5;

that will always perform the clear instruction before assigning a to the value of 5 , whether you're doing OOP or "procedural".

All programming is procedural. there is no such thing as "non procedural programming" where you decide to perform the lines of code in reverse order, or a random order.

when you learn OOP you're automatically doing procedural programming each time you write a method.

what insights can you gain specifically from learning a "procedural language" before learning an OOP language?

Not him but you could easily write an interpreter/assembler to read in lines of code from memory in an order different from n

>trusting /g/ tards, ever.
the people complaining about oob are second year students who were taught c as first language and fail to grasp virtual methods and they never worked in a team.

pretty none of them has ever wrote more than 1k lines in a single project, and they have no idea what they are talking about. Yeah sure oob is useless if you need a scripting language, but it's the only way you will be able to write software that is maintainable for more than a year.

>"computer science"

>ha ha, so funny and original! What would we ever do without him!

Smalltalk was supposed to be an OS with a structured data store rather than a dumb tree of directories containing untyped programs and data. Objects were supposed to replace processes. Retards mistook OOP for an approach to compiling executables.

>There are people on this board RIGHT NOW who aren't doing everything in machine code

declarative programming doesnt follow instructions. Ever programmed in Prolog? It solves questions, rather.

>I could start ranting how CS is not science and how it doesn't belong to this board, but I'll take another approach instead:

Probably because you don't have a leg to stand on.

>Programming is not CS. Unless you are talking about mathematical optimization, i.e integer/linear programming. OOP is purely software engineering shit and belongs to .

>engineering

Looks like it still holds hombre

What else am I supposed to wrap my functions in?

OOP is bad because it only works well with top down approaches to software design because it forces you to design abstractions before you can do any work.

This by itself isn't bad but it leads to big problems when you're working on any non-trivial piece of software that will require long term maintenance. Essentially you're forced to either
>waste a lot of time and effort generalizing everything in the "correct" way before you actually begin coding, often fighting with dumb philosophical questions (should a message send itself, should it be sent by the sender, maybe some other class, etc..) and implementing generalizations that not only never get used but are hard to debug and actually get thrown out later on.
or
>reinventing the wheel every time your project grows and trying to keep the code base from becoming a garbled, convoluted, slow and buggy mess.
In either case there is often a whole lot of wasted time and effort where you originally expected to save those exact things. Big (real world) long term projects often end up not only being a mess but also being convoluted as fuck. It isn't uncommon for people to just scrap a bunch of code and rewrite a project from scratch because of unforeseen design flaws. This is something that would not be a problem if OOP really worked the way people expect it to.

(cont.)

(cont.)

The rule of thumb is:
>Really small simple projects shouldn't bother with OOP, development time is slower and there is little to gain as the project is too small to benefit from OOP anyways.
>Medium size and or short term projects that are conceptually simple and naturally lend themselves to OOP should use OOP. In other words, if it makes sense to use OOP at an abstract level and the project parameters aren't going to be changing and growing over time then this is a good way to do things.
>Small or medium size projects that are expected to change and grow over time should be written in a functional style (from an organic bottom-up approach), preferably in a functional language.
>Large and or abstractly complicated projects should probably be broken down into abstractly simple components and then approached as above.
>Other paradigms are worth looking at for domain specific problems.

You can use larger functions or even monads.

It's like Linux: people use it in the most horrendous possible ways and they blame it on OOP when they fuck up.

namespaces

Did you just assume their gender!?

Seriously though, just busting your balls mang.

Some languages like Haskell are lazy which means shit doesn't get processed in the order it's written and other shit doesn't get processed at all if it doesn't actually get used. Other languages like Node.js are asynchronous and you have to use callbacks or generators or something since shit can get processed in random orders.

Prolog is actually very procedural. Under the hood as it's searching for answers it is actually traversing search tree in order (this is where backtracking comes in). Since the order is procedural then you can manipulate the way it traverses the search tree by using cuts and often you have to if you're doing something complicated. Without using cuts you may end up in situations where useless sections of the tree are traversed countless times and thus your program fails to terminate in any reasonable amount of time, or you may end up with many variants of the same answer depending on how your predicates work.

That said, prolog is a pretty cool and powerful language if you get into the swing of abusing it's pattern matching in really clever ways.

short from the top of the head opinion: it simplifies shit, making devs lazy and dumb( check Idiocracy). OOP should be used by a small copetent group of people in order to prevent idiocracy among devs

>Under the hood
For someone in a field about abstraction, you're certainly retarded.

* competent
texting from phone...

I did describe an abstraction. There are many different implementations of prolog with different features that actually work differently at a concrete level.

The search tree however is an abstraction and you learn about it fairly early on in any prolog textbook. The only reason I referred to it as "under the hood" is because anyone who has only been exposed to a very cursory introduction to prolog (as is common with internet folk) isn't likely to have been introduced to this notion. On the other hand, any one who has written any amount of non-trivial prolog code would have to understand red/green cuts and backtracking which require the search tree abstraction as a pre-requisite.

kys yourself, retard.

OOP and "patterns" have very weak mathematical basis, if any. Functional programming and type theory are a better way to do it.

>I could start ranting how CS is not science and how it doesn't belong to this board

Yep, cryptography, cellular automatas, neural networks, genetic algorithms, calculative methods of theorem proving and data mining isn't science at all

Blaming OOP for slow programs is like blaming usage of tractors for poor farming.

No.

t. type theorist working in OOP languages.

perhaps you can elaborate and tell us what is so great about them.

I'm not claiming the superiority of OOP but the myth that they are "foundationally weak" is rubbish. Read TAPL.

It's a pretty cool concept and allows for singe pretty efficient coding. That being said, implementing it is a bitch.

>OOP

You'll have to figure it out yourself. You will run into OOP cancer in the real world, and will be in charge of trying to compile it. Then, after days of frustration going down the complexity rabbit hole because there's microclasses and methods literally everywhere breaking shit you will understand why OOP is a pile of steaming shit

Rob Pike wrote a ton about this when he was at Google in the early 2000s and they suffered from OOP cancer.

>Read TAPL.

ok, I don't have access to it right now.

They may not be foundationally weak in theory, but in practice OOP languages are pretty shit and not nearly as flexible as functional languages.