EDICIóN GENERAL

Programadores antiguos vs programadores de hoy

#1 el Príncipe de Persia era una maravilla programada en ensamblador; pero para programar en ensamblador hay que ser informático, no basta un becario con un cursillo.

github.com/jmechner/Prince-of-Persia-Apple-II
#62 Al contrario. Para programar en ASM es más facil que C++ con las templates y aprendiendo cosas como mutex y semáforos.
#71 mutex y semáforos hay en C. ¿A qué te refieres exactamente?
#75 que asm es mucho mas sencillo.
#76 nunca he llegado a tanto en ensamblador. Lo máximo que he hecho son programas sencillos de entrada y salida de texto, o como mucho algún cálculo aritmético y poco más. Sin embargo, desde el desconocimiento, cuesta creer que sea más fácil.
#77 Es que no lo es. No hay comparación.
#76 Decir que ensamblador es más sencillo que C es no haber programado jamás en ensamblador. Ya sólo por la gestión automática de memoria en las llamadas a subrutina, te ahora una burrada de trabajo.

Y te lo dice alguien que ha programado ensamblador de 8086, 68000 y microcontroladores PIC.
#194 Después de tocar ASM para la GB desde Forth para cosas que si no irian demasiado lentas y sufrir la locuacidad de C++ me quedo con el primero. He dicho C++, no C. Dejad de confundid ambos lenguajes, que no podrían ser más distintos en concepto. C está tirado.

Confundir C y C++ si que es no tener ni puta idea de nada. C bajo Unix es como juntar carne asada con salsa picante o queso de cabra. C++ es un aborto que no debió haber nacido jamás. Go es lo que encarna lo que pensaron los creadores de Unix como el sucesor natural de C, cogiendo la filosofía de plan9 y sus compiladores (y cosas como dial() ) en un lenguaje donde la compilación cruzada está tirada.
#194 Me dicen de gestionar de nuevo manualmente la memoria (en asm) y me tiro por la ventana
#194 Buff, recuerdo las prácticas de la universidad en Ensamblador, recuerdo hacer una práctica que en una ventana escribías un texto largo y buscaba palíndromos, y te los mostraba... Lo que sudamos esa semana. Aún no se cómo lo logramos, solo se que yo me desesperé y mi compañero empezó a levitar y entró en trance... Nunca te estaré suficientemente agradecido, Raúl.

Por cierto, recuerdo programar Pic... Si lo hacías en C te quedaba sin espacio en seguida
#199 Disculpa. Me refería al #76 todo el rato. Es que no sé leer :wall:. He ido a por lana y he vuelto esquilado...
#207 Llevo un buen rato intentando entender tu flujo de mensajes. ¿Sabes que #199 también eres tú? xD xD xD
#355 No se que ha pasado... Me equivoqué al citar en mi primera respuesta y ahora nada tiene sentido. En cualquier caso no había sido un gran aporte por mi parte :foreveralone: :-D
#76 Esto cada vez se parece mas a forocoches.
#76 ¿En serio lo dices? ¿Por qué crees que nacieron lenguajes como C?
#247 Aqui han dicho C++, no C. C++ es una bestia parda.
#75 Eso es sencillamente falso, compañero. De hecho, es el motivo por el que existen C y C++. Por que el ensamblador era un infierno.

Ahora vendrá alguien a responder que programar en código máquina es mas fácil que en ensamblador...
#165 ¿el qué es falso?
#176 El comentario #75 que cito en mi respuesta.
#199 en ese comentario digo que hay semáforos implementados en C. ¿Eso es falso?
#165 ¡¡Y yo aún digo más!! Programar en binario es más fácil que en código máquina hexadecimal :troll: :troll: :troll: :troll:
#71 Si te refieres a que existen más herramientas para el desarrollador en C++, sí. Si te refieres a que es más sencillo en ensamblador que en C++ hacer el mismo programa, ni de broma.

En ensamblador puedes decirle exactamente a la CPU qué instrucciones ejecutar, y controlar entradas y salidas de forma directa, pero para ello necesitas un conocimiento absoluto tanto de la parte interna de la CPU como de los periféricos que estén conectados a ella.

Ésto en una Atari, un Spectrum, un Amstrad, un Commodore, es relativamente sencillo, por usar CPUs con pocas instrucciones y con pocas I/Os, pero a día de hoy en una CPU medianamente moderna es inabarcable.

Incluso para programar muchos microcontroladores y DSPs potentes de la actulidad, lo normal es al menos usar una HAL proporcionada por el fabricante, y si hay que usar ensamblador en una región crítica, se mete en la función de C/C++ donde sea necesaria y santas pascuas.
#87 Obviamente me refiero en un Z80 :-P

En Forth puedes llamar a ASM Z80 con una facilidad asombrosa.

Sé obviamente que hoy es imposible hacerlo, pero en segun que microcontroladores de AVR no es tan complejo como lo pintan. Y sí, he visto ports de Unix para un MSP con compilador de C y Ncurses en 512kb de RAM. Se perfectamente lo que es el ensamblador, gracias. Acabo de hacer un Hello World para CollapseOS.
#95 Perdona, no me había dado cuenta que hablabas de equipos antiguos.

Pd: Lo de UNIX en el MSP430 me sorprendido bastante, lo buscaré luego :-)
#95 en C puedes empotrar codigo ensamblador. Al final es como programé yo unas prácticas en la carrera para intentar hacer más eficiente mi código.

Si no recuerdo mal con las directivas de gcc_inline. Por lo que podías elegir como montarte el programa para ser más eficiente.
#71 hasta aquí he llegado.
Demasiado internet por hoy, ya.
#71 ni de broma, en mi opinión.

C y c++ es un paseo por el bosque del edén comparado con ensamblador.
#204 y C++17 ya es flotar en el nirvana
#62 El tema es que hacer algo como Prince of Persia en ensamblador ya es una locura, pero si pretendes hacer algo mucho más grande y complejo como se hace ahora es directamente inviable.
#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...
#62 También te digo una cosa, yo como adolescente de los 90 me vicié al ensamblador empezando por el maravilloso arte del cracking y pasando a cosas más complejas, y luego al llegar a la facultad tardé en pillar para qué querías variables locales a funciones y por qué no les molaba que todas fueran globales :shit:
#147 jaja precisamente lo poco que sé de ensamblador fué así mismo, de adolescente aprendiendo un poco de cracking, incluso sin haber empezado a aprender a programar. Recuerdo los XOR para los NAGs, cambiar condicionales para que hicieran justo lo contrario (validar un serial incorrecto)... También herramientas como Win32dasm, que habían aplicaciones que tenían seriales correctos en las string references xD y los depuradores como Softice y Ollydbg. Desempacadores de Aspack, UPX...

Luego ya hice mis pinitos con Visual Basic, Neobook (no es un lenguaje exactamente pero algo así), Delphi, etc. De hecho una de las primeras cosas que hacía eran crackme, intentando programar los trials de X días y eso xD
#147 Y no sirve usar "Elbereth".

menéame