Barrapunto

Al leer este artículo sentí inicialmente un buen cabreo, porque yo soy ferviente partidario de la Orientación a Objetos. Pero luego he examinado con detalle las referencias, y me da la impresión de que es más una cuestion terminológica.

En el texto de presentación del curso de programación funcional dice, por ejemplo, esto, en cuanto a las ventajas de la FP (traduzco guarramente porque voy con prisa):

"Abstracción: PF hace hincapié en la computación centrada en los datos, con operaciones que actúan sobre estructuras de datos compuestas como un todo, en vez de procesar trozo por trozo. En general, la PF enfatiza el encapsulamiento de tipos abstractos de datos que separan claramente la implementación del interfaz. Se usan los tipos para expresar y reforzar los límites de las abstracciones, aumentando en gran manera la mantenibilidad de los programas, y facilitando el desarrollo en equipo."

¡¡Esto es prácticamente la definición que da Bertrand Meyer de la Programación Orientada a Objetos!! [amazon.com]

De hecho Meyer es totalmente partidario de la programación funcional, lo que pasa es que a ella le añade los tipos abstractos de datos y los "efectos laterales" encapsulados, para poder manejar estructuras de datos complejas, que es lo que no les va bien a los lenguajes funcionales puros. Así que creo que ambos autores (Harper y Meyer) acaban llegando al mismo sitio, aunque desde puntos de partida distintos. En un sistema orientado a objetos escrito con el estilo OO-funcional de Meyer se pueden aprovechar las ventajas de paralelismo de las que habla Harper (y no digamos las de verificación). Ver por ejemplo el esquema "MapReduce" de Google [google.com].

Y por otro lado, no conozco el lenguaje ML [wikipedia.org], que creo que es el que se usa en ese curso, pero por lo que se ve es considerado un lenguaje funcional impuro, porque encapsula efectos laterales. Y seguro que en cuanto tenga que enfrentarse, como decía, a estructuras de datos complejas, acaba incorporando alguna forma de tipos abstractos de datos o clases.

El problema, y ahí probablemente esté yo de acuerdo con esta gente, es que muchísimas personas, cuando piensan en (o enseña) orientación a objetos, no empiezan por los principios de Meyer, sino que se lanzan enseguida a montar gigantescos y retorcidos árboles de herencia y montones de truquitos de polimorfismos, sobrecargas y patrones de diseño, pero sin preocuparse de hacer una buena abstracción de datos y unos interfaces claros. Y los lenguajes post-C++ (incluyendo Java, C#, incluso Python, PHP, y la mayoría de los más usados) no ayudan, con problemas tontos como lo de que una clase no puede tener atributos públicos, todo deben ser funciones (a tomar por saco el concepto de tipo abstracto de datos).

Es decir, más que eliminar la programación orientada a objetos, yo creo que lo que habría que hacer es enseñarla bien...

En java y C# hay atributos públicos, otra cosa es que no se suelan usar porque se considera mala práctica; pero están ahí. En Python y PHP no sé, aunque imagino que también.

En todo caso, ¿por qué no usar atributos públicos va en contra del concepto de tipo abstracto de datos? Que yo sepa, los tipos abstractos de datos se definen precisamente mediante sus operaciones, y las restricciones que tengan/produzcan (precondiciones, postcondiciones, etc.). Los atributos están en una capa de abstracción más baja. Así que no sé muy bien lo que quieres decir con eso.