4 ms·

I can't help but wonder how much of your productivity boost was due to leaving Java vs. due to using Typescript. Java is just about the most unjustifiably verbo

I can't help but wonder how much of your productivity boost was due to leaving Java vs. due to using Typescript. Java is just about the most unjustifiably verbose language I can think of off the top of my head.

Supermancho 4y ago
It's not just verbose, but has bad choices that impact the language to have to be verbose (to maintain within it's own limitations) that results in inferior implementations. The "new object" paradigm for instantiation (instead of Class.new, or some other generator), the static keyword, the final keyword, no global scope (eg for singletons), the inability to do non-inheritance mixins without 3rd party libraries, a full pre-runtime to bypass some of these issues in the form of Spring. Many of these work against testability and JUnit just can't keep up. It's horrific and it's not going to get better anytime soon.
- kjeetgill 4y ago
  Interesting. I'd love to know a bit more about why these harm testability for you. I'm not sure I've felt the same way. Especially the global scope bit. Even statics fields are too much global scope in my opinion, not too little.
  - chopin 4y ago
    Static fields can get in the way of testability very quickly, in my experience. Even static methods can if they draw in dependencies.
  - Supermancho 4y ago
    > why these harm testability for you They harm testability for me, because I have to use java to test them. There's a larger discussion about "what is testing" and "how to properly test" which I'm not going to get in to here, but would be happy to talk about in another forum. JUnit (and all the inferior alternatives) can't properly mock them or verify how/when they are called (despite running in a closed test container, which is how JUnit executes them). If you have ever tried to deal with native methods (or FAANG libs that like to use static final methods), there's a practical barrier to how much state you can avoid in testing. That barrier is java's ecosystem itself (JVM + syntax + tooling + ethos).
- kaba0 4y ago
  Interesting how Java manages to chug along for decades on backends with arguably the biggest code bases out there (running basically most of the services at FAANG as well as outside of it), when it is so “inferior”. Empirically I would say that it does very very well on maintainability’s count.
  - Aloha 4y ago
    PHP is another one in that category.
    - Supermancho 4y ago
      PHP is still extremely testable, for now. The slow migration toward another Spring-like preprocessor, via complex annotations, is worrisome.
  - the_gipsy 4y ago
    I don't think maintainability is the reason, though.
  - wiseowise 4y ago
    That’s not achievement of Java language, but Java platform.
    - kaba0 4y ago
      Well true, but then the answer one doesn’t want to read is that the “language doesn’t matter”, at least not in any significant way. Which is in line with the famous “No Silver Bullet” article.
      - Supermancho 4y ago
        > the answer one doesn’t want to read is that the “language doesn’t matter”, at least not in any significant way. When you have an outrageous amount of effort to (what amounts to manual) testing in closed environments before release, you're fighting the language but you just don't care. > Empirically I would say that it does very very well on maintainability’s count FAANG companies don't even release data related to how program defects are detected and addressed (publicly), so the assertion is literally baseless. Given enough time and effort, you can overcome the inability to do simple things. That doesn't make the tooling better, just the perception. This is common, historically, in tech (re Mechanical Turk).
Sohcahtoa82 4y ago
Take my opinion with a huge pound of salt because I've only ever used Java for smaller projects but... A large part of Java's verbosity is optional, but it feels to me that people do it because "That's how you write Java!". But you don't HAVE to write an interface, abstract class, and factory for every class. You can just...write a class. You don't need to write a class that has nothing but an "invoke" function. You can just...write a function. You don't need 10 layers of abstraction for simple cases.
- dataflow 4y ago
  People exacerbate the problem but the language itself is pretty darn verbose too. Just look at how much code you need to instantiate a generic array for instance.
deleted 4y ago
[deleted]

Supermancho 4y ago

It's not just verbose, but has bad choices that impact the language to have to be verbose (to maintain within it's own limitations) that results in inferior implementations. The "new object" paradigm for instantiation (instead of Class.new, or some other generator), the static keyword, the final keyword, no global scope (eg for singletons), the inability to do non-inheritance mixins without 3rd party libraries, a full pre-runtime to bypass some of these issues in the form of Spring. Many of these work against testability and JUnit just can't keep up. It's horrific and it's not going to get better anytime soon.

kjeetgill 4y ago
Interesting. I'd love to know a bit more about why these harm testability for you. I'm not sure I've felt the same way. Especially the global scope bit. Even statics fields are too much global scope in my opinion, not too little.
- chopin 4y ago
  Static fields can get in the way of testability very quickly, in my experience. Even static methods can if they draw in dependencies.
- Supermancho 4y ago
  > why these harm testability for you They harm testability for me, because I have to use java to test them. There's a larger discussion about "what is testing" and "how to properly test" which I'm not going to get in to here, but would be happy to talk about in another forum. JUnit (and all the inferior alternatives) can't properly mock them or verify how/when they are called (despite running in a closed test container, which is how JUnit executes them). If you have ever tried to deal with native methods (or FAANG libs that like to use static final methods), there's a practical barrier to how much state you can avoid in testing. That barrier is java's ecosystem itself (JVM + syntax + tooling + ethos).
kaba0 4y ago
Interesting how Java manages to chug along for decades on backends with arguably the biggest code bases out there (running basically most of the services at FAANG as well as outside of it), when it is so “inferior”. Empirically I would say that it does very very well on maintainability’s count.
- Aloha 4y ago
  PHP is another one in that category.
  - Supermancho 4y ago
    PHP is still extremely testable, for now. The slow migration toward another Spring-like preprocessor, via complex annotations, is worrisome.
- the_gipsy 4y ago
  I don't think maintainability is the reason, though.
- wiseowise 4y ago
  That’s not achievement of Java language, but Java platform.
  - kaba0 4y ago
    Well true, but then the answer one doesn’t want to read is that the “language doesn’t matter”, at least not in any significant way. Which is in line with the famous “No Silver Bullet” article.
    - Supermancho 4y ago
      > the answer one doesn’t want to read is that the “language doesn’t matter”, at least not in any significant way. When you have an outrageous amount of effort to (what amounts to manual) testing in closed environments before release, you're fighting the language but you just don't care. > Empirically I would say that it does very very well on maintainability’s count FAANG companies don't even release data related to how program defects are detected and addressed (publicly), so the assertion is literally baseless. Given enough time and effort, you can overcome the inability to do simple things. That doesn't make the tooling better, just the perception. This is common, historically, in tech (re Mechanical Turk).

Sohcahtoa82 4y ago

Take my opinion with a huge pound of salt because I've only ever used Java for smaller projects but... A large part of Java's verbosity is optional, but it feels to me that people do it because "That's how you write Java!". But you don't HAVE to write an interface, abstract class, and factory for every class. You can just...write a class. You don't need to write a class that has nothing but an "invoke" function. You can just...write a function. You don't need 10 layers of abstraction for simple cases.

dataflow 4y ago
People exacerbate the problem but the language itself is pretty darn verbose too. Just look at how much code you need to instantiate a generic array for instance.

deleted 4y ago

[deleted]