From Commands to Expressions
Imperative languages such as C, Java, and Python describe programs as sequences of commands that mutate variables and program state step by step: assign x, increment y, print z. Haskell instead describes programs as expressions that evaluate to values, with functions defined by equations rather than procedures. A Haskell program is closer to a mathematical definition, like f(x) = x*x + 1, than to a recipe of instructions, and this shift from 'how to do it' to 'what it is' changes how you design, debug, and reason about code.
Cricket analogy: Scoring a Test match imperatively is like a scorer updating a running tally after every ball, team total, wickets, overs bowled, each command mutating the same scoresheet; Haskell instead treats the final score as a pure function of the ball-by-ball data, recomputed rather than incrementally patched, the way Cricinfo's win-probability model recalculates fresh from current state instead of nudging a stored number.
Mutable State vs Immutability
In Java or Python, a variable like total can be reassigned repeatedly inside a loop, and the same memory location holds different values over time. In Haskell, a binding such as total = sum xs never changes once defined, there is no assignment statement, only naming. Where imperative code models a running computation as an evolving value stored in place, Haskell models it as a chain of new immutable values, for example an updated list is a new list sharing structure with the old one via persistent data structures, not a patched array.
Cricket analogy: A scoreboard operator in an imperative system erases and rewrites the same total after every run scored, like a manual scoreboard at a village cricket ground; Haskell instead is like Hawk-Eye's ball-tracking data, where each delivery produces a new immutable record appended to history, and no earlier ball's data is ever overwritten.
Loops vs Recursion and Higher-Order Functions
Imperative languages express iteration with for and while loops that mutate a counter and accumulator on each pass. Haskell has no loop constructs; iteration is expressed through recursion and higher-order functions like map, filter, and foldr. Where a Java for-loop explicitly manages an index variable, map (*2) [1,2,3] describes the transformation declaratively, and the recursive definition of a function like factorial n = if n == 0 then 1 else n * factorial (n-1) replaces the mutable loop counter with a base case and a recursive call.
Cricket analogy: A net-practice imperative routine says bowl 6 balls, increment ball count, repeat until 60; Haskell's map is more like a coach saying apply this correction to every delivery in today's session at once, the way Virat Kohli's throwdown specialist adjusts stance cues for the whole set of balls as one declarative instruction rather than counting iterations.
Eager Evaluation vs Laziness
Most imperative languages use eager (strict) evaluation: an expression like f(g(x)) computes g(x) fully before calling f. Haskell is lazy by default, g x is not evaluated until its result is actually needed, which lets you write infinite structures like fibs = 0 : 1 : zipWith (+) fibs (tail fibs) and take only the first 10 elements with take 10 fibs safely. This changes how you reason about performance, space leaks from unevaluated thunks are a real risk, and enables idioms, like separating generation from consumption, that eager languages can't express as directly.
Cricket analogy: An imperative broadcaster eagerly renders every ball's replay before the next delivery, using bandwidth regardless of viewer interest; Haskell's laziness is like an on-demand streaming service such as Hotstar generating a ball's highlight clip only when a viewer actually clicks to watch it, saving processing until the value is truly needed.
-- Imperative style (pseudocode, e.g. Python)
-- total = 0
-- for x in [1..10]:
-- if x % 2 == 0:
-- total += x * x
-- print(total)
-- Haskell: declarative, expression-based equivalent
sumOfSquaresOfEvens :: [Int] -> Int
sumOfSquaresOfEvens xs = sum [x * x | x <- xs, even x]
-- Or using higher-order functions instead of a loop
sumOfSquaresOfEvens' :: [Int] -> Int
sumOfSquaresOfEvens' = sum . map (^2) . filter even
main :: IO ()
main = print (sumOfSquaresOfEvens [1..10]) -- 220
Don't assume laziness makes Haskell strictly faster or automatically avoids overhead. Unevaluated thunks can pile up and cause space leaks if you fold over a large list with a lazy accumulator like foldl (+) 0. Prefer foldl' from Data.List (strict left fold) when accumulating over large lists to avoid building a long chain of unevaluated additions.
- Imperative languages (C, Java, Python) model programs as sequences of state-mutating commands; Haskell models programs as evaluated expressions.
- Haskell bindings are immutable, there is no assignment statement, only naming a value once.
- Iteration in Haskell is expressed via recursion and higher-order functions (map, filter, foldr) instead of for/while loops.
- Haskell is lazy by default, evaluating expressions only when their results are needed, enabling infinite data structures.
- Laziness introduces its own risks, such as space leaks from unevaluated thunks, requiring strict alternatives like foldl' in performance-sensitive code.
- Pure functions with no side effects make Haskell code easier to reason about and test in isolation compared to typical imperative code.
- Choosing Haskell over an imperative language is a paradigm shift, not just a syntax change, it affects how you decompose problems from the start.
Practice what you learned
1. What is the primary difference between how Haskell and an imperative language like Java handle a variable binding?
2. Which construct does Haskell use in place of imperative for/while loops?
3. What does it mean that Haskell is lazily evaluated by default?
4. What is a 'space leak' in the context of lazy evaluation?
5. Why can Haskell define fibs = 0 : 1 : zipWith (+) fibs (tail fibs) as an infinite list safely?
Was this page helpful?
You May Also Like
Haskell Best Practices
Practical conventions and idioms for writing clean, maintainable, idiomatic Haskell code, from naming and type signatures to error handling and module design.
Haskell Quick Reference
A condensed reference covering core Haskell syntax, common types, standard library functions, and idioms for quick lookup while coding.
Haskell Interview Questions
Common Haskell interview topics and questions, from type-class fundamentals to monads and lazy evaluation, with explanations you can use to prepare.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics