EDICIóN GENERAL

Programadores antiguos vs programadores de hoy

#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".
#94 Descárgate un keygen de esos que se usan para activar un producto de forma pirata, de los que tienen incluso música y efectos gráficos: no pesan absolutamente nada.

Pero claro, están programados en ensamblador accediendo directamente a las librerías de Windows, sin capas intermedias para facilitar el trabajo. Hay hasta concursos con keygens falsos a ver quién hace mas con menos.
#94 Adminsitro Unix principalmente Solaris y HP-UX, y ahora más Linux porque muchos de los productos que quieren instalar el cliente ya están para Linux y ahora ya no te viene SAP y te dice "La base de datos principal tiene que ser un Oracle y estar sobre un Solaris", sino que te da más versatilidad.

Cuando comencé hacía mis pinitos como desarrolladora de bases de datos.

La complejidad que comentas también está en el mundo de los sistemas. Como el software también es más complejo es completamente inviable migrar un producto de HP-UX sobre PA-RISC cuyo último parche salió hace 19 años a Linux o a HP-UX sobre Itanium, que al menos existen repuestos harware. Al final lo que se hace es poner un cluster con máquinas Itanium, crear una IVM y dentro de la IVM un SRP (es decir, una máquina virtual y con un contenedor dentro) que emula el sistema operativo para PA-RISC a partir de una imagen de la máquina física original.

Antes tenías un servidor físico en un centro y otro en otro. Un servidor un host, o al menos una system board equivalía a un hosts, según cableado y jumpers. Alta disponibilidad manual. Cuando se hacía la conmutación de un centro a otro se hacía un servidor cada día e implicaba un montón de cosas, desde cargar un backup manualmente del servidor activo al servidor de respaldo a tirar una interfaz en los switches y levantar otra.

Es decir, siempre sabías cual era el servidor activo, nunca conmutaban solos (te acordarías, o estaría en la pizarra cual era). Siempre sabías cuales eran los discos en uso y como estaba configurada la red.

La maqueta de pruebas era un servidor viejo.

Ahora para instalar una maqueta que tenga cierto parecido a un servicio que va a estar en producción cuando no tienes nada necesitas instalar y configurar una infraestructura de virtualizacón con alta disponibilidad y además todos los productos y capas que van en ello, todo para instalar una imagen docker que luego vas a personalizar para tu uso.

Y cuando la insfraestructura virtual falla o está mal configurada (pasa más veces de lo que parece en ciertas organizaciones grandes) arreglarlo no es trivial porque no tienes ni idea de donde está el fallo. Y si, ahora los servicios conmutan virtualmente ante fallos de hardware, y la conmutas manualmente con un click, pero mi experiencia me dice que ponerlo en marcha es un dolor de gónadas enorme, un tiempo de despliegue inicial y aprendizaje mucho mayor, para luego no tener tantos beneficios.

Eso si, si eres una organización enorme te sale a cuenta. O una organización de crecimiento exponencial.
#221 Válgame Dios, más que un comentario parecía un procedimiento jajaja. Cuando estoy fuera de horas de trabajo, salvo por privacidad y seguridad, me olvido de muchas cosas de lo que hago.

Cuidado con la tecnología. Mal empleada puede pasar factura, como invertir demasiado tiempo en ella, ser espiado/a, tener alguna fuga de información sin ser consciente, etc.

Por lo de la virtualización, soy propenso a virtualizar lo mínimo aunque reconozco sus ventajas, pero, desde mi punto de vista, si se hace a través de zonas de Solaris o LXC en Linux mejor :-)

Por cierto, ¿qué piensas de los FPGA, al margen de la información que pudiera haber por ahí?

Saludos.
#94 Por curiosidad, ¿por qué lo querías sin disco duro? Yo tuve un Amstrad PC2086 con disco duro de 30 MB xD , y no me imagino la pesadilla que sería tener que arrancar y usar el sistema operativo siempre desde disquete. Aparte de que sin disco duro no era posible tener Windows, que yo sepa. Ni siquiera el Windows 2.0 que usaba por aquel entonces...
#287 Los inicios de la informática que estudié fueron de niño, en un aula con ordenadores de pantalla monocromo. Relamente hubieron dos aulas diferentes, una por curso. La primera fue con monitores de fósforo verde, y en la segunda algunas pantallas pasaron a ser de blanco y negro. Estudiábamos conceptos del GW-BASIC y el famoso Logo.

Los ordenadores no tenían disco duro salvo 2 o 3 en el segundo curso, por lo que decidí que mi ordenador se asemejara a estos. Quería hacer mis experimentos y no tener la comodidad de los discos duros que ya palpé en el aula. Eso sí, el color de mi monitor me maravilló. VGA de 256 colores era brutal (precisamente, igual pasa a día de hoy). Una ventaja de no tener disco duro es menor ruido.

El concepto de la informática ha cambiado para el usuario en los últimos 30 años. Realmente es ventajoso e importante conocer y llegar a los límites de una máquina, pero lo más importante es que sepamos dónde está nuestra información en todo momento y qué se hace con esta, algo verdaderamente complicado en estos tiempos que se quiere - casi que obliga - digitalizar todo.

Ah, igualmente pude tener unos cuantos MB de disco gracias al Iomega ZIP de 100MB al cabo de unos años :-) .
#85 el hardware de hoy en dia es muy rapido, puede funcionar con casi cualquier entorno sin problemas, incluso si la aplicacion no está hecha eficientemente
#180 Claro, por eso todos los teléfonos con 30000 mah de batería y 4 aplicaciones les dura la batería 3 meses. ¡Claro que si guapi!
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....
#85 yo sigo trabajando el DOM con vanilla y jQuery no me parece tan fantástico.

Mátame.
#338 Los nuevos frameworks tratan de que el programador no toque "a mano" el DOM. Por eso han tenido tanto éxito. Yo llevo un par de años con React, y ha sido un gustazo que el programador manazas del equipo no pueda hacer de las suyas.
#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
#101 ¿Ese no es un conjunto de artículos que habían salido en El tamiz, recopilados en forma de libro? Porque si es ese... ¡¡Me encanto!!
#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.
#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.
#196 Sí, entiendo esa visión. Es parte un problema de pasta también. Si tienes que hacer algo y no tienes tiempo suficiente para aprender otra tecnología, pues lo haces con lo que tienes (con lo que sabes).

Pero es un problema complejo. También los habrá que no quieren aprender. Otros que no tendrán la capacidad de comprender lo que hay bajo el framework (Javascript a pelo, por ejemplo, es muy duro) y otros mil motivos que no se me ocurren. :-)
#201 Yo en realidad pienso que por lo general nadie es "realmente culpable", se junta un poco de todo, como dices... tema de costes, las empresas al final están para ganar dinero, y a nosotros (los que curramos en el sector, picando...) nos gusta que a fin de mes nos paguen.

Sobre todo a los que somos de vocación nos gusta hacer las cosas lo mejor que sabemos y aprender, y gastar el tiempo necesario en dejarlo bien, con tiempo, experiencia y la capacidad de cada uno esto va siendo menos costoso con el tiempo, pero visto globalmente desde arriba, en que lo que tienes es un mix de "capacidades" al final... lo que quieres es vender el producto o cobrar por lo que haces para tener beneficios y pagar a tu gente, así que muchas veces desde arriba lo que quieren es tenerlo pronto y "cumpliendo", si se puede hacer mejor, más rápido... pero el cliente no va a pagar más ni posiblemente se vaya a enterar... no interesa, es más coste, y en consecuencia la presión va a tenerlo rapidito y baratito.

A mi me han llegado a contar de alguna empresa, pequeña, en la que directamente eran sinceros con el asunto, básicamente lo que se decía a la plantilla es que esfuerzo cero en testing, facilidad de mantenimiento... que funcionase y a correr, pq por lo visto un altísimo porcentaje de lo que desarrollaban no estaba mucho tiempo en el mercado y según sus cuentas eso era dinero tirado.

Luego tampoco es que venga sólo a veces de arriba, quien no tiene un compi hipermotivado que tecnología nueva que aparece tecnología que quiere meter en el producto, dándose casos de productos en los que con el tiempo acabas teniendo 3 o 4 lenguajes, 5 frameworks, movidas de estas instaladoras de módulos, sistemas de compilación, virtualización diversa... lo que iba entrando por que iba a simplificar el mantenimiento o la gestión al final la acaba complicando, por que donde antes el personal tenía que dominar un sistema de compilación o un lenguaje ahora se encuentra con que hay partes en X, partes en Y, 2 sistemas de compilación por que fue imposible quitar del todo el anterior o por que versiones a las que aún hay que dar soporte usan el anterior...
#135 por favor, aunque te entiendo, no metas TCP y UDP y su corrección de errores como ejemplo de “ir con pinzas” o de que funciona de casualidad
#325 Joder, es una forma de hablar. Nada funciona por casualidad, pero no es que sean los protocolos mejor especificados del mundo. Están repletos de parches que hacen que funcionen bien pero está por decidir si esos parches son genialidad que solucionan problemas o chapuza que aguanta el tirón.

Pero que todo es así, he visto tripas de bastantes sitios muy grandes, sistemas que usa muchísima gente, sitios que piensas "buah, esto tiene que estar niqueladísimo" y no, no lo está. Tiene sus mierdas dentro que huelen igual de mal que la de cualquier otro sistema. Pero ahí están, corriendo, dando servicio a millones de personas.
#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"
#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
#315 El problema es el mercado, amigo. Nadie lo niega.
Mientras tanto necesitamos máquinas descomunales de potencia innecesaria y gasto energético exagerado para tareas básicas.
#336 un móvil te parece que tiene un gasto energético exagerado?

Y en el campo de los PCs?

Pentium 4 3.2Ghz - TDP 82W
i7-8550U - TDP 25W

El 8550U es 22 veces más rápido que el P4

Vaya, no me lo esperaba
#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.
#316 Discrepo.
Meter más niveles de frameworks no es más que agregar superficies de ataque al sistema. El programa principal debe estar creado según los principios de desarrollo seguro y buenas prácticas, no es necesario "añadirle cosas para protegerlo"

Un UI sofisticado 1º) Generalmente no es imprescindible, es un lujo añadido y 2º) Se puede hacer en un sistema ligero (incluso en HTML5)
#335 Claro que puedes discrepar pero, por supuesto, te equivocas profundamente.

Meter frameworks es ajustarse a la realidad de que no todo el mundo que ponía una aplicación o servicio informático podía permitirse expertos en seguridad o suficientes programadores para adaptar los cambios por leaks, al externalizarlo en equipos que lo hacen por ti se ha mejorado muchísimo el nivel de seguridad medio.

No sé si me expliqué mal o algo, pero es una verdad innegalbe. Obviamente no me refería a que los frameworks sean el camino a seguir para implementar un sistema muy concreto y que necesite una seguridad nivel CIA.

Y no, no es un lujo añadido, es una realidad necesaria o seguiríamos con PCs de 4kb de ram que usaría gente muy concreta. Para llegar a donde hemos llegado hoy y generalizar el uso de la tecnología eran necesarios esos "lujos".

Podemos valorar si donde estamos es mejor o peor, pero las simplonadas que afirmas no son más eso, simplonadas.

menéame