Programming language Study Guide

📖 Core Concepts Programming language: A formal notation for writing computer programs; consists of syntax (form) and semantics (meaning). Syntax: Rules that define which symbol sequences are well‑formed programs (often described with regular expressions, BNF, context‑free grammars). Semantics: The behavior attached to syntactically correct constructs; split into static semantics (compile‑time checks) and dynamic semantics (run‑time execution). Type system: Classifies values/expressions into types and enforces rules; can be static vs dynamic and strong vs weak. Turing completeness: Ability to simulate a universal Turing machine; any language that can implement any algorithm (given unlimited resources) is Turing‑complete. Paradigm: A high‑level style of programming (imperative, declarative, procedural, object‑oriented, functional, logic, etc.). Compilation vs Interpretation: Compilation translates source → machine/byte code before execution; interpretation executes source (or bytecode) directly at run time. Just‑In‑Time (JIT) compilation: Runtime translation of bytecode to native code, blending interpretation speed with compiled performance. --- 📌 Must Remember Static vs Dynamic typing – static: types known at compile time; dynamic: types resolved at run time. Strong vs Weak typing – strong: disallows implicit mismatched‑type operations; weak: permits implicit conversions (can hide bugs). Typed vs Untyped – typed languages declare permissible types; untyped languages place no such restrictions. Language classification axes – paradigm, intended domain, purpose (general‑purpose, system, scripting, DSL, concurrent). Grammar level – most languages are type‑2 (context‑free) grammars in the Chomsky hierarchy. Compilation → faster execution; Interpretation → higher portability & rapid development. JIT improves interpreted language performance by compiling hot code paths on the fly. Turing‑complete ≠ “good for every task” – still need appropriate abstractions, libraries, and performance characteristics. --- 🔄 Key Processes Lexical analysis Input source → stream of tokens (identifiers, literals, operators) using regular expressions. Parsing Tokens → parse tree according to BNF/CFG rules (context‑free grammar). Static semantic checking Enforce declaration before use, type consistency, unique case labels, etc. Code generation (for compilers) Transform parse tree into intermediate representation, then to machine/bytecode. Execution (interpreter) Walk AST or bytecode, applying dynamic semantics (expression evaluation, control flow, side‑effects). JIT compilation (optional) Detect hot bytecode regions → compile to native code → replace interpreted execution. --- 🔍 Key Comparisons Static typing vs Dynamic typing Static: errors caught early, enables optimizations, requires explicit or inferred declarations. Dynamic: flexible, faster prototyping, runtime type errors possible. Strong typing vs Weak typing Strong: no implicit coercion; e.g., adding int to string raises error. Weak: implicit conversions allowed; e.g., "5" + 3 → 8 (or "53"). Compilation vs Interpretation Compilation: produces standalone executable, usually faster, less portable. Interpretation: runs source/bytecode directly, easier debugging, more portable. Procedural vs Object‑Oriented vs Functional vs Logic paradigms Procedural: sequence of statements, functions for reuse. OO: objects with encapsulated state/behavior, inheritance, polymorphism. Functional: pure functions, immutable data, higher‑order functions. Logic: declarative facts/rules, inference engine derives conclusions. --- ⚠️ Common Misunderstandings “All high‑level languages are interpreted.” – Many (e.g., Java, C#) compile to bytecode then run on a VM; others are ahead‑of‑time compiled. “Strong typing means no type errors ever occur.” – Strong typing prevents certain implicit conversions; explicit mismatches still raise errors. “Turing completeness guarantees a language is suitable for any project.” – Practical concerns (libraries, tooling, performance) matter more than theoretical completeness. “Static semantics is the same as static typing.” – Static semantics includes many compile‑time rules beyond types (e.g., name resolution, label uniqueness). --- 🧠 Mental Models / Intuition Syntax = Grammar; Semantics = Meaning – Think of a sentence: grammar tells you it’s well‑formed; semantics tells you what it means. Type system as a safety net – Static types are pre‑flight checks; dynamic types are run‑time guards. Compilation as cooking, Interpretation as dining – Compile once, serve many (fast); interpret fresh each time (flexible). Paradigm as a lens – Choose the lens that makes the problem simplest: procedural for step‑by‑step, OO for entities with state, functional for transformations, logic for rule‑based inference. --- 🚩 Exceptions & Edge Cases Untyped languages – Rare today; most “untyped” languages still have some runtime type information (e.g., assembly). Weak typing pitfalls – Implicit conversions can produce surprising results (e.g., 0 == false in JavaScript). Hybrid languages – Modern languages often support multiple paradigms; e.g., Python is imperative, OO, and functional. JIT warm‑up – Performance may be slower on first runs until hot code is compiled. --- 📍 When to Use Which Static typing → large codebases, performance‑critical systems, early error detection. Dynamic typing → rapid prototyping, scripting, domains with highly variable data structures. Strong typing → safety‑critical applications where implicit conversion bugs are unacceptable. Weak typing → quick scripts where convenience outweighs strict correctness. Compiled language → system programming, high‑performance compute‑intensive tasks. Interpreted / scripting language → automation, glue code, web‑side scripting, exploratory data analysis. Functional style → problems emphasizing transformations, concurrency without mutable state. Object‑oriented style → modeling real‑world entities, large modular systems. --- 👀 Patterns to Recognize “Declaration before use” → static semantic rule; missing declaration signals compile error. “Immutable data flow” → hallmark of functional code (no assignments, use of map, reduce). “Inheritance hierarchy” → OO pattern; look for class Subclass extends Superclass. “Rule + query” → logic programming pattern (facts + goals). “Mixed paradigm code” → modern languages may intermix OO and functional constructs; recognize lambda expressions inside classes. --- 🗂️ Exam Traps Confusing static vs dynamic semantics – A question may ask about run‑time behavior; answer must refer to dynamic semantics, not compile‑time checks. Choosing “interpreted” because the language is “scripting” – Some scripting languages compile to bytecode first (e.g., Python). Assuming “weak typing” equals “no type checking” – Weakly typed languages still perform type checks, just allow implicit conversions. Mixing up “typed” vs “strongly typed” – A language can be statically typed yet weak (e.g., C). Turing completeness vs practical expressiveness – An exam may ask which languages can express any algorithm (Turing‑complete) vs which are well‑suited for a task. ---