5 ms·

> And most devs hating on Java are using an IDE written mainly in Java (all the JetBrains ones): the irony of that one gives me the giggles. The IDE that's wri

by ilyt 3y ago

> And most devs hating on Java are using an IDE written mainly in Java (all the JetBrains ones): the irony of that one gives me the giggles. The IDE that's written in Java most likely shares nothing with Java ecosystem parts they "hate" (I'm guessing all of the EJB, applets an general 90's Java enterprise stuff). Only irony here is you thinking it is. The 90's Java was a thing to hate. Running fat complex app server with bunch of code-as-XML for configuration just to run simple API app. IDEs are not doing that (althought Eclipse was a bit of a monster of glued in parts) > Did anyone in the mid to late nineties / early 2000s really discover Java and Java applets and thought: "Java applets is the tech that'll catch on, I'll invest in that" and not invest in Java itself? ...entirety of management it seems, it was the most popular hammer for the problem for quite some time in enterprise. Hell, we still have some less than decade old servers needing java applets for KVM

jen20 3y ago
I assure you code as XML has not disappeared from enterprise Java.
- piokoch 3y ago
  It has not disappeared from enterprise and this has nothing to do with Java. XML is still very good as a document format, with powerful validation capabilities (XSD) and powerful language to do transformation of documents (XSLT), searching documents (XPath). It is still used for a reason. In addition there are standard ways of encrypting/signing XML documents.
  - jen20 3y ago
    Those aren’t the parts that are used though - it’s the Spring XML as the replacement for the “new” keyword that is more likely to be found than XSLT or XSD.
abraxas 3y ago
Ironically, deployment, management, monitoring and security of a single (even clustered) EJB app server was a much more straightforward affair that today's cloud based Rube Goldberg machines that I encouter in practically every "modern" enterprise app.
- immibis 3y ago
  Yep. For small projects, why is it so hard to have a "deploy to server" button next to "run locally" in my IDE?
- taeric 3y ago
  I have been explaining to folks how OpenAPI is basically WSDL-lite. And is building up to be as big, at their current velocity. Kubernetes and friends, it is hard not to see as non JVM Glassfish servers. I remember WAR files being far easier to reason about than the current bundle setups we have today. SAR files were an amusing stab at the same thing, complete with the server managing deployment/startup order. I still don't want to go back to that time, mind you. Is probably why I'm so hesitant on the current attempts.
- ilyt 3y ago
  Seriously, I work in ops with a side of coding and in order of "most pleasant" to "most annoying": - Go and similar "one binary". Bonus points if static files are also embedded - "Just a JAR with few parameters" - Anything that comes pre-packaged in OS. Perl with OS-provided libs. - Enterprise Java with code-as-xml for config. More pleasant if we're not the ones managing the XMLS - C/C++ apps with reasonable deps that don't need re-compiling half of OS - Bare containers. Shit visibility without a lot of tooling but at least we don't have fight deps - k8s. Complexity of system rarely pays off with the relatively simple apps our devs are deploying and need even more tooling for good visibility - Ruby outside of container - just fucking kill me. A bunch of requirements for libs in system just to compile "gems" (why those cunts can't call it libs like everyone else), long startup, leaks memory, took them 10+ years to make a web server that's not completely shit... - Python - if I see something is in Python I try to find alternative solutions. I swear half of the install instructions either just don't work or shit all over home/system dirs. The absolute clusterfuck of py2-3 migration didn't help either, thankfully it appears its finally over. Bonus demerit if instructions mention setup.py. Tho to be fair I didn't tried recently, maybe it is better
watwut 3y ago
> The IDE that's written in Java most likely shares nothing with Java ecosystem parts they "hate" Most vocal java haters I had met were JavaScript programmers who knew basically nothing about Java. Their hate was purely cultural - they learned on discussion forums that they should hate java. But, they had literally zero knowledge whatsoever.
- eternalban 3y ago
  > purely cultural oh, I got one to admit he was "intimidated" by Java. Note: there is a subset of developers who have either hit one of Java/JVMs limitations, or, subscribe as a matter of professional judgement and taste to a school of programming (say FP) that is not a good fit to Java and JVM's orientation (classes, OOP). This subset is an informed subset and their feedback is reasonable and at times has helped Java/JVM move forward.
- Xenoamorphous 3y ago
  It’s funny but a lot of JS haters are Java devs. Which also don’t know a thing about JS, or at least think JS looks like in the 90s, with callback hells and whatnot.
  - pkphilip 3y ago
    I know both Javascript as well as Java. Java trumps JS by a mile
- tincholio 3y ago
  I don't particularly like Java (but I did love it back in 98 or so when I came across it, coming from C++), but it's mostly due to the proliferation of OO monstrosities created by architecture astronauts. The language itself is ok, if too verbose. The JVM is awesome when you use something like Clojure on top of it.
osigurdson 3y ago
>> bunch of code-as-XML for configuration Code as json or yaml is fundamentally the same while being nicer to look at (yaml at least).
- The_Colonel 3y ago
  It's a step back in a way. Code as XML had DTD with on the fly validation and autocomplete. JSON and YAML are still playing catch up in this area.
  - osigurdson 3y ago
    I have lots of biases against XML. For me it is nearly personified as Steve Balmer. However, it is rather funny to see people who hate XML yet love html (or even more absurd XAML). The autocomplete feature makes XML somehow not completely horrible as you can easily define a schema and get a kind of mini language with zero effort. Eventually the mind removes the tags and you are just left with the content. However, I see text formats that describe tree structures are all fundamentally the same. It is impossible for json, yaml to be waaaay better than XML as it is the exact same thing.
- ilyt 3y ago
  It's in a way more terrible as it usually is templating language + YAML So you need to navigate pitfalls of YAML (or bear ugliness of JSON) all while learning a templating language. All because someone decided "Users will not want to learn Python for DSL, let's give them YAML"... Every single tool that went that route has that problem and every single one would be better served just picking <language> (Lua is nice and embeddable, just saying) and using it as DSL.
pkphilip 3y ago
For the past several years, the Java enterprise development is very, very easy compared to the mess that is node.js nonsense. And if you are not happy with the JEE environment, you can continue to use frameworks like micronaut, quarkus etc. For instance, in Quarkus, you can have a full REST application in about 12MB of RAM and running on the Graalvm. In Spring (often looked at a heavy framework), this is the code required to write a full REST endpoint: @SpringBootApplication @RestController public class DemoApplication { @GetMapping("/helloworld") public String hello() { return"Hello World!"; } }
_ea1k 3y ago
> The IDE that's written in Java most likely shares nothing with Java ecosystem parts they "hate" IDK, I think the irony is you thinking IDEs wouldn't use those patterns. I bet you'll find tons of weird interfaces and abstractions in IntelliJ. It is a huge and complicated code base.

by ilyt 3y ago

jen20 3y ago

I assure you code as XML has not disappeared from enterprise Java.

piokoch 3y ago
It has not disappeared from enterprise and this has nothing to do with Java. XML is still very good as a document format, with powerful validation capabilities (XSD) and powerful language to do transformation of documents (XSLT), searching documents (XPath). It is still used for a reason. In addition there are standard ways of encrypting/signing XML documents.
- jen20 3y ago
  Those aren’t the parts that are used though - it’s the Spring XML as the replacement for the “new” keyword that is more likely to be found than XSLT or XSD.

abraxas 3y ago

Ironically, deployment, management, monitoring and security of a single (even clustered) EJB app server was a much more straightforward affair that today's cloud based Rube Goldberg machines that I encouter in practically every "modern" enterprise app.

immibis 3y ago
Yep. For small projects, why is it so hard to have a "deploy to server" button next to "run locally" in my IDE?
taeric 3y ago
I have been explaining to folks how OpenAPI is basically WSDL-lite. And is building up to be as big, at their current velocity. Kubernetes and friends, it is hard not to see as non JVM Glassfish servers. I remember WAR files being far easier to reason about than the current bundle setups we have today. SAR files were an amusing stab at the same thing, complete with the server managing deployment/startup order. I still don't want to go back to that time, mind you. Is probably why I'm so hesitant on the current attempts.
ilyt 3y ago
Seriously, I work in ops with a side of coding and in order of "most pleasant" to "most annoying": - Go and similar "one binary". Bonus points if static files are also embedded - "Just a JAR with few parameters" - Anything that comes pre-packaged in OS. Perl with OS-provided libs. - Enterprise Java with code-as-xml for config. More pleasant if we're not the ones managing the XMLS - C/C++ apps with reasonable deps that don't need re-compiling half of OS - Bare containers. Shit visibility without a lot of tooling but at least we don't have fight deps - k8s. Complexity of system rarely pays off with the relatively simple apps our devs are deploying and need even more tooling for good visibility - Ruby outside of container - just fucking kill me. A bunch of requirements for libs in system just to compile "gems" (why those cunts can't call it libs like everyone else), long startup, leaks memory, took them 10+ years to make a web server that's not completely shit... - Python - if I see something is in Python I try to find alternative solutions. I swear half of the install instructions either just don't work or shit all over home/system dirs. The absolute clusterfuck of py2-3 migration didn't help either, thankfully it appears its finally over. Bonus demerit if instructions mention setup.py. Tho to be fair I didn't tried recently, maybe it is better

watwut 3y ago

> The IDE that's written in Java most likely shares nothing with Java ecosystem parts they "hate" Most vocal java haters I had met were JavaScript programmers who knew basically nothing about Java. Their hate was purely cultural - they learned on discussion forums that they should hate java. But, they had literally zero knowledge whatsoever.

eternalban 3y ago
> purely cultural oh, I got one to admit he was "intimidated" by Java. Note: there is a subset of developers who have either hit one of Java/JVMs limitations, or, subscribe as a matter of professional judgement and taste to a school of programming (say FP) that is not a good fit to Java and JVM's orientation (classes, OOP). This subset is an informed subset and their feedback is reasonable and at times has helped Java/JVM move forward.
Xenoamorphous 3y ago
It’s funny but a lot of JS haters are Java devs. Which also don’t know a thing about JS, or at least think JS looks like in the 90s, with callback hells and whatnot.
- pkphilip 3y ago
  I know both Javascript as well as Java. Java trumps JS by a mile
tincholio 3y ago
I don't particularly like Java (but I did love it back in 98 or so when I came across it, coming from C++), but it's mostly due to the proliferation of OO monstrosities created by architecture astronauts. The language itself is ok, if too verbose. The JVM is awesome when you use something like Clojure on top of it.

osigurdson 3y ago

>> bunch of code-as-XML for configuration Code as json or yaml is fundamentally the same while being nicer to look at (yaml at least).

The_Colonel 3y ago
It's a step back in a way. Code as XML had DTD with on the fly validation and autocomplete. JSON and YAML are still playing catch up in this area.
- osigurdson 3y ago
  I have lots of biases against XML. For me it is nearly personified as Steve Balmer. However, it is rather funny to see people who hate XML yet love html (or even more absurd XAML). The autocomplete feature makes XML somehow not completely horrible as you can easily define a schema and get a kind of mini language with zero effort. Eventually the mind removes the tags and you are just left with the content. However, I see text formats that describe tree structures are all fundamentally the same. It is impossible for json, yaml to be waaaay better than XML as it is the exact same thing.
ilyt 3y ago
It's in a way more terrible as it usually is templating language + YAML So you need to navigate pitfalls of YAML (or bear ugliness of JSON) all while learning a templating language. All because someone decided "Users will not want to learn Python for DSL, let's give them YAML"... Every single tool that went that route has that problem and every single one would be better served just picking <language> (Lua is nice and embeddable, just saying) and using it as DSL.

pkphilip 3y ago

For the past several years, the Java enterprise development is very, very easy compared to the mess that is node.js nonsense. And if you are not happy with the JEE environment, you can continue to use frameworks like micronaut, quarkus etc. For instance, in Quarkus, you can have a full REST application in about 12MB of RAM and running on the Graalvm. In Spring (often looked at a heavy framework), this is the code required to write a full REST endpoint: @SpringBootApplication @RestController public class DemoApplication { @GetMapping("/helloworld") public String hello() { return"Hello World!"; } }

_ea1k 3y ago

> The IDE that's written in Java most likely shares nothing with Java ecosystem parts they "hate" IDK, I think the irony is you thinking IDEs wouldn't use those patterns. I bet you'll find tons of weird interfaces and abstractions in IntelliJ. It is a huge and complicated code base.