Haskell vs Imperative Languages

Analogy categoryAnalogies

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.

haskell

-- 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.