Live data from Hacker News

Java 9 with GPU processing, Java 10 will be all-OOP without primitives

javaworld.com

21–30 of 138 posts

Re: Java 9 with GPU processing, Java 10 will be all-OOP without primitives

#21
post #9

Earlier quoted context omitted.

Literally useless? Would you like to elaborate on how specifying a contract that has to be implemented is suddenly useless because you have function types?

I think the experience of Haskell is relevant here. Once Haskell introduced first class functions, everyone stopped using typeclasses. [edit: apparently my sarcasm was too subtle. HOF and typeclasses are both vitally important pieces of Haskell, which are orthogonal to each other. I'm pretty sure both were in Haskell from day 1. Some code for which both are essential: class Monad m where (>>=) :: m a -> (a -> m b) ->…

Once Haskell introduced first class functions, everyone stopped using typeclasses.

What do you mean? From what I've seen, everyone uses typeclasses in Haskell.

Re: Java 9 with GPU processing, Java 10 will be all-OOP without primitives

#23
post #8

All-OOP? So functions will be objects too? And classes? And contexts? Not meaning to start a flame, just saying the title's a bit inaccurate IMHO...

Classes are already objects. I don't know whether Java 8 will finally introduce function as a data type, but if it does, I'm pretty sure they won't do it the way Ruby blocks work (i.e. block is not an object).

I'd rather they didn't. It would be redundant with inner classes that are already there, I don't like this piling up of features. It would be more interesting if they allowed inner classes to close over non-final variables.

Re: Java 9 with GPU processing, Java 10 will be all-OOP without primitives

#24
post #20
post #3

Wow, how can you seriously plan releases of a programming language out to 2021? That is an eternity in this industry. Even 2015 for JDK 9 seems mighty far off, especially accounting for the usual slippage of release dates with big software projects.

Why don't they start now and build Java 2.0 from ground up instead of Java 10 for 2017? That would be way faster and they learned so much by now to make a great successor. Who wants a Java 1.x in 2040?

by the time the rebuilt java2.0-NG reaches stability it will be 2017, or whatever.

Re: Java 9 with GPU processing, Java 10 will be all-OOP without primitives

#25
The presentation declares, "Java is not the new Cobol."

It shocks me that a major company like Oracle would be so foolish as to make a statement like this. Stating that something is not is one of the most effective ways to imply that it is and the speaker knows it.

Re: Java 9 with GPU processing, Java 10 will be all-OOP without primitives

#26
post #25

The presentation declares, "Java is not the new Cobol." It shocks me that a major company like Oracle would be so foolish as to make a statement like this. Stating that something is not is one of the most effective ways to imply that it is and the speaker knows it.

On the other hand, not acknowledging what everyone is saying can make you look out of touch.

Re: Java 9 with GPU processing, Java 10 will be all-OOP without primitives

#27
post #5

Earlier quoted context omitted.

This is a very good point. If functions become objects, interfaces would become literally useless. Somehow it seems that it would not be the case since this would be a drastic change (even thought getting rid of primitives are as well.)

Clojure has both function objects and interfaces (called 'protocols'). In fact, it encourages the use of interfaces while strongly discouraging the traditional object inheritance model. Most people who've tried it AFIAK consider Clojure a well-designed language.

Clojure, Golang, Scala and Rust all implement similar interface.

Re: Java 9 with GPU processing, Java 10 will be all-OOP without primitives

#28
post #9
post #5

Earlier quoted context omitted.

This is a very good point. If functions become objects, interfaces would become literally useless. Somehow it seems that it would not be the case since this would be a drastic change (even thought getting rid of primitives are as well.)

Literally useless? Would you like to elaborate on how specifying a contract that has to be implemented is suddenly useless because you have function types?

Not sure I agree with the GP's point, but I believe he's arguing that when fulfilling the contract of a fictional MouseClickListener:

  interface MouseClickListener {
    void mouseClicked(MouseEvent e);
  }
one often uses an anonymous class to do so:

  void init() {
    mouse.setClickListener(new MouseClickListener() {
      void mouseClicked(MouseEvent e) {
        println(e);
      }
    });
  }
the exact effect could be achieved with a reference to a named function (if Java supported them, which presumably it will once "everything is an object"):

  void init() {
    void mouseClick(MouseEvent e) { println(e); }
    mouse.setClickListener(mouseClick);
  }
given that interfaces are simply syntax for function routing, when you have the ability to reference functions by first-class types (i.e. you have the ability to determine function routing yourself), the set of things that you can only sensibly do with interfaces is a lot smaller.

This is how C# delegates work, right? Any Java -> C# programmer want to comment on whether they rely less on interfaces now and what they use them for?

Re: Java 9 with GPU processing, Java 10 will be all-OOP without primitives

#29
post #25

The presentation declares, "Java is not the new Cobol." It shocks me that a major company like Oracle would be so foolish as to make a statement like this. Stating that something is not is one of the most effective ways to imply that it is and the speaker knows it.

It somewhat surprises me that they'd not want Java to become the new COBOL. COBOL is still alive, still runs large systems, and still sells hardware and software. Owning the new COBOL has the potential to be quite lucrative in the long term.

Re: Java 9 with GPU processing, Java 10 will be all-OOP without primitives

#30
post #9

Earlier quoted context omitted.

Literally useless? Would you like to elaborate on how specifying a contract that has to be implemented is suddenly useless because you have function types?

Not sure I agree with the GP's point, but I believe he's arguing that when fulfilling the contract of a fictional MouseClickListener: interface MouseClickListener { void mouseClicked(MouseEvent e); } one often uses an anonymous class to do so: void init() { mouse.setClickListener(new MouseClickListener() { void mouseClicked(MouseEvent e) { println(e); } }); } the exact effect could be achieved with a reference to a n…

I bounce between Java and C#. I'm not sure at all what he's talking about. I use interfaces all the time in C#. I even specify delegate properties (as distinct from events, when I don't want them to be multicast) in interfaces.

I think both concepts are probably independent of one another.

Post reply on HN