EDICIóN GENERAL

Programadores antiguos vs programadores de hoy

#108 Es inviable no por grande, sino por la variabilidad de arquitecturas y modelos de procesadores. Cuando programas en ASM se hace conociendo la estructura interna, cuántos registros tienes y puertos tienes, etc. Ahora eso no es habitual y se depende 100% en un compilador y un lenguaje un nivel por encima que te lo gestione todo.

Y la forma de programar era distinta, recuerdo pegarme el 80% del tiempo de desarrollo era sobre papel. Diagramas y diagramas, tablas y bocetos. Luego un 10% pasarlo a código y otro 10% probando y depurando. El jefe siempre nos decía que si teníamos los diagramas bien, el código era un mero trámite. Y tenía razón. Hoy en día ya no se programa así.
#164 Porque hoy en día los modelos son mucho más complejos y cambiantes. Tener las cosas en papel en forma de diagrama en lugar de en forma de código funcional es una perdida brutal de tiempo y esfuerzo, además de una forma fantástica de alejar las fechas de salida y asegurarte sacar un producto desfasado a mercado.

UML es una herramienta magnifica como complemento. ¿Para qué? Pues yo suelo usarlo en equipos para que se complementen commits o pull request especialmente complejas (un UML da una buena visión global), o para presentaciones entre diferentes equipos, etc.

Pero casi siempre como algo puntual y a posteriori, para describir lo que está hecho y no lo que se hará (que casi siempre tendrá cambios y terminará en un UML desfasado o esfuerzos extra que no aportan para actualizarlo).
#206 Como dices, los modelos actuales se "documentan" de diversas maneras, pero siempre con una visión global. Es decir, tendrás un globo con "enviar email", pero se queda ahí, no se detalla el proceso interno completo... y eso sí hacía falta con ASM dado que es un lenguaje que no se sigue fácilmente. Dependías de diagramas adicionales para visualizar un método complejo. Por eso se hacía ANTES del código. Era una buena práctica aunque no era imprescindible ni mucho menos.

Hoy con lenguajes modernos y los IDEs es muy distinto. La expresividad y estructura de un código del estilo "C" con sus llaves, tabulaciones y expresiones humanas lo hace muy fácil de leer y seguir, y te evitas el engorro del diseño previo a bajo nivel.
#227 claro, efectivamente, y si tenemos en cuenta que hoy en día C está desfasado en cuanto lo claro, (poco) verboso y conciso que puede ser un lenguaje...

menéame