"Parse, don't validate" through the years with C++
derekrodriguez.dev
"Parse, don't validate" through the years with C++
1–10 of 52 posts
Re: "Parse, don't validate" through the years with C++
#2C++ could use some do-notation
Re: "Parse, don't validate" through the years with C++
#3First thought, assuming that birth year starts at 1900 is bad for a number of reasons; one of which, "process this list of authors and ..."
What about everyone born before 1900?
Re: "Parse, don't validate" through the years with C++
#4Author has used LLMs to generate Java code in C++. It detracts from his point.
Re: "Parse, don't validate" through the years with C++
#5First thought, assuming that birth year starts at 1900 is bad for a number of reasons; one of which, "process this list of authors and ..." What about everyone born before 1900?
It’s a contrived example. And I have to assume the author intended it to be contrived given that he also put an upper bound at 1999 in an article written in 2026 in an industry that skews young.
But the pattern applies regardless of the validation logic.
Re: "Parse, don't validate" through the years with C++
#6[deleted]
Re: "Parse, don't validate" through the years with C++
#7First thought, assuming that birth year starts at 1900 is bad for a number of reasons; one of which, "process this list of authors and ..." What about everyone born before 1900?
Or what if they were born after 1999?
It's just a toy example not a production ready birthday validation library.
Re: "Parse, don't validate" through the years with C++
#8First thought, assuming that birth year starts at 1900 is bad for a number of reasons; one of which, "process this list of authors and ..." What about everyone born before 1900?
Assuming it is necessarily known which is the birth year of anyone assumed to have been in existence is already a big hypothesis if we go in that direction.
Re: "Parse, don't validate" through the years with C++
#9Disregarding the article for a second, has anyone else had the pattern that "parse don't validate" makes sense in object oriented style, but less sense in functional style programming? Like parsing and validating blurs into each other.
Re: "Parse, don't validate" through the years with C++
#10Disregarding the article for a second, has anyone else had the pattern that "parse don't validate" makes sense in object oriented style, but less sense in functional style programming? Like parsing and validating blurs into each other.
In my experience it makes even more sense in functional programming languages, not less, since they usually also have more powerful type systems that help with actually representing parsed vs unparsed data.