Por qué Arc no es especialmente orientado a objetos

En este momento existe una especie de manía por la programación orientada a objetos, pero algunos de los programadores más inteligentes que conozco son de los que menos entusiasmo le tienen.

Mi propia opinión es que la programación orientada a objetos es una técnica útil en algunos casos, pero no es algo que deba permear cada programa que escribas. Deberías poder definir tipos nuevos, pero no deberías tener que expresar cada programa como la definición de tipos nuevos.

Creo que hay cinco razones por las que a la gente le gusta la programación orientada a objetos, y tres y media de ellas son malas:

1. La programación orientada a objetos es emocionante si tienes un lenguaje de tipado estático sin cierres léxicos o macros. Hasta cierto punto, ofrece una forma de sortear estas limitaciones. (Ver La Décima Regla de Greenspun.)

2. La programación orientada a objetos es popular en las grandes empresas, porque se adapta a la forma en que escriben software. En las grandes empresas, el software tiende a ser escrito por equipos grandes (y frecuentemente cambiantes) de programadores mediocres. La programación orientada a objetos impone una disciplina a estos programadores que evita que alguno de ellos cause demasiado daño. El precio es que el código resultante está inflado con protocolos y lleno de duplicación. Este no es un precio demasiado alto para las grandes empresas, porque su software probablemente ya estará inflado y lleno de duplicación de todos modos.

3. La programación orientada a objetos genera mucho de lo que parece trabajo. Allá en los días del papel continuo, había un tipo de programador que solo ponía cinco o diez líneas de código por página, precedidas por veinte líneas de comentarios elaboradamente formateados. La programación orientada a objetos es como crack para estas personas: te permite incorporar todo este andamiaje directamente en tu código fuente. Algo que un hacker de Lisp manejaría empujando un símbolo a una lista se convierte en un archivo completo de clases y métodos. Así que es una buena herramienta si quieres convencerte a ti mismo, o a alguien más, de que estás haciendo mucho trabajo.

4. Si un lenguaje es en sí mismo un programa orientado a objetos, puede ser extendido por los usuarios. Bueno, quizás. O quizás puedas hacerlo aún mejor ofreciendo los subconceptos de la programación orientada a objetos a la carta. La sobrecarga, por ejemplo, no está intrínsecamente ligada a las clases. Ya veremos.

5. Las abstracciones orientadas a objetos se mapean limpiamente en los dominios de ciertos tipos específicos de programas, como simulaciones y sistemas CAD.

Personalmente, nunca he necesitado abstracciones orientadas a objetos. Common Lisp tiene un sistema de objetos enormemente potente y nunca lo he usado. He hecho muchas cosas (por ejemplo, crear tablas hash llenas de cierres) que habrían requerido técnicas orientadas a objetos para hacerlas en lenguajes más débiles, pero nunca he tenido que usar CLOS.

Quizás solo soy estúpido, o he trabajado en un subconjunto limitado de aplicaciones. Existe un peligro en diseñar un lenguaje basándose en la propia experiencia de programación. Pero parece más peligroso incluir cosas que nunca has necesitado porque se considera una buena idea.