C9 Lectures: Dr. Erik Meijer  Functional Programming Fundamentals Chapter 12 of 13
Description
In Chapter 12, Lazy Evaluation, Dr. Meijer takes us on a journey into the world of order of evaluation (when expressions are evaluated). In the case of lazy evaluation, computation is delayed until the result of the computation is known to be required.
Most programming languages that most of you use day to day use eager or strict evaluation, which is the
opposite of lazy evaluation. In the strict evaluation world, expressions are evaluated as soon as they are bound to a variable (this is also known as greedy evaluation). In Haskell, laziness is first class!
Tune in. Learn and enjoy!
Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
Chapter 6
Chapter 7
Chapter 8
Chapter 9
Chapter 10
Chapter 11
Chapter 12
Chapter 13
Download
Download this episode
 High Quality WMV (746.7 MB)
 MP3 (21.7 MB)
 Low Quality MP4 (315.8 MB)
 Mid Quality WMV (444.0 MB)
More episodes in this series
C9 Lectures: Dr. Erik Meijer  Functional Programming Fundamentals Chapter 13 of 13
Related episodes
C9 Lectures: Dr. Erik Meijer  Functional Programming Fundamentals Chapter 13 of 13
C9 Lectures: Dr. Erik Meijer  Functional Programming Fundamentals Chapter 10 of 13
C9 Lectures: Dr. Erik Meijer  Functional Programming Fundamentals Chapter 9 of 13
C9 Lectures: Dr. Erik Meijer  Functional Programming Fundamentals Chapter 8 of 13
C9 Lectures: Dr. Erik Meijer  Functional Programming Fundamentals Chapter 7 of 13
C9 Lectures: Dr. Erik Meijer  Functional Programming Fundamentals Chapter 5 of 13
C9 Lectures: Dr. Erik Meijer  Functional Programming Fundamentals, Chapter 3 of 13
C9 Lectures: Dr. Erik Meijer  Functional Programming Fundamentals, Chapter 1 of 13
C9 Lectures: Graham Hutton  How To Be More Productive
C9 Lectures: Dr. Ralf Lämmel  Going Bananas
The Discussion

So this wonderful series draws to a close on Christmas eve 2009, does that mean on Christmas day we get Haskell .NET?

$!  Talk about bang for the buck ("show me the money"), just in time for christmas
It's nice to know when to introduce strictness. As for how lazy evaluation deals with this accumulation, isn't that a matter of choice on part of the compiler writer? I would assume that is what "strictness analysis" is for. Looking closer...
This lambda book looks nice to have as well.
(End of lazy rewriting of post)

It has been a great journey learning about functional programming in Haskell. To bad I’m going to be out of the country (no internet) for the last lecture

I'll be out too for the last lecture. Hope I'll be able to watch it in China. Happy holidays and wishing great 2010 New Year!

I hope the lectures continue from time to time after this one is done. It would be cool with an audience (local or otherwise) of a select few (one or more) that can ask the right questions at the end, having witnessed the lecture, just to make the experience more interactive. But this has been a truly great initiative. In a typical Channel 9 video you learn something but here the amount of knowledge density is greater (sans the interactive MeijerBeckman combo which also has great knowledge density, sometimes too great heh.)
By the way Erik, have we caught you doing destructive updates of the whiteboard?

I thought I understood lazy evaluation, but I didn't. Very enlightening. Thanks!

Charles and Erik,
Does the series end on Xmas eve!?? What a strange coincidence indeed!
Absolutely fantastic series; all developers should make an effort to understand functional programming in general and haskell in particular. I think it broadens your horizons and makes you a better professional.
Thanks again for these lectures!

Thanks so much everybody for the enthusiastic reception of the lecture series.
I promised Charles to write a book on Rx and lecture about it on Channel 9. What I will probably do instead is lecture about it on Channel 9 and then write each chapter.

You're writing a book on Rx Erik? Awesome. I'll take my place in the long queue of folks offering to act as technical reviewers  although I suspect you won't be short of 'in house' offers. Over the past 18 months, in large part because of the conversations and lectures from yourself and Brian I've found that "composition" has become my new programming mantra. Hope you have a great holiday and a brilliant 2010.

I assume (end of year fire fighting and rush jobs, so no time to find out myself) that Rx is processed lazily, but would there be any scenerios where you would want to do strict calls?

While these lectures are coming to an end we can all look forward to the C9 letures on F#. Charles any idea when that's comming?

Soon..

Well I have to be careful as I've had a lot of brandy tonight.. it is christmas after all, and I am Irish!
But
Lazy Evaluation is a specific name for a more general concept; and in my opinion that more general concept is Delegation. In many ways we ultimately try to model computations on how we process things ourselves: abstractly our brain processes information streams, and reacts to what we receive: event based programming over streams... thanks for Rx
But delegation is key to ANY model of higher orderness, because we delegate the evalution of a "value" to the "item" than can more functionally evaluate that in the best fashion.
Personally I'm an architect, and I consider deployinging a solution as an aggregate of tenchology and people. However you always have to delegate to people, and if you unfold the implementation of a project what you realise is that people are the most important function that are applied to data.

I'd say that applies more to the notion of monads, where you are explicitly distinguish between values of type T and computations of type M<T> (which of course themselves are first class values). In your words, you are delegating the computation of a value to the monad.

Interesting point, I'll have to think about that quite a bit.
I'm not sure I fully get Monads yet.
How does this relate to the concept of an object type? A package of state and behaviour ... is a Monad just an object that obeys a certain behaviour pattern? I've seen them described as amplified Types, and clearly if you have your type obey the behaviour pattern (the monad laws) you get compositional types. I don't quite see yet how this differs from an Type that implements an interface with Bind and Return/Unit methods and thus are supported by certain syntax. Suddenly everything starts to look like a Monad of some sort if it encapsulates data and computations.
I think I'm missing some key insight that differentiates a Monad from an object type: they look very similar to me, both of them represent state and behaviour that can be applied to that state  is it just that a Monad has something more specific to say about the behaviours that are applied? I'm guessing this is what gives them the mathematical properties that allows you to reason about them in a certain way...

That will definitely be wellreceived! Thanks for presenting this fantastic series, Erik. Happy new year!