¿Google Golang aborda los problemas con los idiomas abordados en la publicación de Paul Graham 'Why Arc isn't Especially Object Oriented'?¿El idioma oficial de Google aborda los problemas en la publicación de Paul Graham "¿Por qué Arc no está especialmente orientado a objetos?
Mi sensación inicial hacia este es "Es demasiado pronto para decir"
1) la programación orientada a objetos es emocionante si usted tiene un lenguaje de tipo estático y sin cierres léxicos o macros. Para algunos grados , ofrece una forma de evitar estas limitaciones . (Ver Regla Décima de Greenspun.)
Go es compatible con los literales de funciones (ver docs), que si se me permite la lectura de este correctamente a pasar funciones como parametros, si se define en otro lugar o creado ad hoc.
2) programación orientada a objetos es muy popular en las grandes empresas, ya que se adapte a la forma en que escriben software. En grandes empresas, el software tiende a ser escrito por grandes (y frecuentemente cambiantes) equipos de programadores mediocres . La programación orientada a objetos impone una disciplina en a estos programadores que impide que uno de ellos haga demasiado daño . El precio es que el código resultante está lleno de protocolos y está lleno de duplicaciones. Este no es un precio demasiado alto para las grandes empresas , porque su software es probablemente va a estar hinchado y lleno de duplicación de todos modos.
Este punto es muy subjetivo para responder.
3) programación orientada a objetos genera una gran cantidad de lo que parece ser trabajo. En los días de Fanfold, había un tipo de programador que solo ponía cinco o diez líneas de código en una página, precedido por veinte líneas de comentarios elaboradamente formateados . La programación orientada a objetos es como crack para estas personas: le permite incorporar todo este andamio en su código fuente . Algo que un hacker Lisp podría manejar presionando un símbolo en una lista se convierte en un archivo completo de clases y métodos. Entonces es una buena herramienta si desea convencerse a sí mismo o a otra persona, que está haciendo mucho de trabajo.
Dado que go no es un lenguaje realmente orientado a objetos, probablemente puedas resolver el problema de la forma en que te sientas cómodo.
4) Si una lengua es en sí mismo un programa orientado a objetos, se puede extendida por los usuarios. Bien quizás. O bien, , quizás pueda hacerlo aún mejor al que ofrece los subconceptos de programación orientada a objetos a la carte. La sobrecarga, por ejemplo, es que no está intrínsecamente vinculada a las clases. Ya veremos.
Go parece tener un enfoque interesante para los objetos, donde no es necesario preocuparse/desarrollar grandes árboles de objetos. Parece que las herramientas están presentes en el lenguaje para estructurar sus datos de una manera orientada a objetos sin encerrarlo en un entorno orientado a objetos puros.
5) abstracciones orientadas al objeto de mapa perfectamente en los dominios de ciertas tipos específicos de programas, como simulaciones y sistemas CAD.
...
Go admite funciones de primera clase y de orden superior, así que es genial. Además, es compatible con el tipo de MLs/Haskell/Racket. Lo que personalmente me gusta de Go es que, aunque hay modismos dentro de él, los diseñadores parecen entender que las diferentes situaciones requieren diferentes herramientas, a diferencia de Graham. No me malinterpreten, Graham es increíble. Es solo que discutir sobre modismos de programación es en última instancia infructuoso: se reduce a una discusión sobre herramientas entre artesanos sesgados o entre procesos de pensamiento entre filósofos parciales de lenguaje. – jcc333
Pablo tiene algunos puntos interesantes, en general, he leído muchas de sus reflexiones. En este asunto, no estamos de acuerdo. Él es una tuerca de lisp, y una tuerca de programa horrible. Parece empeñarse en programas difíciles de entender como el trabajo de grandes programadores. Sí, me doy cuenta de que es más matizado que eso, pero realmente se reduce a eso. Al final del día, es fácil trabajar con tu código, o no. Y algunos programadores, programadores que Paul consideraría excelentes, podrán aguantar más basura que otros y aún así ser capaces de entender lo que el código pretende. Es una habilidad, pero seguramente no es la única que necesita un buen programador.
Hablando de Arc, apesta, y a menos que esté equivocado, incluso la gente de la comunidad Lisp piensa que sí, mi punto aquí es que incluso las personas inteligentes cometen errores.
Una vez más, Paul es un tipo inteligente, pero todo su enfoque en esta pieza en particular está fuera de lugar, parece.
Sin embargo, espere, ¿está realmente orientado a objetos? Parece completamente agnóstico en ese frente. Puede usar programación OOP o FP o Imperative dentro de Go. Quiero decir, la "programación" de estilo prólogo sería exagerada, pero por lo demás ...
De hecho, yo diría que Go se parece a Scala en este aspecto: hay algunos paradigmas de objetos por ahí, y sin embargo, hay también lambdas y typecasing por ahí.
Go está orientado a objetos. Utiliza el enfoque de envío genérico a la orientación del objeto, al igual que Common Lisp y Dylan. – PuercoPop
¿Qué problemas? Esa publicación habla de problemas con el uso excesivo de diseños voluminosos orientados a objetos, no problemas con los idiomas. – mquander
@mquander: y realmente la publicación trata sobre las ventajas espúreas más que sobre los problemas. – ctd