5 ms·

I've been using java since Pre-1.0 and professionally since 1999 and I don't see checked exceptions as being particularly high up the list of java issues. Even

I've been using java since Pre-1.0 and professionally since 1999 and I don't see checked exceptions as being particularly high up the list of java issues. Even with all the functional stuff they almost never seem to really create a major issue. My biggest issue with Java is just the way they've caved and constantly added new stuff that is always grafted on so it's never quite as good as a language that focuses on that programming paradigm from the start. But none of the problems in the language compare to the scale & scope of the problems caused by Java's default developer & architect culture. The culture is terrible... everything gets overcomplicated, overabstracted, etc. and you've got charismatic charlatans convincing wide swaths of developers to misuse and abuse language features in ways that have made a lot of people hate the language and have produced a lot of buggy and hyper inefficient code. Java itself doesn't have to be bloated, slow, buggy, and a massive memory hog. But the java developer community has continually made decisions to structure their java software in a way that makes that the default condition of Java systems. The way the Java language constantly gets new giant features grafted on plays into this.. everyone jumps on the latest language addition and misuses it for a few years before they come to understand it. By the time it's understood there's something new to move onto and abuse. Java became everything about C++ it was originally supposed to simplify.

jimbob45 6y ago
> My biggest issue with Java is just the way they've caved and constantly added new stuff that is always grafted on so it's never quite as good as a language that focuses on that programming paradigm from the start. Isn’t that basically the #1 issue with C++? They needed more and more features to compete with newer languages and, in the end, the language feels like a Swiss Army Knife. It’s got a tool for every situation but it’s ultimately impossible to grab and use with all those tools making getting a grip impossible.
- Guvante 6y ago
  I think most of C++'s additions have avoided these problems in the way Java ran into. C++ is pretty clear on the right way to do things at a given point in time. You will run into a similar problem when working with old code, you need to decide whether to abandon the new features to stay consistent, rewrite your program to make it consistent and new or do something in between and be inconsistent. The problem with C++ is that the prevalence of macros and #include make backwards compatibility effectively impossible to patch around. So you end up having to support ancient C++ code working as it was written decades ago working exactly the same. You can't even use file level flags because the object file in almost every case is going to #include old code. The compiler can't stop you from doing things the wrong way due to this. You could have other tooling that warns you that your code is making X mistake but the compiler can't enforce that or assume that you don't make that mistake due to this extreme backwards compatibility requirement. Side note: backwards compatibility in C++ is great and fundamental as it prevents fragmentation of the language between different incompatible dialects. The requirement alone doesn't fundamentally cause C++'s problems it just eliminates the easiest way to solve them. (Assuming Python 3 was easy)
  - tsimionescu 6y ago
    I wouldn't agree at all. I think that for all its worts, Java is a fundamentally simpler language than C++ (well, basically every language in any kind of use is fundamentally simpler than C++). With the exception of generics a long time ago, Java hasn't really added any major language - changing features. Stuff like lambdas, try-with-resources, even annotations, are only minor quality of life improvements to things people were already doing. Project Loom (fibers) and value types will probably be the largest additions to the language in its history, we'll see how they pan out. By contrast, C++ has several ways of doing absolutely anything - 4 kinds of pointers (pointers, references, r-value references, unique/shared pointers), 3 ways of creating functions (top-level, functor, lambdas), 3 ways of initializing objects (construcor, copy assignment, initializer list), and on and on. A variable in C++ is characterized by a type, const-ness, volatile-ness, mutability (if it's a field), being a value, reference or rvalue reference, visibility (if it's a field of a class), and probably others that I'm missing right now.
    - Guvante 6y ago
      I didn't say C++ was a better language or more easily used. I said the specific problem called out about Java didn't occur to C++. I would go into detail about your other comments but it looks like you never actually dived into the language just looked at the complexity of its syntax and got annoyed.
      - tsimionescu 6y ago
        I think Java is much closer to having one right way to do things. In C++, there are still code-bases that don't use std::string, and not (just) for backwards compatibility reasons. I wasn't commenting on the syntax, but the semantics. All of my examples are cases where there are legitimate choices to be made, with different trade-offs,which themselves depend on other choices. I admit that I have very little professional experience with C++, but I have some hobby esoterism, and I have read quite a bit about the language. It is very expressive and can be quite marvelously simple and powerful, but that comes at a very high cognitive cost while working with it. This is especially true when you have a piece of code that contains a bug - that is the time when you need to think about all of the semantics of the code, even the ones you would normally ignore, because you already know someone did something wrong, so now you can't rely on how things are supposed to be.
barrkel 6y ago
The reason for the complexification is the culture of unit testing, and in particular cargo culting that idea to mean every class needs a corresponding test class, every method needs at least one corresponding test method, etc. In order to tests classes in isolation like this, all dependencies must be injected, so they can be stubbed or mocked. Because there's no universally available IoC framework or baked-in functionality, everyone takes the library approach to DI, which means factories of various levels of abstraction, and an excess of parameters. But in practice most production Java systems do run with an IoC container, which in turn makes more fun things possible - AOP, interceptors, automatic transactions, all manner of magic. (There's no doubt that checked exceptions were a mistake, to my mind, but the mistake is being repeated in Rust, so I guess that lesson hasn't been learned. But perhaps all checked exceptions needs is a better type system to manipulate the error types through the control flow graph. We'll see.)
- mabbo 6y ago
  > In order to tests classes in isolation like this, all dependencies must be injected, so they can be stubbed or mocked. This really boils down to which school of testing you follow. London (Mockist) vs Detroit/Chicago (Classicist). [0] is a good article on the different views of testing. Made me think more about it. I find that using fewer mocks, and unit tests that integrate many classes (vs one set of tests for each class) makes Java programming more fun- but it is very much a Detroit school way. And that's okay, but it's good to really think about the differences. [0]https://medium.com/@adrianbooth/test-driven-development-wars-detroit-vs-london-classicist-vs-mockist-9956c78ae95f https://medium.com/@adrianbooth/test-driven-development-wars...
  - flerchin 6y ago
    Good article/comment. Thanks!
- x87678r 6y ago
  > AOP, interceptors, automatic transactions, all manner of magic Magic stuff like this makes maintenance a nightmare. All these random attributes turn regular code into a 4d jigsaw puzzle - the complexity OP is talking about.
stickfigure 6y ago
The Java community is so enormous that it has lots of different cultures. It's easy to pick on the enterprise architect yadda yadda culture because, well, they deserve it. But there are people doing FP in Java, realtime financial in Java, embedded systems in Java, games in Java... there are just a LOT of Java programmers out there. Stop talking about the Java community like it's a monolithic thing. It's far too big for that.
devin 6y ago
I recommend Brian Goetz’ talk about language stewardship. I don’t think what you’ve said here is true, and it kind of bums me out because some of these features took years to develop so they wouldn’t break people on ancient versions. That deserves much respect and appreciation. https://m.youtube.com/watch?v=2y5Pv4yN0b0 https://m.youtube.com/watch?v=2y5Pv4yN0b0

jimbob45 6y ago

> My biggest issue with Java is just the way they've caved and constantly added new stuff that is always grafted on so it's never quite as good as a language that focuses on that programming paradigm from the start. Isn’t that basically the #1 issue with C++? They needed more and more features to compete with newer languages and, in the end, the language feels like a Swiss Army Knife. It’s got a tool for every situation but it’s ultimately impossible to grab and use with all those tools making getting a grip impossible.

Guvante 6y ago
I think most of C++'s additions have avoided these problems in the way Java ran into. C++ is pretty clear on the right way to do things at a given point in time. You will run into a similar problem when working with old code, you need to decide whether to abandon the new features to stay consistent, rewrite your program to make it consistent and new or do something in between and be inconsistent. The problem with C++ is that the prevalence of macros and #include make backwards compatibility effectively impossible to patch around. So you end up having to support ancient C++ code working as it was written decades ago working exactly the same. You can't even use file level flags because the object file in almost every case is going to #include old code. The compiler can't stop you from doing things the wrong way due to this. You could have other tooling that warns you that your code is making X mistake but the compiler can't enforce that or assume that you don't make that mistake due to this extreme backwards compatibility requirement. Side note: backwards compatibility in C++ is great and fundamental as it prevents fragmentation of the language between different incompatible dialects. The requirement alone doesn't fundamentally cause C++'s problems it just eliminates the easiest way to solve them. (Assuming Python 3 was easy)
- tsimionescu 6y ago
  I wouldn't agree at all. I think that for all its worts, Java is a fundamentally simpler language than C++ (well, basically every language in any kind of use is fundamentally simpler than C++). With the exception of generics a long time ago, Java hasn't really added any major language - changing features. Stuff like lambdas, try-with-resources, even annotations, are only minor quality of life improvements to things people were already doing. Project Loom (fibers) and value types will probably be the largest additions to the language in its history, we'll see how they pan out. By contrast, C++ has several ways of doing absolutely anything - 4 kinds of pointers (pointers, references, r-value references, unique/shared pointers), 3 ways of creating functions (top-level, functor, lambdas), 3 ways of initializing objects (construcor, copy assignment, initializer list), and on and on. A variable in C++ is characterized by a type, const-ness, volatile-ness, mutability (if it's a field), being a value, reference or rvalue reference, visibility (if it's a field of a class), and probably others that I'm missing right now.
  - Guvante 6y ago
    I didn't say C++ was a better language or more easily used. I said the specific problem called out about Java didn't occur to C++. I would go into detail about your other comments but it looks like you never actually dived into the language just looked at the complexity of its syntax and got annoyed.
    - tsimionescu 6y ago
      I think Java is much closer to having one right way to do things. In C++, there are still code-bases that don't use std::string, and not (just) for backwards compatibility reasons. I wasn't commenting on the syntax, but the semantics. All of my examples are cases where there are legitimate choices to be made, with different trade-offs,which themselves depend on other choices. I admit that I have very little professional experience with C++, but I have some hobby esoterism, and I have read quite a bit about the language. It is very expressive and can be quite marvelously simple and powerful, but that comes at a very high cognitive cost while working with it. This is especially true when you have a piece of code that contains a bug - that is the time when you need to think about all of the semantics of the code, even the ones you would normally ignore, because you already know someone did something wrong, so now you can't rely on how things are supposed to be.

barrkel 6y ago

The reason for the complexification is the culture of unit testing, and in particular cargo culting that idea to mean every class needs a corresponding test class, every method needs at least one corresponding test method, etc. In order to tests classes in isolation like this, all dependencies must be injected, so they can be stubbed or mocked. Because there's no universally available IoC framework or baked-in functionality, everyone takes the library approach to DI, which means factories of various levels of abstraction, and an excess of parameters. But in practice most production Java systems do run with an IoC container, which in turn makes more fun things possible - AOP, interceptors, automatic transactions, all manner of magic. (There's no doubt that checked exceptions were a mistake, to my mind, but the mistake is being repeated in Rust, so I guess that lesson hasn't been learned. But perhaps all checked exceptions needs is a better type system to manipulate the error types through the control flow graph. We'll see.)

mabbo 6y ago
> In order to tests classes in isolation like this, all dependencies must be injected, so they can be stubbed or mocked. This really boils down to which school of testing you follow. London (Mockist) vs Detroit/Chicago (Classicist). [0] is a good article on the different views of testing. Made me think more about it. I find that using fewer mocks, and unit tests that integrate many classes (vs one set of tests for each class) makes Java programming more fun- but it is very much a Detroit school way. And that's okay, but it's good to really think about the differences. [0]https://medium.com/@adrianbooth/test-driven-development-wars-detroit-vs-london-classicist-vs-mockist-9956c78ae95f https://medium.com/@adrianbooth/test-driven-development-wars...
- flerchin 6y ago
  Good article/comment. Thanks!
x87678r 6y ago
> AOP, interceptors, automatic transactions, all manner of magic Magic stuff like this makes maintenance a nightmare. All these random attributes turn regular code into a 4d jigsaw puzzle - the complexity OP is talking about.

stickfigure 6y ago

The Java community is so enormous that it has lots of different cultures. It's easy to pick on the enterprise architect yadda yadda culture because, well, they deserve it. But there are people doing FP in Java, realtime financial in Java, embedded systems in Java, games in Java... there are just a LOT of Java programmers out there. Stop talking about the Java community like it's a monolithic thing. It's far too big for that.

devin 6y ago

I recommend Brian Goetz’ talk about language stewardship. I don’t think what you’ve said here is true, and it kind of bums me out because some of these features took years to develop so they wouldn’t break people on ancient versions. That deserves much respect and appreciation. https://m.youtube.com/watch?v=2y5Pv4yN0b0 https://m.youtube.com/watch?v=2y5Pv4yN0b0