When we first learned Java in university we were taught that classes were like "molds for objects". For the prior excercises we had to make classes that had a main method and were never used to create objects, which I found confusing. But I had the same issue with abstract classes, which seemed to be molds for object creation, without the ability to be used for creating objects.

I agree that it probably doesn't matter once you get over that.

Personally issue with it (besides the pointless noise of having to make a private constructor and such) is that you can't alias them like you can with actual namespaces/modules in most languages, which becomes a pain when eg. you need functions from both Apache's StringUtils and your own StringUtils in the same file.

Ah, I suppose it can get wordy in Java. I'm more used to C# where you can alias the class name if need be.

Theres an argument that it teaches new programmers poor habits.

What poor habit and what argument?

Unnecessary wrappers. Obviously anything longer than

    print('hello world') 

is a waste. If the language violates Exupery's law why shouldn't developers?

Generally it goes with unnecessary boilerplate that gets copied around without any thought to whether it's necessary.

People who have been harmed by too much oop won't just define a function and call it. They'll define a class solely to contain that function and then call it more verbosely.

On the face of it it's not that bad but once you start tolerating a habit for doing things because that's how they're done and not because you actually think it's the right way you end up picking up all of these fragments from places where they do belong and forcing them into places where they don't.

Or at least, that's what I struggled with when I was new and insecure and wanted people to look at my code and think that I knew what I was doing because I showed evidence of knowing the dogmatic patterns, and I've seen it in others too.

Classes are basically namespaces, and trivial code doesn't need them, but quickly you do.

A lot of the criticisms being leveled here at oop actually me question their programming experience. There are many valid criticisms, but not a lot levelled here.

If all you're doing is using classes as superfluous namespacing, we'll that's hardly a threat. It's when they start having superfluous constructors that you're on a dark path. I once knew a guy who had a when-in-doubt-make-it-a-singleton habit, it was maddening to write tests anywhere near him.

Obviously that's an amateur move (and being an amateur myself I didn't have the confidence to show him a better way). But then it's never the skilled practitioners that make something look bad anyway.

The problem with Java's everything-must-be-a-class OO fundamentalism is that a computer is actually has data AND executable code. Java forces everything into a noun (class/data), but some things are actually verbs. You can these because they have awkward names, like Runnable.

See Steve Yegge's rant: https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...

Oh sure. Java should have had function pointers sooner. The functional interfaces are just ok. C#'s actions and delegates are a bit better, imo.

But the parent went so far as to say that scoping functions to a class name is bad and I just don't see it. I think a pure global scope would make Java worse.

You've never seen Java (or C#) code where a bunch of unrelated functions belong to some meaningless class like "Utility"?

I do think both languages would benefit from allowing/ encouraging namespace-level functions (C# comes close with static classes but that's pretty clearly an abuse of any logical definition of the word "class"). However I probably wouldn't use them for implementing "controllers" in web applications - while I tend to agree it's not a good use of OOP, having key information about the current request/response available via properties of the current controller (and hence kept separate from function-level parameters that represent semantics specific to the endpoint being handled) plus various built-in functionality at the framework-supplied "controller" level isn't something I'd see a benefit in giving up. But I'll admit there's few cases where a single controller class with methods for various CRUD like operations on a particular resource type makes much sense from an OOP perspective. I did think for C# what might actually work is to be able to define extension methods on the framework Controller class and have an automatic routing mechanism based on convention (e.g. if you defined an extension function "Get_Widget" then GET requests to /widgets would be automatically routed to it. Or it could be based on the namespace). But in general it would likely make the code more verbose (lack of implicit "this") for questionable gain.

> You've never seen Java (or C#) code where a bunch of unrelated functions belong to some meaningless class like "Utility"?

Is that worse than the global scope as the dumping ground?

One other benefit of forcing classes is that there's a logical place for private functions and fields. Private state is an anti-pattern to some but it's more consistent design for Java, I think.

> Is that worse than the global scope as the dumping ground?

I wouldn't have a problem with requiring everything to at least be in a namespace, though it needn't be enforced at the language level (vs a linter rule).

> You've never seen Java (or C#) code where a bunch of unrelated functions belong to some meaningless class like "Utility"?

I guess I don't see the problem here; what's wrong with this idea?

I've seen people claim "It's not OOP" but without any ability to explain why and I'd love to see the practical difference.

I don't have any problem with it not being OOP, but I do have a problem with the abuse of the concept of a "class". I also think it's rarely the ideal way to organise your code (even if the .NET core framework has examples of it - WebUtility/HttpUtility etc., and the JRE may well do too, though I can't see any obvious examples in the java.util namespace).

The entire java.util namespace is the example here.

Using static methods on a class seems perfectly fine to me; that's what they're there for. If you have a handy utility class to work around problems in the standard library, then that's an issue with the standard library; Java has this but has gotten better over the years.

I don't know about Java, but IMOE C# delegates often end up in callback hell. The events properties is just pure gasoline on the fire.

"In fact there's a JVM language called The Nice programming language…"

https://nice.sourceforge.net/

I'd call it OO purism, close cousin though.

You didn't really address the question. Because a static method on a static class is a verb, even in the kingdom of nouns. It's just namespaced. So what's the issue? From a practical point of view.

Might be heresy to come in to an OOP-bashing thread and say this, but the noun thing fits my mental model perfectly. IMHO, verbs aren't 'done' by nothing and data rarely exists without belonging to something, so it feels fine to me. I always find these discussions interesting though because clearly a lot of people feel differently (and very strongly in some cases).

(Please don't take this comment as an endorsement of OOP as practiced in the corporate world or that traumatic memory you have of an OOP codebase.)

Having a class whose only purpose is to have a run method feels like writing () => 2

Do you put all of your source code files in 1 folder?

I am confused on the relevance of this question

My obtuse point is that though sorting your source code files into various directories offers no functional benefit*, some folk find it useful from an organisational perspective. Maybe there's an element of that in housing functions an object.

*bear with me - admittedly there are languages/technologies where directory structures are required, but hopefully you get my point.

My point was that if a function in your language is

    class {public function call() {...}}

then it is going to be unergonimic to write what other languages write as

   array.map((elem)=>{...})

You can use verbs passively to do something on something else. Or you can have your program or process do it. Logically, I see no difference between:

"The HandlerCreationFactory created a Handler based on the Request." (oop)

"A Handler is created based on the Request." (passive) or "The program (or process) creates a Handler based on the Request. "

Only that the first one needs a lot more nouns, even when they look silly.

Inform7 Actions and Rules system made me reconsider the centrality of the notion of Object when it comes to dispatching (note: Inform7 reads like english). Inform7 takes a verb-centric stance, then consider the subject (i.e. "this", in OOP), then the object (i.e. the arguments to a method). You can inject more specific behaviors in an action (i.e. something akin to a multimethod in CLOS), by adding an adjective to a verb/method complement/arguments. You can even use adjectives on the verb/sentence. All of this is gathered within a rulebook associated with the verb that exists aside of the actual source code: you can write code linearly, following the natural order of a given user story from the domain you model, using multiple verbs in succession, but can still display all a verb's rule, encompassing many user stories. Most importantly, it is truely extensible because you can't add code to an action's rulebook without doing so through a rule, which has the same role as a junction-point in aspect oriented programming or even subject-oriented-programming.

https://en.wikipedia.org/wiki/Subject-oriented_programming

https://en.wikipedia.org/wiki/Aspect-oriented_programming

https://ganelson.github.io/inform-website/book/WI_12_1.html

https://ganelson.github.io/inform-website/book/WI_19_1.html