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.
|