6 ms·

Evolving Java Without Changing the Language

18 points by fogus 17y ago

10ren 17y ago
The article links to this example of support for XML literals: https://rapt.dev.java.net/nonav/docs/api/index.html?net/java/dev/rapt/proposed/generators/DomLiteral.html https://rapt.dev.java.net/nonav/docs/api/index.html?net/java... It's in the spirit of machine code in REM statements. A ghastly, reanimated spirit. /** <commands> <command name="SOD" order="NEW"> <parameter slot="P2" name="N" value="4811980" /> <parameter slot="P2" name="N" value="4811980" /> </command> </commands> */ @DomLiteral static Document testCommands = DomLiterals.testCommands();
- deleted 17y ago
  [deleted]
nickyp 17y ago
You mean without rewriting it so it is not an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp? ;-)
- ZitchDog 17y ago
  I would say it's more of a formally-specified mature pretty-fast implementation of half of Common Lisp.
wingo 17y ago
The initial Gosling quote gives me shivers of revulsion.
- WilliamLP 17y ago
  I think that very philosophy is the single biggest reason for Java's success. It's "show me where people are actually using this well", not "tell me why people ought to be using this". If you ask some people what is the practical use of certain concepts you get answers like "Uh, you can't even understand why this is so good, because your brain doesn't work in my language, see the Blub Paradox... But see how nice my factorial function looks!" Ironically, I think Java is now one of the most used language in academia, which seemed to have been explicitly an "anti-goal".
  - bad_user 17y ago
    If Java is used a lot in academia is mostly because it is shoved on the throats of students as one of those "real world skills that helps you get a job". Not to say that it doesn't have merits. It's fast enough, it's cross-platform, it has good tools and good libraries. But this wasn't the case until Java 1.4 was released. And its popularity has more to do with Sun's marketing campaign than anything else.
    - WilliamLP 17y ago
      > And its popularity has more to do with Sun's marketing campaign than anything else. If you can do proof by assertion, so can I: Java's popularity has more to do with properties of the language than marketing.
    - 10ren 17y ago
      I think he meant "used by academics in academic research", not "used by students". Both are true.
- jrockway 17y ago
  Me too. I had a hard time reading on after that. Java is absolutely chock-full of "things that sounded like a good idea" -- unboxed types, single inheritance, interfaces without the possibility of shared implementation (or state), public / private / protected / default, positional constructor arguments, "Type foo = new Type", etc. Actually, none of those even sound like good ideas. (But I guess after the brain damage that was C++, it was inevitable that The Industry would overcorrect. Hopefully we've learned one important lesson from Java -- making the language "simple" won't stop people from writing bad code, but it will stop people from writing good code.) Java also popularized some very very experimental ideas, like virtual machines and automatic garbage collection. (And I am very thankful for both.) So now that I think about it, I don't get that quote at all.
  - mike_organon 17y ago
    Also, checked exceptions were not used before, but sounded like a good idea. And they turned out to be harmful in my experience.
    - jrockway 17y ago
      Yes, you are absolutely right. They sound like a great idea, but it seems like "throws Exception" is something that gets tacked onto any method with side effects. It's just not easy to write imperative programs without throwing exceptions somewhere along the call chain. (Another thing that could have gone this way are parameterized types representing null/not-null, like Haskell's Maybe or Either. It seems like a lot of work to annotate every type that can possibly be null, but it is not onerous at all in real life. A few functions are Maybe/Either, but most aren't; and for the price of an annotation you can be sure that you will never get a "NullPointerException". Checked exceptions could have turned out this way, but something about Java, Java's libraries, or imperative programming in general made this not so.)
      - bad_user 17y ago
        > It's just not easy to write imperative programs without throwing exceptions somewhere along the call chain With checked exceptions it is also not easy to be a good OOP citizen and not break encapsulation, since checked exceptions become a part of your interface.
ivenkys 17y ago
At what point does managing the complexity of all the "add-on" pieces of software - APT, Meta-model generators, IDE magic, the interconnecting build tools et all - become too high ? Why not strengthen the core language ?
- bad_user 17y ago
  Because that was the philosophy from the beginning ... don't change the language until it's too late, make sure to cripple all new features to maintain backwards compatibility, leave the problems to the tool-vendors to solve. Actually this philosophy worked better for future-proofing the platform in a weird way. God knows how they would've crippled the JVM if their generics support wasn't made through type-erasure for example. And so the JVM bytecode is pretty light, now only if they added tail-calls and continuations. But I don't think that will happen too soon.
  - ivenkys 17y ago
    I understand the philosophy and yes that has in a way future-proofed the JVM. The question is "Does it make sense to try and include advanced language features in a round-about manner into Java ?" Surely this approach only leads to additional complexity and broken features. Why not put that effort into a newer language running on the JVM ?
mdemare 17y ago
I found the part about IDEs fascinating: IntelliJ will recognize those ugly anonymous classes, and show them to you as closures. I wonder how far you could take this. A language like Duby gives you Ruby syntax, while producing identical bytecode as Java. If you could translate Duby into Java source code, and parse and show it as Duby, your IDE could let you program in Duby without anyone else on your project even noticing. Then you're in effect relegating Java to object code.
- bad_user 17y ago
  Isn't that what compilers do? I actually am thinking of writing a compiler for a custom language that will be translated to Java. It will be a lot like C#, but simplified, with a lot of the cruft removed (like the requirement to define a Main class with a static main, or the requirement that all code should be wrapped in a class, but reified generics is something I want although I'm not sure if it's feasible). I don't like Duby, I don't like Ruby for that matter. Mostly because the syntax is not as extensible as I'd like and because the variables don't have lexical scope.
- axod 17y ago
  I think it's a pretty bad idea. The more IDEs hide code from people, the more verbose code will be produced. Much easier to just setup a simple macro system to run over source files and replace things before compilation.
  - eru 17y ago
    Where's the difference?

18 points by fogus 17y ago

10ren 17y ago

The article links to this example of support for XML literals: https://rapt.dev.java.net/nonav/docs/api/index.html?net/java/dev/rapt/proposed/generators/DomLiteral.html https://rapt.dev.java.net/nonav/docs/api/index.html?net/java... It's in the spirit of machine code in REM statements. A ghastly, reanimated spirit. /** <commands> <command name="SOD" order="NEW"> <parameter slot="P2" name="N" value="4811980" /> <parameter slot="P2" name="N" value="4811980" /> </command> </commands> */ @DomLiteral static Document testCommands = DomLiterals.testCommands();

deleted 17y ago
[deleted]

nickyp 17y ago

You mean without rewriting it so it is not an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp? ;-)

ZitchDog 17y ago
I would say it's more of a formally-specified mature pretty-fast implementation of half of Common Lisp.

wingo 17y ago

The initial Gosling quote gives me shivers of revulsion.

WilliamLP 17y ago
I think that very philosophy is the single biggest reason for Java's success. It's "show me where people are actually using this well", not "tell me why people ought to be using this". If you ask some people what is the practical use of certain concepts you get answers like "Uh, you can't even understand why this is so good, because your brain doesn't work in my language, see the Blub Paradox... But see how nice my factorial function looks!" Ironically, I think Java is now one of the most used language in academia, which seemed to have been explicitly an "anti-goal".
- bad_user 17y ago
  If Java is used a lot in academia is mostly because it is shoved on the throats of students as one of those "real world skills that helps you get a job". Not to say that it doesn't have merits. It's fast enough, it's cross-platform, it has good tools and good libraries. But this wasn't the case until Java 1.4 was released. And its popularity has more to do with Sun's marketing campaign than anything else.
  - WilliamLP 17y ago
    > And its popularity has more to do with Sun's marketing campaign than anything else. If you can do proof by assertion, so can I: Java's popularity has more to do with properties of the language than marketing.
  - 10ren 17y ago
    I think he meant "used by academics in academic research", not "used by students". Both are true.
jrockway 17y ago
Me too. I had a hard time reading on after that. Java is absolutely chock-full of "things that sounded like a good idea" -- unboxed types, single inheritance, interfaces without the possibility of shared implementation (or state), public / private / protected / default, positional constructor arguments, "Type foo = new Type", etc. Actually, none of those even sound like good ideas. (But I guess after the brain damage that was C++, it was inevitable that The Industry would overcorrect. Hopefully we've learned one important lesson from Java -- making the language "simple" won't stop people from writing bad code, but it will stop people from writing good code.) Java also popularized some very very experimental ideas, like virtual machines and automatic garbage collection. (And I am very thankful for both.) So now that I think about it, I don't get that quote at all.
- mike_organon 17y ago
  Also, checked exceptions were not used before, but sounded like a good idea. And they turned out to be harmful in my experience.
  - jrockway 17y ago
    Yes, you are absolutely right. They sound like a great idea, but it seems like "throws Exception" is something that gets tacked onto any method with side effects. It's just not easy to write imperative programs without throwing exceptions somewhere along the call chain. (Another thing that could have gone this way are parameterized types representing null/not-null, like Haskell's Maybe or Either. It seems like a lot of work to annotate every type that can possibly be null, but it is not onerous at all in real life. A few functions are Maybe/Either, but most aren't; and for the price of an annotation you can be sure that you will never get a "NullPointerException". Checked exceptions could have turned out this way, but something about Java, Java's libraries, or imperative programming in general made this not so.)
    - bad_user 17y ago
      > It's just not easy to write imperative programs without throwing exceptions somewhere along the call chain With checked exceptions it is also not easy to be a good OOP citizen and not break encapsulation, since checked exceptions become a part of your interface.

ivenkys 17y ago

At what point does managing the complexity of all the "add-on" pieces of software - APT, Meta-model generators, IDE magic, the interconnecting build tools et all - become too high ? Why not strengthen the core language ?

bad_user 17y ago
Because that was the philosophy from the beginning ... don't change the language until it's too late, make sure to cripple all new features to maintain backwards compatibility, leave the problems to the tool-vendors to solve. Actually this philosophy worked better for future-proofing the platform in a weird way. God knows how they would've crippled the JVM if their generics support wasn't made through type-erasure for example. And so the JVM bytecode is pretty light, now only if they added tail-calls and continuations. But I don't think that will happen too soon.
- ivenkys 17y ago
  I understand the philosophy and yes that has in a way future-proofed the JVM. The question is "Does it make sense to try and include advanced language features in a round-about manner into Java ?" Surely this approach only leads to additional complexity and broken features. Why not put that effort into a newer language running on the JVM ?

mdemare 17y ago

I found the part about IDEs fascinating: IntelliJ will recognize those ugly anonymous classes, and show them to you as closures. I wonder how far you could take this. A language like Duby gives you Ruby syntax, while producing identical bytecode as Java. If you could translate Duby into Java source code, and parse and show it as Duby, your IDE could let you program in Duby without anyone else on your project even noticing. Then you're in effect relegating Java to object code.

bad_user 17y ago
Isn't that what compilers do? I actually am thinking of writing a compiler for a custom language that will be translated to Java. It will be a lot like C#, but simplified, with a lot of the cruft removed (like the requirement to define a Main class with a static main, or the requirement that all code should be wrapped in a class, but reified generics is something I want although I'm not sure if it's feasible). I don't like Duby, I don't like Ruby for that matter. Mostly because the syntax is not as extensible as I'd like and because the variables don't have lexical scope.
axod 17y ago
I think it's a pretty bad idea. The more IDEs hide code from people, the more verbose code will be produced. Much easier to just setup a simple macro system to run over source files and replace things before compilation.
- eru 17y ago
  Where's the difference?