Seguimos con el Maybe.
Este tipo "Maybe" es bastante útil, pero tiene sus límites. Los principiantes tienden a entusiasmarse con "Maybe" y a usarlo en todas partes, aunque un tipo personalizado sería más apropiado.
Por ejemplo, supongamos que tenemos una aplicación de ejercicios en la que competimos contra nuestros amigos. Se empieza con una lista de nombres de amigos, pero se puede cargar más información de fitness sobre ellos más adelante. Podrías tener la tentación de modelarlo así:
type alias Friend =
{ name : String
, age : Maybe Int
, height : Maybe Float
, weight : Maybe Float
}
Toda la información está ahí, pero no estás modelando realmente el funcionamiento de tu aplicación. Sería mucho más preciso modelarlo así:
type Friend
= Less String
| More String Info
type alias Info =
{ age : Int
, height : Float
, weight : Float
}
Este nuevo modelo captura mucha más información sobre tu aplicación. Solo hay dos situaciones reales. O solo tienes el nombre, o tienes el nombre y mucha información. En el código de tu vista, simplemente piensa si estás mostrando una vista Less o More del amigo. No tienes que responder preguntas como "¿qué pasa si tengo la edad pero no el peso?". ¡Eso no es posible con nuestro tipo más preciso!
La cuestión es que, si usas Maybe en todas partes, vale la pena examinar las definiciones de tipo y alias de tipo para ver si puedes encontrar una representación más precisa. ¡Esto suele dar lugar a muchas refactorizaciones útiles en tu código de actualización y vista!
El inventor de las referencias nulas, Tony Hoare, las describió así:
Lo llamo mi error de mil millones de dólares. Fue la invención de la referencia nula en 1965. En aquel entonces, estaba diseñando el primer sistema de tipos completo para referencias en un lenguaje orientado a objetos (ALGOL W). Mi objetivo era garantizar que todo uso de referencias fuera absolutamente seguro, con la comprobación realizada automáticamente por el compilador. Pero no pude resistir la tentación de incluir una referencia nula, simplemente por su facilidad de implementación. Esto ha provocado innumerables errores, vulnerabilidades y fallos del sistema, que probablemente han causado miles de millones de dólares en daños y perjuicios en los últimos cuarenta años.
Ese diseño hace que el fallo sea implícito. Cada vez que creas tener una cadena, podrías tener un valor nulo. ¿Deberías comprobarlo? ¿Lo comprobó quien te dio el valor? ¿Quizás no haya problema? ¿Quizás bloquee tu servidor? ¡Supongo que lo averiguaremos más adelante!
Elm evita estos problemas al no tener referencias nulas. En su lugar, usamos tipos personalizados como Maybe para que el fallo sea explícito. De esta forma, nunca hay sorpresas. Una cadena siempre es una cadena, y cuando ves una cadena Maybe, el compilador se asegurará de que se tengan en cuenta ambas variantes. De esta forma, obtienes la misma flexibilidad, pero sin los fallos inesperados.
