501–510 of 808 posts
Earlier quoted context omitted.
I can (and often do) build from CLI, that is much smoother. I tried using vim on java, but honestly you need an IDE for all the constant code generation and incessant fixups by mouseclicks that are needed. Vim+coc is more than enough in the other languages that I use.
You're living in a parallel universe from the rest of us. IDE isn't necessary (and positively odd) for building Java.
Earlier quoted context omitted.
That is a perfect demonstration of the toxic attitude I’ve come to expect from Java fanatics.
I've just written an argument which can be verified. If you call me a "fanatic" because of writing a provable argument I can at least say I have a freedom of speech...
The amount of vitriol Java receives in the game development space is rather strong. However, whenever people dismiss Java as being a bad language, I can't help but think of Minecraft. Yes, it's one of the few mainstream titles where Java has been successfully applied, but I believe Minecraft's success was specifically because it was written in Java. With no JVM, there would have been no Minecraft mods at the level of…
> The amount of vitriol Java receives in the game development space is rather strong. Java is a language with mandatory GC, tiny objects scattered around the heap (poor locality), and no value types or low-level memory access. This makes it very poor for games (you know, other very basic ones). But they're rapidly addressing these concerns.
Expand?
Earlier quoted context omitted.
This, so much this. The value of code just working and staying working is humongous. Having code that is unchanged from Java 1.3 doing it's thing and delivering value 21 years later without needing to be touched and revisited allows us to focus on improving the code that needs to be improved. Doesn't mean we don't touch old code (change idioms, generic safe, build process etc). It means we do it when there is value t…
> C++ chances that I can compile code from 2000 without issues is minuscule. Really? I have code from the late 90ies and it compiles just fine. Do you perhaps mean dependencies? Because the issue there is the completeness of the framework and libraries around Java rather than the language itself.
So you need to get them but they are not available anymore and may depend on code that doesn't compile anymore. Due to e.g. 32bit assumptions, changes in what a 'long long' means and small hiccups like that.
Or the fact that C++ code was "almost" C++ code and not actually C++ code. Just a variant that was supported by an "almost" C++ compiler.
Not really the case for smaller utilities but larger projects originating on what is now rare equipment suffered from this.
So maybe not "miniscule" but not rare in my experience either.
Earlier quoted context omitted.
"gradle init --type java-application" Honestly I haven't had to deal with the issues you talk about in the last five years (which is as long as I've been writing java commercially, before that I was mostly a C developer). Having had recent experience with Go and Javascript/Node, I can't say either struck me as especially easier or more intuitive to get started with.
Most likely because you have dealt with them many times before that you don't notice them anymore or prevent them in the first place while setting up a project. But everytime I need to do something in Java I get bitten by this stuff, and I'm not the only one.
Maybe things have got much better in the last handful of years, I don't know. My experience of getting started with a java project in that time has been no worse (and not really any better either) than in other languages.
For my use cases, Java has all the wrong compromises: - not high level enough to compete with Python/Ruby/JS/PHP, etc - not low level enough to compete with Rust/D/Nim/Zig - not specialized enough to compete with Erlang/R/Go/Julia - not opinionated enough to compete with Lisp/Haskell So why use Java ? It's good, it's fast, it's productive, it's well supported, battle tested and documented for decades with a huge pool…
- cryptography: It has a wide range support of symmetric/asymmetric algorithms from legacy to modern ones.
- XML and SOAP with Web Service Security in particular.
- Modeling large business concepts because of static typing, Objects inheritance and polymorphism, no memory management while still being performant. I would not use Python for that but other languages can compete C#, Scala, Kotlin, maybe Typescript.
Having been around in the 1990s, I can assure you that "underhyped" is the very LAST thing I think of when Java is mentioned.
Look at their age. We've arrived in a world were young developers rediscover old tools and missed the time when Sun Microsystems brute forced Java down the throat of everyone. Heck, here were native Java CPUs, Java Smartcards and different editions like JavaME for what today is branded IoT devices. I cannot get the "write once - run everywhere"-slogan out of my head to this day. I don't even want to imagine a world w…
The ultimate problem with Java (and OOP too, even in the Kay's sense) is that its philosophy represents a very paternalistic approach to software development. The idea is here are these things called objects, you can't look into them, and you only have to use them the way they are designed; under no circumstances you can break them down into internal components and remix those freely. In Java, this overall approach m…
I think it’s made worse by the fact that you can program in another language, in a shitty codebase, and walk away saying “wow that language is very painful”.
When in reality, it could’ve been the codebase and not the language.
I see a lot of “but look at this successful project in language X”. Okay sure it was successful despite the language. Programmers are smart, we can make things work.
Philosophically forcing developers into having to program in an OOP style, as opposed to having it as one of many tools, is a cardinal sin in my eyes. Same for forcing reference types.
I’ll argue garbage collectors are bad too, but tbh that is more of a debatable topic.
Earlier quoted context omitted.
Guess I'm nobody. I created a simple Swing (desktop) app in Java a couple of weeks ago. The process was something like: Create new Java project in IDE Add no dependencies Use the built in IDE tooling to create a runnable JAR and tick the box to export the Ant build to a build.xml file. Why would I want to complicate things by adding Maven/Gradle to the mix?
And what if you want/need to add dependencies? A lot of them.
My point is there are a wide variety of application types out there, not everything is a web application, not everything needs to use a complex build and dependency management system.
Earlier quoted context omitted.
You're living in a parallel universe from the rest of us. IDE isn't necessary (and positively odd) for building Java.
You do need to be able to build from IDE when you set breakpoints to debug.
We occasionally do remote debugging at work. It’s just a matter of copy/pasting the correct JVM incantation into the IDE.