¿Cómo ha afectado el aumento de la complejidad de los sistemas a las sucesivas generaciones de programadores?

  

simplemente no es necesario debido a la mayor cantidad de potencia de procesamiento y memoria disponible.

Tener memoria barata, discos enormes y procesadores rápidos no es lo único que ha liberado a las personas de la necesidad de obsesionarse con cada byte y ciclo. Los compiladores ahora son mucho, mucho mejores que los humanos para producir código altamente optimizado cuando importa.

Además, no olvidemos para qué estamos intentando optimizar, que es el valor producido por un costo determinado. Los programadores son mucho más caros que las máquinas. Cualquier cosa que hagamos que haga que los programadores produzcan programas de trabajo, correctos, robustos y con todas las funciones de forma más rápida y económica, conduce a la creación de más valor en el mundo.

  

Sin embargo, mi pregunta es cómo se sienten las personas con respecto a esta "ocultación" de los elementos de nivel inferior. ¿Los programadores más viejos lo ven como una bendición o una capa innecesaria para pasar?

Es absolutamente necesario realizar cualquier trabajo. Escribo analizadores de código para ganarme la vida; Si tuviera que preocuparme por la asignación de registros o la programación del procesador o cualquiera de esos millones de otros detalles, no perdería el tiempo arreglando errores, revisando informes de rendimiento, agregando funciones, etc.

Toda la programación consiste en abstraer la capa debajo de ti para hacer una capa más valiosa sobre ella. Si realiza un "diagrama de capas" que muestra todos los subsistemas y cómo se construyen entre sí, encontrará que hay literalmente docenas de capas entre el hardware y la experiencia del usuario. Creo que en el diagrama de capas de Windows hay algo así como 60 niveles de subsistemas necesarios entre el hardware en bruto y la capacidad de ejecutar "hola mundo" en C #.

  

¿Crees que los programadores más jóvenes se beneficiarían más al aprender programación de bajo nivel ANTES de explorar los dominios de las bibliotecas expansivas?

Usted pone énfasis en ANTES, por lo que debo responder su pregunta en forma negativa. Estoy ayudando a un amigo de 12 años a aprender a programar ahora mismo y es mejor que creas que lo estoy iniciando en el proceso de . js y no el ensamblador x86. Si inicias un programador joven en algo como Processing.js , ellos estarán escribiendo sus propios juegos de disparos en aproximadamente ocho horas. Si los inicias en ensamblador, multiplicarán tres números en aproximadamente ocho horas. ¿Cuál crees que es más probable que atraiga el interés de un programador más joven?

Ahora si la pregunta es "¿los programadores que entienden la capa n de la torta se benefician de la capa n - 1?" la respuesta es sí, pero eso es independiente de la edad o la experiencia; Siempre es posible que pueda mejorar su programación de nivel superior al comprender mejor las abstracciones subyacentes.

Tenía ideas sobre este tema, y las puse en un libro 20 años hace . Hace tiempo que está agotado, pero puede seguir obteniendo copias usadas en Amazon .

Una respuesta simple a tu pregunta es tan antigua como Aristóteles: La naturaleza aborrece el vacío . A medida que las máquinas se han vuelto más rápidas y más grandes, el software se ha vuelto más lento y más grande.

Para ser más constructivo, lo que propuse fue que la teoría de la información y su relevancia directa para el software formaran parte de la educación en informática. Solo se enseña ahora, en todo caso, de una manera muy tangencial.

Por ejemplo, el comportamiento de la O grande de los algoritmos se puede entender de forma muy clara e intuitiva si piensa en un programa como un canal de información de tipo Shannon, con símbolos de entrada, símbolos de salida, ruido, redundancia y ancho de banda.

Por otro lado, la productividad de un programador puede entenderse en términos similares utilizando la teoría de la información de Kolmogorov. La entrada es una estructura conceptual simbólica en su cabeza, y la salida es el texto del programa que sale a través de sus dedos. El proceso de programación es el canal entre los dos. Cuando el ruido entra en el proceso, crea programas inconsistentes (errores). Si el texto del programa de salida tiene suficiente redundancia, puede permitir que los errores se detecten y corrijan (detección y corrección de errores). Sin embargo, si es demasiado redundante, es demasiado grande, y su tamaño, combinado con la tasa de error, provoca la introducción de errores. Como resultado de este razonamiento, pasé una buena parte del libro que muestra cómo tratar la programación como un proceso de diseño de lenguaje , con el objetivo de poder definir los lenguajes específicos del dominio apropiados para una necesidad. Nosotros pagamos servicios de enlace a lenguajes específicos de dominio en la educación de CS pero, nuevamente, es tangencial.

Construir idiomas es fácil. Cada vez que define una función, clase o variable, agrega vocabulario al idioma con el que comenzó, creando un nuevo idioma con el que trabajar. Lo que generalmente no se aprecia es que el objetivo debe ser hacer que el nuevo lenguaje se ajuste más a la estructura conceptual del problema. Si se hace esto, entonces tiene el efecto de acortar el código y hacerlo menos con errores simplemente porque, idealmente, hay un mapeo 1-1 entre los conceptos y el código. Si la asignación es 1-1, puede cometer un error y codificar un concepto incorrectamente como un concepto diferente, pero el programa nunca se bloqueará, que es lo que sucede cuando codifica sin requisitos consistentes .

No estamos recibiendo esto. Para todos nuestros valientes comentarios sobre el diseño del sistema de software, la proporción de código a los requisitos es cada vez mayor, mucho más grande.

Es cierto, tenemos bibliotecas muy útiles. Sin embargo, creo que deberíamos ser muy prudentes con la abstracción. No debemos asumir si B se basa en A y eso es bueno, que si C se basa en B es aún mejor. Yo lo llamo el fenómeno "la princesa y el guisante". Apilar capas encima de algo molesto no necesariamente lo soluciona.

Para terminar un largo post, he desarrollado un estilo de programación (que a veces me mete en problemas) donde

• La invención no es algo malo. Es algo bueno, como lo es en otras ramas de la ingeniería. Claro que puede estar creando una curva de aprendizaje para otros, pero si el resultado general es una mejor productividad, vale la pena.
• Código minimalista de estilo haiku. Eso especialmente se aplica al diseño de la estructura de datos. En mi experiencia, el mayor problema del software en estos días es la estructura de datos inflada.

La abstracción de alto nivel es esencial para lograr un progreso continuo en la informática.

¿Por qué? Porque los humanos solo pueden tener tanto conocimiento en sus cabezas en un momento dado. Los sistemas modernos a gran escala solo son posibles hoy en día porque puede aprovechar tales abstracciones. Sin esas abstracciones, los sistemas de software simplemente colapsarían bajo su propio peso.

Cada vez que escribes un método, estás creando una abstracción. Estás creando una pequeña funcionalidad que está oculta detrás de una llamada de método. ¿Por qué los escribes? Debido a que puede probar el método, probar que funciona y luego invocar esa funcionalidad en cualquier momento que desee simplemente haciendo una llamada al método, y no tiene que pensar más en el código que está dentro de ese método.

En los primeros días de la informática, utilizábamos el lenguaje de máquina. Escribimos programas básicos muy pequeños con un conocimiento íntimo del hardware para el que los estábamos escribiendo. Fue un proceso minucioso. No había depuradores; Tu programa normalmente funcionaba o se bloqueaba. No había GUI; todo era ya sea línea de comandos o proceso por lotes. El código que escribiste solo funcionaría en esa máquina en particular; no funcionaría en una máquina con un procesador o sistema operativo diferente.

Así que escribimos lenguajes de alto nivel para abstraer todo ese detalle. Creamos máquinas virtuales para que nuestros programas pudieran ser portátiles a otras máquinas. Creamos recolección de basura para que los programadores no tuvieran que ser tan diligentes en el manejo de la memoria, lo que eliminó toda una clase de errores difíciles. Agregamos la verificación de límites a nuestros idiomas para que los piratas informáticos no pudieran explotarlos con saturaciones de búfer. Inventamos la programación funcional para poder razonar sobre nuestros programas de una manera diferente y la redescubrimos recientemente para aprovechar mejor la concurrencia.

¿Toda esta abstracción lo aísla del hardware? Claro que sí. ¿Vivir en una casa en lugar de armar una tienda de campaña lo aísla de la naturaleza? Absolutamente. Pero todos saben por qué viven en una casa en lugar de una tienda de campaña, y construir una casa es un juego de pelota completamente diferente al de lanzar una tienda de campaña.

Sin embargo, aún puede armar una carpa cuando sea necesario, y en la programación, puede (si así lo desea) seguir bajando a un nivel más cercano al hardware para obtener beneficios de memoria o rendimiento que de lo contrario no podría lograr en su lenguaje de alto nivel.

¿Puedes abstraerte demasiado? "Sobrepasa la tubería", como diría Scotty ? Por supuesto que puede. Escribir un buen API es difícil. Escribir buenas API's que incorporen correcta y exhaustivamente el dominio del problema, de una manera que sea intuitiva y detectable, es aún más difícil. Acumular nuevas capas de software no siempre es la mejor solución. Patrones de diseño de software han empeorado esta situación hasta cierto punto, porque los desarrolladores inexpertos a veces los alcanzan cuando son más astutos La herramienta es más apropiada.

El entrenamiento realmente bueno implica ambos extremos, así como un puente entre ellos.

En el lado de bajo nivel: cómo una computadora ejecuta el código desde cero *, incluido el conocimiento del lenguaje ensamblador y lo que hace un compilador.

En el lado de alto nivel: conceptos generales, por ejemplo, utilizando matrices asociativas, cierres, etc. sin tener que perder tiempo preocupándose por cómo funciona bajo el capó.

En mi humilde opinión, todo el mundo debería tener experiencia con ambos, incluidos sus inconvenientes, y una idea de cómo ir de conceptos de bajo nivel a conceptos de alto nivel. ¿Te gustan los arreglos asociativos? Genial, ahora intente usarlos en un procesador integrado de 50 centavos con 1kB de RAM. ¿Te gusta escribir código rápido usando C? Genial, ahora tienes tres semanas para escribir una aplicación web; puede pasar su tiempo tratando con estructuras de datos y administración de memoria usando C, o puede dedicar su tiempo a aprender un nuevo marco web y luego implementar la aplicación web en unos pocos días.

En cuanto a la complejidad de este aspecto: creo que es demasiado fácil en estos días hacer sistemas complejos sin un clara comprensión del costo de hacerlo . Como resultado, como sociedad, hemos acumulado una gran cantidad de deuda técnica que nos pican de vez en cuando . Es como los terremotos (solo el costo de la vida cerca de una falla geológica, ¿no?), Solo que está empeorando gradualmente. Y no sé qué hacer al respecto. Lo ideal sería aprender y mejorar en la gestión de la complejidad, pero no creo que eso vaya a suceder. Una educación de ingeniería responsable debe incluir mucha más discusión sobre las consecuencias de la complejidad que la mayoría de nuestras universidades actualmente.

* y, de todos modos, ¿dónde está el "terreno" en cómo una computadora ejecuta el código? ¿Es lenguaje ensamblador? ¿O la arquitectura informática? ¿O lógica digital? ¿O transistores? ¿O la física de dispositivos?

Creo que la programación de alto nivel tiene muchas ventajas y es una parte esencial de un lenguaje de programación. Una de las razones por las que Java tuvo éxito fue que tiene una biblioteca completa. Obtiene más con menos código, solo llame a una función predefinida.

Ahora podemos distinguir a los usuarios de lenguajes de programación de los escritores de lenguajes de programación (escritores de compilación). Dejamos las optimizaciones a los escritores compiladores. Nos centramos más en la mantenibilidad, la reutilización, etc.

El aumento en la complejidad de los sistemas es implacable, opresivo y, en última instancia, paralizante. Para mí, como un programador de generaciones anteriores, también es muy decepcionante.

He programado durante más de 40 años, he escrito código en 50-100 idiomas o dialectos diferentes y me he convertido en experto en 5-10. La razón por la que puedo afirmar tantos es que en su mayoría son solo el mismo idioma, con ajustes. Los ajustes agregan complejidad, haciendo que cada idioma sea un poco diferente.

He implementado los mismos algoritmos innumerables veces: colecciones, conversiones, clasificación y búsqueda, codificación / decodificación, formato / análisis, búferes y cadenas, aritmética, memoria, E / S. Cada nueva implementación agrega complejidad, porque cada una es un poco diferente.

Me pregunto por la magia que producen los trapecistas de alto vuelo de los marcos web y las aplicaciones móviles, cómo pueden producir algo tan hermoso en tan poco tiempo. Luego me doy cuenta de cuánto no saben, cuánto necesitarán para aprender sobre datos, comunicaciones, pruebas o subprocesos o lo que sea antes de que lo que hacen sea útil.

Aprendí mi oficio en la era de los lenguajes de cuarta generación, donde creíamos genuinamente que produciríamos una sucesión de lenguajes de niveles superiores y superiores para capturar progresivamente más y más partes repetitivas de software de escritura. Entonces, ¿cómo resultó eso, exactamente?

Microsoft e IBM mataron esa idea al regresar a C para escribir aplicaciones para Windows y OS / 2, mientras que dBase / Foxpro e incluso Delphi languidecieron. Luego, la web lo hizo nuevamente con su último trío de lenguajes de ensamblaje: HTML, CSS y JavaScript / DOM. Todo ha sido cuesta abajo desde allí. Siempre más idiomas y más bibliotecas y más marcos y más complejidad.

Sabemos que deberíamos hacerlo de manera diferente. Sabemos sobre CoffeeScript y Dart, sobre Less y Sass, sobre la plantilla para evitar tener que escribir HTML. Lo sabemos y lo hacemos de todos modos. Tenemos nuestros marcos, llenos de abstracciones con fugas, y vemos qué maravillas pueden hacer los pocos elegidos que aprenden los encantamientos arcanos, pero nosotros y nuestros programas estamos atrapados por las decisiones tomadas en el pasado. Es demasiado complicado cambiarlo o volver a empezar.

El resultado es que las cosas que deberían ser fáciles no son fáciles, y las cosas que deberían ser posibles son casi imposibles, debido a la complejidad. Puedo estimar el costo de realizar cambios para implementar una nueva característica en una base de código establecida y tener la confianza de que estaré en lo correcto. Puedo estimar, pero no puedo justificarlo o explicarlo. Es demasiado complicado.

En respuesta a tu pregunta final, recomendaría encarecidamente a los programadores más jóvenes que comiencen tan alto como sea posible en el pastel de capas, y que solo se sumerjan en las capas inferiores, ya que la necesidad y el deseo proporcionan el ímpetu. Mi preferencia es para idiomas sin bucles, poca o ninguna ramificación y estado explícito. Lisp y Haskell vienen a la mente. En la práctica, siempre termino con C # / Java, Ruby, Javascript, Python y SQL porque ahí es donde están las comunidades.

Palabras finales: ¡la complejidad es el enemigo supremo! Supera eso y la vida se vuelve simple.

  

Sin embargo, mi pregunta es cómo se sienten las personas con respecto a esta "ocultación" de los elementos de nivel inferior. ¿Los programadores más viejos lo ven como una bendición o una capa innecesaria para pasar?

Ninguno, realmente.

La estratificación es necesaria porque sin ella, llegas a un punto en el que tu sistema se convierte en un espagueti inalcanzable. También es uno de los principios de la reutilización: si el desarrollador de una biblioteca hizo un buen trabajo, las personas que lo usan no deberían tener que preocuparse por los detalles de la implementación. La cantidad de código enlatado que utilizamos en nuestros sistemas ha crecido por órdenes de mangitude de lo que era cuando escribí mi primer programa hace 35 años. Ese crecimiento significa que somos capaces de hacer cosas más poderosas a medida que pasa el tiempo. Esto es bueno.

El lugar donde ha sido un problema para mí es completamente cultural. Mi mitad pragmática entiende que ya no es posible envolver mi mente hasta el último detalle y ser capaz de terminar las cosas que quiero hacer. (El envejecer tampoco ayuda, tampoco.) A mi mitad canosa y canosa le costó dejar de lado muchos años de tener una comprensión tan detallada de todo lo que trabajé.

  

¿Crees que los programadores más jóvenes se beneficiarían más al aprender programación de bajo nivel ANTES de explorar los dominios de las bibliotecas expansivas?

Como se ha señalado en otras respuestas, hay un equilibrio entre atraer y mantener la atención de los neófitos y darles una educación ideal, desde la base hacia abajo. Si no puedes hacer lo primero, lo último no puede suceder.

Veo cosas en nuestra industria que son paralelas al resto de la sociedad. Solía ser que casi todos cultivaban su propia comida y pasaban mucho tiempo haciendo eso. Desde entonces, hemos brotado especialistas llamados agricultores que hacen ese trabajo, liberando a otros para hacer otras cosas que contribuyen a la sociedad. Compro mi comida en una tienda de comestibles y no podría producir la mayor parte por mi cuenta si tuviera que hacerlo. Algo similar sucede, aunque en una escala de tiempo mucho más comprimida. Los programadores se están especializando en un conjunto de capas y no en otros. El usuario promedio que escribe GUI puede saber que existe el espacio de intercambio, pero probablemente no sepa o le importe mucho cómo lo gestiona el sistema operativo.

El resultado de todo esto es que ya no se trata solo de desarrollo. La especialización continuada significa que los desarrolladores deberán continuar mejorando sus habilidades de comunicación e integración.

Como con todo, un poco te hace bien, pero duele demasiado. El problema es que muchos sistemas no saben cuándo detenerse: solo 1 abstracción más, para ayudarte a programar más rápido ... pero luego terminas codificando en el mundo real, donde las cosas nunca son tan simples como quieres, y tú Pase más tiempo trabajando alrededor de los bordes de lo que hubiera gastado con una abstracción menos destacada.

Se describe aquí

o aquí - "con una sola línea de código puede agregar 500 usuarios al dominio" .. .

Sus abstracciones tratan de ocultarle la complejidad, pero en realidad lo único que hacen es ocultar esa complejidad. La complejidad sigue ahí, es solo que tienes mucho menos control sobre ella, y es por eso que terminas con este tipo de situación.

  

¿Los programadores más jóvenes se benefician más al aprender programación de bajo nivel ANTES de explorar los dominios de las bibliotecas expansivas? Si es así, ¿por qué?

No lo creo. Todavía hay muchas situaciones en las que es beneficioso tener en cuenta que el bajo nivel de 'capa inferior' funciona, por ejemplo,

• Al depurar un problema en la capa n , a menudo se puede explicar considerando lo que sucede en la capa n-1 (es decir, la capa de abajo). Supongo que la capa 0 sería "transistores", pero si quieres explicar un problema con los transistores, probablemente hablarías de física (por ejemplo, calor), así que tal vez la física sea realmente de nivel 0.

• Cuando se optimiza el código (desafortunadamente), en ocasiones ayuda a disminuir el nivel de abstracción, es decir, la implementación de un algoritmo en términos de una capa de nivel inferior. Sin embargo, los compiladores se convirtieron en realmente en hacer esto por ti si realmente ven todo el código involucrado. Esta razón se hizo más popular recientemente con el auge de los dispositivos móviles e integrados, que tienden a tener procesadores más débiles y donde el "rendimiento por vatio" es mucho más relevante que en los sistemas de escritorio, por ejemplo.

Sin embargo, en general, se hizo mucho más fácil hacer que las computadoras hicieran cosas (incluso de formas ligeramente ineficientes), lo que significa que hay muchos más programadores de los que solía haber. Esto a su vez hizo que el factor "humano" fuera mucho más importante: La respuesta de Robert Harvey ya mencionó que "los humanos solo pueden resistir tanto conocimiento en sus cabezas en un momento dado ", y creo que ese es un aspecto muy relevante hoy en día.

Una de las principales motivaciones en el diseño de bibliotecas y lenguajes de programación (es decir, API) es facilitar las cosas en el cerebro humano. A día de hoy, todo se compila a código de máquina. Sin embargo, esto no solo es propenso a errores, sino que también es muy difícil de entender. Así que es muy conveniente para

• Haga que la computadora lo ayude a encontrar errores lógicos en los programas que escribe. Cosas como los sistemas de tipo estático o los analizadores de código fuente (escucho que Eric Lippert funciona en un sistema bastante popular en estos días) ayuda con eso.

• Tenga un lenguaje que pueda ser procesado eficientemente por un compilador y que comunique el intento del programador a otros programadores para Facilitar el trabajo en el programa. Como un extremo absurdo, imaginar programas de escritura en inglés simple era posible. Los programadores compañeros podrían tener un tiempo más fácil para imaginar lo que está sucediendo, pero aún así, la descripción sería muy difícil de compilar en los instructores de la máquina, y es notoriamente ambigua. Por lo tanto, necesita un lenguaje que un compilador pueda entender, pero que sea también comprensible.

Dado que muchos compiladores (¿la mayoría?) son todavía de uso general, tienen un conjunto de instrucciones muy genérico. No hay instrucciones de "dibujar un botón" o "reproducir esta película". Por lo tanto, bajar hacia abajo la jerarquía de abstracción hace que termines con programas que son muy difíciles de comprender y mantener (aunque triviales de compilar). La única alternativa es mover arriba la jerarquía, lo que lleva a más y más bibliotecas y lenguajes abstractos.

"si los programadores más antiguos ven innovaciones como estas como una bendición o una capa adicional a la que abstraerse, ¿por qué podrían pensar eso?"

He estado programando desde que estaba en la escuela secundaria, aproximadamente 34 años, comenzando con el ensamblador Básico y Z80, cambiando a C, varios lenguajes 4GL, Esquema, SQL y ahora varios lenguajes web. El alcance, la escala y la profundidad de los problemas abordados por la profesión experimentaron un período inflacionario durante ese tiempo, particularmente en los años noventa. Las construcciones tales como bibliotecas, marcos y servicios de SO son todos los dispositivos destinados a abordar la complejidad que acompaña al espacio ampliado de problemas. No son una bendición ni una carga en sí mismas, solo una exploración continua de un vasto espacio de soluciones.

Pero, en mi humilde opinión, la "innovación" se entiende mejor en términos de formas novedosas, y no se confunde con un movimiento lateral, reintroduciendo formas que ya hemos visto introducidas. De alguna manera, la fecundidad de un ecosistema sufre cuando las formas primitivas no se componen, cuando fijan decisiones tomadas al inicio de la evolución, o no pueden reprocesar sus propios detritus. Algunos, si no la mayoría, de los constructos en los que nos mantenemos enfocados no priorizan el mantenimiento del valor a largo plazo como una preocupación. Eso ha empezado a cambiar: enfoques como la Orientación al Servicio y el Diseño Dirigido por Dominio, sin mencionar los modelos de hipertexto y gráficos, por ejemplo, están alterando el panorama. Como cualquier ecosistema, eventualmente las formas dominantes darán paso a nuevas formas; estamos mejor atendidos al permitir la diversidad, de forma amplia y en pequeños incrementos, en lugar de la estandarización descendente a gran escala seguida de un colapso todo a la vez.

"¿Y los programadores más jóvenes se benefician más al aprender programación de bajo nivel ANTES de explorar los reinos de las bibliotecas expansivas? Si es así, ¿por qué?"

Yo diría que la mayoría de los lenguajes humanos se basan en metáforas que se olvidaron hace mucho tiempo, por lo que si bien me gustaría aprender a programar programas de bajo nivel desde el punto de vista de la alfabetización científica / numérica, es más importante que busquemos primitivos que apoyen la escala y el alcance de los problemas que estamos abordando de manera que podamos ignorar de forma segura el nivel de detalle más bajo. Un marco no es un elemento primitivo, tampoco lo es un sistema operativo o una biblioteca, son bastante deficientes para hacer el tipo de abstracción que realmente necesitamos. El progreso real llevará a las personas que (a) saben lo que sucedió antes y (b) pueden pensar de una manera novedosa como para encontrar algo lo suficientemente diferente como para explorar un espacio de solución que no haya sido explorado antes o que haya sido explorado y olvidado.

OTOH, incluso si su objetivo es trabajar como técnico / mecánico, algún nivel de exposición de programación de bajo nivel seguirá siendo útil para desarrollar sus habilidades de resolución de problemas.

Mi primer programa (como adolescente de 15 años) fue en 1974 en PL / 1 en tarjetas perforadas para un mainframe IBM 370/168. Mi padre trabajaba en IBM y tuve la suerte de poder ir al centro de datos los domingos.

En ese momento, un programa de varios miles de declaraciones (es decir, tarjetas perforadas) era un programa grande (y también pesado, ya que muchos miles de tarjetas perforadas pesaban muchos kilogramos). Las interfaces visuales no existían (un programa típico se leía desde su "entrada estándar" utilizando un comando de tarjeta perforada que comienza con //GO.SYSIN DD * IIRC, pero no dominé JCL ). La algorítmica era importante, e IIRC la biblioteca estándar era bastante pequeña para el estándar de hoy.

Hoy en día, los programas de varios miles de líneas generalmente se consideran pequeños. Por ejemplo, el compilador GCC tiene más de diez millones de líneas de código fuente, y nadie las comprende completamente. .

Mi opinión es que la programación de hoy es muy diferente de la de la década de 1970, porque necesita utilizar muchos más recursos (en particular, las bibliotecas y los marcos de software existentes). Sin embargo, creo que a las personas que desarrollan software de centros de datos (por ejemplo, motores de búsqueda en Google) o a algún software integrado les importa tanto los algoritmos como la eficiencia que el programador promedio de los años 70.

Sigo pensando que la comprensión de la programación de bajo nivel es importante incluso hoy (incluso si la mayoría de los programadores no se codifican a sí mismos algoritmos básicos de contenedores como árboles equilibrados, arreglos ordenados de acceso dicotómico, etc.) porque entender todo el panorama sigue siendo importante.

Una diferencia importante entre la década de 1970 y la actualidad es la proporción del costo entre los esfuerzos (humanos) del desarrollador y el poder de la computadora.