Great article!
I drafted this post years ago but didn’t finish it until now. The concept I write about has shaped the way I design software more than anything else, and I believe every software engineer should be introduced to it early in their career.
P.S. I don’t want the title to come across as clickbait: the post is about ADT.
Great article!
Beautiful!
Nice :) You may enjoy this post from a while back (not mine): https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/
I haven't read it yet but guessing it's about the conversion of external data into a proper domain type on the app border to guarantee integrity?
Great article
TLDR; hey Gemini, turn this article into a skill Jk, great read
Ugh, I don't even want to waste my time reading, because claiming static typing has anything to do with the "bedrock of software design" is obviously wrong.
Static typing is neither necessary nor sufficient for high quality, but it sure helps a lot.
Nice to see more focus being brought to the power of algebraic data types. I also like to combine them with value semantics and wither based updates insted of destructive inplace updates to enforece side effect free code by design.
Really good article, I hope my agent reads it
Honestly, I go into paranoid mode whenever I work in an exception-based language.
I'm the opposite, I go into annoyed-mode when I have to manually unwrap everything (and the CPU does too because it has to execute more instructions)
To me, it really depends on how "normal" the error is. If I get in a state that shouldn't exist, I'd rather throw an error. If the error is expected (an API call to a 3rd party that fails), I'd rather return a result.
So you also don't use std::expected? LLVM optimizes for the happy path, like it does for exception based error handling.
I already find it hard find it hard to put myself into the perspective of someone who doesn't what GADTs, higher ranks, higher kinds, etc, but I always have to remind myself that a lot of people don't know basic ADTs are. Like, ADTs have bene a staple of typed functional programming since like the late 1970s. It's so disheartening that still so many programmers still don't know even what they are.
Some (like me) know what they are and even use them, but never had a formal education in compsci/programming to connect the theory to the execution.
I'm writing c# mostly and i have spent two year to find balance these usage. These are not new concepts, the article felt like i have read this hundred times. The problem is you cannot use these practices everywhere. If you use these practices evertwhere then your code while start to bloat, for example you need to keep your result pattern usage thin and think where to apply. Type structuring is good thing in generale, just need to keep simple the structure. I prefer to create a service class and methods to process the data structure. And one thing i can do this in c# but not sure in typescript, i suggest to keep separate types for api surface and internal layer. In the c# we can prevent people to access internal structure.
Dont get me wrong, encoding errors in the type system is good, but every time I read an article like this I can't help but laugh how this will be used of what not to do when effects become more mainstream Which makes sense. The good part of embedding errors in the type system isn't really being in the type system, its being compiler checked. In the limit, confounding data and control flow is cumbersome to say the least, even computer science theory aside, its natural to assume those two axis should be independent
Nice article. I also the same pattern in C#. The recently added closed keyword means we no longer need a default "impossible" value in a pattern match too.
Good techniques, wrong title. Everything here is about how to encode design decisions once you already have them. Sum types and exhaustive matching are the recording medium. The design itself happened earlier, when somebody worked out that an order can be pending, shipped, or cancelled and never two of those at once. That earlier part is what I'd call bedrock. You get it by sitting with the problem and with the people who live in it every day, writing the concepts down until they hold together. I spent a lot of years shipping line-of-business systems, and the ones that went sideways never failed because someone picked a boolean where a sum type belonged. They failed because nobody understood the domain well enough to know what the states were in the first place, and no compiler was going to catch a state we never knew existed. That's also the clearest divide I know between senior and junior developers. A senior documents first and designs from what the homework turns up. Juniors go straight to code. I'd file DRY, SOLID, and the rest of the rule catalogs under the same heading. They're rules of construction. Useful, but they operate on a design that already exists. A roadmap of structures isn't design, it's carpentry. Bone/EvilGenius