On 7 January 2013 12:57, Casper Bang <[email protected]> wrote:
>
>> In Scala at least, I'm finding almost the entire community still think of
>> themselves as Java programmers. Java nowadays is first and foremost a
>> platform, and you're still programming against Java even if you're not not
>> using Java-the-language.
>>
>>
> Fair enough, but you aren't really programming against Java (the API)
> either though are you? You constantly live in this shadow world (not unlike
> Java arrays vs. generics, C const vs. non-const etc.).
>
>
>> What Java *isn't* about here is default mutable collections, and use-site
>> variance, and get/set property accessors, and lambdas being delayed at the
>> same time as you gain the ability to put underscores in numbers, or any of
>> the other delays and setbacks that cause a project like Lombok to even be
>> needed in the first place!
>>
>>
> However, the JVM and bytecode is so heavily tied to Java that it seems
> like an uphill battle, which is what Lombok is now hitting. The bytecode is
> still OO (new, invokeinterface, invokevirtual), with operators required to
> having been assigned a type (iadd vs. fadd) etc.
>
> Considering how many of the later advanced features of Java (the language)
> relies on hacks and workarounds (inner classes, generics by erasure,
> reference equality) and how we are now getting silly unsigned int
> arithmetic utilities in JDK8 rather than simply a new unsigned byte, I can
> only imagine what goes on underneath with Clojure, Scala etc. when
> implementing i.e. "yield" efficiently.
>
Assuming you mean "yield" in the sense of for-comprehensions, that's one of
the easy ones! It's a nice localised rewrite of the syntax tree:
for(x <- myCollection) yield { x.toString }
becomes
myCollection map { x => x.toString }
All comprehensions are translated like this, using the necessary
combinations of map, flatMap, filter and foreach. When people say that
"for" in Scala is a comprehension and not a loop, they really aren't joking
:) The programming in Scala book has an entire chapter on the subject.
More interesting and challenging is the lambdaLift, which converts x =>
x.toString into a synthetic inner class with an apply(x) method that
encapsulates the lambda. It gets more interesting still if that lambda is
actually a closure and has to "close over" contextual state.
I'd also hesitate to call erasure a hack, without it we'd be stuck with
use-site variance and cripple a lot of work on type systems in the JVM*.
Erasure is actually the norm in most languages. What Java lacks here is
not reification, but a convenient mechanism to supply the erased type
information at runtime if it should be necessary.
Fortress had a nice approach here, and Scala's manifests (or typeTags since
2.10) are also a step in the right direction. But they're still rather
clunky in some scenarios and won't be a complete solution until pattern
matching can automatically "unerase" via manifests whenever they're
available.
* e.g. The approaches used by JRuby, Mirah or Fortress. Not to mention
declaration-site variance, or Martin Oderky's "delimited object types"
proposal.
--
You received this message because you are subscribed to the Google Groups "Java
Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
