Supongamos que suministró un equipo de codificadores de 1990 con una computadora portátil moderna de alta gama y un entorno de desarrollo. ¿Qué podrían hacer con él?

Claro, dentro de los límites.

El “poder” definitivo de las computadoras de los usuarios en la década de 1990 es el mismo, aún habría límites sobre lo que podría escribir, pero el proceso de creación sería sustancialmente más fácil, permitiendo a los programadores probar más variaciones y crear aplicaciones más confiables más rápido Y con más características.

Aquí hay un paralelo:

En 1977, el Sistema de Video Computadora Atari (VCS) llegó al mercado. Los programadores en el viejo y bueno Atari 2600 frecuentemente tenían que usar una minicomputadora compartida o (más tarde) tiempo limitado en computadoras personales lentas para compilar programas. Se realizó mucho trabajo a mano, incluida la edición de gráficos y la decisión de cómo almacenar el almacenamiento.

Algunas de estas decisiones incluyeron la colocación de variables o subrutinas en los cartuchos ROM para evitar tener que mover otras.

La depuración de ese programa sería, bueno, en términos prácticos, casi inexistente. Se podrían usar trucos especiales de hardware y código de programa temporal para mostrar el estado interno del programa, pero no había nada como un depurador simbólico con una posible ejecución paso a paso.

Avance rápido hasta 2016. Ahora se puede usar Gimp para editar gráficos, compilar PNG en valores de mapa de bits, recompilar un cartucho completo de 4k en segundos y ejecutar un emulador Atari completo en una computadora portátil barata de $ 200 con depurador simbólico, ejecución paso a paso y monitoreo completo de cada registro y dirección de memoria.

Existen entornos similares para otras computadoras que existieron en los años 90. Los lenguajes de programación disponibles solo en minicomputadoras de “gama alta” y estaciones de trabajo Unix de lujo ahora están disponibles. Entonces, si viajó en el tiempo a 1990 y le entregó una computadora portátil Linux de $ 200 a un programador de esa época, les dio alguna forma (tal vez un cable de serie a USB de ~ $ 15) para sacar el software de ella, podrían fácilmente escribir código para generar software interesante que otros en esa época puedan usar.

Codificar una aplicación Commodore 64 escribiendo un programa Common Lisp para generar el lenguaje ensamblador MOS-6510 y luego depurándolo en el emulador Vice x64sc, por ejemplo, sería mucho más agradable que codificar en un cartucho Turbo Assembler y esperar 300 caracteres. unidad de disquete de 5¼ ”por segundo para girar.

– ~ –

Si, por otro lado, está suponiendo que viaja en el tiempo una flota completa de computadoras modernas en el tiempo, ignorando, por el momento, cosas como la falta de infraestructura de Internet, muchos programadores podrían usar rápidamente idiomas que son todavía en uso común, como C, Common Lisp, FORTRAN y muchos otros para desarrollar software no muy diferente de lo que usamos hoy, aunque tal vez con las expectativas de la interfaz de usuario de 1990.

En 1990, ya teníamos la metáfora de escritorio en los sistemas Atari, Commodore, Amiga, Apple, Macintosh, Windows, Lisp Machines y Smalltalk (al menos). Los discos duros y los disquetes, que no son muy diferentes de los dispositivos USB, los ratones y el “Koala pad” (como los paneles táctiles de hoy), MIDI y audio digital, incluso las cámaras digitales existían. Realmente, sería sencillo escribir código para las nuevas máquinas mágicamente “más grandes”, ya que los cambios son principalmente una cuestión de escala.

Atari GEM

Commodore 64 GEOS

Banco de trabajo Amiga

SGI Irix

MIT Athena

Charla

Genera

GeoWorks Ensemble para DOS

Macintosh Finder

Ventanas

Primero echemos un vistazo a cómo era 1990:

  • Linux estaba a 1 año de distancia, pero GNU estaba fuera. Al igual que SunOS y una gran cantidad de otros Unixes.
  • Windows 3.0 acaba de ser lanzado.
  • Perl fue lanzado hace unos años.
  • Java (Oak) y Visual Basic están a solo un año de distancia.
  • El lenguaje de programación que se enseña en la escuela es probablemente Pascal.
  • La programación de los juegos pasaría del ensamblaje hecho a mano a C / C ++.
  • El desarrollo de negocios sería C / C ++, BASIC y Pascel (con COBOL y ADS en proceso de liquidación)
  • El desarrollo de software ágil está a 11 años (el proyecto C3 está a 6 años).

Así que nuestros desarrolladores mágicamente transportados tendrán que aprender mucho. La mayoría de los idiomas que usaban ahora están muertos. Los desarrolladores basados ​​en UNIX serán bastante mejores, los de Windows verán algo en común mientras que los desarrolladores de juegos tendrán problemas. Todo lo que un desarrollador de juegos usó ahora está desactualizado.

Lo bien que se adapten también depende de la personalidad. Conozco desarrolladores que han tomado la ruta lenta desde finales de los 90 hasta ahora y han fallado.

Pero me pregunto si hay una segunda pregunta aquí. Uno sobre ‘desarrolladores perezosos que no se preocupan por los recursos’ y tener desarrolladores reales obtendría mejores resultados. La mejor manera de responder a esto sería mirar a un desarrollador de juegos de los 90. John D. Carmack. Si bien estoy seguro de que hacen cosas inteligentes, no todo es un ensamblaje de manivela que se produce hasta el último ciclo. Porque el tiempo de comercialización es más importante. La mayor parte del desarrollo en la programación ha sido por tiempo de comercialización. Obtener buenos códigos estables cierra sesión rápidamente.

Creo que se adaptarían bastante rápido, creo que todos lo hicimos en otros momentos.

Pasé de un Acorn A3010 con 4 MB de RAM a un Sun Ultra 1 con 128 MB de RAM, y un procesador probablemente unas 100 veces más rápido. Los gráficos también fueron incomparablemente mejores, desde el buffer de cuadro básico de Acorn hasta un Creator 3D era como pasar del blanco y negro al color.

Al igual que pasar de un Acorn Electron a un Commodore Amiga, fue una transición bastante normal en ese momento, pero realmente está dando un salto generacional en términos de tecnología.

En 1990, Sun Microsystems estaba enviando el SPARCStation 2, que obviamente es una computadora muy lenta para los estándares actuales, pero ejecuta SunOS, por lo que cualquiera acostumbrado a eso se sentiría muy bien en casa al iniciar sesión en una máquina Linux 2016.

El SPARCStation 2 tiene un máximo de 64 MB de RAM, y si consideramos que una computadora portátil típica podría tener 4 GB u 8 GB de RAM, no es un cambio incomprensible. Los programadores en ese momento no habrían experimentado 8GB de RAM, pero entenderían lo que significaba.