7 ms·
Hitting a couple of your points: What about Generics is broken? For the extent of power they seem to intend to provide (forcing methods to only take a particula
by sukuriant 16y ago
Hitting a couple of your points:
What about Generics is broken? For the extent of power they seem to intend to provide (forcing methods to only take a particular type, and providing syntactic sugar so you don't have to cast everywhere.
Tail-call optimization is just that, an optimization. A 1.6 compliant, open-source JVM could provide that. Same with the faster startup time.
As I don't generally use closures, and would replicate their abilities through interfaces and anonymous classes, I don't have a comment on them; and you'd need to expound upon "module system" for me to say anything.
- steveklabnik 16y ago> What about Generics is broken? I'm going to be slightly handwavy, so forgive me: Generics are implemented by doing type erasure[1] rather than as 'real generics' through some other method. This causes issues with runtime reflection. > would replicate their abilities through interfaces and anonymous classes, This embodies exactly what I hate about Java: In other languages, where I simply 'do/end' or ' \ ->', I have to create a whole giant pile of boilerplate bullshit to pull off something that's supposed to be easy. 1: http://en.wikipedia.org/wiki/Generics_in_Java#Type_erasure http://en.wikipedia.org/wiki/Generics_in_Java#Type_erasure
- sukuriant 16y agoOn Generics: I did not know they performed that slight-of-hand, internally. That does make them rather weak. On Java-bloat: to be fair, it's really not that much, especially if it's already a known interface: new TreeSet<Foo>(new Comparator<Foo>() { public void compare(Foo a, Foo b) { mycode(); } }); However, your point stands. I've just come to accept that as being a part of Java, myself.
- crux_ 16y agoWhat's wrong with java generics: erasure. "Cast everywhere" is still happening. And useful info is hidden: eg there is no access to generic type info via reflection. Another wrong thing: generics are incompatible with subtyping. (No co/contra-variance, to use the pointy headed terms) Tail call optimization is not a mere optimization. A jvm cannot provide it and still provide conforming exception stack traces, for example. As far as closures: you're missing out :)
- dantheman 16y agoAlso tail call optimization changes the semantics of the language - it allows you to write code that would normally be incorrect
- crux_ 16y agoTrue, although you have to be careful about "incorrect": the code will still compile (unless there's some corner case I'm missing?), so for that particular definition of correctness it is just fine without TCO. It just won't run (for very long). :)
- dantheman 16y agoI agree, but compilation is a low barrier for correctness :)
- sukuriant 16y agoWould it be that impossible to keep a counter of what iteration of function X the user is on? Or, does tail recursion also count things like: int A() { return 1 + B(); } int B() { return 1 + A(); } (with necessary ending conditions)
- crux_ 16y agoYes, tail call optimizations include mutually recursive functions. Note that your example was not of tail calls, however. (Tail call would be: return A(...); that is, a tail call is one whose result is immediately returned.)
- sukuriant 16y agoThat does become harder to follow, then. And, woops...
- mkross 16y agoWait, generics support co/contra variance through the 'extends' and 'super' keywords. e.g. Collection<? extends Foo>
- quicksilver03 16y agoThe only thing that I would fix in Java Generics is the syntax, the use of angle brackets is what makes me reject the whole implementation.