Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Will I develop good/bad habits because of lazy evaluation?

I'm looking to learn functional programming with either Haskell or F#.

Are there any programming habits (good or bad) that could form as a result Haskell's lazy evaluation? I like the idea of Haskell's functional programming purity for the purposes of understanding functional programming. I'm just a bit worried about two things:

  1. I may misinterpret lazy-evaluation-based features as being part of the "functional paradigm".
  2. I may develop thought patterns that work in a lazy world but not in a normal order/eager evaluation world.
like image 604
MikeRand Avatar asked Sep 23 '10 16:09

MikeRand


People also ask

Is lazy evaluation bad?

Always using lazy evaluation also implies early optimization. This is a bad practice which often results in code which is much more complex and expensive that might otherwise be the case. Unfortunately, premature optimization often results in code that performs slower than simpler code.

What are some potential disadvantages of lazy evaluation?

Lazy Evaluation − Drawbacks It forces the language runtime to hold the evaluation of sub-expressions until it is required in the final result by creating thunks (delayed objects). Sometimes it increases space complexity of an algorithm.

Why lazy evaluation is good?

The benefits of lazy evaluation include: The ability to define control flow (structures) as abstractions instead of primitives. The ability to define potentially infinite data structures. This allows for more straightforward implementation of some algorithms.

Is lazy evaluation strict or non strict?

Lazy evaluation is a form of non-strict evaluation in which arguments are not evaluated until required. A computation that does not terminate under strict evaluation, can terminate under lazy evaluation.


1 Answers

Recently, i found myself doing Haskell-style programming in Python. I took over a monolithic function that extracted/computed/generated values and put them in a file sink, in one step.

I thought this was bad for understanding, reuse and testing. My plan was to separate value generation and value processing. In Haskell i would have generated a (lazy) list of those computed values in a pure function and would have done the post-processing in another (side-effect bearing) function.

Knowing that non-lazy lists in Python can be expensive, if they tend to get big, i thought about the next close Python solution. To me that was to use a generator for the value generation step.

The Python code got much better thanks to my lazy (pun intended) mindset.

like image 106
LennyStackOverflow Avatar answered Oct 05 '22 23:10

LennyStackOverflow