DUDE OBJECTS LMAO

DUDE OBJECTS LMAO

Other urls found in this thread:

stackoverflow.com/questions/10177830/optimize-nested-loop
youtu.be/0nTDFLMLX9k
youtu.be/v2Q_zHG3vqg
twitter.com/NSFWRedditGif

it's better than C++

Dude what if we like took a programming language and made it run in a virtual machine so it can't do something as retardedly simple as simulating a keypress?

What if we learnt different languages to do different things instead of learning just one language and hoping it can do everything you want.

>Objects are somehow bad

okay

if it's an object-oriented language, why does it have primitive types?
checkmate, Pajeets

>having to use objects for everything

Structs are enough for everything

>this is what C-ucks and gophers actually believe

C++ can do everything I want, though.

>implying that you can't do that in Java

you->kill_yourself(you);

DUDE FUNCTIONS LMAO
>LE LISP MEME PICTURE

t. brainlet

Name one (1) thing C++ can not do that other programming languages can.

Compile.

I'll post something I found in a reddit thread one day regarding Java hate:

// ---
Because of long method names, forced OOP and forced boilerplate code.
...That's basically it. It's just the cool kid thing to do for kids to hate on Java even though it's a great language to make things like servers and multithreaded applications with managed thread pools much simpler than something like C.
I get the feeling most of the Java hate come from either:
Memers
People who write in dynamically typed languages and static type checking fucks them in the ass.
People that don't ever write in a lower level language like C to appreciate some of the things java makes easy, or "front end engineers".
And finally:
People with actual complaints about java because of fucked up industry standards, or just hate the forced abstractions pattern which can make for some really, really bad code. When OOP is originally taught, people are taught inheritance too freely and need to understand that it's in general a bad practice to do over composition and can cause for some horrible boilerplate code passing, which can usually be solved by interfacing then defining implementations there.
The language definitely has its downs and its ups, and has developed a use case now. It's not a language to use for every scenario, but it's an industry standard for a reason.
tl;dr kiddies
--- //

also Java / OOP reigns supreme when it comes to enterprise systems

>check out job ads
>50% are java
>50% are .NET
nope

B T F O
T
F
O

Assign from void*

>2017
>getting jobs through ads
If you're not getting noticed because of your open source contributions, then you don't know SHIT about programming.

that's built into the standard library

wat

>implying anyone cares about you being able to program FizzBuzz in 50 different languages

The job I currenly have was because I made a pull request on github.

More details on this phenomenon and what kind of project was it

>object oriented

if (player.collidesWith(leftWall) ||
player.collidesWith(rightWall) ||
player.collidesWith(topWall) ||
player.collidesWith(bottomWall)) {

player.stop();
}

>imperative

if (collidesWith(player,leftWall) ||
collidesWith(player,rightWall) ||
collidesWith(player,topWall) ||
collidesWith(player,bottomWall)) {

stop(player);
}

There really isn't that much difference.

> Dude what if we like took a programming language and made it run in a virtual machine
Actually worked so well that most languages now have this as option, and for many it's the reference implementation that has it enabled by default.

> so it can't do something as retardedly simple as simulating a keypress?
Lel wat? java.awt.Robot and other means exist.

That said, I'm not even opposed to the idea that an OS wouldn't accept this. It's actually not coming from something registered in the kernel as input device - so in a way, why should a well-designed OS kernel accept it?

Sure, it was a project involving using raspberry pis for behavioral research at a local university. I noticed an error in some of the code they were using to interact with the UART and made a pull request. The guy who ran the lab (biologist) found me on twitter and sent me a message asking if I'd like to take a job up there helping him design the rest of the system since he wasn't that knowledgable about electronics or programming.

>muh collided namespace

player.stop if [leftWall, rightWall, topWall, bottomWall].any? { |wall| player.collidesWith wall }

is also object-oriented :^)

No collisions in my example.

>player.collidesWith
lmao what kind of dipshit OOP classes have you had?

Player and Walls should both be independent objects, and that statement should be a single if that passes two generic objects into a method. One being an actor, the other being a literal object (as a noun).
The actor should have passable terrain types and the object should have its terrain type (air, water, ground, crate, wall, whatever) as an attribute.
if (collision(player, terrain))
player.stop();

> If I only have three things in a warehouse, I don't need to stow them in boxes and shelves to have order of sorts
Yea, true. OOP is however for getting some order on a bigger scale.

And likewise is modern FP/OOP or FP with the right composition strategy.

Imperative is generally just a mess.

There are no different types of terrain in my example. Only walls.

>I'm retarded tho

Thanks, do you know if this happens on other kind of projects that aren't as "local", like contributing to Mozilla and someone noticing, maybe even from another company?

Then you have two types of terrain: Wall and Floor, and all you actually have to check is whether the actor object can pass over that or not. You don't need 4 separate object types for each wall.

boolean validTerrain(Actor actor, Terrain tile) {
if(actor.validTerrain.contains(tile.type))
return true;
return false;
}


Depending on how you choose to store valid terrain types in the Actor class you can make those checks a variety of ways, but the way you did it is not proper OOP design. It's bad imperative design.

I know for a long time Red Hat only hired developers who'd worked on their code base. The traditional way to get a job there was to find something you wanted to work on, put in some work on the side, and wait for one of their people to notice you.

>I lucked out by getting noticed by the right retard at the right time
>that means everyone that didn't must be even more braindead than me!!!
every womyn and koder can make a pull request and shove some fresh shitcode in

you're probably absolute trash at programming, especially since you mentioned the guy that hooked you up doesn't know a thing

How's the job search going, user?

>doing it for free until they finally hire you for minimum wage
lmao

>Then you have two types of terrain: Wall and Floor
No, can't you read? I already said there are only walls in my example.

Then you have:
Walls
and
Not walls

Two types of terrain.
You could write it so it only checks to see if it's of type Wall, but that's sloppy and again bad programming. The way you wrote it is not good OOP design, period. What happens when you DO add more than just walls? You have to go back and rewrite everything.
Compared to the example I gave, you could add 1000 more types of terrain without changing a single line.

Thanks hope senpai notices

There are not two types of terrain. Walls are not terrain and not walls is no terrain either. I have no idea what the fuck you're talking about.

>What happens when you DO add more than just walls?
Nobody except you is talking about adding anything. You're pulling criticism out your ass whilst not even knowing what the snippet was from. Why are you giving advice when you have absolutely no clue?

I'm telling you your "Object oriented" example is not object oriented, you dipshit.
Whatever, write 60-line chained || if statements instead of bothering to learn how to properly design an OO program.

>I have no idea what the fuck you're talking about.
that's because you have no fucking idea what you're doing

t. not the guy you're replying to

It IS object oriented. It even says so in post

see

>checks for collidedWith
>no collisions :DD

>It's OOP because I said so
You're a fucking retard

>so it can't do something as retardedly simple as simulating a keypress?
I might be an idiot, but wouldn't it still be possible as java is turing complete?

>object oriented is such a phenomenal paradigm that there is still no consensus about what does it mean despite being the no1 pleb filter for IT interviews (only plebs ask this question)

Object oriented was a mistake - Alan Kay

Turing-completeness wouldn't mean it's possible but the guy is an idiot. Automating keypresses is part of the Java standard library.

Why wouldn't it mean it's possible? I'm somewhat new to programming so I don't really have a good understanding of turing completeness.

Turing Complete means it can represent any algebraic formula, not that it can do anything that's possible to be done with computers. By design Java exists in Virtual Machine space, so it doesn't have direct access to the OS API (because that changes from OS to OS and would prevent the code from being portable). Instead it relies on Java's built-in libraries to interact with the Virtual Machine which interacts with the OS API. Most common functionality (including simulating keypresses) are easily done, but some things (like finding which Workspace the screen is currently in) is pretty much impossible without writing a DLL because the library/virtual machine has no command to do so.

While Turing Completeness is a form of equivalence (any two Turing-Complete command structures can perform the same set of logical things), the concept of Turing Completeness exists with respect to a certain algebraic space and that algebraic space is different from scope to scope.

Think of it like this: if you have a robot who can arrange blocks into any shape, it can only manipulate blocks that it has access to. And if you put it in a box, it can't change the blocks outside of the box into any shape because it can't reach them. Java exists within a smaller box than Assembly/C.

Collect its own garbage.

You're the programmer, its your god damn garbage.

Collect my* grabage

Can you give me an example of garbage that needs to be collected?
I've only taken the first two programming classes at my school, and they were in Java.

anytime you make an instance of a variable or object as a pointer, then it isnt removed when you leave the current frame (think functions or any time you use {}) so you have to explicitly tell the code to de-allocate the memory. If you dont do this then you risk just allocating more and more till you are using like, 80TB of ram.

Thats a super simple way of describing it, its been a while sense i have worked in C specifically, most of my knowledge of the specifics has gone sideways from lack of use.

As long as you dont create objects in nested loops you should be fine.

stackoverflow.com/questions/10177830/optimize-nested-loop

Basically if you keep creating one time use variables the GC contantly needs to delete them but cant keep up. and like says, RAM usage will shoot up like crazy, very fast.

OOP has a pretty clear definition, read about the 4 pillars of OOP. Organization of data and functions is useful.

The mistake was taking OOP way too far and forcing every problen to fit into the paradigm. Not every problem maps well to OOP, and OOP doesnt map well to multicore systems. We have to use locks and mutexs to prevent race conditions because OOP shares so much state between objects.

What maps better to hardware? Pure functions and immutable data structures that by nature of immutability do not share state and are therefore threadsafe. We only need to organize these functions and structs into jobs, then pass these jobs to threads. This is how modern game engines scale according to hardware. more threads = more concurrent jobs.

how does OOP fit in? OOP should still be used for UI work. combine OOP with MVC (model, view, controller) design pattern and UI design is very straight forward. the entry point for the engines work (the pure functions + structs) comes from user input. this happens from the controller or the model.

so you can see how OOP and functional programming work together to build modern multicore programs. source: i'm a developer.

This pretty well sums up the issue with OOP, when all you have is a hammer after all.

Yeah why does it have data at all. Checkmate data fags.

Its just making sure the code is bug-proof

No state? No bugs!

>name one thing
>*names thing*
>B-But that doesn't count!
BTFO

run without imperative declarations?

as in, not use header files. header files are completely unnecessary and a relic of the past. in c++, you cant call a function unless its been declared, which is simply a pointless burden. fucking javascript can do that, and it's autistic.

I'm starting to think that Java might actually not be that bad; I just thought it was bad because of all of the code I've seen written by my classmates, where object orientation is used, often incorrectly, regardless of whether or not it fits the situation.

>tfw another year of this torture until I'm done my CE degree

theres nothing wrong with java, its just a tool. you can use a hammer to build a house, and that makes sense. but try to use a hammer to brush your teeth. there are different tools better suited to specific jobs, like OOP.

its likely that your peers are being force fed OOP by teachers/professors that learned it in the 90s when it became very popular. and they were such bad programmers that they couldnt get real jobs, so they became teachers. basically, your teachers are probably bad and dumb.

if you are ever asked to create a 'factory' in java, dont do it.

The issue there, is that you have to use namespaces or prefix the collidesWith method with player_ or something.

I find namespaces to be clumsy. If you use an implicit namespace, it becomes difficult to look at a function and immediately know where it comes from. If you're using an explicit namespace, it's the same as just adding a prefix to the name.

java just went crazy with inheritance when it's almost always the wrong thing to do

>theres nothing wrong with java, its just a tool
INTERCAL completely negates this point. A tool can be fundamentally flawed.

>its likely that your peers are being force fed OOP by teachers/professors that learned it in the 90s when it became very popular
They don't actually teach anyone to program in my program, apart from in the first term, when you get a class that goes over the basic concepts. The principles of OO are useful if you use them correctly in situations where they apply, but no one was ever taught how to do it, so it's like watching someone on deviantart trying to make porn. Disgusting.

OO is actually a pretty nice meme compared to some of the other things that are becoming popular now, like functional programming. Trying to do commercial software with functional programming is like trying to cut a tree down with a scalpel.

>if you are ever asked to create a 'factory' in java, dont do it.
I used to do C# web dev shit and I'm still not sure what the fuck a factory is

inheritance AND abstraction.

abstraction was supposed to simplify problem solving and architecture. take it too far, and theres so much abstraction that it becomes its own problem. inheritance has the same issue.

i'm about to blow some people's minds. ready? inheritance is a form of class coupling - where one class is dependent upon another classes data and functions. inheritance DOES NOT decouple classes. rather, subclasses rely on parent definitions.

So we tried interfaces. which again, couple to classes that depend on the interface.

so we tried factories, which couple to class constructors.

OOP has no mechanism to objectively decouple classes. compare that to data passed to functions: the data is decoupled (independent), and the function is coupled only to the parameters it accepts, localizing state.

OOP is snakeoil sold by 90s programmers as a cure all, and actual smart people bought into it and cant admit they were wrong, so now we're stuck with it like an architectural herpes.

DUDE SEGFAULTS LMAO

i'm not arguing that a tool cant be fundamentally flawed, just that java wasnt originally flawed.

functional programming is how modern software efficiently scales to multicore systems. if you think functional programming is a meme, then you should look into becoming a teacher. i hated FP prior to understanding it. once i "got it", it made designing program architecture alot easier and simpler. seriously, give it a chance, it will make you a better programmer.

a factory attempts to abstract away the construction of an object, so the constructor function doesnt need to be called directly. usually this is done in conjunction with interfaces, which leads to a chain of responsibility shared across 10 files that is a nightmare to understand, debug, maintain, and extend. once you get to the point of thinking that a factory is a good idea, you've made a terrible mistake.

>java just went crazy with inheritance

No. java programmers went crazy with inheritance.

>OOP is snakeoil
>used by every major software-producing firm in the country extensively
>emulated extensively in non-OO languages such as C, especially in operating systems

love it

Mobile.

OOP is only snakeoil when idiots like you think every single problem has to be solved using an OOP paradigm
like you aren't allowed to write functions that operate on arbitrary objects, everything has to be a method because that's OOP right

If you're good enough, shouldn't you be able to start your own company or make your own worthwhile program.

organizing functions and data together is useful and smart.

forcing encapsulation and fake decoupling through abstraction is dumb.

also,
> implying normie corporations write good code
i can tell from that statement that you've never worked on an enterprise codebase.

people write bad code. put them together and ego takes over, the codebase turns to complete shit. add deadlines set by marketing team, and that shit codebase just gets piled on with more shit as fast as possible. oop and fp are part of that pile of shit.

>java wasnt originally flawed
If I go and work with any language for 10 minutes, I find a lot of things that make my angry at the language designers. The last time I programmed in Java, I got angry at the lack of unsigned types and the forced usage of classes. I don't think those are good features that benefit the language. The exception system is also badly designed, which wastes memory and clock cycles. The GC is also a potential flaw if you're tight on memory or doing realtime code that uses a ton of memory; I've seen some horrific GC stutters on Android. The lack of mandatory forward declarations also causes some horrible parsing errors.

If you can take any language, you can find several flaws with it.

>functional programming is how modern software efficiently scales to multicore systems
The multicore scaling part of functional programming is only effective when you have critical sections that don't have monads in them. A lot of commercial software requires monads everywhere because it interacts with an external system.

functional programming is a tool. Just like OO, it's very good in situations that it fits, and just like OO it's a meme. When I say something is a meme, it doesn't mean that it doesn't have a purpose; it means that idiots say that it's the only way to program. If you're trying to make a game in OpenGL (very CPU heavy, cannot be multithreaded and based largely on global state), functional programming doesn't work particularly well.

i dont think every problem has to be solved using oop. thats not what i'm saying at all. you lack reading comprehension.

functions that operate on arbitrary objects is basically functional programming, which is how the majority of the program's work should be done. i only use oop (+mvc) for ui work, where it maps nicely to the problem domain.

i was taught oop by a fag who used to work at adobe, who said that oop was the only way to program. which made me wonder why wasnt he still working at adobe, if he was such a great programmer?

lol you've worked in "an enterprise codebase" once, prolly as an intern

unsigned types are cancer.
does java have structs?
dont rely on the gc. manage your own memory like a real programmer.
agree on the exception system.
forward declarations are outdated.

> monads
no.

> interacts with external system
concurrent jobs usually sync up once work is complete, at which point data can be passed to the external system.

> opengl is cpu heavy
have you heard of this new thing called the gpu?

> cannot be multi-threaded
are you seriously making the case that no modern game that uses opengl can be multithreaded? oh i am laffin

> the best insult he could come up with
enjoy taking my burger order

No. look at java's standard library.

>especially in operating systems
especially only the VFS layer and nothing else

Just use smart pointers :^)

>completely self-negating comeback

>implying being able to run the same code on every single system for which a JVM has been implemented without touching a single line is a bad thing
>implying you can't do this shit anyway
dumb phoxposter

>unsigned types are cancer
I would argue that they are significantly better than using a signed type as an unsigned type. There are plenty of situations where there is no better alternative than using an unsigned type.

>does java have structs?
I was referring to the requirement to put all functions and data into classes. There might also be structs, but that doesn't fix the requirement to have a bunch of static classes that have no purpose being classes.

>dont rely on the gc. manage your own memory like a real programmer.
Is there a way to do that in Java? You wouldn't be able to use most classes in the standard libraries or other libraries.

>forward declarations are outdated
forward declarations prevent parsing errors. I guess they could have just designed the syntax better to prevent horrific parsing errors from the ambiguous grammar.

>have you heard of this new thing called the gpu?
you clearly have never worked with OpenGL. OpenGL is CPU heavy for some reason. You can go and find a Linux open source OpenGL implementation if you want to figure out why. I never looked into it.

>are you seriously making the case that no modern game that uses opengl can be multithreaded?
OpenGL cannot be multithreaded. You can have threads doing other things, but you can only have one thread doing OpenGL. This is part of the unfortunate design of OpenGL.

>dont rely on the gc. manage your own memory like a real programmer.
if being a "real programmer" is going out of your way to introduce more bugs and wasting time instead of working towards useful, working code for the sake of nostalgic virtue signalling than programming is truly dead

unless you're working at the systems level where its advantages still and will always shine, there is no reason for you to use that ancient 1970s language for anything but maintaining legacy code in current year

i'm simply stating that modern game engines that use opengl are multithreaded, and leverage the gpu.

and yes i have worked with opengl. and directx. and neither are cpu heavy. drawing a blank opengl window does not require significant cpu time. however, this is subjective. if you fuck up your draw calls, then its very expensive. but thats not opengl's fault.

opengl runs on a single thread, yes, but the program is free to run on as many threads as it needs to. i think we're talking about different things. normally you dont shovel game logic onto the same thread as your opengl instance. how did you approach designing your game?

If you need real time performance or low memory usage, using a GC is probably not the best choice. I've seen horrible stutters in some game projects when the GC was invoked. You can also do some optimizations if you manage your own memory.

i'm more referring to using design patterns like object pools, which allocate a number of objects upon construction, negating the need to create new objects later (and release them), which leads to garbage collection.

i'm not talking about reference counting or any of its derivatives.

certain design patterns, like obj pools, actually make the code more predictable in size and operation time, because the pool sizes are (usually) static.

I've seen plenty of applications that used OpenGL and had the rendering thread act as the limiting factor. The worst case of this is probably using Wine on DX games, where a single thread is always running at 100%.

The original point we were discussing here was that this was not a situation where functional programming benefited greatly. That was only being discussed as part of saying that functional programming is not the best way of doing absolutely everything. I don't think functional programming works as well as a low level procedural language in cases like this.

if you think functional programming isnt a good approach, i would suggest watching these two gdc talks, which discuss how very smart programming teams designed a modern game engine using functional programming:

youtu.be/0nTDFLMLX9k

youtu.be/v2Q_zHG3vqg

These are not light talks, and will take a few hours to get through, but its well worth your time.

Functional programming maps very well to multicore systems (cpu + gpu), better than oop, or declarative, or imperative, or any other paradigm. thats why its used.

also,
> using wine
found the problem