7 ms·

> The JVM is a treasure just sitting there waiting to be rediscovered. It's the result of man-centuries (man-millennia?) of work, yes, and as a result is reall

by wtbob 10y ago

> The JVM is a treasure just sitting there waiting to be rediscovered. It's the result of man-centuries (man-millennia?) of work, yes, and as a result is really, really impressive. But imagine if that much work had been put into something fundamentally great, like Smalltalk or Lisp, rather than something fundamentally okay like Java. > It really is a shame that there is so much noise and unnecessary complexity around using it. Very true. Java itself is not a terrible language (hence why I wrote 'fundamentally okay' above); it's the arcane, rococo, lunatic levels of ritual which surround it. Every time I look at Java code I'm reminded of some insane fantastic court in which one has to plead with the Minister of Small Affairs, make a sacrifice to the God of Bureaucracy, pay for a Token of Token-Paying, appeal to the good graces of the Wise Undersecretary of Vice-Small Affairs and finally spend a weekend climbing an Escher Staircase before an audience with the King, all just to get a scrap of toilet paper.

_asummers 10y ago
Java and the JVM are entirely separate beasts and should not be taken together. While most JVM code began as Java code, there are enough non-Java languages hosted on the JVM at this point that it should be looked at through the Java lens only.
- desdiv 10y ago
  >...that it should be looked at through the Java lens only. I think you missed a "not" there.
  - _asummers 10y ago
    I did indeed. Good catch!
niftich 10y ago
(Edited to clarify that I think Java was good in the very beginning, less so in the middle, and is good once again) Java started off as the Golang of the 90s: small, simple, opinionated, statically-typed, in many ways state-of-the-art, and engineered to protect the programmer from doing bad things (either due to ignorance or will). It came with a batteries-included standard library. Then, in a quirk of fate, it became very popular. Though its library provided clean abstractions, you had to chain several of them together to actually accomplish anything: this is why it was so verbose. Everyone was writing Java, but no one was sharing Java, yet. Before Apache (Jakarta) Commons, no one bothered to make wrappers for basic stuff... just like how we were writing bad JS before jQuery or underscore came out. We were caught between our own experimentation, Sun's desire to take over the desktop, and companies like IBM and Oracle that wanted to ensure they could sell commercial support for big monolithic Java appservers. When the 'Design Patterns' book came out, someone should've made a framework, but instead we sprinkled AbstractStrategyFactoryBuilders everywhere because that's what the enterprise libraries did... and it read like a bad parody of object-oriented programming, but by now, we've learned our mistake. Now that bad APIs have fallen out of favor, Java EE is nearly abandoned, Spring brought some sanity but also forced us to consider why we're even thinking about convention over configuration, Java is much, much nicer. In the Maven, Github, CI world, we can -- environment and company policies permitting -- easily pull in libraries and frameworks that allow us to actually get stuff done at the correct level of abstraction.
- agibsonccc 10y ago
  I'd argue much of that time has passed now. I used to write J2EE code. Now we have frameworks like lagom and dropwizard which make life exponentially better. I'd suggest taking another look.
- hota_mazi 10y ago
  I feel you haven't taken a look at Java in the enterprise in a long time. Spring is considered to be an overloaded bloated mess and Java EE has become lean and mean with plenty of very capable specifications and implementations (JPA, CDI, etc...). And FYI, the Design Patterns book came out before Java (1994 vs/ 1995) so I think you have your timelines confused. The early editions of Design Patterns didn't contain a single line of Java, they were mostly C++ (and some Smalltalk). Java is twenty years old, and for such an old geezer, it's adapted remarkably well (and between Java 8 and Kotlin picking momentum, its legacy seems to be well assured).
  - niftich 10y ago
    I was trying to express a lot of ideas in a small space, and I have edited it since, but it's still not as clear as I'd like. You and I agree, but I have struggled to get this point across. Spring is a bloated mess, but when it first came out it was lean new framework and a relief from EJBv1 and EJBv2. In response, EJBv3 was much better, but in the meantime Spring became the new normal, and grew into some strange swiss army chainsaw glue with now-deprecated awful xml configuration replaced by the horror of not-quite-code-but-compiled-into-the-classfile @Annotations! The 'new Spring' is Spring Boot, which was a response to this then-obscure framework called Dropwizard which showed that all you had to do was pick a handful of very good libraries get work done. Guava, Jersey, Jackson, Jetty; some decent ORM, and you're good to go. Some of these are backed by new Java specs like JAX-RS and JPA that are legitimately pretty good. I think the biggest problem Java still has in the hearts and minds of people outside the 'enterprise' is not because of Java, but because of the complexities that only manifest in environments where your code isn't 100% greenfield every time. Dependency Injection isn't something you realize you need until you realize you need it -- and then you realize you need it Really Badly. Externalized XML config files declaring reusable beans isn't something you think you need until your client is asking how they can reconfigure something in the shipped software when they can't just recompile it to what they need.
Zafira 10y ago
> It's the result of man-centuries (man-millennia?) of work, yes, and as a result is really, really impressive. But imagine if that much work had been put into something fundamentally great, like Smalltalk or Lisp, rather than something fundamentally okay like Java. The eternal irony of this is the current JVM---HotSpot---was a Smalltalk VM that Sun bought. It was an attempt to commercialize some of the work done (also at Sun) on the Self language [1]. [1] http://c2.com/cgi/wiki?HotSpotVm http://c2.com/cgi/wiki?HotSpotVm
- mikro2nd 10y ago
  Well, "an attempt to commercialise" seems to me to trivialise it a bit. The fact is that the Self research uncovered some pretty interesting things around optimisation... at the time optimisers were pretty much based on the research done in the '70's when structured languages were still quite new-and-all. The Self work uncovered that those assumptions were really quite bad when it came to OO environments. OO-structured programmes behaved quite differently at runtime. Indeed, one of the most surprising (then) results was that you really couldn't optimise all that well at compile-time, but that you needed continuous runtime analysis and optimisation do anything really effective. But when you do, then it's hella effective! Remember that we were still in an era when byte-code interpreters were viewed (mostly rightly) as woefully slow and inefficient. Sun had part-funded the Self research for quite a number of years (>5? if memory serves me) so when they found themselves with a bytecode interpreter that really needed some serious help there was a natural fit, and why should they not have gained some advantage out of some pure research work they had funded? As I recall it, most of the Self research was done at Stanford. Sun just provided money, and only much later in the project's lifetime, a home in Sun Labs ("Church" side of Sun). (All this is purely from memory, so I might have misremembered bits of it - I can go upstairs and dig out all those old OOPSLA conference proceedings if it matters.)
cageface 10y ago
If Smalltalk and Lisp are so magical then why didn't they win?
- robotresearcher 10y ago
  Because Worse is Better applies here as usual. Java was fast enough and familiar enough and the libraries were good enough and the language safe enough and Sun supported it well enough in the enterprise. Nothing else had the same combination of okayness. I never enjoyed Java but it had my half-grudging respect.
  - hota_mazi 10y ago
    > Because Worse is Better applies here as usual. It's not that simple. They lost for very pragmatic reasons: Smalltalk and Lisp were worse than Java in many ways (even smaller than Java's initial implementations, Smalltalk's binary images were undeployable in production, these two languages are dynamically typed, etc...).
    - niftich 10y ago
      [1] https://en.wikipedia.org/wiki/Smalltalk#History https://en.wikipedia.org/wiki/Smalltalk#History, scroll midway down: "During the late 1980s to mid-1990s, Smalltalk environments -- including support, training and add-ons -- were sold by two competing organizations: ParcPlace Systems and Digitalk, (...) Both firms struggled to take Smalltalk mainstream due to Smalltalk's substantial memory needs, limited run-time performance, and initial lack of supported connectivity to SQL-based relational database servers. (...)" "In 1995, ParcPlace and Digitalk merged into ParcPlace-Digitalk and then rebranded in 1997 as ObjectShare (...) The merged firm never managed to find an effective response to Java as to market positioning, and by 1997 its owners were looking to sell the business." There was also Strongtalk, a strongly typed variant of Smalltalk. The guys who wrote Self and the guys who wrote Strongtalk were both eventually acqui-hired by Sun and they were the ones who wrote HotSpot [2][3] [2] http://www.strongtalk.org/history.html http://www.strongtalk.org/history.html [3] https://en.wikipedia.org/wiki/Strongtalk https://en.wikipedia.org/wiki/Strongtalk
hellofunk 10y ago
You should not confuse or conflate Java the language with Java the virtual machine. They really are quite distinct technologies.

by wtbob 10y ago

_asummers 10y ago

Java and the JVM are entirely separate beasts and should not be taken together. While most JVM code began as Java code, there are enough non-Java languages hosted on the JVM at this point that it should be looked at through the Java lens only.

desdiv 10y ago
>...that it should be looked at through the Java lens only. I think you missed a "not" there.
- _asummers 10y ago
  I did indeed. Good catch!

niftich 10y ago

(Edited to clarify that I think Java was good in the very beginning, less so in the middle, and is good once again) Java started off as the Golang of the 90s: small, simple, opinionated, statically-typed, in many ways state-of-the-art, and engineered to protect the programmer from doing bad things (either due to ignorance or will). It came with a batteries-included standard library. Then, in a quirk of fate, it became very popular. Though its library provided clean abstractions, you had to chain several of them together to actually accomplish anything: this is why it was so verbose. Everyone was writing Java, but no one was sharing Java, yet. Before Apache (Jakarta) Commons, no one bothered to make wrappers for basic stuff... just like how we were writing bad JS before jQuery or underscore came out. We were caught between our own experimentation, Sun's desire to take over the desktop, and companies like IBM and Oracle that wanted to ensure they could sell commercial support for big monolithic Java appservers. When the 'Design Patterns' book came out, someone should've made a framework, but instead we sprinkled AbstractStrategyFactoryBuilders everywhere because that's what the enterprise libraries did... and it read like a bad parody of object-oriented programming, but by now, we've learned our mistake. Now that bad APIs have fallen out of favor, Java EE is nearly abandoned, Spring brought some sanity but also forced us to consider why we're even thinking about convention over configuration, Java is much, much nicer. In the Maven, Github, CI world, we can -- environment and company policies permitting -- easily pull in libraries and frameworks that allow us to actually get stuff done at the correct level of abstraction.

agibsonccc 10y ago
I'd argue much of that time has passed now. I used to write J2EE code. Now we have frameworks like lagom and dropwizard which make life exponentially better. I'd suggest taking another look.
hota_mazi 10y ago
I feel you haven't taken a look at Java in the enterprise in a long time. Spring is considered to be an overloaded bloated mess and Java EE has become lean and mean with plenty of very capable specifications and implementations (JPA, CDI, etc...). And FYI, the Design Patterns book came out before Java (1994 vs/ 1995) so I think you have your timelines confused. The early editions of Design Patterns didn't contain a single line of Java, they were mostly C++ (and some Smalltalk). Java is twenty years old, and for such an old geezer, it's adapted remarkably well (and between Java 8 and Kotlin picking momentum, its legacy seems to be well assured).
- niftich 10y ago
  I was trying to express a lot of ideas in a small space, and I have edited it since, but it's still not as clear as I'd like. You and I agree, but I have struggled to get this point across. Spring is a bloated mess, but when it first came out it was lean new framework and a relief from EJBv1 and EJBv2. In response, EJBv3 was much better, but in the meantime Spring became the new normal, and grew into some strange swiss army chainsaw glue with now-deprecated awful xml configuration replaced by the horror of not-quite-code-but-compiled-into-the-classfile @Annotations! The 'new Spring' is Spring Boot, which was a response to this then-obscure framework called Dropwizard which showed that all you had to do was pick a handful of very good libraries get work done. Guava, Jersey, Jackson, Jetty; some decent ORM, and you're good to go. Some of these are backed by new Java specs like JAX-RS and JPA that are legitimately pretty good. I think the biggest problem Java still has in the hearts and minds of people outside the 'enterprise' is not because of Java, but because of the complexities that only manifest in environments where your code isn't 100% greenfield every time. Dependency Injection isn't something you realize you need until you realize you need it -- and then you realize you need it Really Badly. Externalized XML config files declaring reusable beans isn't something you think you need until your client is asking how they can reconfigure something in the shipped software when they can't just recompile it to what they need.

Zafira 10y ago

> It's the result of man-centuries (man-millennia?) of work, yes, and as a result is really, really impressive. But imagine if that much work had been put into something fundamentally great, like Smalltalk or Lisp, rather than something fundamentally okay like Java. The eternal irony of this is the current JVM---HotSpot---was a Smalltalk VM that Sun bought. It was an attempt to commercialize some of the work done (also at Sun) on the Self language [1]. [1] http://c2.com/cgi/wiki?HotSpotVm http://c2.com/cgi/wiki?HotSpotVm

mikro2nd 10y ago
Well, "an attempt to commercialise" seems to me to trivialise it a bit. The fact is that the Self research uncovered some pretty interesting things around optimisation... at the time optimisers were pretty much based on the research done in the '70's when structured languages were still quite new-and-all. The Self work uncovered that those assumptions were really quite bad when it came to OO environments. OO-structured programmes behaved quite differently at runtime. Indeed, one of the most surprising (then) results was that you really couldn't optimise all that well at compile-time, but that you needed continuous runtime analysis and optimisation do anything really effective. But when you do, then it's hella effective! Remember that we were still in an era when byte-code interpreters were viewed (mostly rightly) as woefully slow and inefficient. Sun had part-funded the Self research for quite a number of years (>5? if memory serves me) so when they found themselves with a bytecode interpreter that really needed some serious help there was a natural fit, and why should they not have gained some advantage out of some pure research work they had funded? As I recall it, most of the Self research was done at Stanford. Sun just provided money, and only much later in the project's lifetime, a home in Sun Labs ("Church" side of Sun). (All this is purely from memory, so I might have misremembered bits of it - I can go upstairs and dig out all those old OOPSLA conference proceedings if it matters.)

cageface 10y ago

If Smalltalk and Lisp are so magical then why didn't they win?

robotresearcher 10y ago
Because Worse is Better applies here as usual. Java was fast enough and familiar enough and the libraries were good enough and the language safe enough and Sun supported it well enough in the enterprise. Nothing else had the same combination of okayness. I never enjoyed Java but it had my half-grudging respect.
- hota_mazi 10y ago
  > Because Worse is Better applies here as usual. It's not that simple. They lost for very pragmatic reasons: Smalltalk and Lisp were worse than Java in many ways (even smaller than Java's initial implementations, Smalltalk's binary images were undeployable in production, these two languages are dynamically typed, etc...).
  - niftich 10y ago
    [1] https://en.wikipedia.org/wiki/Smalltalk#History https://en.wikipedia.org/wiki/Smalltalk#History, scroll midway down: "During the late 1980s to mid-1990s, Smalltalk environments -- including support, training and add-ons -- were sold by two competing organizations: ParcPlace Systems and Digitalk, (...) Both firms struggled to take Smalltalk mainstream due to Smalltalk's substantial memory needs, limited run-time performance, and initial lack of supported connectivity to SQL-based relational database servers. (...)" "In 1995, ParcPlace and Digitalk merged into ParcPlace-Digitalk and then rebranded in 1997 as ObjectShare (...) The merged firm never managed to find an effective response to Java as to market positioning, and by 1997 its owners were looking to sell the business." There was also Strongtalk, a strongly typed variant of Smalltalk. The guys who wrote Self and the guys who wrote Strongtalk were both eventually acqui-hired by Sun and they were the ones who wrote HotSpot [2][3] [2] http://www.strongtalk.org/history.html http://www.strongtalk.org/history.html [3] https://en.wikipedia.org/wiki/Strongtalk https://en.wikipedia.org/wiki/Strongtalk

hellofunk 10y ago

You should not confuse or conflate Java the language with Java the virtual machine. They really are quite distinct technologies.