Hola Habr!
Les traigo a su atención una traducción del artículo "
Tres paradigmas " de Robert C. Martin (tío Bob).
En los últimos 40 años, las tecnologías de hardware han aumentado la potencia informática de nuestros dispositivos en más de veinte órdenes de magnitud. Ahora jugamos a Angry Birds en nuestros teléfonos, que tienen el poder de procesamiento de una supercomputadora refrigerada por freón de los años 70 del siglo pasado.
Pero durante los mismos 40 años, la tecnología de software no ha cambiado mucho. Al final, todavía usamos los bucles if, while y operadores de asignación que usamos en los años 60. Si tomé un programador de 1960 y lo traje aquí para que pudiera sentarse en mi computadora portátil y escribir código, le tomaría 24 horas recuperarse de la conmoción, pero podría escribir este código. Los principios no han cambiado tanto.
En el proceso de escribir programas, tres cosas han cambiado. No estoy hablando de hardware, ni de la velocidad de la computadora, ni de las increíbles herramientas que tenemos. Me refiero al código en sí. Tres cosas han cambiado en el código. Puedes llamarlos paradigmas. Y todos fueron "descubiertos" hace más de una década, hace más de 40 años.
* 1968 -
Programación estructural .
Edsger Dijkstra escribió su artículo: "Sobre los peligros del operador Ir a" y una serie de otros documentos y artículos que proponen abandonar el enfoque Ir a desenfrenado, reemplazándolo con herramientas tales como if / then / else y while loops.
* 1966 -
Programación orientada a objetos .
Ole-Johan Dahl y
Kristen Nyugor , que estudian el lenguaje
Algol , "descubren" objetos y crean el primer lenguaje orientado a objetos, Simula-67. A pesar de que este logro tiene muchas perspectivas, no ha traído ninguna característica nueva a nuestro código. Además, eliminó uno. Después de todo, con la llegada del polimorfismo, la necesidad de punteros a las funciones desapareció, pero en realidad desapareció.
* 1957 -
Programación funcional .
John McCarthy crea Lisp, el primer lenguaje funcional. Lisp se basó en
el cálculo lambda creado por Alonzo Church en los años 30. Aunque hay muchas perspectivas para la programación funcional, hay una gran limitación en todos los programas funcionales. No usan la asignación.
Tres paradigmas Tres limitaciones La programación estructural establece las reglas para la transferencia de control directo. La programación orientada a objetos introduce reglas para la transferencia indirecta de control. La programación funcional introduce restricciones en la asignación. Todos estos paradigmas han quitado algo. Ninguno de ellos agregó nuevas características. Cada uno de ellos tiene mayores requisitos y menores oportunidades.
¿Podemos crear otro paradigma? ¿Hay algo más que se pueda eliminar?
Durante 40 años no ha habido un nuevo paradigma, por lo que quizás sea una buena señal de que no hay nada más que buscar.
¿Deberíamos usar todos estos paradigmas, o podemos elegir?
Con el tiempo, decidimos implementarlos. La introducción de la primera programación estructurada fue posible gracias a la abolición del principio Ir a (como lo recomendó Dijkstra en su artículo). OOP se ha implementado con éxito reemplazando punteros con funciones en nuestros lenguajes modernos usando polimorfismo (por ejemplo, Java, C #, Ruby). Por lo tanto, al menos para estos dos, la respuesta a esta pregunta es que DEBEMOS usarlos. Todas las demás opciones fueron excluidas o al menos severamente limitadas.
¿Pero qué pasa con la programación funcional? ¿Deberíamos usar idiomas que no tienen un operador de asignación? Probablemente si! Ya estamos escribiendo código que debería funcionar bien en varios núcleos, y estos núcleos se multiplican como conejos. Mi laptop tiene 4 núcleos. El próximo probablemente tendrá 8. El que está después de 16. ¿Cómo va a escribir un código confiable con los procesadores 4096 que luchan por el derecho de acceso al autobús?
Difícilmente podemos conseguir que funcionen dos hilos paralelos, sin mencionar los procesadores 2 ^ n.
¿Por qué la programación funcional es una parte importante para resolver este problema? Debido a que tales programas no usan asignación, lo que significa que no tienen efectos secundarios y, por lo tanto, no tienen problemas asociados con la capacidad de actualización, al menos esa es la teoría.
Hablaremos más sobre programación funcional en futuros blogs. Lo que me sorprende de los tres paradigmas mencionados anteriormente son sus fechas. Son antiguos, casi mayores que yo. Y desde que cumplí 16 años, hace 42 años, no ha habido nuevos.