Cita:
Iniciado por Malenko 
Cuando una persona en lugar de usar un array de 9 posiciones para jugar al tateti/tictactoe/3-en-raya usa 9 variables diferentes....es que efectivamente hay un problema gordo de base.
Podemos llevar esta afirmación un poco más lejos. Los lenguajes OOP nos enseñan que es válido tener estados de los datos que representan situaciones que en la realidad son inválidas o imposibles:
Código C#:
Ver originalvar algunCasillero = new { Marcado = true, Jugador = null };
podríamos meter validaciones para que tire un Exception en runtime, pero el compilador no tiene noción de que este es un estado inválido: si el casillero está marcado, efectivamente tiene relacion con algún jugador, y null no es un valor válido.
En los lenguajes FP, uno puede usar una Discriminated Union para hacer que los estados inválidos sean imposibles de representar:
Código F#:
Ver originaltype Casillero =
| Vacío
| Marcado of Jugador
let algunCasillero = Vacío //Correcto
let otroCasillero = Marcado // Error de compilación
let tercerCasillero = Marcado(null) // Error de compilación
let cuartoCasillero = Marcado(jugador1) // Correcto
Nótese que de ésta afirmación uno puede inferir de inmediato lo siguiente: los lenguajes de programación no son meramente "herramientas". Un lenguaje condiciona la manera de pensar de uno. Cuanto más rico es el lenguaje (o más bien cuanto más rico es el Type System que usemos) mayor es la medida en la que podemos crear abstracciones correctas de los problemas y entidades de la realidad, y sus reglas de interacción. Y uno aprende a identificar casos de uso en el código para estas abstracciones: volviendo de F# a C# me encuentro con situaciones en las que usaría DUs, pero éstas no existen en C#...