[jmduke]

Agreed with this essay, and I think it rhymes with two others that I've found pretty influential over the past five years:

1. Parse, don't validate (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...)

2. Pipeline-oriented programming (https://fsharpforfunandprofit.com/pipeline/)

In my experience, the "best" code (defining "best" as some abstract melange of "easy to reason about", "easy to modify", "easy to compose", and "easy to test") ends up following the characteristics outlined by the sum of these three essays — strictly and rigorously elevating exceptions/failures/nulls to first-class types and then pushing them as high in the stack as possible so callers _must_ deal with them.

[blowski]

What constitues the "best" code depends on the incidental complexity of the problems you're trying to solve. Great code is when you have just enough of all those things, but have too much or too little and the code is worse.

[jmduke]

You're right, of course — there are parts of my codebase that flagrantly disregard these rules, and did so for good reasons that I don't regret.

But I've found that while "everything is relative and should be situated in the context of the problem you're trying to solve" is a useful truism, it makes for poor praxis. It's hard to improve existing code or develop newer engineers without _some_ set of compasses and heuristics for what "good code" is, and once you develop that set the patterns and strategies for implementing "good code" naturally follows.

[blowski]

I agree, I'd imagine as a senior you have a good sense of what counts as good enough. Unfortunately, there are too many would-be seniors justifying horrendous amounts of accidental complexity as "good practice".

[MrMikardo93]

IIRC Rich Hickey says something similar to the "pipeline-oriented programming" piece in his talk about systems: https://www.youtube.com/watch?v=ROor6_NGIWU&pp=ygUccmljaCBoa...

[klysm]

I hold these two essays similarly high in influence for myself. The pipeline/railway oriented programming really made it click about how to use first-class types to deal with error cases elegantly.

Unfortunately, a lot of languages make it difficult to have the compiler enforce exhaustiveness.

[yccs27]

Isn't parsing itself a maybe function?

[mrkeen]

The author has conflated two concepts into "maybe function". Parsing is "maybe" in the sense that the parser will either return your object or fail. But it doesn't have to do any hidden, surprising behaviour like the "if (!loggedIn) {" line in the article.

[zenolove]

A better name might be “sometimes function”

[quaunaut]

No. Maybe functions aren't the result of simply returning different results. It's doing or not doing something, abstracted into a function.

Parsing is determining whether you should do it or not- it's about setting up a boundary from which you never attempt something that would be a maybe.

[cloogshicer]

Parse, don't validate is fantastic. I read it a few years ago and I still think about it quite often.

[begueradj]

Good concepts (although too few text on the slides on the second link)