Portada
Hace 5 años | Por lalarrañaga a tonsky.me
Publicado hace 5 años por lalarrañaga a tonsky.me
El desencanto del software [EN]

El desencanto del software [EN]

 tonsky.me

He estado programando durante 15 años. Recientemente, la falta de cuidado por la eficiencia, simplicidad y excelencia de nuestra industria ha comenzado a afectarme, hasta el punto de deprimirme por mi propia carrera y la informática en general.

Etiquetas

DE3C548D-E347-406A-A60F-E6BBD322CAB7 7.4k 395

Comentarios

ElPerroDeLosCinco

Muchos nos formamos como programadores en los tiempos en que era necesario optimizar cada byte de disco ocupado y cada paso de procesador. Han pasado los años y el hardware actual no exige ese cuidado. Ahora priman más otros criterios, como la usabilidad, la legibilidad o la mantenibilidad del código. Hay gente a la que le está costando adaptarse y sigue refunfuñando por el derroche de CPU, como mi abuelo refunfuñaba cuando veía que en casa se tiraba el pan que sobraba, o mi abuela veía que tirábamos calcetines en lugar de zurcirlos.

V 90
K 587
Cidwel
editado

No hay nada que me guste mas que sentir la destrucción del universo cuando añado un boilerplate con un overhead inmenso de dependencias para hacer una simple pantalla de ayuda..... en react.... con redux y saga.....

y entonces va npm install. Aprovecho los 3-10 minutos de descargar software que aparentemente ya debería estar en caché y me voy a por un café... entonces cobro mi salario

Soy parte del problema.

Luego nos falla una dependencia que simplemente vale para arreglar un string y arde troya. Definitivamente los programadores retroalimentamos la rueda que nos dá de comer. Creamos soluciones que automatizan problemas. Pero los haremos ineficientes para continuar manteniendolos. Nos hartaremos a vender soluciones para problemas que el cliente realmente no necesita. Soy feliz

V 58
K 410
lalarrañaga
autor

Me quedo con esta cita: "As a general trend, we’re not getting faster software with more features. We’re getting faster hardware that runs slower software with the same features"

V 51
K 359
Nova6K0
editado

#7 Te olvidas de los 200.000 scripts en Javascript para ver que hace o no el usuario, que datos se les pueden birlar y esas cosas... que antes apenas existían.

Salu2

V 37
K 297
mr_b

#2 Y aún así tirar el pan y no zurcir los calcetines sigue siendo un derroche que no deberíamos hacer. Pues lo mismo con los recursos de la máquina, porque quizás hoy nos podamos permitir desperdiciarlos, pero no sabemos los problemas energéticos que tendremos en el futuro. Y no te creas que volver a la optimización va a ser cosa de un momento.

V 33
K 262
D

Tiene toda la razón.

Un tema que a mi me preocupa, y del que no estamos tomando conciencia todo lo rápido que deberíamos, es del impacto energético que tiene el software. No es una cuestión de tiempo humano, sino de cuantos recursos de nuestro planeta va a gastar un software por culpa de no estar bien optimizado. Está claro que lanzar un programa en un ordenador personal no tiene un impacto significativo, pero cuando hablamos de escalas de millones de servidores corriendo un software, el impacto puede llegar a ser muy grande.

V 27
K 238
kucho

#2 y al mismo tiempo los usuarios se te quejan de que para correr tu aplicacion hace falta el doble de recursos que tienen sus equipos corporativos. pero la culpa es del usuario.

V 24
K 194
Shotokax
editado

#2 a mí si me importa que un sistema operativo me folle 6 GiB de RAM por ejemplo, pero a lo mejor es que me estoy haciendo viejo.

V 21
K 175
D

#4 "sin razón aparente"

Solo que antes una web era 1KB de texto y una imágen GIF de 120x80, y ahora una web implica 300KB de código en 4 lenguajes diferentes, imágenes de alta resolución, video en streaming, fuentes embebidas... luego el prefetching y prerenderizado de los enlaces principales de esa web para acelerar todo lo posible la navegación... Encriptación con criptografía de 2048 bits, un buen puñado de certificados para analizar, con sus CRLs y sus mierdas...

V 19
K 161
Nova6K0

#2 Ese es el error el pensar de porque hay mucha potencia bruta se puede desaprovechar. Antes era impensable porque el hardware era muy poco potente. Yo digo que es más por vagancia y por sacar productos rápidamente porque solo interesa el dinero, de hecho no se piensa en posibles fallos que pueden lastrar un programa (sea una aplicación, videojuego) y luego pasa lo que pasa.

Añadiendo que algunas empresas, no se a que se dedican en la fase "beta" o de testeo del programa, porque se le cuela cada error que tela.

Salu2

V 16
K 147
robustiano

#2 Tu abuelo sigue teniendo razón, tiramos demasiadas cosas y los recursos son finitos...

V 15
K 126
c

#2 Lo que prima ahora es desarrollar rápido y barato.

Esa es la raíz del problema.

V 15
K 115
redscare

#2 Bueno, si y no. Una cosa es derrochar unos ciclos de cpu y otra que y una puta web tarde 20s en cargar y el scroll vaya a pedos porque usa 5 frameworks con 3 millones de dependencias. Los weblogic de mi curro tienen tanta mierda que tardan 20min de reloj en arrancar en unos bicharracos de servidores con tropecientos cores y gb de ram. Estoy con el autor en que se nos han ido los frameworks de las manos.

V 10
K 86
Kr0n0

Depende del tipo de programación. Si se trabaja en desarrollo en microcontroladores a bajo nivel aún es necesario arremangarse y tirar de JTAG y volcados de memoria más que de Stack Overflow.

V 8
K 85
m

#15 Ya veras cuando las prisas, la nula optimización del código de la IA y los algoritmos "a lo loco" creen una pseudo Skynet...

V 8
K 83
D
editado

#30 no has entendido nada. Coje 12 librerias para hacer un proyecto, cada lib con sus dependencias, algunas incompatibles entre si. Crea un monstruo lento y gigantesco en un entorno de programación que devora el hw de una maquina potente y nueva y tarda 10 min en compilar. Espera que tu producto falle en una actualización de la plataforma en la que corre o que este sujeto a dependencias, problemas de seguridad, escalabilidad y mantenimiento por usar código que se actualiza cada 2x3. ect. se refiere a eso entre otras muchas cosas.

V 9
K 83
redscare

#29 Skynet se colgará con un null pointer al intentar destruir el mundo, no hay problema lol

V 11
K 82
ElPerroDeLosCinco

#13 No digo que se deban desaprovechar los recursos del hardware. Digo que el autor se está desencantando del oficio porque ya no se presta tanta atención al rendimiento como a él le gustaría. Todos querríamos hacer un software super-optimizado, porque apreciamos la belleza y la elegancia de un proceso eficiente. Pero hay que saber adaptarse y aceptar una solución de compromiso entre lo que queremos hacer y lo que se nos pide.

V 8
K 81
D

#3 (Despues de leerlo entero)

Degenera muy rápidamente en un rant de persona mayor lol

Le falta ver que vivimos en un ecosistema competitivo donde prima sacar nuevas features lo más rápido posible, por encima de sacar la solución más eficiente ("Move fast, break things"). Es la época del "efficient-enough", si una empresa tiene que elegir entre desarrollar una feature en 3 meses o tardar 9 meses y que sea 10 veces más rápida y ocupe 100 veces menos, siempre va a elegir la primera opción.

V 9
K 80
redscare

#30 Si es es tu conclusión tras leer el artículo, es que no lo has entendido.

V 8
K 74
D

Cada vez más gente que ha estudiado otras cosas dicen ser "ingenieros" o "desarrolladores" porque han hecho un curso de unos meses o han hecho un blog siguiendo un tutorial. Es asqueante el intrusismo que hay, y los efectos resultantes. Al menos en el mundo web todo va de saber cuantos más frameworks mejor, luego ya hacer algo pensando primero mejor lo dejamos para los idiotas.

Un coñazo.

V 9
K 65
D

#93 Como dijo un compañero de trabajo en mi departamento:
>>Nunca hay tiempo para hacer las cosas bien, pero siempre lo hay para hacerlas dos veces.

Fin de la cita.

V 8
K 63
derethor
editado

Yo llevo programando bastante más de 15 años, y creo que el artículo es una visión parcial.

Hay dos tipos de programadores.

1. Los que montan soluciones. Estos descargan librerías de componentes, y montan una solución rápida y sencilla de mantener.

2. Lo que montan los componentes de bajo nivel. Son los que optimizan y mejoran el código.

El problema es que hoy en día, las soluciones requieren una barbaridad de componentes, que antes no hacía falta. Pero si analizas cada componente por separado, no me parece que sea mal software. No creo que los que programan react sean malos programadores. Desde luego, lo que programan la VM de javascript no son malos programadores. Pero hoy en día para hacer un interfaz web necesitas muchísimos componentes distintos.

La filosofia de "lo importante es la claridad del software, no del rendimiento" te mete en el grupo de los montadores de soluciones. Salarios más bajos en general (el tope lo marca el presupuesto del cliente)

la filosofía de optimizar y mejorar te mete en el grupo de los "desarrolladores de componentes". En general, es más sencillo crear un modelo duradero y cobrar más dinero a largo plazo.

En el articulo, habla de soluciones finales montadas por componentes, y ahí es donde está el problema.

V 7
K 62
D
editado

#2 Han pasado los años y el hardware actual no exige ese cuidado. Ahora priman más otros criterios, como la usabilidad, la legibilidad o la mantenibilidad del código. Hay gente a la que le está costando adaptarse y sigue refunfuñando por el derroche de CPU

¿Usabilidad? ¿Legibilidad? ¿Es una broma?

Los programas eran bastante más usables hace años. Más feos, sí, ahora son muy bonitos, vale, ¿pero usables?, para nada, la gente confunde la estética con la usabilidad. Antes eran más simples, intuitivos y con una interfaz más estandarizada. Encontrabas las cosas sin problemas. Ahora ponte a probar iconos hasta que des con el correcto.

Y mantenibles... eso es otra historia, y no es una excusa para el estado del software actual.

V 8
K 61
m

#2: Si, pero si son los usuarios los que refunfuñan y desinstalan tu flamante APP superusable (no mucho más que lo mismo en consola) y superlegible (algo que C permite si pones comentarios), a lo mejor el problema es tuyo.

V 6
K 59
D

#81 para que necesitas imágenes 4k en un teclado?

V 9
K 57
D

#4 Dejate de mariconadas....
http://lynx.invisible-island.net/lynx2.8.9/index.html

V 4
K 56
D

Traducción libre: "Soy un chapuzas al que le pone burro sacar hasta el último milisegundo de tiempo de procesador, aunque eso signifique pasarse por el forro las prácticas que hacen el código mantenible y mínimamente legible para otros programadores. Tampoco me gusta utilizar frameworks y prefiero tirarme días o semanas haciéndolo todo de 0 aunque el código no sea crítico y vaya a introducir millones de bugs por intentar reinventar la rueda."

No sé tío, si tanto le mola la eficiencia que cambie de sector y se pase a programar microcontroladores con memoria limitada en C y directivas de compilación por todas partes.

V 10
K 56
u

#2 A JAVA le gusta tu comentario.

V 5
K 55
ollupacre

#15 Es que no es sólo la optimización. A mí me pasó lo mismo hace 10 años y deje el desarrollo para irme a sistemas.
La programación descuidada, líneas y líneas de código inútiles, bucles dentro de bucles porque no se sabe usar el SQL, y clases kilométricas por doquier. La mayor parte de programadores solo saben usar tal framework y poco más.
Ni siquiera son conscientes de porque un for dentro de un for puede llevar tu aplicación a tiempos de procesos absurdamente elevados.

V 8
K 55
inar

#14 Y tenemos como prueba la cantidad de webs que mágicamente han mejorado su velocidad de carga al tener que adecuarse a la nueva protección de datos europea.
CC. #7

V 6
K 53
D

#52 Yo soy de esos bichos raros que, si tiene que elegir prefiere la programación a bajo o medio nivel. Pero soy una excepción, todos mis amigos informáticos trabajan o en web o con entornos de muy alto nivel, y muchos no conciben programar en otra cosa. Les hablas de C++ y se ríen de ti, dicen que "eso ya no se usa". Así surgen aberraciones como Electron...

V 5
K 52
C

#2 Disiento:

1. Programador excelente de vieja escuela: Piensa en la RAM, disco duro, ancho de banda, procesador y sus programas son optimizados al máximo, sus obras se miden en bytes"

2. Programador excelente de nueva escuela: "Instala el framework gordo de moda, componentes pesados de moda, cualquier servicio por si acaso, solo piensa en terminar así use el equivalente al algoritmo de burbuja en sus programas, su unico pensamiento es terminar las mil y una funcionalidades, sus obras se miden en gigabytes"

¿Usabilidad? ¿Legibilidad? ¿mantenibilidad? Eso son las típicas excusas de los usa "frameworks con obesidad mórbida", la razón real es: "solo se programar con el framework rechoncho y no tengo tiempo, ni quiero aprender sobre optimización de código".

V 5
K 49
Conde_Lito

#81 ¿Una letra ocupa mucho?

Acabo de hacer la prueba, una W, de color naranja además, a una resolución de 3840 x 2160 (4K) con su transparencia y todo guardada en formato PNG ocupa la friolera de 109Kb, con lo que el teclado completo ocuparía unos 5.5Mb.

W

comment_25326658 media
V 5
K 49
i

Solo hay que comparar un navegador web de hace 10 años y uno de ahora. La RAM se la come sola sin razon aparente.
Estoy por probar Netscape y ver como tira...aparte de las incompatibilidades CSS...debe ser una delicia...

V 5
K 48
D

Muchos de los problemas es el frameworktitis que tenemos actualmente.
Todo el mundo utiliza framework que trabajan sobre framework que a su vez trabajan sobre frameworks. Realmente, un ingeniero de verdad, estudiaría ese framework y se daría perfecta cuenta que con el primer frameworks ya tiene todo solucionado. Y lo peor, es que las empresas lo primero que te dicen es: ¿Conoces el X de la version 5?. ¿No? ¿Que conoces solamente el X de la version 4? Joder pues ya no estás actualizado. Aunque el X de la version 5 está en Beta.

V 5
K 48
m

#7: Vale, justifica ahora el 85% restante de la memoria RAM consumida.

V 4
K 47
t

#54 Pues bastante, sí. Si quieres hacer código eficiente y te pones a programar en C con fragmentos en ensamblador (para aprovechar las instrucciones especiales del nuevo Core i14 de novena generación), pasan dos cosas:

- El código lo entiende el que lo escribió... las dos semanas posteriores a haberlo escrito. Buena suerte luego manteniendo eso
- En cuanto Intel saque el Core i14 de décima generación, probablemente haya que reescribir parte del código para adaptarlo, lo cual me lleva al punto anterior. Ya no quiero ni imaginar qué pasa si quieres que funcione en otro sistema operativo, en un móvil o en la CPU de otra marca.

Los frameworks javascript serán lentos de cojones, pero escribes un programa y funcionan en un PC, en un Mac, en un móvil o donde le eches. Eso también tiene un valor.

V 5
K 47
D
editado

#30 #40 y otros...

Si leeis los links aparecen varios ejemplos:
- Un modulo que importa la enciclopedia britanica entera suponiendo un 93% del codigo del modulo para dar la definicion de una palabra en el 'about'.
- Otro modulo enchufa una foto de 13MB como broma.
- Otro modulo da like automatico cada vez que se instala a un post de twitter.

Una cosa es no utilizar frameworks. Otra cosa es usar un millon de mierdas que no sabes lo que llevan dentro.

V 4
K 47
t

#21 Es que no es que se desperdicien recursos en sí, sino que se están priorizando otras cosas por encima del rendimiento. Y eso no es necesariamente malo, siempre que no se abuse.

Con los frameworks javascript de hoy en día, será verdad que son lentos e ineficientes. Pero al mismo tiempo escribes una vez el programa y funciona en cualquier ordenador del planeta: Windows o Linux, PC o Mac, escritorio o móvil. Intenta hacer eso con un programa súper optimizado escrito en C, verás qué risa cuando tengas que escribir y compilar para una docena de plataformas diferentes. (y me quedo corto) Y luego mantener todas esas ramas de código sincronizadas y al día, además probablemente reescribiendo partes importantes cada vez que Intel lanza los nuevos i3/i5/i7 de nueva generación, o sale el nuevo Snapdragon XXX.

La memoria es selectiva, y muchas veces sólo nos acordamos de lo bueno, pero ya nos hemos olvidado de lo que no era tanto. Y de cómo esos frameworks tan chungos de hoy día hacen triviales cosas que antes eran una pesadilla.

V 5
K 46
frankiegth
editado

#1. Es mucho peor que eso, incluso la gente que paga más por el hardware recibe cacahuetes con el software que viene por defecto.

V 4
K 45
pedrobz

#29 No, Skynet al ver su propio código tan horrible matara a los programadores y luego se suicidará.

V 5
K 45
Varlak
editado

#21 joder, menos mal, alguien con dos dedos de frente... el dia de mañana, cuando el codigo sea tan complejo y, chapucero que las cosas no funcionen, nada sea seguro y todo consuma una barbaridad de tiempo y recursos, , ese dia nos echaremos unas risas.

Siempre he sabido que iba a serun cascarrabias cuando envejeciera, pero lo que nunca me esperè es que ano mis 33 años tuviera que decir "los programas de ordenador ya, no son lo que eran". Me desespero cada vez que mi flamante ordenador de trabajo que era ciencia ficcion hace una decada, miles de veces mas potentes que el que llevó al hombre a la luna, se bloquea con las cosas mas sencillasnormal, y esto lo escribo mientras mi outlook acaba de abrir un correo nuevio (y da gracias si no peta)

V 4
K 43
lalarrañaga
autor
editado

#5 algo de eso hay, sí, supongo que en un equilibrio está la virtud. Pero hay también mucho software comercial que debe ser una castaña y en el que el desarrollo ágil no explica por si solo su ineficiencia (o castañez).

Por cierto que el fulano que lo escribe es ruso, un tal Nikita, de los Nikita de toda la vida de Novosibirsk: http://tonsky.me/projects/

V 4
K 41
D

#100 Explicamelo

V 3
K 41
w

#13 Bueno, no creo que sea para nada el tema de vagancia, si que es mas bien la necesidad de sacar productos rapidamente. Esto no es porque a la gente no le interesen los fallos, es sencillamente que si quieres tener un producto muy optimizado te toca hacer todo desde cero.

El articulo tiene un punto interesante, pero es demasiado idealista. Se usan muchisimos programas y tenemos software sobrecargado por usar bibliotecas sobrecargadas, vale, pero ahora dime tu que haces si necesitas un servidor de aplicaciones. Te montas tu propio jetty/tomcat/loquesea? Y si quieres montarte tu propio servidor de aplicaciones, crees que va a ser mas seguro que cualquiera de los ya existentes?
Lo mismo vale para la gran mayoria de bibliotecas que se usan, es que la reutilizacion de software es algo muy basico y que tiene los siguientes puntos a favor:
1 - Es mas rapido coger algo que existe que hacerlo tu (no hay que reinventar la rueda)
2 - Si hay un producto que esta siendo actualizado durante un periodo largo de tiempo, lo mas probable es que este mas optimizado y tenga menos agujeros de seguridad que un producto nuevo.

El reutilizar software nos permite progresar. Claro que se van a arrastrar errores y la optimizacion se puede ver resentida, pero la capacidad de seguir produciendo mas software es lo que nos permite crear productos cada vez con mayor velocidad y conseguir avances en todas las areas.

Estoy de acuerdo con el mensaje de fondo, pero no con la forma en que lo ha contado, ha usado cosas puntuales y ha exagerado para conseguir su objetivo, creo que es exagerademente negativo.

V 5
K 39
ur_quan_master

A mí me pagan el rato que estoy en la empresa. Luego si quiero programar algo chulo lo hago fuera.

V 4
K 37
carcadiz

#88 Porque son las que ves en tu móvil. Si tienes una pantalla 4k, necesitas una imagen 4k o se va a notar tela en contraste con el resto.

V 3
K 37
S

#2 Siempre nos quedará javascript

V 3
K 36
D

#16 No, no lo verá.

Skynet tomará conciencia de sí misma y destruirá el mundo.

V 3
K 36
D

#15 El problema del que se queja el autor es que esa solución de compromiso no existe. Tampoco predica reescribir todo en C super optimizado. Pero es que estamos en el otro extremo, donde hay capa de mierda sobre capa de mierda, y donde acabas usando webpack para "arejuntar" toda esa basura y sacar una app en electron que ocupa un monton de ram, y va de pena, y donde al cabo de 15 dias ya no compila porque las librerias de npm son menos de fiar que cualquier politico de por aquí.

V 4
K 35
Candidatas
14
meneos
tecnología Bitwarden lanza su propia aplicación Authenticator gratuita y de código abierto [ENG]
9
meneos
tecnología Satélite encontrado después de 25 años perdido en el espacio
21
meneos
tecnología Detectan vulnerabilidad crítica en GNU C Library con 24 años de antigüedad
17
meneos
tecnología "El coche eléctrico sigue siendo prohibitivo". El precio y las dudas para cambiar los coches de gasolina estancan las ventas de eléctricos en Europa
7
meneos
tecnología Las ventas de coches electrificados siguen sin avanzar
7
meneos
tecnología Optimus, el robot de Tesla, se venderá a fines de 2025: ¿qué podrá hacer y cuánto costará?
6
meneos
tecnología El Rabbit R1 es solo una app Android en un hardware muy caro
6
meneos
tecnología Usar la IA como herramienta militar, ¿su momento Oppenheimer?
32
meneos
tecnología Consejos para dejar de alimentar las redes del fascismo en Internet
5
meneos
tecnología Sparkles, el perro robot de Boston Dynamics que baila para homenajear al Día Internacional de la Danza
14
meneos
tecnología Supermium: Un navegador Chromium para Windows XP, Vista, 7 y 8.x
9
meneos
tecnología La Mega Drive llega a España
6
meneos
tecnología Investigadores de HKU Engineering descubren la clave para lograr células solares orgánicas eficientes y estables (eng)
8
meneos
tecnología Doom scroll
5
meneos
tecnología Palas de madera para reverdecer la industria eólica
8
meneos
tecnología RiMusic: la mejor alternativa gratuita a Spotify
10
meneos
tecnología PROSOLAR BIRDS, El original invento desarrollado en España para proteger los paneles solares de los excrementos de los pájaros
25
meneos
tecnología musicForProgramming ();
6
meneos
tecnología Cuatro meses de cárcel para Changpeng Zhao, fundador del mercado de criptomonedas Binance
Shotokax
editado

#10 así sois los programadores de software propietario, por eso yo intento no utilizarlo.

V 4
K 34
D

#7 Esos scripts que dices, como comenta #14, son el 15%. El resto es mierda que bloqueo con Ublock Origin.

V 3
K 34
M

#2 Depende mucho del tipo de aplicacion, en una de escritorio quizas te interese dedicar tus esfuerzos en generar codigo bien estructurado y claro, para que sea facilmente mantenible.

Pero en otro tipo como servicios con muchos usuarios simultaneos, aplicaciones en tiempo real, sistemas embebidos con bateria limitada.. me consta que sigue siendo muy importante la optimizacion. Por ejemplo un servidor de streaming que soporte la mitad de usuarios que la competencia estaria fuera de mercado por muchas opciones que tenga.

V 5
K 33
yemeth
editado

#2 Yo empecé siendo de los que medían cada maldito byte, y tengo cada día más claro que lo importante a día de hoy es diseñar y encapsular correctamente. Y con ello un uso apropiado de patrones de diseño para llevarlo a cabo.

Dentro de un buen diseño ya podemos hablar de optimización orientada a tamaño, a uso de CPU, o lo que toque.

No obstante hay ejemplos como programación web, móvil o videojuegos donde sigue siendo importante la optimización si no quieres hacer un producto inusable.

V 3
K 33
c

#96 Los gráficos vectoriales ya si eso, para otro día.

V 4
K 33
t

#82 Algo de razón lleva. Primero nos convencieron de que meter librerías en las aplicaciones era ineficiente, y teníamos que usar servidores de aplicaciones con servicios comunes. Pero luego, una década después, no ha habido cojones de resolver los problemas de las interacciones entre aplicaciones en un mismo servidor (o el simple problema de desplegar una aplicación sin tener que reiniciar todo), y ahora lo más cool es que cada aplicación se ejecute en su propia instancia del servidor de aplicaciones dentro de un contenedor Docker. La misma mierda que teníamos al principio, pero con más capas que al final no aportan nada.

V 3
K 32
G
editado

#2 y el nieto en vez de usar el.pan para hacer pan rallado o usar los calcetines para limpiar el polvo, seguramente lo tire. Qué quieres que te diga, me quedo con lo que hacían tus abuelos.

V 3
K 31
lutarK999

Yo creo que la clave del artículo está casi al principio: "programmer time is more expensive than computer time"

Algo eficiente, casi seguro, llevará más tiempo de desarrollo que "lo primero que salga para salir del paso" que es lo que se hace en la mayoría de empresas de desarrollo...

V 3
K 31
mr_b

#328 Mi comentario es el #21.

Pero es que el problema no es la energía demás que pueda consumir un software, que puede ser irrelevante o no, dependiendo de cuánto se ejecute ese software. El problema está en cuántos recursos se están invirtiendo cada año en diseñar y fabricar nuevos procesadores más potentes para mover el software cada día más ineficiente. Pero no es sólo eso, es que también estamos desperdiciando recursos en sustituir todos los procesadores que dicen que están ”obsoletos” por otros nuevos para mover el software, cuando los procesadores antiguos están en perfecto estado y funcionarían a la perfección con un software optimizado.

¿De verdad que lo que cobrarían los ingenieros para mejorar el software sería mayor que todos los recursos desperdiciados porque no lo hagan?

V 1
K 31
lalarrañaga
autor

#10 brillante!

V 2
K 30
chulonsky

Esta noticia de ayer, que habla exactamente de lo mismo, se hundió en la mierda.
Cada programador de la generación anterior piensa que el software actual está hinchado. [Eng]

Hace 5 años | Por oraculus_reload... a blogs.msdn.microsoft.com
Publicado hace 5 años por oraculus_reloaded a blogs.msdn.microsoft.com

Cada programador de la generación anterior piensa ...

 blogs.msdn.microsoft.com

V 3
K 29
D

#48 No creo, ante este comentario:
"Este código es una basura contemporánea, que tardará como 10 segundos en hacer una tarea que realmente se realiza en 200 ms si se optimizara el código de verdad"
Obtuve este:
"No seas panoli, el hardware es más rápido, no necesitamos optimizar el código, va a ir rápido"
¿Adivináis cuanto tardaba en ejecutarse esa rutina? -> 11s y aún lo veían bien. [De esto hace cerca de 8 años, pero la línea se mantiene]

V 2
K 29
Trublux

#81 Es un teclado, valdría con SVG.

V 2
K 29
mr_b

#117 Siento decirte que sí se desperdician recursos. Y te lo digo por experiencia propia en cuanto a “sobreingenierizar” el software, empezando por tantas y tantas capas que luego, resulta, que no eran necesarias porque sale el siguiente framework que funciona igual con la mitad de cosas.

Y pongo tu ejemplo: javascript. Pero no javascript en web, sino javascript en interfaces de usuario en entornos de escritorio. ¿En serio? ¿En serio que no hay lenguajes compilados, no interpretados, con los que no se pueda construir un framework de interfaz gráfica portable y eficiente?

V 2
K 29
D
editado

#9 Yo tiré por otro lado y ahí sí que toca ser ingeniero y no te lo saca un tío con únicamente un curso de programación.

Porque toca programar, saber de electrónica, de protocolos de comunicaciones, de automatismos, de integración con bases de datos y Scada... y la verdad es que soy mucho más feliz profesionalmente.
(y encima la velocidad de proceso y gestión de memoria suele ser muy importante)

El mundo web me quemó rapidísimamente.

V 3
K 28
D

Estamos en la era ridicula. Los medicamentos no curan, los productos se rompen, las noticias no informan, los politicos roban, la educacion adoctrina. Que esperabas? Habra k esperar que caiga este estúpido sistema del dinero y las competencias. El negocio hoy está en la mediocridad

V 3
K 28
f

#81 Un teclado 150MB no se sostiene por ningún sitio.

V 3
K 28
PacoJones
editado

A mi lo que me toca los webs es que muchas veces se intente reinventar la rueda, y lo que ayer servía perfectamente, hoy ya no sirve y hay cuatrocientas soluciones para hacer lo mismo. No es cuestión de no reciclarse o actualizarse, es que llega un momento de tu vida que molesta estar continuamente oyendo "esto es el futuro de la programación, si no lo utilizas eres un mal programador, no estás en la onda".

V 3
K 27
redscare

#49 El problema es que no hacemos ninguna de las dos cosas lol

V 2
K 27
D

#84 Porque se les ha acostumbrado a las interfaces de alto nivel. La gran mayoría de programadores Java no saben como funcionan internamente las colecciones que usan, ni como reservan memoria ni nada. y por eso para buscar elementos recorren arrays completos en lugar de usar maps que por clave apuntas directamente a su contenedor esperado. Y demás cosas. ¿las ordenaciones? Se mean encima como les digas que les programes una en arbol (algo basico en C). La gente ya no sale ni con nociones básicas de los cursos. Hoy ya es al segundo compañero que le tengo que explicar que es la clausula finally (el otro fue otro dia y tiene 3 años de experiencia). Y es algo basiquisimo en la gestion de errores.

V 2
K 27
apetor

#129 Macho, mira lo que me has respondido: "El compilador en C optimiza mejor que tú, lo siento. El problema son mierdas como Electron.". ¿ Tu crees, por un segundo siquiera, que eso ha lugar con respecto a lo que he puesto en #98 ? Cuando precisamente he dicho que el ensamblador no se usa por optimizar.

El ensamblador, usarlo, se necesita, no solo para drivers, kernels y embedded ( que es a lo que me dedico, pero en PC ), tambien para otro tipo de software que, si, es bastante nicho. Pero esta el usarlo y esta el conocerlo bien y controlarlo, para ser mejor desarrollador, saber depurar problemas dificiles e incluso para, en el lenguaje de alto nivel que sea, programar mejor.

V 2
K 27
Conde_Lito
editado

#96 ¿Y no se podría hacer lo mismo con un tipo de fuente?

Aún así es lo mismo, una letra, la W por ejemplo, con una resolución de 3840 × 2160 con su canal alpha y todo para hacer la transparencia metida por ejemplo en un PNG ocupa la friolera de 109Kb...

V 2
K 27
comadrejo
editado

#c-9" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3014333/order/9">#9 Los mayores proyectos bicicleta que he visto en mi vida como administrador de sistemas han sido producidos por empresas de Ingenieros Informáticos/Telecos y profesores de universidad.

El caso mas sangrante es el siguiente:
Empresa IBEX35 entra en el negocio del pago electrónico. Sus clientes finales son gobiernos, consorcios de transportes, etc...
Opera en 4 países y en hora punta llega a picos de 100 ventas por segundo.
El aplicativo de frontales donde llegan los "teletipos" de terminales embebidos, el "middleware" y los esquemas de BBDD en Oracle fueron creados y eran mantenidos por esta empresa de Ingenieros/Profesores de Software.

El departamento de negocio del cliente pide una especie de Panel de mandos para tener una idea del estado de las ventas, errores en las negociaciones con las pasarelas de bancos, etc...
La empresa ingenieril les prepara un aplicativo desarrollado en VB.Net con una serie de botones que lanzan unas consultas a producción pasando por el "middleware".
Lo genial viene ahora. Como a veces esas consultas tardaban mucho por tener un criterio y diseño de consulta discutible, la aplicación permitía volver a pulsar la consulta. Ya pueden imaginarse la cantidad de consultas encoladas que esto provocaba.
A partir de cierto punto de encolamientos los terminales de venta presentaban errores por la espera y las ventas se cancelaban.

Quien "pariera" y supervisara ese engendro podría ser muy ingeniero de software, pero idea de lo que estaba haciendo no tenía.

La solución decidida por la empresa cliente, lejos de exigir un software con un mínimo de calidad, pidió a sistemas realizar una ñapa.

Se implanto un script que si se producía contención en la BBDD se cortaba el acceso de Negocio.

Conclusiones que he sacado en 10 años como "bombero" de producción.
Si el aplicativo ha sido desarrollado en:
VB.Net -> 90% posibilidades de ser escombro. (Si un programador tiene un mínimo de nivel no programa en VB)
C#.net, Java -> 60% posibilidades de ser escombro.
Python -> 40% posibilidades de ser escombro. Lento pero con cierto criterio.
C, C++ -> 20% posibilidades de ser escombro. (Menos posibilidades si es para sistemas "Como UNIX" o Mainframe)

Bonus: Si en BBDD tiene toneladas de PL/SQL... escombro casi con total seguridad.

V 3
K 27
Al_Gal

#16 De hecho en el programa este de Iñaki Gavilondo, cuando ya no este creo que se llama, en la tercera temporada entrevista al creador de internet y apunta que el mayor peligro para internet es el software mal programado junto con el internet de las cosas. Combinación explosiva, no es que lleve a producir Skynet, es que igual produce una puta mierda que no vale para nada y encima crea problemas.

V 3
K 25
w

#2 qué sabios nuestros abuelos... Pero como tú tienes un título y no dejaste los estudios con 9 años te tendremos que hacer caso

V 2
K 25
Penetrator

#28 Tu caso es raro, normalmente ocurre al revés: es difícil encontrar a alguien que lleve 18 años programando, porque en cuanto llevas 5 o 10 las empresas se empeñan en convertirte en mánager.

Si de verdad quieres dejar de programar, no te será difícil.

V 2
K 25
D
editado

#2 yo llevo 13 años en esta industria, y como CTO no podría estar mas de acuerdo en tu lectura. Ojalá todos los developers de meneame lean tu comentario y reflexionen sobre ello.

#11 si el ordenador tiene el doble de recursos, es normal que las aplicaciones usen el doble de recursos. De lo contrario, esos recursos no servirían para nada. El modelo multitarea basado en ventanas está desfasado, y cada vez vamos a ir mas al modelo android. Donde las aplicaciones pueden usar tantos recursos como quieran (hasta un limite), por que el usuario está usando esa aplicación en ese momento. Eso permite exprimir mucho mas toda esa ram y cpu que has pagado, por que tus programas pueden usar texturas de mas calidad, usar funcionalidades complejas, o trabajar con ficheros mas grandes, etc etc. Luego están los programas que usan mas recursos pero no aportan ninguna funcionalidad extra. Pero no pasa nada, cuando los cierras liberan esos recursos, y mientras los usas no te importa que usen mas recursos, siempre que tu sistema pueda soportarlo, claro.

Los programas que usan los usuarios hoy en día en sus terminales (del tipo que sean) no suelen ser buenos o malos por que consuman mas o menos memoria. Lo que el usuario quiere es que funcionen bien, sean bonitos, sean baratos o gratis y sean usables. Esa obsesión por la optimización solo la tienen los techies.

#63 si tu empleador no quiere que inviertas el tiempo en optimizar, será por que no lo considera necesario para su negocio, o para el éxito o fracaso de la aplicación. Cuando el rendimiento sea un problema, se verá en las ventas y las quejas, y seguro que os poneis a optimizar. Pero optimizar por que si es rídiculo, ya que optimizar es una tarea que cuesta dinero y solo se justifica si aporta un valor. Si reduces la memoria de algo pero no lo nota ningún usuario, has tirado el dinero que podrías haber invertido en mejorar de alguna forma tangible tu aplicación.

#93 La ingenieria de software está al servicio del negocio y funciona para el negocio. Nuestro objetivo es producir el software que el negocio necesita, de una forma compatible con lo que el negocio tiene a su alcance. Si se priorizan funcionalidades nuevas por encima de arreglas las existentes, será que las existentes no están afectando tanto a las ventas o usuarios, sino, estarían priorizando los problemas. Las empresas por norma general invierten el dinero en lo que consideran mas urgente e importante para mantener su negocio. Si consideras que tu product owner está ignorando un problema real que tienen los usuarios, habla con el.

#271 es que hacer las cosas bien significa hacer las cosas de la forma mas eficiente para el problema que negocio intenta solventar. Si estás programando un MVP para una ronda seed, es mejor que piques algo rápido, valides tu modelo de negocio, y si al final el modelo de negocio tiene sentido y las asunciones se cumplen, con el dinero de las rondas lo puedes repicar todo. Pero si lo picas todo de calidad desde el principio, investigar modelos de negocio te sale mas caro. En las startups el dinero del principio es mas importante que el dinero del futuro. Un euro al principio vale muchos euros del futuro. Si la empresa no es una startup, tiene un modelo de negocio definido y ha tenido que programar dos veces una cosa y no existe ninguna justiciación excepto la calidad, el CTO/arquitecto debería ser despedido.

#13 no es por vagancia. Es por dos razones. La primera, que la mayoría de usuarios usan solo una aplicación a la vez y que uses mas recursos les da igual y nunca lo van a percibir, por lo que en muchas empresas que hacen software de usuario, no se preocupan de esas cosas por que nadie las va a valorar: no va a mejorar sus ventas ni sus proyecciones. La ingenieria no es arte, hacemos lo que hacemos para gastar de la forma mas eficiente posible el dinero de la empresa. Sobre la fase beta: la mayoría de empresas usan las fases betas para recoger feedback de producto, validar las funcionalidades y feedback de usabilidad. Los usuarios usan aplicación que les hacen falta si tienen sentido y saben usarlas. Por muy bien que funcione una aplicación, si no es lo que buscas no la vas a usar, o si no la entiendes. Por eso se centran en eso, y no en el rendimiento.

#84 un for dentro de un for para evitar que un producto cartesiano lo haga el motor de base de datos es algo habitual en muchos sistemas modernos. Facebook prefiere mover ese tipo de lógica a PHP, en lugar de tenerla en el motor de bases de datos, donde es mas complejo escalarla, mas complejo debuggearla y mas complejo entenderla cuando se complica. Un DSL como SQL siempre termina siendo mas complejo expresando operaciones que un lenguaje de programación completo. Todo el mundo entiende un for dentro de un for, con luego otro for y un par ifs. Pero no todo el mundo procesa rapido un join dentro de un join que tiene una subquery. Yo los SQL para resolver cartesianos etc solo los he visto generar coste en las empresas, nunca como algo positivo.

#99 si usas npm y no fijas versiones lo estás haciendo muy mal. Lo de capa sobre capa nos permite crear aplicaciones que antes ni soñabamos en tiempos que son de risa, a costes ridiculos. Todo esto que hacemos lo hacemos para digitalizar la sociedad, buscar modelos de negocio digitales, etc. Y cuanto mas barato sea, mejor. La optimización es un lujo que la mayoría de usuarios no valoran, por eso siempre está ausente.

#17 la legibilidad de un programa no depende los comentarios, sino del compromiso entre cohesión y acoplamiento y del mal uso de ciertas funcionalidades del lenguaje, así como de lógicas complejas sin necesidad. Los comentarios no son el problema, de hecho, si tienes que poner comentarios es que tu codigo no es legible y lo has hecho mal. Los usuarios no desinstalan las apps por usar mas ram o cpu, mientras les funcionen bien cuando están en primer plano. Solo les preocupa cuanto ocupan instaladas, y cada vez menos, además de tener mucha tolerancia, por que todas las apps pesan mucho.

#20 no se puede hablar de optimización y javascript (ecmascript?) por que es una especificación y las especificaciones no son performantes o dejan de serlo, son simplemente especificaciónes. En todo caso tendríamos que hablar de v8 u alguna otra implementación de la maquina virtual de javascript.

#21 la energía que desperdicían los computadores por aplicaciones que no son óptimas es rídicula comparado con casi cualquier otra forma de consumo de energía, no es algo de donde rascar mucho.

#111 los prograamas ya no son lo que eran: se pueden producir a un coste mucho mas bajo, podemos producir mucho mas programas al año, y hacen muchas mas cosas. La optimización es un lujo que los usuarios no valoran. Los usuarios quieren aplicaciones gratis o muy baratas, y nosotros como ingenieros producimos lo que la sociedad demanda. Lo que comentas es una cuestión de preferencia personal, pero en el trabajo debemos ser profesionales.

#23 no, eso no es la raíz del problema: eso es una de las cosas que permite el boom de aplicaciones digitales a costes de risa que estamos viviendo, además de la abundancia de opciones. El usuario cada año tiene mas cores y mas memoria, y la mayoría no valora la optimización: lo que quiere es contenido, esto va de contenido y algunos aun no has habeis enterado. Y cuando el contenido es interactivo, es decir, una aplicación, el usuario quiere que sea gratis o barata, y quiere tener muchas donde escoger. Y el empresario intenta descubrir que aplicación tendría mas éxito, y para ello necesita gastar lo minimo en cada iteración en la que prueba a crear y vender aplicaciónes y servicios.

#32 en eso estamos 100% de acuerdo, pero es que la inmensa mayoría de programadores trabaja en aplicación donde el rendimiento no es importante, no es la maxima prioridad del usuario ni del product owner, no es lo que necesita la empresa para vender mas, pero es el deseo caprichoso del ingeniero, que se olvida que hacerlo bien no es hacer lo que le gusta hacer o lo que el considera necesario, sino hacer lo que el usuario realmente pide y necesita y lo que la empresa realmente pide y necesita. El que tiene que priorizar los esfuerzos es el product owner.

#37 eso suele ser una mala lectura de las herramientas de diagnóstico. Los sistemas operativos modernos consumen gigas de memoria sin hacer nada por que la cachean, para asignarla mas rapido etc.

#51 el software hace años era inusable, con complejas interfaces, era feo y era muy caro de producir por la inmantenibilidad extrema. Y los que no eran inmantenibles, estaban hechos en plan artista, a costes extremos por una comunidad online que trabaja 10 años en programar wget, obviamente que está de puta madre su código, pero a que coste?

#54 si y por dos razones: uno, por que los recursos de la empresa son finitos, y los que destinas a optimizar no los destinas a otras cosas del programa. El usuario no requiere esa optimización mientras estés dentro de unos margenes, y lo que requiere es un programa mas barato o mas funcionalidades. Es decir, nadie está pidiendo eficiencia realmente, mas que el ingeniero por sus propias inquietudes. La segunda razón es técnica, y tiene que ver con que las estrategias de abstracción y las de reutilización de código son siempre mas caras que los programas a medidas para tu cpu y que duplican procedimientos para ahorrarse condicionales.

#59 las aplicaciónes web de cliente no tardan en cargar por que usen X frameworks, lo hacen por errores de diseño en cuanto a la comunicación cliente servidor (abuso de roundtrips) y al mal uso de la cache, servidores mal configurados (compresión, keep-alive, etc) o problemas similares. Se puede hacer una web no optimizada con 4 frameworks y con una uso inteligente de http (que no cuesta nada) y la web carga super rápido. Optimizar mas que eso es capricho de ingeniero casi siempre, excepto en casos muy puntuales.

#92 se nota que eres un experto de esta industria

V 2
K 25
P

#344 en serio?? Yo hice francés en el instituto, 2 o 3h semanales durante 2 años. No recuerdo un carajo.

Me vas a decir que van a aprender a programar en media docena de lenguajes, diseño web, programación para móviles, videojuegos, ofimática, mantenimiento de sistemas... TODO, en una puta asignatura, y me van a quitar el trabajo!?? JAJAJAJAJAJA

Es como decir que todos los que hagan la asignatura de Física van a querer ser Stephen Hawking...

V 2
K 25
Magog

A mi lo que me "deprime" después de 20 años es lo sobredimensionado del sector, cada día me estoy volviendo un poco más anti tecnologico

V 2
K 24
pawer13

#46 Disculpa, pero con el código abierto el problema es el mismo. De hecho todas esas dependencias de npm son código abierto.

V 2
K 24
Shotokax

#14 y spam, y malware, y hasta minado de criptomonedas. Luego que por qué la gente utiliza bloqueadores.

V 2
K 24
t

#95 Claro, y ponte a renderizar un SVG en tiempo real en un móvil chino ñapa, verás qué risa cuando tarde 10 segundos en abrirse cada vez que quieres enviar un whatsapp.

Al final, aunque las aplicaciones usen SVG, internamente guardan una caché con los bitmaps renderizados.

V 3
K 23
Conde_Lito

#80 Los drivers y firmwares como quien dice es electrónica, sobre todo estos últimos.
Tienen que ver con la informática ya que un ordenador también tiene uno o varios microprocesadores y de alguna forma hay que decirles que tienen que hacer cuando se encienden nada más aplicarles tensión.

Sin un firmware un procesador no hace apenas nada y digo apenas ya que están programados electrónicamente para que hagan determinadas rutinas lógicas, como por ejemplo habilitar determinada o determinadas líneas de direcciónes (Address Line) donde se encuentra un programa que lo mismo solo hace que se encienda un LED que está conectado a tal pata del bus de datos del micro, que lo mismo es un programa que inicializa un ordenador, este programa que puede encender un LED o inicializar un ordenador es el firmware.

V 1
K 23
apetor

#242 Uff, a ver a ver, la gran mayoria de drivers y sobre todo firmware de hoy dia, son instrucciones de procesadores, no son logica programada. Las microcode updates de los procesadores, si, aunque no se conoce muy bien por que son cerradas y bien cerradas, pero se asume que son tablas de logica programada. Pero es que eso representa muy poco % del firmware. Hoy dia, ademas, el firmware, por ejemplo en PC con UEFI, es 95% C, si, de bajo nivel ( no todo tampoco, hay mucha programacion tipo sistema operativo ) y tal, pero vamos, software normal y corriente.

A lo que te refieres en tu segundo parrafo, en UEFI, serian los PEIM de la fase PEI, muy poco % de todo el UEFI, que son eso, tocar bits en chips concretos para enrutar ciertas cosas fisicas a logicas ( no habla de paginacion ni nada de eso, sino de addressing PCI, puertos,... ), encender partes del chipset como el LPC ( Low Pin Count, bus donde se conectan las cosas viejas/lentas de un PC ), inicializar la DRAM ( inicialmente el procesador usa cache as ram, no puede acceder a DRAM hasta cierta fase, muy inicial ), etc. Pero eso, esto es muyyy poco codigo.

V 1
K 23
apetor
editado

#268 Si, se nota que te gusta. Yo me se muchos opcodes de instrucciones por que los veo dia a dia, no es que quieras aprenderlos, es que los memorizas sin querer.

Es una mezcla, las capas medias o altas acceden en general a capas mas bajas, pero hay excepciones. Aunque si, UEFI esta pensado para ser relativamente portable, la parte PEI ( Pre-EFI Initialization ) no, pero la parte DXE que viene despues y es bastante mas tocha, si. Incluso hay binarios compilados a lo que se conoce como EBC ( EFI Byte Code ) que son compatibles no ya a nivel de source sino a nivel binario. Ahora, esto es "on paper", luego... bueno, medio medio.

editado:
E9 XXXXXXXX ( relativo de 32bit con signo que se suma al EIP o al RIP -extendido con signo- actual; nota: el EIP/RIP esta apuntando a la siguiente instruccion cuando la instruccion actual se ha decodificado y pasa a ejecutarse ). EAX como tal no es un solo opcode, son una combinacion de 3 bits en diferentes codificaciones de instrucciones, en las de acceso a memoria normales serian 000b en la parte ModRM, pero segun que tipo de instruccion toma parte de forma algo diferente.

V 1
K 23
Conde_Lito

#270 He cogido jmp y eax por coger, los primeros que se me han venido a la cabeza de un procesador x86 para hacer este ejemplo tonto.
Igual mejor habría sido coger como ejemplo un procesador más básico/antiguo o un RISC.

V 1
K 23
w

#9 Eso es un poco de clasismo sin sentido. El peor código que me he encontrado ha sido hecho por un grupo de ingenieros con prisas y, sobre todo, vagos y con pocas ganas de hacer las cosas bien. Eso sí, sabían la hostia de historia de la informática y se conocían muy bien el mundillo, pero claro, eran unos chapuzas.

Que es obvio que la gente con estudios suele hacer las cosas mejor porque tiene más conocimientos, pero hay mucho ingeniero que cuando sale de la carrera se pega la hostia con el mundo real donde te toca hacer un codigo de mierda líquida que ha pasado ya por siete ojetes distintos y te toca descubrir cómo era todo antes de salir del ojete primigenio para luego acabar expulsando tu propia mierda, un poco más durita y espesa, pero todavía más bien líquida.

V 2
K 23
KimiDrunkkonen

#81 y los putos vectores para qué están?

V 2
K 22
RubiaDereBote

#38 Puedes no aparecer por la oficina

V 1
K 21
D

#2 perdoname, creo que o no has leido el articulo entero o no lo has entendido. Tu comentario tiene razon pero no va de eso el texto.

V 1
K 21
apetor

#2 NO son excluyentes, salvo en 4 casos extremos sacados de quicio. Diseñar y programar algo con principios de no poner nada de mas, no irse a lenguajes muy "fancy" y hacer las cosas con gusto, no requiere hacer el loco en plan ensamblador y demas.

Yo programo en C y ensamblador ( para PC, no solo para embebidos ) en 32 y 64 bits y vamos, todavia la gente se piensa que el ensamblador es por optimizar... no, el ensamblador ser usa mas por control fino cuando se requiere, para lo justo. El ensamblador, en la mayoria de cosas de hoy dia, viene bien para depurar, y aqui hay grandes carencias incluso en desarrolladores con años de experiencia. Todo por mantras de tipo "buff, ensamblador, eso ya no se usa, eso ya... pa cuatro locos". Es mas, el ensamblador ayuda mucho a programar mas simple incluso y a entender bien lo que se esta haciendo, incluso cuando se usan lenguajes de mas alto nivel.

Hay mucha falacia interesada para justificarse, como la que dices: "priman mas otros criterios", NINGUNO de esos criterios salvo, y en menor medida de lo que se dice, el tiempo de desarrollo ( tambien es una inversion hacerlo todo simple, ya que mantenerlo cuesta mucho menos ), es excluyente a programar con gusto y "pelado".

Un software puede ser MUY usable, muy moderno y funcionar de puta madre y estar hecho en C y con programacion minimalista; de hecho, de hacer una estadistica, veriamos la cruda realidad.

A design is not perfect when there's nothing to add to it, but when there's nothing to remove from it.

V 3
K 21
m

#124: Pero volvemos a lo de siempre: ¿Hace falta cargar 200 bibliotecas de JavaScript para dar una información que en muchos casos es básica y hace 20 años se mostraba igualmente sin tanta tontería?

V 1
K 21
llorencs

#124 Pero pongamos, que yo abro y cierro Firefox con el mismo número de pestañas. No se explica que con el tiempo pase de 600MB a 2GB de memoria. Eso, me indica que quedan hilos basura ejecútandose por allí, que nunca son cerrados. Por lo tanto, la optimización es pésima.

Y eso me pasa teniendo mi mínimo de 8-10 pestañas a tener el máximo de pestañas abiertas unas 80-100. Tenga ese número o no, tras horas de tenerlo abierto acaba ocupando 2GB e incluso 4GB de RAM, llegando a representar más del 50% del uso de memoria de mi sistema de 8GB.

#121 8GB se me quedan pequeños.

V 1
K 21
Conde_Lito

#243 No es mucho mayor ya que tienen pocos colores y son muy planos.

Por ejemplo este que tiene varios colores ocupa 140Kb

comment_25327178 media
V 1
K 21
n

#37 Y Windows 10, tras un año de uso, me suele ocupar unos 30 GB (después de ejecutar el limpiador del sistema con todas las opciones posibles).

V 1
K 21
D

#344 Me querias dar miedo. Pero mucha gente va a perder su curro en el futuro.
Sobretodo cuando los coches vayan solos...

V 1
K 21
P

#20 flame!

V 1
K 20
Abeel

El error se ve hasta en el habla, 'optimizar' es hacer algo lo más eficiente posible (o conocido) por lo que no se puede decir 'más optimizado', antes se intentaba ir al máximo y se podía decir que un código era óptimo, ahora como es improbable intentarlo ya es más complejo m

V 1
K 20
apetor

#19 Lo mismo en desarrollo de drivers, UEFI y otros.

V 1
K 20
1 2 3 4