Lo que se hará evidente es que muchas de nuestras percepciones sobre la tecnología están formadas por la publicidad comercial. La realidad es que escribir código hoy es más o menos equivalente a la forma en que se hizo en el pasado. Algunas ligeras diferencias.
Si la narrativa que sigue hace que te haga girar la cabeza, te pido disculpas. La pregunta percibe una narrativa más homogénea sobre la tecnología que va en contra de la situación real de los tiempos. Comienzo con Microsoft ya que su plataforma ofrece una representación clara del estado de las cosas con respecto a las bibliotecas de códigos, los marcos y las herramientas.
Microsoft
- ¿Qué campo de ingeniería es mejor para alguien que quiere desarrollar software o construir productos electrónicos como ventiladores eléctricos, auriculares, ratones y teclados?
- ¿Cuáles son algunas malas experiencias que ha tenido con la gestión del desarrollo de software?
- ¿Cómo funciona Squwaka (o cualquier otro software que proporcione actualizaciones de fútbol en tiempo real)?
- ¿Cuál es la diferencia entre las técnicas de prueba de software y las estrategias de prueba de software?
- ¿Cuál es el consejo de Adam D'Angelo para ingenieros de software principiantes?
En el mundo de Microsoft, el Modelo de objetos componentes era una gran cosa. En relación con los detalles de la pregunta sobre la falta de marcos / bibliotecas, muchos existían basados en COM. Microsoft tenía muchas bibliotecas basadas en COM. Docenas de compañías de terceros vendieron bibliotecas de códigos.
Una de esas compañías fue ComponentSource. A menudo anunciaban bibliotecas de códigos destacados en revistas impresas. Si compró una revista que hablaba sobre desarrollo de software o publicaciones como Computer Shopper o PC Magazine, es posible que haya visto anuncios de diferentes compañías que venden bibliotecas de códigos. Algunas de las revistas tecnológicas ya no están impresas. Otros han realizado una transición total a entornos web y móviles. Empresas como ComponentSource todavía están activas en el suministro de bibliotecas que se remontan a la década de 1990 en términos de origen. Intente una búsqueda en su sitio web como ocx o leadtools para hacerse una idea.
Curiosamente, Microsoft todavía tiene COM fuerte en el resurgimiento de esa tecnología en forma de Windows Runtime y C ++ / CX. Menos resurgimiento y más énfasis selectivo donde tiene sentido. Una de las ventajas del uso continuo de COM es que muchas de las bibliotecas de código y los marcos que se originaron en la década de 1990 se pueden unir con implementaciones más nuevas de COM y enfoques que usan C ++ / CX en la plataforma Windows.
Bajo el paraguas del uso de la tecnología de Microsoft, una gran diferencia entre entonces y ahora son los materiales de referencia. En ese momento tenía manuales y libros de referencia, mientras que hoy tiene una herramienta llamada Microsoft Help Viewer, así como varios sitios web en línea. Hoy en día, encontrar información es más rápido, pero el enfoque general para la información de referencias cruzadas para una tarea de desarrollo de software sigue siendo el mismo.
Otros entornos siguieron un curso similar. Consulte la respuesta de Andy Dent para obtener más detalles, incluidos entornos como Apple.
Muchos idiomas entonces y ahora
La pregunta se pregunta sobre la pluralidad de lenguajes de programación en la década de 1990. Determinar qué idiomas eran más populares puede ser difícil ya que algunos idiomas se comercializan con más fuerza que otros. Muchos de los que se enfatizaron aún más aún sobreviven en términos de uso convencional. Otros que tuvieron un uso fuerte pero que se discutieron menos abiertamente volvieron a la corriente principal.
Si observa la línea de tiempo de los lenguajes de programación, desglosada por año, verá 62 idiomas para la década de 1990. La lista está un poco fuera de lugar, ya que algunos lenguajes como ActionScript que se muestran para el año 2000 estaban realmente disponibles años antes. Quizás un aspecto más interesante de la lista es que la mayoría de los idiomas utilizados para la Web hoy en día se originan en la década de 1990.
Cascada y requisitos formales
Siempre hubo personas que personalmente hicieron cosas de acuerdo con Agile, YAGNI, MVP y otras prácticas similares. A nivel corporativo, fue diferente. Algunos lugares que usaban equipos realmente caros llamados computadoras Mainframe querían asegurarse de que los equipos se usaran correctamente. Esas máquinas usaban lenguajes y técnicas de una variedad aún más antigua.
Imagínese a alguien enfocado en la tecnología modelo cliente-servidor que le hace a las personas en esos entornos una pregunta similar a la que estamos discutiendo en este momento. Hubo otras buenas razones para la metodología llamada modelo de cascada y la creación del documento de requisitos del producto. Un equipo grande, un tiempo de inactividad costoso y un proceso de desarrollo menos orientado a pivotes rápidos en tiempo real significaron un proceso secuencial mucho más lineal que el que se puede aplicar hoy en día.
El mainframe puede regresar en términos de una alta absorción en los centros de datos corporativos y las implementaciones en la nube. La noticia de esa posibilidad llega a través de IBM hace presión para los clientes de Linux con mainframes Ubuntu. Muchas grandes ideas surgieron del pasado que todavía usamos hoy de manera similar a la forma en que se aplicaron esos conceptos. La diferencia es parte de la terminología y las formas de representar esos conceptos.
Pruebas
El código de certificación siempre fue importante. Las herramientas y métodos de prueba van de la mano con procesos estructurados. Los métodos de prueba hoy en día pueden ser un proceso más desarrollado y sistemático en capas además del control de calidad manual que es la prueba unitaria. La gente siempre ha hecho y debería hacer pruebas unitarias y las herramientas que existen hoy en día le permiten escalar eso al nivel de equipos y grupos. Tiene perspectivas como el desarrollo impulsado por pruebas y las pruebas automatizadas que crecieron en mayor importancia en los últimos tiempos. Eso lleva a prácticas como la integración continua en algunas organizaciones más grandes dedicadas a la práctica de la creación de software. El principio básico es el mismo, pruebe el código para asegurarse de que cumpla con los requisitos. La diferencia es la medida en que vas a cumplir ese principio.
Desarrollo de software autosuficiente
Quizás la mayor diferencia entre el desarrollo de software en ese momento y ahora es la mayor predisposición a la autosuficiencia en el pasado. Como la Web no estaba al alcance de su mano y otras fuentes de información eran demasiado limitadas o no lo suficientemente rápidas para resolver una pregunta, usted aplicó más de su mente a la solución total. Algo así como las misiones Apollo Moon diseñadas de acuerdo con la regla de cálculo. Ver, La regla de cálculo: un dispositivo informático que puso a un hombre en la luna.
Digamos que tuvo un problema con una llamada a la API. Tal vez es la primera vez que usó esa API o encontró una anomalía extraña en su uso. Dependiendo del tiempo disponible para usted y los recursos, a menudo se encuentra involucrado con un manual completo o con volúmenes de información en papel al intentar navegar por ellos para obtener una respuesta. En lugar de una resolución rápida en StackOverflow o 20 minutos en Google escaneando rápidamente enlaces prometedores a respuestas, es posible que tenga que pasar los mismos 20 minutos o unas pocas horas revisando un conjunto de detalles más amplio de lo que estaría dispuesto a hacer hoy.
La situación a menudo significaba que no había nadie a quien recurrir. Una página web con una descripción completa de la solución no estaba disponible. A menudo actuaba como su propio StackOverflow. Con suficiente tiempo, antigüedad y encuentros intensos con problemas de sistemas, te convertiste en StackOverflow de otras personas. Aún así, no había suficientes personas para andar por ahí.
Eso produjo un mayor instinto y predisposición hacia lo que llamo depuración de estilo Ken Thompson. Es la práctica de depurar mentalmente en lugar de recorrer un programa línea por línea en un depurador interactivo. Significaba que con mayor frecuencia hacía un sistema completo, un diagnóstico integrador por observación combinado con educación, conocimiento y experiencia para construir, diseñar y solucionar problemas de una manera que dependía mucho menos de terceros. A menudo se equivocaba, pero el ciclo progresivamente alimentó una comprensión que mejoró con el tiempo para marcar una gran diferencia en situaciones críticas de producción.
Desarrollo web
Muchas tecnologías de desarrollo web existían antes de PHP, Java y .NET con el fin de escribir código del lado del servidor y aplicaciones web basadas en datos. Una de las más notables es la combinación de PERL / CGI que tiene una larga historia. Algunos de los mejores libros sobre PERL / CGI en ese momento tenían más de 500 páginas. Casi lo mismo que un libro en ASP.NET, excepto que estos libros entrarían en la historia de http, RFC y desglosarían toda la pila de red como contexto de cómo se manejan las páginas web. La mayor crítica de Common Gateway Interface fue que procesar una página web a través de un solo proceso de subproceso no era la mejor idea del mundo en términos de rendimiento.
Tenías muchas bibliotecas de código para el desarrollo de PERL / CGI en la década de 1990. Uno de los más populares para aquellos tiempos fue Matt’s Script Archive, Inc .. El script formmail fue muy útil. El sitio web de Matt podría constituir una técnica anterior en muchos conceptos que involucran componentes de aplicaciones web.
Entonces tenías filtros ISAPI de Microsoft. Esta fue la gran innovación en las plataformas de Microsoft para crear sitios web de alta velocidad utilizando C y / o C ++. Hubo un tiempo en que tenía docenas de bibliotecas de códigos para él, incluso en lugares como el sitio web ComponentSource que mencioné anteriormente. La programación de ISAPI no era accesible para muchas personas que usaban tecnologías web, las secuencias de comandos parecían más prometedoras y, por lo tanto, Active Server Pages y todas las herramientas y bibliotecas de soporte creadas. Tenías los lenguajes gemelos de VBScript y JScript para ASP. Dado que ASP se creó sobre el Modelo de objetos componentes, también podría crear páginas web utilizando la tecnología con lenguajes compatibles con COM, que era más que solo C ++ y VB.
Aunque ISAPI sigue siendo una tecnología de desarrollo web disponible que utiliza C ++ en Windows, la mayoría de las personas lo descarta automáticamente. Las personas con una larga experiencia en TI tuvieron malas experiencias con la caída de los servidores web de ISAPI. Otros, que utilizaron ISAPI para sitios web a gran escala, pueden recordar lo difícil que fue encontrar personas con las habilidades necesarias para mantener dichos sitios web. Eso no ha disminuido el apetito de Microsoft por soluciones nativas que podrían aplicarse para el desarrollo de aplicaciones. Usted ve esto en la implementación conocida como WinHTTP.
Una de las principales razones por las que TI quería .NET para entornos operativos basados en Microsoft (o que lo usaban como complemento de mainframes y UNIX de gran tamaño) es que las aplicaciones web ASP se bloquearon horriblemente. El temido componente ActiveX no puede crear un mensaje de objeto podría tener mil significados detrás de él. Cuando ocurrió, no tenía seguimiento de Stack para diagnosticar y determinar la causa exacta. Si involucraba a un equipo de personas que escribían diferentes partes, tenía que someterse a lo que podría llamar una rutina de seguimiento social que consistía en preguntas cuidadosas para determinar la verdadera causa. Podría haber sido una sustitución de DLL o actualizar una clave de registro de Windows o cambiar un GUID de objeto. Más importante aún, los errores de este tipo a veces derribaron el servidor web. El alojamiento compartido de múltiples aplicaciones web en una máquina fue una pesadilla. Ingrese a Microsoft ASP.NET para salvarlo de todos los problemas de COM y permitirle iterar sobre una nueva funcionalidad sin los dramáticos efectos colaterales en el entorno operativo general. Antes de eso, aquellos que tuvieron más éxito en la aplicación de tecnologías como ISAPI o ASP eran más de la variedad autosuficiente mencionada anteriormente.
Desarrollo de juegos
Algunos de los más sofisticados de marketing que verías para el desarrollo de juegos en tiempos pasados involucraron DirectX. Los carteles eran muy llamativos y los materiales a su alrededor siempre fueron algunos de los más refinados en términos de representación visual. Una cosa que no ha cambiado, todavía tiene muchas tarjetas gráficas para elegir.
Muchas bibliotecas de juegos han existido. Algunos siguieron la suerte de las implementaciones de hardware de gráficos que variaron y se retiraron rápidamente. Relativamente alta volatilidad en las tarjetas gráficas en los años anteriores al duopolio de Nvidia y ATI en comparación con la actualidad.
AMD compró ATI. Entre eso y una concentración general en Nvidia y un enfoque lento pero creciente en gráficos integrados, más bibliotecas y marcos para juegos y gráficos obtuvieron la oportunidad de estabilizarse y proliferar. El marco de Unity no podría existir en la década de 1990, incluso si C # fuera un acuerdo cerrado. El hardware de gráficos era una perspectiva más volátil y las 486 placas de sistema informático ofrecían muchos desafíos en términos de estabilidad del controlador. Aunque las computadoras comerciales eran una situación establecida desde hace mucho tiempo en la década de 1990, el hardware para uso personal era un nuevo mercado que aún no había madurado.
Uno de los motores de juego más antiguos es Allegro, descendiente de Atari. Ha evolucionado a lo largo de los años para abarcar DirectX, OpenGL, y probablemente traerá Vulkan cuando esté completamente horneado. Tenías otros paquetes de gráficos que podrían usarse para lo que podríamos llamar juegos rudimentarios a través de idiomas como GW-Basic y HiRes Graphics. Una diferencia clave entre el desarrollo de juegos en ese momento y ahora es la aceptación más generalizada de la programación orientada a objetos con una absorción lenta pero constante de más prácticas convencionales del desarrollo de software empresarial.
Dominio del desarrollo de software
Volviendo a los detalles de la pregunta, no creo que se pueda decir que aquellos que escribieron software tenían un mayor dominio del desarrollo de software que aquellos que lo aplican hoy. Más bien, simplemente hay una diferencia en las áreas de desarrollo de software que se enfatizó. Usted tenía más autosuficiencia que por necesidad, pero el entorno actual puede ser mejor en términos de reducción del agotamiento individual o la necesidad de esfuerzos heroicos. Lo que es seguro es que muchos de los que crearon software tuvieron una mayor capacidad para construir tecnología de base que se mantuvo bien durante muchas décadas.
Conciencia de diversas tecnologías
Las personas pueden haber sido menos conscientes de todas las diferentes tecnologías que realmente existían en ese momento. Otros gradualmente se deslizaron en múltiples tecnologías con el tiempo sin ser conscientes de ello. Digamos que pasó 15 años con la tecnología X y la tecnología X fue la tecnología principal que utilizó. Con el tiempo, puede olvidar los otros 5 o 10 años que pasó con varias otras tecnologías, ya que fueron menos dominantes en su experiencia. Algunos grupos de desarrolladores de software estaban en lo que se llamaba silos. Se encontraban en situaciones en las que el ejercicio tecnológico era más singular y centrado. Lo mejor de un silo tecnológico es que es una experiencia tecnológica más productiva. Por lo general, haces las cosas más rápido y de forma más ágil. La realidad es que había tanta diversidad de tecnología entonces como ahora.
Homogeneidad del software empresarial
Además de la existencia de la Web, uno de los grandes cambios en la toma de conciencia de la tecnología diversa ocurrió en la campaña más amplia en contra de ver los sistemas de manera homogénea. Eso sucedió principalmente para vender soluciones de interoperabilidad o mantener la inversión en una tecnología al demostrar su disposición a los cambios en la forma en que se utiliza la tecnología. En lugar de ver el entorno operativo como todo Microsoft, todo UNIX o todo IBM, la realidad era que los escritorios eran PC / Microsoft, el back-end podría ser UNIX / Risc transmitiéndose a una plataforma de mainframe de IBM en algún lugar. Puede haber comenzado con un mainframe en el que se vincularon otras tecnologías directa o indirectamente.
Tendría grupos de desarrolladores dedicados a cada peldaño en las empresas. Usted tuvo una gran productividad en cada peldaño en el que centrarse en las tecnologías en esas áreas conducen a soluciones sólidas para esa área de práctica. Aquellos con responsabilidades de liderazgo técnico que cruzaron áreas vieron una imagen diferente. Todos los idiomas y más mencionados a lo largo de esta discusión. Es posible que tenga acceso a los aspectos más críticos en CICS / COBOL a través de una capa de comunicaciones a nivel de aplicación definida en Java o C usando una implementación alternativa y patentada de DCOM a la que accedió alguna aplicación en VB, C ++, VBScript, Delphi, PowerBuilder o FoxPro o una combinación improbable que años después aún vio transformaciones XSLT con consultas XPath atornilladas. Tuviste que DB2 en algún lugar fluía hacia Oracle en algún otro lugar que filtraba datos a un SQL Server citado por varias bases de datos de MS Access que luego se exportaron a archivos de MS Excel que un día encontraron una nueva vida como cargas en un sistema en la nube.
Eso suena como hoy con node.js en algún lugar de Amazon EC2, hablando con otra cosa en Python, enviando a otra cosa optimizada en C, con un front-end en JavaScript que usa WebGL que es similar a una versión móvil que se hace en Swift que habla con el mismo back-end pero usando JSON enviado a node.js a través de la transferencia de estado de representación.
La experiencia
La pregunta es, ¿cómo fue esto? Fue bueno o malo?
Si no entendía que todos los sistemas eran, en última instancia, iguales y que todas las capas de abstracción existían con fines de productividad, a menudo los proveedores comerciales de lenguajes y marcos tecnológicos lo tiraban en muchas direcciones que generalmente no valían la pena. término. A corto plazo, podría ser muy bueno. A largo plazo, por lo general, era mejor si se hubiera mantenido abierto a los estándares.