5 ms·

From the article, under "open questions": Generics over values. It is persistent irritant that generics do not work over primitive types today. With value type

by gordaco 12y ago

From the article, under "open questions": Generics over values. It is persistent irritant that generics do not work over primitive types today. With value types, this irritation will increase dramatically; not being able to describe List<Point> would be even worse. Still worse would be having it mean “today’s list, containing boxed points”. Supporting generics over primitives and values, through specialization, is the topic of a separate investigation. The need for boxing/unboxing is for me one of the most common sources of facepalm in Java. I guess it's difficult to fix without breaking existing code (I guess that a new implementation of generics may not break java code, but it would break existing bytecode), but it's really annoying.

pas 12y ago
Java needs feature opt-in, import future.sane.Generics; and so on. (Scala has these.) Python learned it the hard way. The value of backward compatibility got a bit underestimated there, with Java it's going the other way (the value of progressing, giving better tools to developers is overlooked). The JVM is a big bag of crazy code already (HotSpot with C1 and C2 JIT compilers, the many garbage collector algorithms/implementations and the other stuff that is currently deemed the JVM's responsibility), so there's plenty of space for new opt-in features.
- mcosta 12y ago
  Feature opt-in sounds good. The C++ people did it. Look what happened. Qt, boost, gtkmm, mscf are all (more or less) good. But you can't (shouldn't) mix them.
  - nly 12y ago
    > Qt, boost, gtkmm, mscf are all (more or less) good. But you can't (shouldn't) mix them. I think you're missing the point of generic programming.
hencq 12y ago
> Supporting generics over primitives and values, through specialization, is the topic of a separate investigation. Sort of off-topic, but isn't that dilemma also the one preventing Go from having generics?
- fiatmoney 12y ago
  Basically. If you want to implement generics you basically have the choice of 1) boxing (Java approach), 2) instantiating a different type for each generic parameter (C++ approach), and 3) doing something in the runtime to enable a relatively transparent hybrid (C# approach). They each have their own tradeoffs in terms of flexibility, memory consumption, runtime complexity, and compilation / linking time.
  - acjohnson55 12y ago
    How does Scala's approach fit with these options?
    - coolsunglasses 12y ago
      Scala runs on the JVM and uses boxing, but unreliably attempts unboxing. Sometimes. Maybe. Meanwhile, in Haskell, there already are value types and newtype wrappers are erased at compile-time, eliminating all overhead.
      - bad_user 12y ago
        No, that's not true. Scala does true specialization of primitives by means of the @specialized annotation: http://www.scala-lang.org/api/2.10.3/index.html#scala.specialized http://www.scala-lang.org/api/2.10.3/index.html#scala.specia... This functionality is old and because it tends to generate many class files, there's also a newer project that fixes that and that should replace the @specialized annotation soon: http://scala-miniboxing.org/ http://scala-miniboxing.org/ But wait, there's more - Scala 2.10 also brought with it "value classes", as in zero-overhead wrappers: http://docs.scala-lang.org/overviews/core/value-classes.html http://docs.scala-lang.org/overviews/core/value-classes.html Speaking of the JVM and overhead, the JVM also does escape analysis and it can choose to allocate values on the stack in case they don't escape their context: http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#escapeAnalysis http://docs.oracle.com/javase/7/docs/technotes/guides/vm/per...
frowaway001 12y ago
It's funny how they slowly realize that value types without better Generics are as pointless as better Generics without value types.
pron 12y ago
Note that specialization ("templates") are not a JVM issue but a language issue. If the JVM offers value types, then any JVM language can choose to provide specialization -- or not. In fact, this might be a better idea than baking specialization into the JVM (as done in .Net), as doing so might enforce a specific implementation of generic types, and might prevent other JVM languages from providing their own, novel type systems.

by gordaco 12y ago

pas 12y ago

Java needs feature opt-in, import future.sane.Generics; and so on. (Scala has these.) Python learned it the hard way. The value of backward compatibility got a bit underestimated there, with Java it's going the other way (the value of progressing, giving better tools to developers is overlooked). The JVM is a big bag of crazy code already (HotSpot with C1 and C2 JIT compilers, the many garbage collector algorithms/implementations and the other stuff that is currently deemed the JVM's responsibility), so there's plenty of space for new opt-in features.

mcosta 12y ago
Feature opt-in sounds good. The C++ people did it. Look what happened. Qt, boost, gtkmm, mscf are all (more or less) good. But you can't (shouldn't) mix them.
- nly 12y ago
  > Qt, boost, gtkmm, mscf are all (more or less) good. But you can't (shouldn't) mix them. I think you're missing the point of generic programming.

hencq 12y ago

> Supporting generics over primitives and values, through specialization, is the topic of a separate investigation. Sort of off-topic, but isn't that dilemma also the one preventing Go from having generics?

fiatmoney 12y ago
Basically. If you want to implement generics you basically have the choice of 1) boxing (Java approach), 2) instantiating a different type for each generic parameter (C++ approach), and 3) doing something in the runtime to enable a relatively transparent hybrid (C# approach). They each have their own tradeoffs in terms of flexibility, memory consumption, runtime complexity, and compilation / linking time.
- acjohnson55 12y ago
  How does Scala's approach fit with these options?
  - coolsunglasses 12y ago
    Scala runs on the JVM and uses boxing, but unreliably attempts unboxing. Sometimes. Maybe. Meanwhile, in Haskell, there already are value types and newtype wrappers are erased at compile-time, eliminating all overhead.
    - bad_user 12y ago
      No, that's not true. Scala does true specialization of primitives by means of the @specialized annotation: http://www.scala-lang.org/api/2.10.3/index.html#scala.specialized http://www.scala-lang.org/api/2.10.3/index.html#scala.specia... This functionality is old and because it tends to generate many class files, there's also a newer project that fixes that and that should replace the @specialized annotation soon: http://scala-miniboxing.org/ http://scala-miniboxing.org/ But wait, there's more - Scala 2.10 also brought with it "value classes", as in zero-overhead wrappers: http://docs.scala-lang.org/overviews/core/value-classes.html http://docs.scala-lang.org/overviews/core/value-classes.html Speaking of the JVM and overhead, the JVM also does escape analysis and it can choose to allocate values on the stack in case they don't escape their context: http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#escapeAnalysis http://docs.oracle.com/javase/7/docs/technotes/guides/vm/per...

frowaway001 12y ago

It's funny how they slowly realize that value types without better Generics are as pointless as better Generics without value types.

pron 12y ago

Note that specialization ("templates") are not a JVM issue but a language issue. If the JVM offers value types, then any JVM language can choose to provide specialization -- or not. In fact, this might be a better idea than baking specialization into the JVM (as done in .Net), as doing so might enforce a specific implementation of generic types, and might prevent other JVM languages from providing their own, novel type systems.