Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals Chapter 12 of 13

Download

Right click “Save as…”

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

 

 

Tags:

Follow the Discussion

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

  • Bent Rasmussenexoteric stuck in a loop, for a while

    $! - Talk about bang for the buck ("show me the money"), just in time for christmas Smiley

     

    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 Sad

  • David Chuchudq Life is beautiful, and sharing is ​wonderful&#​33;

    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!

  • Bent Rasmussenexoteric stuck in a loop, for a while

    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 Meijer-Beckman 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? Wink

  • Richard Anthony HeinRichard.Hein Stay on Target

    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.

  • ChevalN2Cheval Why not null?

    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?

  • CharlesCharles Welcome Change

    Soon.. Smiley

  • ParmenioParmenio () => {}

    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 Smiley

     

    But delegation is key to ANY model of higher order-ness, 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.

  • ParmenioParmenio () => {}

    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 well-received! Thanks for presenting this fantastic series, Erik. Happy new year!

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.