In August, I was also struggling with laziness. As I went along my learning curve, I realized that much of this fog in my mind came up because I was still taking mutability of data and side effects as "normal" by habit. I had not "spliced" my thoughts while toggling between Java and Clojure, something I was doing a lot at the beginning.
Once I hammered in my brains that everything in Clojure is immutable by default while coding, it cleared up things. I could now deal with the distinction between desired side effects and deferred results (laziness). Now side effects in my code are exceptions and this helps circumvent the laziness gotchas. Today it's now integrated in my mind and I do not face such problems anymore. I still do not know why the two were linked in my mind except for the fact that I was really messed up with the "right-left assignment" syndrome and this probably increased confusion regarding laziness :)))) Our brains is suppose to be like plasticine but as we grow older it gets a bit dryer :))) Luc On Mon, 2009-03-02 at 08:55 -0800, Bradbev wrote: > On Mar 2, 3:29 am, Mark Volkmann <r.mark.volkm...@gmail.com> wrote: > > On Sun, Mar 1, 2009 at 11:06 PM, max3000 <maxime.lar...@gmail.com> wrote: > > > > > Hi, > > > > > I find the laziness in clojure very hard to wrap my head around. I > > > understand the idea and it's probably nice in theory. However, in real > > > life it doesn't seem really useful beyond hardcore mathematical > > > problems. > > > > I felt the same way at first. I think it would help if the group > > shared some common, non-mathematical cases, where laziness is helpful. > > > > I'll share this one which is described near the end of the section on > > "Input/Output" athttp://www.ociweb.com/mark/clojure/article.html#IO. > > > > The line-seq function takes a java.io.BufferedReader and returns a > > lazy sequence of all the lines of text in it. The significance of > > returning a lazy sequence is that it doesn't really read all of the > > lines when it is called. That could consume too much memory. Instead > > it reads a line each time one is requested from the lazy sequence. > > > > Another way to think about this is that it allows writing functions > > that return all the data a caller might want without having to know > > ahead of time how much each caller might want. It may be the case that > > a caller just wants the first piece of data or three pieces or all of > > them. As the writer of the function that returns the data, you don't > > have to care about that. > > > > -- > > R. Mark Volkmann > > Object Computing, Inc. > > I also struggled (still struggle) with laziness. My main objection > was that lazy/non-lazy sequences is not a hidden abstraction - ie you > really need to know if what you are asking for is actually being > produced. I am slowly changing my mind. I now consider every seq > operation to be lazy, which means I only need to think about the cases > where I map for side effects. > I really like the above suggestion that the compiler warn about lazy > computation that is thrown away. > > Another very subtle (at least I think so) point about lazyness is that > you need to be VERY careful about using refs in a lazy seq. Because > the work for creating a seq is deferred, the dereference will happen > later than what you possibly expect. I'd also like to see a warning > in the compiler that says "Don't use refs inside lazy seqs" > > Cheers, > Brad > > > -- Luc Préfontaine Off.:(514) 993-0320 Fax.:(514) 993-0325 Armageddon was yesterday, today we have a real problem... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
