edición general

¿Puede la retroinformática darnos mejores programadores en el futuro? Este estudio cree que sí

#16 Para mí, no hay nada como optimizar el código para hacer una aplicación mejor. Programar en ensamblador mejor programador, pero te dará la visión de cómo pensar un algoritmo para que corra más rápido.
#25 Ninguna duda en ello. Pero también es cierto que hay areas en las que será más importante saber ensamblador que en otras. Para muchas aplicaciones Android o webs, por decir un ejemplo, quizá te será más útil conocer patrones de diseño o conocer a fondo un framework o una librería que saber optimizar algoritmos. Aunque todo ayuda, claro.
#25 Depende... el for de C no tiene nada que ver con el for de python. El compilador tiene mucho que decir. Si te piensas que todos los for son como la instruccion que cuando el registro llega a cero, salta a una zona de memoria... vas listo.
#58 Pues depende. Si haces un for explícito en Python, funciona igual que el de C. El compilador (intérprete más bien) hará lo que le dices: desde 1 hasta 10, hacer esta operación sobre el elemento i.

Ahora bien, si lo que quieres hacer en realidad es aplicar una misma operación a todos los elementos de un array, puedes hacer directamente un map(), indicando el array y la operación que quieres hacer, y así el intérprete es libre de, si le parece, enviar cada una de las 10 operaciones a una CPU diferente, y ser tremendamente más rápido que la versión C.

Si el programador no sabe muy bien cómo funcionan las tripas de la máquina, a lo mejor piensa que las dos formas de hacerlo son iguales (semántica y funcionalmente lo son), pero el que alguna vez ha tocado las cañerías probablemente tenga en cuenta este tipo de matices.
#105 Ese supuesto procesamiento en paralelo podría ser más perjudicial que otra cosa porque lo ganado en paralelismo puedes perderlo con fallos de caché.
#141 Podría, podría... Claro que podría. Esa es la tarea del compilador, saber cuándo conviene y cuándo no. Pero haciendo los bucles explícitos, nunca podrás paralelizar, mientras que escribiéndolo de la otra forma dejas la puerta abierta para hacerlo cuando convenga.

Y al ritmo que va la informática, con CPUs de 8 y 16 cores en ordenadores de escritorio, lo de paralelizar hasta las chorradas más simples cada vez va a ser más importante.
#25 Sólo que la velocidad no lo es todo en la vida. Si empiezas, por ejemplo, a reescribir partes de tu código en ensamblador para que vaya más rápido, pues sí, irá más rápido. Ahora bien, si en 6 meses hay que hacer una modificación al código y tú ya no estás, el que le toque probablemente no entienda un pimiento y no sepa por dónde meterle mano. Incluso te puede pasar a ti mismo, es muy típico coger código propio no muy bien documentado y no saber qué coño hiciste. Y todo para optimizar una rutina que, muy probablemente, daba igual que fuera un 20% más o menos rápida.

El rendimiento de un código es un factor, pero ni de lejos el más importante. Es mucho más importante la mantenibilidad, y eso a veces implica escribir en lenguajes no tan eficientes pero más legibles, y dedicar menos tiempo a optimizar y más a documentar.
#103 En realidad yo no diría que hay factores más importantes que otros. Diría que los factores dependen del contexto.

Por ejemplo, si programas la New Horizons, prima mucho que tu código tenga el mínimo consumo de recursos posible. Cada miliwatio que ahorres de consumo al hacer una operación puede suponer que tu nave alcance un planeta nuevo o no.

No todo es la eficiencia, pero tampoco todo es la mantenibilidad. Los factores dependen del contexto.
#143 Claro, todo depende del contexto. Pero, naves espaciales aparte, yo diría que en un entorno empresarial típico es bastante más importante la mantenibilidad que el rendimiento, y normalmente se prioriza al contrario. Vamos, que si un programador dice "he conseguido que el código vaya el triple de rápido" todo van a ser felicitaciones y enhorabuenas, pero como diga "he comentado todo el código y he documentado el modelo de datos", más bien lo que se va a encontrar son resoplidos de sus jefes, e insinuaciones de por qué perdía el tiempo con esas cosas cuando podría haber avanzado el siguiente proyecto.

menéame