Como dijo Quora User, nos estamos acercando rápidamente a los límites de la fabricación de chips, y estamos empezando a alcanzar límites cuánticos que nos impedirán un mayor crecimiento de la velocidad y la capacidad, tal como hemos estado utilizando durante los últimos 40 años (la Ley de Moore). Los programadores (y los gerentes) siempre apostaban a la actualización de hardware del próximo año para resolver la falta de rendimiento de su software; y eso ha funcionado durante tanto tiempo que las últimas dos generaciones de programadores rara vez se preocupan por la eficiencia, ya sea la velocidad o la memoria, o ambas cosas. (Excepto los juegos … Luego se esfuerzan por exprimir el último abandono de la plataforma de su elección).
Nosotros, los programadores en el área científica, hemos estado presionando la última caída de rendimiento desde el día 1. Y aprendimos muchas lecciones sobre cómo hacerlo sin comprometer la claridad del código y su capacidad para ejecutarse en arquitecturas y entornos futuros. Algunos códigos científicos tienen un pedigrí muy largo, y cambiarlos o volver a codificarlos no afectará la reproducibilidad de los resultados que es tan importante en la ciencia.
Anticipamos el “enamoramiento cuántico” de la Ley de Moore y comenzamos a hacer nuestros planes de contingencia. Esos planes, en esencia, indican que debemos aprovechar la mayor ventaja posible del procesamiento paralelo, ya sea mediante la distribución del cómputo en múltiples máquinas independientes o en múltiples unidades de cómputo independientes. Incluso aprovechamos las GPU mejoradas (cuya razón de ser fue impulsada en gran medida por la industria del juego) disponible en todas partes donde se encontraba disponible una moderna tarjeta gráfica. Gigantes como Nvidia incluso satisfacían nuestras necesidades con arreglos de GPU sin video aptos para clusters, e incluso bibliotecas desarrolladas capaces de computar nuestros algoritmos centrales en ellos.
El área de programación científica sabe que la única forma de avanzar es aprovechar el paralelismo en forma de múltiples unidades de cómputo homogéneas (o heterogéneas, como en el caso de las GPU y lo que venga a continuación). Actualmente, muchos compiladores de alto nivel de lenguajes como C / C ++ pueden utilizar múltiples unidades centrales en las CPU populares para distribuir los cálculos automáticamente sin tener que lidiar con las complejidades de bajo nivel de la programación de subprocesos.
- ¿Por qué pensamos en el futuro?
- ¿Cuál es el futuro del diseño de sitios web?
- ¿Qué reemplazará a PHP en el futuro si su popularidad para el nuevo desarrollo web disminuye?
- ¿Cuál es el futuro de la logística?
- ¿Qué grandes proyectos espaciales se llevarán a cabo en los próximos 50 años?
Aparte de esto, no puedo decir con certeza. El mundo de la electrónica y los chips no cambiará demasiado en 5-10 años: ahora es más un “rastreo por los últimos centímetros” que un “ataque precipitado para la línea de meta”; es “más de lo mismo, solo que más grande y mejor” en lugar de “nueva velocidad sin precedentes”. (A menos que haya avances imprevistos, es decir. Pero “imprevisto” significa exactamente eso: no se puede prever ).
¿Por qué todo este desvío en “tierra electrónica”? Porque los lenguajes de programación no existen en un vacío: atienden necesidades específicas y aprovechan oportunidades específicas. No creas un nuevo idioma solo porque puedes (debería saberlo: he estado haciendo esto durante décadas, siempre porque surgió la necesidad, no porque quería “intentarlo y hacerme famoso”). El atributo más importante de un idioma es qué tan bien se ajusta a las necesidades del campo al que se dirige y qué tan bien se abstrae de los detalles esenciales de la implementación de aquellos que no necesitan preocuparse por sí mismos (y también, qué tan bien se revela Detalles a quienes realmente necesitan conocerlos).
Ningún lenguaje actual o pasado ha golpeado el “punto dulce”. No para todos los casos de uso, es decir. La tendencia siempre ha sido diseñar lenguajes de propósito general que cubran la mayor cantidad posible de patrones de uso. Ellos son “generalistas”. Pero por la misma razón que ahora tenemos que pensar cada vez más en la optimización, los lenguajes generalistas siempre se retrasarán un poco debido a su necesidad de compromiso para generalizar . Yo, personalmente, predigo el aumento de más idiomas “especializados”, sintonizados con precisión en sus áreas objetivo; no existe solo, sino en un próspero ecosistema de otros idiomas, tiempos de ejecución y entornos que permiten a cada uno centrarse en lo que hace mejor y relegar otros aspectos a otros idiomas. Ya lo estamos viendo con “sistemas multiparadigm” que aprovechan muchos idiomas, cada uno haciendo su parte y parcela.
Lo importante a recordar es que “los humanos son caros, las máquinas son baratas”. No fue hace décadas, pero lo es cada vez más hoy y mañana. Necesitamos idiomas que ayuden a los humanos, no a la máquina: ya conocemos muchas formas de ayudar a la máquina sin molestar demasiado a los humanos (si es que lo hacemos); no lo hicimos cuando empezamos a crear los primeros idiomas, y no lo hicimos. durante muchos, muchos años después, pero ahora conseguimos una comprensión decente del “arte” y lo estamos utilizando en tantos compiladores como tenga sentido. Los programadores rara vez, si acaso, necesitan conocer esos detalles de bajo nivel (de hecho, la mayoría de los programadores han sido ajenos a la necesidad de conocerlos desde que comenzó su carrera).
Los programadores pierden enormes cantidades de tiempo pensando o preocupándose por la velocidad de las partes no críticas de sus programas, y estos intentos de eficiencia en realidad tienen un fuerte impacto negativo cuando se consideran la depuración y el mantenimiento. Debemos olvidarnos de las pequeñas eficiencias, digamos que aproximadamente el 97% de las veces: la optimización prematura es la raíz de todo mal. Sin embargo, no debemos dejar pasar nuestras oportunidades en ese 3% crítico.
–En el artículo de Donald Knuth “Programación estructurada con ir a declaraciones”
Eso fue escrito hace 40 años por un gran sabio , durante la “revolución de la programación estructurada”. Todavía es cierto hoy. Y será verdad para el futuro previsible.
Los lenguajes de programación deberían ayudar a los humanos a usarlos, no a la máquina que ejecuta los programas. Si la máquina necesita ayuda para ejecutar de manera eficiente y rápida alguna parte del código, y el sistema de lenguaje no puede determinar por sí mismo qué parte es y qué hacer al respecto, entonces la primera línea de ataque es perfilar al culpable (s) y entonces enfócate en ellos. Ese no es el trabajo de un procesador de lenguaje (compilador, intérprete, JIT, lo que sea) sino de un conjunto de herramientas que se pueden implementar para instrumentar el código en ejecución y que producirá un resultado que ayude a un experto en optimización a identificar las causas y sugerir mejoras ( e incluso interactuar con los diseñadores de sistemas de idiomas para agregar algunas heurísticas para abordar el problema).
Mi punto es que nos estamos acercando rápidamente a una situación de “escasez de recursos”, donde necesitamos optimizar todos los componentes relevantes del problema para convertirlo en una solución. Y la parte humana ha sido esencialmente descuidada durante demasiado tiempo. Los lenguajes deben abordar tanto el lado de la computadora (eficiencia, medida de la manera que sea apropiada) como la parte humana (programador y eficiencia de apoyo, medida de la manera que sea apropiada). Esos lados son complementarios e interactúan, por lo que deben abordarse juntos.
Eso es lo que espero ver adelante. No “compilado versus interpretado”, no “adelantado en el tiempo versus justo en el tiempo”, no “procesal versus funcional”: esas son batallas antiguas . El “enemigo” ha cambiado: el enemigo a vencer somos nosotros , el eslabón débil : los programadores. Es hora de optimizar las capacidades humanas y también de educar a los programadores para que sean mucho más que “programadores”, “programadores competitivos” y “piratas informáticos”.
Descargo de responsabilidad: antigua industria del software curmudgeon hablando. Siéntete libre de ignorarme. 🙂