Under the Hood with Java 10 Enhanced Generics • Hacker News Board

Re: Under the Hood with Java 10 Enhanced Generics

#41

Post by lmm » Tue, Dec 30, 2014, 4:20 PM UTC

the_af wrote: post #39

lmm wrote: post #30

Earlier quoted context omitted.

I won't touch IntelliJ, but I find Eclipse good enough to work with. I've seen the syntax-errors-in-random-files bug occasionally; it's always been a block of text "moved" to the wrong place in the file. Annoying and worrying, but pretty quick to fix. Debugging has always been reliable though, and simpler refactoring works, and it's getting better at a good rate. But yeah, the problems are real.

It's interesting that debugging is reliable in your setup. I use Kepler-based Scala IDE, and debugging sometimes doesn't work, which means: not all expressions are inspectable. Sometimes you cannot inspect the value of a variable. I'm beginning to think this is actually a Scala issue: maybe those expressions simply get elided in the actual bytecode?

It's possible; I tend to only look at member variables. Note that if you're inside a block then variables from a slightly larger scope are often under this/this$2 or similar. Are you using the old scala debugger or the new one? (I'm using Luna now, which didn't give me the choice, so presumably the new one is stable enough that they've made it the default?)

Re: Under the Hood with Java 10 Enhanced Generics

#42

Post by hyperpape » Tue, Dec 30, 2014, 4:35 PM UTC

pkinsky wrote: post #40

lukedegruchy wrote: post #5

Earlier quoted context omitted.

Scala isn't the only alternative JVM language that has a superior generics implementation and that doesn't have primitives. What neither Scala nor those languages have is support for value types (structs) at the JVM level. Generics over primitives and value types is a natural consequence of the introduction of value types to the JVM.

Scala supports value types now: http://docs.scala-lang.org/overviews/core/value-classes.html

The document says that you can't actually always avoid the Object allocations, because of the JVM. I'm pretty sure you'll need VM changes in addition to language changes for this.

Re: Under the Hood with Java 10 Enhanced Generics

#43

Post by kasey_junk » Tue, Dec 30, 2014, 5:10 PM UTC

papauschek wrote: post #36

kasey_junk wrote: post #25

Earlier quoted context omitted.

Let me preface this by saying I've been a full time Scala dev for a few years now, and routinely make the choice to use Scala in new projects. That said, the complaints about Scala's complexity are not overblown in the least. If you ever had the opportunity to move from one Scala team to another, or to integrate 2 Scala teams that had grown independently previously, you see that even saying you are a Scala team does…

Would love to hear in more detail about your experiences integrating Scala teams and the challenges that come with it. I only worked in a small team so far (3 devs) and had a good experience introducing Scala, but I can imagine that with people who have previous Scala experience and "their own style" can be problematic.

The single biggest problem facing Scala right now is a lack of a true idiomatic style. When opening a Scala code base you can encounter everything from "Java without semicolons" to "scalaz style operator soup" and everything in between.

Added to this is that "best practices" have migrated pretty significantly over time, and things that many people thought of as very beneficial are now often seen as problematic (xml support, mixins, large for comprehensions, implicit conversions, etc) but not everyone agrees on these.

Compounding all of this is that the Scala "defaults" can lead to some pretty heinous problems and experienced Scala developers often have opinions that seem to directly contradict what Typesafe is selling (for instance, Akka, Play, the collections library, sbt etc. are all subject of ire for lots of people who have used them extensively).

Re: Under the Hood with Java 10 Enhanced Generics

#44

Post by eropple » Tue, Dec 30, 2014, 6:25 PM UTC

the_af wrote: post #38

eropple wrote: post #28

Earlier quoted context omitted.

Huh, I use Slick quite a lot and never have trouble. Never used Spray. I guess I don't write terribly complex stuff (I really do use Scala largely as I'd use a JVM C#, I suppose) in general, though. About all I find myself using refactoring tools with for Java is renaming, honestly, so I guess I'm more likely to have my itches scratched by the current state of tooling. Thanks for the explanation, though!

I don't write complex Scala code either. Simple renaming doesn't reliably work for me on Kepler-based Scala IDE for Ubuntu :( This means sometimes it will fail to rename in every call site, and sometimes it will introduce random symbols.

I've never found ScalaIDE worth the time of day--I wrote Scala in Vim before IDEA 11. There, simple renames work fine. =)

Re: Under the Hood with Java 10 Enhanced Generics

#45

Post by eropple » Tue, Dec 30, 2014, 6:26 PM UTC

lukedegruchy wrote: post #34

lmm wrote: post #31

Earlier quoted context omitted.

Ceylon is very nice, and probably is more consistent; first-class union types are a really good idea. Its Java interop story isn't quite as good as Scala's (without existential types, you can't express many Java generic methods - and try calling a Java generic method with a Ceylon tuple), and I don't think I could live without higher-kinded types and some equivalent to for/yield (do notation). But it does feel pretty…

Java interop is way better with Ceylon 1.1. For example, use-site variance for generics was introduced and overloading bugs have been resolved. Ceylon 1.2 will have constructors (to support DI frameworks) and I believe Java EE integration. The Ceylon guys have been very careful about adding new features, considering the pros and cons. Strict Java interoperability would have resulted in a much less elegant language (e…

Yeah, having looked at Ceylon 1.2 I withdraw the "or Ceylon" part of what I'd said above. It's a lot nicer than when I'd looked at it before. I'd still go to Scala first, but that ain't bad.