29 ms·

My pet speculation on why Java attracts this stuff is that it's actually a very robust and strongly backward compatible (and forward compatible) language that r

by api 9y ago

My pet speculation on why Java attracts this stuff is that it's actually a very robust and strongly backward compatible (and forward compatible) language that runs on a very robust VM. I can take a compiled .jar file from the late 90s and in quite a few cases I can run it right now unmodified. I can also link against it and use it in Java code pretty trivially. I can do this with modern tools and modern VMs. Then I can copy the result from an x64 box to and aarch64 box and most of the time it will run the same way. That is just amazing. Java's strength in the areas of robustness and compatibility means it can sustain a lot of complexity. You can build really insanely complicated towers of Babel in Java and they won't topple over. Java's excellent tooling means they'll even be somewhat maintainable. This transforms Java's great strengths into its great weakness. Its capability to sustain complexity means that nothing checks the tendency of sophomore programmers to over-engineer everything. In other languages over-engineered rococo monstrosities just fall over, but in Java you can actually get away with it to a shocking degree and still ship working robust code. Try that kind of over-engineering in C++ and you'll have 20 minute compile times for small projects. (I've seen this, so people still try!) Try it in a dynamic language like JavaScript or Ruby and your complex design pattern monstrosity will become a non-deterministic generator of random runtime bugs. These languages can't sustain code that is riddled with FactoryFactoryFactorySingletonFactoryObserverFactory type stuff. Java can, so the Java ecosystem is where the people who love to over-engineer go.

monocasa 9y ago
That actually makes a lot of sense. You've got VM tech like polymorphic inline caches, and the kind of speculative devirtualization and subsequent inlining that you can only get from a JIT that'll flatten these towers of complexity at runtime. And you have a simple static type system that can easily tooled to flatten it on developer mind space as well.
crdoconnor 9y ago
My pet speculation is that Java programmers are culturally predisposed to, and are typically proud of creating towering architectural ziggurats with at least 3 layers of unnecessary abstraction. It's the only language for which I've ever met "architects who didn't code". It wasn't backwards compatibility that made that happen.
- seanmcdirmid 9y ago
  Java today is used heavily in the enterprise, which thrives on utilizing marginal talent. Java didn’t look that way in the 90s, and anyways, I bet you’d see drastically different kinds of code comparing enterprise and Android.
deleted 9y ago
[deleted]
geodel 9y ago
> Java's excellent tooling means they'll even be somewhat maintainable. I think it may be otherway round. Excellent tooling seems essential for Java to succeed. Since standard JDK could not even compile a project without ant/gradle/maven etc. Java has tools to parse/filter stack traces, of course because few 1000 line vomit for a missing file, or wrong jar means one need tools to extract relevant error from stack trace. A 10 level file hierarchy to read some config data means I can't really code without full blown Java IDE.
- jpitz 9y ago
  > Since standard JDK could not even compile a project without ant/gradle/maven etc. I'm sorry, but I think you have to defend that statement. Certainly, gradle and maven do a LOT to make it easier to BUILD java projects, but compile? These tools do more to apply some common-sense patterns to project source and dependency management, so that you're only specifying the things you really need to, but, like most compilers, javac just needs to know where the compile-time dependencies are and where the source files are. The SDK is quite able to compile without a build tool.

by api 9y ago

monocasa 9y ago

That actually makes a lot of sense. You've got VM tech like polymorphic inline caches, and the kind of speculative devirtualization and subsequent inlining that you can only get from a JIT that'll flatten these towers of complexity at runtime. And you have a simple static type system that can easily tooled to flatten it on developer mind space as well.

crdoconnor 9y ago

My pet speculation is that Java programmers are culturally predisposed to, and are typically proud of creating towering architectural ziggurats with at least 3 layers of unnecessary abstraction. It's the only language for which I've ever met "architects who didn't code". It wasn't backwards compatibility that made that happen.

seanmcdirmid 9y ago
Java today is used heavily in the enterprise, which thrives on utilizing marginal talent. Java didn’t look that way in the 90s, and anyways, I bet you’d see drastically different kinds of code comparing enterprise and Android.

deleted 9y ago

[deleted]

geodel 9y ago

> Java's excellent tooling means they'll even be somewhat maintainable. I think it may be otherway round. Excellent tooling seems essential for Java to succeed. Since standard JDK could not even compile a project without ant/gradle/maven etc. Java has tools to parse/filter stack traces, of course because few 1000 line vomit for a missing file, or wrong jar means one need tools to extract relevant error from stack trace. A 10 level file hierarchy to read some config data means I can't really code without full blown Java IDE.

jpitz 9y ago
> Since standard JDK could not even compile a project without ant/gradle/maven etc. I'm sorry, but I think you have to defend that statement. Certainly, gradle and maven do a LOT to make it easier to BUILD java projects, but compile? These tools do more to apply some common-sense patterns to project source and dependency management, so that you're only specifying the things you really need to, but, like most compilers, javac just needs to know where the compile-time dependencies are and where the source files are. The SDK is quite able to compile without a build tool.