EDICIóN GENERAL

Programadores antiguos vs programadores de hoy

#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.
#378 Antiguamente cuando conmutábamos un servicio con éxito de un CPD a otro descorchábamos una botella. O cuando sobrevivíamos al pico de más carga del año sin cortar el servicio, aunque haciendo operaciones manuales por el camino. Ahora conmuta solo y si está bien montado ni te enteras. Solo quería decir que en el mundo del hardware la complejidad también se ha incrementado mucho, para en ocasiones no ganar funcionalidad, o que no se note. Desde soporte de serie para cosas que no usas y no piensas usar a querer hacer una instalación pequeña de una maqueta de pruebas y tener que meterte con contenedores, virtualización...

Creo que aún les falta bastante a las FPGA para asaltar masivamente el datacenter, aunque tienen todo lo necesario. Habrá aplicaciones concretas en las que sobresalgan, pero la tendencia es la contraria. Incluso la electrónica de red dedicada se está sustituyendo por una pila software cada vez más grande y compleja, por ejemplo en en firewalls y balanceadores.

Pero vamos, si IBM perdió su supremacía en el Datacenter, ARM está encontrando su hueco y han surgido granjas de ASIC o GPU dedicadas para ciertas tareas no es descabellado que las FPGA tengan también el suyo. Y con una caducidad menor que las ASIC dedicadas. Aunque claro, mi bola de cristal necesita un pulido, porque el futuro no lo veo con claridad.
#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!
#241 no mezclemos el tocino con la velocidad
rapidez del telefono es independiente de la bateria. Ahora mismo puedes hacer una aplicacion muy mal programada, con imagines enormes y el tlf va a funcionar igual, eso no era posible con los primeros tlf
#268 Ya claro, que una aplicación tenga 750 librerías de mierda o que tenga embebido un chrome entero en vez de hacer una aplicación decente no tiene nada que ver ... verdad?
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....
#249 Vaya, creí que nadie iba a encender esa mecha :-D. Voy a tratar de ser breve, pero el tema da para mucho...

En primer lugar, todos más o menos hemos estado presentes en la evolución de la web. Cuando JS era el "lenguaje pegamento" para hacer las cuatro cosas que necesitaban programación dentro de una web estática. Pero con los años, la demanda de una web cada vez más reactiva y con una UX más completa fue desplazando más y más lógica de negocio al front end. Esto generó una época dorada del front end que dura hasta hoy.

Desde hace algunos años, el concepto de cliente servidor clásico, en el que un back end "compila" una web dados unos datos de entrada y genera un HTML "estático" de salida está muriendo. Ahora la web prácticamente se construye en tu navegador con JS (como en el caso de librerías como React o Vue y frameworks como AngularJS y Angular). La idea pasa por pedir al servidor la "receta" que viene en forma de scripts de JS, y ejecutar todo en front, de manera que las interacciones del usuario sean respondidas en el acto, y la información fluya entre servidor y cliente en segundo plano.

En paralelo a todo esto, la gente de google desarrolla chromium y junto con él, el motor v8 de JS dando resultados de rendimiento muy buenos. Como consecuencia de esto nace NodeJS, entorno de ejecución de JS en el lado del servidor y así se forja el ya famoso paradigma de "JS Everywhere".

Y aquí es donde entra mi opinión.

He trabajado con muchos lenguajes, arquitecturas y frameworks diferentes. Actualmente llevo casi 4 años como desarrollador fullstack JS. después de 3 años en ASP .Net Framework y ASP .Net Core. El hecho de tener el mismo lenguaje en cliente y servidor tiene una barbaridad de ventajas, como por ejemplo:
No tener que depender de librerías externas para el marshalling de JSON (ya que la notacion de objetos de javascript es reconocida directamente por el propio JS)
#281 Estoy en una situación parecida a la tuya... Todo el mundo odia Js, a mí me encanta...

Pero más allá de eso, yo creo que el éxito real de Js no está ni en los frameworks front (que sí), ni en Node (que también). Sino que Javascript es el primer, y probablemente único, lenguaje que cumple eso de "Write Once Run Everywhere" que prometía Java y que nunca cumplió. Y ese éxito, probablemente, se deba a que por el hecho de ser el único lenguaje interpretable en navegador han optimizado el intérprete de Javascript al máximo. Otros lenguajes interpretados como Python o Ruby no tienen intérpretes tan flexibles... no parece probable que metan un intérprete de python en relojes, o lavadoras, o neveras... Me da a mí que varios relojes ya llevan un intérprete de javascript... Las teles lo llevan, y las neveras lo llevarán...
#288 Totalmente de acuerdo. La idea es muy similar a la que yo comento. El hecho de que el intérprete y el propio lenguaje hayan nacido en el seno de los navegadores han hecho a JS partícipe del boom de la web. Pero creo que se habría quedado ahí de no ser por Node. El hecho de llevar un lenguaje sencillo y con buen rendimiento al lado del servidor lo ha puesto definitivamente en el mismo saco que Java y C#, dejando de ser un lenguaje de "scripting" al uso para asumir un papel mayor.

En cuanto al fundamentalismo anti-JS, una inmensa mayoría habla desde la ignorancia, pensando en scripts infumables incrustados en un head, "this" que son cualquier cosa menos "this", variables globales, etc... Sin embargo muy poca gente está familiarizada con ES 6/7 y Babel o con TypeScript y con que hace tiempo que están resueltas.
#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.
#345 igual es que me he vuelto viejo y tras 18 años haciendo lo mismo, tardo menos de esta manera que lo que tardan mis juniors en buscar como se hace en stackoverflow o en el manual de referencia de la librería.

Hicimos una pequeña competición hace no mucho, un chavalito con 1 año de experiencia (bastante decente, eso si) usando VUE contra mi usando vanilla js (solo js, haciendo document.createElement y appendChild).

La prueba era llamar a un Json, formatear los datos de una determinada manera y hacer un toggle de CSS al pinchar sobre ciertos elementos.

La teoría decía que el iba a ser mucho más rápido y productivo, la realidad es que sabe más el diablo por viejo que por diablo.

Y que mientras el decía "voy a mirar como era esto", yo picaba en mi notepad++ como el que escribe una carta a su abuela.

Me supo mejor la victoria que el mixto con huevo y el zumo de naranja que gané.

Luego les preguntas que es un shadowroot y no saben de que cojones les hablas.

menéame