Top all-time · #281
Alexis King
Personal blog · lexi-lambda.github.ioprogrammingphilosophy
Alexis King's personal blog at lexi-lambda.github.io covers programming and philosophy. Since 2015, 173 different Hacker News readers have linked it 225 times, most often “Parse, Don’t Validate”. It is still writing: the last post was on 2025-05-29, and you can follow it by feed.
Sometimes recommended · 7 of 40 sampled comments recommend it?
Why HN links it
HN readers link Alexis King's posts, mainly "Parse, Don't Validate", for the argument that parsing untrusted data into types beats validating it. Her posts on static vs dynamic typing are also linked.
- Recommended for · 7 comments
- "Pretty much the final word" on typing messy data; "a good post"; "very well written"; "favorite" comparison; "go read".
Summarised by Claude from a sample of 40 HN comments that link here. Each comment is marked recommending, critical or neutral (citing without judging); how this works.
Most-linked posts?
- Parse, Don’t Validate95 people · 110 mentions · first linked 2019-11-07
- Dynamic type systems are not inherently more open17 people · 22 mentions · first linked 2020-01-19
- Realizing Hackett, a metaprogrammable Haskell8 people · 8 mentions · first linked 2017-05-28
- Names are not type safety (2020)7 people · 10 mentions · first linked 2021-06-27
- An opinionated guide to Haskell6 people · 6 mentions · first linked 2018-02-10
- Types as axioms, or: playing god with static types5 people · 10 mentions · first linked 2020-08-14
- A Break from Programming Languages5 people · 5 mentions · first linked 2025-05-29
- The Hackett Programming Language5 people · 5 mentions · first linked 2018-08-07
- Empathy and subjective experience in programming languages5 people · 5 mentions · first linked 2019-10-20
- Rascal: a Haskell with more parentheses5 people · 5 mentions · first linked 2017-01-02
What Hacker News says?
I think copilot is solving the wrong problem. A future of programming where we're higher up the abstraction tree is absolutely something I want to see. I am taking advantage of that right now -- I'm a decently good programmer, in the sense that I can write useful, robust, reliable software, but I'm pretty high up the stack, working in languages like Java or even higher up the stack that free me from worrying about t…
Comment linking /blog/2019/11/05/parse-don-t-validate/
on “Copilot regurgitating Quake code, including sweary comments”Submitted Parse, Don’t Validate as a story · 642 points
HN discussion> The Valid method takes a context (which is optional but has been useful for me in the past) and returns a map. If there is a problem with a field, its name is used as the key, and a human-readable explanation of the issue is set as the value. I used to do this, but ever since reading Lexi Lambda's "Parse, Don't Validate," [0] I've found validators to be much more error-prone than leveraging Go's built-in type chec…
Comment linking /blog/2019/11/05/parse-don-t-validate/
on “How I write HTTP services in Go after 13 years”Submitted Parse, Don't Validate (2019) as a story · 389 points
HN discussionBecause ideally your JSON schema validator would turn it into a type that mirrors the structure of the data. "Parse, don't validate"[0] [0]: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
Comment linking /blog/2019/11/05/parse-don-t-validate/
on “Dave Herman’s contributions to Rust”Submitted Dynamic type systems are not inherently more open as a story · 382 points
HN discussion> no commonly used statically typed language helps here because they all allow null references This is false. TypeScript, Swift, and Rust are commonly used and support non-nullable references. > those languages, don't help you because you are dealing with real world data where inputs to your system can be null or not so you end up using some type system escape hatch anyway. You don't need escape hatches to deal with…
Comment linking /blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/
on “Cold Showers”Submitted Parse, Don't Validate (2019) as a story · 321 points
HN discussionIt all comes down to proper data modelling, whether in a statically-typed or a dynamically-typed codebase. If you were consuming a JSON API that gave you this data: {"id": 1, "name": "Bob", "age": 55} But your Clojure app only needed the 'id' and 'name', why would you write a parser function that also grabbed 'age'? E.g. (I don't know specific Clojure libs, so this is for illustration only): (defn decode-user [json-…
Comment linking /blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/
on “A History of Clojure [pdf]”Submitted Names are not type safety as a story · 262 points
HN discussionThat's almost the same thing as parse don't validate: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
Comment linking /blog/2019/11/05/parse-don-t-validate/
on “Push Ifs Up and Fors Down”Submitted An opinionated guide to Haskell as a story · 260 points
HN discussionCouldn't you just take the advice in [0] of parsing into types rather than validating? Then you get the best of both worlds: your inputs are necessarily checked every time the function is called (they would have to be to create the type in the first place), but you don't need to validate them at every nested layer. You also get the benefit of more descriptive function signatures to describe your interfaces. [0] http…
Comment linking /blog/2019/11/05/parse-don-t-validate/
on “Push Ifs Up and Fors Down”Submitted Four months with Haskell as a story · 249 points
HN discussionYou can and should put as many as you can there https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... If instead of validating that someone has sent you a phone number in one spot and then passing along a string, you can as easily have a function construct an UncheckedPhoneNumber. You can choose to only construct VerifiedPhoneNumbers if the user has gone through a code check. Both would allow you to pluck…
Comment linking /blog/2019/11/05/parse-don-t-validate/
on “Push Ifs Up and Fors Down”Submitted Realizing Hackett, a metaprogrammable Haskell as a story · 161 points
HN discussionYes indeed. If you are doing this kind of job, reach for a parser generator framework and fuzz your program. Also go read Parse Don’t Validate https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
Comment linking /blog/2019/11/05/parse-don-t-validate/
on “Initial details about why CrowdStrike's CSAgent.sys crashed”Submitted Learning Haskell – A Racket programmer's foray into the land of Haskell as a story · 132 points
HN discussionWhile this is true in some senses, Rust's type system is very different than Haskell's when it comes to handling IO. That said, I don't think it's impossible to type IO. https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ... isn't the same problem, but it's related.
Comment linking /blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/
on “Unit Testing Is Overrated”Submitted Types as axioms, or: playing god with static types as a story · 109 points
HN discussionhttps://github.com/lexi-lambda/hackett https://lexi-lambda.github.io/blog/2017/05/27/realizing-hack...
Comment linking /blog/2017/05/27/realizing-hackett-a-metaprogrammable-haskell/
on “Alan Kay on Lisp”Submitted Defeating Racket’s separate compilation guarantee as a story · 109 points
HN discussionHeh. Hickey once debated with me at length about visual neuroscience, a subject I have a master's degree in and he doesn't. At no point did this stop him from confidently asserting things. I have to wonder if "Maybe Not" is similar, since he's not actually an expert in types, either afaik. Alexis King wrote a partial rebuttal to Maybe Not: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ...
Comment linking /blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/
on “The jank programming language”Submitted Climbing the infinite ladder of abstraction as a story · 77 points
HN discussionIt doesn't surprise me much that this was written by the same author as "Parse, don't validate", very well written [0]: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... [1]: all previous threads https://news.ycombinator.com/from?site=lexi-lambda.github.io
Comment linking /blog/2019/11/05/parse-don-t-validate/
on “How do modern compilers choose which variables to put in registers?”Submitted An Introduction to Typeclass Metaprogramming as a story · 72 points
HN discussion> Rust is a really good language for writing parsers. C++ really isn’t. One thing I appreciate about writing Rust is that ADT support implies writing parsers is simpler under the "parse don't validate" mindset (which was clarified for me I think in this [0] article). [0]: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
Comment linking /blog/2019/11/05/parse-don-t-validate/
on “Everything Is Broken: Shipping Rust-Minidump at Mozilla”Submitted Names are not type safety (2020) as a story · 56 points
HN discussion> There's a follow-up article by the same author (that I unfortunately can't find), in which she explains this point. I think this is it: https://lexi-lambda.github.io/blog/2020/11/01/names-are-not-...
Comment linking /blog/2020/11/01/names-are-not-type-safety/
on “Parse, Don't Validate (2019)”Submitted Simple, safe multimethods in Racket as a story · 50 points
HN discussion