Complexity Has a Shape

I’ve been turning over an idea that programming languages have a distinct “shape” to their complexity. Not complexity as in “hard to learn” (that’s subjective and boring to argue about), but where a language concentrates its rules, edge cases, and gotchas.

Picture a stack of layers, each one representing a band of abstraction. The width of each layer is its conceptual density: how many rules, special cases, and surprising interactions you need to hold in your head to work comfortably at that level. Glue these layers together and you get a silhouette, a funnel shape that tells you where a language will demand the most from you.

The number and nature of these layers varies from language to language. C barely has anything going on at the top. Haskell barely has anything at the bottom. That’s the whole point: the silhouette is different, and the differences are instructive.

To keep this grounded, I went back to the actual language specs rather than relying on vibes. Here’s what the standards say about where the complexity lives.

C: The Bottom-Heavy Slab

C’s complexity is almost entirely concentrated at the foundation. The C standard (ISO/IEC 9899) dedicates enormous surface area to its type system and memory model, and Annex J.2 catalogues roughly 200 explicitly undefined behaviors. The upper layers are deliberately thin, almost vestigial. The whole language fits in three tiers.

• Textual Macros: The preprocessor (§6.10) is textual substitution with no type awareness or hygiene. Powerful in practice, but the rules fit in about 15 pages. There isn’t really a “meta” layer beyond this.
• Structs, Unions & Functions: The middle of C. Composite types, function pointers, _Generic (C11), atomics. Moderate density, nothing wildly surprising if you survived the layer below.
• Pointers, Memory & UB: Where C lives. Pointer arithmetic is only valid within arrays (§6.5.6), integer promotions have signed/unsigned mismatch traps (§6.3), and the strict aliasing rule (§6.5¶7) is notoriously misunderstood. The spec spends more ink on what you can’t do than what you can.

Java: The Uniform Tower

The Java Language Specification (JLS) is designed for predictability. Every layer carries a similar conceptual load. The result is a tower with straight walls: no dramatic bulges, no tapers. The only real asymmetry is the primitive/reference type duality at the base, the subtle friction between int on the stack and Integer on the heap.

• Annotations & Reflection: Runtime introspection, annotation processing, and the java.lang.reflect API. Useful for frameworks, largely invisible to application code.
• Generics & Type Inference: Bounded wildcards, type erasure, and the 30+ pages of constraint solving in §18. Where variance bites.
• Sealed Types & Records: The newer layer. Sealed interfaces (§8.1.1.2), records, and pattern matching in switch. Clean additions, consistent density.
• Classes & Interfaces: The bread and butter. Inheritance, method dispatch, access control. Extremely well-trodden ground.
• Primitive / Reference Duality: Eight primitive types live in a parallel universe from reference types. Autoboxing (§5.1.7) bridges them, but the NPE trap and identity-vs-equality confusion persist. The one layer that’s slightly wider than the rest.

Python: The Top-Heavy Funnel

The Python Language Reference hides complexity at the bottom and piles it on at the top. The primitive layer is deliberately narrow: everything is an object, you never think about memory, and the Data Model (§3.1) collapses what would be five concepts in C into one. The meta layer, on the other hand, is enormous.

• Metaclasses & Import Hooks: Metaclasses (§3.3.3), import hooks (§5.3), exec/eval, and the ast module. More metaprogramming surface area than almost any mainstream language, and it’s all written in the same language as everything else.
• Descriptors & Decorators: The descriptor protocol (__get__, __set__, __delete__) underpins properties, classmethods, and staticmethods. Decorators layer on callable transformation. Deceptively deep.
• Async & Generators: async/await, generator-based coroutines, yield from. Two overlapping concurrency models that share syntax but differ in mechanism.
• Classes & Dunder Methods: MRO, __init__ vs __new__, the sprawling collection of double-underscore methods that customize operator behavior, comparison, hashing, iteration.
• Object Model: You rarely think about types at runtime (§3.1). id(), type(), and garbage collection are nearly invisible. The narrowest layer, by design.

JavaScript: The Geological Sediment

The ECMAScript specification (ECMA-262) reads like an archaeological dig. Decades of backwards-compatible additions have created geological strata, and the oldest layers at the bottom are the most hazardous. The == operator alone (§7.2.15, Abstract Equality Comparison) is a 10-step algorithm that recursively invokes ToPrimitive. There are five distinct this-binding modes, each following a different spec path.

• Proxy & Symbols: Proxy/Reflect (§28) and well-known Symbols are powerful but well-contained. Most JS developers never touch this layer.
• Async & Promises: The microtask queue, async/await, Promise.all vs Promise.allSettled. Clean in isolation, painful when composed with the layers below.
• Prototypes & Closures: The original object model. Prototype chains, Object.create, lexical closures, arguments. Still the actual runtime mechanism under class syntax.
• Modules & Classes: ES modules, class syntax (syntactic sugar over prototypes), import/export. The modern face of JS, pasted over the older strata.
• Coercion, Scoping & this: The type coercion tables (§7.1), dual equality operators (§7.2.15 vs §7.2.16), this binding rules, var hoisting vs let/const TDZ (§14.3), and null vs undefined. The widest layer of any mainstream language, and the reason linters exist.

Haskell: The Inverted Tornado

The Haskell 2010 Report defines a famously small value-level language. ADTs, pattern matching, and Hindley-Milner inference fit on a napkin. But GHC ships over 100 language extensions, and the extensions chapter of the GHC User Guide is larger than the entire Haskell Report. The shape is an inverted tornado: a point at the bottom that expands as you ascend into type-level programming.

• Template Haskell & Deriving: Template Haskell is compile-time metaprogramming, splicing AST fragments into your code. DerivingStrategies, GeneralizedNewtypeDeriving, and DeriveGeneric automate boilerplate, but knowing which strategy applies where is its own skill.
• Type Families & GADTs: Type families, GADTs, DataKinds. Effectively a second, Turing-complete language at the type level. This is where the funnel really widens.
• Typeclasses & Monads: The composition mechanism. Functor, Applicative, Monad, and friends. Lawful abstractions that are elegant once internalized, but the learning curve is famously steep.
• ADTs & Pattern Matching: Algebraic data types and pattern matching (Report Ch 3-4). The core vocabulary of Haskell. Small, precise, and composable.
• Pure Values: Lazy evaluation, purity, and type inference actually reduce primitive surface area compared to imperative languages. No mutation, no null, no implicit conversions. The narrowest foundation of any language here.

What The Shapes Tell You

The shape of a language is dictated by how much precedes the next layer up, often as a pre-requisite. This is how I’ve personally experienced languages, the complexity and difficulties are in the wider layers. JavaScript has given me endless issues in those lower layers as there’s so many features interacting with each other. Whereas the bottom layer in Haskell is values, functions and data types, where there’s very little scope for issues.

What The Shapes Don’t Tell You

The other dimension to this is the quality and value of those features. We’re all familiar with the issues that null references has caused the entire software engineering industry. Upper layers are (often) built on top of the lower layers, so bad lower layers leads to bad upper layers. Equality being massively complicated and easy to get wrong in JavaScript for regular values leads to the same issue for instances of classes and so on.

Sidenote

I didn’t build these layer images, I asked Claude to create them by analysing the specs and asked it to align them how it determined their complexity and relationships. The only data I gave it was the list of programming languages to include.