Barrapunto

Insisto, el hardware no es la panacea. Un hardware el doble de caro o dos años más moderno no va a hacer que un programa chapucero corra el doble. Simplemente no es así. Incluso aunque el programa esté bien hecho, el doble de potencia no significa el doble de rendimiento. No obstante, un buen diseño y gestión de los recursos sí puede suponer una mejora de dos órdenes de magnitud en el rendimiento, una reducción del 60% en el tiempo de respuesta o que pueda escalar de 10 a 1000 peticiones sin despeinarse. Te hablo todo de casos reales.

Un buen programador es un buen programador, PUNTO. Si lo cambias de C a Java y luego a C++ da igual. Un pequeño periodo de adaptación y seguirá haciendo las cosas bien. Son los malos programadores los que presentan resistencia a los cambios, los que pasan de hacer mal las cosas en Java a no ser capaz de hacerlas en absoluto en C#.

Tu último párrafo es una sarta de chorradas que no venía a cuento, profundamente desinformada y profundamente errónea. ¿Usar patrones es renunciar a encontrar una solución mejor? Vamos, que ni sabes lo que es un patrón. Eso es incluso más estúpido que decir que utilizar el framework de Java es renunciar a hacer tú uno mejor.

¿Programadores "artistas"? Vamos, que ahora resulta que o eres un chapucero o un artista, no se puedes ser un buen programador a secas...

El hardware no es la panacea, estoy de acuerdo contigo, pero el resultado del cambio de hardware o su duplicación suele ser visible de inmediato, y la inmediatez hoy en día es un valor en alza.
Si un programa esta medianamente bien hecho las mejoras no suelen ser tan drásticas, otra cosa es que sea un auténtico desastre o que no se pensaró en sus inicios para los requerimientos actuales, en ese caso tienes toda la razón.
"Un buen programado es un buen programador", eso no te lo crees tú, ni nadie. Un buen programador en C con 15 años de experiencia que se pase a Java no es igual de productivo que un programador medio que se haya criado con la POO y que haya programado durante 3 años en Java, pese a quien le pese. Después de cierto tiempo, no digo yo que se igualen o que incluso le supere. bueno eso depende del tiempo libre, la familia y las ganas que tengas. no es lo mismo tener 25 años que 35 años, todo se oxida.
Pues ese párrafo se basa en mi experiencia en el mundo del desarrollo del programador español. Lo que quiero decir que a la informática le faltan muchas cosas para llegar a ser una ingeniería. Todavía existen muchas malas prácticas, dando valor solo a tirar lineas de código y realizar las entregas en fechas sea como sea. He visto muchos desarrollos que no son ingeniería, ¿Por que se sabe que no son ingeniería?
No existe documentación de requisitos, ni análisis o diseño o la que hay está desactualizada, no hay histórico de cambios ni hay versionado. Si se creando una aplicación no hay planificación o la que hay es imposible y no se la cree nadie. El código no está normalizado, nomenclatura kafquiana, sin cabeceras, ni comentado, ni con posibilidad de generar documentación automatizada, o en el peor de los casos con código deliberamadente ofuscado. El conocimiento reside en un tío "imprescindible" que no puede ni irse de vacaciones, sea un crack o un mamón, etc. Y alguna o varias de estas cosas puede ocurrir y que el código sea digno de enmarcar si ese tío es un artista de la variable!!!!
No confundir programar de lujo con hacer ingeniería.
Un ingeniero prefiere tener a 4 tíos normales y no a un 1 crack más un inútil.
Yo recuerdo que hubo una época que los patrones y los framework no existían y los proyectos salían adelante.
Cuando había que hacer un programa para algo se hacia un análisis y un diseño propio para cada proyecto, luego era correcto o incorrecto, pero para cada proyecto se hacia un estudio personalizado total. Hoy en día, lo que se hace es un estudio para ver analizar el problema e intentar ajustarlo a un solución de patrón de diseño, no digo que siempre, pero si que lo hace la mayoría. Y si no lo hacen, es que una de dos, o son unos gañanes y no tiene ni puta idea de los patrones o al revés, es suficientemente bueno para plantearse crear su diseño totalmente personalizado para esa aplicación.
Te voy a decir un secreto, los patrones/framework son soluciones genéricas a problemas genéricos y suelen funcionar generalmente en la mayoría de los casos. Pero una buena solución personalizada, aunque requiere más análisis y más trabajo (Aunque sea modificando ligeramente un patrón concreto), da mejor rendimiento.
Yo no he dicho que si no eres un artista eres un chapuza, es más eso creo que son los casos mínimos, el 90% de la gente es normalita o mejor dicho, el tipo de trabajo, la falta de motivación o los plazos de entrega hacen que el resultado sea normalito. Sinceramente yo conozco a poca gente que haya definido un nuevo patrón de diseño, un nuevo paradigma o lenguaje de programación o un framework de relevancia. La mayoría de gente que yo conozco se dedica a las personalizaciones de paquetes de software de gestión (E