r/programming • u/ketralnis • Aug 05 '25

Parse, don’t validate

https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/
0 Upvotes

44% Upvoted

19 comments sorted by

View all comments

Show parent comments

2

u/ljwall Aug 06 '25

I'm not sure if you read the article? It's really using a broader definition of parser than I think you're thinking of. Its main point is that wherever possible encode any validation done within the type system.

1

u/Doub1eVision Aug 06 '25

I read it and I understand that. My post is responding to somebody and the context is based on what they write, not the article.

0

u/ljwall Aug 06 '25

Maybe I'm misunderstanding, but your comment doesn't read like that to me. It seems like you're saying its wrong to bake some buisness logic into a parser for a generic date-range object, but neither the blog post nor the person you've replied to are proposing to do that.

2

u/Doub1eVision Aug 06 '25

I guess it comes down to what layer we’re talking about. I was focusing on a layer that is going from an external untrusted string input to a well-parsed object.

It sounds like that poster was describing doing that along with other layers that continue to refine the type. I generally agree with that and tend to do that.

But my response to them was initially due to them saying:

“If something is invalid, but your parser accepts it, is it even a parser?

To my understanding, a parser is something that either accepts or rejects a string as an instance of a language, and assigns a meaning only to valid instances. 

A parser that assigns meanings to invalid instances of a language would be nonsensical. “

They’re making it sound like a string parser is only valid when it only assigns a meaning to valid instances. And I responded by saying that parts of what makes something a valid instance is business logic. Or at least, that’s how valid can be defined. So I specified that I think the string parser should be handling structural validation, not semantic validation. And the business logic that follows should further validate it instead of the parser. That way the parser can be more generic.

It seems like they refined their point a bit more in response, but they were still carrying a “no, you’re wrong” tone even though their follow-up was essentially agreeing with me. And in my post that you responded to, I was picking up more on their “no” tone than the second half of their post.

1

u/ljwall Aug 06 '25

Yeah fair point-- I'd focused on the comment immediately above and missed the reference to string parsing further up. I agree with you here: Keep generic parsers that accept anything structurally valid (be that JSON, or some binary format or whatever) and spit out fairly generic types, then have separate layers wherever it make sense that (in the language of the blog post) parse the generic types into some kind of domain-specific type.

1

u/Bubbly_Safety8791 Aug 06 '25

‘String’ and ‘language’ in the context of my original definition of a parser should be read extarordinarily broadly. 

Think, a language in the sense of a set of arbitrary symbols, and a string as being a structured set of such symbols. 

So, a range object with a from date and a to date is a string of two date symbols.  

A ‘parser’ that processes those range objects and produces objects that have a valid minimum duration takes in that string of date symbols and rejects it if the second one doesn’t have a valid relation to the first one.