Introduction to Programming - Types of Languages, Memory Management


π§ 1. Procedural Programming
π Definition:
A programming paradigm based on procedures (or routines/functions). Itβs like following a step-by-step recipe.
π Key Features:
Top-down execution
Global state
Functions act on data
Code is structured into procedures, not objects
β Examples:
- C, Pascal, Bash, Early versions of Python, JavaScript
π§ͺ Code Example (JS-style procedural):
let total = 0;
function addToCart(price) {
total += price;
}
addToCart(100);
addToCart(50);
console.log(total); // 150
β οΈ Downsides:
Global state is risky
Harder to scale
Code reuse is limited
π§ 2. Object-Oriented Programming (OOP)
π Definition:
A paradigm where everything revolves around objects β bundles of data (properties) and behaviors (methods).
π Key Features:
Classes and Objects
Encapsulation (hide internal state)
Inheritance
Polymorphism
Mutability
β Examples:
- Java, C++, Python (OOP style), TypeScript
π§ͺ Code Example:
class Cart {
constructor() {
this.total = 0;
}
add(price) {
this.total += price;
}
getTotal() {
return this.total;
}
}
const cart = new Cart();
cart.add(100);
cart.add(50);
console.log(cart.getTotal()); // 150
β Benefits:
Modular code
Easier to manage complex systems
Reusability via inheritance
β οΈ Downsides:
Can become bloated
Inheritance abuse
Mutability can lead to bugs
π§ 3. Functional Programming (FP)
π Definition:
A paradigm where functions are first-class citizens. Everything is treated as pure functions and immutable data.
π Key Features:
Pure functions (no side effects)
Immutability
Higher-order functions
Declarative style
Composability
β Examples:
- Haskell, Elixir, Clojure, JS (FP style)
π§ͺ Code Example (Same cart):
const addToCart = (cartTotal, price) => cartTotal + price;
const total1 = addToCart(0, 100);
const total2 = addToCart(total1, 50);
console.log(total2); // 150
β Benefits:
Highly testable
Easy to debug
Parallelism-friendly (no shared state)
Reusable, composable functions
β οΈ Downsides:
Verbose or less intuitive at first
Can be harder to write stateful apps
π Comparison Table
Feature | Procedural | OOP | Functional |
Basic unit | Procedure / Function | Object / Class | Function |
State | Global or local vars | Encapsulated in objects | Avoided, immutable |
Reuse | Function reuse | Inheritance, composition | Function composition |
Style | Step-by-step (how) | Object interactions | Declarative (what to do) |
Side Effects | Common | Common | Avoided |
Data Mutability | Often mutable | Often mutable | Immutable |
Real Example | C | Java, C++, TS classes | Haskell, Elixir, FP-style JS |
Testing | Moderate | Sometimes harder (mocking) | Easy (pure functions) |
π Summary
Procedural β Good for simple tasks, scripting, linear logic
OOP β Best for large apps, user-based systems (e.g., ecommerce, games)
Functional β Great for data processing, predictable logic, concurrency (e.g., search engines, real-time data)
π· Static Typed Languages
π Definition:
In statically typed languages, the type of a variable is known at compile-time. You have to define or infer the type before running the program.
π§ Key Features:
Type checking happens before code runs
Errors are caught early
Requires you to declare or infer types
β Examples:
TypeScript, Java, C, C++, Rust, Go, Kotlin
π Example:
let age: number = 25;
age = "twenty"; // β Type error during compilation
β Pros:
Fewer bugs at runtime
Better auto-completion (intellisense)
Safer refactoring
IDE support is π₯
β οΈ Cons:
More boilerplate
Slower for quick scripts
πΆ Dynamic Typed Languages
π Definition:
In dynamically typed languages, types are determined at runtime. You donβt declare types; theyβre inferred when the code runs.
π§ Key Features:
Type checking happens during execution
More flexible
Variables can change type
β Examples:
JavaScript, Python, Ruby, PHP, Lua
π Example:
let age = 25;
age = "twenty"; // β
No error β works at runtime (might cause bugs)
β Pros:
Less code to write (faster to prototype)
Great for small scripts or quick tasks
Very flexible
β οΈ Cons:
Bugs can occur at runtime
Harder to maintain large codebases
Type-related bugs go unnoticed till crash
π Summary Table
Feature | Static Typing | Dynamic Typing |
Type Checking | Compile-time | Runtime |
Type Declaration | Required or inferred | Not required |
Error Detection | Early (before running) | Late (during execution) |
Speed of Dev | Slower setup, safer long-term | Fast prototyping, less safety |
Flexibility | Less flexible | More flexible |
Ideal For | Large apps, critical systems | Small apps, quick scripts |
Memory management
stack and heap memory
β Stack vs Heap
π· Stack (Thread Stack)
Stores method calls, local variables, and reference pointers
Memory is automatically managed
Each thread has its own stack
Faster but smaller
β Example:
void greet() {
int x = 10; // x stored in stack
String name = "Abhee"; // reference in stack, actual string in heap
}
When greet()
finishes β local vars are removed from stack
πΆ Heap
Stores objects, arrays, class instances
Shared across all threads
Cleaned up by Javaβs Garbage Collector (GC)
Larger but slower access
π How Java Manages Memory
Area | Used For | Managed By |
Stack | Method calls, primitives, refs | Automatically (per thread) |
Heap | Objects, instance vars, arrays | Garbage Collector (GC) |
β»οΈ Garbage Collector (In Java)
Frees heap memory for unreachable objects
Automatically runs in background
No manual
free()
like in C/C++
π₯ TL;DR
π Stack = Per-thread, fast, for temporary stuff (primitives, refs)
π§Ί Heap = Shared, for objects, slow but flexible, GC-managedThanks to kunalkushwaha for great video!
Subscribe to my newsletter
Read articles from Abheeshta P directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by

Abheeshta P
Abheeshta P
I am a Full-stack dev turning ideas into sleek, functional experiences π. I am passionate about AI, intuitive UI/UX, and crafting user-friendly platforms . I am always curious β from building websites to diving into machine learning and under the hood workings β¨. Next.js, Node.js, MongoDB, and Tailwind are my daily tools. I am here to share dev experiments, lessons learned, and the occasional late-night code breakthroughs. Always evolving, always building.