EDICIóN GENERAL
467 meneos
7344 clics
El desencanto del software [EN]

El desencanto del software [EN]

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: software , desarrollo , optimizacion
Comentarios destacados:                                  
#2 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.
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"
#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.
#1 #24 Yo hay un par de veces que dudo que este tio sea programador.
Muchas veces se queja del tamaño, por ejemplo que si el teclado predictivo ocupa 150megas.
Pues hombre. Si tienes en el mismo software las imagenes HD, full DH, 2k, 2.5k, 4k y todo el teclado predictivo... Pues hasta me parece poco. Solo las imagenes en 4k del teclado y las mierdas de emogis sin comprimir se pasaran de eso
#81 para que necesitas imágenes 4k en un teclado?
#81 Es un teclado, valdría con SVG.
#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  media
#81 Un teclado 150MB no se sostiene por ningún sitio.
#218 En 109 Kb creo que cabía el tetris entero antiguamente... Creo que a eso es a lo que se refería #81
#81 Precisamente de lo que se queja es de meter 150mb para un simple teclado parezca aceptable. Siguiendo el ejemplo de las mierdas de emogis.. cada aplicación puede tener su propio juego de imágenes.

De hecho creo recordar que Google trabajaba en alguna forma de adelgazar los apk incluyendo sólo los recursos necesarios para el dispositivo en concreto y no un montón de relleno innecesario.

A mi personalmente, lo del teclado me parece una aberración y suscribo lo que dice el autor, pero también me dejo llevar muchas veces por el lema "vale menos la RAM que el sueldo de un programador".
#81 y los putos vectores para qué están?
#81 ¿Eres consciente de que se pueden usar gráficos vectoriales precisamente para evitar usar imágenes enormes en altas resoluciones?
#81 A mi el artículo en parte me recuerda a laboro, me parece que se toma la licencia de escribir así para tener más repercusión, pero a parte de eso sí, a veces suena a que es alguien que se queja sin tener ni idea. Por ejemplo, no puedo decir por qué el teclado ocupa tanto, pero creo que es fácil obviar que es algo que puede tener mucha complejidad por debajo, me explico:

El teclado de google que me viene por defecto es predictivo, va aprendiendo las palabras que usas. También te permite…   » ver todo el comentario
#1 #24 No es verdad. Los sistemas operativos cada vez son más robustos y tienen una carga grafica mucho mayor. Luego está el tema de la simplicidad. El usuario medio no es capaz de utilizar aplicaciones complejas, y eso deja mucho mercado a simplicidad.
#100 #24 Y dentro de 5 años, con la cantidad de PROGRAMADORES que van a haber....muchísimo más. Me alegra mucho que saquéis este tema por que, si alguno de los que escribis/leis aqui en menéame es informático/programador/analista deberíais empezar a daros cuenta de que los institutos se HAN CONVERTIDO EN UNA FABRICA DE PROGRAMADORES/informáticos, en todas sus formas; como sabéis, desde hace ya dos años se está impartiendo la programación como asignatura troncal y obligatoria en los institutos…   » ver todo el comentario
#1 No olvidemos que los procesadores no avanzan como antes. Hay una gran dificultad a sobrepasar los 4GHz y sobretodo en los 5GHz. Ahora se añaden núcleos para hacer micros más potentes por lo que tmb es importante adaptarse a la programación en paralelo y preocuparse un poco por la eficiencia, pues bajar de litografía también cuesta cada vez más y el monoproceso no ha mejorado mucho en los últimos años, pero lo que me preocupa de verdad, es esa despreocupación por la seguridad, me parece sumamente alarmante en un entorno que no es que vaya a estar conectado, es que hace años que ya lo está.
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.
#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.
#11 yo no llevo tanto solo 13 años en esto y hay tareas que decrecen en horas y son normalmente las de optimizar si tengo menos tiempo pues se pasa por alto muchas cosas no porque no sepa que necesitan depurarse sino porque no tengo el tiempo necesario para ello
#63 se quiere software bueno bonito barato y luego solo acaba siendo.... Ninguna de las 3.
#63 ya, y la prioridad es sacar nuevas funcionalidades, no arreglar los problemas que hay en las existentes. no hay tiempo para hacer un trabajo fino y al final lo sufre el usuario: aplicaciones pesadas, poco optimizadas y llenas de errores.

los programadores se quejan de pagar 60 euros por un juego y tener que aguantar bugs? o que vaya lento? al final, en todas partes cuecen habas.
#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…   » ver todo el comentario
#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
#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.
#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...
#16 No, no lo verá.

Skynet tomará conciencia de sí misma y destruirá el mundo.
#29 No, Skynet al ver su propio código tan horrible matara a los programadores y luego se suicidará.
#29 Skynet se colgará con un null pointer al intentar destruir el mundo, no hay problema xD
#29 Skynet tomara conciencia pero por bugs de programación tendrá una depresión de caballo y tendremos que crear un IA para hacer sicoterapia.
#79 Yo creo que irá a hablar con el "arquitecto" y acabará colapsando. :-S
#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.
#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.
#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.
#84 Y te pasas a los sistemas... ¿has leído las cosas de www.mundowdg.com? deberías...
#84 Yo hice lo mismo allá por finales de los 90, me pase a sistemas y así ahora puedo echarles la culpa de todo a los desarrolladores!!
:-D
Y acierto en el 99,99% de los casos!
m.youtube.com/watch?v=Vhh_GeBPOhs#
#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í.
#13 Luego los ves llorando porque la ps4 tiene que hacer rescalados y correr a 30 fps para ponerte un 4k falso.
#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…   » ver todo el comentario
#13 Economía. Es caro hacer las cosas eficientes. Ahorras muchas horas tirando de librerias y actualizando cada 2x3 para parches.
Lo de hacer bien las cosas en el tema de sooftware, creo que queda para sondas espaciales y armamento. Poco más.
#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.
#2 Siempre nos quedará javascript :troll:
#20 o python
#66 #2 Pues ya vereis cuando llegue el apocalipsis digital, y solo nos quede Visual Basic... :tinfoil:
#20 precisamente ese es el problema... un lenguaje interpretado que se ejecuta en un motor web que transforma esas instrucciones a un bytcode que reinterpreta una maquina virtual que ahora ya si transforma a instrucciones de lenguaje máquina...

Capas y capas de abstracción innecesarias por la absurda manía de querer hacer todo con aplicaciones web que corren sobre sistemas operativos hechos en Java.

No digo que haya que volver a programar ensamblador, pero hoy dia existen muchos lenguajes de alto nivel muy buenos que compilan en nativo, y la diferencia en eficiencia suele ser abismal
#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.
#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…   » ver todo el comentario
#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…   » ver todo el comentario
#21 Si no desperdiciáramos tanta ropa no habría trabajo para tanto asiático que sobrevive gracias a hacer ropa. Y a tantos dependientes que la venden, etc.

Cuando yo era un chaval llevábamos al colegio paquetes de arroz, espaguetis o azúcar para los países asiáticos, que pasaban hambre. (Hoy los pongo en un carro que el supermercado tiene reservado para los pobres de aquí).
#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…   » ver todo el comentario
#2 A JAVA le gusta tu comentario.
#2 Lo que prima ahora es desarrollar rápido y barato.

Esa es la raíz del problema.
#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.
#32 ¿alguien aun hace aplicaciones de escritorio?
#2 Tu abuelo sigue teniendo razón, tiramos demasiadas cosas y los recursos son finitos...
#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.
#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).
#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.
#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.
#51 Ahora son mucho menos mantenibles.
Una aplicacion de escritorio tenia 0 complejidad. Ahora tienes capas y capas de software y frameworks para hacer lo mismo que hacias antes con 2 componentes.
#2 Son incompatibles la la usabilidad, la legibilidad o la mantenibilidad del código con un software eficiente y que funcione bien como el de antes? Pregunto desde la total ignorancia.
#54 pues no, pero te estás pasando con la preguntita....
#54 Cuando el tiempo del que dispones está ajustado sí, porque estas cosas requieren tiempo y si lo dedicas en una cosa se lo quitas a otra.
#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…   » ver todo el comentario
#54 Quizás decir incompatibles sea demasiado, pero son objetivos contrapuestos, es como hablar de tener un transporte efectivo que no contamine. Si tienes que quedarte con la solución óptima para un objetivo lo más probable es que sea solo a costa de darle una patada a las otras dos.
#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.
#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.
#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 :professor:
#2 Han pasado los años y el hardware actual no exige ese cuidado

falso, si eso fuera cierto no se seguiría investigando para desarrollar hardware más potente
#83 Hombre, ese mismo cuidado no lo necesita, por eso abusan, lo que ocurre es que abusan 7 veces más, pero es cierto que el mismo cuidado que necesitaba el hardware de hace 25 años no es el mismo que el de ahora.
#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.
#2 El requisito fundamental que debe cumplir cualquier software es ser entregado a tiempo con bugs que se noten poco. Lo demás es accesorio y queda supeditado a eso.

Si eres capaz de decirle a tu cliente que tienes sus features listas pero que necesitas X horas de desarrollo para optimizar un 10% la ejecución del programa me juego lo que quieras a que a menos que sea inejecutable como estas ese tiempo no se va a pagar.

A quien no le gusta como se desarrolla y necesitas que se optimice vete al…   » ver todo el comentario
#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…   » ver todo el comentario
#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…   » ver todo el comentario
#2 Pero eso será en el mundo de desarrollo de apps, porque yo llevo 12 anyos desarrollando software para la industria aeronaútica y del automóvil y creedme, las metricas de consumo de CPU, de RAM y de ROM están al orden del día y se miran al milímetro.
#2 Hace 20 años todo el mundo programaba en escritorio. Y la "usabilidad" ya te venia dada, igual que el diseño. Nadie hablaba de "usabilidad". Me hace pensar en los "coach", y es que ya conozco a unos cuantos de "expertos en usabilidad".
#2 primar más la legibilidad, usabilidad y mantenibilidad? Lo que conozco es que lo que más se prima es la fecha de entrega y que funcione. Aunque sea una chapuza de código, no se hagan casi pruebas, no se documenta, se repite el mismo codigo en 20.000 sitios aunque se pueda reutilizar mediante objetos porque de primeras cuesta menos hacerlo. Pero luego para mantenerlo cuesta diez veces más tocar el código cada vez y probarlo ... El que venga después que se las apañe...
Cómo el código los usuarios no lo ven ....
#2 A la mierda NodeJS.
#2 que barbaridades hay que leer. Dile que eso de optimizar la CPU no es importante a quien tenga que desarrollar sistemas de alta disponibilidad o que dan servicio a millones de peticiones concurrentes. Cuanto daño hizo el visual basic.
#2 El pan que sobra no se tira. Sirve para las tostadas, para el salmorejo y para el gazpacho. Por cierto, que es uno de los alimentos caros: un pan medio decente no baja de los 5 euros el kilo, el doble que la carne de pollo.
#10 #2 Y no hay que olvidar que no se paga, al menos en españa, no se paga ni por optimizar y si me tiras de la lengua, ni por programar.
#2 Estoy de acuerdo parcialmente contigo.
Cuando antes tenias que calcular cuanto te ocupaban los datos en memoria y definir tipados acordes, hoy en dia vas a lo seguro y pones tipos mas largos "por si acaso", dado que el hardware lo permite.
Tambien es cierto que el software de hoy no prima la eficiencia, sino la seguridad, mantenibilidad, etc... como bien dices.
Cuando optimizar la velocidad de tu software implica refactorizar y calculas en coste de esfuerzo que te va a costar…   » ver todo el comentario
#2 pero tampoco te puedes ir a los extremos. Vale que no te de por zurzir calcetines, pero tampoco es plan de ponerse a usar Java para hacer aplicaciones web.
#103 No creo que lo que tu dices y lo que dice #2 sean cosas contrapuestas, al final cada área tiene sus propios intereses, pero en general optimizar recursos es secundario, o al menos no es el único factor principal.
#2 ahora estoy desarrollando para zxspectrum para tener esa necesidad, y hay algo que no tienes en cuenta y yo he visto: la mantenibilidad del código.
Cuando optimizas tienes que hacer cosas que 'afean' y lo hacen más complicado.
#2 ...y así amigos es como el planeta se ha convertido en un gigantesco basurero con calcetines rotos por ejemplo.

Y ahora gastamos electricidad como para desentrañar la física de las partículas elementales, para jugar a los angry birds, y todo porque no se optimiza. (Además de un montón de hardware viable que acaba en montones de chatarra porque se necesita potencia para hacer lo mismo).
#2 Eso que dices es la cultura del despilfarro.
#2 tu abuelo tiene su parte de razón y te digo porqué: estamos derrochando en HW por no optimizar el SW pensando que eso no tiene ningún coste. Estamos creando cada vez más HW de usar y tirar por no optimizar al SW porque no imputamos en los costes el enorme precio ecológico que suponer tirar o producir el HW. Nos creemos que eso es gratis, que nuestro planeta es infinito. Puedes pensar que es algo alarmista lo que digo, pero hay que verlo como algo global (millones y millones de dispositivos…   » ver todo el comentario
#138 #2 ¿De verdad ninguno sabe que se puede hacer tortillas de pan con pan de 5 días duro como piedra?
www.pequerecetas.com/receta/tortilla-de-pan/
#2 El problema del software tal como lo describe el escritor del articulo, es que no existe un proceso real de ingeniera detrás de él. En los tiempos en los que cada byte contaba se ponía mas atención en adelgazar el código. Pero no nos engañemos, no existen patrones ni modelos de diseño sofisticados de programación porque nunca han existido. Como leia una vez en un libro, llamamos ingeniería a la programación pero poco tiene en que parecerse al proceso de diseño de una casa, de un puente o de…   » ver todo el comentario
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.
#3 (Despues de leerlo entero)

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

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.
#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: tonsky.me/projects/
#5 Sabes que pasa? Que programar bien cuesta igual ( en tiempo) que hacer mierdas. Es una cuestión de supervisión y cualificación profesional.
#5 Lo primero, no te lo tomes como un ataque!! que yo también lo hago, pero porque tantas palabras en ingles innecesarias, "rant", "Move fast, break things","efficient-enough", "feature"... todo eso tiene palabras en español igual de validas!
No es tu caso, te he usado de respuesta porque has escrito así, pero es que estoy harto que la gente se ponga en modo "marketing" a usar palabras en ingles para quedar guay y venderte la misma m!
#5 Sí, ya sabemos lo que prefiere la empresa de hoy, pero no es el buen camino.
#5 A lo que dices tu, añadiría que también le falta ver que ahora cualquier funcionalidad básica tiene una complejidad enorme. A efectos prácticos es como comparar una máquina de escribir mecánica con un ordenador. A lo mejor soy muy pesado al centrarme en el tema del teclado, pero es que esa aplicación de teclado no es para nada algo que muestra "teclas" las pulsas y ya está... por debajo tiene un montón de funcionalidades, algunas que no usamos o no necesitamos, vale, pero vivimos en un mundo globalizado.
#3 A este paso, viendo el panorama mundial, prefiero el aceleracionismo. Que es cargarse rápidamente algún recurso natural clave, para que la gente lo note de verdad y reaccione de verdad. Mientras los problemas ecológicos sean una amenaza apocalíptica abstracta, la gente no va a moverse, por mucho que se grite "el fin está cercaa!!"
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...
#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...
#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
#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
#7 Esos scripts que dices, como comenta #14, son el 15%. El resto es mierda que bloqueo con Ublock Origin.
#14 y spam, y malware, y hasta minado de criptomonedas. Luego que por qué la gente utiliza bloqueadores.
#7: Vale, justifica ahora el 85% restante de la memoria RAM consumida.
#18 Que Firefox se coma entre 600MB recién abierto a 2GB cuando lleva unas horas abiertos, independientemente de cuantas pestañas haya abiertas me lo explicas. Y con Chrome lo mismo.
#72: Pues eso, que entre unos y otros, cada vez se consume más memoria cabro RAM de forma injustificada.
#72 Hay gente que se monta 8GB de RAM para luego estar usando solo 1 o 2GB. Si yo tengo 8GB, quiero usar los 8GB y tanto el sistema como aplicaciones, usarán de más si hay memoria disponible. Hay mucha gente que cae en los errores de "limpieza" de ram en móviles y demás. ¿Cuantas pestañas tienes abiertas?, ¿videos?, y precisamente, ¿cuantas de esas pestañas estarán ineficientemente programadas y con excesivos javascript totalmente innecesarios a nivel de usuario solo para trackearte o mandarte publi?
#72 #18 Chrome y Firefox lanzan un proceso para cada pestaña, eso ya hace que tengas duplicada parte de la memoria usada.
Ahora carga en memoria en código Javascript, compílalo y crea un ejecutable "nativo". Y carga una herramienta de monitorización para poder hacer optimizaciones JIT (just in time) sobre la marcha. Es decir, una máquina virtual de Javascript.
Prácticamente has cargado un IDE y un depurador de código sobre la marcha cada vez que cargas una página web (de hecho, si pulsas F12 en cualquier navegador lanzarás un IDE para depurar la página actual).

La contrapartida es la velocidad de ejecución: un navegador hoy día ejecuta Javascript unas 100 veces más rápido de lo que lo Netscape o IE6.
#72 Acabo de abrir un Firefox 62.0 (en sistema MX Linux) a estrenar, con solo presente la página de "inicio-bienvenida": solo 300 MB de RAM.

Chrome no lo uso y no puedo decir nada.
#4 Intenta pensar qué se podía hacer en los tiempos de Netscape con un navegador, y qué se puede hacer hoy en día. Igual te da una idea de a qué se están dedicando esos recursos que se van "sin razón aparente".
#4. Si la web se deteriora más muchos volveremos al formato de las primeras páginas de los inicios de la web en simple texto plano. La gente no sabe lo que se pierde volviendo a disfrutar simplemente de los contenidos y no muchos 'contenedores' actuales.
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.
#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.
#25 Qu'e haces? sistemas embebidos? dispositvos con sensores?
#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…   » ver todo el comentario
#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…   » ver todo el comentario
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…   » ver todo el comentario
#10 brillante!
#10 Muy bueno
#10 así sois los programadores de software propietario, por eso yo intento no utilizarlo. :-)
#46 Disculpa, pero con el código abierto el problema es el mismo. De hecho todas esas dependencias de npm son código abierto.
#46 Tanto npm como react, redux y el 99% de los frameworks js de hoy día son abiertos. ¿A qué te refieres?
#46 Uff, pues lo que ha puesto de ejemplo es todo software open source...que no es software libre pero cerca...
#10 Culpable! Yo hago lo mismo y la verdad es que mientras cobre a fin de mes me da igual. Si los jefes no ponen tiempo y pasta en la mesa para arreglar los desaguisados no seré yo quien pierda el sueño xD
A mi todavía nadie me ha dado un requisito de rendimiento ni en CPU, ni en Memoria ni en nada.

El rendimiento se mide después si es que se mide. Venga esto que hemos parido hace X, lo metemos en esta maquina Y y hace 10X en 10 minutos. Si sale una cosa que es una mierda o la competencia ha sacado algo mejor (cosa que no sabías porque van a matacaballos como tu) pues ya si eso te preocupas y si no, a otra cosa. Es como creo que van las cosas hoy en día.

El día que me pongan un requisito de rendimiento delante sere el primero en cumplirlo a rajatabla. Como díce #10, retroalimentaré la rueda.
#10. Has descrito al milímetro el 'modelo de negocio' de empresas tipo Micro$oft.

Las distribuciones Libres Gnu/Linux fueron la respuesta de la comunidad de usuarios a lo largo y ancho del mundo.
#10 Como buena noticia, en yarn está abierta la propuesta para vivir sin node_modules y usando Plug'n'Play.
Por otra parte, kat e iarna están trabajando en tink, kat lo publicó aquí: blog.npmjs.org/post/178027064160/next-generation-package-management
Y empieza a tener tracción, la semana pasada estaba en los trending weekly de github.
github.com/npm/tink
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.
#19 Yo percibo en mucha gente (tanto programadores como gente que no ha tirado ni una línea de código en la vida) que no hay "nada más allá" de la programación web.

Y sí, en web hay muchísimo y es lógico que así sea.
Pero hay muchos campos que ahora, además, se están potenciando muchísimo y van a ir a más (automatización, IoT, etc)
#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...
#52 IoT, también conocida como "convertir en una red de botnets todas las cámaras neveras, calderas, lavadoras y demás cacharros "inteligentes" conectados a internet porque los fabricantes pasan 300 pueblos de aplicar unas mínimas medidas de seguridad". Le estás dando munición al del artículo xD
#19 Lo mismo en desarrollo de drivers, UEFI y otros.
#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…   » ver todo el comentario
Esta noticia de ayer, que habla exactamente de lo mismo, se hundió en la mierda.
www.meneame.net/story/cada-programador-generacion-anterior-piensa-soft
A mi me pasa igual pero por otros motivos: me aburre programar. Llevo 18 años programando y espero que la semana que viene sea mi última semana como programador.
Lo que relata el autor pasa en todos los ámbitos. Las prisas y la velocidad de la vida actual obliga a todo el mundo a terminar las cosas como sea.

#28 si de verdad quieres dejar de ser programador no tienes que esperar a la próxima semana.
#33 Lo de esperar depende de como te lo tengas montado.
#38 Puedes no aparecer por la oficina
#41 Si tuviera dinero para pagarle el piso al dueño del piso donde vivo, al de la eléctrica su jubilación millonaria, y al otro y al otro y al otro, ya me habría ido. Pero las circunstancias son las que son y no me puedo ir antes.
#45 Ok, entonces tu problema es otro. Ojalá se te arregle la situación.
#61 Gracias pero no quería pintarlo tan grave. Tan solo quería expresar que a veces no es posible cambiar por mucho que queramos.
#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.
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.
#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.
#30 Si es es tu conclusión tras leer el artículo, es que no lo has entendido.
#74 El único que no ha entendido nada es el colega que ha escrito esto:
We put virtual machines inside Linux, and then we put Docker inside virtual machines, simply because nobody was able to clean up the mess that most programs, languages and their environment produce.
#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.
#82 A ver, la virtualizacion y los containers tienen usos "legítimos" como poder balancear en caliente la capacidad de proceso, levantar instancias nuevas cuando la carga aumenta, etc. Pero también se abusa de ellos en plan "se me ha jodido el entorno porque es un puta mierda cero optimizada y en lugar de arreglarlo lo tiro y levanto otro". Yo entiendo que por ahí va el autor.
#30 Los has clavado. Los que van de puristas de la optimización... suelen programar para si mismos. Están tan poco acostumbrados a tratar con frameworks, equipos de personas y demás, que suelen ser bastante chapuzas. No hay quién pille su trabajo y lo pueda retomar.
#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.
A mí me pagan el rato que estoy en la empresa. Luego si quiero programar algo chulo lo hago fuera.
Me siento identificado con el autor de la noticia, entre eso y muchas otras cosa he abandonado la programación profesional. Conozco bastantes informáticos que lo han dejado para dedicarse por completo a otra cosa :-(
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...
#40 Diseñar bien un software es mas importante que tal vez optimizar un bucle for
#49 El problema es que no hacemos ninguna de las dos cosas xD
#78 cuando prima más la rapidez que la calidad se llega a eso (con esto me refiero a todas las carnicas o empresas con gente al mando que son idiotas), un compromiso siempre es lo ideal.
#40 depende, si yo consigo que la búsqueda de Google vaya 3 ms más rápida creo que Google me hace no volver a trabajar en la vida.

Si una cárnica Le haces que vaya 2 segundos más rápido el sap-oncio te da una palmada y te dice pos ok
#65 claro, lo que pasa es que creo que, en general, somos más los de las cárnicas que los de Google xD
A todo el que le interese este problema debería ver esta charla de Uncle Bob www.youtube.com/watch?v=ecIWPzGEbFc
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
#43 Kali Yuga a tope
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.
#44 Que suerte, simplemente estás desactualizado. A mi los que me hacen gracia son los que piden 5 años de experiencia para un framework que apenas tiene 2 años (y efectivamente, aún sigue en beta).
#44 Esa es la percepción que yo tenía hace unos 4 o 5 años. Me puse a fondo con el symfony para descubrir la tendencia opuesta. Todo el mundo estaba intentando desacoplar se de los frameworks.

Hoy programo en golang, donde la filosofía es tirar muy poco de frameworks y mucho de la librería estándar. Es muy común ver proyectos muy grandes en golang que apenas tienen 10 o 15 dependencias. A veces, ni eso.
No te deprimas si fichas por una consultoría y logras agenciarte 6000 lereles al mes de consultor master of universe de SAP-como-mola o cualquier niccho revienta presupuestos (que aún los hay a montones), te la va a traer al pairo la eficiencia del software.
Un pelín exagerado el autor, aunque lleva algo de razón. Me quedó con algo que leí en un libro de Tanenbaum, sobre que el desarrollo en software / hardware tiende a retornar donde empezó. Pasó con los servidores mainstream / terminales tontas -> cloud (centralización); también con los PC antiguos -> móviles (recursos limitados). Por ejemplo en el desarrollo para el cloud (digamos AWS), tienes que cuidar el performance ya que a mayor necesidad de recursos, mayor tu factura.
#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]
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
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…   » ver todo el comentario
Para que quieres poner un programa de tertulia en la tele si se puede hacer en la radio. Más eficiente, ecológico,...
Es muy sencillo. En las empresas no se aplica ingeniería y programa gente con muy poco nivel para tirar los precios. Una ventaja de las atribuciones sería la calidad del software (aunque tienen otras desventajas)
#60 En las empresas hay gente muy buena y gente muy mala.
Pero la gente buena depende de sus jefes y de fechas de entrega.
Y si te dicen que tiene que estar en tal fecha, tienes que programar sin probar muchas cosas.
Lo he hablado con Dios, y me ha dicho que si, que eso es así.
Muy buen artículo con muchos puntos interesantes y que estoy totalmente de acuerdo:
- No tiene sentido utilizar Electron para aplicaciones de escritorio (Electron permite hacer programanas utilizando lenguaje de programación para web como React/Javascript en escritorio). Cada aplicación programada con Electron ejecuta toda una instancia de Chromium. Y porqué se utiliza Electron? Para ahorrar costes de programadores nativos (con sueldos más altos) ya que hay más oferta de programadores…   » ver todo el comentario
#68 Se usa electrón porque te permite desplegar tu programa genérico en cualquier plataforma/arquitectura. Tú programas una vez y te vale para todo. Mucho más cómodo y rápido que programar para osX, windows, linux, bsd... ¿que tiene un precio? vale, pero no lo paga el programador (seguramente se esté ahorrando muchos dolores de cabeza y no esté perdiendo dinero... si tienes que mantener muchas plataformas tarde o temprano empezarás a perder tiempo y dinero porque en alguna de ellas algo falle).
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
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".
Por eso hay que apreciar la belleza de lenguajes como Golang.
#77 Tú sí que eres un Golang :-D
#77 la belleza de tener que andar comprobando errores en cada llamada a función, de tener que comprobar el tipo de datos en runtime, de tener que meter toda tu base de código en una misma carpeta...

menéame