Lo que amo de Scala: los tuples

Tengo una relación de amor y odio con los tuples. Los adoro cuando escribo código por primera vez y los odio cuando vuelvo a leer el código más tarde.  Son, por lejos, lo que me hace más difícil entender mi propio código.  Igual los uso a cada rato porque son demasiado prácticos.

En Scala, Java y cualquier lenguaje tipeado es fácil agregar un parámetro de entrada a un método.  Se define el nuevo parámetro y se deja el IDE o el compilador detectar todos los usos del método que fueron quebrados.  Los tuples me permiten exactamente lo mismo pero con el parámetro de salida.

Como ejemplo, 2 versiones de un método supuestamente complejo: evaluación de riesgo de un cliente  La primera versión solamente retorna un boolean que indica si el cliente es demasiado riesgoso
En la siguiente versión, el método calcula el riesgo usando varios criterios y se requiere retornar un mensaje que indica el porque.

Si no existiesen los tuples, tendría que definir una clase para contener el retorno.  A pesar que en Scala, crear un "case class" es rápido, tengo que por lo menos escoger un nombre para la clase.  Y, es en este preciso momento que adoro los tuples: cuando estoy pensando en un algoritmo no trivial mi capacidad creativa para nombrar las clases, objetos y variables tiende a cero.  Si tengo que detener mi pensamiento para nombrar correctamente la clase, evaluar si puedo re-utilizarla en otra situación, si debo hacerla más genérica, etc, pierdo completamente el hilo del algoritmo que estoy resolviendo.  Los tuples son una forma rápida de salirme del paso y enfocarme en la parte "matemática" del problema.

Los tuples son perfectos cuando uso el resultado del método localmente. Los problemas de mantenebilidad surgen cuando tengo que guardar los tuples en alguna colección y procesarla en otra parte del código. Cuando eso ocurre, tengo que hacer un refactoring y por eso los odio.