Polyglot Programming & Paradigm Shifting

Languages are ephemeral; paradigms are foundational. Learn only syntax and every new language is a fresh start; learn how memory, execution flow and state change are managed across paradigms and you can pick up a new language in a weekend — because you will recognise it as a new accent, not a new tongue.

The Meta-Skill of Language Translation

When you meet an unfamiliar language, interrogate it with the same six questions and map the answers onto what you already know:

Question	What you're mapping	Example spread
Where do values live, and who frees them?	Memory model	GC heap (Java/Ruby) ↔ ownership (Rust) ↔ manual (C)
When is a name visible, and when does its value die?	Scope & lifetime	Lexical closures ↔ block scope ↔ dynamic scope
When are types checked, and how strong is the promise?	Type discipline	Static/nominal (Java) ↔ static/structural (Go, TS) ↔ dynamic/duck (Ruby, Python)
How does one piece of behaviour substitute for another?	Polymorphism	Subtyping ↔ interfaces/protocols ↔ higher-order functions ↔ generics
What changes, and who is allowed to change it?	State model	Mutable objects ↔ immutable values ↔ monadic effects
Who decides what runs next?	Control flow	Call stack ↔ event loop ↔ solver/backtracking

The Paradigm Landscape

Imperative & procedural. Step-by-step state manipulation through explicit instructions grouped into routines. The focus is how: sequence, selection, iteration. Every mainstream language contains this core, which is why it is taught first — and why its habits (shared mutable state everywhere) are what the other paradigms exist to discipline.
Object-oriented. Encapsulating state and behaviour into cohesive objects that communicate — as the rest of this track explores — by message passing, with polymorphism and interface contracts enforcing structural invariants. The deep idea is less "classes" than protected state behind a behavioural boundary (see Event-Driven Programming for messaging taken to its logical conclusion).
Functional. Computation as evaluation of pure functions; mutable state and side effects pushed to the edges. Higher-order functions are first-class citizens: functions consume and return functions. You already use this paradigm every time you write a map/filter chain, a Ruby block, or a Java stream — the paradigm arrived inside the OO languages while nobody was watching.
Event-driven. Control flow inverted: the system idles until a message arrives — a click, a packet, a domain event — and routes it to a handler. Covered in depth on Event-Driven Programming, including what the inversion costs in traceability.
Goal-oriented & logic programming. Declare what — facts, rules, constraints, goals — and let an execution engine (a backtracking resolution solver in Prolog; a planner in GOAP) derive the how. The mental shift is the largest of all: you stop writing the search and start writing the search space.

One Problem, Five Accents

"Total the prices of in-stock items" — watch the state and control flow move between paradigms:

# Imperative: explicit accumulation, mutable loop state
total = 0
for item in items:
    if item.in_stock:
        total += item.price

# Object-oriented: the collection owns the behaviour
total = basket.total_in_stock()   # state hidden behind the message

# Functional: expression over immutable data, no assignment
total = sum(i.price for i in items if i.in_stock)

# Event-driven: totals maintained by reacting to facts
bus.subscribe("item.stocked",   lambda e: ledger.add(e.price))
bus.subscribe("item.sold_out",  lambda e: ledger.remove(e.price))

% Logic: declare the relation; the engine finds the total
in_stock_price(P) :- item(I), in_stock(I), price(I, P).
total(T) :- findall(P, in_stock_price(P), Ps), sum_list(Ps, T).

Choosing (and Composing) the Tool

Real architectures rarely stay inside one paradigm; they compose them. A typical modern service is an object-oriented shell (modules, dependency boundaries, SOLID discipline) around functional stream processing (pure transformations over immutable events), driven by an event loop, with a declarative configuration layer on top. The skill is not picking a winner — it is noticing which paradigm's guarantees each layer of the problem needs: auditability wants immutable events; complex domain invariants want encapsulating objects; concurrency wants purity; interaction wants events.

The practical advice: learn one language from an unfamiliar paradigm properly — far enough to feel its idioms stop being weird. Each paradigm permanently adds a lens, and code in your home language improves because you now see which of its features are borrowed lenses too.