Portada
mis comunidades
otras secciones
#21:
La historia de siempre, como el que programa mal. Como el hardware es barato programo como el culo, total, si tienes que comprarte un nuevo procesador para mi cutrenotepad moderno chupiguay te lo compras. Lo de pensar que hemos llegado a la velocidad maxima de los conductores baratos y que no queda mas remedio que reducir tamaños para meter mas chips si eso lo dejamos para otro articulo.
Comentarios
La historia de siempre, como el que programa mal. Como el hardware es barato programo como el culo, total, si tienes que comprarte un nuevo procesador para mi cutrenotepad moderno chupiguay te lo compras. Lo de pensar que hemos llegado a la velocidad maxima de los conductores baratos y que no queda mas remedio que reducir tamaños para meter mas chips si eso lo dejamos para otro articulo.
#21 --editado--
#21 Además cuanto más eficiente sea el programa mejor escalará para conjuntos de datos mayores.
#21 #28 Si hubiera un lenguaje mágico que lo hiciera todo bien, sólo usaríamos ese. Pero con cualquier lenguaje de programación tienes que escoger un punto entre estas dos características:
1. Que el código sea rápido y eficiente
2. Que el lenguaje sea potente y abstracto y permita hacer un montón de cosas chulas con poco código
¿Quieres código rapidísimo? No problem, lo que pasa es que el desarrollador va a tardar 10 veces más en escribir el código que si lo hace en python, que irá más lento pero igual lo tiene hecho en una mañana.
Al final todo depende del problema: si el rendimiento/tamaño no es crítico, es mejor un lenguaje abstracto tipo python o Java, que te permitirán tener el producto listo más deprisa y con menos esfuerzo. Si estás haciendo un juego, o algo para Arduino o algo así donde el rendimiento/tamaño sea crucial, pues lo harás en C o algo así, y te gastarás más pasta en sueldo del programador, porque va a tardar bastante más.
#42: A lo mejor gastas más dinero, pero si es un dinero que vas a tirar en cambios innecesarios, a lo mejor compensa.
Y más si lo que te juegas es que la gente empiece a dejar de usar tu producto.
#43 Si lo vas a tirar en cambios innecesarios, por supuesto que es una mala decisión. Pero si tienes que escoger entre rendimiento y características añadidas... ahí sí que hay que establecer prioridades. Y en muchos casos una funcionalidad concreta es mucho más importante que un segundo arriba o abajo.
Pero al final la moraleja es que tienes lo que pagas, y que entre bueno, bonito y barato puedes escoger dos como máximo.
#42 ¿Y quien habla de lenguajes mágicos? Hablamos de hacer las cosas bien, que no haya un lenguaje perfecto no implica hacer lo que te de la gana con el lenguaje que quieras. Una de las cosas a tener en cuenta a la hora de desarrollar una aplicación son las necesidades tecnicas de esta y las habilidades del equipo (en este caso solo uno mismo). Una cosa es verse limitado por el conocimiento (solo saber programar en un lenguaje) y otra cosa muy distinta es hacer una puta mierda por capricho implicando un consumo desmedido de recursos, que es lo que intenta justificar el articulista. Los caprichos que se los quede para el, no pago por mierda.
#45 Es que puedes hacer las cosas tan bien como quieras, si tienes el suficiente dinero. La gracia de la ingeniería no es hacer las cosas perfectas, eso está chupado gastando suficiente pasta. Lo importante, y lo más difícil, es hacerlas lo suficientemente bien como para resolver el problema, gastando el mínimo dinero posible.
Los programadores mediocres son más baratos que los putos máquinas que son unos virtuosos, eso es un recurso más. Por eso, ante la necesidad de resolver un problema, hay que decidir cuánto nos queremos gastar, y a lo mejor nos basta con el mediocre. Porque si nos ponemos puristas y sólo buscamos la excelencia, nuestro producto va a costar 10 veces más que el de la competencia que resuelve el mismo problema (aunque tarde un segundo más), y me iré a pique.
Incluso sin un enfoque tan económico, hay que ser buen estratega, y si por hacer concesiones en rendimiento podemos añadir funcionalidades mejores, a lo mejor globalmente compensa. Pero al final es todo una cuestión de gestión de recursos, y la ingeniería el arte de hacer las cosas lo peor posible, dentro de que cumplan especificaciones
#46 "La gracia de la ingeniería no es hacer las cosas perfectas"
Claro que no, porque ninguno somos perfecto, la gracia está intentarlo. La única manera de mejorar.
"Los programadores mediocres son más baratos que los putos máquinas que son unos virtuosos"
Recurso habitualmente utilizado en empresas explotadoras que viven de proyectos para la adminisrtación publica o amiguetes. En empresas tecnologicas de verdad si se paga barato a alguien es porque su trabajo carece de relevancia y puede hacerlo cualquiera. El problema es que aqui en España, no quieren mediocres, si no juniors que es peor, para todo, haciendolos pasar por tecnicos especialistas mediocres. Y que justifiques este hacer en pro del beneficio empresarial cuando solo es posible con redes clientelares dice mucho de ti y de la calidad del software que produces.
#47 No estoy justificando nada ni diciendo que sea la mejor opción. Sólo digo que las cosas tienen un coste, y que obviamente cuanto más dinero metas en algo mejor te va a quedar, pero no siempre compensa.
La perfección no siempre es necesaria, ni tiene sentido buscarla. Si necesito un script que lance un backup cada noche, puede tenerlo listo en 30 segundos en tres líneas de bash, o puedo dedicar una hora a escribir un programa en C++ que haga las llamadas de sistema oportunas para hacer lo mismo. Esta última opción será objetivamente más rápida y eficiente, pero esa eficiencia no me aporta nada en cuanto al resultado final, y encima he gastado unos recursos (de tiempo y dinero) que podría haber dedicado a otra cosa más necesaria. Este es un ejemplo chorra, pero puedes escalar lo mismo a cualquier situación, y resulta que al final la ingeniería es siempre lo mismo: hacer malabarismos entre eficiencia y recursos disponibles para conseguir un objetivo, sin que las decisiones que tomes impliquen necesariamente que seas un cutre por no haber buscado la perfección absoluta.
#48 Hombre, lo de los scripts es un tema aparte, al menos el que pones de ejemplo que basicamente es una automatizacion de una tarea administrativa y esta muy lejos de tener la complejidad que tiene una aplicacion totalmente desarrollada. En tu script te limitaras a invocar unos binarios del sistema que no has implementado tu y estan hechos de putisima madre y por eso tu script funciona tan bien. Porque programar no has programado nada, has usado aplicaciones ya hechas, y muy eficientes. Y por eso tu script funciona tan bien con tan poco esfuerzo, porque otros se han esforzado en hacer lo que tu dices que no hay que hacer.
#51 No, hay muchas tareas que puedes hacer con scripts y que son objetivamente órdenes de magnitud más lentas e ineficientes que lo mismo hecho con un programa específico. La gracia es que, en ocasiones, el rendimiento no es la prioridad número uno, ni la número dos, ni la número tres.
Todo depende en el contexto en que estés, y de las necesidades que tengas. Siempre. La búsqueda del rendimiento y la eficiencia máxima a veces es importante, pero muchas veces no, y si nos emperramos en buscarla, por necesidad estamos dejando de lado otros aspectos que quizá en ese caso son más importantes, por lo que no estamos haciendo bien nuestro trabajo.
#52 "No, hay muchas tareas que puedes hacer con scripts y que son objetivamente órdenes de magnitud"
"Todo depende en el contexto en que estés, y de las necesidades que tengas. "
Creo que he sido bastante claro especificando de que hablaba, no hablaba de cualquier script. Si no del que ejemplificaste. Si tu en tu script llamas por ejemplo al dumper de una base de datos. La tarea va a tardar exactamente lo mismo que si invocas directamente desde consola el dumper. Porque es hacer lo mismo. Otra cosa es que digas, soy mas chulo que un ocho y para el copiado del fichero resultante en lugar de tirar del binario cp voy a hacer un copiado byte a byte con un sleep en cada iteracion solo por tocar los cojones. Pues si, entonces tardaras mas.
#53 Y yo te he dicho que era un ejemplo, y que el mismo tipo de elecciones las puedes hacer a casi todos los niveles. Siempre hay varias formas de hacer las cosas, diferentes en función de factores como rapidez de desarrollo, eficiencia del código, mantenibilidad... Y en cada caso hay que evaluar cuáles son las prioridades en ese momento, y tomar una decisión. De nada me sirve tener el código más rápido del mundo si no lo entiende más que el que lo ha escrito (que mañana se puede ir), o si necesito 6 meses para hacerlo pero tiene que estar en una semana.
#54 Creo que estamos debatiendo cosas diferentes. eres un desarrollador que hereda el mantenimiendo del producto o eres alguien comprando el producto? Porque si es lo segundo la facilidad de mantenimiento a ti te da igual mientras que el encargado de ello (la desarrolladora) lo haga. Cuando lanzas un producto te comprometes a un tiempo de mantenimiento. Si el mantenimiento es pesimo o va a desaparecer cambias de producto. ¿O pretendes decirme que cuando te pasa eso sigues usando un producto deprecated?
#55 Aunque simplemente seas un comprador de software, los aspectos relacionados con el desarrollo te afectan igual. Porque si una empresa hace un software súper óptimo, pero que sólo lo entiende el programador, seguramente tendrá que reescribirlo de cero a los pocos años, y eso tiene un coste notable que, obviamente, se repercutirá al cliente. Y aunque te comprometas a X años de mantenimiento, si tu programador estrella se va a otro sitio, vas a tener que gastarte un buen dinero, por lo que ya no te sale tan rentable la cosa.
Al final es mercado, y se trata de ver qué prefiere el cliente: ¿un software muy muy rápido y eficiente por 10.000 eur, o uno no tan rápido pero que sólo vale 250? ¿Cuál es objetivamente mejor? Ninguno, en realidad. Depende del caso.
Python da asco,larga vida a Java
#1 uy loquehadicho
#1 Java da pena, larga vida al BASIC.
#3 mis queridos gotos ...
#7 Hay goto, hay meneo
#14 #13 #10 #5 #4 #3 os preparare una hoguera para juntaros con los sincebollistas y hacer de este mundo un lugar mejor.
#16 Calla, que tú seguro que eres ciclista los fines de semana.
#16 Eh, eh, eh! que yo soy del frente cebollista de Judea. Un respeto.
#16 Lo siento, yo no entro, yo soy concebollista
#3 BASIC da pena, larga vida al ensamblador.
#3 #1 Os veo en la proxima vida picando tarjetas perforadas en Cobol... el karma funciona (edit - faltaba el "veo")
#30 reportado por incitación al odio
#1 A veeeer haya paz, a los de la programacion procedimental nos dais asco todos los lenguajes con paradigma de objetos por igual
#4 donde esté el Miranda!
#4 programacion procedimenta ya tardaba en aparecer los que se creen guais de la clase,pero en realidad son unos marginados.
#9 #15 #17 Haysss nenes de web...
#20 "haysss" ¿en serio? ¿"Haysss"?
#4 Presumir de programador procedimental es como presumir de estar soltero pero porqur nadie te quiere.
#4 Tú no tienes clase
#4 a mí me dan asco todos. Viva C++ con punteros.
#1 Java da asco, larga vida a go
#10 go da asco, larga vida a Ada
#11 #10 Ada da asco, larga vida al BASIC
#1 Java da asco, larga vida a Scala
#1 De Java se aprovecha el café y a mí no me gusta el café, así que ni eso.
Larga vida a Python
#1
- Toc, toc
- quién es?
- ...
- ...
- ...
- ...
- ...
Hola! Soy Java!
#25
(pero el chiste solo vale si se compara con un lenguaje compilado, no con uno interpretado como los que han defendido aquí la mayoría)
Pues yo soy usuario, soy el que paga la electricidad, la batería, el que espera cuando usa el producto... y si me importa que tu lenguaje de programación sea una birria, si es que merece ser considerado como "lenguaje de programación" y no como producto educativo usado en entornos de producción.
Si se trata de un software libre, lo perdono, pero en productos privativos que pagas en caja o bien por medio de la venta de datos personales... por favor, optimízamelo, que para eso pago.
Si no hay recursos, dejad de tirar el dinero en cambios que ni se os ha pedido ni son necesarios y centrad los recursos de programación en que la aplicación vaya a la velocidad que se supone que debería ir un producto con esa funcionalidad. Yo no necesito que todo se mueva según paso el ratón, si necesito que el programa no me chupe la memoria
cabroRAM o ocupe ciclos de CPU que procesador que quiero usar para otra cosa o que prefiero dejar en blanco para ahorrar energía.#28 Es tecnología de servidor, no de cliente
#36: En ese caso si puede ser razonable, depende mucho del tipo de código que sea:
- Si es un código efímero que se va a usar poco, pues si, lo que se programe más rápido.
- Si es un código que se va a usar numerosas veces, conviene optimizarlo o directamente hacerlo en lenguajes más rápidos.
#28 He leído tu comentario y estoy leyendo el meneo. Saco dos conclusiones:
El que escribe el artículo confunde conceptos, tú los mezclas un poco.
Python es un lenguaje de programación potente y muy útil para algunas cosas, no es un "producto educativo". Luego está ese "optimízamelo, que para eso pago": pagas por lo que te dan, y si invierten dinero en optimizarlo vas a tener que pagar más. Quizá prefieras pagar más por el uso y que vaya un poco más rápido, quizá no, eso ya es variable.
#38: Pero es que al final propongo de dónde se puede sacar ese coste extra: de no hacer cambios innecesarios o implementar funciones no necesarias. Al final uno se aburre de ver cómo el botón "actualizar", lejos de significar "más y mejor" suele significar "lo mismo pero más difícil de usar o más pesado y lento". Al final uno acaba evitando las actualizaciones porque sabe lo que le deparan.
Relacionada Como mejorar el rendimiento de una web puede salvar el planeta [eng]
Como mejorar el rendimiento de una web puede salva...
smashingmagazine.comY a mi no me importa que a ti no te importe
¿Pero tan lento como una golondrina africana o como una golondrina europea?
no deja de ser cierto que el hardware va siendo cada vez más barato. No es la primera vez que oigo que ante un proceso que va lento la solución que se propone es tener la base de datos en memoria porque la RAM es barata. Y ojo, que no es ninguna burrada. Al precio que está la memoria RAM cualquier empresa se lo puede permitir, pero eso no quita que se optimicen los procesos.
El otro día sin ir más lejos tuve que revisarme un proceso que un inútil había programado hace años que tardaba en ejecutarse casi una hora, un tiempo exageradamente largo para lo que se suponía que tenía que hacer. El susodicho proceso se revisaba unos 200K registros y para cada uno de ellos hacía una complicada búsqueda en la base de datos para ver había registros relacionados que cumplieran ciertas condiciones. La optimización consistió básicamente en identificar primero los registros que cumplían esas condiciones y en base a eso buscar los registros afectados dentro de esos 200K. Como los registros que cumplían esas condiciones eran menos de un 0,05% el proceso optimizado dura ahora apenas 1 minuto. Ni que decir tiene que el inútil que programó aquel engendro fui yo mismo. En mi defensa solo puedo argumentar que en la época en que programé aquel engendro no habia 200K registros sino como mucho una décima parte. Ale, he confesado, ya podéis lapidarme.
#39 tener la base de datos en memoria porque la RAM es barata
Welcome to SAP HANA.
La optimización consistió básicamente en identificar primero los registros que cumplían esas condiciones
La solución general es programarlo de forma que se lea primero los datos a procesar y los ordene y filtre en función de lo que va a hacer. Luego los procesa.
Ordenar es primordial, pues agrupa accesos de consulta. Ni siquiera suele hacer falta programarlo si se usa una bbdd con cache.
Luego descartar los registros que se sabe que no se van a poder procesar con algún criterio. Ahí ayuda mucho disponer de metadatos (preprocesados).
Muchas veces la culpa de que un programa en Python sea lento es más del que lo escribe que del propio lenguaje.
Pues si a él no le importa, que se imagine lo que me importa a mí que no trabajo con Python.
bonito meneo de un artículo de hace 2 años. Está más visto que el TBO
Pero... nadie ha mencionado a Julia en una notícia así.
Poneros al dia: https://en.wikipedia.org/wiki/Julia_(programming_language)
Ahora vas y se lo dices al que paga la luz de "mis" clusters, al jefe de proyecto cuyo grupo necesita sacar adelante el trabajo de todo el año en las 3 semanas en las que tiene alguno de los sistemas a su disposición o al que le vence la fecha para presentar las modificaciones exigidas por un referee y tiene que incluir los resultados de unos cálculos...
Larga vida a FORTRAN77!