OOP more like OOPS

OOP more like OOPS.

No seriously though, fuck OOP.

OOPS? More like POOPS

haha, what a great thread.
I don't know anything about programming either.

What's the problem with OOP?

POOP

Poettering did it.

OOP? More like POO in LOO

ya ok.

and what do you propose to replace it?

explicit message passing inter-process communication to create segregation of states from one another?
polluted global states?
complex, hard to track, closures?
what faggot?

objects exist and are not going anywhere and oop is better than no oop, even if it's some gimped shit like javascript prototypal objects.

"Procedural Object-Oriented Programming", or POOP for short, is a cancer in the world of computing.

FOOP is okay, POOP is pure self-contradictory insanity.

OOP? More like POO

ironically OOP is POO in spanish

Fuck OP.

No, no lo es.

>Programación Orientada a Objetos

Shit, I was thinking in another kind of poo. Proceed gentlemen.

Apparently youve never heard of functional programming. Also F# has OOP features so you can have it both ways.

It is a meme you dingus.

You really think heavy-threaded OOP is the future with everyone moving to 8 and 16 core processors? Light-weight multi-threading is the future and functional languages do that best, and with far less code then your typical bloated Java app.

What makes you think you cannot make light weight OOP applications?
Or make it multi threaded?

Obviously some problems can be overengineered with OOP, but you can easily make mistakes with a functional structure.
It can often be harder to make it multithreaded as a lot of algorithms were optimized for complexity rather than how to best divide and conquer the problem.

Looks like a sound method of developing and maintaining software to avoid spaghetti unreadable code. Do you actually have a specific problem with it or are you just going to post pictures?

I have seen a lot more spaghetti POOP than any other paradigm.

t. brainlet

Because you are a retard who never worked with professionals.
no wonder nobody loves you.

its in portuguese.
We say: Programação Orientada a Objectos

Its disgusting, to me assembly its way more easy to learn and make stuff than this shit.

Teachers get surprised when i say C++ its easy. Then they say Java its way more easy than C++.

The world have gone mad, i say.

this
functional shills say oop is bad, then offer either nothing or shit to replace it

op kis ok?

Using it for everything.

>implying extends insinuations

oop is poo spelled backwards

>functional programming
>everything is immutable, i.e. S L O W
>finding behavior in an existing code base is like finding Waldo
>anyone can touch the data
>someone touches the data on the other side of the code base
>CRASH. BAD OUTPUT. NOW FIND THE BUG FAGGOT.

No. FP is fine for some narrow use cases. It's shit otherwise.

That said, OOP gets a bad rap because it's strongly associated with Java, which is slow shit, and Java frameworks, which are overly complicated slow shit, all used by Pajeet, who doesn't understand OOP and shits in the street.

GOOD OOP, proper OOP, OOP by someone who is not a moron, is pottery.

There are a lot of people in this thread who don't actually have jobs as programmers.

>Java is slow shit
i wish this meme would die already.
java is the fastest language that runs on a virtual machine.

yes, it's slower than low level languages, but that's how you pay for portability, security and stability.

OOP is great in a lot of situations. I'm glad you're such an edgy contrarian who doesn't conform to industry standard practices.

>tfw you actually like OOP

>i wish this meme would die already.
It's not a meme. On code competition sites Java will often run 50-100x slower than C for the same fucking algorithm. When you start to optimize shit in the C or C++ version the speed difference can grow to 1,000x or more.

>java is the fastest language that runs on a virtual machine.
JavaScript is faster. C#/VB.NET are a lot faster and the .NET runtime is pretty damn close to being a "virtual machine."

>yes, it's slower than low level languages, but that's how you pay for portability, security and stability.
Define "portability" because C/C++ will compile to just about anything in existence. Qt gives you a GUI on major systems.

And there are other options. Xojo gives you a high level language, native binaries, native UI controls, a nice cross platform framework, and it is WAY faster than Java.

Java is a meme.

I'm aware of functional programming which is why i said closures you dingus.

you have to have some form of state and in FP closures are the way to keep state unpolluted.

>On code competition sites Java will often run 50-100x slower than C for the same fucking algorithm

there is this thing called JIT lag tardo.
maybe you should learn it.
humorously enough, that same JIT is why java can be faster than C in some cases while still being safer.

>Define "portability"

being able to compile a static uber jar and drop it on any machine running various OSes and potentially different CPU architectures where a JVM exists.

>and what do you propose to replace it?
Nothing.
You just eliminate it, period.

>there is this thing called JIT lag tardo.
Nice try but that's taken into account.

>humorously enough, that same JIT is why java can be faster than C in some cases
Never seen it in the real world.

>where a JVM exists.
>"portable"
So C is more portable when dealing with embedded or resource constrained systems. Got it.

Also: JavaScript could fit that definition and it's faster. .NET is damn near there as well.

>Can't spell poop without OOP
hmmm...

Same in French
«Programmation Orienté Objet»

>So C is more portable when dealing with embedded or resource constrained systems. Got it.
>word padding
>different definitions of "int"
>endianness
>portable

ok, kid. and you still need at least a basic libc on the target platform just like you need a jvm on the target as well, unless you're so 1337 you can just inline assembly like some cool kid which will NEVER be portable.

>Nice try but that's taken into account.
ok kid, then java wouldn't be that slow.
also clearly you're retarded if you think being able to dynamically recompile to optimize for frequent access patterns won't result in greater speeds prove you know shitall about the jvm or its power.

literally nothing

literally this.

if you don't like OOP, no one is forcing you.

you can use shit like Erlang or Elixir if you want light weight processes and IPC, with functional twists

if you want pure FP, you have shit like Haskell, which includes a very rich meta-programming feature and strict type safety.

If you want to be a literal retard and cause the next major CVE, you have shit tier procedural ASM-like garbage such as C.

Or, you can continue using OOP shit like, java, C++, etc.

there is literally nothing wrong with C

>>So C is more portable when dealing with embedded or resource constrained systems. Got it.
>>word padding
Compilers generally deal with this.
>>different definitions of "int"
The definitions are of the form "guaranteed to AT LEAST be this." If you understand that it's not a problem.
>>endianness
Only really an issue if you're doing very low level bit manipulation. If you're doing this it's for performance and Java can't match it any way.
>ok, kid. and you still need at least a basic libc on the target platform just like you need a jvm on the target as well,
And which one is on more platforms?

>
>>Nice try but that's taken into account.
>ok kid, then java wouldn't be that slow.
>"hurr durr my theory trumps observational evidence"

Java is that slow. It is consistently slower than C, C++, C#, VB.NET, and JavaScript, is often slower than PyPy, and is even sometimes slower than Python. It only consistently beats Scala and Haskell.

I was indifferent to Java performance before spending time reviewing submissions on a couple code competition sites, and would normally parrot "it's slower than C++ but still fast" because that's the meme. I would bitch any time I had to use an end user GUI Java application because they all seem slow as fuck, but I would chalk that up to Pajeets or Enterprise framework shit.

But what I've seen has blown that meme away. Java really is fucking slow. It's slow on simple algorithms. It's a fucking dog.

>also clearly you're retarded if you think being able to dynamically recompile to optimize for frequent access patterns won't result in greater speeds
>MUH THEORIES!
>WHAT...ABOUT...MUH...THEORIES!

If it helps at all, it's not enough to overcome Java's other issues. Get your nose out of some fucking book and actually test code.

And as for "access patterns", NOTHING beats understanding the CPU, caches, and cache prefetch algorithms, and writing your C function (or assembly) accordingly.

inconsistent int sizes

>Java really is fucking slow.
source or gtfo

t. benchmarking pro

also you're literally wrong if you think C is more portable than a JVM. You literally need a full-blown virtual machine framework like LLVM, a strict standard and a shitload of man-hours put into compilers, standard libraries and cross-platform compatible kernel API

Excuse me? One plus about C is you always know exactly how many bytes you're taking up and can specify. Do you use int for everything like a retard instead of uint8_t for small loop counters and size_t for array indexes etc.?

except when struct padding comes up.

face it, if you want a consistent C experience you need some IR, like what LLVM gives you.

>except when struct padding comes up.
It never comes up unless you're a retard.

To pick one site:

* Sign up on HackerRank.

* If you don't care about participating or earning points: just pick some challenges, click the Leaderboard tab, and confirm that you want to see other solutions and don't care about earning points. Once you view other solutions or the editorial you can't earn points for your submission.

* Now copy/paste C, C++, and Java solutions off the leaderboard into their code editor and run them. Check the times.

Java is horrible.

>JIT lag is horrible
not really.

to be fair, did you try AOT compiled Java?
you know that OpenJDK made this if you don't mind gimped long running performance but don't want JIT lag.

>t. benchmarking pro
Ignore the real world all you want. It still exists.

>also you're literally wrong if you think C is more portable than a JVM.
What language can target more platforms right now today? By that definition C is more portable.

>everything is immutable
>someone touches the data on the other side of the code
>CRASH

could you elaborate?

>uint8_t for small loop counters
That's fucking stupid. All of the arithmetic is done as int anyway due to integer promotions, your inhibiting compiler optimisations by using an unsigned type, and it's not totally portable.
If you need a small integer, just use int. There is very little reason to use anything smaller, except for members of structs and whatnot.

the real world rarely has to worry about speed in most cases, since there is always going to be a 40-50ms delay in almost any network and you have load balancing, caching and clustered systems to handle large traffic volume.

>oh no, Java isn't in this machine
>go to the internet
>download Java
>Java is now portable

OOP is undisputedly the best way for game programming, but beyond that, I don't see a reason for it.

You mispelled ECS

true

OOP has been through so many iterations and re conceptualizations (remember when inheritance was its killer feature?) that it barely even means anything anymore.

>What language can target more platforms right now today?

what the fuck do you mean?
so your hello world horse shit C can build anywhere? good for you?

Java jars can literally be compiled on any JDK--ignoring nonfree J2E bullshit, and run on virtually any major--relevant, platform that Oracle or OpenJDK have made a JVM for.

this is portability. you don't need inline asm or rely on kernel or libc specific ABI or APIs, you don't need external toolkits which have to be built specifically for your platform which have to handle shit like different window servers, DRM/DRI infrastructure, etc.
you literally go on Maven central, dl some jars/classes, and the fucking Oracle devs make it jus werk. you don't have to do virtually anything.

that is real portability kid

>it's the JIT lag I swear!!!
God damn you are a broken record. You really believe nobody thought about that? They are either accounting for it or it's too small to be relevant. You can prove this by running a hello world app. Which is the first thing I did the first time I saw an algorithm take 100x longer in Java than C and thought "can this be right???"

>to be fair, did you try AOT compiled Java?
>muh portability means Java is best!
>did you try discarding portability???
If we're trashing Java's famed portability then why not use C++?

>moving the goal posts
>pajeet attitude on performance
This is why we have web pages that push the TDP limits of phones and desktop apps that take 13% of the CPU to blink a fucking cursor.

>ECS
>used by a handful of literally whos who never published their code, automatically assumed to be good because it's not OOP

>what the fuck do you mean?
Exactly what I said. Is English a second language for you?

>"platform that Oracle or OpenJDK have made a JVM for."
And there's your problem.

Depends on the architecture.
x86 has a few special encoding for 8-bit operations (and even smaller for eax particularly) so you can save instruction bytes.
And on x86_64 you get unsigned zero extension to 64 bit for 'free' (on movs), so it can often be advantageous to use them over int since it's 32 bit on all x86_64 targets.

using uint8_t for loop indexes usually doesn't do anything since the counter will likely be stored in a register and the 8bit registers are simply aliases to the lowest byte of the bigger ones anyway

how does it actually inhibit compiler optimizations?

t. someone saying run some one shot java source code off some meme benchmarking/coding e-peen site.

and ya no shit AOT is garbage, which is why JIT lag is irrelevant for any real system using java.

Immutability does not solve the same problem that data hiding solves in OOP.

so instead you have to rely on Apple devs or GNU devs to build a compiler/VM toolkit like GCC or LLVM for you?

wow, such a shocking distinction. it's still ignoring literally everything else I said.

That's not important. Arithmetic on chars/shorts are done as int. It's called integer promotion.

>how does it actually inhibit compiler optimizations?
It can't assume that it won't overflow.

How does reading a value cause a crash? Keep in mind that the only way a function can touch a value on the other side of the code is if that variable is passed the entire way down.

IT AIN'T THE JIT LAG FAGGOT.

There are challenges on that site where C solutions finish in 0.02s and Java solutions finish in 2s. Are you going to tell me JIT lag is 1.98s? My reply is going to be "try hello world." Now where's your JIT lag?

Java. Is. Slow. Deal with it.

>That's not important. Arithmetic on chars/shorts are done as int. It's called integer promotion.
If it's assigned to an 8 bit variable you can use 8-bit ops, since a promotion and demotion would be redundant.

>How does reading a value cause a crash? Keep in mind that the only way a function can touch a value on the other side of the code is if that variable is passed the entire way down.

I'm not talking about crashes. I'm talking about you doing something with a variable that ultimately gets passed to me in the wrong form or with the wrong data.

So you're using java to make one shot software and claiming JIT lag doesn't cause any problems even though JIT plays an important role in Java's performance.

* Count the number of targets for C.
* Count the number of targets that can host a JVM.
* Compare the numbers.

Nothing else you have to say is relevant for the following definition of portability:
"How many systems can the language currently target?"

>* Count the number of targets for C.
this is irrelevant since that doesn't imply all of your C code is API, and very strongly unlikely to be ABI, compatible when the JVM is both of these.

thus java source code and binaries are more portable

>trying this hard

Their timer either does not include JIT lag, or JIT lag is so low as to be irrelevant. It is not the reason Java gets blown out by so many other languages, and royally blown out by C/C++.

>I'm not talking about crashes
>CRASH. BAD OUTPUT. NOW FIND THE BUG FAGGOT.

>ultimately gets passed to me in the wrong form or with the wrong data
Could you give me an example? This sounds like an issue with static vs. dynamic typing and unrelated to functinal vs oop.

Looking at the original comment, the language in question was F# which provides more static guarantees than C#.

Another thing to add:

For a platform where a compiler currently doesn't exist, how long would it take to port one over?

C is gonna win over Java there as well (in fact Java has no chance since JVMs are written in C++).

But that's the point. FP isolates the problem so that you know if you got the wrong value the problem is in that function and not on outside state. You can't expect it to prevent all bugs ever.

>seriously using a task that executes in 0.02s for a benchmark
Try one that lasts a non-trivial time period, kiddo

POO in spanish

Programación Orientada a Objetos

Retard. Every hear about actors? There's this thing called concurrency that's all the rage.

The idea of objects (basically a dynamic struct) isn't bad its when a languages forces you to use them for everything. Sometimes only a function isn't needed. Not an interface. Not a class. Just a function. But no instead everything has to be described as a class.

I'm guessing that you've only ever programmed in Java or C#.


Every hear about object capabilities? If you were to have prototype-based objects that shared their properties vis-a-vis capabilities you could have your cake and eat it too.

Also bear in mind the fuckton of overhead that objects and classes take while simultaneously over-complicating even the simplest of tasks. Read the OOP considered harmful essay.


tl;dr you're a faggot

>There are challenges on that site where C solutions finish in 0.02s and Java solutions finish in 2s.

This is so fucking retarded. Post the specific challenges and the code, instead of saying 'there are cases' and trying to imply it's what usually happens.

Yes.

The point is it claims to solve one set of bugs...which aren't really a problem in OOP either...while making it more difficult to solve another set that OOP solves almost completely.

It gets worse for Java when you run the code locally and feed in test data that's larger then their limits allow.

this, it's basically what I said here OOP is fine but not everything is an OOP problem

A C T O R S
C
T
O
R
S

I think it's the same in any SVO languages, including all Romance languages.
We say "Programare orientată spre obiecte" in Romanian

so explicit message passing and "lightweight" processes?

Erlang is slower than Java, fact.

>The idea of objects (basically a dynamic struct) isn't bad its when a languages forces you to use them for everything.

this isn't a bad thing if your workflow demands composable modules with a strict provide and require interfaces. this is the case for actual enterprise software.

>If you were to have prototype-based objects that shared their properties vis-a-vis...

so more explicit message passing overhead. good for you.

ok kid

I never programmed functionally. What is so great about clojure, Haskell vs Java?

>this isn't a bad thing if your workflow demands composable modules with a strict provide and require interfaces. this is the case for actual enterprise software.

What is the diamond problem?

Enterprise software or any other software for that matter does not require using class-based OO. Only an idiot would think that class-based OO is a swiss army kinfe.

>so more explicit message passing overhead. good for you.

Capabilities are less overhead than class definitions. Capabilities also provide superior security via an unforgeable token. Look at the exokernel project. They made a system faster than any modern OS. Faster and more elegant than Plan9. Java can't do that.

I know that you haven't read about capabilities btw. Nice try.

clojure is a meme. if you like writing out your own AST, like what all lisp languages are, go for it but it's not incredibly fun or useful.

haskell is super cool language that really leverages the type system to solve certain problems and ensure correctness.
plus you have stuff like guards, recursion etc.
Only downside is it's very strictly fp and any stateful laden problems are going to depend on complex "monads" to handle which is the FP way of being procedural.

a lot of system haskell is going to be loaded with shit like do, etc, as well. at the end of the day FP is just a different way of trying to abstract programming, but it doesn't mean it's very useful way of solving that problem.

From my experience with other functional languages:
>closer to mathematical description of the problem
>universal polymorphism (contrasting with java's flawed generics)
>comfy type system
>pattern matching
>better encapsulation with abstract data types
I suppose Clojure and Haskell also should apply to those points (at least Haskell, since Lisp is a specific language family).

no i haven't because it sounds like a meme and at best.

also yes the diamond problem is a realistic problem with class systems, using inheritance, which is why, like everything, you have to know when to denormalize. it's also why java doesn't let you have multiple inheritance.

your shitty "capabilities" problem just sounds like a reinvention of CORBA style pluggable components, which still comes to the same solution. strict provide and require interfaces.