What are some legitimate arguments against Java and OOP?

That's not a problem with OOP, that's just bad design. Good design would define query objects full of optional parameters which are just an abstraction of SQL where-clauses and make use of those when querying for models.

1. There's no point in associating functions with objects. Instead of trying to decide whether it should be "hammer.attach(nail, plank)" or "nail.attach(plank, hammer)" or something else, just write "attach(nail, hammer, plank)", because why the fuck not? That way you can easily edit all the arguments as you please, without one of them being available and having to call methods on the others.

2. Inheritance is terrible, and Java is full of it. No further arguments necessary.

3. Java is verbose as fuck. It only recently got type inference. You still need a bunch of getter and setter methods to use Java standard utilities and to write idiomatic java.

4. Mutability is bad. And Java handles defensive copies badly since something as simple as a clone of an object is a major pain in the ass to do. What you end up with is most things being immutable, but on the other hand some built-in things like streams being immutable.

The hardcore evangelist sell OOP as a way to make your code look and feel like real world objects so that they are easier to work with, maintain, and understand, hence all the car inherit from vehicle style examples.

Then in reality, you inherit somebody else's MAXIMUM EXTREME OO codebase and have to debug why a WorkerFactoryFactoryCotractMaker is causing the MarshallDbObjectToFactoryMaker class to fail to dynamic dependency inject only in the Pacific timezone on tuesdays.

Grouping by type doesn't work nicely either though as you still left having to decide whether to group by parameter or by return type or to be correct you should just implement the same method on both services.

bandService.getbandByMusician(musicianId)
musicianService.getbandByMusician(musicianId)

>but no, you're actually shit at OOP, so you never considered >getMusicianById(musicianId).getBand()

Yes and .getBand() will have to perform an operation to access the band data from a service which encounters the same problem as above, unless you're just lazy loading data onto the object through a framework.

I really want to know where else you plan on putting these functions.
If they're not static. perhaps they all belong on the object representing the whole database?

Are you daft? If you're going to group by "parameter type", you better get ready to have every single "whateverByID" in one huge class, since you'd have an int for each ID.

>There's no point in associating functions with objects
there totally is
try and basic collection data structure
why type AddList(list,object) instead of list.Add(object)
its not like it incurs a runtime cost without virtualization

Java != OOP.

>It doesn't scale well
scaling well is the entire reason you use OOP in the first place
and your example is just bad design

Then you get retarded shit like virtual methods and the rest. All just so you could avoid using named imports
import List as L
L.add(item)

>2. Inheritance is terrible, and Java is full of it. No further arguments necessary.
This desu.

Attached: 1457973475584.jpg (690x610, 39K)

Java is the best

Attached: java.png (1200x2195, 116K)

obviously left out the list param here, I was in a hurry to post before captcha ran out

Your 1 is just a matter of syntax and is not inherent to OOP, plus I'm not even sure what your point about "easily editing all the arguments" is (changing the function definition is going to amount to the same number of edits no matter how the syntax for invoking it is).

Method syntax for the first argument has the benefit of being chainable. Which is more instantly readable,
value = value.add(5).subtract(10).multiply(6)
or
value = multiply(subtract(add(value, 5), 10), 6)
?

Not by literal language parameter type, but the parameter type of the database object. i.e. whether the parameter is a musicianId or bandId so everything that handles a musician object would be in the same class.

I said "without virtualization"
binding functions to types in no way requires virtual methods

Java performance and stop of world in realtime or compute heavy systems.

OOP, people end up focus in class hierarchy instead of modularity and pass message.

There's neither any harm nor any benefit to binding functions to types unless you need virtualization. It's just a matter of whether you want an implict first argument and whether you want your code base to have all functions operating on one particular type defined in the same file as the type.

In idiomatic Java, you can't edit fields of other objects directly, only the fields of the object that includes your method. That's a major hassle, why not instead keep methods out of objects and make object fields public and easily mutable? Then it won't matter which object you insert your function into, since you're not inserting your function into an object in the first place.

Nothing wrong with the second example, it's plenty readable once you become more familiar with mathematic notation. In a good language you can write your own piping operator to fix the issue.

Then it's just unintuitive syntactic sugar for named imports. And forces you to attach functions inside objects, which again makes no sense.

Polymorphics
Class = struct + Vtable

en.wikipedia.org/wiki/Virtual_method_table

Rust,Swift,Julia and more languages start to introduce structs for fast data representation.

>There's neither any harm nor any benefit to binding functions to types unless you need virtualization
yes there is you idiot, the implicit first argument makes things more natural to type, as has already been pointed out
who the hell said every function had to be a method?
sounds more like you're criticizing Java than the actual concept

what the hell does it have to do with named imports? and how does it not make sense to bind a function to a type when a function has a primary type it operates on? Like I said, look at any basic collection type and tell me it doesn't make sense for it to have methods

1. syntax ain't shit, and many things are more naturally expressed with a context(object) first.
2. learn2inheritance or repeat yourself quickly
3. >implying verbosity is bad. >implying getters and setters are idiomatic, when they are functions and could instead be fields and still be OO, so really what is your argument?
4. >mutability is bad

turbotard forgot he was working on a computer

t. Pajeet

>muh secret society

I only use C#, but won't your boilerplate GetX()/SetX(value) methods get optimized by the JIT compiler into direct field access anyway? Information hiding is one of the few good things about OOP that is fairly absent in other paradigms.

typing boilerplate isn't a good thing and hiding information isn't really a good thing either but neccessary maybe if you need to protect your code from shit programmers

Great argument, poojeet

See

good argument, I guess I'll concede everything I said

>boilerplate
That's a problem with Java and not OOP. Properties in C# are just fields with optional accessor/mutator logic behind the scenes and extremely non-verbose.
>information hiding
Do you have an actual argument as for why information hiding is bad? "Only bad programmers need it" is not an argument.

>an actual argument as for why information hiding is bad?
it's an extra consideration you shouldn't need to make

>against Java
O ne
R ich
A sshole
C alled
L arry
E llison

>That's a problem with Java and not OOP. Properties in C# are just fields with optional accessor/mutator logic behind the scenes and extremely non-verbose.
Yes, properties in C# are yet another more rule shoved into the language. Meanwhile simple languages like Lisps or Haskell can work with an extremely small set of base rules, everything is built on top of that core without adding more and more features and sugar.

Property field-methods are fixing a problem that doesn't exist if you don't do useless information hiding and don't attach functions to objects for no gain.

>attach functions to objects for no gain.
you're an idiot

No, you're suffering from dunning-kruger

>typing list.Add(object) has no benefits over AddList(list,object)

Java existed before Oracle, and any damage Oracle can inflict on it is limited because openjdk is good enough these days

L.add(item, list)

Is that too hard to type for you? Is this the greatness of OOP? Re-structure your code entirely differently, just to save yourself typing 2 characters occasionally?

I could make the same argument that mutability and const correctness is a consideration you shouldn't need to make and that anyone who isn't a shit-tier programmer should know what fields you can and can not mutate, but the truth is that that stops being the case as soon as you're working with a code base of a non-trivial size.

Access modifiers, just like mutability modifiers, makes your code easier to reason about because you don't have to stop and ask yourself if there are any dependencies in some other corner of the project relying on this field you're about to remove that you're going to break, because there's a nice little "private" label there telling you exactly what scope it has.

Simple languages like Lisps, Haskell or even C are not used to build enterprise software. People tried that before the turn of the millenium and there's a reason we stopped.

>occasionally
it's not occasionally, most of your functions will be bound to types, and your answer to that is shorten List to L, which sacrifices readability, for what purpose exactly? There is nothing actually wrong with binding functions to data if it makes sense. The only arguments are some functions have no primary data type, in which case you can make a free function, or whining about virtual functions which has nothing to do with it

>musicianService.getbandByMusician
That's retarded, well done proving his point.

mutability modifiers change the way your program actually compiles. Hiding information is just there for human concerns, which can be valid, but I'd rather just not work with shit programmers who don't need to be physically prevented from touching data they aren't allowed to

And how do you let the people who you work with know what they are allowed to touch and what chunks of code are considered internals?

via documentation or private public blocks I guess, private / public isn't so bad but writing a getter and setter for every variable is just an awful waste of time

do you know why information hiding exists?

It's not retarded though, both are equally valid given they both share the same references at the database level.

>Conflating OOP with Java
C++ is OOP is probably one of the fastest languages for realtime systems. What now?

>only response is "hurr pajeet"
So I guess this means we know won?

I guess JS is closes to a functional language being used in enterprise software. Most Java and C# stuff really is pajeet software these days, so I'd not use that as an argument.

You don't need information hiding when you forget trying to pair functions and their data. You have some data, and you pass it into a function, which you assume modifies it in the way you want. That's it. There's no need to concern yourself about any kind of private variables or object APIs. Just take data, transform it, get new data, that's it. OOP complicates this hilariously simple process for zero gain.

L.add is perfectly readable. Most things don't need to be namespaced at all, usually it's just data structure methods where you may run into conflicts. Reorganizing your functions inside classes and changing the way you call them just for the sake of being too lazy to use namespaces is dumb.

Cool, so you agree with me on the usefulness of public/private, and your idea of why getters/setters are bad is because they are verbose and a "waste of time", which is more about how Java was designed and not actually about the purpose that accessors and mutators serve.

pretty much

>n-no x4
Isn't an argument

>Most things don't need to be namespaced at all, usually it's just data structure methods where you may run into conflicts
>too lazy
You've literally never worked on a reasonable sized project in your life
There's absolutely no reason to give something a cryptic one letter namespace when the type of the object already is your namespace
you're an idiot and an embarrassment to programming

>writing copious amounts of documentation to explain which things are private isn't waste of time
>but using a simple private keyword is

Attached: 1544403590593.jpg (216x225, 6K)

Genuine question: what is the largest project you have worked on?

Java is good.
OOP is bad.

moot agrees, don't bother him about it.

Is that some lesbian Jojo?

>You've literally never worked on a reasonable sized project in your life
Projecting much, pajeet? I'm paid to work on a JS ERP and write Haskell on free time, both of which work just fine with regular namespaces. This meme of "you need OOP to structure large applications" needs to die. You need composition, pure functions and clean separation of concerns between components to structure large applications, not OOP.

You too

my wife Marie is so cute and sexy

Holy shit imagine the irony of you calling someone else Dunning-Krueger

>moot
who?

>JS
>Haskell
lmao
You don't NEED OOP to structure large applications, but you need something, and you clearly have no idea what working on a large application is like, you just parroting the Haskell dogma
Still having provided a single argument as to why binding a function to a type is bad

>bragging about having a job writing JS while talking down to others
AHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA *breathes in*

Yes, it's cool that you can accuse anonymous posters on Jow Forums of being Indian, but that doesn't answer the question? How big are the projects you work on?

Something between 50k and 100k lines, hard to say right now. How about you?

Read the thread, faggot. Ironic, considering you're defending Java of all things here. Modern JS is a decent language.

There is literally nothing wrong with being Indian.

t. white man

>Read the thread, faggot.
We did, that's why we're laughing so hard at you.

You provided an example of a function that is better as a free function because it has no primary data type. If a function has a primary data type there's no objective reason why you shouldn't be able to attach it to that data type if you wish
And if your job is programming in JavaSCRIPT you have no grounds to be talking about structuring large programs

>Modern JS is a decent language.
BRUH

LOOK AT THIS DUDE

WAIT TILL YOU SEE THE
OH NONONONONONONONONO *BREATHES IN*

AHAHAHAHAHAHAHAHAHA
LOOK AT THE TOP OF HIS HEAD
LOOK AT HIS LIPS

Attached: js.jpg (480x480, 28K)

based ohnonononono poster

Well, what's the largest program you've worked on? I already gave you numbers, now's your turn to go before talking shit about JS (basically Lisp with C-like syntax and no macros) without likely never having used modern JS or React. Are you perhaps still developing Swing apps?

There's absolutely no reason to create an entire new semantic system for handling functions that use "a primary data type" (which is a muddled definition, btw).

Oh wow, JS totally BTFO. How about not using loose equality and then wondering why it's loose?

>How about you?
Currently it's a .NET system spanning about 300k LoC split across 4 developers.

>Modern JS is a decent language.
Modern JS is still an absolute clustefuck of a language when used for anything but simple scripting or frontend web glue stuff. There's a reason anyone doing anything non-trivial has jumped on the TypeScript train.

>JS (basically Lisp with C-like syntax and no macros)
I do not have a brainlet wojak picture that can do this sentiment justice

Only 4 devs for 300k LOC? I'd estimate 30 % of those lines are just Java's verbosity and it'd be much smaller written in JS.

>There's a reason anyone doing anything non-trivial has jumped on the TypeScript train.

Citation needed

How about providing a counter-argument first, brainlet

OOP doesn't make any sense and just overcomplicates shit instead of letting the programmer do their work.

>Modern JS is still an absolute clustefuck of a language
Not even close and I can tell from lurking for so long that people on this board think 2008 when they say anything related to JS or just something spout some retarded shit they would get bitchslapped for doing in first week in unis like This board has 0 clues what JS is like today and just parrot some irrelevant garbage.

>There's absolutely no reason to create an entire new semantic system for handling functions
yes there is, it makes your code more expressive, it's really not that difficult to grasp
I'm not talking shit about JS, just pointing out that it's a scripting language, for writing unstructured code, because you clearly have no idea what working on a structured project is like, but are perfectly willing to talk about it like you are (and then you call me dunning-kruger, lol)

>I'd estimate 30 % of those lines are just Java's verbosity and it'd be much smaller written in JS.
Damn, I didn't know Java could target .NET, you absolute fucking troglodyte.

Quit LARPing on Jow Forums, finish your CS101 degree and get a few odd years of actual industry experience before you start pretending you have event the slightest insight into how professional software development works.

is this the new marie thread

Attached: marie17.jpg (2043x2112, 945K)

>writing getters and setters

Attached: marie12.png (1362x1920, 2.67M)

Attached: marie_x_nyotengu_0.jpg (1600x900, 201K)

>This board has 0 clues what JS is like today
"lol no static typing" is the only argument you need as for why it's not suitable for projects beyond a handful of files and 10-ish k LoC.

>yes there is, it makes your code more expressive, it's really not that difficult to grasp
>java
>expressive
Mangling the semantics of a language just to avoid using namespaces is not "expressiveness". Java is the opposite of expressive. You can't even use function composition in Java, meanwhile in JS it's just
const compose = (f, g) => a => f(g(a))

Next you'll tell me composition is useless, at which point you'll have proven you have no idea what you're talking about, you've been ruined by the OOP kool-aid. Try reading SICP or theory of programming languages some time.

>I'm not talking shit about JS, just pointing out that it's a scripting language, for writing unstructured code, because you clearly have no idea what working on a structured project is like, but are perfectly willing to talk about it like you are (and then you call me dunning-kruger, lol)
What have I said that allowed you to conclude I'm not used to writing structured code?

Are you projecting again?

my wife marie ready to be painted white with my cum

Attached: marie9.jpg (1575x1453, 500K)

Static typing a la C# and Java is worthless, it's only limiting and catches hardly any bugs. Use Haskell or better yet Coq if you want static types.

when the fuck did I say I used Java you troglodyte? Java is a horrible language. Who said anything about composition being bad? You're the perfect example of the Dunning-Kruger effect. You have a little bit of experience so you think you're tne times as experienced and knowledgable as you actually are.

Scripting languages are for writing smaller bits of less structured code. That's their design goal. When you write bigger programs you want shit like OOP and static typing to make things more organized

This. Type hinting is the correct answer.

Static typing works the exact same in both Haskell and C#/Java.