--- title: The Unreasonable Effectiveness of Constructive Data... description: A conference talk by Alexis King (formerly a Haskell compiler engineer, now writing Scala at August Health) advocating for constructive data modeling as a... canonical: https://daily.dev/posts/the-unreasonable-effectiveness-of-constructive-data-modeling---alexis-king-ssw-2026-lkvwww6lj twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: The Unreasonable Effectiveness of Constructive Data Modeling - Alexis King | SSW 2026 | daily.dev og:description: A conference talk by Alexis King (formerly a Haskell compiler engineer, now writing Scala at August Health) advocating for constructive data modeling as a... og:url: https://daily.dev/posts/the-unreasonable-effectiveness-of-constructive-data-modeling---alexis-king-ssw-2026-lkvwww6lj og:image: https://api.daily.dev/og/posts/lKVWWW6lJ.png og:image:alt: The Unreasonable Effectiveness of Constructive Data Modeling - Alexis King | SSW 2026 og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # The Unreasonable Effectiveness of Constructive Data Modeling - Alexis King | SSW 2026 **[Lobsters](https://daily.dev/sources/lobsters)** · 42 min read · 0 upvotes · 0 comments ## Summary A conference talk by Alexis King (formerly a Haskell compiler engineer, now writing Scala at August Health) advocating for constructive data modeling as a practical alternative to complex type system features. The core argument: instead of restricting types from a large universe of values (negative space), define types that only include valid values from the start (positive space). Key techniques include using product and sum types with exhaustive pattern matching, representing non-empty lists as a head-plus-tail tuple, modeling mutually exclusive states as explicit enumerations, and choosing the simplest representation that eliminates runtime panics. The talk frames type systems not as formal proof engines but as obligation propagation machines that connect producers and consumers of data, ensuring all cases are handled. King also discusses the 'parse don't validate' idea, total functions, and when to use optional types — arguing that Option types can actually be more restrictive depending on where obligations are placed. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How do I represent a non-empty list in the type system without fancy type system features? Represent a non-empty list as a tuple of one element plus a list of zero or more elements. This works in any language with product types — no refinement types or dependent types needed. The first element is always present by construction, so operations like 'get the first element' are total and cannot fail. TypeScript's variadic tuple types offer a more ergonomic version, but the tuple approach works universally. _Developers enforcing non-empty collection invariants across codebases share patterns like these on daily.dev._ ### What does it mean to model the positive space of a type instead of the negative space? Modeling the positive space means defining a type that only contains the values you want, rather than starting from a broad type and restricting it. For example, instead of an int constrained to be non-negative, start from an unsigned integer. Instead of a struct with nullable fields and a comment saying 'at least one must be set', define an explicit sum type enumerating every valid combination. This avoids refinement types and keeps type checking tractable. _Teams moving away from nullable fields and runtime guards track this kind of type design thinking on daily.dev._ ### When should I use Option types and when should I avoid them in a statically typed language? Use Option types when the call site is the right place to handle the missing-value case. Avoid them when they push an unresolvable obligation inward — for example, a notify function that accepts Option still has to decide what to do when the user is absent, which may be harder there than at the caller. Changing a parameter from Option to T moves the obligation outward to the caller, which is often better equipped to handle it. _Choosing where to place Option boundaries is the kind of design decision Scala and TypeScript engineers discuss on daily.dev._ ## Similar posts on daily.dev - ["Five-Point Haskell": Total Depravity \(and Defensive Typing\)](https://daily.dev/posts/five-point-haskell-total-depravity-and-defensive-typing--xwwoyitrt) · Planet Haskell · 0 upvotes · 0 comments - [Co-Creator of Haskell: Functional Programming, Thinking in Types, Useless Languages](https://daily.dev/posts/co-creator-of-haskell-functional-programming-thinking-in-types-useless-languages-o1piocsn9) · The Developing Dev · 0 upvotes · 0 comments - [Learning Lean: Part 1](https://daily.dev/posts/learning-lean-part-1-ruwzozxws) · Hacker News · 0 upvotes · 0 comments - [To test, or not to Test? Part 2 – Make it hard to make mistakes](https://daily.dev/posts/to-test-or-not-to-test-part-2-make-it-hard-to-make-mistakes-fnfxbqcof) · We Are .NET · 0 upvotes · 0 comments --- Tags: [#functional-programming](https://daily.dev/tags/functional-programming), [#general-programming](https://daily.dev/tags/general-programming), [#type-systems](https://daily.dev/tags/type-systems) [View this post on daily.dev](https://daily.dev/posts/the-unreasonable-effectiveness-of-constructive-data-modeling---alexis-king-ssw-2026-lkvwww6lj) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"The Unreasonable Effectiveness of Constructive Data Modeling - Alexis King | SSW 2026","url":"https://daily.dev/posts/the-unreasonable-effectiveness-of-constructive-data-modeling---alexis-king-ssw-2026-lkvwww6lj","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/the-unreasonable-effectiveness-of-constructive-data-modeling---alexis-king-ssw-2026-lkvwww6lj"},"datePublished":"2026-08-11T08:32:01.999Z","dateModified":"2026-10-14T02:23:38.598Z","description":"A conference talk by Alexis King (formerly a Haskell compiler engineer, now writing Scala at August Health) advocating for constructive data modeling as a...","image":"https://i.ytimg.com/vi/0BXuYlNrUmE/sddefault.jpg","thumbnailUrl":"https://i.ytimg.com/vi/0BXuYlNrUmE/sddefault.jpg","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/the-unreasonable-effectiveness-of-constructive-data-modeling---alexis-king-ssw-2026-lkvwww6lj","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"functional-programming,general-programming,type-systems","timeRequired":"PT42M","video":{"@type":"VideoObject","name":"The Unreasonable Effectiveness of Constructive Data Modeling - Alexis King | SSW 2026","description":"A conference talk by Alexis King (formerly a Haskell compiler engineer, now writing Scala at August Health) advocating for constructive data modeling as a...","thumbnailUrl":"https://i.ytimg.com/vi/0BXuYlNrUmE/sddefault.jpg","uploadDate":"2026-08-11T08:32:01.999Z","duration":"PT42M","url":"https://api.daily.dev/r/lKVWWW6lJ","embedUrl":"https://www.youtube.com/embed/0BXuYlNrUmE"}} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"The Unreasonable Effectiveness of Constructive Data Modeling - Alexis King | SSW 2026"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/the-unreasonable-effectiveness-of-constructive-data-modeling---alexis-king-ssw-2026-lkvwww6lj#faq","mainEntity":[{"@type":"Question","name":"How do I represent a non-empty list in the type system without fancy type system features?","acceptedAnswer":{"@type":"Answer","text":"Represent a non-empty list as a tuple of one element plus a list of zero or more elements. This works in any language with product types — no refinement types or dependent types needed. The first element is always present by construction, so operations like 'get the first element' are total and cannot fail. TypeScript's variadic tuple types offer a more ergonomic version, but the tuple approach works universally. Developers enforcing non-empty collection invariants across codebases share patterns like these on daily.dev."}},{"@type":"Question","name":"What does it mean to model the positive space of a type instead of the negative space?","acceptedAnswer":{"@type":"Answer","text":"Modeling the positive space means defining a type that only contains the values you want, rather than starting from a broad type and restricting it. For example, instead of an int constrained to be non-negative, start from an unsigned integer. Instead of a struct with nullable fields and a comment saying 'at least one must be set', define an explicit sum type enumerating every valid combination. This avoids refinement types and keeps type checking tractable. Teams moving away from nullable fields and runtime guards track this kind of type design thinking on daily.dev."}},{"@type":"Question","name":"When should I use Option types and when should I avoid them in a statically typed language?","acceptedAnswer":{"@type":"Answer","text":"Use Option types when the call site is the right place to handle the missing-value case. Avoid them when they push an unresolvable obligation inward — for example, a notify function that accepts Option still has to decide what to do when the user is absent, which may be harder there than at the caller. Changing a parameter from Option to T moves the obligation outward to the caller, which is often better equipped to handle it. Choosing where to place Option boundaries is the kind of design decision Scala and TypeScript engineers discuss on daily.dev."}}]} ```