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