Comment by mrkeen

Comment by mrkeen a day ago

It's the parse-versus-validate hill in this case.

This pseudocode is "Validate" for at least 3 reasons:

Forgetting to check:

  this check is fragile: it’s extremely easy to forget. Because its return value is unused, it can always be omitted, and the code that needs it would still typecheck.

Repeatable/redundant checks:

  First, it’s just annoying. We already checked that the list is non-empty, why do we have to clutter our code with another redundant check?

  Second, it has a potential performance cost. Although the cost of the redundant check is trivial in this particular example, one could imagine a more complex scenario where the redundant checks could add up, such as if they were happening in a tight loop.

Not using the type system:

  Use a data structure that makes illegal states unrepresentable. Model your data using the most precise data structure you reasonably can. If ruling out a particular possibility is too hard using the encoding you are currently using, consider alternate encodings that can express the property you care about more easily. Don’t be afraid to refactor.

> How do you know PARSE_ERROR is not email_t

It has to be for it to compile, right? Which means that email_t is the type which represents both valid and invalid emails. How do you know if it's valid? You remember to write a check for it. Why not just save yourself some keystrokes and use char* instead. This is validate, not parse.

lmz 21 hours ago

> It has to be for it to compile, right? Which means that email_t is the type which represents both valid and invalid emails. How do you know if it's valid? You remember to write a check for it. Why not just save yourself some keystrokes and use char* instead. This is validate, not parse.

I feel this kind of fundamentalism is letting the perfect be the enemy of the good.

Reply View 3 replies

mrkeen 21 hours ago

Every C programmer is already doing it the 'good' way (validation), so this article doesn't really add anything.
The only fundamentalism involved in PdV is: if you have an email, it's actually an email. It's not arbitrary data that may or may not an email.
Maybe you want your emailing methods to accept both emails and not-emails in your code base. Then it's up to each method to validate it before working on it. That is precisely what PdV warns against.

Reply View | 2 replies
- lmz 20 hours ago
  
  You don't think there's a degree of difference between (valid email_t or null) and (valid char pointer or invalid char pointer)?
  
  Reply View | 1 reply
  
  mrkeen 17 hours ago
  
  There's a huge difference. One is an email_t to validate and one is a char* to validate.
  As established, head is partial because there is no element to return if the list is empty: we’ve made a promise we cannot possibly fulfill. Fortunately, there’s an easy solution to that dilemma: we can weaken our promise. Since we cannot guarantee the caller an element of the list, we’ll have to practice a little expectation management: we’ll do our best return an element if we can, but we reserve the right to return nothing at all. In Haskell, we express this possibility using the Maybe type
  ^ Weaken the post-condition. In some contexts null might be close enough for Maybe. But is Maybe itself even good enough?
  Returning Maybe is undoubtably convenient when we’re implementing head. However, it becomes significantly less convenient when we want to actually use it! Since head always has the potential to return Nothing, the burden falls upon its callers to handle that possibility, and sometimes that passing of the buck can be incredibly frustrating.
  This is where the article falls short. It might be good (the enemy of perfect), but it ain't PdV.
  
  Reply View | 0 replies