3 ms·
The ultimate problem with Java (and OOP too, even in the Kay's sense) is that its philosophy represents a very paternalistic approach to software development. T
by js8 6y ago
The ultimate problem with Java (and OOP too, even in the Kay's sense) is that its philosophy represents a very paternalistic approach to software development. The idea is here are these things called objects, you can't look into them, and you only have to use them the way they are designed; under no circumstances you can break them down into internal components and remix those freely.
In Java, this overall approach manifests in myriad of different ways:
- Functions and data are tied together. It's difficult to create new functions (methods) that operate on existing data, you have to inherit, and even that avenue can be closed, even indirectly because you find that you cannot actually get to some internals.
- Interfaces are tied to objects. You cannot explain to the compiler that a given class actually supports a certain other interface in the way YOU define it.
- Everything is a reference, no value types. No need to worry about the intricacies of cache management, we will handle that for you.
- No need to worry about CPU optimizations or memory management either - we will do that for you, without an escape hatch.
- You cannot change the existing operators to introduce more convenient syntax, because I said so. Any kind of "macro" - code generators, compile-time checks, conditional compilation, DSLs - forbidden.
- The class and package hierarchy determines the access to its components. No way to override this from the outside, no way to expose things that are hidden. Worse, this is implicit, for example, class method accesses an object attribute, where taking a parameter would be more convenient; this hurts reusability pretty badly.
Some of these shortcoming are only now being addressed, because people actually need to do these things anyway, in certain situations, which leads to proliferation of patterns and magical code generators.
- fsociety 6y agoThis so hard. I’m fearful when I hear things like Java being under hyped. Do people think this is the pinnacle of what software development is today? I think it’s made worse by the fact that you can program in another language, in a shitty codebase, and walk away saying “wow that language is very painful”. When in reality, it could’ve been the codebase and not the language. I see a lot of “but look at this successful project in language X”. Okay sure it was successful despite the language. Programmers are smart, we can make things work. Philosophically forcing developers into having to program in an OOP style, as opposed to having it as one of many tools, is a cardinal sin in my eyes. Same for forcing reference types. I’ll argue garbage collectors are bad too, but tbh that is more of a debatable topic.
- kaba0 6y agoI think you mistake general Objects, and their sub”class” data objects. Data oriented design is popular now, but it is just a subcategory. As a base, OOP is really great, class invariants and encapsulation is the only effective weapon against complexity (and software engineering is largely about managing complexity). Data classes that expose their internals are a great way for some program logic, but let’s say a database connection is very much not a simple data class. It does have some static data, but it should not be accessible to the outside, because then it is not safe to close/use/whatever.
- js8 6y agoActually, "data-oriented design" is very old, if you look how some old COBOL apps are written, what JCL was about, etc. But I think you completely missed my overall point about being patronising, meaning, the idea that the author of the language/library knows better than the user of the language/library. The reason why Java is so guilty of this is that its other competitors at the time (C++, Common Lisp, Python) at least acknowledged other paradigms than OOP, and were not so fundamentalist about it. (Smalltalk is a notable exception, but it is not as patronising in other ways as Java is. But in general, OOP tends to be patronising because its central tenet is that the definition of the object should alone determine its properties, they shouldn't be changed/imposed from the outside. Which is a good rule of thumb, but sometimes in practice becomes an obstacle.)