¿Es OOP el modelo de programación dominante en el mundo real?

¿Los objetos nunca? Bueno, casi nunca

En la sección PUNTO DE VISTA de Comunicaciones de The ACM, encontré un artículo interesante titulado "¿ Objetos nunca? Bueno, casi nunca ". Es una perspectiva radicalmente diferente a la de los objetos primero u objetos tardíos. Sugiere "objetos-nunca" o tal vez "objetos-escuela de posgrado".

El autor habló sobre OOP e hizo una pregunta sobre cómo se usa OOP en entornos de programación del mundo real. Él piensa que OOP no es el modelo de programación dominante. Por ejemplo, afirma, el 70% de las programaciones se realizan para sistemas embebidos donde la POO no es realmente adecuada.

Cuando algunos profesores en las universidades quieren hablar sobre los beneficios de la OOP, hablan sobre la reutilización de códigos. Como otro ejemplo, nuevamente, afirma, este no es el caso real en el mundo real. La reutilización de códigos es más difícil de lo que se afirma en las universidades:

Afirmo que el uso de OOP no es tan frecuente como la mayoría de la gente cree, que no es tan exitoso como afirman sus proponentes y, por lo tanto, que su lugar central en el plan de estudios de CS no está justificado.

¿Es interesante para mí saber cómo piensan las personas en el desbordamiento de pila sobre esto? ¿Es OOP el modelo de programación dominante desde el punto de vista de los programadores?

Si debo elegir / aprender / usar solo un enfoque, ¿es POO o no? ¿por qué?

En la sección PUNTO DE VISTA de Comunicaciones de The ACM

Si está interesado en la programación práctica , los procedimientos de ACM y similares son la última fuente que desea leer. Estas son a menudo publicaciones [pseudo] científicas sin aplicación en el mundo real. Estas son opiniones a menudo poco ortodoxas hechas para publicidad, para que el escritor se diferencie de la multitud y promueva a su propia persona.

Afirmo que el uso de OOP no es tan frecuente como la mayoría de la gente cree, que no es tan exitoso como afirman sus proponentes y, por lo tanto, que su lugar central en el plan de estudios de CS no está justificado.

Tiendo a estar en desacuerdo con tu punto. OOP está muy extendido y funciona bien. Por el número, los proyectos basados ​​en OOP probablemente han superado los desarrollos realizados con otras estrategias (hablemos de los tiempos modernos, 15-20 años).

Sin embargo, la POO no es una bala de plata. Funciona para algunos desarrollos, no funciona para otros. Como cualquier otro enfoque.

Pero una cosa que debo mencionar es que un plan de estudios debe comunicar el conocimiento de diferentes enfoques. Si está basado en OOP, está mal. Si está basado en FP, está mal. Debería cubrirlos a todos o no tocar este tema por completo.

PD ¿Por qué preocuparse por lo que es dominante y lo que no? Simplemente tome lo que sea adecuado para el proyecto en cuestión y deje los números a los "investigadores".

Si OOP es el único paradigma que conoce, tal vez debería aprender más. Pero realmente, ¿qué significa realmente la POO? ¿Significa Java o C ++? ¿Significa Smalltalk? ¿Significa ranuras y cierres de valores configurables? (Hola, Scheme!) ¿Significa enviar mensajes? (Hola, Erlang!)

En resumen, parece una pregunta poco interesante. "¿OO es útil ?" Es una mejor pregunta. Y, bueno, eso parece. (Ciertamente es para mí).

¿Dónde están todos los desarrolladores haciendo ese "70% de las programaciones"? De todos los desarrolladores que conozco, menos del 1% están trabajando en sistemas embebidos.

Entonces, tenemos 3 opciones:

1. Soy único y todos tus amigos realmente hacen programación integrada
2. Hay ejércitos de desarrolladores encerrados en un sótano que hacen el 70%
3. esta estadística está hecha y el artículo es una mierda

a menos que vea alguna evidencia de que las opciones 1 o 2 son realmente verdaderas, voy con la opción 3.

(Por cierto, no considero la programación integrada de desarrollo móvil moderno, y el desarrollo móvil a menudo es OO, después de todo Apple te obliga a usar * Objective * C para desarrollar para el iPhone)

No tengo hechos para seguirlo, pero OOP no es el modelo de programación dominante. Imagínense todas esas aplicaciones internas desarrolladas por alguien que tomó un curso básico visual o realizó alguna programación macro en Excel.

Muchas aplicaciones solo están haciendo una programación imperativa donde toda la lógica se acumula en una sola clase o vista. Esta es probablemente la gran mayoría de las aplicaciones simples internas que se ejecutan en todas las empresas.

No hay nada de malo en eso, hay varias formas de resolver el mismo problema. Algunos más adecuados que otros.

Además, como señaló, OOP no es útil para todos los escenarios. También hay otros modelos.

Si OOP es o no el modelo de programación dominante es irrelevante, simplemente ponga diferentes modelos para diferentes casos.

No hay bala de plata.

Lo que Moti Ben Ari está discutiendo es una afirmación académica, que ya no tiene sentido. Sin embargo, él mismo afirma que nunca encontró que OOP "tuviera sentido", claramente lo hace para miles de desarrolladores e ingenieros de software y se ha utilizado en muchos sistemas ...

Pero, en realidad, el punto de mi respuesta es este: ¿de qué sirve afirmar que un modelo u otro es dominante o no, entonces es una buena razón para usarlo ciegamente? Por supuesto que no lo es.

Esta es realmente una pregunta difícil de responder de manera confiable. La razón más importante es la gente como yo, que trabaja en aplicaciones internas personalizadas, donde el código nunca sale de nuestro edificio. ¿Usamos OO aquí? No estoy diciendo. ¿Cuántos otros programadores tienen trabajos similares? Ellos tampoco lo dicen. Tenemos sitios de trabajo, pero no todos los trabajos se publican, y no todos los anuncios son para trabajos reales en lugar de reclutadores que intentan recopilar listas de nombres.

Incluso si dije que usamos OO donde trabajo, ¿eso significa la definición tradicional del artículo vinculado: Objetos, Clases, Herencia? ¿O significa que uso objetos principalmente como un medio para organizar el código? ¿O significa que realmente solo programo interfaces y apenas uso la herencia? Todavía no lo digo, pero ¿cuál de estos realmente cuenta como OO?

Ni siquiera tiene sentido preguntar si OO es útil hasta que las preguntas anteriores hayan sido respondidas, y mucho menos dominantes.

Por supuesto que sí, porque es la última palabra de moda a la que se ha aferrado la gerencia. También ofrece una mejor encapsulación y abstracción que la programación imperativa, por lo que creo que el salto de oop a lo que viene a continuación podría llevar incluso más tiempo que el imperativo de oop.

PS2: si debo elegir / aprender / usar solo un enfoque, ¿es OOP o no? ¿por qué?

Si solo vas a aprender uno, debes elegir un campo diferente.

Debería aprender sobre los tipos y la encapsulación y todos los otros beneficios de OOP, y luego aprender cómo lograr esas mismas cosas usando un estilo funcional de programación.

OOP es definitivamente uno de los modelos de programación más dominantes en el mundo real.

Seamos realistas, incluso las personas que diseñan hardware digital, los propios diseñadores de chips, están haciendo una transición al dúo de SystemVerilog y SystemC. Estos son lenguajes de programación orientados a objetos.

¿Dónde no se utilizaría OOP? Bueno, si está codificando controladores de dispositivos, es difícil imaginar por qué necesitaría una programación genérica o una herencia múltiple O si está haciendo técnicas de programación funcional de IA lo hace mucho más fácil. Hay muchas otras situaciones también, basta decir que OOP es un lugar bastante poderoso para estar en un mundo de programación oligopolista.

Yo diría que no.

Entiendo que hay una gran cantidad de código que está escrito usando un lenguaje 'orientado a objetos', pero generalmente encuentro que el código es solo de procedimiento envuelto en clases. (No es que esto sea necesariamente algo malo). El código que he visto que está escrito para ser más OO en estos idiomas tiende a ser un horrible desastre de dependencias entre clases que generalmente no se puede mantener.

Se supone que OO se trata de pasar mensajes entre objetos completamente independientes, y lo vemos en el código de hoy, pero a un nivel mucho más amplio, es decir, vemos estos objetos implementados como dlls o ensamblados u objetos COM. 'Componentes' Los he escuchado descritos como.

Por lo tanto, creo que realmente no importa si se usa OO o no: si el código se puede mantener durante su vida útil, reutilizable en la medida en que fue diseñado y rápido de desarrollar, entonces no me importa si es puramente procesal o semi-orientado a objetos o totalmente orientado a objetos. Dudo que alguien pueda decirte si el estilo predominante es cualquiera de estos, pero me arriesgaría a adivinar que el estilo de procedimiento será el más común, incluso si está dividido en clases en lugar de funciones.

Creo que es importante diferenciar una solución obtenida aplicando un Enfoque Orientado a Objetos y una solución implementada USANDO el Paradigma Orientado a Objetos. Mi opinión sobre una buena pieza de software de orientación a objetos es combinar ambas soluciones. Si piensa en objetos y respeta las definiciones e interacciones de los objetos, y su problema podría adaptarse para usar esta estructura, entonces tendrá un código que es flexible y robusto. Pero si usa objetos para resolver un código usando un paradigma de procedimiento, terminará con una mezcla desagradable que no se aprovechará de los profesionales de Objetos.

Realmente prefiero que mi código esté orientado a objetos, y me he dado cuenta de que al principio podría ser un poco más molesto crear una buena estructura, pero cuando se trata de la flexibilidad y los requisitos de flash del cliente de hoy, creo que vale la pena esfuerzo.

No pretendo saber los números exactos, ni siquiera hacer una suposición aproximada, pero hay muchos proyectos de programación que no involucran OOP. Yo trabajo con robots industriales. Los programas tienden a ser un código de procedimiento bastante simple y directo. El sistema operativo real del robot lo es aún más.

Muchas de nuestras "herramientas" que utilizamos están basadas en OOP, pero se ejecutan en PC y no en el controlador del robot. Estos incluyen editores, simulaciones y utilidades.