¿Cuáles fueron algunos de los factores económicos (y otros factores históricos) que llevaron a que los lenguajes de programación orientados a objetos se volvieran influyentes? Sé que Simula comenzó las cosas, pero ¿fue la adopción de lenguajes OOP debido a las necesidades cada vez mayores de las empresas? ¿O la adopción se debió más a las nuevas cosas que se podían hacer con los lenguajes OOP?
Editar Estoy realmente interesado en saber si hubo algunos factores externos a los propios idiomas que les permitieron establecerse.
technology
programming-languages
ihtkwot
fuente
fuente
Respuestas:
Respuesta corta
Creo que fue la rotación de proyectos de software antes de los días de OO. OO ayudó agregando el concepto fundamentalmente crítico: modelar el mundo real .
El primer lenguaje de programación orientado a objetos fue Simula en 1967. Sin embargo, en ese momento el desarrollo de software en general todavía estaba en los laboratorios y la mayoría de los paradigmas aún estaban más cerca del caso del hardware .
Durante una década más, el desarrollo de software para aplicaciones empresariales creció en otras aplicaciones comerciales y el desarrollo de software en general se recuperó durante toda la década de 1970. Las lenguas que aún sobreviven hoy en día (antes de 1980) fueron C, Cobol, Fortran y otras similares. La mayoría de estos idiomas son de procedimiento. Lisp también existió desde ese día, sin embargo, no estoy seguro si ese fue un lenguaje prominente de propósito general para el desarrollo comercial. El famoso término Modelo de cascada también fue acuñado a principios de la década de 1970.
En la mayoría del entorno comercial, el elemento más importante que surgió en el desarrollo de software fue la gestión de proyectos. Hubo una gran necesidad de presupuestos ajustados y al menos predecibles y requisitos de gestión para congelar para garantizar que el proyecto llegue a la meta de manera respetable. Durante este período también fue uno de los Manmonios Míticos en 1975.
Supongo que a finales de los años 70 la gente estaba agotada, ya que los lenguajes de procedimiento no cumplían con esas promesas. Y un nuevo paradigma orientado a objetos que existió desde entonces lo hizo grande. Aunque la gente puede estar en desacuerdo, creo que el C ++ que ayuda a la familiaridad y la experiencia comprobada y de C, y la orientación Promesa de Objeto (originalmente con el nombre C con Clases) en 1983 fue una piedra angular para el éxito de la programación orientada a objetos.
Alguna referencia para más perspectiva: http://journal.thedacs.com/issue/43/88
Entonces, ¿por qué OO?
Creo que esos días (si nos fijamos en el punto de vista del éxito del proyecto), tenía sentido que lo que puede entender mejor sea mejor manejable. La metodología orientada a objetos con una promesa "... todo en la vida es un objeto" parecía más un sentido común incluso antes de que se demostrara que era significativo. El éxito práctico de este factor fue la noción misma de modelar suficientemente el mundo real y el problema en cuestión antes de saltar el arma, lo que creo que es algo fundamentalmente nuevo que OO ofreció y que ningún otro paradigma ofreció hasta esa fecha. Y definitivamente dado que este paradigma te obligó a pensar un poco antes de codificar más que los lenguajes de procedimiento, ¡mostró un éxito visible en los proyectos de software que emplearon y desde entonces se dieron cuenta!
EDITAR
También agregaría que los lenguajes de programación evolucionaron simultáneamente en paralelo a tales conceptos fundamentales (paradigma OO, Aspecto, Máquinas virtuales,) Cada nuevo concepto y pensamiento nuevo surgieron solo cuando un nuevo lenguaje de programación nuevo lo dominó: mantén solo la familiaridad pero cambia los fundamentos de ¡núcleo! Al mismo tiempo, estos nuevos conceptos y nuevos lenguajes solo surgieron debido a nuevos problemas comerciales. 1980 - OO para software a gran escala, 1990 Java en la era de Internet, PHP / ASP y muchos otros para la web. La innovación en los lenguajes de programación también se debió principalmente a la necesidad discontinua del mercado.
En resumen, a principios de los años 80, la era en la que despegaba el software comercial a gran escala, mientras que los proyectos con lenguajes de procedimiento tenían sus problemas, OO mostró la mejor luz e hizo que los proyectos fueran más exitosos.
fuente
Customerclase no tiene métodos comoeatLunch,goToWorkosleep, aunque esto es lo que hacen los clientes en el mundo real . LaProductclase tiene varios métodos, aunque la mayoría de los productos no tienen exactamente ningún comportamiento en el mundo real . Por lo tanto, diría que el modelo OO solo corresponde (más o menos) en términos de propiedades, pero no en términos de comportamiento, con el mundo real. Pero no necesita OO para tener un modelo de datos que corresponda a objetos del mundo real. Grabar tipos es todo lo que se necesita.Creo que la razón más importante fue el éxito de las interfaces gráficas de usuario como X y Windows. Una GUI consta de varios objetos que tienen un comportamiento propio, algo que OO puede representar de cerca.
Por otro lado, una interfaz de usuario basada en texto (que no intenta parecerse a una GUI) a menudo simplemente sigue un patrón de respuesta de comando, que puede implementarse fácilmente en un lenguaje de procedimiento. Las reglas de negocios y cosas similares se han implementado con lenguajes de procedimiento durante décadas, sin demasiados problemas, y aún hoy en día muchos programas de OO para aplicaciones de negocios son bastante procesales; con objetos estúpidos que contienen los datos y objetos sin estado que contienen las reglas de negocio; el primero podría ser registros en un lenguaje de procedimiento, el segundo podría ser, bueno, procedimientos.
fuente
Veo OOP como un paso evolutivo natural del código de procedimiento:
Estoy seguro de que alguien con una visión más amplia intervendrá, pero parece que esta fue una progresión natural al permitir que los programadores produzcan código más rápido: es decir, permitir una mayor reutilización del código.
Desde este punto de vista, el factor externo más importante fue la reducción del costo de la potencia del procesador (en comparación con el costo de mano de obra del desarrollador para crear programas típicos): la sobrecarga informática en el uso de las clases OOP se convirtió en una preocupación menor que el ahorro de tiempo del desarrollador. (Esta misma compensación de gasto de CPU versus gasto de programador ha influido en muchos otros aspectos de la programación).
fuente
Al principio había una programación imperativa (si pudieras llamarlo así). Instrucciones simples que le dijeron al mainframe qué y cómo debería estar calculando. Esos lenguajes de programación usaban saltos incondicionales y otras instrucciones "no estructuradas", la mayoría de ellas exóticas para los estándares actuales.
Entonces a alguien se le ocurrieron estructuras para la programación. El for, while, do while y foreach que conocemos hoy. Fue una gran innovación ya que ahora las aplicaciones con un flujo relativamente complejo podían escribirse y entenderse fácilmente. Así nació la programación estructurada.
Luego vinieron otras personas que dijeron que necesitabas repetir un montón de código aquí y allá y que era una pesadilla mantenerlo, por lo que debería inventarse una forma de reutilizar el código. A la gente se le ocurrieron procedimientos y funciones para delimitar bits de código reutilizables. Esto también dio origen a los principios de encapsulación y responsabilidad única.
Luego, algunos académicos dijeron que la funcionalidad debería estar estrechamente relacionada con los datos en los que está trabajando. Luego agregaron los conceptos de herencia para la reutilización de código y el polimorfismo para que coincida con la forma lógica en que funcionó la clasificación en la vida real. Así nació la tercera generación de lenguajes de programación y OOP.
fuente