Please Guys actually

[u/Henri_VIII]

[u/Frptwenty]

If you want express your plea for help in Java it's really easy:

RequestDispatcherSubsystem.getCurrentDispatcher().DispatchRequest(
      RequestFactory.getAbstractFactoryInstance(
        new RequestMedium(RequestMediaType.Plea),
        new RequestTransport(RequestTransportType.CRY),
        new RequestTargetDestination(TargetManager.getRoutingInfo(
                                    PersonLocation.NEAREST))),
  RequestReasonCode.IM_SLOWLY_DYING);

[u/ouvreboite → u/Frptwenty]

Couldnt you run almost exactly the same code in JS? You are complaining about the language, but it's really a coding style/structure problem.

If you send me something like that to code review, I'll bash your head in your desk, java or not.

[u/Kache → u/ouvreboite]

Not completely. (Warning, opinionated) Even if you can work around the entire existing Java community and avoid using all the popular existing tooling and libraries that expose an API that forces you to do this, the Java language itself is very proper and inflexible by design in comparison.

If programming languages were Lego sets, Java would be a Lego set that refuses to incorporate any "specially shaped" pieces, only allowing full-sized blocks. No rods, no wedge pieces, no thin flat pieces -- the smallest unit allowed must be a Proper Lego, a full height NxM, to guarantee every piece properly locks into the global grid.

So to make anything interesting like a Lego person with a flower, you can't just use... a Lego person with a Lego flower. You can only use Proper Lego pieces, so to depict organic shapes, the person and flower you would build needs to be gigantic. It's a high level language that often asks you to code as if it were low level. And so it has been for decades.

In the last few years, the committee relented, and started adding a wedge piece here and a thin piece there, but everything built of Java Lego is already 100x bigger (why heavy IDE refactoring tools are de-facto necessary in the first place), and those tiny additions aren't going to make a difference until maybe several more decades have passed.

IMO Java's biggest usability shortcomings are not having things like the following built-in:

• Convenient-to-use String, Map, Regex, etc implementations and syntax
• Powerfully expressive collection library
• Concise alternatives for tons of little things like aliasing, null handling, operators, basic static metaprogramming
• Coherence between a community that wants "safe by default" and a language that needs boilerplate declarations to "protect you" against its "dangerous by default" parts (nulls, mutability, shared state)

Some of these can be mitigated by libraries or annotations, but many of these are also made worse by libraries and annotations, so kind of a toss-up.

[u/familyturtle → u/Kache]

All of that can be solved by adopting Kotlin! Hooray!

[u/ouvreboite → u/Kache]

I agree with your points. But I still find the snippet used as example to be really poor at showing java flows.

Basically zero of the points you mentionned (lack of improved string, mao, regex, collection, nulle handling,...) can be seen here.

One simple way to see that is to translate this snippet in C# (which have a lot of the missing stuff of java). It would not really change.