11–20 of 144 posts
Congratulations to the Java-programmers for getting a feature that virtually every other OOP language has had for about 10 years.
Care to elaborate? Ruby had them from day 1, PHP has only had them since 5.3, not sure what the deal is with python.
Congratulations to the Java-programmers for getting a feature that virtually every other OOP language has had for about 10 years.
Earlier quoted context omitted.
Care to elaborate? Ruby had them from day 1, PHP has only had them since 5.3, not sure what the deal is with python.
C# has had them for a little while now.
C# lambda expression syntax (the =>) are about 4 years old now.
Finally... and they even infer the type! Positively surprised. I will stick to Scala, though.
'sorted()' doesn't really act like that, does it - taking in a comparator function? It's much better to have comparator functions for the most common types baked in, and use projection to select a list of fields to use to compare with. Comparator functions are very easy to get wrong. The example given here - ".sorted((a, b) -> a.getValue() - b.getValue())" - won't work properly when the calculation wraps around.
Except that requires a sorting key for the result. Trivial for dynamically typed languages, but how do you handle the type of that key in a statically typed language? Mandate that the key be a string? Build a limited set of overloads against a dedicated type? And even then, how do you specify the relative constraints of the different values within that key, especially within the limitations of java's type system?
> The example given here - ".sorted((a, b) -> a.getValue() - b.getValue())" - won't work properly when the calculation wraps around.
But that's less an issue of "comparator functions [being] very easy to get wrong" and more an issue of "integer is an asinine type to use as ordering result". Even more so in a statically typed language. Haskell uses a dedicated enumerated type[0] which does not have this issue.
[0] http://hackage.haskell.org/packages/archive/base/latest/doc/...
I'm curious to see what the implications are for other JVM languages given the promise of more efficient byte code.
Earlier quoted context omitted.
Care to elaborate? Ruby had them from day 1, PHP has only had them since 5.3, not sure what the deal is with python.
Python has lambdas and functions as first-order values since the beginning.
I don't know how I feel about interface defaults. Why is that more important than say declared properties or unsigned types?
Declared properties and unsigned types are relatively small changes. BTW, in JDK8 they have provided limited support for unsigned types, just not at the language level:
Finally... and they even infer the type! Positively surprised. I will stick to Scala, though.
They can't _really_ infer the type. You just have to have one less set of pizzas. It doesn't work like scala's type inference.
http://download.oracle.com/otndocs/jcp/lambda-0_5_1-edr2-spe...