Resumen de conceptos vistos

Vamos a anotar algunos conceptos que nos parece importante que se lleven de la materia, algunos son propios de algún paradigma, pero otros son cross:
  • declaratividad: la posibilidad de utilizar un motor para no tener que pensar la solución + el algoritmo (all de funcional y objetos, forall de lógico)
    • sabemos que no tiene que ver con la expresividad, aunque en la cursada hemos batallado mucho para que le pongan nombres representativos a las variables y a las abstracciones
  • variables, como
    • puntero a un espacio en memoria (cerca del algoritmo, concepto conocido)
    • argumento de una función (concepto matemático de que un hecho depende de otro)
    • referencia a un objeto
    • o una incógnita que se resuelve en las consultas
  • abstracción, un concepto fundamental a lo largo de toda la cursada. Las abstracciones permiten poner nombres a los conceptos que el cliente conoce, ese proceso se llama reificación
    • en funcional tenemos las funciones, los tipos de dato definidos por el usuario (incluso los nombres de los constructores, fíjense que la tupla es más general pero no permite reificar el concepto, yo tengo que entender que (String, Int) representa el nombre del alumno y la nota.
    • en lógico tenemos los predicados, y los functores que sí permiten dar un nombre a lo que representan.
    • en objetos podemos modelar muchas abstracciones: un objeto, una clase, el nombre de una referencia, un método, entre otras
  • polimorfismo, como una forma de bajar el acoplamiento entre componentes....
    • en funcional, porque me sirve para no repetir length para listas de enteros, de decimales o de Strings
    • en lógico, asociado al pattern matching con functores, para generar definiciones posteriores utilizando nuevos tipos de dato
    • en objetos, porque permite enviar un mensaje a un objeto sin conocer la implementación, lo que permite definiciones posteriores
  • pattern matching
    • concepto fundamental en Funcional que permite reemplazar al mecanismo de selección (if)
    • si trabajan en Scala, verán que ese concepto funcional se puede entremezclar con objetos, el curioso puede ver este blog
    • en lógico el concepto es similar, pero se junta con el concepto de backtracking, lo que permite aceptar varias soluciones.
  • orden superior, que es un concepto poderoso cross-paradigmas que el mercado ya adoptó
    • está claro su implementación en funcional y en lógico: funciones que reciben funciones, predicados que trabajan sobre predicados
    • pero no hay que quedarse con la definición de "abstracción que recibe como parámetro la misma abstracción" sino que lo que está en juego es algo mucho más valioso: tener una abstracción que modele código ejecutable. Por eso lo que hace que Haskell tenga orden superior es su declaración de la función como "first class citizen", es decir, la función es un tipo de dato más, tan tipo de dato como un 2 o "Manuel Belgrano". 
Modelar un bloque de código es algo muy buscado hoy en el mercado (de hecho Java perdió mucha competitividad por retrasar este feature en favor de otros lenguajes que llegaron antes a cubrir este faltante: Ruby, C#, Javascript, Groovy, Scala, Python, entre otros)
Pero ¿por qué es tan importante?
Comparemos estos códigos:

 public void removeAllBlueCars() {
    List<Car> result = new LinkedList<Car>();
    for (Car car : cars) {
        if (car.getCarColor() == Color.BLUE) {
            result.add(c);
        }
    }
    return result;
}
 method removeAllBlueCars() =
      cars.filter { car => car.color == Color.BLUE }

La quinta vez que lo tenemos que hacer, no queremos saber más nada, ¿no?
Y tiene que ver en gran medida con la declaratividad: delegar la respuesta a otro objeto que lo resuelve (en este caso la colección) funciona como una especie de motor. Lo que termina pasando es que el motor es una gran caja negra.

  • Testing: una actividad independiente de la tecnología que elijamos, tenemos que validar nuestra solución de alguna manera. Hemos aprendido que podemos automatizar las pruebas unitarias, hacerlas independientes y repetibles, asociado a esto es la ausencia de efecto
    • en funcional y lógico, trabajamos sin efecto, esto nos causa algunos problemas de acostumbramiento...
    • ...pero después vemos que en objetos también podemos separar métodos con y sin efecto. 
    • Y en la industria también pasa mucho que una buena arquitectura tiene componentes con comportamiento que no tiene efecto (reportes, extracción de información) y comportamiento que necesita efecto (actualización de datos online o batch)
  • No repetición de código, calidad de lo que hacemos como profesionales de un oficio
Y esto no depende de la función que cumplan el día de mañana. Pueden ocupar cualquier puesto, lo que un ingeniero en sistemas no puede hacer es desconocer la tecnología porque el ingeniero toma decisiones, y la parte técnica es una de ellas.
Abrazo de gol.

Comments