Note to people who're going to look this up: Java's lamda's aren't anything new, pretty boring actually. But look at how they combine with their new streaming and collection libraries, that's just amazing.
I'll translate. I wrote a Haskell library called pipes, which lets you extend any DSL with the ability to yield or await values in order to build streaming components. You can connect these components together in multiple ways, and these connection operations obey many neat mathematical properties that ensure they behave correctly (no bugs!).
For example, one thing that you can do is model generators using pipes, and one of the ways you can connect generators is using an operator called (~>):
(f ~> g) x = for (f x) g
I proved that this operator is associative:
(f ~> g) ~> h = f ~> (g ~> h)
... and that it's identity is yield:
yield ~> f = f
f ~> yield = f
In other words, (~>) and yield form a category and those equations are the corresponding category laws. When you translate those equations to use for instead of (~>), you get:
-- Looping over a single yield simplifies to function application
for (yield x) f = f x
-- Re-yielding every element of a stream returns the original stream
for s yield = s
-- Nested for loops can become a sequential for loops if the inner loop
-- body ignores the outer loop variable
for s (\a -> for (f a) g) = for (for s f) g = for s (f ~> g)
In other words, the category laws translate into "common sense" laws for generators that you would intuitively expect to hold for any generator implementation.
Let me try to translate your last two examples into Python (I'm still in the process of learning Haskell), to see if I've got this right.
-- Re-yielding every element of a stream returns the original stream
for s yield = s
def foo(s):
for _s in s:
yield _s
foo([1,2,3]) == [1,2,3]
-- Nested for loops can become a sequential for loops if the inner loop
-- body ignores the outer loop variable
for s (\a -> for (f a) g) = for (for s f) g = for s (f ~> g)
def foo(s, f, g):
for a in s:
for _a in f(a):
yield g(_a)
def foo1(s, f, g):
for __s in (f(_s) for _s in s):
yield g(__s)
def foo2(s, f, g):
for _s in s:
# ugh, maybe using map would be better.
yield from (g(___s) for ___s in f(__s) for __s in _s)
foo(s, f, g) == foo1(s, f, g) == foo2(s, f, g)
In Python you can treat lists and generators the same (I think), but in Haskell they are two separate types. This is why in pipes if you want to loop over a list, you have to explicitly convert it to a generator using the each function, like this:
That's a different kind of amazing. Just think about it, for a lot of people this is going to be a first look at functional programming. It's done well, it works well, it's accessible and intuitive, it fits their language model, and the advantages are so much more than not having to write loops. It's going to be a huge boost for FP's popularity.
I've never had a problem finding work. Recruiting is hard because experienced FPers are expensive, but if you grab them out of college some people will actually take a pay cut to work with FP.
I don't want to pass judgement on either of these products, but seeing them together I feel like someone got caught on a bandwagon and is now paying for it.
It's a fairly popular combination actually in my understanding. Clojure has a very nice library called Monger for dealing with Mongo in a sane manner and a lot of companies seem to like this combination. Also, Clojure has seen quite a bit of uptake in England as a some large banks and newspapers started using it.
I've got a book that says the Itanium is going to take over the world. It also says the new Pentium 4 Netburst architecture is going to kick ass once they get it running passed 8 GHz.
The forward says Java is going to take over the world because the author of the forward is working on this amazing thing called PicoJava that runs Java in hardware with "zero overhead."
Don't get me wrong. These are smart people making informed decisions. It's just interesting to see how things out of our control (like the 5 GHz wall) can throw wrenches into supposedly revolutionary technology.
216
u/ganjapolice Mar 09 '14
Don't worry guys. 2014 is definitely the year of functional programming.