Maybe Functions

Nature of “maybe” functions

• Many readers recognized they frequently write “maybe” functions that sometimes do nothing or return null, and found the critique useful.
• Others argue the article conflates two things:
  • Functions whose behavior is hidden / inconsistent with their type (e.g., silently not acting when not logged in).
  • Functions that must sometimes fail (e.g., parsing, logged-out user) and therefore can’t always return a value.
• Several commenters think the real problem is lying function signatures and hidden global-state checks, not optionality itself.

Alternatives: exceptions, nulls, and explicit options

• Some advocate exceptions for “why-not” information instead of null, but others criticize exceptions as invisible in type signatures and easy to miss in callers.
• There’s debate over what is “exceptional”: is “user not logged in” normal flow or error? Opinions differ by function contract.
• Many prefer explicit optional/nullable return types (T | null, Option<T>, TryParse-style) so callers are forced to handle absence.
• For collections, returning empty lists instead of null is widely favored. Null Object pattern is seen as occasionally useful but dangerous when it hides real failures.

Type systems, monads, and language support

• Several comments connect the topic to “Maybe vs null”, “parse, don’t validate”, and pipeline/railway-oriented programming: model failure as first-class types and push handling up the stack.
• Multiple people note the article’s “Maybe” is only a functor (map) and not a full monad (missing flatMap/bind).
• There’s discussion of how monads/Options become “infectious”: once introduced, many functions must handle them. Languages with syntax sugar (? in Rust, do-notation in Haskell, optional chaining) make this pleasant; in JS/Java/Go it can be clumsy.

Design patterns & structuring state

• Strong push to move login/validity checks to the edges:
  • Use explicit session/LoggedInUser parameters instead of global state.
  • Ensure functions that assume preconditions take arguments that encode them, avoiding “maybe” behavior inside.
• Some see proliferation of maybe-functions as a sign of poor call-graph design and scattered global state.

Disagreements and pragmatics

• Some reject an absolutist ban on maybe-functions, citing patterns like maybeShowReminderDialog as practical and DRY.
• Others emphasize failing fast (crashing or compile-time rejection) for programmer errors instead of over-defensive maybe-handling.