EDICIóN GENERAL

Programadores antiguos vs programadores de hoy

#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.
#342 es lo que defiendo: la simpleza.
#377 simplonada != simpleza.

Con simplonada me refiero a una simplificación excesiva que obvia gran parte de la realidad que pretende describir, analizar o explicar.

Además la simpleza o la simplicidad, la sencillez, la elegancia... son terminos relativos y muy subjetivos. Un buen microframework enfocado a algo concreto podría entrar en la descripción de sencillez. Te ofrece la solución a una tipología de problemas concretos, de forma simple, bien modelada (ya sea en POO, Funcional o el paradigma que sea) y bien testeada sin querer abarcar una infinitud de casos posibles dónde pueda aplicarse dicha solución (Ej: Microframework HTTP, como flask, vs Web Full Frameworks, como Django).

Si nos referimos a UI, puede que sea sencilla de cara al usuario (lo que finalmente importa cuando haces una UI) pero conlleve cierta complejidad o una cantidad grande de código para llevarse a cabo. Código que si tienes que mantener tú o tú equipo en cada aplicación en lugar de depender de un Framework, tendrá más bugs y, encima, te saldrá más caro al necesitar profesionales especializados en ciertas tareas que a tu negocio le aportan poco y que sin embargo a otro (la compañía tras un framework, por ejemplo) le aportan mucho, acabando en una muy buena simbiosis.

Puedes obviar la realidad todo lo que quieras, está claro que no tienes argumentos para mantener tu postura inicial y por eso has acabado con una intervención de seis palabras que además tergiversa mi postura, algo bastante mediocre, como las simplonadas del artículo.

Por ejemplo, no has podido mantener tu afirmación de que meter Frameworks eleva los problemas de seguridad, cuando obviamente ha sucedido lo opuesto (acercandonos a la extinción de inyecciones SQL, por ejemplo).

Y así con el resto: calidad, mantenibilidad, complejidad accidental, testabilidad, coverage... la mayoría de indicadores han aumentado de forma sólida (no solo aparente) gracias a la existencia de todo tipo de frameworks, ayudando a atajar el problema que existe: (casi) todo el mundo quiere poner una Web o una App en el mercado pero no tiene recursos para financiar un proyecto que termine en un producto seguro sin apoyarse en soluciones generalizadas como librerías y frameworks, manteniendo a expertos en seguridad, actualizaciones cada vez que existe un problema, cambios en el código cada vez que hay un cambio en el protocolo HTTP o las capas más ligadas al hardware del lenguage, etc, etc.

Sinceramente, que una aplicación pueda hacer un "npm update", "sbt update" o "composer update" y resolver así un fallo de seguridad sin tener que intervenir en una línea de código porque el framework o librería de turno lo han hecho, es un alivio y ofrece una seguridad y fácilidad de mantenimiento nunca vista antes. ¿No hay aquí simpleza, sencillez o elegancia? Al menos yo sí la veo..

Eso sí, si crees que una buena solución informática es la más eficiente, la más cercana al hardware y que ahí radica la simpleza... no estás en tu momento, vuelve a cuando todo fallaba cada 2 por 3 y los programas tenían bugs y fallos de seguridad explotables en cada operación ofrecida, seguro que eran tiempos mejores y no es una idealización creada por un sentimiento de nostalgia :roll:

En resumen, tengo una visión del estado del arte que choca bastante con la del pesimista, sesgadísimo, parcial y mediocre artículo que enlazabas.

menéame