141–150 of 175 posts
What's lexi up to these days? Her last big contribution to Haskell was the delimited continuation primops, then she disappeared in a puff of smoke.
Hot take: Static typing is often touted as the end all be all, and all you need to do is "parse, don't validate" at the edge of your program and everything is fine and dandy. In practice, I find that staunch static typing proponents are often middle or junior engineeers that want to work with an idealised version of programming in their heads. In reality what you are looking for is "openness" and "consistency", becau…
> no amount of static typing will save you from poorly defined or optimised-too-early types that encode business logic constraints into programmatic types. That's not a fault of type systems, though. > because business logic will move faster than whatever code you can write and fix, and exposing it as just "types" breaks the process for future programmers to extend your program That's a problem with overly-tight coup…
yeah imagine if you could foresee the future five years in advance. People overestimate their ability to use type systems correctly, as shown in your reply here.
Related. Others? Parse, Don't Validate (2019) - https://news.ycombinator.com/item?id=41031585 - July 2024 (102 comments) Parse, don't validate (2019) - https://news.ycombinator.com/item?id=35053118 - March 2023 (219 comments) Parse, Don't Validate (2019) - https://news.ycombinator.com/item?id=27639890 - June 2021 (270 comments) Parse, Don’t Validate - https://news.ycombinator.com/item?id=21476261 - Nov 2019 (230 comm…
Parsix - https://news.ycombinator.com/item?id=27166162
TypeScript - https://news.ycombinator.com/item?id=28425435
C - https://news.ycombinator.com/item?id=44507405
Without comments:
Non-blank strings in Rust - https://news.ycombinator.com/item?id=34947030
Email type in Rust - https://news.ycombinator.com/item?id=34946791
Hot take: Static typing is often touted as the end all be all, and all you need to do is "parse, don't validate" at the edge of your program and everything is fine and dandy. In practice, I find that staunch static typing proponents are often middle or junior engineeers that want to work with an idealised version of programming in their heads. In reality what you are looking for is "openness" and "consistency", becau…
how does this square with very senior people putting in a lot of effort to bolt fairly good type systems onto Python and JavaScript? > business logic will move faster than whatever code you can write and fix, and exposing it as just "types" breaks the process for future programmers to extend your program. I just don't understand how this is the case. Fields or methods or whatever are either there, or they are not. Ty…
You could spend more time understanding Pydantic before you make this comment however.
Hot take: Static typing is often touted as the end all be all, and all you need to do is "parse, don't validate" at the edge of your program and everything is fine and dandy. In practice, I find that staunch static typing proponents are often middle or junior engineeers that want to work with an idealised version of programming in their heads. In reality what you are looking for is "openness" and "consistency", becau…
This is such a tired take. The burden of using static types is incredibly minimal and makes it drastically simpler to redesign your program around changing business requirements while maintaining confidence in program behavior.
Hot take: Static typing is often touted as the end all be all, and all you need to do is "parse, don't validate" at the edge of your program and everything is fine and dandy. In practice, I find that staunch static typing proponents are often middle or junior engineeers that want to work with an idealised version of programming in their heads. In reality what you are looking for is "openness" and "consistency", becau…
> staunch static typing proponents are often middle or junior engineeers While we're sharing anecdotal data, I've experienced the opposite. The older, more experienced fellows love static types and the new ones barely understand what they're missing in javascript and python.
Earlier quoted context omitted.
The crucial design choice is that you can't get a Doodad by just saying oh, I'm sure this is a Doodad, I will validate later. You have to parse the thing you've got to get a Doodad if that's what you meant, and the parsing can fail because maybe it isn't one. let almost_pi: Rational = "22/7".parse().unwrap(); Here the example is my realistic::Rational. The actual Pi isn't a Rational number so we can't represent it, b…
The point is parse and validate are interchangeable words for the most part. If you’re parsing something you expect to be an int, but it’s a float or the letter “a” is that not invalid? Is this assessment a form of validating expectations? The line between parsing and validating doesn’t exist.
Hot take: Static typing is often touted as the end all be all, and all you need to do is "parse, don't validate" at the edge of your program and everything is fine and dandy. In practice, I find that staunch static typing proponents are often middle or junior engineeers that want to work with an idealised version of programming in their heads. In reality what you are looking for is "openness" and "consistency", becau…
You are yet another person who is misguided in exactly the way described in this article by the same author: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ...
:)
Earlier quoted context omitted.
> On your precise exemple, I can even say that I never saw something like an "Email object". Well that's.... absolutely horrifying. Would you mind sharing what industry/stack you work with?
> horrifying. IMO it's worth distinguishing between different points on the spectrum of "email object", ex: 1. Here is an Email object with detailed properties or methods for accessing its individual portions, changing things to/from canonical forms (e.g. lowercase Punycode domain names), running standard (or nonstandard) comparisons, etc. 2. Here is a immutable Email object which mainly wraps an arbitrary string, so…
If it's neither, who cares? This is an obvious nightmare for all involved
Earlier quoted context omitted.
In the spirit of "Parse, Don't Validate", rather than encode "validation" information as a boolean to be checked at runtime, you can define `Email { raw: String }` and hide the constructor behind a "factory function" that accepts any string but returns `Option ` or `Result `. If you need a stronger guarantee than just a "string that passes simple email regex", create another "newtype" that parses the `Email` type fur…
I would still usually prefer email as just a string and validation as a separate property, and they both belong to some other object. Unless you really only want to know if XYZ email exists, it's usually something more like "has it been validated that ABC user can receive email at XYZ address". Is the user account validated? Send an email to their email string. Is it not validated? Then why are we even at a point in…
> Because in those examples you can have a User whose email property is a ParseError and you still end up having to check "is the email property result for this user type Email or type ParseError?"
It's kind of a "oh I forgot to check `email.isValidated`" reminder, except now being presented as an incompatible type assignment and at compile-time. Borrowing Rust's syntax, the type error can be solved with
user.email = Email::parse(raw_string)
.ok()
.and_then(|wellformed_email| {
email_service.validate_by_send_email(wellformed_email)
});
> and it's very similar to just checking a validation bool except it's hiding what's actually going on.
On the other hand, the usual approach of assigning raw string directly doesn't say anything at all about its contract, hiding the contract of `user.email` must be a well-formed, contactable email. Not only it's possible to assign arbitrary malformed "email" string, remembering to check `email.isValidated` is also programmer due diligence, forget once and now there's a bug.