Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 8 Lambdas

datumedge.blogspot.co.uk

Post reply on HN
Print view View original

131–140 of 144 posts

Re: Java 8 Lambdas

#131

Post by clavalle »

jimbokun wrote: post #103
diego_moita wrote: post #76

Earlier quoted context omitted.

No, I was not trolling. The key to understand the whole thing is that it was not a software company, but a construction company and I was there as a consultant. For them, software is a cost, not a source of revenue. That's why they didn't implement rigorous practices such as code reviews. That's why they'd prefer the cheaper against the better coders. That's why I already followed your 3rd advice.

It's hard for me to think of a good reason why a construction company should be writing custom software, instead of buying something off the shelf.

For the same reason any other large enterprise does...so many special cases in their organically grown 'systems' that it would be cheaper to get something custom coded than try to shoehorn their process into an off the shelf environment.

Re: Java 8 Lambdas

#132

Post by eropple »

fauigerzigerk wrote: post #124
sreque wrote: post #99

Earlier quoted context omitted.

I don't understand or agree with your logic at all. Oracle shouldn't waste time on Java because it is already so far behind as to be hopeless? That notion seems silly at best, especially as 99% of code written on the JVM is still done in Java. Also, generics fiasco? Generics may not be perfect, but I haven't met a single person who isn't glad that they are in the language. Who has done generics better? C#? Because C#…

I agree with your first point. There's no reason not to make Java better. But generics have been a fiasco. No collections of primitive types? Come on, that is a major fiasco for code that needs to be memory efficient.

Trove and Colt handle those cases fine.

Re: Java 8 Lambdas

#133

Post by drostie »

Will you be able to return lambdas or just create them as function inputs? (I guess you can write a method which takes an object of interface X and returns it, but do you have to do this for every interface you want to use, or would there be a universal reify() method? Is there a universal interface which would allow these to be proper first-level functions?)

If there are competing lambda interfaces, does the system fail at compile-time?

Re: Java 8 Lambdas

#134

Post by soc88 »

Djehngo wrote: post #128
soc88 wrote: post #127

Earlier quoted context omitted.

You're missing the point. The problem is that as an author you have to implement an interface which is probably completely unrelated to what your class is doing, otherwise you get punished by bad performance. Scala solves this problem nicely with traits, btw.

I may also be missing the point but what prevents you from putting a count method on an enumerable with a default implementation which does the same? In terms of .Count() which will attempt to call ICollection.Count you can create the same thing as an extension method or a default implementation on Enumerable. Either way you do it you will have ambiguity regarding time complexity. Extension methods have the advantage…

> I may also be missing the point but what prevents you from putting a count method on an enumerable with a default implementation which does the same?

Isn't that exactly what we're talking about?

The huge difference between C#'s extension methods and traits is that the first one is statically dispatched, the second one dynamically.

This means classes with a better implementation can just override Count() and suffer none of the problems of the extension method approach.

Scala also offers implicits to "enrich" existing types, slightly comparable to Extension methods, but a lot more general.

Whereas extension methods only support some ad-hoc "addition" of members to existing types, Scala's implicits allow you to use these methods to implement new interfaces -- and isn't that the reason why you add methods in the first place: to implement interfaces?

> So for a (poor) example you might extend float so you could convert an angle to a 2d unit vector, but only in given bits of your program you want to be converting between angles and vectors.

   implicit def floatTo2DUnitVector(angle: Float) = 2DUnitVector(...)
Done. Import where you need it.

Btw, C# has some limited form of implicits, too, but I haven't seen any serious usage of them for a while.

Re: Java 8 Lambdas

#135

Post by eru »

masklinn wrote: post #16
barrkel wrote: post #9

'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.

> 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. 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 ev…

> Trivial for dynamically typed languages, but how do you handle the type of that key in a statically typed language?

Haskell handles this just fine. Static types are only a problem, if they are weak and/or your language syntax is cumbersome. Automatic type inferences helps, of course.

Re: Java 8 Lambdas

#136

Post by eru »

Peaker wrote: post #57
batista wrote: post #42

Earlier quoted context omitted.

How do you define the sorting key in a static language? With reflection? e.g if anArray is a Java array of Employee objects, and you want to sort on their salary attribute, how do you specify it? anArray.sortBy(???); In a dynamic language it doesn't matter much, since all attribute access amounts to (and is as slow as) reflection on a static language anyway, so you can do something like, say: anArray.sortBy("salary")…

In Haskell, sortBy takes a comparison function: sortBy :: (a -> a -> Ordering) -> [a] -> [a] And Ordering is defined as: data Ordering = LT | EQ | GT If you want to provide a "key" function rather than a comparison function, you can use sortOn: sortOn :: Ord b => (a -> b) -> [a] -> [a] Which is basically just a sortBy with a function that applies the key function and then compares as normal.

And everything is statically typed.

Re: Java 8 Lambdas

#137

Post by ImJasonH »

Sandman wrote: post #96

I was recently at a Java conference where Juergen Hoeller (of Spring fame) was a keynote speaker. In one of his talks he said something like "Once again, Java is solving yesterday's problems". The moment he said that, I thought to myself "Yes! So true!". The day before, Angelika Langer gave a talk on Lambdas in Java 8. I watched as the other developers listened with half-opened mouths (and some of them, with confused…

If they were solving tomorrow's problems everyone would complain about premature optimization.

Or time travel. :)

Re: Java 8 Lambdas

#138

Post by kmontrose »

soc88 wrote: post #134
Djehngo wrote: post #128

Earlier quoted context omitted.

I may also be missing the point but what prevents you from putting a count method on an enumerable with a default implementation which does the same? In terms of .Count() which will attempt to call ICollection.Count you can create the same thing as an extension method or a default implementation on Enumerable. Either way you do it you will have ambiguity regarding time complexity. Extension methods have the advantage…

> I may also be missing the point but what prevents you from putting a count method on an enumerable with a default implementation which does the same? Isn't that exactly what we're talking about? The huge difference between C#'s extension methods and traits is that the first one is statically dispatched, the second one dynamically. This means classes with a better implementation can just override Count() and suffer…

> This means classes with a better implementation can just override Count() and suffer none of the problems of the extension method approach.

Instance methods are bound before extension methods, if someone provides an implementation of Count() in a subclass it'll be invoked instead (provided your reference is typed appropriately). More narrow extension methods are bound before general ones, so you can even "override" within extension methods.

Scala has some neat stuff, but it's not Java 8 so I don't see how it's relevant.

> Btw, C# has some limited form of implicits, too, but I haven't seen any serious usage of them for a while.

C# has implicit conversion operators you can define, http://msdn.microsoft.com/en-us/library/z5z9kes2(v=vs.100).a... . You'd better have a really good reason for defining one though, silent conversions are generally frowned upon.

Re: Java 8 Lambdas

#139

Post by soc88 »

kmontrose wrote: post #138
soc88 wrote: post #134

Earlier quoted context omitted.

> I may also be missing the point but what prevents you from putting a count method on an enumerable with a default implementation which does the same? Isn't that exactly what we're talking about? The huge difference between C#'s extension methods and traits is that the first one is statically dispatched, the second one dynamically. This means classes with a better implementation can just override Count() and suffer…

> This means classes with a better implementation can just override Count() and suffer none of the problems of the extension method approach. Instance methods are bound before extension methods, if someone provides an implementation of Count() in a subclass it'll be invoked instead (provided your reference is typed appropriately). More narrow extension methods are bound before general ones, so you can even "override"…

That's exactly the issue I'm talking about: you can't “enforce” the static type, so different methods get called depending on whether you pass List foo = MyList(...) or MyList foo = MyList(...), which is acceptable for static methods, but a source of bugs when they can be made to look like instance methods.

> Scala has some neat stuff, but it's not Java 8 so I don't see how it's relevant.

Java's default methods are basically Scala's traits (just made a bit more cumbersome to make Java developers feel right at home), so what I said about traits applies to “interfaces with default methods”, too.

Post reply on HN