31–40 of 50 posts
Earlier quoted context omitted.
Could you try to give a summary for those who don't?
The summary: "Hickey did not invent FP, how dares he?"
Earlier quoted context omitted.
Transducers _can be_ parallelized (TODO) but some transducer implementations do contain state, like `take` and therefore cannot be parallelized. The big thing is no intermediate results.
If you watch the first Rich Hickey Transducers talk, he shows that some transducers (the ones that rely in the underlying reduce implementation that uses fork/join and assumes that reducing the collection is associative) are already parallelized. I agree with you regarding `take`
Earlier quoted context omitted.
So transducers are like .Net/LINQ enumerables?
Nah, Clojure seqs are more like .NET/LINQ enumerables. Functions that work over seqs/enumerables return a new seq/enumerable. From what I understand, and I'm sure I am wrong, a transducer receives and transforms a value, and may call the next transducer with the transformed value. The nice thing is that a transducer does not create intermediate results (a seq/enumerable), and that it doesn't make any assumptions on t…
Enumerable.Range(1, 100)
.Where(n => n % 2 == 0)
.Select(n => n * 2)
.ToList();
sequence(
Enumerable.Range(1, 100),
compose(
filter(n => n %2 == 0),
map(x => x + 1)
)
).ToList();
I absolutely understand the case where a language's map/filter/reduce/etc results in a whole new list, but for the above case the performance/memory overhead improvement doesn't see that huge and really minor. The fact that it removes the overhead of having to support IEnumerable and as you mentioned is only dealing with functions is what seems like a win. At first I was thinking that plain old LINQ is also more readable, but my contrived c# transducer example doesn't look that bad in the end. Am I incorrect on any of this?
Even if you forget entirely about Clojure for a second, Rich has this very rare gift to take a complicated subject and make it easy for the audience to understand.
That that for what you will, but please be aware that a "gift for simplification" sometimes is a double-edged sword and can leave the audience thinking that they've understood when, actually, they haven't.
I'm not saying that's the case here, just something to be wary of.
Earlier quoted context omitted.
The summary: "Hickey did not invent FP, how dares he?"
People keep attacking him whenever he interduces something. Why? Every time he releases something, he also shows from what research it originated. Go back to the first transducer talk and you will see the references.
(I think Rich is absolutely spot on on many of the more abstract things about or industry/craft, but this is just one of those details that irks me.)
[1] http://existentialtype.wordpress.com/2011/03/19/dynamic-lang...
Even if you forget entirely about Clojure for a second, Rich has this very rare gift to take a complicated subject and make it easy for the audience to understand.
This is a double-edged sword. Forgive me a small anecdote: I once had a wonderful tutor who could explain any advanced concept in highly intuitive terms and it just made sense... until I got out of the classroom. At which point I'd just have this feeling of "Hang on, whaaaaaa...?". The first time I attempted the exam in this particular subject matter, I failed miserably (rightly so). Having learned my lesson, I went…
Earlier quoted context omitted.
If you watch the first Rich Hickey Transducers talk, he shows that some transducers (the ones that rely in the underlying reduce implementation that uses fork/join and assumes that reducing the collection is associative) are already parallelized. I agree with you regarding `take`
IIRC from yesterday's talk he was explaining that these will be easy to parallelize, and its slated for 1.7. I had thought they were already parallel myself until I saw the talk; and possibly some of them are, but the item is still Open. http://dev.clojure.org/jira/browse/CLJ-1553
Earlier quoted context omitted.
For me the "ephiphany" was when I realized reduce don't need to be (T,T)->T, but can be (T1, T2) -> T1.
They can also be (T1,T2)->T3
When you reduce with function f(T1, T2) -> T3 the result of previous iteration becomes first argument for the next iteration, so they must be of the same "type".
Or am I missing something?
Earlier quoted context omitted.
This is a double-edged sword. Forgive me a small anecdote: I once had a wonderful tutor who could explain any advanced concept in highly intuitive terms and it just made sense... until I got out of the classroom. At which point I'd just have this feeling of "Hang on, whaaaaaa...?". The first time I attempted the exam in this particular subject matter, I failed miserably (rightly so). Having learned my lesson, I went…
I had similar experiences many times, and I don't know what's best, looking at an abstraction for weeks until you get the "ohh they just meant this" or knowing in advance it's not that obscure and then work to imprint said abstraction deeper.