http://stackoverflow.com/questions/9864497/generate-a-sequence-of-fibonacci-number-in-scala
Post by Scott ShippNow I'm really hooked on this lambda business. I just updated my gist with
newly learned code. (https://gist.github.com/scottashipp/9916656)
Lines of code in Java 7 - 70
Lines of code in Java 8 - 37
Scott
------------------------------
Date: Tue, 1 Apr 2014 09:20:43 -0700
Subject: Re: [seajug] [ANN] JDK 8 Crash Course (3/27)
http://docs.oracle.com/javase/tutorial/collections/streams/parallelism.html
I think limit(n) is similar to Haskell's 'take'. There is also a skip(k).
Due to a desire to answer Steve's question seriously, I've been
experimenting with lambdas and comparing/contrasting the old SAM way versus
the new Lambda way. The main example I wanted to try for myself was
https://gist.github.com/scottashipp/9916656
TL;DR - Lambdas are cool and yes, they are more readable as far as usage
within the bounds of what they were designed to do.
1. It *is* more readable to do it the Lambda way, if you are using
Lambdas the way they are designed.
2. It is *not* more readable if you abuse it. There were some things I
tried where I think I found the limits of lambdas, at least in this
particular case.
3. For this particular case of simply listing numbers to the screen in
series order, .parallel() doesn't work...your numbers come back out of
order...but this showed me how powerful parallel() could be when you might
be doing something like updating objects in a collection, where order is
not important.
4. The Lambda version is more expressive (more nerdy at least) if you like
lines like "generateValue.andThen(format).apply(i)".
5. Speaking of the chained functions feature, that is really nice.
Although I didn't do it in this example, you can see how abstracting the
formatting completely away would be really helpful. In the Java 7 version,
the method takes a "NumberFormat" object. But in the Java 8 version, it
just takes a function which might encapsulate any kind of behavior. Sure,
sure, if you really needed this in J7 you could easily create your own
subclass of NumberFormat but there you are again writing way more code than
you probably need to do something that is conceptually simple.
6. Lambdas are so horizontal, that you either keep them on one line which
potentially runs past the right side of your screen or you break them up
onto separate lines, in which case I wonder how much it really "solves the
vertical problem."
This is *mostly *syntactic sugar but in the best sense. I think this
actually accomplishes something for the developer in terms of the
conceptual idea in the code matching the way you might actually think
about. (Yes I know it is not ALL syntactic sugar since there are new scope
rules, the potential for lazy evaluation, etc.)
Now for a question: does anyone know if Java 8 has anything like the
Haskell "take" keyword (see example at
http://mdickens.me/2013/12/16/those_weird_haskell_features_are_actually_useful/)? That would be even better.
Scott
------------------------------
Date: Thu, 27 Mar 2014 16:16:19 -0700
Subject: RE: [seajug] Re: [ANN] JDK 8 Crash Course (3/27)
it's hard to say if it is more readable. Probably those of us programming
in Java for awhile now will automatically think the JDK 7 and lower type of
implementation will be "more readable" simply due to familiarity. I'm
reserving my judgment until I can get time to sit down and absorb the
lambda way of thinking more.
However, right now I don't like the idea of using Lambda expressions for
stuff even as complex as the anagram kata, which is actually fairly simple.
Instead, I like lambda's for things like filtering, counting, etc. from a
larger collection. You know...stuff like generate all the fibonacci numbers
up to some value or count the number of managers in this list of employees.
Which is all I ever used the "old" way of passing anonymous classes into
method parameters anyway. To my mind, even if something is readable /
simple to me, it may not be readable to someone else on the team, maybe a
jr dev not yet familiar with the concept? Perhaps it is best for
maintenance purposes not to put so much idea-space into one line of code.
On another note, I noticed that your code takes the approach of rolling a
private class as a data structure to hold the anagrams. I did this kata
last year and instead of doing that I simply made a Map<String,
List<String>> to hold the anagrams. You can see this at
https://gist.github.com/scottashipp/7680127 with an explanation of the
thought process at
http://code.scottshipp.com/2013/11/27/given-a-word-file-find-all-words-that-are-anagrams/.
I find this to be simpler and more readable, personally. It basically cuts
the solution down to 20 lines of code (the rest of my code is a small timer
class and some basic output). However, if you are a developer who doesn't
like nesting collections within collections this feels like anathema, I'm
sure.
Anyway, my implementation didn't split lines of text into words, either,
or do the other things in your guys' like find the longest, etc.
String keyWord = key(word);
Cheers,
Scott
------------------------------
Date: Thu, 27 Mar 2014 15:05:07 -0700
Subject: [seajug] Re: [ANN] JDK 8 Crash Course (3/27)
Having looked at Joe BowBeer's Java 8 Anagrams bitbucket.org/joebowbeer/
anagrams I decides to look at what a Java 7 implementation would look like -
http://bitbucket.org/steve_lewis_/anagrams-jdk-7
The file is more verbose -
my questions -
1) is it more readable
2) My version does the following
a) splits a line of text into words
b) drops punctuation
It would be interesting to see how hard it would be to add those features
to Joe's version
Also look at both - neither has comments for readability and
understandability
-
Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State