edición general

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

#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