21–30 of 52 posts
Disregarding 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.
Parse, don't validate was written around Haskell!
Author has used LLMs to generate Java code in C++. It detracts from his point.
What Java code? Regardless of how they might have used LLMs, I tend to have an issue with this kind of complaint, given the C++ example code on the Design Patterns: Elements of Reusable Object-Oriented Software book, released in 1994, 2 years before Java was made public. Or the examples from "Using the Booch Method: A Rational Approach", "Designing Object Oriented C++ Applications Using The Booch Method", or "Using t…
There's not much mystery about that - Java took that approach and ran with it, and now has much greater mindshare than C++.
Also, the mid-90s were before most software developers working today were born, I suspect. They'd have to go find a graybeard and ask them to tell them tales of yore, to find out about any of this.
Disregarding 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.
> Disregarding 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? Parse, don't validate was written around Haskell!
// There are a few ways to let API callers bring their own
// memory, as they would in a no-malloc environment and this
// stack-friendly c'tor is a stand-in for that.
static Birthdate epoch() { return Birthdate(1900, 1, 1); }C is perfectly capable of type-driven design. He's already got the type (struct), and although C is a bit limited, he can: * return pointer-or-null * choose "invalid" sentinel values and then use birthdate_is_valid(...) to check validity. * Add an is_valid bool field (or even an error enum like in the C++23 example) * Add an out field in the constructor function for the error code (similar to how ObjC does things).
All four of your examples are validate.
Know any languages that are worse than C at this?
Earlier quoted context omitted.
What Java code? Regardless of how they might have used LLMs, I tend to have an issue with this kind of complaint, given the C++ example code on the Design Patterns: Elements of Reusable Object-Oriented Software book, released in 1994, 2 years before Java was made public. Or the examples from "Using the Booch Method: A Rational Approach", "Designing Object Oriented C++ Applications Using The Booch Method", or "Using t…
> Somehow There's not much mystery about that - Java took that approach and ran with it, and now has much greater mindshare than C++. Also, the mid-90s were before most software developers working today were born, I suspect. They'd have to go find a graybeard and ask them to tell them tales of yore, to find out about any of this.
C is perfectly capable of type-driven design. He's already got the type (struct), and although C is a bit limited, he can: * return pointer-or-null * choose "invalid" sentinel values and then use birthdate_is_valid(...) to check validity. * Add an is_valid bool field (or even an error enum like in the C++23 example) * Add an out field in the constructor function for the error code (similar to how ObjC does things).
I don't see how this is in any way preferable to having an ordinary default constructor that does the same thing: // There are a few ways to let API callers bring their own // memory, as they would in a no-malloc environment and this // stack-friendly c'tor is a stand-in for that. static Birthdate epoch() { return Birthdate(1900, 1, 1); }
if (sscanf(user_input, "%4u-%2u-%2u", &year, &month, &day) != 3) {
// return an error
}
if (sscanf(user_input, "%4u-%2u-%2u%c", &year, &month, &day, &dummy) != 3) {
// return an error
}