Transcripción de Previniendo el colapso de la civilización

Previniendo el colapso de la civilización es una charla que Jonathan Blow dio en Mayo de 2019 en la conferencia DevGamm en Moscú, Rusia.

Esta charla es polémica y muy directa, y trata acerca del estado actual de la industria del Software y su posible declive. Podrás estar de acuerdo o no con los argumentos que presenta, pero no podrás permanecer indiferente.

Con el fin de difundirla, la hemos traducido y subitulado al español. Les dejamos el video y más abajo la transcripción. Si encuentras un error en la traducción o alguna mejora, se aceptan Pull Requests.

También hemos puesto los subtitulos y la transcripción en inglés en este otro post.

Transcripción

link
00:00:04
Cuando preparaba esta charla, me hizo pensar acerca de algunas cosas que sucedieron entre nuestras sociedades algunas décadas atrás. Por ejemplo, en 1957, cuando la Unión Soviética lanzó el Sputnik, el primer satélite hecho por el hombre en orbitar la tierra exitósamente. En Estados Unidos, todos se asustaron por esto.

No les gustaba estar atrás en la carrrera espacial.

Dijeron: "Dios, tenemos que alcanzarlos. Tenemos que poner un satélite en órbita en 90 días".

Eso suena a una locura y lo era. Nuestro primer intento explotó en la plataforma de lanzamiento.

Pero el segundo intento tuvo éxito. Eso fue el 31 de Enero de 1958. Casi 120 días después del primer intento. Eso fue realmente rápido para estándares modernos.

Entonces, el 6 de Abril de 1961, Yuri Gagarin se convirtió en el primer ser humano en orbitar la Tierra, y, de nuevo, la noticia le dio la vuelta al mundo. Todos estaban impresionados por ello. De nuevo, la gente en los Estados Unidos estaban molestos, porque, de nuevo, estábamos atrás en lo que se estaba volviendo claramente la carrera espacial. Y no nos gustaba, y ¿qué podíamos hacer al respecto?

link
00:01:17
Así que a finales de Mayo, 1961, un mes después de ese vuelo, nuestro presidente en esa época, Kennedy, dio un discurso al Congreso diciendo, si queremos alcanzarlos y no estar detrás de ellos siempre, tenemos que hacer algo grande. Tenemos que poner mucho dinero, muchos recursos. Vamos a ir a la Luna. Y eso era una locura. Y, en 1962, reiteró esto en un famoso discurso público y dijo, vamos ir a la Luna antes de que la década termine y era una locura.

Realmente era una locura porque no habíamos hecho nada remotamente cercano. Pero aquí lo tienen, eventualmente lo hicimos.

El Apollo 11 se lanzó el 16 de Julio de 1969, antes de que terminara la década. Y justo este año salió un muy buen documental sobre la misión.

¿Qué es? Está hecho de tomas originales tomadas por la NASA durante la misión que habían estado guardadas en armarios y clósets y que fueron restauradas y las usaron para hacer una recreación de cómo era vivir durante la misión. Les voy a reproducir un extracto del documental, solo para darles una idea de la escala de todo esto.

Es muy grande y es una locura que pasamos de nada a todo esto en algo como 12 años.

Antes del vuelo del Sputnik, no teníamos un programa espacial en los Estados Unidos. Y, al final, terminamos con todo esto. Y luego, por supuesto, después de eso continuamos haciendo cosas espaciales.

link
00:03:38
Construimos el transbordador espacial. Se veía como algo genial, como una nave de ciencia ficción. Podía despegar y aterrizar de vuelta, eso es genial, ¿no? El problema es que no todo el transbordador podía aterrizar, como esos tanques en la parte trasera. Y por ello, era muy costoso volarlo y poco confiable. Gente murió en él en un par de diferentes misiones, así que decidimos dejar de usarlo, por esas razones. Así que, después de eso, si queríamos poner a personas en órbita, teníamos que conseguir un viaje en el Soyuz y, a partir de ahí, la trayectoria de nuestro programa espacial se mantuvo en declive. Así que, si hubieras hablado con alguien como yo alrededor del 2002 or 2005, teniamos esta actitud de, ¿no es una lástima? Los Estados Unidos solía hacer estas cosas geniales en el espacio, pero ahora no hacemos nada.

link
00:04:27
El futuro de ciencia ficción que visualizamos, no va a pasar y no vemos que eso vaya a cambiar, pero ¿qué puedes hacer al respcto?

Pues, solo encogerte de hombros, ¿correcto? Esa era la actitud de todos. Bueno, no de todos. En algún punto, alguien llegó, que había hecho mucho dinero en un sitio web y dijo: "Ey, quiero hacer algo al respecto. A pesar de no tener experiencia en cohetes espaciales, crearé una compañía para lanzar cohetes y para hacer cosas más grandes de las que hemos hecho".

link
00:04:59
Y aqui hay un extracto de un video acerca de las razones por las que lo hizo.

Elon Musk: "Acerca de volvernos una especie multiplanetaria y una civilización espacial. No es inevitable. Es muy importante darnos cuenta que no es inevitable. El futuro de la energía sustentable, creo que es prácticamente inevitable, pero el ser una civilización espacial, definitivamente no lo es. Si miras el progreso que tuvimos en el espacio, en 1969 envíamos a alguien a la Luna. 1969. Luego tuvimos el transbordador espacial.

El transbordador espacial solamente podía llevar personas a la órbita terrestre baja. Luego retiramos el transbordador espacial y los Estados Unidos no podían mandar personas a la órbita. Y esa era la tendencia... La tendencia iba a la nada.

La gente se equivoca cuando piensa que la tecnología automáticamente mejora. No mejora automáticamente. Solo mejora, si mucha gente trabaja muy duro por mejorarla. De hecho, creo que se degrada.

Si miras a grandes civilizaciones como el Antiguo Egipto, que pudieron construir las pirámides, ellos olvidaron cómo hacerlo. Y los Romanos, construyeron esos maravillosos acueductos. Olvidaron cómo hacerlo."

link
00:06:24
Jonathan: Así que su idea fue muy exitosa y hoy aterrizamos cohetes espaciales y estamos planeando seriamente otra misión a la Luna en 2024. Ya veremos si realmente sucede.

Pero el hecho de estar hablando seriamente acerca de ella, es ya un gran logro, dada la situación en la que estábamos hace poco. Así que, Elon habló acerca de un par de cosas en el pasado que fueron grandes logros y que se perdieron, quiero mostrar un par más de esos casos para ilustrar que la tecnología automáticamente se degrada.

link
00:06:52
Esto que ven aquí es la copa Lycurgus. Es un reliquía que se encontró y fechada en el imperio romano: 380 DC. Está hecha de vidrio y este vidrio del que está hecha es el primer nano material conocido en el mundo. El color del vidiro cambia dependiendo de cómo lo mires y de dónde esté la fuente de luz.

Si lo miras estando de pie frente a la copa y con la luz por aquí arriba, de tal forma que la ves con el reflejo de la luz, entonces la copa es verde. Pero si la luz atraviesa el vidrio, la copa es roja.

Tenian esto en el 300 DC. Luego, el imperio Romano cayó y ese conocimiento se perdió por siempre.

La forma en que esto funciona fue comprendida alrededor de 1990. El vidrio está impregnado con partículas muy pequeñas de plata y oro. Por muy pequeñas, quiero decir de 50 a 70 nanómetros. Que son tan pequeñas que no se pueden ver con un microscópico físico. Necesitas un microscopio electrónico para verlas.

Pero en algún momento, el imperio Romano cayó y olvidaron cómo hacerlo. Se requirió mucha habilidad artesanal para ello. Pueden ver como está hueca por dentro justo donde está el cuerpo de la persona, para darle un tono más púrpura, que contraste con el fondo rojo.

link
00:08:14
Y si escuchas a gente hablar sobre esta copa hoy, o lees algo al respecto, pueden tener una actitud dismisiva, como "Oh, los estúpidos Romanos no entendían de tecnología. Probablemente no sabían que eran la plata y el oro los que lograban ese efecto. Probablemnte fue un accidente e hicieron solamente como cinco copas así"

Lo que no tiene sentido alguno. Cualquiera que se dedique a construir cosas y no solo a hablar sobre ellas, sabe que no obtienes un resultado así de bueno sin un proceso constante de iteración y refinamiento. Puedes imaginar que hubo un accidente inicial, quizás alguien quería un vidrio que brillara e intentaron ponerle plata y oro, y notaron un poco de descoloramiento. Y se preguntaron, ¿por qué sucede? Y quizás luego intentaron averiguar más.

Por ejemplo. ¿qué pasa si cambio las cantidades?. ¿Qué tan grueso debe ser el vidrio? Resultados de ingeniería así de buenos toman mucho tiempo, lo que quiere decir que en Roma había gente haciendo algo que reconocemos hoy en día como Ciencia de Materiales. Luego, eso se perdió. Algo más pasó. Por ejemplo, en el imperio Bizantino, tenían lanzallamas, y no eran pequeños. Tenían recipientes presurizados gigantes en la parte baja de los barcos disparando una sustancia parecida al napalm con tubos metálicos que incineraban los barcos vecinos.

Era parecido al napalm, en el sentido que el agua no apagaba el fuego. Era un arma muy seria. Era un secreto de estado del imperio Bizantino. La usaron para defender Constantinopla una y otra vez por cientos de años, hasta que un día ya no pudieron hacerlo, por alguna razón y el secreto militar desapareció.

Nadie sabe cómo construirlo. Obviamente, re inventamos los lanzallamas, pero son diferentes.

link
00:10:01
Este es el mecanismo de Anticitera, nombrado así por la isla griega donde se encontró dentro de un barco hundido. Era un pedazo de metal corroído o varios pedazos corroídos. Pero, era claro cuando se descubrió originalmente, que tenía engranes.

Con el tiempo, la gente los ha analizado. Se dieron cuenta que es un calendario mecánico que se usaba para saber cosas como en qué año estamos, cuáles son las fases de la Luna, dónde se encuentran los planetas ahora mismo, cuándo son los siguientes juegos Olímpicos. Se ha escaneado lo que queda del mecanismo y se han deducido los engranes que contenía.

Y es muy diferente de lo que yo pensaba. Cuando escuché las ideas acerca de esto, pensé que debían haber tenido pequeños y bonitos engranes en Grecia, que sorpresa. Pero déjenme mostrarles la escala de la reconstrucción generalmente acordada de lo que el dispositivo es.

Esos parecen muchos engranes, ¿cierto? Pero esperen, hay más. Así que la antigua Grecia tenía eso. Pero esa no es la imagen que tenemos hoy de la antigua Grecias, ¿cierto? Y de lo que nos debemos de dar cuenta es que no llegas a eso a partir de nada. No es como que un día no conocías los engranes y al siguiente una persona inventa esto. Necesitas un proceso completo de ciencia para crear algo así de sofisticado. Y no sabemos nada sobre ese proceso hoy.

Todo eso se perdió. Y podría seguir y seguir con más ejemplos. Hay muchas cosas en la historia que son como éstas. Pero no tenemos tiempo.

link
00:12:32
Solo voy a reafirmar que ahora vivimos en un tiempo privilegiado. En el que la tecnología ha estado en buena forma por un largo periodo. La hemos visto mejorar y, por ello, pensamos que el curso natural en la historia es que la tecnología siempre mejora y que estos momentos en la historia son pequeños blips o algo de lo que oímos hablar. Pero no son solo blips. De hecho, el curso normal de la historia mundial es que los grandes logros tecnológicos se pierdan totalmente, porque las civilizaciones que los hicieron colapsan o tienen esta especie de colapso paulatino, en el cual fallan en propagar el conocimiento hacia el futuro. La tecnología va hacia atrás todo el tiempo y no solo en la historia antigua, también en los días modernos, ¿cierto?

Perdemos conocimiento todo el tiempo. Les voy a leer un extracto de una entrevista con Bob Colewell, quien fue el arquitecto en jefe de los microprocesadores en Intel por un tiempo. Pero esta entrevista es de antes de eso.

link
00:13:26
Es de los días del auge de Silicon Valley, cuando trabajaba en una startup llamada MultiFlow. Estaban intentado hacer un procesador de palabra de instrucción muy larga, cuando eso era una idea nueva y experimental. Estaban teniendo muchos problemas. Por ejemplo, cuando estás diseñando el chip, usas componentes de terceros y simplemente no lograban que nada funcionase de forma confiable.

Y estaba como, ¿qué diablos?

Así que dice: Rich Lething y yo hicimos un viaje a Texas Instruments en Richardson, Texas y les dijimos: "Hasta donde sabemos, muchos de sus chips no funcionan apropiadamente. ¿Es esto una sorpresa para ustedes?" Yo medio esperaba que nos contestaran, "¿Qué? ¿Están locos? Están haciendo algo mal. Vamos, no saben lo que están haciendo. Y vayan a usar los chips de otro fabricante" Pero no, nos dijeron "Sí, lo sabemos. Déjenos ver su lista". Leyeron la lista y dijeron:

link
00:14:14
"Bien, aqui hay otros errores de los que no saben" Y por cierto, no era solamente TI. Sus componentes no eran peores que los de otros. Los de Motorola no eran buenos. Los de Fairchild no eran buenos. Todos tenían ese problema. Así que le pregunté a TI: ¿Cómo es que toda la industria cayó al mismo tiempo? Nos estamos matando tratando de darle la vuelta a los problemas en tu silicón.

Y el tipo me contesta, "La primera generación de lógica de transistores fue hecha por los viejos de barba gris que realmente sabían que estaban haciendo. La nueva generación fue hecha por niños salidos directamente de la escuela que no sabían preguntar lo que el cambio en el empaquetamiemto le haría a los picos inductivos".

link
00:14:50
Entonces, cuando cambias el voltaje en lugares en un chip, se genera un campo magnético porque eso es lo que pasa. Y cuando esos campos interactúan en un chip eso es malo. Así que estos novatos diseñando estos chips no sabían que debían tomar eso como un asunto serio. Y eso es el porque la tecnología se degrada, o al menos es una de las razones, ¿cierto? Requiere mucha energía y esfuerzo comunicar de generación a generación estos hechos importantes que son necesarios para un trabajo competente haciendo tecnología.

Y hay pérdidas en ese proceso de comunicación, casi inevitablemente. Y sin esa transferencia generacional de conocimiento, las civilizaciones pueden morir.

link
00:15:33
Si la tecnología de la que esas civilizaciones dependen se degrada y falla. Ahora hablemos de civilizaciones que cayeron. De hecho, un grupo entero de civilizaciones. Los diagramas que voy a mostrar aquí son de una charla que encuentran en Youtube llamada "1177 AC, el año en que la civilización colapsó" de Eric Cline. Estamos hablando de la Edad de Bronze tardía, que fue la época en que existieron varias civilizaciones de las que probablemente has oído, como los Egipcios, los Micénicos, los Griegos o los Hititas, los Babilonios. Así que esta civilización o esta red de civilizaciones que iban desde Mesopotamia hasta el Mar Mediterráneo y habían desarrollado una red bastante sofisticada de comercio.

En este grafo, cada uno de estos puntos es una de esas civlizaciones y las líneas son rutas establecidas de comunicación y comercio entre esas civilizaciones y aunque no todas están conectadas entre sí, estaban lo suficientemente interconectadas que puedes relativamente eficientemente enrutar cosas de un lugar a otro si lo necesitas.

link
00:16:39
Y eso era muy importante porque el bronce, del que las civilizaciones dependían para cosas como defensa, era difícil de fabricar en ese entonces. Lo tenías que hacer combinando cobre y estaño. El cobre es relativamente difícil de encontrar, se encontraba en lugares como la isla de Chipre. Y el estaño también era difícil de encontrar, se encontraba en lugares lejanos de donde se encontraba el cobre, como en Afganistán. Así que se pueden dar cuenta que tenían que mandar estas cosas a varios lugares para poder fabricar tu bronce y las otras cosas de las que tu sociedad dependía. Y nadie está seguro exactamente de lo que pasó en este colapso, pero la gente cree que hubo algún tipo de estresor ambiental que lo inició. Quizás hubo una gran sequía, también algunas inundaciones se teoriza.

Esto llevo a cierto grupo de personas a atacar a otro grupo. Así que, quizás tuviste que empezar a usar tus barcos para defenderte, en lugar de para el comercio. Y, básicamente, pasaste de tener todas estas civilizaciones florecientes, a, cien años después, no quedó ninguna. Y por ninguna, quiero decir que las ciudades-estado desaparecieron. Muchas ciudades fueron quemadas totalmente y los lenguajes de las culturas no sobrevivieron, a pesar de que sabían escribir presionando cosas en piedra, nadie podía traducir esos lenguajes. Aún hoy, no podemos traducir muchos de ellos.

link
00:18:03
Así mucho conocimiento se perdió en este colapso. Regresaremos a él más tarde, pero quiero conectar esto a la era moderna de alguna forma. Y mi tesis para el resto de esta charla es que el software está en declive ahora. Quizás, sea solo un declive leve que hace las cosas sean muy inconvenientes para nosotros. Pero, podría llevar a un declive fuerte en el futuro.

Dado que nuestra civilización depende del software, lo hemos puesto en todos lados.

Todos nuestros sistemas de comunicación son software, nuestros vehículos son software. Ya saben, ahora aviones que matan a cientos de personas debido a mal software y solo al mal software, ¿ciero?

No había ningún otro problema con esos aviones. Ahora, no creo que la mayoría de la gente me creerá si digo que el software está en declive. Ciertamente, parece que está floreciendo, tengo que convencerles al menos de que es una perspectiva válida y ese será mi objetivo para el resto de la charla.

link
00:18:56 Y lo que diré al respecto es: estos colapsos, como el colapso de la Edad de Bronce, fueron masivos, todas esas civilizaciones se destruyeron. Pero tomó cien años. Así que si estuvieran al inicio del colapso, en los primeros 20 años, podrían pensar, bueno, las cosas no son tan buenas como lo eran hace 20 años, pero está bien, básicamente todo sigue igual, ¿cierto? Pero si siguen pensando eso, cada 20 años otro par de ciudades son quemadas totalmente, y entonces, eventualemte, no queda nada, ¿cierto?

link
00:19:24
La caída del imperio Romano duro 300 años.

Asi que si estuvieran en medio de un colapso tan lento como ese, ¿lo reconocerían?, ¿sabrían como se ve desde dentro? Así que, por supuesto, espero que la respuesta a lo que digo sea: "Estás loco, el software lo está haciendo genial! Mira a todas esas empresas de internet haciendo todo ese dinero y cambiando la forma en que vivimos" y yo diría: "Sí, todo eso está pasando. Pero lo que realmente está pasando, es que el software se ha aprovechado del hardware". En las últimas decadas, hemos tenido grandes avances en la tecnología de hardware. Las computadoras siguen volviéndose más y más rápidas.

link
00:20:03
Realmente es uno de los grandes logros en la historia humana, que hemos logrado hacer eso, y el software se vuelve mejor, entre comillas, porque hay mejor hardware para ejecutarlo.

Esa es la principal razón por la que la tecnología de software no ha mejorado hace mucho, eso es lo que afirmo, ¿cierto? Y ustedes podrían decir: "Pero mira todos estos ejemplo de cosas geniales que podemos hacer. Incluso en los dos años pasados, cosas como AlphaGo una IA que venció a jugadores humanos en Go". y podrían continuar hablando de "Instagram u otra app que hace que tu rostro se vea como el de otra persona, eso es una locura. Antes no podíamos hacerlo" Y eso es cierto. Pero primero, la mayoría de esos productos son gracias a que el hardware es rápido. La mayoría de estas cosas geniales que hacemos son gracias a los algoritmos de Machine Learning y esos dependenden de la capacidad de cómputo que tenemos ahora para producir resultados impresionantes. Es difícil imaginar que pudiéramos entrenar AlphaGo hace 20 años en las computadoras que existían en ese entonces, ¿cierto? Así que no es que... o sea, sí hay mejoras en la tecnología aquí, ¿cierto? Los algoritmos de Machine Learning han mejorado. Pero hay dos cosas que decir al respecto.

Bueno, el punto principal al respecto, yo diría, es que es solo una minoria de toda la tecnología de software, ¿cierto? De todo el volumen de cosas que ejecutamos, la cosa que ejecuta el algoritmo de Machine Learning que produce el resultado impresionante, es una pieza muy pequeña del programa. Es algo muy simple, una vez que entiendes las matemáticas y, especialmente, si no tienes que entrenarlo, si solo lo usas, ¿cierto?

link
00:21:41
Así que usas una app en tu teléfono como esa, que hace algo divertido con tu foto, la parte de la app que hace eso que pensamos que es genial y valuable, esa pieza de software es tremendamente simple, comparada con cosas como cargar el mapa de bits de tu rostro o responder al input de los eventos del usuario, ¿cierto? Esa parte es enorme y complicada y es la parte que está decayendo. Entonces, yo describiría al software como que está teniendo mejoras en tecnologías muy localizadas, como Machine Learning, con una tendencia general a la degradación en el resto del campo.

Y aún así, nos impresionan mucho las mejoras, ¿cierto? Y déjenme ilustrarles las partes que se están degradando lo mejor que pueda y es decir que simplemente ya no esperamos que el software funcione mas. Y no estoy seguro cuando sucedió esto, ¿saben?.

Las computadoras siempre han tenido la reputación de ser complicadas. Pero, si viajan varias décadas atrás, era debido generalmente a no ser amigables con el usuario o a que era difícil de entender cómo usarlas. En cambio, hoy, si están usando un programa y hace algo de forma incorrecta, simplemente dicen "sí, es software, reinícialo o lo que sea". Y eso no era así. Y si tu estándares se están reduciendo con el tiempo, ¿cuánto más se tienen que reducir hasta que no sea sostenible?

link
00:22:58
Así, que decidí cuantificar o ilustrar cuántas veces me sucede esto día a día. Decidí a partir de ahora guardar una imagen de mi pantalla cada vez que el software que uso tiene un bug obvio o no es intuitivo o tiene un comportamiento que no es correcto. Y, bueno, escribirlo, ¿cierto?

Cuando tomé esa decisión, estaba trabajando en mi compilador en la línea de comandos y la terminal que uso, después de un tiempo, empezó a decir "intento de indexar un valor nulo" en el prompt, porque está escrita en Lua por alguna razón. Luego, voy a Emacs y estoy trabjando en mi código y Emacs está configurado para volver a cargar los archivos que fueron modificados y eso funcionaba bien, en algún punto dejo de hacerlo así que vuelve a cargar el archivo demasiado pronto y no obtiene todo el contenido y la mitad está cortado y debo reiniciar manualmente cada vez que sucede.

Entonces abro Gmail y voy a mandar un correo al resto del equipo acerca de unas cosas de gráficos para tomar decisiones acerca de qué hacer, y copio una línea de un correo previo y la pego en la caja de "contestar". Y empiezo a teclear mi respuesta y se vuelve algo como una columna de tres caracteres de ancho por aquí, porque de alguna forma, lograron reproducir todo tipo de estúpidos bugs que Microsoft Word tenia formateando texto y frustraban a todo mundo en los 90s y en los 2000, ahora están en Gmail. Y no sé cómo arreglarlo.

link
00:24:18
Te peleas con eso por un rato, intentando que no pase, tienes que borrar algo invisible, no sé. Muy molesto. Así que digo "ok, voy a programar en serio". Y voy a Visual Studio y digo "Voy a teclear los argumentos de mi línea de comandos ahí arriba". Y, tan pronto como hago eso, tenemos esta caja que dice "ey, la colección fue modificada, la opción de enumeración puede que no, tu operación puede no ejecutarse" ¿Por qué?

No sé exactamente la razón. Eso es un problema, lo único que estoy diciéndole es una cadena de texto. Ni siquiera estamos intentando hacer algo con esa cadena. Es como, lo intentaré más tarde. Para cuando intente ejecutar el programa. Pero, aparentemente, eso es muy difícil, ¿cierto?

Y no es el único problema con Visual Studio ni de lejos. Visual Studio tiene muchos, muchos bugs, pero este es el más divertido. Porque lo que estoy intentando hacer es tan simple y no siempre funciona. Esto, no sé qué porcentaje de tiempo pasa.

Probablemente como 5%, no sé, 4%. Entonces decido tomar una pausa. Desahogarme un poco y jugar unos videojuegos.

link
00:25:16
Así que déjenme descargar un juego de la tienda de Epic, pero la descarga no inicia por alguna razón. Así que quizás mejor voy a Steam, porque es una tienda más confiable y con más antiguedad. Y puedo, de hecho, descargar un juego, pero cuando abro la ventana de instalación es una ventana negra y debo reiniciar Steam para poder jugarlo. Entonces, logro jugar el juego y de repente me salgo por un segundo para revisar algo y ahora la pantalla completa es un caos y el juego está como en la esquina de una ventana, ¿cierto? Así que debo reiniciar el juego para que se ponga en pantalla completa de nuevo.

Luego, estoy viendo un muy buen partido de Counter Strike entre Cloud 9 y Luminosity Gaming hace como un mes. Y, durante toda la partida, había un misterioso sexto jugador en Cloud 9 llamado undefined. Ahí en esa esquina. Dejen hago zoom en el mapa para los fans de Counter Strike. Undefined está a la izquierda. Cien mil personas vieron esta partida y todo ese tiempo estuvo ahí.

link
00:26:06
Estaba pensando en un juego que me gusta llamado Ultima 4, así que fuí a su página web que tiene el mapa del juego. Y el mapa estaba como dañado por que estaba cortando algunas líneas, lo abrí en otro navegador para que eso no pasara.

Necesitaba obtener una visa para venir a la Federación Rusa, voy al sitio de la visa y empiezo a teclear mi información y puse mi número telefónico, puse el +1 y algo no le gustó. Así que dice que el número telefónico es inválido aquí, pero no puedo corregirlo sin importar lo que haga. No acepta mi corrección, porque alguna variable que tiene el valor de que el número es inválido nunca se reinicia. Así que tuve que terminar mi aplicación, cerrar la página web; limpiar mis cookies y volver a llenar el formulario. Y ser muy cuidadoso cuando estaba capturando mi número telefónico. Simplemente hay demasiados ejemplos así. Todo esto sucedió en un par de días. Ni siquiera tuve que intentar encontrarlos. Solo tuve que coleccionarlos.

link
00:27:01
Pero luego, llego aquí y como si quisieran darme más ejemplos para esta charla, aquí en el hotel donde he estado escribiendo la charla por un par de días, tienen este sistema de iluminación y calefacción controlado por software. En el que presionas un botón que no parece botón y pasan cosas. Y algún porcentaje del tiempo, no siempre, cuando enciendo el aire acondicionado o lo apago, el teléfono suena. No es un sonido como cuando te llaman, es solamente como una burbuja y luego se detiene. Pero sé que no es intencional, porque no pasa siempre. Y no estoy inventando esto. Esto sucede en mi cuarto, ¿cierto?

link
00:27:38
Ahora, ok, hace un par de horas, estaba trabajando en esta charla. Estaba trabajando en el último minuto porque quería hacer diagrama y descargué una versión de Photoshop de Creative Cloud con una licencia legítima a mi máquina. Lo primero que hago es ir a Archivo, Nuevo Documento. BAM, la nueva extensión de documento no puede cargarse por un error del programa, ¿cierto?

link
00:27:56
Y mi punto, es que nada de esto nos sorprende. Mi otro punto, es que con el tiempo, la situación empeora. Así que intenten esto todos los días, porque nos hemos acostumbrado. No pensé que iba a ser tan malo cuando tuve la idea de coleccionar esos errores. No pensé que iba a haber tantos. Intenten contarlos todos los días, hagan una pequeña lista y creo que se sorprenderán con cuantos serán.

link
No sé si todos sabe lo que esta frase significa: "cinco nueves". Estoy seguro que mucha gente no. Esta era una frase muy común en los 90 y los 2000, cuando la gente te quería vender software o un sistema de hardware. Lo que significa es que este sistema está arriba y funcionando y disponible 99.999% del tiempo, ¿cierto? Cuatro nueves, serían 99.99, algo así. Y ya no la usamos más, creo en parte, porque el número de nueves estaría bajando y no podríamos hacerlo subir de nuevo y a nadie, bueno a algunas personas, no les importa.

link
00:29:00
Así que yo estaba, saben, trabajando en este discurso la semana pasada y dos veces, la primera cuando estaba dormido en el avión y la otra vez en la noche en mi cuarto, mi laptop se reinició cuando estaba hibernando y simplemente cerró todos mis programas. Supongo que por una actualización, pero quizás no lo era. Quizás solo era el sistema operativo fallando. Pero creo que era una actualización. Eso automáticamente lleva mi laptop a ... ¿Qué? ¿Tres nueves o menos? Menos de tres nueves. Y si mi laptop tiene menos de tres nueves, nada que se ejecute en ella puede llegar a tres o cuatro o cinco nueves, ¿cierto? Hemos perdido la retórica de la calidad que solíamos tener, ¿cierto?

link
00:29:39
Y si dicen, el software es defectuoso, las personas como los programadores web o los usuarios de Hacker News o lo que sea, dirán "Sí, lo sabemos, pero el mercado no pagará por ello, ¿cierto? Podríamos hacer mejor software. Pero lleva tiempo y dinero arreglar los bugs y todo eso, y nuestros clientes no lo pagan o el mercado lo penaliza, porque te toma más tiempo lanzar al mercado". Y eso es cierto hasta algún punto. Podría definitivamente debatir algunos puntos. Pero esto es lo que estoy pensando hoy: Si no has visto a toda una industria producir software robusto por décadas, ¿qué te hace pensar que realmente pueden hacerlo? ¿Cierto? Ellos dicen: "Podríamos si quisiéramos, pero no queremos". Pero, ¿por qué habría de creer que realmente podrían hacerlo? ¿Cierto? Porque, como he dicho, hay este factor de transferencia generacional de conocimiento que creo que no está sucediendo, ¿cierto? Así que creo que el conocimiento de cómo hacer cosas menos defectuosas se ha perdido. E incluso el concepto de lo que es una empresa de tecnología ha cambiado y, de nuevo, esto ilustra la diferencia entre software y hardware.

link
00:30:49
Las empresas de tecnología de hardware solían ser un lugar que hacían materiales avanzados o desafiantes, ya saben, diseñan nuevos radares u otra cosas que antes no eran posibles, ¿cierto? Ahora en Silicon Valley y creo que en todo el mundo, una empresa de, entre comillas, tecnología de software, es una empresa que hace cosas con computadoras, y que espera encontrarse con un nicho de mercado que explotar. Y lo que les importa es ese nicho de mercado. Su punto no es el software, y su punto es especialmente no diseñar tecnología de software superior que mueva empujen los límites de la tecnología, que es lo que las empresas de hardware siempre han hecho. Así que incluso hemos corrompido las palabras de las empresas de tecnología, ¿cierto?

link
00:31:31
Ok, ahora quiero llevar esto a algo más cercano a lo que hacemos. Ha habido esta secuencia de abstracciones por las que hemos pasado como programadores en las últimas décadas, ¿cierto? Originalmente, tenían que programar en lenguaje máquina, luego era en lenguaje ensamblador, luego tenemos la secuencia de lenguajes de alto nivel, como Fortran y C o C++. Y hoy en día tenemos cosas como C# o Haskell o JavaScript, que están más alejadas aún de la máquina. Y la justificación de esto es que estamos trabajando a un nivel más alto de abstracción y que mientras más alto sea tu nivel de abstracción, más tareas terminas; porque no tienes que preocuparte por calendarizar instrucciones a la máquina y así. Así que hemos sido muy listos y evitado el esfuerzo. Y pienso que eso es cierto. No pienso que queramos programar cosas en lenguaje ensamblador. Es una pérdida de tiempo.

link
00:32:25
Pero en algún punto en esa cadena, algo salió mal. Y así es como mucha gente se equivoca la mayoría de las veces, ¿cierto? Como que empiezas estando en lo correcto y luego lo extrapolas demasiado hasta el territorio donde estás equivocado. Pero lo importante de esto es que solo vemos un lado. Vemos que estamos siendo listos y evitando el esfuerzo, y no vemos el otro lado de todas estas cosas. Que es que hay una pérdida correspondiente de capacidades, ¿cierto? Porque, dado que ya no programo en ensamblador, ya no puedo programar en ensamblador, ¿cierto? Si no puedo, ¿saben?, si uso lenguajes de un nivel muy alto, y soy un poco holgazán, como a menudo la gente es, ya no sé donde viven mis variables en la memoria, cómo se ven o incluso que tan remotamente grandes son, ¿cierto? No sé con certeza lo que está haciendo el CPU en respuesta al código que escribí.

Podría estar asustado de usar lenguajes no administrados, porque la sola idea de asignación de memoria suena muy difícil y aterradora. O incluso si soy una persona que programa en un lenguaje no administrado, quizás le tenga miedo a los apuntadores y empiece a generar este culto de tenerle miedo a los apuntadores y qué hacer al respecto, como les pasa a los programadores de C++ moderno, ¿cierto?

Así, la retórica es que estoy siendo muy listo, que no debería estar haciendo las cosas de bajo nivel, ¿cierto? Pero parte de la realidad es hay una pérdida de las capacidades que corresponden a esas decisiones y ambas cosas pueden ser ciertas al mismo tiempo.

link
00:33:50
No estoy diciendo que no estamos siendo listos por subir un poco el nivel de abstracción, bueno un poco sí. Quiero decir que hay un problema, que es que el punto de subir a estos niveles es hacer a todos más productivos. Pero los programadores no son más productivos ahora de lo que eran antes. De hecho, me parece que la productividad por programador se acerca a cero. Y, si eso es cierto, entonces, ¿dónde está la prueba de que subir esta escalera de abstracción más y más, esté realmente ayudando?

link
00:34:15
Así que, la forma de entender esto es que vean a una empresa, como Twitter o Facebook. Emplean a mucha gente. Y si ven su producto y se preguntan ¿cuánto ha cambiado año tras año? ¿Cuánta funcionalidad se añade a Twitter año tras año? ¿Cuánta funcionalidad se añade a Facebook? No es mucha, ¿cierto? Y luego divídanla con el número de ingenieros en la empresa, ¿cierto? Que son miles o a veces decenas de miles. Resulta un número muy pequeño al hacer esa división, ¿cierto? Será muy cercana a cero. ¿Qué está pasando?

link
00:34:56
Y para ilustrar esta diferencia en productividad, y que no solo soy yo quien piensa esto, les mostraré un extracto de una entrevista con Ken Thompson, quien es el autor del sistema operativo Unix. Y está hablando de su tiempo en los laboratorios Bell donde empezó a hacer Unix en una computadora que para estándares modernos, no tenía ningún software, ¿cierto?

link
00:35:22
Ken Thompson: "En algún punto me di cuenta, sin que lo hubiera sabido hasta ese punto, que estaba a tres semanas de tener un sistema operativo si hacía tres programas en esas semanas: un editor, necesitaba escribir código; necesitaba un ensamblador, para convertir ese código a un lenguaje que pudiera ejecutar y necesitaba un pequeño kernel, una especie de envoltorio, llámalo un sistema operativo. Por suerte, justo en ese momento, mi esposa tomó tres semanas de vacaciones para llevar a mi hijo de, mas o menos, un año a visitar a mis suegros que estaban en California. Desaparecieron, estaba solo y una semana, una semana, una semana, y tenemos Unix". Brian Kernighan: "Sí, creo que los programadores ya no son tan productivos estos días como solían serlo".

link
00:36:32
Así es, dijo que los programadores ya no son tan productivos como lo eran, y todos se ríen. Pero es divertido, pero no es divertido, ¿cierto? Realmente no es divertido cuando consideras cuanto desperdicio debe haber en la diferencia entre que tan productiva es la gente y que tan productiva pudieran ser, si todo no estuviera tan jodido, ¿cierto? Así que es mi caso acerca de que la robustez del software está en declive y de que la productividad de los programadores está en declive. Así que si van a decir que la tecnología del software está avanzando, contradeciría esos hechos, ¿cierto? Así que pienso que el argumento de que el software está avanzando es claramente falso. Excepto, nuevamente, quizás en pequeñas áreas-burbuja.

link
00:37:11
Así que, ¿por qué es tan malo? ¿Por qué es tan difícil escribir programas? ¿Por qué somos tan miserables cuando intentamos escribir programas hoy? Es porque estamos agregando muchas complicaciones a todo, ¿cierto? Y tengo una forma de pensar acerca de esto que le llamo "No puedes solamente". Cuando hay muchos tipos de cosas que solías poder hacer en una computadora y que ya no puedes hacer hoy.

link
00:37:36
Hoy no puedes solamente copiar un programa de una computadora a otra y que funcione, ¿cierto? Necesitas un instalador. O algo como flatpack en Linux, o como contenedores, si una persona que hace servidores o usuaria de Hacker News, ¿cierto? Y la gente piensa que eso es genial. Ahora tenemos contenedores eso es una ventaja o un avance de la tecnología del software. Todo lo que los contenedores están haciendo es llevarnos de vuelta a la década de 1960, cuando no teníamos nada de eso. Excepto que no es así, porque añaden todos estos pasos que ahora tienen que hacer, ¿cierto? Y cosas que debes de mantener.

link
00:38:09
Pensémoslo por un segundo, ¿por qué necesitas un instalador para instalar software? ¿Es por el CPU? No realmente, imagina que tienes un código máquina para x64 y no te preocupes como lo llevaste a la memoria de la computadora. Pero de alguna forma lo llevaste ahí, y tu simplemente saltaste a él. Pusiste el contador de programa en ese código. Ese código va a hacer lo mismo en una PC con Windows, que en una Mac, que en una máquina con Linux. Lo mismo en un Xbox que en un Playstation 4, ¿cierto? Porque todos esos sistemas usan CPUs compatibles. Entonces, ¿para qué es el instalador? El instalador es para darle la vuelta a las incompatibilidades que añadimos a la capa del sistema operativo. Que es esta cosa inmensamente compleja que en su mayoría no queremos. Así que tendemos a pensar que los sistemas operativos añaden capacidades a un sistema, al sistema de hardware y de software. Pero también le quitan capacidades, como la compatibilidad, ¿cierto?

link
00:39:11
Y es muchas veces arbitrario y no podría ser peor, yo pienso, que lo que hace a los lenguajes shading. Cualquiera que hace motores 3d sabrá de lo que hablo. Solía ser que si querías compilar un programa para muchas platformas, podías escribirlo en un lenguaje portable como C o C++, y tenías que poner unos pocos "if Def's" para adaptarlo a diferentes plataformas. Pero hacías eso y era básicamente el mismo programa. Hoy no puedes hacerlo, porque decidimos que si estás ejecutando un shader debe de ser en un lenguaje de programación diferente en todas las plataformas, incluso si el hardware es el mismo, ¿cierto? Así que si tienes un CPU x86, un GPU NVIDIA, en un SO debes escribir tu shader en un lenguaje de metal shading y en otro SO en un HLSL, ¿cierto? Y son diferentes, aunque sean lo mismo, así que tienes que re escribir todo N veces, donde N es muy grande, o debes de usar sistema de auto traducción para re escribir tus shaders y esos traen mucha complejidad, molestias y bugs. Y ¿por qué? Un shader es un programa más simple que los viejos programas que solíamos escribir. Pero, ¿por qué hemos hecho más difícil escribir un programa más simple? No tiene sentido.

link
00:40:27
No nos importa, ¿cierto? Así que la lista de cosas que simplemente no puedes hacer: No puedes simplemente copiar un programa. No puedes simplemente enlazar estáticamente. No puedes simplemente pintar pixeles en una pantalla. Oh Dios!, el número de pasos que tenemos que hacer para pintar un pixel es una locura. No puedes simplemente escribir un shader. No puedes simplemente escribir un programa para Windows sin un manifiesto y otras cosas. Y en estas nuevas plataformas cerradas, no puedes solamente ejecutar un archivo ejecutable, a menos que esté firmado a través de todo un proceso, ¿cierto? Y todas estas cosas y muchas que no están en la lista que añaden fricción, bugs, tiempo, tiempo de ingeniería y espacio en tu cabeza que evita que pensemos en cosas realmente interesantes que hacer.

link
00:41:09
Un par de ejemplos de esto, que muestran que esto no se va a acabar pronto, han entrado a mi vida. Uno de mis proyectos personales es un compilador y para compilar programas debes enlazarlos con las bibliotecas en la máquina de la gente. Por ejemplo, con el SDK de Windows y la biblioteca con el runtime de C. Y ahora diferentes versiones de cosas, las instalan en diferentes lugares en la máquina. Así que debes ser capaz de encontrarlas para poder enlazarlas. Y en lugar de hacer las cosas más fáciles, Microsoft te da un programa llamado vswhere que puedes encontrar en github. Y la tarea de vswhere es solo para decirte donde estas bibliotecas están instaladas. Tiene más de 7000 líneas de código en 70 archivos, ¿ok? Y ni siquiera intenten añadirla como una biblioteca. Es un programa standalone. Lo que ellos pensaron es que no se puede solamente hacer un compilador que es un solo programa. Obviamente, tiene que ser una suite de aplicaciones, y una vez que tienes una suite de aplicaciones, ¿qué más da otra? ¿Qué más da un pequeño vswhere que ponemos aquí, cierto? Ni siquiera piensan que esto es algo malo. Es una locura. Construí mi propia versión de esto basado en el trabajo de otros y lo redujé a 500 líneas de código. Que siguen siendo demasiadas para básicamente hacer dos preguntas, ¿esas debieron ser dos líneas de código, cierto? Las multipliqué por 250.

link
00:42:28
Luego, también en el mundo de lenguajes de programación, existe algo llamado Language Server Protocol, que es básicamente lo peor que haya escuchado. Y hay proponentes de esto por todos lados. Están construyendo sistemas para eso ahora mismo que vivirán por siempre en tu computadora mañana o quizás hoy mismo. Y hasta donde entiendo, es básicamente una manera más complicada y lenta de hacer bibliotecas. Imagina que tienes un editor para algún lenguaje de programación y quieres ser capaz de hace cosas que hemos estado haciendo por décadas, como buscar la declaración de un identificador haciendo clic en el, o mostrar tooltips que te digan cosas como el tipo de este valor, ¿cierto?

Ellos dicen que la forma en que debes hacer esto es tener un editor y luego es una molestia hacer plugins, esto es un problema que se inventaron, es una molestia hacer plugins por varias cosas. Así que con el fin de estandarizar, vas a tener que levantar un servidor en tu máquina y el editor va a hablar a través de un socket con el servidor y el servidor responde y te da la respuesta, ¿cierto? Lo que ha convertido a un solo programa en un sistema distribuido. Pero el error en toda esta línea de pensamiento, del que ninguna de estás personas parece darse cuenta, es que no hay nada especial en buscar la ubicación de un identificador en tu ... Es solo un API, como los que hemos tenido toda la vida para todo.

Así que el siguiente paso obvio, si dices que debemos usar esa arquitectura en nuestros APIs, es hacerlo así para otras tareas, ¿cierto? Así que ahora tus editores o cualquier programa estará hablando a muchas de estas cosas, ahora si quieren crear algo para esto, deben crear y depurar componentes en un sistema distribuido donde el estado no está ubicado en ningún lugar central y todos sabemos que eso es muy divertido, ¿cierto? Pero por supuesto, las bibliotecas no son tan simples, ¿cierto?Las bibliotecas usan otras bibliotecas, así que ¿qué sucede en ese punto, si estás ejecutando todos esos servidores en tu sistema? Y cuando, ya sabes, algunos se van a caer y tendremos que reiniciarlos, y se estaban sincronizando entre ellos. No, esto es un desastre, ¿cierto? Y la gente está activamente construyendo esto ahora.

link
00:44:36
Y mientras tanto, mientras gastamos todo este tiempo sobre complicando cosas que podíamos hacer en 1960, en la industria de los juegos no somos capacez de hacer las cosas que siempre hemos necesitado hacer. Por ejemplo, hoy en día los juegos no pueden ejecutarse consistentemente a pantalla completa, como se ve en la captura de pantalla y no quiero culpar a un juego en particular, porque todos hemos puesto mucho trabajo de ingeniería intentando hacer que nuestro juego se ejecute a pantalla completa. Es vergonzoso, ¿por qué? Además, es de hecho imposible en la actualidad renderizar a una velocidad suave de cuadros por segundo en una PC. Es simplemente imposible sin importar lo que hagas. Alen Ladavac de Croteam tiene una charla en el GDC y un paper acerca de lo que necesitas para lograr esto. Simplemente, ya no tenemos esa capacidad, lo que es una locura, ¿cierto?

link
00:45:25
Y estamos desperdiciando todo este esfuerzo en otras cosas, así que esta complicación que ha sido introducida en todos nuestros sistemas y que no solo hace nuestras vidas difíciles en el presente cuando intentamos construir algo, además, acelera la pérdida de conocimiento en el tiempo, ¿cierto?

Primero que nada, tenemos que conocer más cosas cuando son complicadas, así que cuando hablas de un trabajo que realizan entre muchas personas, cada individuo conoce un porcentaje pequeño de lo que hay que hacer. Tienen una visión menos global lo que hace difícil hacer un buen trabajo, ¿cierto? Y será más difícil transmitir el conocimiento a la gente en el futuro. Otra cosa que pasa, es que el conocimiento profundo es remplazado por trivial.

El conocimiento profundo puede ser un concepto general, como, así es como la coherencia de caché funciona y eso permite que el software se ejecute rápido en diferentes procesadores y eso. Y el trivial es algo como, bueno, este sprite en Unity no se despliega de forma correcta por alguna razón, pero sabemos que se puede arreglar si abres este panel y cambias este valor booleano, y eso lo arregla por un rato. Pero unas semanas después, por razones aleatorias, el valor misteriosamente cambia de nuevo. Así que solo asegúrate de revisarlo antes de una liberación y estará bien, ¿cierto? Y la razón por la que es trivial, es no solo por el hecho de que no aplica a nada más en el mundo; sino que también va a ser obsoleto en unos seis meses cuando la nueva versión de Unity salga. Y es simplemente ofensivo que estemos gastando nuestro cerebro en estas cosas, ¿ok?

link
00:46:43
Y la tercera cosa que pasa es que la información buena se ahoga en el ruido. Si algo es difícil de entender, el porcentaje de gente que hace el esfuerzo por entenderlo será muy pequeño, y mientras más difícil sea, el porcentaje se reducirá más. Así que si preguntas a la gente, o aprendes en la escuela, o buscas en la web, la probabilidad de encontrar malas respuestas al problema es más alta para cosas complicadas, que para cosas menos complicadas. Así que la complejidad se propaga y magnifica.

link
00:47:15
Pero volvamos al colapso de la civilización. Mientras más complejidad pongamos en nuestro sistema, menos probabilidad habrá de que sobrevivamos a un desastre, porque nosotros tenemos que mantener toda esa complejidad. Estamos comportándonos ahora mismo como si creyéramos que el límite superior de lo que podemos manejar es una cantidad infinita de complejidad, ¿cierto? Pero no creo que esto tenga sentido. Asi que, ¿cuál es el límite superior? ¿Cómo decidiremos cuánta complejidad podemos manejar? La cantidad es diferente a lo que la gente piensa hoy que puede manejar. Así que si tienen a un ingeniero que puede entender todo un sistema que es muy complejo en su cabeza y trabaja en él. Cuando esta persona renuncie y deba pasar su trabajo a otra persona, no va a poder comunicar necesariamente todo eso, ¿cierto? La cantidad de complejidad que podemos sostener, es menos que la cantidad de complejidad que los individuos pueden hacer hoy, ¿cierto?

link
00:48:05
¿Por qué estoy hablando de esto en una conferencia de juegos? Todos saben que los videojuegos no son serios y todo eso, ¿cierto? Pero los videojuegos, al menos, se trataban de maximizar lo que la máquina puede hacer y realmente impresionar a las personas jugando el juego. Y para maximizar la máquina quiere decir que deben entender a la máquina muy bien. Y eso se correlaciona con software robusto, porque si entiendes bien a la máquina, tienes menos probabilidad de introducir bugs productos de malentendidos. También hay anti correlaciones con software robusto, pero de cualquier forma, no hay mucho de eso ahora.

Especialmente, cuando hablamos de desarrolladores independientes, la gente se está cambiando a Unity y a Unreal y deberían, ¿cierto? No hay mucha gente que escriba sus motores hoy en día. Así que tenemos generaciones enteras de programadores que han crecido aprendiendo a programar, ya sabes, haciendo pequeños snippets de C# que los pones en otras partes de Unity o algo así. Y que nunca han escrito algo sistémico y que nunca han escrito algo a bajo nivel. Que por una parte está bien, no estoy diciendo que no deberían hacer eso. Porque hay un grado en el que eso es ser listo, reduce el tiempo de desarrollo, ¿cierto? Te ayuda a lanzar tus juegos antes. Pero, como ya dije antes, hay otro lado. El otro lado, es renunciar a la capacidad de hacer la otra cosa. Renunciar al conocimiento de cómo hacer la otra cosa.

Así que no pienso que es malo, de forma aislada, si muchas personas hacen juegos poniendo snippets en Unity, ¿cierto? Pero, si todos hacen esto, entonces nadie sabrá hacer otra cosa que no sea eso. Y después de un tiempo, ¿qué pasará? Porque tenemos que asumir que no podremos usar estos motores por siempre.

Pero Unity y Unreal fueron creados en un ambiente en el que había muchas empresas de juegos haciendo motores todo el tiempo, ¿cierto? Y de ahí es que contrataron gente, y cuando ya no hay una forma natural de aprender como hacer motores, porque nadie lo hace, ¿De dónde Unity y Unreal van a contratar empleados que mantengan esos motores que todos usan, cierto? Y, ¿saben? mientras puedan seguir contratando gente, es la calidad de gente la que va a decrecer porque tienen menos experiencia. Simplemente toma más tiempo aprender, ¿cierto? Así que quizás en algún punto, bueno, ciertamente en un punto no habrá la gente suficiente para hacer un motor que compita. Pero quizás en algún punto no podrás mantener los existentes y continuarán decayendo con el tiempo, algo así es factible.

link
00:50:37
Entonces, la forma en la que pienso acerca del desarrollo de juegos es hacer algo como la Fundación en los libros de Asimov donde los que realmente sabemos cómo programar computadoras y, ya saben, también otros tipos de programadores como los de sistemas embebidos y la gente de cómputo de alto desempeño, todos los que saben lo que pasa con las computadoras; y cuando el resto del software se caiga a pedazos, aún tendremos el conocimiento y podremos recuperarlo y darlo a la gente. Pero no estoy seguro que eso vaya a suceder ahora. Porque no sé si ... no sé si habrá suficientes de nosotros haciendo trabajo de bajo nivel, o incluso personas haciendo trabajo de alto nivel que entiendan que sucede en el bajo nivel, mientras ellos construyen el alto nivel, ¿cierto? Así que quizás necesite haber una segunda Fundación. Alerta de Spoiler para aquellos que no han leído el libro.

link
00:51:23
Así que de regreso a la Edad de Bronce, ¿cierto? Una de las razones por la que esas civilizaciones desaparecieron, es que por la forma en que estaban organizadas, la lectura y la escritura era prácticada solo por una pequena élite que iba a la escuela por años y esto se cuidaba que fuera así. El público general no sabía cómo hacerlo y probablemente no querían hacerlo. Y porque esas habilidades no eran generalizadas, eran frágiles. Así que cuando la sociedad se quebrantó, no fueron continuadas, porque no había suficientes personas que lo hicieran.

Hoy, casi nadie sabe qué pasa en el CPU, ¿cierto? Esa habilidad no es generalizada. Así que es frágil y pensamos que eso inmensamente complicado que construimos hoy es de alguna manera más robusto que lo que tenían en la Edad de Bronce para fabricar bronce, porque eso no sobrevivió. Si eso no sobrevivió, ¿por qué pensamos que lo que tenemos hoy lo hará?

link
00:52:14
Y podemos pensar que tenemos estresores similares, podremos tener problemas de cambio climático, ¿cierto? O podrían suceder otras cosas, como ¿qué sucedería si hubiera tantos ciber ataques que los países se empiecen a cortar unos a otros del internet? Ahora muchas personas en muchos países no podrían entrar a StackOverflow para copiar y pegar su código, eso afectaría a su código de producción, ¿cierto? o ¿qué pasaría si China dice "saben qué, nos vamos a quedar con todos los CPUs, ya no queremos venderles"? ¿Qué sucederá, cierto? Ninguna de estas cosas de forma aislada, pienso, traerá la caída de la civilización. Pero podría afectar al sistema con un gran impacto. Y si el sistema es demasiado complejo, podría no sobrevivir al impacto muy bien. Y lo que estoy intentando decir, como Elon Musk estaba diciendo, es que la tecnología por si misma se degrada y necesitamos, tan rápido como podamos, empezar a trabajar en contra de esto.

link
00:53:09
A cualquier nivel al que tengamos acceso: Tenemos que simplificar el hardware sobre el que corremos, tenemos que simplificar los sistemas operativos que usamos, las bibliotecas que usamos, el código de las aplicaciones que escribimos, los sistemas de comunicaciones que usamos para ello, como el internet. Tenemos que simplificar cómo compilamos, depuramos y distribuimos software y tenemos que simplificar la interfaz entre las personas y el software. Y eso suena como muchas cosas que hacer, pero la buena noticia es que todas esas cosas son tan ridiculamente complejas hoy en día, que es muy fácil encontrar cosas que mejorar. Simplificar cualquiera de estos sistemas solo requiere la voluntad de hacerlos, mas que tener un gusto, necesitan tener un gusto para reconocer lo complicadas que son las cosas y cómo serían mejor si no lo fuesen, ¿ok?

link
00:53:54
Ahora mucha gente probablemente dirá "Ok, lo que sea. El software es complejo, pero no creo que la civilización vaya a colapsar o algo así". Y saben, quizás, quizás contestaría: Si eres un programador, esto te debe importar de cualquier forma, incluso si solo tomas en cuenta tu futuro personal. Los programadores no están felices hoy en día, muy a menudo estamos de mal humor, y la razón de nuestro mal humor es que estamos haciendo cosas estúpidas todo el tiempo en lugar de hacer cosas interesantes. Y eso no mejorará si seguimos haciendo las cosas de la misma forma que las hacemos.

Así que ustedes personalmente serían más felices si cambiamos la forma en que hacemos las cosas y si hacemos las cosas de la forma que es ahora, quizás el futuro es profundamente mediocre, de la misma forma en que el futuro del programa espacial de Estados Unidos iba a ser profundamente mediocre.

link
00:54:41
Así que aunque quieras sobrevivir como un desarrollador de videojuegos individualmente, solo pensarás, bueno, yo solo quiero terminar mi juego, quiero lanzarlo, quiero que sea un éxito financieramente, si solo quieres preocuparte de forma limitada como eso, quitar complejidad sigue siendo una jugada a corto plazo, aunque no lo parezca. Estoy seguro que estamos muy familiarizados con casos como, bueno, vamos a lanzar en cinco meses y tenemos muchos problemas con este sistema en particular, tiene muchos bugs, saben. Pierde mucho trabajo que han hecho todo el tiempo o lo que sea.

Pero si lo toleramos por cinco meses, ya pasará, será historia y eso es bueno porque re escribirlo requiere mucho esfuerzo. Podria retrasar la fecha de lanzamiento, así que vamos a seguir usándolo por solo cinco meses y eso siempre es la decisión equivocada. Porque lo que siempre pasa, es que toma 2 años el lanzamiento, en lugar de 5 meses, y la cantidad de sufrimiento producido por el sistema es mucho peor del que hubiera sido de otra forma. Y quizás, de hecho, ese sistema fue un gran ingrediente en la razón por la que se retrasó el proyecto.

Así que simplifica, simplificando tu propio código para resolver tus propios problemas locales, también estás construyendo conocimiento insitucional acerca de cómo simplificar. Que suena muy básico, pero puedo afirmar que ya ni siquiera tenemos eso.

link
00:56:05
Aquí hay unos video de referencia que pueden ver si están interesados en este tema: El video de Casey Muratori "El problema de las 30 milliones de líneas". El video de Samo Burja: "Civilizaciones: instituciones, conocimiento y el futuro". Y el video de Eric Cline que les mostré antes: "1177 AC, el año en que la civilización colapsó". Y eso es todo lo que tengo que decir. Gracias por su tiempo.