EDICIóN GENERAL

Programadores antiguos vs programadores de hoy

La verdad es que es muy interesante. Los programadores de antaño estaban más relacionados con la programación de bajo nivel, o un alto nivel pero directamente compilable, sin pasar por "entornos virtuales". Ahora están de moda estas virtualizaciones y y los lenguajes interpretados, por lo que requieres más potencia de cálculo para hacer lo mismo y, sobretodo, muchísima más memoria RAM y disco.

Se podrían hacer programas que ocupen poco espacio en entornos virtuales como Java, pero ya requieres ese entorno. To do se complica.

Yo recuerdo el Prince of Persia 1 que ocupaba nada menos que un disquete de 3 1/2 de baja densidad (720K) y me lo pasaba super bien en un PC de 640KB de RAM (también funcionaba en 512KB de memoria menos la consumida por el S.O.).
#1 El problema son los frameworks. Para una aplicación de chichinabo, si quieres programarla rápido y a un presupuesto bajo, tienes que tirar de frameworks y librerías externas. Entonces esa aplicación que normalmente sería un puñado de ficheros de pocos kb cada uno, termina teniendo decenas de miles de ficheros.

Y si resulta que la aplicación es grande, también necesitas librerías y frameworks porque facilitan el mantenimiento, los tiempos de desarrollo y a veces incluso el cliente exige la tecnología que desea.
#1 #3 Leeros esto:
tonsky.me/blog/disenchantment/es/

Al que me adhiero totalmente.
#79 Lo que dice es cierto, pero actualmente es inasumible ser productivo programando de esa forma. La única forma de crear un producto rápidamente y barato, es usar algo que ya te lo da casi todo hecho, aunque sea ineficiente. Y tú dedicarte solamente a pegar trozos.

Las librerías y frameworks aparecieron por muchas razones:
- todos estábamos escribiendo las mismas funciones
- al usar librerías, que están testadas, evitas errores
- trabajar a bajo nivel se vuelve criptico a medida que el proyecto crece
- los frameworks ayudan a que todos los miembros del equipo hagan un trabajo ordenado

Aún recuerdo la pesadilla que era trabajar con el DOM directamente en javascript. Una simple librería como jQuery cambió aquello radicalmente. Y todos habíamos escrito nuestras propias funciones que ya venían incorporadas en esa librería. Y así todo.
#79 #85 No soy programador (soy de sistemas) pero sí hice alguna cosilla en programación. No me iba mal, no, pero decidí rechazarla, quizá por el tiempo que invertía, y para meterme en puñetas virtuales o "frameworks" como bien dice squanchy prefiero ni acercarme. Aunque siempre tuve cierta curiosidad por el ensablador (aunque requiere muuuchas hooras).

La idea está en que hemos llegado a un momento en que, a diferencia de lo que se programaba hace 20 o incluso 30 años y para hacer algo similar, y que corresponde a lo que nos quejamos muchos, todo es muchísimo más pesado, sobretodo en la programación en entornos Windows o incluso móvil, Todo es parecido, pero orientado a la "facilidad" de programación y no a la eficiencia. En cuanto a "librerías", que yo sepa, estas ya se usaban en C con la programación en alto nivel (que sepa, aquí me meto ya en terreno pantanoso para mí :p).

Ahora me iré de madre un poco. Cuando tuve mi primer ordenador en casa (el Amstrad PC3086 que comenté con @barcelonauta), vino con este el Lotus 1-2-3 versión 2.01. Qué pasada. En un disquete de 720K tenía una estupenda hoja de cálculo con el que hacía gráficos de barras normales, apiladas y sectores, y creo que líneas también. Los imprimía en la matricial que me venía. Y si me apuráis... ¡monté DOBLE PANTALLA en mi XT para el Lotus y funcionaba, ya lo creo! Macros incluidas. Ahora está todo orientado al gráfico, pero a nivel funcional... psé. Sí, bueno, el copiar-pegar (el texto bien manipulado no necesita copiar-pegar), pero si nos parásemos a pensar, poco más. ¿Iconitos? ¿La web? ¿TLS requiere GUI? ¿No os acordáis del IRC? :-D

Los entornos gráficos son más "bonitos", pero menos funcionales realmente.

Aprendí con consolas MS-DOS, tuve MS-DOS en mi casa y mi ordenador me vino sin disco duro, pero no porque no los hubiese sino porque me acuerdo como si fuese ayer (con la ilusión que me desbordaba) que le dije a mi madre que lo quería "sin".
#79 mierda! mis ojos!!!
#79 Un conocido ha escrito un libro que por lo visto va de un programador de la vieja escuela que sufre en la industria actual: Eugenio, memorias de un informático. 10 verdades que ocurren en los proyectos
#79 Pues yo no. El tío compara win95 con Android.

En Win95 tenías que buscar e instalar los putos driver de tu equipo a mano. Instalar Internet o cualquier otra cosa podía ser un puto infierno. En Android todo viene de serie y todo funciona sin hacer nada y la variabilidad de dispositivos y piezas de multitud de fabricantes distintos es abismal, por no hablar de tamaños de pantalla, resoluciones, etc. Obviamente eso no es gratis. Tienes los controladores y los sistemas dentro del SO. Del tirón.

El precio a pagar por la sencillez es que todo venga dentro de golpe sin tener que hacer cherrypicking de lo que necesitas.

Estoy de acuerdo en algunas cosas que dice pero ni mucho menos en todas. Y él lleva 15 años en esto, yo solo 10, pero tampoco soy el más nuevo del barrio. Las páginas webs y sistemas de hace 10 años eran rápidas y pesaban poco. Y eran una puta mierda. No tenían ningún tipo de funcionalidad, el mantenimiento era nefasto y no había que hacer que una web se viese bien en un puto reloj, en un Ipad, en un Iphone, en una TV de 52 pulgadas, no tenían que tener una API decente, no pintaban ni mucho menos imágenes enormes, el JS era simple pero tenían que cargar una mierda flash que era insegura por defecto...


No creo que el código actual sea peor que el de ayer. Son igual de malos. Las cosas funcionan casi de casualidad, y eso lo sabe cualquiera con unos tiros pegaos. ¿O acaso el TCP no tiene un sistema de redundancia de datos para recuperar que se pierde parte de ellos? ¡Y en UDP se asume que se pueden perder, simplemente consideramos que no importa que pase! Y estamos hablando de cosas básicas sobre las que funciona todo, pero es que... todo es así. Toodo va con pinzas. Yo hace ya tiempo que pienso que eso es el desarrollo, es lo que hay.
#79 Y no, en mi mundo, una aplicación que te dice “voy a destruir una parte de tu trabajo, pero te dejo elegir cuál” no está bien.
¡Joder alquilen que lo entiende por fin!
#79 Seguramente has escuchado este mantra: “el tiempo del programador es más importante que el tiempo del computador”

Curioso, usaba otra frase, "es mas barato el kilo de metal que el kilo de carne"
#135 Yo creo que no está diciendo que el código sea peor, si no que como se cuenta en el enlace que ha puesto #79 (muy bueno) en general todo se complica hasta la naúsea, también lo han comentado varios. Ahora en general no es que todo tire de librerías más o menos gordas y que bueno, es pasable, puede que el binario y todo lo que arrastre ocupe más pero más lento no tiene por que ser, al final llamas a las funciones que llamas y por lo general las que ya están aceptadas por la comunidad van a ser mejores que las que puedas hacer tú. El problema es que ahora mucho SW tira de frameworks completos que simplemente muchos desarrolladores usan pq es lo que saben, aunque lo conozcan muy bien (si sólo tienes un martillo de oro todo te parecerá un clavo).

Creo que somos muchos ya los que hemos visto en el trabajo como se acaba implantando un entramado de capas, instaladores de módulos, virtualizaciones innecesarias simple y llanamente por que alguno que cae bien o tiene mucha labia vende la moto y el de los galones da el OK.

Al final para hacer una puta mierda de aplicación, tienes ahí un sindios de cosas que complican la entrada de gente nueva por los palos que hay tocar, complican el mantenimiento, aumentan el tamaño y reducen el rendimiento.

Cada vez me gusta más programar para Arduinos y similares por la cantidad de basura que no tienes que tener en cuenta y con la que nadie te va a venir a molestar.
#10 Y además de lo que dice #20 es que el salto del Wolfenstein era brutal. Y eso sin ser verdaderamente 3D. Doom incorpora novedades como juego en red y otras que justifican el aumento de requisitos.

Requisitos mayores pero visualmente mejor y con juego en red. Lo que denuncian algunos comentarios como el de #79, que suscribo por completo es que el software ha ganado tamaño sin apenas añadir funcionalidades. Cualquier aplicación de Android tipo "la calculadora" pasa de ocupar unos kilobytes ocupar unos megabytes.

Un editor de texto mínimamente avanzado con resaltado de sintaxis y funciones de búsqueda avanzada ocupan decenas o cientos de megas. El Turbo Pascal ocupaba dos disquetes con las todas las librerías para empezar a programar. Y me refiero a un IDE con librerías y todo el toolchain necesario para generar binarios ejecutables. Un editor de texto sin librerías ni nada ocupa una barbaridad (por ejemplo el notepad ++ portable que utilizo son 22 Megas solo el editor de texto y algunos plugins que vienen con él que jamas es utilizado). Solo utilizo reconocimiento de sintaxis para un par de lenguajes. El instalador de atom para windows 7 y superior son 170Mb. Instalado son más.

Cualquier aplicación de tablet pero que puede ejecutarse en móvil es inmensa porque entre otras cosas trae los assets para ejecutarse en decenas de tamaños de pantalla diferentes. He incorpora librerías de manipulación gráfica cuando solo quieren necesitan mostrar los botones de la interfaz.

Y ese crecimmiento no es como comparar Wolfstein 3D con Doom, o Doom II con Quake. Es comparar en editor de texto con el que vas a editar texto con un editor de texto con el que vas a editar texto con los mismos atajos de teclado. No es comparar Oblivion con Skyrim y este con lo que venga después dentro de un par de años o cuando sea.
#79 el artículo falla muy pronto, en cada sector se tiende a minimizar el uso del componente más costoso, que en el caso de la programación es el equipo de desarrollo. Todos esos frameworks, librerías, virtualizaciones... existen para que el coste de desarrollo sea muy inferior
#79 un enfoque bastante simplón y muy sesgado desde un solo punto de vista. la mejora en seguridad, por ejemplo, ha sido brutal gracias a Frameworks y Librerías... obviarlo en ese análisis me parece estúpido...Por no hablas del UX, los nivels actuales de complejidad de UIs no serían mantenibles sin lirerías que te abstraigan, no al menos por compañías pequeñas/medianas.

Y así con mil cosas que ese post o menosprecia o ni siquiera nombra.
#3 uno de los problemas.
Otro, es que no se considera, ni se tiene en cuenta, en fase de diseño o de implementación ningún aspecto de rendimiento o consumo de recursos.
"Eso ya se irá ajustando" es la frase clave.

Y ahora con los contenedores, peor. 'Ya si eso metemos más réplicas" está causando estragos.

Cuando llegas y te pones a explicar a un Junior que hay ciertas cosas que comprometen el consumo de memoria, es como hablarles en klingon. Si ya te metes en algún tema de concurrencia de hilos y deadlocks les pierdes más allá de toda esperanza.

Y hablo de programadores de back. Si nos pasamos al front, la cosa empeora y mucho, sin que haya ningún motivo que de verdad justifique esa falta de interés.

Como siempre: son generalizaciones y como tales, un poco injustas: estoy seguro de que aquí nadie es así, y todos los javeros del lugar os conocéis la estructura de la VM, y todos los de JavaScript entienden la gestión de hilos en Node y tal.
#3 Tranquilo, para ésto hay una solución que se llama Cloud: AWS, GCloud, Azure, ... En el momento en que te toca pagar directamente las ineficiencias es cuando ves que realmente necesitas optimizar y crear mejor software. A las empresas les va a pasar lo mismo, tendrán dos opciones: crear un software muy bueno y muy caro pero que tendrá poco coste operativo en la nube o crear un software nada óptimo mucho más económico pero por el que tendrá que pagar mes a mes un coste operativo alto.
#3 Y el problema es? Los discos duros van baratos y el tiempo es dinero.
La complejidad, tamaño, necesidades de escalabilidad, la cambiabilidad del entorno (SO, Libs, Drivers, Hardware)... no tienen nada que ver con las que había antes. LAs App de antaño son juguetes en entornos ultraestables en comparación con las actuales que han de ofrecer una resiliencia infinitamente mayor.

#3 Estoy en completo desacuerdo. Cualquier aplicación medianamente compleja hoy en día se hará con un Framework (o como algunos se denominan ahora "MicroFrameworks") , sea este público o inhouse, pero un Framework al fin y al cabo (de hecho serán muchas veces varios si hay microservicios).

El problema, aunque prefiero verlo como la causa, es que las aplicaciones de hoy son monstruosamente grandes, han de ser altamente escalables y lo más mantenibles que se puedan hacer, todo estoy limitados por el tamaño de los equipos que no puede irse de madre.

Otro debate que sí me parece más interesante y realista es el de buen Framework vs mal Framework, que si creo que limita lo optimizada que pueda estar la aplicación.

El objetivo de un framework es ofrecerte un entorno en el que los problemas que tiene el 90% de las aplicaciones ya estén resueltos y dónde puedas conectar las partes que resuelven los casos de tu negocio.

Un buen framework te ofrecerá formas de limitar su aparición a la capa más externa de tu proyecto (ej: capa HTTP, Manejo del DOM, Routing...) un mal framework te obligará a hacer las cosas de una manera e infectará tu aplicación hasta lo más profundo.

Un buen framework te ofrecerá modularidad y posibilidad de no incluir el código que no necesites (ej: Tree Shaking).

Un buen framework te ofrecerá una IoC atractiva porque tiene unas interfaces solidas y bien definidas, además de un buen sistema de inyección de dependencias permitiendo que tu codigo esté libre de detalles de implementación (lenguaje, frameworks y libs es lo que son, detalles de implementación).

Un buen framework se encargará de adaptarse a los cambios de esas capas de infrastructura (HTTP, Window API, APIs del lenguaje, libs de sistema) minimizando el impacto que pueda tener en tu aplicación. Esto hace precisamente que, si no es un proyecto de chinchinabo, puedas centrarte en lo que te hace viable: tu capa de negocio sin necesidad de decicar tanta cantidad de esfuerzo a todas esas capas externas y comunes a todas tus aplicaciones (seguridad incluida).

También podríamos hablar de como se usan en muchas ocasiones los Frameworks, que algunas personas no terminan de entender que NO son librerías.

#6 Pero el problema ahí es de análisis y diseño de la solución, no el framework en sí, el problema es de quien decide que ese framework y ese lenguaje son los correctos para dar solución a determinado problema. Es como si yo diseño un sistema de seguridad en aviones con Visual Basic, el problema no es el lenguaje, es la elección.

Si no se entiende que el lenguaje, el framework y en general toda la infrastructura es un detalle de implementación y que ha de ser elegido pensando en el producto a implementar... ningun framework o lenguaje serán buenos. Es como usar Java para un SO, mientras Java puede ser una buena elección para implementar Servicios SOAP, nunca lo será para implementar un SO, pero el problema no será Java, será de quien lo eligió para implementar esa solución.

De todas formas siempre hay excepciones y creo VS Code, no parece siquiera Electron, me sorprendé muy gratamente siempre que lo uso.
Me metí aquí creyendo que por fin podría salirme del monotema y la política y ahora quiero volver...

El 90% de los comentarios parecen escritos por gente que no conoce la industria del software. Pero voy a intentar arrojar mi rayito de luz sobre el tema.

- Cuando entras en un proyecto, no escoges framework, lenguaje o tecnología. Solo unos pocos tienen tales privilegios. Así que #3, tienes razón a medias. En la vida real no existen las aplicaciones de "chichinabo". Ergo los frameworks son una consecuencia derivada del mercado al que se enfrenta la industria. El espacio y la ram son muy asequibles hoy en día. Se puede ver como "hacer un puente de acero cuando a lo mejor si fuese de madera soportaría el peso requerido". Hoy sí, pero mañana igual no. El precio que pagas por el framework es por curarte en salud cuando vengan "las nuevas especificaciones".

- El odio a Javascript y todo el ecosistema a su alrededor es común en las redes, pero marginal entre los expertos. #6 citaba tres aplicaciones, y pasaba de lo particular a lo general de forma muy discutible. Se le olvidó hacer mención a Visual Studio Code. Escrito en TS/JS, corre sobre electron (node) y desarrollado por ni mas ni menos que microsoft. Es el mejor IDE que he utilizado, y la lista es larga. Mira si es bueno, que el motor intellisense de Visual Studio que tanto nos mola se ha migrado a node.

- #1 toca un tema interesante. Los lenguajes interpretados comenzaron su auge en el contexto de la multiplataforma. Compilo una vez (a bytecode) y lo ejecuto en cualquier PC, móvil, cafetera o dispositivo que soporte el runtime de Java (JRE). Esto fue especialmente importante con la llegada de Android, entorno en el que mayoritariamente se programa en Java. (Muy a mi pesar por que creo que el lenguaje es un truño). ¿Por qué ahora JS lo peta si ya estaban ahí la JVM de java y el CLR de .Net? Si a alguien le interesa respondo contando mi punto de vista.

- #85 en mi opinión pone un poco los pies en la tierra. Lo verdaderamente triste es que hoy en día, enfrentarte a un proyecto supone asumir unos plazos imposibles, y los clientes, ya muy inmersos en la era digital, tienen muy poca tolerancia a fallos. Especialmente a aquellos que detienen el sistema parcial, o totalmente. Por eso es necesario utilizar herramientas que te permitan hacer el trabajo de forma rápida y segura. A veces esto te obliga a tomar ciertas decisiones, como la de utilizar muchas bibliotecas de código por que ya están testeadas. Pero eso no quiere decir que el resultado tenga que ser malo, ni mucho menos.

Volviendo a los juegos de game boy, la comparación es absurda. El cliente final ya no se conforma con música de 8 bits y 160 × 144 píxels. Ahora lo que vende son los reflejos súper realistas del agua, ciudades tan grandes que tal vez no llegues a recorrerlas enteras, cada uno de los edificios debe parecer real, los pedestrians deben tener una IA súper avanzada y saber cuando cruzan la calle, las explosiones nosecuantos, las físicas newtonianas y así podría seguir hasta el infinito. Por eso ahora necesitas cosas como Unreal Engine que ya de por sí es enorme y consume muchos recursos.

Esto al final se puede transportar a los frameworks, lenguajes y lo que se os presente. Es que el mundo entero tiene nuevas especificaciones.
#198 "¿Por qué ahora JS lo peta si ya estaban ahí la JVM de java y el CLR de .Net? Si a alguien le interesa respondo contando mi punto de vista."

Me interesa, y mucho....
#3 El problema son los costes. Hoy en día, cualquier juego necesita mucho personal. Incluso tirando de engines ya hechos, librerías de recursos ya hechas, arte ya hecho, hacer un juego es un esfuerzo importante de tiempo y dinero. Si además quieres unos valores de producción altos, el presupuesto se dispara.

Antes un equipo de una docena de personas te hacía un AAA en relativamente poco tiempo; en los ochenta, meses y siendo la mitad de personas. En los noventa, si se era técnicamente ambicioso quizá se tardaba algo más (digamos de uno a dos años, tres a lo sumo si la cosa se desmadraba) y normalmente se construían sus propios motores casi siempre. En los dosmiles, para terminar un juego en ese intervalo de uno a tres años necesitabas un equipo muy grande, cohesionado y bien dirigido, partiendo como mínimo de algún tipo de middleware y normalmente con un engine completo ya funcional.

Ahora, los últimos call of duty o assasins (que son productos digamos prefabricados, donde el molde "ya está hecho" y se construye a partir de ahí) necesitan no uno, sino varios estudios trabajando codo con codo para sacar los proyectos adelante.

Por otro lado, antes tenías un hardware simple: una serie de registros, unos chips que configurabas y programabas adecuadamente y aprovechar los recursos de la máquina, no había más. Era muy fácil programar (una curva de aprendizaje al principio elevada, eso si) porque tenías acceso directo a todos los recursos, todo lo que hacías tenía coreespondencia directa con el hard. Más adelante, se programaba en sistemas que no controlabas directamente, tenías que tirar de drivers y de llamar al sistema operativo. Ya las cosas no eran tan directas, no todo funcionaba en todos lados, había complejidades extra y ya tenías que tirar de liberías escritas por ti o por otros. Ya los programas no son tan pequeños, tenían que arrastrar un buen puñado de funcionalidades que no se usaban pero que venían en esas librerías. El siguiente paso son los engines, que de ser especializados en según qué tipo de juegos y por tanto muy ligeros, empezaron a engordar para poder ser muy flexibles y abarcar todo tipo de aplicaciones. Hoy en día puedes hacer un juego con unreal engine para móviles donde sólo el engine ocupa más que juegos completos en cdrom de los 90. Pero es el precio a pagar por el que cualquiera pueda desarrollar un juego y publicarlo.
#3 No para todo hace falta un framework. Un programador experto debería tener los suyos propios, muy específicos y de pico peso.

El problema es el uso de.frameworks de.propósito general
#3 Frameworks............

Un programador de verdad usa mariposas  media
#1 Un lenguaje como TCL/TK o Jimtcl no ocupa una mierda, es una VM y es bastante rapido.

Y por cierto, sobre entornos, la maquina virtual Z (Zork, Curses y otros) rulaba hasta en un Spectum +3.
#9 Abuse (que también es de disparos pero a alienígenas) funciona sobre TCL/TK :-D
#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.
#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.
#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:
#1 no estoy solo... :foreveralone:

Yo con el tiempo he flipado de que juegos como ese o Pinball Fantasies, Monkey Island, Lemmings, Golden Axe, Eye of the Beholder, Budo Khan, Stunts, Battle Chess y bastantes más que me dejo en el tintero funcionaran decentemente en un triste 8086 a 10 mhz y 640 k de ram que heredé de una oficina... Entonces sí se optimizaban a tope los juegos, vaya que sí...
#1 La diferencia es que antes la memoria y la capacidad de procesado costaba más que el tiempo del programador, ahora es al reves. Es así de sencillo.
#159 El problema es que cada vez se construyen mas castillos de mierda encima de otros castillos de mierda con esa excusa ya que es demasiado tarde para hacer las vosas bien y demasiado caro volver a hacerlo todo de nuevo.

El problema es que la ingenieria de software se ha vuelto el proyecto mas complejo que existe y para abordarlo se ha llegado a la conclusion de que es mas facil hacer parches y soluciones que simplifican los problemas a base de perdida de rendimiento, fiabilidad, etc... No creo que exista tal ahorro, solo a corto plazo.
#1 Los programadores de Spectrum si que eran buenos, con 48K de memoria hacían unos pedazo de juegos increíbles. Y encima en aquella época había un buen número de empresas españolas de videojuegos triunfando en todo el Mundo, igualito que ahora.

Made in Spain, Opera Soft, Zigurat,...

es.wikipedia.org/wiki/Edad_de_oro_del_software_español
#257 En esta época hay un buen montón de empresas españolas triunfando en el mundo, o integradas en grupos de estudios más grandes.
#257 #265 Edad de oro poco, son juegos bastante mediocres comprados con los britanicos. Y los eslavos les daban mil vueltas.
Lo siento pero tenia que decirlo. La Abadia del Crimen no puede competir con Where Time Stood Still.
Y si nos vamos al port de Elite, la edad de oro no llega a ni a la edad de la quincalla.
#257 Tengo el número 1 de Microhobby. Todavía tengo en la memoría el día que lo compré. Un recuerdo muy claro, y muy bonito.
#1 Bueno, pero es que es parte del progreso. Hoy en día disponer de 1gb es más barato que 1Mb, según el año que elijas. Y tirando dos líneas de código puedes hacer cosas que en 1996 no se podían ni imaginar, y ni siquiera haría falta ser un experto.

menéame