¿Es bueno que los lenguajes utilizados en TI sean cada vez más altos?

Sí, sí y sí! Después de haber visto algo del código que puede suceder cuando las personas no están acostumbradas a abstraer código, escribir comentarios significativos y desarrollar API en general con el siguiente desarrollador en mente, creo que esto es definitivamente una bendición.

Es obvio que la TI no está tan centrada en el rendimiento como dice ser; En la mayoría de los casos, TI no necesita ese tipo de rendimiento. Si lo hubieran hecho, se habrían dado cuenta hace mucho tiempo de que las habilidades de desarrollo de software correctas después de la pausa, al negarse a subcontratar el desarrollo y el mantenimiento continuo del código hacen que estas cosas sean significativamente más asequibles a una fracción del costo. En la experiencia de aquellos con los que he hablado a través de varias compañías con divisiones de TI (donde defino a TI como una función no principal del negocio que tiene una administración que está más preocupada por cumplir con los plazos y tachar las cosas de sus listas que defender los principios de ingeniería como no están enfocados en la ingeniería) y la historia es siempre la misma. Estas sucursales de TI están tan ocupadas tratando de mantener el barco a flote debido a malas prácticas anteriores además de nuevos cambios que parece que no pueden salir adelante. Esto me lleva al siguiente punto.

Como la parte de ingeniería no es tan importante como la lógica de negocios (especialmente en las posiciones de TI), la falta de optimizaciones porque una JVM o algo es una capa intermedia generalmente es una preocupación auxiliar. El tiempo del procesador es barato y los desarrolladores son mucho más caros. Si este no fuera el caso, estaríamos esclavizados en las máquinas al igual que muchos trabajadores de oficina con mainframes en los años 60. Además, dado que muchos de estos lugares buscan desarrollarse rápidamente, ya que están perpetuamente atrasados, ¿por qué no usar un lenguaje que resuma?

Para responder a tu pregunta secundaria, perdemos cantidades significativas de poder. Sin embargo, en mi experiencia, ese poder se abandonó en el momento en que alguien dentro de la empresa decide que puede cortar grandes esquinas en el desarrollo.

Les dejo con esto: ¿Por qué preocuparse si la casa está hecha de mármol (código optimizado) si la construyó sobre arena que se hunde (principios de ingeniería deficientes inherentes a “TI”)?

En el pasado, necesitábamos hacer las cosas de bajo nivel porque los recursos eran escasos, apenas teníamos memoria suficiente para mantener nuestro programa y mucho menos poder de procesamiento. Esa es una de las razones por las que necesitamos el lenguaje de bajo nivel para administrar cada cosa de forma manual y para exprimir cada bit (sin intención alguna) del poder que teníamos.
Hoy en día, su teléfono móvil tiene la memoria y el poder en abundancia. Así que los idiomas están llegando a un nivel más alto, porque en realidad ya no nos preocupamos por esos pequeños detalles, se ha solucionado de forma automática.
Ahora debemos concentrarnos en resolver el problema, y ​​esto se logra mejor utilizando un lenguaje de propósito general.
En el futuro, me imagino que podremos programar simplemente “diciendo” lo que queremos, y la máquina hará la codificación por nosotros. Eso es, por supuesto, si no han logrado la autoconciencia y nos han matado a todos 😉

Seguramente es bueno: como lo señaló Christopher correctamente, en términos de costos, a menudo es más eficiente hacer un código ligeramente suboptimizado con mucha menos mano de obra que viceversa.

Solo agregaría a su respuesta que también es buena porque es solo otra opción: nadie te obliga a usar, por ejemplo, Ruby o Python para hacer un trabajo determinado y aún puedes hacerlo en la Asamblea (buena suerte con eso, ¡aunque!).

En caso de que se requieran altos rendimientos (como en una tarea hecha por miles de veces, piense en un buen ejemplo de las consultas de Google), aún puede seguir uno o más pasos y encontrar toda la optimización que pueda desear, posiblemente preguntando por Lenguajes de nivel dedicados a codificadores.

Entonces, sí: definitivamente algo bueno desde cualquier punto de vista.

Gracias por el a2a.

Sí, es una gran cosa. Naturalmente, perdemos la capacidad de hacer cosas de bajo nivel en lenguajes de alto nivel, pero eso es una pérdida muy pequeña para la mayoría de las aplicaciones. Lo más importante es la legibilidad y la capacidad de mantenimiento del código. Los lenguajes de alto nivel permiten que los desarrolladores de software sean cada vez más productivos con menos errores.

Curiosamente, la razón ya no tiene que ver con la Ley de Moore. La Ley de Moore está muerta. La duplicación de los transistores en los chips se detuvo aproximadamente en 2010. Esto se debe a que se convirtió en un costo prohibitivo en comparación con el simple hecho de tener múltiples procesadores en una sola máquina para hacerlo más rápido.

Ahora, para ejecutar el código más rápido, debemos preocuparnos por la correcta paralelización de nuestro código. Para la mayoría de las aplicaciones de usuario, esto es trivial, ya que probablemente tenga una máquina de cuatro núcleos y su sistema operativo sea capaz de distribuir la carga de las cuatro aplicaciones que está ejecutando, lo que podría no estar escrito para aprovechar esto.

Sin embargo, en los procesos de back-end a gran escala, como el procesamiento de números, la extracción de datos o similares, una máquina solo puede ejecutar un programa y debe hacerlo lo más rápido posible. Ese programa necesita saber cómo aprovechar los múltiples procesadores. En muchos casos, el software necesita entender cómo aprovechar muchas máquinas diferentes a la vez. A esto lo llamamos computación distribuida.

La programación paralela, distribuida y concurrente son temas muy actuales en la ingeniería de software. Con la escala de algún software y la muerte de la Ley de Moore, no hay otra opción. Lamentablemente, estos tres temas son relativamente complicados debido a los desafíos de garantizar que su código sea correcto cuando no puede comprender de manera determinista cuándo se ejecutará. Hay muchas medidas que los desarrolladores pueden tomar para hacer esto más fácil y una de ellas es reducir la cantidad de acoplamiento entre procesos al reducir el estado mutable compartido. Por eso creo que la programación funcional será cada vez más importante en el futuro.

Todas las respuestas hasta ahora son un rotundo “sí” de que los lenguajes de TI deberían ser de mayor nivel, y eso está de acuerdo con mis pensamientos iniciales también. Creo que hacer un seguimiento de todos los pequeños y complicados fragmentos no es lo que quiere hacer su esfuerzo. Sin embargo, para examinar la otra cara por un segundo: ¿requirió un enfoque más metódico y estructurado para poder usar lenguajes de nivel inferior para TI? Es decir, ¿estábamos construyendo sistemas de TI más sólidos en C / C ++ porque nos vimos obligados a hacerlo? (No estoy pensando en la optimización, estoy pensando en la parte de “ingeniería” de la ingeniería de software, que debido a que un lenguaje de alto nivel se encarga de algunas de las tareas domésticas, posiblemente no se necesita tanto en el alto nivel).

Quizás la respuesta depende del alcance de “TI”: si se trata de un sistema temporal interno de su compañía, use Python y elimínese. Si es un código que controla el enrutamiento de una red troncal de Internet, creo que la mayoría se sentiría más segura si utiliza C / C ++. El espectro de trabajo de TI es un millón de variantes entre los dos. En general, se necesita más trabajo de TI para completarse rápidamente sin optimización de lo que es una larga duración y una misión crítica, por lo que todavía tengo que considerar los idiomas de alto nivel. Pero siempre hay una advertencia que depende de para qué sirve.

La respuesta depende de lo que es barato y lo que es caro.

La CPU y la memoria están reduciendo el costo de la Ley de Moore, mientras que las personas son cada vez más caras a pesar de que tenemos más y más.

Esto crea un incentivo para desarrollar lenguajes de muy alto nivel para disminuir los costos laborales de desarrollo y mantenimiento. Está bien si el código resultante utiliza más CPU y RAM de lo que sería un código de ensamblador equivalente a mano o máquina optimizado.

Creo que es increíblemente bueno. Recuerdo a Perl; Me encanta este idioma, pero es el menos confiable de todos los que he conocido. Python está bien, pero a la larga es inmanejable. Java no es para scripting, definitivamente.

Pero sé que la gente escribe guiones en Haskell; y mucha gente escribe guiones en Scala en estos días. También se usa sh funcional. Todo esto hace que las cosas sean más difíciles de romper y más confiables a largo plazo.

No solo es genial, es nuestra única esperanza. Las cosas no se están moviendo lo suficientemente rápido en esta dirección. El progreso se estancó alrededor de 1990 y apenas hemos empezado a recuperarnos.