5 ms·
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
by prewett 3y ago
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-kingdom-of-nouns.html https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...
- jayd16 3y agoOh 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.
- wizofaus 3y agoYou'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 are few cases where a single controller class with methods for various CRUD like operations on a particular resource type makes any 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.
- jayd16 3y ago> 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.
- wizofaus 3y ago> 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).
- BeefWellington 3y ago> 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.
- wizofaus 3y agoI 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).
- BeefWellington 3y agoThe 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.
- TeeMassive 3y agoI 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.
- igouy 3y ago"In fact there's a JVM language called The Nice programming language…" https://nice.sourceforge.net/ https://nice.sourceforge.net/
- jxramos 3y agoI'd call it OO purism, close cousin though.
- mvdtnz 3y agoYou 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.
- 000ooo000 3y agoMight 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.)
- afiori 3y agoHaving a class whose only purpose is to have a run method feels like writing () => 2
- 000ooo000 3y agoDo you put all of your source code files in 1 folder?
- afiori 3y agoI am confused on the relevance of this question
- 000ooo000 3y agoMy 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.
- afiori 3y agoMy 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)=>{...})