Funciones “maybe”

Naturaleza de las funciones “maybe”

• Muchos lectores reconocieron que suelen escribir funciones “maybe” que a veces no hacen nada o devuelven null, y encontraron útil la crítica.
• Otros argumentan que el artículo confunde dos cosas:
  • Funciones cuyo comportamiento está oculto / es inconsistente con su tipo (por ejemplo, no actuar en silencio cuando no se ha iniciado sesión).
  • Funciones que deben fallar a veces (por ejemplo, al analizar, usuario sin sesión iniciada) y, por tanto, no pueden devolver siempre un valor.
• Varios comentaristas creen que el verdadero problema son las firmas de función que mienten y las comprobaciones ocultas de estado global, no la opcionalidad en sí.

Alternativas: excepciones, nulos y opciones explícitas

• Algunos defienden las excepciones para obtener información del tipo “por qué no” en lugar de null, pero otros critican las excepciones porque no son visibles en las firmas de tipo y son fáciles de pasar por alto en los llamadores.
• Hay debate sobre qué es “excepcional”: ¿“el usuario no ha iniciado sesión” es un flujo normal o un error? Las opiniones difieren según el contrato de la función.
• Muchos prefieren tipos de retorno opcionales/nullable explícitos (T | null, Option<T>, estilo TryParse) para obligar a los llamadores a manejar la ausencia.
• Para colecciones, devolver listas vacías en lugar de null está ampliamente favorecido. El patrón Null Object se considera a veces útil, pero peligroso cuando oculta fallos reales.

Sistemas de tipos, mónadas y soporte del lenguaje

• Varios comentarios conectan el tema con “Maybe vs null”, “parse, don’t validate” y la programación orientada a pipeline/railway: modelar el fallo como tipos de primera clase y empujar su manejo hacia arriba en la pila.
• Varias personas señalan que el “Maybe” del artículo es solo un functor (map) y no una mónada completa (le falta flatMap/bind).
• Hay discusión sobre cómo las mónadas/Options se vuelven “contagiosas”: una vez introducidas, muchas funciones deben manejarlas. Los lenguajes con azúcar sintáctico (? en Rust, do-notation en Haskell, optional chaining) lo hacen agradable; en JS/Java/Go puede ser torpe.

Patrones de diseño y estructuración del estado

• Hay una fuerte tendencia a mover las comprobaciones de login/validez a los bordes:
  • Usar parámetros explícitos de sesión/LoggedInUser en lugar de estado global.
  • Asegurar que las funciones que asumen precondiciones reciban argumentos que las codifiquen, evitando el comportamiento “maybe” dentro.
• Algunos ven la proliferación de funciones maybe como una señal de mal diseño del grafo de llamadas y de estado global disperso.

Desacuerdos y pragmatismo

• Algunos rechazan una prohibición absolutista de las funciones maybe, citando patrones como maybeShowReminderDialog como prácticos y DRY.
• Otros enfatizan fallar rápido (crashear o rechazo en tiempo de compilación) para errores del programador en lugar de un manejo defensivo excesivo de maybe.