Java Is Underhyped • Hacker News Board

Re: Java Is Underhyped

#741

Post by kaba0 » Sat, Apr 17, 2021, 1:45 PM UTC

chriswarbo wrote: post #739

kaba0 wrote: post #580

Earlier quoted context omitted.

Alt insert generate equals method, select fields, ready. Or use a record. It is such a minuscule part of the language, that it simply doesn’t matter compared to every other line of code, lib, ecosystem. You may imagine how much more productive you are that this language has sane equals, but it is not even a reasonable constant factor.

> Alt insert generate equals method, select fields, ready. This sounds like you're not programming in the Java language, you're programming in some sort of graphical macro language which compiles down to Java (presumably built-in to an IDE of some sort?). The fact that people resort to such things is evidence that this is a valid criticism of the Java language.

For data only classes, records are an existing solution. For non-data classes you have to specify what equals means. Is two database connections to the same db equals? No, even though they may have the exact same fields.

Re: Java Is Underhyped

#742

Post by Retric » Sat, Apr 17, 2021, 1:59 PM UTC

relaxing wrote: post #735

Retric wrote: post #591

Earlier quoted context omitted.

I don’t know where you would even look for that kind of statistics for companies that might use Java. That said, America has: 1,829,875 companies with 5-9 employees 779,922 companies with 10-19 employees 467,634 companies with 20 - 49 employees 170,749 companies with 50 - 99 employees Of that a few are pure software companies, but it’s far more common to want to automate something. Which often means outsourcing it, b…

Clearly you’re not going to arrive at a good answer starting from first principles. Industry research groups have the numbers, but they’re locked behind paywalls. Starting from the other end, the Stackoverflow survey has 50% of devs identifying as full-stack. Most surveys have Java as the #2 programming language, where it’s been for the last 20 years. That says nothing about how those devs are organized among teams,…

Their 2020 survey has: “About 55% of respondents identify as full-stack developers, and about 20% consider themselves mobile developers.”

I always took that kind of a breakdown to mean most website developers where full stack with embedded etc being their own categories. With majority full stack teams including various specialists as needed, which fits my experience over the last 20 years.

However, Android is Java and is frequently used as a front end. As things grow I normally see teams split by system, so I can see mobile being split off as their own team becoming more common even if it’s the still the minority. That said, it’s teams managing the backend teams which would be considering Java vs NodeJS and based on that 55% I think most teams are familiar with JavaScript.

Re: Java Is Underhyped

#743

Post by pjmlp » Sat, Apr 17, 2021, 2:04 PM UTC

for_xyz wrote: post #717

BiteCode_dev wrote: post #663

Earlier quoted context omitted.

So you are in the very niche use case where: - you need a GUI - you need perf beyond what Python is capable and you identified it clearly in advance - you can't use numpy / multiprocessing / cython, pypy or they won't give you the perf you need - you can't find a main hotpath you can optimize with a 5 lines c or rust extension and write 99.99% of your app in python. Or you don't want to bother. If you ever find yours…

No, he is in need of writing production quality software together with his medium to big sized dev team and he doesn't want to introduce maintenance burden into his project 10 years from now. Software will get improved during it's lifetime and not overwritten from scratch every 2 years.

With external contractors arriving to work on a foreign code base just for a couple of Jira tickets as per department budget.

Re: Java Is Underhyped

#744

Post by ta988 » Sat, Apr 17, 2021, 2:57 PM UTC

cutler wrote: post #680

the_gipsy wrote: post #337

Earlier quoted context omitted.

I'm talking about a maven project I have to use sometimes at work. Let me walk you through all the shit I had to do: - Install and set the right java version system-wide - Copy some config files for the project system-wide (granted, this is not java specific, but still) - Click in some IDE menu to enable some build settings - Click in some IDE menu to install some "Lombok" plugin - Click in some IDE menu to select th…

You left out Gradle installed/downloaded options, Gradle version, Gradle JVM version, Gradle plugin auto-upgrades and the unholy mess this lot can create.

This is why we virtually all use the ./gradlew script that manage all of that by itself on every platform... No global installation of gradle should ever be done.

Re: Java Is Underhyped

#745

Post by otterley » Sat, Apr 17, 2021, 3:05 PM UTC

hn_throwaway_99 wrote: post #26

I was a Java developer for about 15 years, then switched to Node and Typescript about 4 years ago. I think this author is going to be up for a rude awakening when it comes to the benefits of nominal typing, as this is the area that I couldn't disagree with more. I've commented about this before, but structural typing in Typescript makes it so much easier to refactor and to get one existing piece of code to confirm to…

Is this because the automation tools for performing such refactoring don’t work well? Or were you trying to do this kind of work manually?

Re: Java Is Underhyped

#746

Post by otterley » Sat, Apr 17, 2021, 3:11 PM UTC

eyelidlessness wrote: post #625

I think the discussion about TypeScript, and particularly type guards, really misses the point. Structural typing and manual type narrowing is basically what you’d do anywhere you don’t know some data’s type in the first place—for instance when you get some JSON from an external service. It just happens that that’s fairly common in JS/TS. It’s also a natural consequence of TS explicitly choosing not to expose its typ…

I really like the fact that you have to declare when a class implements an interface. I consider it a valuable feature in Java. It’s a tremendous boon for documentation because it makes finding compatible classes much easier. Documentation indexers make this a snap, and it makes it easy for IDEs to autocomplete for you.

I have spent more time than I ought to have trying to find conforming types in TypeScript and Go code through trial and error. Fortunately I get feedback pretty quickly in my editor, but it is still a frustrating exercise. I want to build mechanisms, not solve jigsaw puzzles.

Re: Java Is Underhyped

#747

Post by Pet_Ant » Sat, Apr 17, 2021, 3:18 PM UTC

doctor_eval wrote: post #684

Pet_Ant wrote: post #453

Earlier quoted context omitted.

What is wrong with Optionals?

Optionals can be null, so dereferencing them can still cause an NPE. Also the syntax is horrible. I know the excuse that they are just meant to be used to wrap the return value of a function that might be null, rather than as a guard against NPEs, but that just means we’ve got a crappy, verbose Optional class ... and NPEs. It was the most half assed attempt to fix the billion dollar mistake [0] anyone could have come…

Sorry but of course Optional can be null because of Java’s type system. Objects can be null, Optionals are objects. I’d rather it have been different from the beginning but now that it’s here it’s really not something that should change. Just never let anyone get away with returning a null for an optional... though I can imagine the scenario where in. A framework that might cause it to happen. To have special rules for Optional in Java is the wrong answer for a blue collar language at this level of adoption and age. They said they never want to make a change as big as generics again.

Re: Java Is Underhyped

#748

Post by reader_mode » Sat, Apr 17, 2021, 3:41 PM UTC

oftenwrong wrote: post #726

reader_mode wrote: post #329

Earlier quoted context omitted.

>the syntax, although not the most succinct is fairly easily readable and maintainable by other developers I dislike that people conflate simple languages with easy to read code. Low level verbose abstractions make code harder to read - going through the layers of IFactoryRepositoryLocatorBullshit because the language abstractions suck doesn't make it easier to read code. It makes the code more accessible, in the sen…

"IFactoryRepositoryLocatorBullshit" really has nothing to do with Java the language. That's just how some developers choose to design their programs. What specifically is Java terrible at? I find Java to be as expressive as most mainstream languages. Certainly no less expressive than, say, Python or JavaScript.

>Certainly no less expressive than, say, Python or JavaScript.

Java can't even have a free standing function without 6 lines of boilerplate minimum and 2 levels of indentation to start.

Nominal static typing with weak generics and no almost no compile time programming support - you end up mucking with reflection or code generation if you want to do anything metaprogramming related or non trivial higher order functions - JavaScript and Python just deal with it at runtime, and if you need to type it out - you can still generate types that convey to the user what the result will be (the underlying code doesn't have to be typed)

Re: Java Is Underhyped

#749

Post by daptaq » Sat, Apr 17, 2021, 4:08 PM UTC

kaba0 wrote: post #608

daptaq wrote: post #390

> Java simply feels good to write. A lot of this is due to the craftsmanship JetBrains puts into IntelliJ IDEA The issue with Java is that you need an IDE for it to be usable. That's not an argument for Java itself.

It needs an ide as much as any other language. Java programmers are just lucky that they have the best IDEs around.

Go was perfectly usable without an IDE, before gocode broke. And I'd still rather program C without any help than Java.

Re: Java Is Underhyped

#750

Post by eyelidlessness » Sat, Apr 17, 2021, 5:54 PM UTC

otterley wrote: post #746

eyelidlessness wrote: post #625

I think the discussion about TypeScript, and particularly type guards, really misses the point. Structural typing and manual type narrowing is basically what you’d do anywhere you don’t know some data’s type in the first place—for instance when you get some JSON from an external service. It just happens that that’s fairly common in JS/TS. It’s also a natural consequence of TS explicitly choosing not to expose its typ…

I really like the fact that you have to declare when a class implements an interface. I consider it a valuable feature in Java. It’s a tremendous boon for documentation because it makes finding compatible classes much easier. Documentation indexers make this a snap, and it makes it easy for IDEs to autocomplete for you. I have spent more time than I ought to have trying to find conforming types in TypeScript and Go c…

> I really like the fact that you have to declare when a class implements an interface. I consider it a valuable feature in Java. It’s a tremendous boon for documentation because it makes finding compatible classes much easier. Documentation indexers make this a snap, and it makes it easy for IDEs to autocomplete for you.

In some contexts I miss this in TS, in others I find it unnecessarily limiting. Probably an even split. Though I find myself wanting nominal types more for primitives (sure email is a string, but not every string is; or is this number really an unsigned int?).