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

121–130 of 144 posts

Re: Java 8 Lambdas

#121

Post by flatline3 »

kamaal wrote: post #120
flatline3 wrote: post #106

Earlier quoted context omitted.

There are significant lessons to be learned from functional programming, the least of which is the value of immutability in making complex systems comprehensible. Immutability is almost completely necessary for easy-to-understand concurrency, and extremely helpful in designing easy-to-understand APIs and operations on in-memory-models. It is a poor programmer indeed that discards the lessons of FP and instead writes…

>>It is a poor programmer indeed that discards the lessons of FP and instead writes purely imperative OO. Your interns may have been writing bad code, but it wasn't the "functional" part that was the problem. Functional code is not Idiomatic Java code, 99.99% of Java code, practices and projects do not have it. Now when you go and bolt functional code on top of it, you are putting a tough puzzle on top of the code. D…

It's bad code to write idiomatic mutable imperative Java. I'm not willing to write worse code just because bad engineers can't get their head around basic concepts that are integral to reliability, composability, maintainabiliy, and correctness.

Maintaining 'idiomatic' Java written by an 'average' developer is far more difficult and disheartening than maintaining well-written Java based on lessons from FP.

Re: Java 8 Lambdas

#122

Post by kamaal »

flatline3 wrote: post #121
kamaal wrote: post #120

Earlier quoted context omitted.

>>It is a poor programmer indeed that discards the lessons of FP and instead writes purely imperative OO. Your interns may have been writing bad code, but it wasn't the "functional" part that was the problem. Functional code is not Idiomatic Java code, 99.99% of Java code, practices and projects do not have it. Now when you go and bolt functional code on top of it, you are putting a tough puzzle on top of the code. D…

It's bad code to write idiomatic mutable imperative Java. I'm not willing to write worse code just because bad engineers can't get their head around basic concepts that are integral to reliability, composability, maintainabiliy, and correctness. Maintaining 'idiomatic' Java written by an 'average' developer is far more difficult and disheartening than maintaining well-written Java based on lessons from FP.

In this case you shouldn't use Java at all. Because if your use case requires functional programming then you must use a functional programming language. Force fitting a non native paradigm to a tool and then calling those who don't understand it as bad is not fair.

I'm good != Others are bad.

>>Maintaining 'idiomatic' Java written by an 'average' developer is far more difficult and disheartening than maintaining well-written Java based on lessons from FP.

More than 90% of the Java projects I know are chosen to written in Java because its easy, cheaper, quicker to hire the 'average developer'. And not because of the merits of Java itself. These days 'Knows to use eclipse' == 'Knows Java', even if all the programmer knows is basic syntax, its assumed he can code in Java using intellisense and code complete.

Most of the Java code written today is tool generated, any way.

Re: Java 8 Lambdas

#123

Post by pjmlp »

kamaal wrote: post #119
gurkendoktor wrote: post #109

Earlier quoted context omitted.

As a "language snob", I feel that Java is hopelessly behind among JVM languages. But I also think that C# is well-designed enough that it doesn't matter whether it's the only CLR language I'll ever use. I don't know if the grandparent poster feels the same, but your post actually confirms my opinion. Of course I have no realistic idea how Oracle would ever migrate millions of Java coders to a cleaner language. :(

>>As a "language snob", I feel that Java is hopelessly behind among JVM languages. Java is designed by its existence to be a better C++, nothing much. Nothing changes that base design goal. But this is a design goal for the late 80's and early 90's. The fate of most Java-only programmers, which are uncountable today is pitiable to say at the least. Its like Dijkstra said, one must avoid prolonged exposure to bad tool…

> "Employable only at MegaCorps"

Usually it comes with a salary full with nice digits.

Re: Java 8 Lambdas

#124

Post by fauigerzigerk »

sreque wrote: post #99
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…

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.

Re: Java 8 Lambdas

#125

Post by gouranga »

thomasz wrote: post #108
gouranga wrote: post #95

Earlier quoted context omitted.

You miss one important point, which I've learned from many years of using .Net: Which dereference in your LINQ expression is causing the NullReferenceException? Try solving that problem when it goes pop in production and you have a couple of million quid in flight! I'd write it as follows (probably wrapped as a generic function of T: public Thing GetItemWithName(ICollection collection) { Thing output; int found; // p…

Well, if the error reporting of Enumerable.Single() isn't good enough for you (i think it throws InvalidOperationExceptions with different messages for both error cases), nothing stops you from implementing it once for yourself and profit from the benefits everytime instead of writing the same looping constructs interlaced with error reporting again and again. public static T MySingle ( this IEnumerable collection, F…

Your code iterated more than once. Mine doesn't. Mine is O(N). This is one of the side effects of using all the functionality.

On a positive note, your example is very lisp-like.

Re: Java 8 Lambdas

#126

Post by thebluesky »

flatline3 wrote: post #22
ohhmaagawd wrote: post #8

Would have been a big deal - if they introduced 10 years ago

Java is still widely used. I'm looking forward to this -- there are some projects we can't take to Scala due to client concerns around a less mainstream language.

Scala is starting to become more and more mainstream these days: http://www.indeed.com/jobanalytics/jobtrends?q=scala&l= but I do look forward to the enhancements in Java for the existing code I maintain.

Re: Java 8 Lambdas

#127

Post by soc88 »

kmontrose wrote: post #80
gouranga wrote: post #75

Earlier quoted context omitted.

The problem I have with extension methods is semantics and determinism, particularly in the collections framework (if you can call it that - it's a mess). Great example: Look at System.Core's Count() inside reflector. Using pseudo code: def count(ref): if ref is ICollection: return (ref As ICollection).Count else n = 0 for each item in ref: n++ return n That hurts badly if you are not careful. Enumerables will be ite…

What about interface defaults prevents or precludes that hack/optimization? You have exactly the same information after all. For example (disclaimer, it's been a bit since I've touched these classes; but you should get the idea), an extension of Iterator that adds a longSize() method would probably want to make use of ArrayList's size() rather than iterating over the whole thing too. As an aside, if your code absolut…

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.

Re: Java 8 Lambdas

#128

Post by Djehngo »

soc88 wrote: post #127
kmontrose wrote: post #80

Earlier quoted context omitted.

What about interface defaults prevents or precludes that hack/optimization? You have exactly the same information after all. For example (disclaimer, it's been a bit since I've touched these classes; but you should get the idea), an extension of Iterator that adds a longSize() method would probably want to make use of ArrayList's size() rather than iterating over the whole thing too. As an aside, if your code absolut…

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 that the langauge designers _could_ have left .Count() off IEnumerable and then people who wanted to use it could implement it themselves and those worried about the ambiguity wouldn't have to risk people enumerating their collection needlessly.

The problem with extension methods over default implementation interfaces is that the code regarding a class can be distributed in several (potentially non-obvious) locations and it reduces portability.

The advantage is that you can extend a class or an interface you don't own, and you can have implementations specific to a given namespace.

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.

Re: Java 8 Lambdas

#129

Post by moomin »

masklinn wrote: post #44
barrkel wrote: post #21

Earlier quoted context omitted.

I don't know what you mean by "sorting key" in this context. The idiom I have in mind is how .Net implements "SortBy", "ThenBy" and friends. Overloads can be used for a comparator function based approach, but it should not be the first choice. And I'll stand by comparators being easy to get wrong, particularly when values may be null, polymorphic, etc.

> I don't know what you mean by "sorting key" in this context. The result of the projection which is associated with each value and used to actually sort the values. > The idiom I have in mind is how .Net implements "SortBy", "ThenBy" and friends. I assume you mean OrderBy. I see, instead of having sorting as a single atomic operation it becomes a stateful multi-step transformation of the iterator. I can still see we…

For the record, T needs to implement IComparable. I think there are special rules for anonymous types for convenience.

And do bear in mind that C# supports both idioms. So you can handle hard cases any way you want.

Re: Java 8 Lambdas

#130

Post by thomasz »

gouranga wrote: post #125
thomasz wrote: post #108

Earlier quoted context omitted.

Well, if the error reporting of Enumerable.Single() isn't good enough for you (i think it throws InvalidOperationExceptions with different messages for both error cases), nothing stops you from implementing it once for yourself and profit from the benefits everytime instead of writing the same looping constructs interlaced with error reporting again and again. public static T MySingle ( this IEnumerable collection, F…

Your code iterated more than once. Mine doesn't. Mine is O(N). This is one of the side effects of using all the functionality. On a positive note, your example is very lisp-like.

> Your code iterated more than once.

Uh... no.

*edit The first element is iterated three times, the second two times and the rest once, making it O(n).

Post reply on HN