I get the point, but I wonder at why people find this particular article compelling

> You really want to push it upward if it's a high-level concern, and downward if it's a low-level concern. E.g., suppose you're working on an app or service that accesses the database, so the database is lower-level. You'll want to push your database-specific type transformations closer to the code that accesses the database. IMO, database code is at exactly the same level of concern as network code or filesystem code. By “upward”, she means push parsing to the boundaries of your program — as close to the point of ingress as possible.

> It's built on a particular technical distinction between paring and validating that (1) is not all that commonly understood or consistently accepted and (2) not actually explicitly stated in the article! If this isn't clear to you, ask yourself why programming languages are parsed and not merely validated. Validation is a subset of parsing, so clearly there's something important added.

I figured from the title I'd get a better explanation in the comments, and I was right, but I think the article is not nearly as bad as the clickbaity title suggests. It's a decent introduction to how to use types to simplify code, and the basic idea that your types should reflect what you know about the data is extremely powerful. If you go to the trouble of checking that your data meets some constraints, you should be able to represent it with a more constrained type afterwards, and that is the essence of parsing. It all makes sense! Even the title makes sense, as a quick way to reference and remember the idea after you've learned it. But, yeah, the clickbait title put me off, and you're right that the terminology is unhelpful, since the distinction between parsing and validation isn't consistently made, especially in practical work. Virtually all of the "validation" code I've seen in …

> (2) not actually explicitly stated in the article! the difference between validation and parsing lies almost entirely in how information is preserved. Consider the following pair of functions: validateNonEmpty :: [a] -> IO () parseNonEmpty :: [a] -> IO (NonEmpty a) Both of these functions check the same thing, but parseNonEmpty gives the caller access to the information it learned, while validateNonEmpty just throws it away.

> You really want to push it upward if it's a high-level concern, and downward if it's a low-level concern. E.g., suppose you're working on an app or service that accesses the database, so the database is lower-level. You'll want to push your database-specific type transformations closer to the code that accesses the database. This confusion is, I think, just a question of different conceptions of the system architecture. Your terminology is drawing from a three-tier architecture [0] with a presentation layer, logic layer, and data layer. Under this model, input (data) is the bottom layer and output (HTTP/GUI) is the top layer, with your application logic in the middle. On the other hand, she is viewing the system through an inside-outside lens similar to the hexagonal architecture [1]. All input (data) and output (HTTP/GUI) is considered to be up and out of your application logic. Rathe…