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.

[#2 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.

[#11 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.

[#63 osids]

#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

[#328 Desactivado]

#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

[#13 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

[#15 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.

[#16 manolo_nenaza]

#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...

[#29 Desactivado]

#16 No, no lo verá.

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

[#56 pedrobz]

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

[#62 redscare]

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

[#79 manson2000]

#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.

[#50 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.

[#84 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.

[#127 Desactivado]

#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.

[#191 meneandro]

#84 Y te pasas a los sistemas... ¿has leído las cosas de http://www.mundowdg.com? deberías...

[#205 Desactivado]

#c-84" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3014333/order/84">#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!!

Y acierto en el 99,99% de los casos!

[#99 Desactivado]

#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í.

[#112 Desactivado]

#13 Luego los ves llorando porque la ps4 tiene que hacer rescalados y correr a 30 fps para ponerte un 4k falso.

[#170 wornes]

#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.

[#322 Desactivado]

#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.

[#17 mcfgdbbn3]

#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.

[#20 SrEstaire]

#2 Siempre nos quedará javascript

[#31 Poseido_returns]

#20 flame!

[#66 xizor]

#20 o python

[#327 Zade]

#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

[#21 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.

[#111 Varlak]

#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)

[#117 triturator]

#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.

[#145 Desactivado]

#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í).

[#356 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?

[#22 username]

#2 A JAVA le gusta tu comentario.

[#23 chavi]

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

Esa es la raíz del problema.

[#32 Maegruin]

#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.

[#188 Desactivado]

#32 ¿alguien aun hace aplicaciones de escritorio?

[#35 robustiano]

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

[#37 Shotokax]

#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.

[#278 noises]

#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).

[#39 Gorgonita]

#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.

[#51 Desactivado]

#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.

[#202 Desactivado]

#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.

[#54 selina_kyle]

#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.

[#67 xizor]

#54 pues no, pero te estás pasando con la preguntita....

[#90 ivan123]

#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.

[#119 triturator]

#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.

[#302 Desactivado]

#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.

[#59 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.

[#64 Desactivado]

#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.

[#73 wurg]

#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

[#326 acido303]

#73

[#83 Desactivado]

#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

[#185 Desactivado]

#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.

[#85 yemeth]

#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.

[#86 Mael]

#66 #2 Pues ya vereis cuando llegue el apocalipsis digital, y solo nos quede Visual Basic...

[#92 empanadilla.cosmica]

#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 desarrollo de software científico o a sistemas empotrados que tengan que ser realmente eficientes. Seguro que en bioinformatica o en sistemas de misión crítica que tengan que estar embarcados en algún sitio poco accesible pero importante y no se puede subir un parche con facilidad valoran la eficiencia más que en cualquier aplicación de gestión empresarial.

[#283 sidez]

#92 No creo que sea cosa de un 10%, eso sería lo ideal, pero en muchos casos estamos hablando de perdidas muy importantes, he visto ERPs que una vez bien optimizados ahorraban a los usuarios y por ende a la empresa decenas de horas al año (por usuario) y eso no es moco de pavo. Lo mismo pasa en muchos otros entornos, la optimización empieza como dices por un buen diseño y si eso se hace bien, posiblemente todo esté relativamente optimizado.

[#98 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.

[#116 Desactivado]

#98 El compilador en C optimiza mejor que tú, lo siento. El problema son mierdas como Electron.

>y estar hecho en C y con programacion minimalista;

http://suckless.org, mpv...

[#141 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.

[#246 foxaxel]

#116 #98

Y el compilador también la caga como es normal porque está hecho por humanos.

Pero bueno es un ejemplo un poco extremo. Trabajando en cosas que requieren rendimiento muy a lo bestia, sí, dejas al compilador hacer pero de vez en cuando tienes que mirar el ensamblador porque hay cosas que no cuadran y pillas cosas que no hace bien. Pasa algunas veces si trabajas en esos entornos. Pasa lo suficiente como para que yo lo haya visto varias veces.

En entornos normales no, ahí el compilador da de sobra.

[#252 apetor]

#246 A ver, que precisamente lo que digo en #98 es que el ensamblador no se usa por optimizar, que eso es falso a dia de hoy, o una verdad muy a medias. Ensamblador se usa pa cosas que requieren usarlo. Y saber ensamblador, mas que usarlo, saber, es conveniente para programar mejor y es necesario para cierto tipo de desarrollo de software.

[#282 Penetrator]

#98 Por curiosidad, ¿en qué casos es necesario usar ensamblador?

[#303 Desactivado]

#98 No hablo de tu trabajo, no lo conozco, y seguro que hay situaciones en las que necesitas saber exactamente qué está pasando en tu máquina, pero en general, diría que irse hasta el ensamblador es totalmente innecesario. Si tienes un problema, eres tu.

[#101 CrudaVerdad]

#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".

[#103 carcadiz]

#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.

[#104 Desactivado]

#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".

[#109 varios]

#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 ....

[#113 Desactivado]

#2 A la mierda NodeJS.

[#135 Desactivado]

#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.

[#138 squanchy]

#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.

[#144 del_dan]

#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.

[#147 gotxi85]

#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 4000€, y en cambio como alternativa compras un par de palitos de ram por 165€, reinicias el tomcat de vez en cuando y a funcionar, parece que la elección es lógica.

No obstante eso ha sido muy usado como excusa para hacer software de manera perezosa, hincharse a sacar releases con poco contenido, dejar de lado temas de rendimiento (para la proxima release si eso...), y para incluir dependencias de las dependencias de las dependencias porque hacer una funcionalidad para tu caso especifico exigia mucho esfuerzo y es mejor usar funcionalidades externas y aplicar transformaciones de datos entre ellas.

Coincido con el autor del artículo en que podríamos tener mucho mas de lo que tenemos si no fuesemos tan perezosos, egoistas, pasotas o chapuceros.

[#275 freeCode]

#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.

[#304 Desactivado]

#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.

[#311 Desactivado]

#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.

[#334 MDman]

#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).

[#342 Desactivado]

#2 Eso que dices es la cultura del despilfarro.

[#345 unchusco]

#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 que podrían ser usados con mejor SW durante décadas y décadas, en contra de la filosofía del usar y tirar). También hay que tener en cuenta que un mal SW necesita mayor gasto en electricidad, tanto de CPU como de refrigeración como en comunicaciones. Además, todos estos conceptos de gastos innecesarios están creciendo de forma exponencial.
Yo pienso que tu abuelo tiene razón, educarnos en usar el pan duro para muchas cosas es bueno, sobre todo cuando piensas la de millones de toneladas de pan duro que podrían reutilizarse en todo el planeta.
El problema es complejo, porque hacer SW de calidad implica estar en contra de un mundo de prisas, de usar y tirar, de tener ya y ahora.... es un cambio de filosofía, es un cambio cultural.

[#373 darkdead4]

#138 #2 ¿De verdad ninguno sabe que se puede hacer tortillas de pan con pan de 5 días duro como piedra?
https://www.pequerecetas.com/receta/tortilla-de-pan/

[#393 Desactivado]

#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 un avión.

Los constantes bugs de seguridad, de rendimiento, de estabilidad solo dan una idea de lo rápido que está creciendo la complejidad del software de programación y el deficit de diseño que tiene este software.

El futuro del software pasa por plantearse de 0, con "planos" y "cálculos" serios como va a ser la pieza de ingeniería que se va a realizar. Lo que se ha hecho hasta hoy ha sido improvisar sobre la marcha, pero lo que la industria no está decidida a aceptar es que el software se ha convertido en una pieza lo suficientemente compleja para que tenga unos patrones de diseño acordes a su importancia.

[#10 Cidwel]

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

[#12 lalarrañaga]

#10 brillante!

[#27 TinTan]

#10 Muy bueno

[#46 Shotokax]

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

[#131 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.

[#134 triturator]

#46 Tanto npm como react, redux y el 99% de los frameworks js de hoy día son abiertos. ¿A qué te refieres?

[#335 MDman]

#46 Uff, pues lo que ha puesto de ejemplo es todo software open source...que no es software libre pero cerca...

[#69 redscare]

#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

[#224 foxaxel]

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.

[#235 frankiegth]

#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.

[#291 fluffy]

#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í: https://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.
https://github.com/npm/tink

[#1 lalarrañaga]

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"

[#24 frankiegth]

#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.

[#81 Desactivado]

#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

[#194 gonas]

#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.

[#344 jorge.rodr]

#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 madrileños.

Es evidente que no os dais cuenta de que precisamente esos chavales que la cursen, y tras un par de meses de formación auspiciado por las cárnicas, os quitarán el trabajo.

En breve la cosa será mucho peor para TODOS los informáticos cuando salgan los chavales del instituto después de dar 4 horas semanales de programación por que, con 16 años...que creéis que harán??Pues trabajar (no les quedará otra), ¿de que? de programadores, ¿por cuanto? por 650 pavos/mes. ¿Cuantos? 400.000 nuevos trabajadores. ¿Consecuencia? Olvidaros de poneros gallitos en el trabajo por que a la primera os cambian por 4 chavales con un par de semanas de formación en los entornos que "domináis".

¿Creéis que a las consultorías les importa algo la formación que tenéis?¿la calidad con la que decís que hacéis el trabajo? Les importa una puta mierda. Solo quieren ampliar sus margenes de beneficio, por lo que los que llevamos un tiempo en este sector nos iremos a la mierda (o lo que es lo mismo, a la calle).
¿¿Buscar trabajo mejor??Olvidadlo, habrá que competir con 500 personas que se apuntarán entonces a cada una de las ofertas de infojobs o tecnoempleo. También hay que tener en cuenta que en estos portales, 2 de cada 4 ofertas de empleo provienen del mismo integrador, pero son gestionadas por diferentes "cárnicas" y postulan en realidad para el mismo puesto de trabajo, así que quitaros de la cabeza eso de que la informática es un sector sobredemandado.

Tenedlo en cuenta:

a) 400.000 (según las estadísticas) chavales dentro de 4 años habrán recibido tres horas de programación (de aplicaciones móviles, osea Java) semanales. También, según las evaluaciones descritas en el Decreto (que podéis leer mas abajo) que regula el curriculum educativo de la asignatura en Madrid, Python y JavaScript ( asi que...preparaos la gente de AngularJS, JQuery,etc...)

b) A las consultoras les importa poco la experiencia y títulos que podamos aportar "los veteranos".Solo quieren trabajadores picacódigos baratos.Lo solucionan con algunas horas de formación previa.ES DECIR: EN VEZ DE CONTRATAR A UN INFORMATICO CON CARRERA QUE PIDA 42.000 BRUTOS/AÑO, CONTRATARÁN A 4 CHAVALES QUE PIDAN 16.000 cada uno.

c) Cada uno de esos chavales, aunque no le atraiga la programación, solo la tendrá como opción real profesional, ya que en ese sector, hasta ahora, nunca ha tenido problemas de oferta de empleo.Ocurría lo mismo antes a ese nivel con la construcción; si te iba mal en la escuela, podías dejarlo a los 16 años y trabajar en el ladrillo.... ... ... ... .. ... empieza a oler a burbuja no?

d) Dentro de 4 años, teniendo en cuenta la cantidad de personas capaces de programar (y al fin y al cabo también de hacer todas las funciones relacionadas con las inherentes a los departamentos CAU/IT/Microinformática) podréis iros olvidando de cambiar tan fácilmente a un empleo mejor.

e) El gobierno se ha gastado los 17 millones de € que la UE aportó para acabar con el paro juvenil en dárselo a sus amiguitos de telefónica,que a su vez se lo gasta en "formar" a profesores de tecnología que no estaban preparados para ello.

f) Tampoco hace falta esperar 4 años, ya esta ocurriendo:
vozpopuli.com/economia-y-finanzas/65091-indra-ofrece-trabajo-a-100-inf.


Leed y llorad: Extraído directamente del Decreto 48/2015 del Consejo de Gobierno por el que se establece para la Comunidad de Madrid el currículo de la Educación Secundaria Obligatoria:

Bloque 1. Programación
1. Mantener y optimizar las funciones principales de un ordenador, tableta o teléfono móvil en los
aspectos referidos a su uso, su seguridad y a las funciones del sistema operativo.
1.1. Utiliza y gestiona un ordenador bajo un sistema operativo Windows y/o una distribución de
Linux u otro sistema operativo.
1.2. Instala y desinstala de manera segura software básico (ofimática, antivirus, diseño gráfico,
robótica y simuladores tecnológicos).
1.3. Utiliza adecuadamente los dispositivos electrónicos como fuente de información y para crear
contenidos.
1.4. Usa, con soltura, aplicaciones informáticas que permitan buscar, almacenar, organizar,
manipular, recuperar presentar y publicar información, empleando de forma habitual las
redes de comunicación.
1.5. Emplea con destreza aplicaciones informáticas de ofimática (procesador de textos, hoja de
cálculo, presentaciones) para la presentación de sus trabajos.
1.6. Reconoce los riesgos informáticos y gestiona adecuadamente las aplicaciones de seguridad.
2. Analizar los diferentes niveles de lenguajes de programación
2.1. Identifica las características de los lenguajes de programación de bajo nivel.
2.2. Describe las características de los lenguajes de programación de alto nivel.
2.3. Reconoce las diferencias entre las diferentes formas de ejecución de los programas
informáticos.
2.4. Representa mediante diagramas de flujo diferentes algoritmos
2.5. Analiza el comportamiento de los programas a partir de sus diagramas de flujo.
3. Utilizar con destreza un entorno de programación gráfica por bloques
3.1. Describe el proceso de desarrollo de una animación o un juego y enumera las fases
principales de su desarrollo.
3.2. Emplea, con facilidad, las diferentes herramientas básicas del entorno de programación.
3.3. Sitúa y mueve objetos en una dirección dada.
3.4. Inicia y detiene la ejecución de un programa.
3.5. Modifica, mediante la edición, la apariencia de objetos. Crea nuevos objetos: actores, fondos
y sonidos.
3.6. Maneja, con soltura, los principales grupos de bloques del entorno.
3.7. Utiliza, con facilidad, los comandos de control de ejecución: condicionales y bucles.
3.8. Emplea de manera adecuada variables y listas.
3.9. Usa, con soltura, la interacción entre los elementos de un programa.
3.10. Analiza el funcionamiento de un programa a partir de sus bloques.
3.11. Identifica y considera las implicaciones del “diseño para todos” para los programas que
realiza.
4. Desarrollar y programar aplicaciones móviles sencillas en entornos de programación por bloques
4.1. Describe el proceso de diseño de una aplicación para móviles y las fases principales de su
desarrollo.
4.2. Utiliza con precisión las diferentes herramientas del entorno de desarrollo.
4.3. Distingue los diferentes tipos de datos y sus formas de presentación y almacenamiento.
4.4. Clasifica los objetos disponibles, sus métodos y eventos.
4.5. Identifica las posibilidades de interacción con los sensores de los que dispone un terminal
móvil.
4.6. Reconoce y evalúa las implicaciones del “diseño para todos” para los programas que realiza.
4.7. Desarrolla aplicaciones informáticas para su ejecución en dispositivos móviles utilizando
diferentes sensores y elementos de interfaz.
4.8. Describe las características y normas de publicación de diferentes plataformas para la
publicación de aplicaciones móviles.
5. Desarrollar una página Web sobre un gestor de contenidos (CMS).
5.1. Describe el procedimiento de instalación de un gestor de contenidos sobre un servidor Web.
B.O.C.M. Núm. 118 MIÉRCOLES 20 DE MAYO DE 2015 Pág. 299
BOCM-20150520-1
BOCM BOLETÍN OFICIAL DE LA COMUNIDAD DE MADRID
5.2. Analiza y asigna perfiles de usuario en función de sus características y atributos principales.
5.3. Distingue y utiliza adecuadamente los diferentes objetos de contenidos que admite el gestor.
5.4. Explica la utilidad de “componer uno” y “publicar muchos” como reutilización de los objetos
de publicación.
5.5. Utiliza adecuadamente clases de estilos para mantener y homogeneizar el aspecto de una
página Web.
5.6. Describe como integrar diferentes elementos activos – pluggins – en la página Web.
5.7. Usa de manera adecuada el almacenamiento de datos procedentes de formularios mediante
el uso responsable de los mismos de acuerdo con la legislación.
5.8. Diseña atendiendo a las consideraciones del “diseño para todos” para los programas que
realiza.
6. Analizar el proceso de programación de páginas Web en un lenguaje estándar.
6.1. Describe los lenguajes de marcado estándar: HTML y su evolución
6.2. Identifica los problemas de estandarización en la Web.
6.2.1. Navegadores libres y navegadores propietarios.
6.2.2. Tecnologías libres y tecnologías propietarias.
6.3. Emplea de forma adecuada etiquetas de marcado estándar, hojas de estilo y bases de datos
para sus programas.
6.4. Elabora programas de ejemplos de servicios básicos para Internet.
6.5. Utiliza los principios de diseño para interfaces hombre-máquina en Internet con criterio
inclusivo.
7. Desarrollar programas en un lenguaje de programación textual (Lenguajes de programación
textuales pueden ser, por ejemplo, Phyton, PHP, Processing, Alice, JavaScript, etc.).
7.1. Utiliza de manera adecuada los diferentes tipos de datos y estructuras.
7.2. Usa de forma adecuada estructuras de control de ejecución
7.3. Analiza el problema a resolver descomponiéndolo en elementos más sencillos.
7.4. Documenta adecuadamente los algoritmos y programas desarrollados incorporando
comentarios.
7.5. Emplea con facilidad el sistema de almacenamiento y archivos.
7.6. Elabora diagramas de flujo de ejecución de sus programas y algoritmos.
7.7. Analiza el funcionamiento de programas y algoritmos a partir del código.
7.8. Utiliza librerías de funciones disponibles en Internet.



FIJAOS EN QUE PONE Lenguajes de programación
textuales pueden ser, por ejemplo, Phyton, PHP, Processing, Alice, JavaScript, ETC

[#102 DaviDvD]

#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á.

[#3 Desactivado]

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.

[#5 Desactivado]

#3 (Despues de leerlo entero)

Degenera muy rápidamente en un rant de persona mayor

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.

[#6 lalarrañaga]

#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/

[#91 ollupacre]

#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.

[#133 Desactivado]

#91 Ah sí? Tú tardas lo mismo en solucionar un problema complejo en O(N²) que en hacerlo en O(logN) ?

[#152 soso2]

#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!

[#285 Desactivado]

#5 Sí, ya sabemos lo que prefiere la empresa de hoy, pero no es el buen camino.

[#306 Desactivado]

#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.

[#263 BananaAnanda]

#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!!"

[#19 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.

[#52 Desactivado]

#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)

[#176 Desactivado]

#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...

[#298 redscare]

#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

[#80 apetor]

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

[#242 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.

[#9 Desactivado]

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.

[#25 Desactivado]

#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.

[#338 Desactivado]

#25 Qu'e haces? sistemas embebidos? dispositvos con sensores?

[#281 comadrejo]

#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.

[#312 wornes]

#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.

[#55 derethor]

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.

[#88 Desactivado]

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

[#96 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.

[#212 Conde_Lito]

#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...

[#219 xavigo]

#96 ¿Una pantalla 4K en una diagonal de 6”? El 4K no lo distingues ni a 1mm de distancia

[#289 chavi]

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

[#100 Desactivado]

#88 Vamos que ni idea tienes

[#105 Desactivado]

#100 Te has matado argumentando.
Todas las resoluciones estándar existentes desde QVGA hasta 4K no ocupan 150MB ni en raw.

[#120 Desactivado]

#100 Explicamelo

[#343 jorge.rodr]

#100 Y dentro de 5 años, con la cantidad de PROGRAMADORES que van a haber....muchísimo PEOOORRR. 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 madrileños.

Conozco hijos de algúnos compañeros de trabajo que estan dando C++ en el instituto con 14 años!!!

Es evidente que no os dais cuenta de que precisamente esos chavales que la cursen, y tras un par de meses de formación auspiciado por las cárnicas, os quitarán el trabajo.(CREEDME, OS LO VAN A QUITAR: A LAS CÁRNICAS LES IMPORTA UNA PUTA MIERDA VUESTROS CONOCIMIENTOS O VUESTRA EXPERIENCIA)

En breve la cosa será mucho peor para TODOS los informáticos cuando salgan los chavales del instituto después de dar 4 horas semanales de programación por que, con 16 años...que creéis que harán??Pues trabajar (no les quedará otra), ¿de que? de programadores, ¿por cuanto? por 650 pavos/mes. ¿Cuantos? 400.000 nuevos trabajadores. ¿Consecuencia? Olvidaros de poneros gallitos en el trabajo por que a la primera os cambian por 4 chavales con un par de semanas de formación en los entornos que "domináis".

¿Creéis que a las consultorías les importa algo la formación que tenéis?¿la calidad con la que decís que hacéis el trabajo? Les importa una puta mierda. Solo quieren ampliar sus margenes de beneficio, por lo que los que llevamos un tiempo en este sector nos iremos a la mierda (o lo que es lo mismo, a la calle).
¿¿Buscar trabajo mejor??Olvidadlo, habrá que competir con 500 personas que se apuntarán entonces a cada una de las ofertas de infojobs o tecnoempleo. También hay que tener en cuenta que en estos portales, 2 de cada 4 ofertas de empleo provienen del mismo integrador, pero son gestionadas por diferentes "cárnicas" y postulan en realidad para el mismo puesto de trabajo, así que quitaros de la cabeza eso de que la informática es un sector sobredemandado.

Tenedlo en cuenta:

a) 400.000 (según las estadísticas) chavales dentro de 4 años habrán recibido tres horas de programación (de aplicaciones móviles, osea Java) semanales. También, según las evaluaciones descritas en el Decreto (que podéis leer mas abajo) que regula el curriculum educativo de la asignatura en Madrid, Python y JavaScript ( asi que...preparaos la gente de AngularJS, JQuery,etc...)

b) A las consultoras les importa poco la experiencia y títulos que podamos aportar "los veteranos".Solo quieren trabajadores picacódigos baratos.Lo solucionan con algunas horas de formación previa.ES DECIR: EN VEZ DE CONTRATAR A UN INFORMATICO CON CARRERA QUE PIDA 42.000 BRUTOS/AÑO, CONTRATARÁN A 4 CHAVALES QUE PIDAN 16.000 cada uno.

c) Cada uno de esos chavales, aunque no le atraiga la programación, solo la tendrá como opción real profesional, ya que en ese sector, hasta ahora, nunca ha tenido problemas de oferta de empleo.Ocurría lo mismo antes a ese nivel con la construcción; si te iba mal en la escuela, podías dejarlo a los 16 años y trabajar en el ladrillo.... ... ... ... .. ... empieza a oler a burbuja no?

d) Dentro de 4 años, teniendo en cuenta la cantidad de personas capaces de programar (y al fin y al cabo también de hacer todas las funciones relacionadas con las inherentes a los departamentos CAU/IT/Microinformática) podréis iros olvidando de cambiar tan fácilmente a un empleo mejor.

e) El gobierno se ha gastado los 17 millones de € que la UE aportó para acabar con el paro juvenil en dárselo a sus amiguitos de telefónica,que a su vez se lo gasta en "formar" a profesores de tecnología que no estaban preparados para ello.

f) Tampoco hace falta esperar 4 años, ya esta ocurriendo:
vozpopuli.com/economia-y-finanzas/65091-indra-ofrece-trabajo-a-100-inf.


Leed y llorad: Extraído directamente del Decreto 48/2015 del Consejo de Gobierno por el que se establece para la Comunidad de Madrid el currículo de la Educación Secundaria Obligatoria:

Bloque 1. Programación
1. Mantener y optimizar las funciones principales de un ordenador, tableta o teléfono móvil en los
aspectos referidos a su uso, su seguridad y a las funciones del sistema operativo.
1.1. Utiliza y gestiona un ordenador bajo un sistema operativo Windows y/o una distribución de
Linux u otro sistema operativo.
1.2. Instala y desinstala de manera segura software básico (ofimática, antivirus, diseño gráfico,
robótica y simuladores tecnológicos).
1.3. Utiliza adecuadamente los dispositivos electrónicos como fuente de información y para crear
contenidos.
1.4. Usa, con soltura, aplicaciones informáticas que permitan buscar, almacenar, organizar,
manipular, recuperar presentar y publicar información, empleando de forma habitual las
redes de comunicación.
1.5. Emplea con destreza aplicaciones informáticas de ofimática (procesador de textos, hoja de
cálculo, presentaciones) para la presentación de sus trabajos.
1.6. Reconoce los riesgos informáticos y gestiona adecuadamente las aplicaciones de seguridad.
2. Analizar los diferentes niveles de lenguajes de programación
2.1. Identifica las características de los lenguajes de programación de bajo nivel.
2.2. Describe las características de los lenguajes de programación de alto nivel.
2.3. Reconoce las diferencias entre las diferentes formas de ejecución de los programas
informáticos.
2.4. Representa mediante diagramas de flujo diferentes algoritmos
2.5. Analiza el comportamiento de los programas a partir de sus diagramas de flujo.
3. Utilizar con destreza un entorno de programación gráfica por bloques
3.1. Describe el proceso de desarrollo de una animación o un juego y enumera las fases
principales de su desarrollo.
3.2. Emplea, con facilidad, las diferentes herramientas básicas del entorno de programación.
3.3. Sitúa y mueve objetos en una dirección dada.
3.4. Inicia y detiene la ejecución de un programa.
3.5. Modifica, mediante la edición, la apariencia de objetos. Crea nuevos objetos: actores, fondos
y sonidos.
3.6. Maneja, con soltura, los principales grupos de bloques del entorno.
3.7. Utiliza, con facilidad, los comandos de control de ejecución: condicionales y bucles.
3.8. Emplea de manera adecuada variables y listas.
3.9. Usa, con soltura, la interacción entre los elementos de un programa.
3.10. Analiza el funcionamiento de un programa a partir de sus bloques.
3.11. Identifica y considera las implicaciones del “diseño para todos” para los programas que
realiza.
4. Desarrollar y programar aplicaciones móviles sencillas en entornos de programación por bloques
4.1. Describe el proceso de diseño de una aplicación para móviles y las fases principales de su
desarrollo.
4.2. Utiliza con precisión las diferentes herramientas del entorno de desarrollo.
4.3. Distingue los diferentes tipos de datos y sus formas de presentación y almacenamiento.
4.4. Clasifica los objetos disponibles, sus métodos y eventos.
4.5. Identifica las posibilidades de interacción con los sensores de los que dispone un terminal
móvil.
4.6. Reconoce y evalúa las implicaciones del “diseño para todos” para los programas que realiza.
4.7. Desarrolla aplicaciones informáticas para su ejecución en dispositivos móviles utilizando
diferentes sensores y elementos de interfaz.
4.8. Describe las características y normas de publicación de diferentes plataformas para la
publicación de aplicaciones móviles.
5. Desarrollar una página Web sobre un gestor de contenidos (CMS).
5.1. Describe el procedimiento de instalación de un gestor de contenidos sobre un servidor Web.
5.2. Analiza y asigna perfiles de usuario en función de sus características y atributos principales.
5.3. Distingue y utiliza adecuadamente los diferentes objetos de contenidos que admite el gestor.
5.4. Explica la utilidad de “componer uno” y “publicar muchos” como reutilización de los objetos
de publicación.
5.5. Utiliza adecuadamente clases de estilos para mantener y homogeneizar el aspecto de una
página Web.
5.6. Describe como integrar diferentes elementos activos – pluggins – en la página Web.
5.7. Usa de manera adecuada el almacenamiento de datos procedentes de formularios mediante
el uso responsable de los mismos de acuerdo con la legislación.
5.8. Diseña atendiendo a las consideraciones del “diseño para todos” para los programas que
realiza.
6. Analizar el proceso de programación de páginas Web en un lenguaje estándar.
6.1. Describe los lenguajes de marcado estándar: HTML y su evolución
6.2. Identifica los problemas de estandarización en la Web.
6.2.1. Navegadores libres y navegadores propietarios.
6.2.2. Tecnologías libres y tecnologías propietarias.
6.3. Emplea de forma adecuada etiquetas de marcado estándar, hojas de estilo y bases de datos
para sus programas.
6.4. Elabora programas de ejemplos de servicios básicos para Internet.
6.5. Utiliza los principios de diseño para interfaces hombre-máquina en Internet con criterio
inclusivo.
7. Desarrollar programas en un lenguaje de programación textual (Lenguajes de programación
textuales pueden ser, por ejemplo, Phyton, PHP, Processing, Alice, JavaScript, etc.).
7.1. Utiliza de manera adecuada los diferentes tipos de datos y estructuras.
7.2. Usa de forma adecuada estructuras de control de ejecución
7.3. Analiza el problema a resolver descomponiéndolo en elementos más sencillos.
7.4. Documenta adecuadamente los algoritmos y programas desarrollados incorporando
comentarios.
7.5. Emplea con facilidad el sistema de almacenamiento y archivos.
7.6. Elabora diagramas de flujo de ejecución de sus programas y algoritmos.
7.7. Analiza el funcionamiento de programas y algoritmos a partir del código.
7.8. Utiliza librerías de funciones disponibles en Internet.
FIJAOS EN QUE PONE Lenguajes de programación
textuales pueden ser, por ejemplo, Phyton, PHP, Processing, Alice, JavaScript, ETC

[#30 Desactivado]

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.

[#57 Desactivado]

#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.

[#74 redscare]

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

[#82 Desactivado]

#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.

[#115 blid]

#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.

[#125 Desactivado]

#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.

[#4 ingenieril]

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...

[#7 Desactivado]

#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...

[#14 Nova6K0]

#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

[#71 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

[#118 Desactivado]

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

[#255 Shotokax]

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

[#18 mcfgdbbn3]

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

[#72 llorencs]

#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.

[#107 mcfgdbbn3]

#72: Pues eso, que entre unos y otros, cada vez se consume más memoria cabro RAM de forma injustificada.

[#121 DaviDvD]

#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?

[#124 pawer13]

#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.

[#183 Desactivado]

#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.

[#8 Desactivado]

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

[#130 triturator]

#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".

[#234 frankiegth]

#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.

[#44 Desactivado]

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.

[#175 meneandro]

#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).

[#392 cosmonauta]

#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.

[#34 ur_quan_master]

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

[#40 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...

[#49 eduardor2k]

#40 Diseñar bien un software es mas importante que tal vez optimizar un bucle for

[#78 redscare]

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

[#89 eduardor2k]

#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.

[#65 Abeel]

#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

[#148 lutarK999]

#65 claro, lo que pasa es que creo que, en general, somos más los de las cárnicas que los de Google

[#26 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]

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

[#70 Desactivado]

#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]

[#95 Trublux]

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

[#106 triturator]

#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.

[#43 Desactivado]

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

[#267 BananaAnanda]

#43 Kali Yuga a tope

[#76 PacoJones]

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".

[#75 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

[#41 RubiaDereBote]

#38 Puedes no aparecer por la oficina

[#45 Desactivado]

#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.

[#61 RubiaDereBote]

#45 Ok, entonces tu problema es otro. Ojalá se te arregle la situación.

[#53 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

[#42 dospuntoswq]

A todo el que le interese este problema debería ver esta charla de Uncle Bob

[#93 kucho]

#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.

[#110 Desactivado]

#93 De la wiki del COD:

Para febrero de 2016, la serie de Call of Duty ya había vendido 250 millones de copias y alcanzaron los 15 mil millones de dólares estadounidenses en ventas totales, incluyendo contenido in-game.1

Elijo este por ser el primer AAA que se me ha ocurrido. Porque si pago 60 espero que sea un AAA (nunca lo haré espero siempre unos meses a las ofertas de steam, no me corre prisa jugar al ultirmo refrito de nada). Creo que con esos numeros, con la cuarta parte, te da para pagar a tecnicos un timpo considerable para hacer un trabajo decente. Y no voy a hablar de todos los ingresos via e-sports y otras mierdas. Con esos numeros que te den algo lleno de bugs (como el juego de batman que disney tuvo que devolver el dinero) es una maldita tomadura de pelo. Me cobras la mierda a precio de oro.

[#271 Desactivado]

#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.

[#340 osids]

#93 El problema es que ese tiempo de optimización y revisión de software suele mejorar sustancialmente la calidad pero vamos que el día que alguien se cuele y robe el dinerito me voy a reir

[#47 Manuelis]

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.

[#97 Desactivado]

#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í.

[#68 multimed]

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 Front-End.

- No tiene sentido poner virtualización encima de virtualización: Docker encima de AWS. Por mucho que a todos los desarrolladores y devops les encante AWS no quiere decir que sea lo mejor. De hecho, es de los hostings más caros que hay. Además con AWS tienes que hacer todo a su manera, lo que provoca que la gente se especialice en herramientas propietarias y ya no sepa prácticamente manejarse por consola en un entorno Unix.

[#169 meneandro]

#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).

[#87 Desactivado]

#63 se quiere software bueno bonito barato y luego solo acaba siendo.... Ninguna de las 3.