21:48 the reasoning is facinating.
"OOP thrived in an age of monoliths. But program units are getting smaller. They don't need as many internal boundaries. They are often coupled by less strongly typed schema."
I understand where he's coming from, but on the other hand it sounds like he's trying to avoid saying "maybe that OOP thing isn't all it was cracked up to be".
I think that is more descriptive and less prescriptive.
I’ve never seen a codebase ever really use OOP in an enterprise setting. Just spaghetti and meatballs architecture. Meaty god objects “services” with long strings of structs.
Or more about boundaries, like in less Monoliths, and more micro services and container deployments including cloud functions like AWS Lambda and Azure Functions. And "coupled by less strongly typed schemas" is more of a fact statement, but is it really a good thing?
Software Engineering will not progress into real Engineering, until it starts building on the past instead of throwing away past lessons. OO was about many things but particularity about code reuse. Is that also a bad thing?
I haven't had a chance to listen, but if he said those exact words they certainly seem to imply the rest of what OP said.
EDIT: I have now listened, and I'm with OP on their interpretation. Goetz doesn't say the exact words that OP used, but he definitely expresses each idea and means what OP says he means.
The hypothetical return type for Future using ADTs was interesting - this seems almost Rust-ish. The distinction between a return Value and an Exception really is often unnecessary and complicates things.
I struggle with this one because exceptions are a perfectly good solution. The compiler will tell you when you are not handling a failure case. And if exceptions are unchecked, then you won't get a compiler warning but at least failures will be obvious at runtime.
Why push java towards this 'failures as return values' when we already have a solution? Yes, you will be able to get the compile-time safety by immediately using switch on the return value, but what if you don't? Exceptions are a completely sound solution, failures as return values can easily escape detection.
No-one likes having to think about the error cases, it feels like it complicates things. But we need to stop seeing exceptions/try/catch as something to eliminate and realise that this approach is one of the best innovations of Java. Using return values, or monadic approaches to error handling, are fundamentally unsafe when you have a mixed paradigm language. Far too easy for the programmer to do something wrong, so we're relying on discipline again and not the compiler. In other words, back to square one.
It's working out well as a 'forever' language: I can understand and use java code from the dawn of time (aka late 90s, but more realistically 1.5, 20 years ago), and Goetz seems to being doing well keeping that going. The challenge is adding any new features, but they are maintaining a reasonable cadence.
At some point I imagine they will have to remove or at least isolate and disarm some ubiquitous core features (e.g. serialisation and synchronisation).
Unfortunately these pushers were not strong enough to get Java to add null-safety. "Everything can be null" is the by far biggest daily headache of working in Java codebases.
JSR-305, checker framework, Optional are all half-baked workarounds evidenced by the lack of their adoption.
Thankfully, the Java Community Process works pretty well, and it's not just Oracle pulling the strings. JEPs and JSRs are the primary drivers of Change in the Java world, and they are largely driven by the Java Community Process and its many members.
Readit News
I’ve never seen a codebase ever really use OOP in an enterprise setting. Just spaghetti and meatballs architecture. Meaty god objects “services” with long strings of structs.
Software Engineering will not progress into real Engineering, until it starts building on the past instead of throwing away past lessons. OO was about many things but particularity about code reuse. Is that also a bad thing?
EDIT: I have now listened, and I'm with OP on their interpretation. Goetz doesn't say the exact words that OP used, but he definitely expresses each idea and means what OP says he means.
Why push java towards this 'failures as return values' when we already have a solution? Yes, you will be able to get the compile-time safety by immediately using switch on the return value, but what if you don't? Exceptions are a completely sound solution, failures as return values can easily escape detection.
No-one likes having to think about the error cases, it feels like it complicates things. But we need to stop seeing exceptions/try/catch as something to eliminate and realise that this approach is one of the best innovations of Java. Using return values, or monadic approaches to error handling, are fundamentally unsafe when you have a mixed paradigm language. Far too easy for the programmer to do something wrong, so we're relying on discipline again and not the compiler. In other words, back to square one.
Then you switch on the value at some other point in time. It's still AsyncReturn<V>. Why do you think safety would get lost?
> Exceptions are a completely sound solution, failures as return values can easily escape detection.
How so?
At some point I imagine they will have to remove or at least isolate and disarm some ubiquitous core features (e.g. serialisation and synchronisation).
JSR-305, checker framework, Optional are all half-baked workarounds evidenced by the lack of their adoption.
Deleted Comment
Deleted Comment