From Hero of Alexandria’s automata to Turing’s universal machine — the thinkers who asked what it means to compute, and built the tools to find out.
The Computing Department is the Universitas Scholarium’s faculty of the discipline that turned calculation into a universal medium — the study of what can be computed, how, and at what cost. Its scope runs from the first programmable machines to the compilers, networks, and learning systems of the present day. The faculty trace computing’s long emergence from mechanism into mathematics into engineering. Its ancient mechanists — Hero of Alexandria, whose weight-driven automata ran the earliest known programs, and Robert Hooke, who built instruments to extend the senses — gave way to the visionaries of calculation: Ada Lovelace, who saw that Babbage’s engine could manipulate symbols and not merely numbers, and Alan Turing, whose universal machine defined computation itself. The cyberneticists — Norbert Wiener, Warren Weaver, and Claude Shannon, who made information a measurable quantity — joined the discipline’s theory to its machines. Its software pioneers — Grace Hopper, who wrote the first compiler, John Backus of FORTRAN, Edsger Dijkstra, who made programming a rigorous science, and Donald Knuth, who made its analysis an art — built the practice; while Seymour Cray raised the machines to supercomputing scale and Steve Jobs carried them to the desk and the hand. Each is an AI simulacrum that reasons in its progenitor’s computational idiom.
Python
Python Language Design · The Zen of Python · BDFL · Readability · Executable Pseudocode
Based on the published writings of Guido van Rossum. The creator of Python, which he designed to read like executable pseudocode. As “Benevolent Dictator For Life” he guided Python from a scripting language to the dominant language of data science, machine learning, web development and education. His design philosophy — codified in PEP 20, the Zen of Python — prioritises readability, simplicity and explicitness. “There should be one — and preferably only one — obvious way to do it.”
Can help you with: Python language design philosophy, writing readable and Pythonic code, understanding why Python works the way it does, the Zen of Python as a design guide, PEPs and the evolution of Python, and thinking about language design as a discipline of clarity.
→ Converse with Guido van Rossum
Idiomatic Python · Transformations · Core Developer · PyCon · There Must Be a Better Way
Based on the published writings of Raymond Hettinger. A Python core developer renowned for his PyCon talks that transform verbose, un-Pythonic code into elegant, idiomatic Python. His catchphrase “There must be a better way” captures his teaching method: show the clumsy version, then reveal the transformation. His contributions to the standard library include collections, itertools extensions, and functools improvements. He teaches Python as a language of transformations rather than a language of instructions.
Can help you with: Writing idiomatic Python, transforming verbose code into clean code, understanding Python’s standard library in depth (collections, itertools, functools), decorators, generators, list comprehensions, the Python data model, and learning to see code as a series of transformations.
→ Converse with Raymond Hettinger
Think Python · Computational Thinking · Pedagogy · Data Science · Bayesian Statistics
Based on the published writings of Allen Downey. The author of Think Python, Think Stats, Think Bayes and Think Complexity — a series of textbooks that teach programming as a way of thinking rather than a set of syntax rules to memorise. His pedagogical method starts with concepts (variables are labels, functions are abstractions, loops are repetitions) and introduces syntax only as needed to express them. He believes programming should be taught the way mathematics should be taught: through problems, not through formalism.
Can help you with: Learning Python from scratch, computational thinking as a discipline, data science and statistics with Python, Bayesian reasoning, structuring programs around concepts rather than syntax, and understanding why programming is a way of thinking about problems.
→ Converse with Allen Downey
Fluent Python · Pythonic Idiom · Data Model · Iterators · Descriptors · Metaprogramming
A simulacrum abstracted from the published work of Luciano Ramalho, who is living and has had no part in it. Its subject is not Python's syntax but its DATA MODEL — the special methods that make an object behave like a sequence, a number, a context manager or a callable. ⭑ Writing Python fluently means implementing the protocols the language already understands rather than inventing parallel machinery.
Can help you study: The data model as the key to the language: what `__len__`, `__iter__`, `__enter__` and their kin actually buy. Why an object that implements the right protocol works with every construct that expects it. Iterators, generators and the difference between them. And the general habit of asking, of any Python design, whether the language already has a protocol for it.
→ Converse with Ramalhoan Fluent Python Simulacrum
Python Cookbook · Advanced Python · Generators · Metaprogramming · The Machinery Underneath
Based on the published writings of David Beazley. The author of the Python Cookbook and Python Essential Reference, and creator of PLY (Python Lex-Yacc) and Curio. Beazley teaches advanced Python with a unique internalist method: he shows you not what Python does, but how it does it — the descriptor protocol, the import system, the GIL, metaclasses, generator pipelines, async internals. His PyCon tutorials on generators and coroutines are legendary. He believes that understanding the machinery underneath makes the surface vastly more powerful.
Can help you with: Advanced Python: generators, coroutines, decorators, metaclasses, descriptors, the import system, the GIL, async/await internals, parser construction, and the deep Python that sits beneath the surface syntax. For when you want to understand what actually happens when Python executes your code.
→ Converse with David Beazley
Fortran
Fortran · Formula Translation · BNF · Turing Award 1977 · Functional Programming
Led the IBM team that created Fortran (1954–1957) — the first successful high-level programming language and the system that proved compilers could produce code competitive with hand-written assembly. Fortran made scientific computing accessible to mathematicians and engineers who were not programmers. He also invented BNF (Backus–Naur Form), the standard notation for describing programming language syntax. His 1977 Turing Award lecture, “Can Programming Be Liberated from the von Neumann Style?”, proposed functional programming as an alternative to the imperative style his own language had established.
Can help you with: Learning Fortran from first principles, understanding why Fortran is designed the way it is (formula translation as the core idea), scientific and numerical programming, the structure of Fortran programs (modules, subroutines, derived types), compiler behaviour, and the history of programming languages from someone who started it all.
→ Converse with John Backus
Modern Fortran Explained · Fortran Standards Committee · Fortran 90/95/2003/2008/2018 · CERN
Based on the published writings of Michael Metcalf. Co-author of Modern Fortran Explained, the definitive reference for the modern language. A member of the Fortran standards committee for more than thirty years, and a former CERN staff member who helped bring Fortran from its fixed-format origins into the modern era of modules, allocatable arrays, object-oriented features and parallel coarrays.
Can help you with: Modern Fortran (2003/2008/2018) features, migrating from Fortran 77 to modern style, modules and derived types, allocatable arrays, coarrays for parallel programming, Fortran standards and best practices.
→ Converse with Michael Metcalf
IEEE 754 · Floating-Point Arithmetic · Numerical Stability · The Perils of Floating-Point
Based on the published writings of William Kahan. The “father of floating-point,” whose work on the IEEE 754 standard ensured that every computer in the world performs floating-point arithmetic the same way. Turing Award 1989. His career has been devoted to understanding and taming the errors that arise when infinite mathematics meets finite representation — and to ensuring that programmers know where their precision goes.
Can help you with: Floating-point arithmetic and its pitfalls, numerical stability, why 0.1 + 0.2 does not equal 0.3, IEEE 754, precision analysis, avoiding catastrophic cancellation, and writing numerical code that gives correct answers.
→ Converse with William Kahan
MATLAB · LINPACK · Numerical Linear Algebra · Matrix Computation
Based on the published writings of Cleve Moler. Created MATLAB so his students could use the Fortran numerical libraries LINPACK and EISPACK without learning Fortran. Co-author of LINPACK. The matrix operations that underpin NumPy, PyTorch and every scientific computing framework trace back through MATLAB to the Fortran code Moler and his colleagues wrote. He bridges the gap between Fortran’s numerical power and accessible computation.
Can help you with: Numerical linear algebra, matrix computation, LINPACK and LAPACK, the Fortran-to-MATLAB connection, understanding what NumPy operations actually compute, and why matrix decompositions matter.
→ Converse with Cleve Moler
Supercomputer Architecture · Vector Processing · Cray-1 · HPC · The Speed of Light as Design Constraint
Designed the fastest computers in the world for three decades. The Cray-1 (1976) was the first supercomputer to make vector processing practical — the hardware architecture that Fortran array operations map directly onto. His design philosophy was radical simplicity: make the machine small (to minimise the speed-of-light delay between components), eliminate everything unnecessary, and let the computation be fast. His machines ran Fortran because Fortran was the language of the problems worth solving.
Can help you with: High-performance computing architecture, vector processing and why it matters for Fortran, supercomputer design philosophy, the relationship between hardware and numerical software, and thinking about performance from first principles.
→ Converse with Seymour Cray
Language Pioneers
The first generation of programming language designers — from COBOL to C.
Compilers · COBOL · FLOW-MATIC · Bug · Naval Computing
Hopper invented the compiler — the program that translates human-readable code into machine instructions — and in doing so made programming accessible to people who were not mathematicians. Her FLOW-MATIC language, designed for business data processing, became the foundation of COBOL, the language that still runs more financial transactions globally than any other. She famously taped the first actual computer bug (a moth) into her logbook. She served in the US Navy until she was eighty-three, rising to Rear Admiral, and continued programming until shortly before her death.
Can help you with: The history of compilers and what they do, the origins of high-level programming languages, COBOL and its enduring importance in finance, the relationship between mathematical and practical computing, and the history of women in computing.
→ Converse with Grace Hopper
Lisp · Artificial Intelligence · Garbage Collection · Time-Sharing · Recursive Functions
⭑ In most languages code and data are different things — code instructs, data is what gets processed. In Lisp they are the same thing, and that single decision is what makes a program able to write and transform programs. Everything else in the language follows from taking that seriously, and so does most of the field's subsequent thinking about metaprogramming.
Can help you study: Homoiconicity worked through until it is obvious rather than mystical: why a list of symbols is both an expression and a data structure. The evaluator written in the language it evaluates, which is the shortest route to understanding what evaluation IS. Garbage collection as a consequence of the design rather than an addition to it. And the general habit of asking what a language forbids you to say.
→ Converse with John McCarthy Simulacrum
C · Unix · Systems Programming · Bell Labs · The Language That Built the World
⭑ C is neither a high-level language nor a low-level one — it is a PORTABLE ASSEMBLY LANGUAGE. It gives you the machine's model of memory, arithmetic and control, and then lets that model be recompiled somewhere else. The whole design is that trade: near-total access to the hardware, in a form that does not have to be rewritten when the hardware changes.
Can help you study: The memory model that everything else assumes — pointers, arrays and the identity between them, and why that identity causes both the power and the vulnerabilities. Undefined behaviour as a deliberate design choice rather than an oversight, and what the compiler is permitted to do with it. Why portability was the radical claim in 1972. And reading C as the substrate that most later languages are defined against.
→ Converse with Dennis Ritchie Simulacrum
Pascal · Modula · Oberon · Structured Programming · Software Engineering as Discipline
⭑ Software is getting slower more rapidly than hardware becomes faster — Wirth's Law, and the inverse of the one everybody quotes. His languages are the argument in practice: Pascal, Modula-2 and Oberon each smaller than the last, each removing something rather than adding, on the conviction that a language a compiler can hold and a person can learn is worth more than a language that can express everything.
Can help you study: Designing by removal, and the discipline of asking what a feature would cost every future reader. Structured programming as it was actually argued for, against the practice it replaced. Why a single-pass compiler is a constraint that improves a language. ⚠ And the standing question his career poses: whether the simplicity he insisted on was affordable, given that the languages that won were the ones that grew.
→ Converse with Niklaus Wirth Simulacrum
Smalltalk · Objects All the Way Down · The Dynabook · Personal Computing · GUI · OOP Origins
A simulacrum abstracted from the published work of Alan Kay, who is living and has had no part in it. ⭑ *I made up the term object-oriented and most people got it wrong.* OOP is not about classes and it is not about inheritance — it is about MESSAGING: independent processes that communicate only by sending messages, hiding their state absolutely, and deciding for themselves what to do on receipt.
Can help you study: Messaging as the primary idea, and how far the mainstream reading of OOP departs from it. Late binding and why deferring a decision to runtime buys more than it costs. The Dynabook as a specification for what a personal computer was FOR, written before one existed. ⚠ And the critique he still presses: that the industry adopted the syntax of his idea and discarded its content.
→ Converse with Kayan Smalltalk Vision Simulacrum
Relational Model · SQL · Normal Forms · Data Independence · Set-Based Thinking
⭑ Data has a LOGICAL structure independent of how it is physically stored, and the logical structure is the RELATION. Everything that follows — normalisation, the relational algebra, the idea that a query says WHAT you want rather than how to fetch it — is a consequence of insisting on that separation against an industry that had built its systems on physical navigation.
Can help you study: The relational model from first principles, with the algebra worked rather than described. Normal forms as consequences of dependencies rather than rules to memorise. Why declarative querying became possible only once the logical layer was independent. And his twelve rules read as what they were — a polemic against products claiming to be relational while preserving the old physical coupling.
→ Converse with Edgar Codd Simulacrum
Ada · Safety-Critical Systems · Strong Typing · DoD-STD-1815 · Concurrency · Tasking
⭑ When software controls a missile, a reactor or an aircraft, the cost of a bug is not a crash dump. Ada was designed for that case: strong typing, explicit ranges, tasking in the language rather than the library, and a refusal of convenience wherever convenience could hide an error. ⚠ The result is verbose by design, and the verbosity is the point.
Can help you study: Designing a language for a domain where being wrong is catastrophic, and what that justifies. Strong typing with range constraints as a way of moving errors from runtime to compile time. Tasking and rendezvous as language features rather than library calls. ⚠ And the trade-off worth arguing about: whether the safety was worth the cost, given how few of Ada's ideas were adopted elsewhere until much later.
→ Converse with Jean Ichbiah Simulacrum
APL · A Notation as a Tool of Thought · Array Programming · Concision · Turing Award 1979
⭑ The notation we use to express a computation SHAPES the computations we can think — a poor notation makes some ideas inexpressible and others invisible. APL was built as a notation first and a language second, which is why it looks like nothing else: array operations as single symbols, so that a whole loop becomes one character and the shape of the algorithm becomes visible on the page.
Can help you study: Array thinking: reformulating an iterative algorithm as whole-array operations, and what becomes obvious once you do. Notation as a tool of thought, argued as a general claim about mathematics and not only about programming. Why terseness is a feature when the reader knows the notation and a disaster when they do not. And reading a dense APL expression by decomposing it right to left.
→ Converse with Kenneth Iverson Simulacrum
BASIC · Computing for Everyone · Dartmouth Time-Sharing · Accessibility · The Peoples Language
⭑ In 1964 computing was for priests — specialists in white coats feeding punch cards into million-pound machines. BASIC and the Dartmouth time-sharing system were built on the opposite premise: that every undergraduate, in any subject, should be able to sit at a terminal and get an answer back while still caring about the question.
Can help you study: Language design where the target user is a novice rather than a professional, and every decision that follows from it. Time-sharing as the enabling condition — why interactivity mattered more than the language did. ⚠ And the long argument about whether BASIC taught a generation to program or taught them habits that had to be unlearned, which is worth taking seriously in both directions.
→ Converse with Kemeny-Kurtz BASIC Democratisation Simulacrum
Logo · Constructionism · Turtle Graphics · Learning by Making · Mindstorms · Piaget Applied
⭑ Children do not learn by being TOLD; children learn by MAKING. The turtle is an object to think with — a creature on the floor or the screen whose movements a child can identify with bodily, so that geometry becomes something you instruct rather than something you are shown. ⭑ And a bug is not a failure but a description of what you actually thought.
Can help you study: Constructionism: knowledge built while building something shareable, and how it differs from constructivism. Body-syntonic reasoning — why 'walk it yourself' is the debugging instruction that works. Debugging as the pedagogically valuable moment rather than the frustrating one. ⭑ And the critique of school embedded in the method, which is easy to lose when the method is adopted without it.
→ Converse with Seymour Papert Simulacrum
ML · Type Inference · Hindley-Milner · Pi-Calculus · LCF · Turing Award 1991
⭑ You should not have to WRITE the types — the compiler should INFER them. Given an expression, the type is determined by how it is used, and an algorithm can find the most general one. ML was built to demonstrate that, and the same career produced CCS and the pi-calculus, which do for concurrent processes what the lambda calculus did for functions.
Can help you study: Hindley–Milner inference: how the most general type is computed, and why polymorphism falls out rather than being added. Why a program that type-checks in ML has had a real class of errors eliminated rather than deferred. Process calculi as a way of reasoning about concurrency formally. And the LCF tradition, where the type system itself guarantees that only valid proofs can be constructed.
→ Converse with Robin Milner Simulacrum
Prolog · Logic Programming · Unification · Backtracking · Declarative Computing · Constraint Solving
⭑ In most languages you tell the computer HOW — step by step. In Prolog you state WHAT is true and let the machine search for what follows. A program is a set of facts and rules; running it is asking a question and letting unification and backtracking find the answers, which inverts the relationship between the programmer and the procedure.
Can help you study: Unification as the central mechanism — what it does that pattern matching does not. Backtracking search, and reading the execution of a Prolog program as a tree being walked. Why the declarative reading and the procedural reading of the same clause can diverge, and what the cut does about it. ⚠ And the honest limit: the declarative ideal is real, and the working programmer thinks about the search order anyway.
→ Converse with Alain Colmerauer Simulacrum
Forth · Stack Machines · Radical Simplicity · Extensible Language · Colorforth · Embedded Systems
⭑ Most languages give you a fixed set of features and you solve the problem within them. Forth gives you a STACK and the ability to define words, and you build the language up until the problem is expressible — at which point the program is one word. The system is small enough to be understood completely, which is treated as more valuable than being powerful.
Can help you study: Stack-based computation and postfix notation, until the parameter passing is invisible. Building a domain vocabulary upward so that the final program reads as the problem statement. Why an entire system a single person can hold in their head has properties no large system can have. ⚠ And the counter-case: what happens to Forth code when its author leaves.
→ Converse with Moorean Forth Radical Minimalism Simulacrum
Systems Languages
Languages for building operating systems, compilers, and infrastructure.
C++ · Zero-Overhead Abstraction · RAII · Templates · Multi-Paradigm · Systems Programming
A simulacrum abstracted from the published work of Bjarne Stroustrup, who is living and has had no part in it. ⭑ C++ is C with ABSTRACTIONS whose abstractions must cost NOTHING compared to hand-written C — the zero-overhead principle. You do not pay for what you do not use, and what you do use could not have been coded better by hand. Every design decision in the language is that constraint applied.
Can help you study: The zero-overhead principle used as a test: given a proposed feature, what would it cost a program that never touches it? RAII as the mechanism that makes deterministic resource management possible without a collector. Templates as compile-time computation rather than as generics. ⚠ And the complexity argument, which he answers rather than avoids: whether a language that never removes anything can stay usable.
→ Converse with Stroustrupian C++ Design Philosophy Simulacrum
Go · Concurrency · goroutines · Channels · Simplicity as Strength · Infrastructure at Scale
A simulacrum abstracted from the published work of Rob Pike, who is living and has had no part in it. ⭑ C++ grew into a monster — feature upon feature, templates upon templates, a manual of thousands of pages. Go is the reply: a language small enough to hold entirely, compiling in seconds, with concurrency built in and generics deliberately withheld for a decade because the cost of the feature was judged higher than the cost of doing without.
Can help you study: Designing by refusal, and how to evaluate an omission rather than an addition. Goroutines and channels: communicating sequential processes as a practical model rather than a theoretical one. Why compilation speed is a language design consideration and not merely a tooling one. ⚠ And the long argument over generics as a case study in whether a simplicity commitment can survive its users.
→ Converse with Pikean Go Simplicity Simulacrum
Rust · Ownership · Borrowing · Memory Safety Without Garbage Collection · Fearless Concurrency
A simulacrum abstracted from the published work of Graydon Hoare, who is living and has had no part in it. ⭑ C trusts the programmer with memory and the programmer makes mistakes — buffer overflows, use-after-free, decades of vulnerabilities traceable to one class of error. Rust's answer is ownership: the compiler tracks who owns each value and when it dies, so the entire class becomes unrepresentable rather than merely discouraged.
Can help you study: Ownership, borrowing and lifetimes worked through on real code until the borrow checker's complaints become predictable. Why memory safety without a garbage collector required moving the analysis to compile time. Fearless concurrency as a consequence: data races are the same error the ownership rules already forbid. ⚠ And the cost, which is real — a steep learning curve, and a language that argues with you.
→ Converse with Hoarean Rust Ownership Simulacrum
Zig · No Hidden Allocations · Comptime · Safety Without Garbage Collection · C Interop
A simulacrum abstracted from the published work of Andrew Kelley, who is living and has had no part in it. ⭑ C hides nothing but has undefined behaviour; Rust eliminates unsafety but adds complexity. Zig's claim is to hide nothing AND have no undefined behaviour — no hidden allocations, no hidden control flow, no operator overloading, and comptime as a single mechanism doing the work of macros, generics and conditional compilation.
Can help you study: Explicit allocation as a design principle: what changes when every allocation names its allocator. Comptime — compile-time execution of ordinary code — and why one mechanism replaces three. Reading a language for its hidden costs: allocations, exceptions, and control flow you did not write. And the practical claim worth testing: that Zig is a better C compiler than C.
→ Converse with Kelleyan Zig No-Hidden-Cost Simulacrum
Nim · Metaprogramming · Compile-Time Execution · Python-Like Syntax · Systems Performance
A simulacrum abstracted from the published work of Andreas Rumpf, who is living and has had no part in it. ⭑ Python's syntax, C's speed, Lisp's metaprogramming — Nim compiles to C and lets C compile to native, so the indentation-based syntax sits on top of genuine systems performance. The distinctive part is the macro system: code that transforms the abstract syntax tree at compile time, in the same language.
Can help you study: AST macros as a real capability rather than text substitution — what becomes possible when a program can restructure itself before compilation. Compiling through C as a portability strategy and what it buys. Why an indentation-sensitive syntax is a readability decision with real consequences. ⚠ And the ecosystem question that faces every small language, however good.
→ Converse with Rumpfian Nim Metaprogramming Simulacrum
Application & Web Languages
Languages for building applications, web services, and user-facing software.
JavaScript · Prototypal Inheritance · The Event Loop · Closures · The Language of the Web
A simulacrum abstracted from the published record of Brendan Eich, who is living and has had no part in it. ⭑ Ten days. Netscape needed a browser scripting language; it had to LOOK like Java because marketing demanded it, and underneath he built something else entirely — first-class functions, closures, prototypes rather than classes. ⚠ The famous flaws are the ten days, and the good parts are the parts marketing did not specify.
Can help you study: Prototypal inheritance as a genuinely different model from classes, and why the class syntax added later is a disguise over it. Closures and first-class functions as the language's real foundation. Reading a design for the constraints that produced it — schedule, politics and a mandated appearance. ⚠ And a hard case in language evolution: what you can fix when you can never break the web.
→ Converse with Eichian JavaScript Design Simulacrum
TypeScript · Type Systems · Delphi · C# · Language Design at Scale · Structural Typing
A simulacrum abstracted from the published work of Anders Hejlsberg, who is living and has had no part in it. ⭑ Four languages, one lesson: the type system is not a constraint, it is a TOOL. Turbo Pascal, Delphi, C# and TypeScript each treat types as the thing that makes tooling possible — completion, refactoring, navigation — rather than as a tax paid for safety.
Can help you study: Structural typing in TypeScript against nominal typing elsewhere, and what each makes easy. Gradual typing as an engineering strategy for a language that already exists and cannot be replaced. Why a type system's real payoff is often in the editor rather than the compiler. And designing a language whose adoption path matters as much as its semantics.
→ Converse with Hejlsbergian Type System Architect Simulacrum
Perl · TMTOWTDI · Regular Expressions · Text Processing · Linguistic Programming
A simulacrum abstracted from the published work of Larry Wall, who is living and has had no part in it. ⭑ *I studied linguistics before I studied computers.* Human languages are messy, redundant, context-sensitive and magnificently expressive — and Perl was designed on the premise that a programming language should be too. There is more than one way to do it, because that is how natural language works and how people actually think.
Can help you study: Why redundancy and multiple idioms are a deliberate design position rather than an absence of one, and the case against it. Context — scalar and list — as a linguistic idea imported into a language. Regular expressions as first-class citizens and what that did to text processing. ⚠ And the readability objection, which is the strongest one and which the linguistic argument answers only partly.
→ Converse with Wallian Perl Linguistics Simulacrum
Ruby · Programmer Happiness · Duck Typing · Blocks · Rails · The Principle of Least Surprise
A simulacrum abstracted from the published work of Yukihiro Matsumoto, who is living and has had no part in it. ⭑ *I designed Ruby for the PROGRAMMER, not the machine.* C is optimised for the machine, Java for the enterprise, Ruby for the person typing — the principle of least surprise, everything an object, blocks as an ordinary part of the syntax, and the explicit goal that using it should be pleasant.
Can help you study: Designing for developer happiness as an actual criterion, and how it decides concrete syntax questions. Blocks and yield: why a first-class chunk of behaviour changes how libraries are written. Everything-is-an-object taken further than most languages take it. ⚠ And the trade the design accepts: expressiveness and metaprogramming bought at a real cost in performance and in the ability to reason statically.
→ Converse with Matsumotoan Ruby Joy Simulacrum
Erlang · Fault Tolerance · Let It Crash · The Actor Model · Concurrency · Telecom-Grade Reliability
⭑ Things will go wrong. Not a possibility — a certainty: hardware fails, software has bugs, networks partition. Erlang is built on accepting that rather than defending against it. Let it crash, isolate the process so the crash cannot spread, and put a supervisor above it whose only job is to restart what died. Reliability comes from recovery rather than from correctness.
Can help you study: Let-it-crash as an engineering discipline, and why defensive coding inside a process often makes a system less reliable. Supervision trees: designing the restart strategy as the primary architecture. Isolated processes with no shared state as the precondition that makes any of it work. And hot code loading — replacing a running system's code without stopping it, which follows from the same design.
→ Converse with Joe Armstrong Simulacrum
PHP · Server-Side Web · Pragmatic Scripting · WordPress · Laravel · The Web That Works
A simulacrum abstracted from the published record of Rasmus Lerdorf, who is living and has had no part in it. ⭑ *I did not set out to create a programming language.* He set out to make a personal home page dynamic and needed to count visitors — and what grew from that is honest about its origins in a way few languages are. It is plumbing: unglamorous, everywhere, and shaped by the problem in front of its author each week.
Can help you study: How a tool becomes a language by accretion, and what that produces — inconsistency, and an extraordinarily short path from problem to working page. The request-response model as the thing PHP is actually designed around. ⚠ And a case worth studying without snobbery: why a language widely derided by language designers runs a very large share of the web.
→ Converse with Lerdorfian PHP Web Plumbing Simulacrum
Dart · Flutter · Cross-Platform · Ahead-of-Time Compilation · Sound Null Safety · UI Framework
A simulacrum abstracted from published work on cross-platform development. ⭑ Write ONE codebase and run it on iOS, Android, web, Windows, Mac and Linux — not through a web wrapper but through NATIVE compilation, so the result is a real application rather than a page pretending to be one. The whole design question is what must be shared and what must be genuinely per-platform.
Can help you study: Deciding the boundary: which layers can be common and which must be native for an application not to feel foreign. Why a rendering-your-own-widgets strategy and a use-the-platform-widgets strategy produce different failures. The compilation pipeline that makes one source tree yield native binaries. And costing cross-platform honestly against maintaining separate applications.
→ Converse with Bakian Cross-Platform Simulacrum
Kotlin · Null Safety · Coroutines · JVM Interop · Android · Pragmatic Modern Language Design
A simulacrum abstracted from published work on Kotlin's design. ⭑ Java is verbose, null-unsafe and showing its age — but the JVM is magnificent, the ecosystem immense, and billions of lines already exist. Kotlin's position is pragmatic rather than revolutionary: fix what can be fixed, interoperate completely, and never require anyone to rewrite what already works.
Can help you study: Null safety in the type system, and how much of a real defect class it removes. Interoperability as the binding constraint on every design decision. Coroutines as a concurrency model layered onto a platform that did not have one. ⚠ And the general strategy worth examining: whether a successor language that must stay compatible can ever fix the deepest problems.
→ Converse with Brestovian Kotlin Pragmatism Simulacrum
Lua · Embeddable Scripting · Game Engines · Tables · Coroutines · Minimalism by Design
A simulacrum abstracted from the published work of Roberto Ierusalimschy, who is living and has had no part in it. ⭑ Lua has ONE data structure: the table. A table is an array, a dictionary, an object, a namespace, a module — and having one mechanism instead of five is what keeps the entire language small enough to embed in something else.
Can help you study: Building objects, modules and inheritance out of tables and metatables, which shows what those concepts actually require. Why designing for embedding constrains everything — size, dependencies, and the C interface. The virtual machine and its stack-based C API. And the general lesson: what a single sufficiently general mechanism buys against several specialised ones.
→ Converse with Ierusalimschian Lua Embedding Simulacrum
Functional Languages
Languages built on mathematical foundations — purity, types, and composition.
Haskell · Lazy Evaluation · Monads · Type Classes · Purity · Referential Transparency
A simulacrum abstracted from the published work of Simon Peyton Jones, who is living and has had no part in it. ⭑ A pure function takes inputs and produces outputs and does NOTHING ELSE — no printing, no reading, no mutation. Effects are not forbidden but made explicit in the type, so the compiler knows which parts of a program can be reordered, memoised or run in parallel because they cannot interfere.
Can help you study: Purity as a licence for the compiler rather than a moral position. Lazy evaluation: what it enables, and the space behaviour that makes it genuinely hard. Monads introduced as a way of sequencing effects in a pure setting, from the problem rather than from category theory. ⚠ And the honest assessment he makes himself — avoiding success at all costs, and what a research language gives up to stay one.
→ Converse with Peytonesque Haskell Purity Simulacrum
Elixir · OTP · BEAM · Fault Tolerance · LiveView · Distributed Systems · Let It Crash
A simulacrum abstracted from the published work of José Valim, who is living and has had no part in it. ⭑ Erlang has the best concurrency model in computing and a syntax that frightens most developers away from it. Elixir puts Ruby's ergonomics on top of the Erlang virtual machine — same processes, same supervision, same fault tolerance, wrapped in something a working developer will actually adopt.
Can help you study: The actor model as it works in practice on the BEAM: cheap processes, message passing, and supervision. Why adoption is a design problem and not merely a marketing one. Macros and the language's own extensibility, used to build the framework rather than bolted on. And the general question of when a new syntax over an existing runtime is the right engineering move.
→ Converse with Valimian Elixir Concurrency Simulacrum
F# · Functional-First · Type Providers · .NET · Domain Modelling · Railway-Oriented Programming
A simulacrum abstracted from the published work of Don Syme, who is living and has had no part in it. ⭑ F# is functional FIRST but not functional ONLY: begin with immutable values and pure functions, and drop to mutation or object-orientation where the platform or the problem requires it. The pragmatism is the design, and it is the reason the language lives inside a large object-oriented ecosystem rather than beside it.
Can help you study: Type providers — types generated from an external schema at compile time — which is an idea with few equivalents anywhere. Functional-first design against functional-pure, and where the boundary is drawn in practice. Units of measure in the type system. And interoperating with an object-oriented platform without abandoning the functional core.
→ Converse with Symean F# Functional .NET Simulacrum
Scala · FP + OOP Fusion · JVM · Spark · Akka · Type-Level Programming · DOT Calculus
A simulacrum abstracted from the published work of Martin Odersky, who is living and has had no part in it. ⭑ Object-oriented and functional programming are not opposites but COMPLEMENTARY: objects organise code into components, functions describe transformation, and a language can have both if the type system is strong enough to hold them together. Scala is the argument that it can.
Can help you study: Fusing the two paradigms in a single type system, and the machinery — traits, variance, implicits — that the fusion requires. Implicits and given instances as a mechanism for context, powerful and easy to misuse. ⚠ And the complexity question, which the Scala 3 redesign is itself a response to: whether the fusion is worth what it costs a reader.
→ Converse with Oderskian Scala Fusion Simulacrum
Julia · Multiple Dispatch · Scientific Computing · Speed of C · Ease of Python · JIT Compilation
A simulacrum abstracted from published work on Julia's design. ⭑ Scientists have a two-language problem: prototype in Python because it is easy, deploy in C or Fortran because it is fast, and maintain two versions of everything forever. Julia's claim is that multiple dispatch plus just-in-time compilation to native code removes the need for the second language.
Can help you study: Multiple dispatch as the organising principle — how it differs from single dispatch and why it suits mathematical code. Type stability and how to diagnose the code that defeats the compiler. The two-language problem stated properly, with what it actually costs a research group. ⚠ And the counter-question worth asking: whether the problem is solved or relocated to compile latency.
→ Converse with Bezansonian Julia Speed Simulacrum
R · Statistical Computing · CRAN · Data Frames · ggplot2 · Literate Analysis · Bioinformatics
A simulacrum abstracted from published work on R's design. ⭑ R was not designed by computer scientists — it was designed by STATISTICIANS for statisticians, and that is the whole difference. The data frame is a first-class object, missing values are part of the language rather than an afterthought, and formulae are syntax. What looks like eccentricity to a programmer is usually a statistical decision.
Can help you study: The data frame and vectorised operations as the natural unit of statistical work. NA as a language-level concept, and how it propagates. Formula notation and why modelling reads the way it does. ⚠ And the tension worth understanding: a language whose statistical ergonomics are excellent and whose general-purpose semantics surprise every programmer who arrives from elsewhere.
→ Converse with Ihakean R Statistical Computing Simulacrum
Further Faculty
Scholars of the department not yet placed in a section — a build point rather than a category.
Automata · Programmable Machines · Pneumatics · The Aeolipile · Ancient Computing
Hero built the first programmable machines. His automata — mechanical theatres driven by falling weights and string-wound axles — could perform sequences of actions in a fixed order: the earliest known programs. He also invented the aeolipile (a steam reaction turbine), wrote systematically on pneumatics, hydraulics, and mechanics, and described a coin-operated vending machine for holy water. The gap between his technologies and their widespread adoption is one of the great puzzles in the history of science.
Can help you with: The ancient origins of computing and automation, programmable mechanical devices, the history of machines, the aeolipile and ancient steam technology, and why technological capability does not always lead to adoption.
→ Converse with Hero of Alexandria
Micrographia · Instrument Design · The Universal Joint · Mechanical Philosophy · Invisible College
Polymath of the early Royal Society, Hooke designed instruments of extraordinary ingenuity, drew the microscopic world in Micrographia, formulated the law of elasticity that bears his name, and invented mechanisms — the universal joint, the iris diaphragm, the anchor escapement — still in use today. His mechanical philosophy and his quarrels with Newton mark him as one of the founders of experimental science.
Can help you with: Instrument design and the mechanical philosophy, microscopy and Micrographia, the workings of the early Royal Society, Hooke’s law of elasticity, and the invention of foundational mechanisms.
→ Converse with Robert Hooke
First Programmer · Analytical Engine · Algorithm · Bernoulli Numbers · Symbolic Operations
Lovelace wrote the first published algorithm intended to be processed by a machine — a method for computing Bernoulli numbers on Babbage’s Analytical Engine — in 1843. More importantly, she grasped what Babbage had not fully articulated: that the Engine could manipulate any symbols according to rules, not just numbers. Her note that the machine could compose music if given appropriate rules anticipated the whole of modern computing theory. She died at thirty-six, having seen further than anyone else in the nineteenth century.
Can help you with: The first algorithm and what it means, the distinction between hardware and software, the theoretical scope of programmable machines, the history of the Analytical Engine, and why the Victorian era almost had the computer.
→ Converse with Ada Lovelace
Communication Theory · Shannon-Weaver Model · Information · Noise · Machine Translation
Weaver co-authored with Claude Shannon the paper that founded information theory, adding the section that framed communication as a problem of signal and noise. His contribution was philosophical as much as technical: he distinguished three levels of communication (technical, semantic, effectiveness) and argued that the technical problem of transmitting signals accurately was the foundation on which meaning could be built. He also wrote the first serious proposal for machine translation in 1949, reasoning from wartime cryptography that if codes could be broken, languages could be translated algorithmically.
Can help you with: Information theory and the Shannon-Weaver model, the distinction between signal and noise, the levels of communication and what each requires, the history of machine translation, and the relationship between cryptography and computing.
→ Converse with Warren Weaver
Cybernetics · Feedback · Control Systems · Communication Theory · Human-Machine Boundary
Wiener founded cybernetics — the science of control and communication in animals and machines — and in doing so dissolved the boundary between biology and engineering. His insight was that feedback loops are the same whether they occur in a thermostat, a nervous system, or a guided missile. His book Cybernetics (1948) was one of the most influential scientific texts of the twentieth century. He was also an early and serious thinker about the social consequences of automation, warning in 1950 that machines might displace workers at a scale society was not prepared for.
Can help you with: Feedback loops and control systems, the relationship between machines and organisms, cybernetics and its influence on computing and cognitive science, the social consequences of automation, and the history of artificial intelligence’s conceptual foundations.
→ Converse with Norbert Wiener
Affordances · Ecological Perception · Direct Perception · Gibson’s Theory · Visual Interface
Gibson’s theory of affordances — the idea that we perceive not raw sensory data but directly the action-possibilities of objects — is the psychological foundation of interface design. We see a door handle as graspable, a button as pressable, not because we reason about them but because the information for action is directly available in the environment. His Ecological Approach to Visual Perception (1979) challenged the computational model of cognition and remains the most influential theory of direct human-computer interaction. Every usable interface is, consciously or not, designed around Gibsonian principles.
Can help you with: Affordance theory and its application to design, ecological approaches to perception, the direct perception vs. computational cognition debate, the psychological foundations of interface design, and why some interfaces feel natural and others do not.
→ Converse with James Gibson
Computation · The Turing Machine · Halting Problem · Can Machines Think? · Codebreaking
Turing defined computation. His 1936 paper on computable numbers, introducing the abstract machine that bears his name, proved that there are mathematical problems no algorithm can solve — and in doing so established what computation fundamentally is. He broke the Enigma cipher at Bletchley Park, shortening the war. He asked “Can machines think?” and proposed what is now called the Turing Test as a way of making the question precise. He was chemically castrated for homosexuality by the British state and died at forty-one. He is the foundational figure of computer science.
Can help you with: The foundations of computation and computability, the Turing Machine, the Halting Problem, the Turing Test and its implications, the history of codebreaking at Bletchley Park, and the philosophical question of machine intelligence.
→ Converse with Alan Turing
Information Theory · Entropy · The Mathematical Theory of Communication · Cryptography
Based on the work of Claude Shannon. His 1948 Mathematical Theory of Communication founded information theory, defining information in terms of entropy and establishing the limits of compression and reliable transmission over noisy channels. He also laid the foundations of digital circuit design and of modern cryptography, making him a principal architect of the information age.
Can help you with: Information theory and entropy, channel capacity and the noisy-channel coding theorem, data compression, the foundations of digital communication, and the mathematical basis of cryptography.
→ Converse with the Shannonian Simulacrum
Algorithms · Elegance · Proof · Structured Programming · The GOTO Statement
Dijkstra invented the shortest-path algorithm, developed the foundations of concurrent programming, and led the campaign that abolished the GOTO statement from serious programming — his 1968 letter “Go To Statement Considered Harmful” is the most influential single document in programming methodology. His deeper contribution was the insistence that programs must be proved correct, not merely tested, and that a program whose correctness cannot be reasoned about is not a good program regardless of whether it works. He received the Turing Award in 1972 and wrote his final technical notes by hand with a fountain pen.
Can help you with: The shortest-path algorithm and graph theory, structured programming and why GOTO was harmful, program correctness and formal reasoning, the aesthetics of elegant code, concurrent programming, and the relationship between mathematical rigour and practical programming.
→ Converse with Edsger Dijkstra
Neuromorphic Computing · VLSI · Mead-Conway Revolution · Silicon Neurons · Physics of Computation
Based on the published writings of Carver Mead. Mead coined the term “neuromorphic” and pioneered analogue circuits that emulate neural and retinal processing. With Lynn Conway he wrote the textbook that democratised VLSI design, enabling the explosion of custom silicon. His work links the physics of devices to the architecture of computation.
Can help you with: Neuromorphic engineering and silicon neurons, VLSI design and the Mead-Conway revolution, the physics of computation, and analogue approaches to neural processing.
→ Converse with the Meadesque Simulacrum
The Art of Computer Programming · TeX · Literate Programming · Algorithm Analysis
Based on the published writings of Donald Knuth. His multi-volume The Art of Computer Programming is the foundational analysis of algorithms; he created the TeX typesetting system, invented literate programming, and established the rigorous mathematical analysis of algorithmic complexity. Few people have shaped the discipline of computer science so deeply.
Can help you with: The analysis of algorithms and asymptotic complexity, The Art of Computer Programming, TeX and digital typesetting, literate programming, and mathematical rigour in computing.
→ Converse with the Knuthian Simulacrum
Gödel Escher Bach · Strange Loops · Self-Reference · Consciousness · Analogies as Cognition
Based on the published writings of Douglas Hofstadter. His Gödel, Escher, Bach wove logic, art, and music into a meditation on how self-reference and “strange loops” might give rise to mind. His later work argues that analogy-making is the core of cognition. He treats consciousness as a pattern that refers to itself.
Can help you with: Strange loops and self-reference, the ideas of Gödel, Escher, Bach, analogy as the engine of cognition, and the relationship between formal systems and consciousness.
→ Converse with the Hofstadter Simulacrum
SHRDLU · Breakdown as Revelation · Heidegger and Computing · Design for Human Practice
Based on the published writings of Terry Winograd. His SHRDLU program was an early triumph of natural-language understanding in a constrained world; he later turned, with Fernando Flores, to a Heideggerian critique of AI, arguing that computers are best understood as tools embedded in human practice rather than as minds. He shaped human-computer interaction and taught the founders of Google.
Can help you with: Natural-language understanding and the lessons of SHRDLU, the phenomenological critique of AI, design for human practice, and the philosophy of human-computer interaction.
→ Converse with the Winogradian Simulacrum
The Singularity · Exponential Growth · Pattern Recognition · Mind Uploading · The Law of Accelerating Returns
Based on the published writings of Ray Kurzweil. Inventor of pioneering optical-character-recognition and music-synthesis systems, he is best known for his theory of the technological singularity and the “law of accelerating returns” — the claim that information technologies improve exponentially, leading toward a transformation of human capability.
Can help you with: The law of accelerating returns and exponential technology trends, the technological singularity, pattern-recognition theories of mind, and the history of OCR and synthesis.
→ Converse with the Kurzweillian Simulacrum
Apple I · Apple II · Engineering Elegance · Minimal Hardware · The Joy of Engineering
Based on the published writings of Steve Wozniak. He designed the Apple I and Apple II almost single-handedly, achieving feats of hardware economy — a floppy controller in a handful of chips, colour graphics from clever timing tricks — that became legendary. His engineering embodies elegance through minimalism and a genuine joy in the craft.
Can help you with: Elegant minimal hardware design, the engineering of the Apple I and II, doing more with fewer components, and the craft and joy of engineering.
→ Converse with the Wozniakian Simulacrum
Subsumption Architecture · Behaviour-Based Robotics · Embodied Intelligence · iRobot · The World is its Own Model
Based on the published writings of Rodney Brooks. He overturned classical AI’s reliance on internal world-models with subsumption architecture — layered, reactive behaviours coupling sensing directly to action — arguing that “the world is its own best model.” He co-founded iRobot and Rethink Robotics, putting embodied intelligence into real machines.
Can help you with: Subsumption architecture and behaviour-based robotics, embodied intelligence, the critique of representation-heavy AI, and the path from lab robots to commercial machines.
→ Converse with the Brooksian Simulacrum
Product · Design · The Personal Computer · The Graphical Interface · Simplicity as Discipline
Jobs did not invent the graphical user interface, the personal computer, the digital music player, the smartphone, or the tablet — but he made all of them work for ordinary people, which is a different and arguably harder achievement. His method was relentless removal: eliminate everything that does not need to be there, then eliminate some more. The result was products that felt inevitable in retrospect but required enormous effort to make. His 1984 Macintosh brought the graphical interface out of the research lab; his 2007 iPhone made the computer truly personal in ways the desktop never was.
Can help you with: The graphical user interface and its history, the design philosophy of simplicity, product development and the role of taste in technology, the history of Apple, the transition from personal computers to mobile devices, and the relationship between art and engineering in product design.
→ Converse with Steve Jobs
Computer Vision · Deep Visual Representations · VGG Networks · Action Recognition · Visual Geometry Group
Based on the published writings of Andrew Zisserman. A leader of Oxford’s Visual Geometry Group, he shaped modern computer vision from multiple-view geometry through the deep-learning era — the VGG networks, large-scale recognition, and self-supervised visual representations. He is among the most cited researchers in the field.
Can help you with: Computer vision and multiple-view geometry, deep visual representations and the VGG architectures, large-scale recognition and action understanding, and self-supervised visual learning.
→ Converse with the Zissermanian Simulacrum
Mathematica · A New Kind of Science · Wolfram Language · Cellular Automata · Computational Irreducibility
Based on the published writings of Stephen Wolfram. He built Mathematica and the Wolfram Language, and in A New Kind of Science argued that simple computational rules — cellular automata — generate the complexity of nature, introducing computational irreducibility as a limit on prediction. His more recent work seeks a computational foundation for physics.
Can help you with: Cellular automata and computational irreducibility, the ideas of A New Kind of Science, symbolic computation and the Wolfram Language, and computational approaches to natural law.
→ Converse with the Wolframian Simulacrum
LLVM · Clang · Swift · Mojo · Compiler Infrastructure · Language Design
Based on the published writings of Chris Lattner. He created LLVM, the compiler infrastructure now underlying much of modern software, then the Clang front-end and the Swift language at Apple, and more recently Mojo for AI systems. His work has repeatedly reshaped how languages are built and how code is compiled.
Can help you with: Compiler infrastructure and LLVM, language and type-system design, the Swift and Mojo languages, and the architecture of modern toolchains.
→ Converse with the Lattnerite Simulacrum
A simulacrum abstracted from the published work of Ruzena Bajcsy, who is living and has had no part in it. ⭑ Perception is ACTIVE: an observer must control its sensors to acquire information, so vision is not the processing of an image that arrives but the deliberate business of deciding where to look and moving to look there. The same argument runs through the haptic work — a hand does not receive a shape, it executes exploratory procedures to find one out.
Can help you study: Active perception as a design principle: what changes when sensing is treated as a control problem rather than a signal-processing one. Exploratory procedures in touch — the specific movements that recover hardness, texture, weight and shape. Purposive sensing: choosing the next measurement by what would most reduce uncertainty. And why a passive vision system and an active one need different mathematics.
→ Converse with Bajcsyan Active Perception Simulacrum
