5 ms·

Java: The Good Parts

31 points by fogus 17y ago

Tichy 17y ago
Basically, the jvm.
- mattew 17y ago
  I have to admit that it took me a little while to figure out exactly how cool the JVM is, and how much of a standalone product it is. Its exciting to see so many languages targeting the JVM and taking advantage of the many years of development and optimization that have gone into the JVM.
  - smokinn 17y ago
    What I find kind of funny is that both major JVMs (Sun's and IBM's) were both originally Smalltalk VMs that were basically abused (crippling them with Java's security model among other things in Sun's case, not too sure about IBM) to run Java.
    - strlen 17y ago
      HotSpot is built on top of the Strongtalk VM, which is very interesting in several ways. First, it's a Smalltalk implementation with optional strong static typing. Second, since 2006 it's been available as open source: http://strongtalk.org/ http://strongtalk.org/ I believe, along with Common Lisp and its VM, it's the only such option on the market. Clojure may have optional static typing -- which, running on the HotSpot JVM, would mean bringing this "full cycle" -- but I need to RTFM before I say for sure.
      - rabidsnail 17y ago
        Clojure has optional type hints. Ex: (fn [#^String foo] (.length foo)) See http://clojure.org/java_interop#Java%20Interop-Type%20Hints http://clojure.org/java_interop#Java%20Interop-Type%20Hints
- stralep 17y ago
  Will there be a tail recursion on jvm?
  - strlen 17y ago
    It's possible to tail recursion on the JVM, especially with a statically typed language (see Scala for a classical approach, see Clojure's loop/recur for a slightly different approach). Not tail call elimination and mutual recursion, however. That is, however, if you want the compiler to output code that's fully backwards compatible with Java (which is what Scala and Clojure do).
    - gtani 17y ago
      late hit: I've seen chatter that scala has TCO, clojure doesn't (kinda like, what's wrong with clojre?). Read what Rich hickey has to say http://groups.google.com/group/clojure/msg/946d98e5b88a6497 http://groups.google.com/group/clojure/msg/946d98e5b88a6497
rbranson 17y ago
"Frameworks such as Grails bring it [Java] to parity with Rails or Django." Apparently the author has never bothered to actually use Rails or Django.
- ZitchDog 17y ago
  or Grails
  - gacba 17y ago
    "With the release of Java FX, widespread deployment of the JRE, and better browser integration, Java has set the stage for a comeback to its roots." I'm guessing he hasn't actually touched this part either. It's a disaster. JavaFX is a less capable version of Flex or Silverlight. If he thinks applets were stillborn, this was closer to a miscarriage.
- brazzy 17y ago
  Nor has he taken a look at Java EE within the last couple of years - the difference between EJB 2 and 3 is like night and day.
Maciek416 17y ago
This article is mostly a historical rehash with few-to-none specific points highlighting the "Good Parts" of Java. I was ready to read about them, and I personally know there are some very compelling Good Parts to modern Java, but the article didn't address any of them. He makes vague mentions of the need to debunk Java myths, but doesn't debunk any himself. He advocates Java on the client side, where apparently "one must acknowledge that somewhere along the line, manipulating a DOM/markup language with a scripting language isn’t the most effective development platform for everything". Love it or hate it, history seems to be disagreeing by sheer volume of numbers. He offers up JavaFX, a platform that is about as obscure as you can get, as an alternative to not only HTML/DOM/js but also Flash. Given that HTML5's tide may already be washing over top of Flash, which is likely orders of magnitude better supported than JavaFX may ever be, this seems like a crazy, almost non-sequitur point to bring up in an article presumably about Java's Good Parts. Next, highlighting the JVM as a strength of Java feels weak since most of his argument focused on a call to arms to get people to host more dynamic languages on top of the JVM. This is hardly a strength of Java. Finally, while he mentions that open source really mattered when it came to Java's evolution, if this article had done an actual analysis of any language features itself, it would have had to admit the reality that Java is in many ways falling behind direct competitors like C# -- which is decidedly run in a much more closed than open style by Microsoft. In the face of this, when comparing Good Parts, how is this a strong argument? To me it seems that open sourcing Java at worst just ensured that a language that was on shaky ground continued to survive, at best nudged it forward a notch or two. For an example of how an open process doesn't guarantee rapid progress with respect to Good Parts, just look at the sluggish and fractured deliberation over Java's closure proposals. Somebody needs to take the title of the article and write the one we all expected when we clicked the link. I expected a meaty homage to Crockford's work.
- bad_user 17y ago
  You do have a point about TFA not showing the Good Parts, but I disagree with the following ... > highlighting the JVM as a strength of Java feels weak since most of his argument focused on a call to arms to get people to host more dynamic languages on top of the JVM. This is hardly a strength of Java. It is a strength ... the JVM is state of the art. And when using JRuby or Closure, you have the advantage of dropping to Java for bottlenecks / use Java libraries ... and this is huge. > while he mentions that open source really mattered when it came to Java's evolution ... Java is in many ways falling behind direct competitors like C# The language yes, but the open-source ecosystem around Java is definitely a huge advantage that can't be balanced with the goodies of C#.
jrockway 17y ago
Where's axod to say "languages don't have good parts, only programmers have good parts"?
lionshare 17y ago
It's a very short book. But if you liked "Cobol the good parts", than it's absolutely recommended.
- raganwald 17y ago
  If you know that witty put-downs are discouraged, then you may also know that spelling flames are considered in poor taste.
n8agrin 17y ago
Here's my problem with Java. No one ever talks about the language, and what makes the language so great. No one ever writes articles stating something like "Look this is why loops are so _cool_ in Java." Everyone in the Java world seems to point at these big libraries built on top of Java and say things like "Look Swing is what makes Java cool!" or "Java Beans are so great!" I just don't believe that, for exactly the same reason I don't believe rubygems doesn't make Ruby cool, why I don't believe Django makes Python cool nor jQuery makes Javascript cool. On the other hand I do value opinions like, "Ruby is cool because of it's blocks.", "Python got it's package system right and list comprehensions are awesome.", or "Javascript's closure implementation works well." The book this article is named after, "Javascript: The Good Parts", does exclusively talk about the language Javascript, not jQuery or other Javascript libraries. After reading "Javascript: The Good Parts" I was excited to use the language for all the reasons Crockford pointed out. This article doesn't ever approach that for Java, and instead focuses more on the Java libraries, hence I'm not more inclined or more excited to go back to writing Java.
- guelo 17y ago
  Coming from the dynamic language world to Java it took me a long time to find "The Good Parts", but I think the main advantage is the static type system and what that allows tools like Eclipse to do, e.g. code-completion, inline docs, refactoring, etc. In a huge project, some of the refactorings that I do on a daily basis in Java, would be scary if not down right impossible in more fungible languages.
  - n8agrin 17y ago
    Now that is cool and a valid opinion on the "good parts" of Java. FWIW, I know at least one ActionScript coder who has a hard time going back to coding in Javascript because of its lack of a type system (even though they are both very loosely based on the same ECMAScript standards).

31 points by fogus 17y ago

Tichy 17y ago

Basically, the jvm.

mattew 17y ago
I have to admit that it took me a little while to figure out exactly how cool the JVM is, and how much of a standalone product it is. Its exciting to see so many languages targeting the JVM and taking advantage of the many years of development and optimization that have gone into the JVM.
- smokinn 17y ago
  What I find kind of funny is that both major JVMs (Sun's and IBM's) were both originally Smalltalk VMs that were basically abused (crippling them with Java's security model among other things in Sun's case, not too sure about IBM) to run Java.
  - strlen 17y ago
    HotSpot is built on top of the Strongtalk VM, which is very interesting in several ways. First, it's a Smalltalk implementation with optional strong static typing. Second, since 2006 it's been available as open source: http://strongtalk.org/ http://strongtalk.org/ I believe, along with Common Lisp and its VM, it's the only such option on the market. Clojure may have optional static typing -- which, running on the HotSpot JVM, would mean bringing this "full cycle" -- but I need to RTFM before I say for sure.
    - rabidsnail 17y ago
      Clojure has optional type hints. Ex: (fn [#^String foo] (.length foo)) See http://clojure.org/java_interop#Java%20Interop-Type%20Hints http://clojure.org/java_interop#Java%20Interop-Type%20Hints
stralep 17y ago
Will there be a tail recursion on jvm?
- strlen 17y ago
  It's possible to tail recursion on the JVM, especially with a statically typed language (see Scala for a classical approach, see Clojure's loop/recur for a slightly different approach). Not tail call elimination and mutual recursion, however. That is, however, if you want the compiler to output code that's fully backwards compatible with Java (which is what Scala and Clojure do).
  - gtani 17y ago
    late hit: I've seen chatter that scala has TCO, clojure doesn't (kinda like, what's wrong with clojre?). Read what Rich hickey has to say http://groups.google.com/group/clojure/msg/946d98e5b88a6497 http://groups.google.com/group/clojure/msg/946d98e5b88a6497

rbranson 17y ago

"Frameworks such as Grails bring it [Java] to parity with Rails or Django." Apparently the author has never bothered to actually use Rails or Django.

ZitchDog 17y ago
or Grails
- gacba 17y ago
  "With the release of Java FX, widespread deployment of the JRE, and better browser integration, Java has set the stage for a comeback to its roots." I'm guessing he hasn't actually touched this part either. It's a disaster. JavaFX is a less capable version of Flex or Silverlight. If he thinks applets were stillborn, this was closer to a miscarriage.
brazzy 17y ago
Nor has he taken a look at Java EE within the last couple of years - the difference between EJB 2 and 3 is like night and day.

Maciek416 17y ago

This article is mostly a historical rehash with few-to-none specific points highlighting the "Good Parts" of Java. I was ready to read about them, and I personally know there are some very compelling Good Parts to modern Java, but the article didn't address any of them. He makes vague mentions of the need to debunk Java myths, but doesn't debunk any himself. He advocates Java on the client side, where apparently "one must acknowledge that somewhere along the line, manipulating a DOM/markup language with a scripting language isn’t the most effective development platform for everything". Love it or hate it, history seems to be disagreeing by sheer volume of numbers. He offers up JavaFX, a platform that is about as obscure as you can get, as an alternative to not only HTML/DOM/js but also Flash. Given that HTML5's tide may already be washing over top of Flash, which is likely orders of magnitude better supported than JavaFX may ever be, this seems like a crazy, almost non-sequitur point to bring up in an article presumably about Java's Good Parts. Next, highlighting the JVM as a strength of Java feels weak since most of his argument focused on a call to arms to get people to host more dynamic languages on top of the JVM. This is hardly a strength of Java. Finally, while he mentions that open source really mattered when it came to Java's evolution, if this article had done an actual analysis of any language features itself, it would have had to admit the reality that Java is in many ways falling behind direct competitors like C# -- which is decidedly run in a much more closed than open style by Microsoft. In the face of this, when comparing Good Parts, how is this a strong argument? To me it seems that open sourcing Java at worst just ensured that a language that was on shaky ground continued to survive, at best nudged it forward a notch or two. For an example of how an open process doesn't guarantee rapid progress with respect to Good Parts, just look at the sluggish and fractured deliberation over Java's closure proposals. Somebody needs to take the title of the article and write the one we all expected when we clicked the link. I expected a meaty homage to Crockford's work.

bad_user 17y ago
You do have a point about TFA not showing the Good Parts, but I disagree with the following ... > highlighting the JVM as a strength of Java feels weak since most of his argument focused on a call to arms to get people to host more dynamic languages on top of the JVM. This is hardly a strength of Java. It is a strength ... the JVM is state of the art. And when using JRuby or Closure, you have the advantage of dropping to Java for bottlenecks / use Java libraries ... and this is huge. > while he mentions that open source really mattered when it came to Java's evolution ... Java is in many ways falling behind direct competitors like C# The language yes, but the open-source ecosystem around Java is definitely a huge advantage that can't be balanced with the goodies of C#.

jrockway 17y ago

Where's axod to say "languages don't have good parts, only programmers have good parts"?

lionshare 17y ago

It's a very short book. But if you liked "Cobol the good parts", than it's absolutely recommended.

raganwald 17y ago
If you know that witty put-downs are discouraged, then you may also know that spelling flames are considered in poor taste.

n8agrin 17y ago

Here's my problem with Java. No one ever talks about the language, and what makes the language so great. No one ever writes articles stating something like "Look this is why loops are so _cool_ in Java." Everyone in the Java world seems to point at these big libraries built on top of Java and say things like "Look Swing is what makes Java cool!" or "Java Beans are so great!" I just don't believe that, for exactly the same reason I don't believe rubygems doesn't make Ruby cool, why I don't believe Django makes Python cool nor jQuery makes Javascript cool. On the other hand I do value opinions like, "Ruby is cool because of it's blocks.", "Python got it's package system right and list comprehensions are awesome.", or "Javascript's closure implementation works well." The book this article is named after, "Javascript: The Good Parts", does exclusively talk about the language Javascript, not jQuery or other Javascript libraries. After reading "Javascript: The Good Parts" I was excited to use the language for all the reasons Crockford pointed out. This article doesn't ever approach that for Java, and instead focuses more on the Java libraries, hence I'm not more inclined or more excited to go back to writing Java.

guelo 17y ago
Coming from the dynamic language world to Java it took me a long time to find "The Good Parts", but I think the main advantage is the static type system and what that allows tools like Eclipse to do, e.g. code-completion, inline docs, refactoring, etc. In a huge project, some of the refactorings that I do on a daily basis in Java, would be scary if not down right impossible in more fungible languages.
- n8agrin 17y ago
  Now that is cool and a valid opinion on the "good parts" of Java. FWIW, I know at least one ActionScript coder who has a hard time going back to coding in Javascript because of its lack of a type system (even though they are both very loosely based on the same ECMAScript standards).