Barrapunto

No se como esta construido Gnumeric, pero lo cierto es que la optimizacion de las aplicaciones es algo que deberia ser el referente en el software libre... El otro dia lei algo aqui que personalmente me escandalizo: alguien puso un comentario diciendo que no entendia para que narices hacia falta ajustar hasta la ultima instrucciones teniendo los maquinones y la memoria de que disponemos hoy en dia... Economizar memoria y recursos del sistema deberia ser el pan nuestro de cada dia entre los programadores, de todo tipo, pero especialmente los que realizan software libre, para crear aplicaciones que den mayor rendimiento y aprovechen mejor las posibilidades del sistema... Y esto es un referente fundamental en las aplicaciones orientadas a Internet. Lo de "escribe y ya depuraras" es algo que deberia pasar a la historia, y personalmente creo que se deberia educar a los programadores en aprender a corregir y optimizar codigo mientras se va a escribiendo... Es algo que los que llevamos muchos años hacemos casi automaticamente, pero deberia conseguirse que los programadores noveles adquirieran esa conciencia de hacer los programas bien desde el principio, y no nos encontrariamos con tanto cascorro que hay por ahi...

Uso Gnumeric en un 233Mhz+96MB y en un 600MHz+256MB (anteriormente 350MHz+64MB). No son hojas muy complicadas, pero si algo grandes, y, salvo la carga que si que se nota algo lenta (imagino que parte de la culpa será el formato usado), van perfectamente.
Seguramente muchas aplicaciones libres están algo faltas de optimización, gnumeric entre ellas.
¿Has comprobado la versión que estás usando?. Yo tengo instalada la 0.56 (como no me da problemas y hace lo que quiero, ni me he molestado en ver si hay versiones actualizadas, esten estas recargadas u optimizadas).

Si, pero no hay que olvidar que no es una versión "estable" todavía, hasta que no se llega a una versión 1.0 no se considera estable y por tanto los esfuerzos de programación se centran en que las cosas funcionen y que se añadan prestaciones nuevas, el tiempo de optimización ya llegará.

Lo que pasa es que como todas estas aplicaciones de Linux que actualmente están en desarrollo nos dan unas prestaciones casi similares a las de Windows (o de Linux tambien, por ejemplo Netscape 6.0, para la comunidad de software libre está todavía en desarrollo, pero para Netscape esa versión piensa que es ya la final :-? ) que están ya oficialmente "estables" pues se nos olvida ese detalle.

Tened eso en cuenta. ;-)

Me reafirmo: desconozco el estado de Gnumeric. Lo que indico es que incluso las versiones beta deben escribirse "bien" desde el principio... Personalmente cuido mucho el codigo que escribo, e intento que este bien hecho desde la primera linea, incluso aunque evidentemente tenga errores y despues haya que corregirlos... Para eso hay que tener en la cabeza bien claro el diseño inicial y como desarrollarlo. Lo que quiero decir es que a mi nadie me va a convencer de que hay que poner mucho codigo de depuracion, ni que no importa a priori que metas "basura" en el codigo... Cuando uno programa bien, programa bien desde el principio. Si se hicieran las cosas asi, los proyectos durarian mucho menos tiempo y necesitarian menos carga de trabajo despues durante el periodo de depuracion.

Para mi muchas aplicaciones de M$ no son mas que simples betas que se lanzan como finales... La mayoria estan repletas de codigo depuracion y las dependencias del depurador aun no han sido eliminadas... Por eso te salta el depurador de VC++ cada vez que ocurre un error en muchos programas... La prueba es el propio Windows: si no, no se explica que tenga tantas pantallas azules... Simplemente se colgaria, pero no aparecerian las pantallas azules... Un buen codigo errores no sacaria una pantalla azul (prueba irrefutable de un depurador), sino lindas ventanitas diciendo: ha ocurrido tal cosa. Y en el caso de un error irreparable, el propio Windows haria salir el programa sin mayor problema. Pero claro, esto no es evidente...

Prefiero una aplicacion que en la release tenga alguna utilidad menos, que el que te hagan pasar una beta por la misma release, con la excusa de que tiene no se cuantos "features" mas que la version anterior...

Esta demostrado que las optimizaciones tempranas son una mala costumbre. Yo tiendo a optimizar solo las partes criticas ya que la mayoria de las optimizaciones hacen el codigo mas dificil de mantener y comprender.Y no puedes saber si la parte que estas escribiendo en ese momento no sera suficiente rapida hasta que este terminada (Siempre con excepciones)Pero como todo es mi humilde opinion.

Más bien de "sobreaprovechar" los recursos.

Pero a mí las aplicaciones en Windows 2000 me van muy ligeritas.

Pues lo tenemos bien jodido, porque creo que la tendencia actual es la contraria.

Para eso se ha inventado la expresión creeping featurism (características crecientes), que es una enfermedad de que adolecen muchos programas. Consiste en agrandar la lista de cosas que hace: "Pues vamos a meterle un Tetris oculto".

Creo que lain se refiere a escribir el código con limpieza. No a coger un listado de ensamblador y ahorrar tres ciclos en este bucle poniendo las instrucciones alineadas de algún modo extraño sugerido por Intel; sino, por ejemplo, cuidar las estructuras de datos y no tirar la casa por la ventana pensando que "volverás a pasar por ahí".

Aunque esto es una interpretación libre de sus palabras.

Los de Mozilla no opinan igual. Mozilla es pesado como un quintal métrico y lento como una tortuga.

Aunque no tenga nada que ver con lo que estamos discutiendo, Ken Thompson (creador de Unix) dice que los proyectos grandes tienen el problema de que algunas partes del código tienen mucha calidad y otras muy poca. Lo dijo en esta entrevista. Desgraciadamente, se refería al núcleo Linux. Y aunque, en mi opinión, este núcleo es una obra maestra de la ingeniería, creo que su afirmación es aplicable a Mozilla, porque a estas alturas me pregunto cómo van a aligerarlo.

Si los tíos hubieran tenido más cuidado desde el principio, tal vez Mozilla sería ligero (como pretendían). ¡Que las técnicas de programación existen desde tiempos inmemorables! Y a quien construye una aplicación con los algoritmos mal diseñados, luego le resulta muy difícil cambiar la estructura.

Me refiero tanto a escribir codigo limpio (bueno, otra cosa fundamental, aunque no era el tema), como a escribir codigo eficiente, tambien desde el principio... Si yo se que haciendo las cosas de una determinada forma, el programa va a ser mas rapido o va a requerir menos memoria, voy a usarlo, aunque tarde 15 minutos mas que haciendolo de otra forma... Al final, ese codigo eficiente podra tener algun error, pero sera facilmente subsanable si esta bien escrito, lo cual entronca con lo que tu decias.

Puedo equivocarme, pero creo que han hecho todo el codigo desde cero... Y eso es otra cosa realmente detestable... Es una practica habitual en el software libre reaprovechar el codigo hecho por otros. Por que no usaron GTK o QT para hacerlo, sabiendo que son sistemas portables? Se habrian ahorrado mucho trabajo, y tendrian un codigo ya probado para trabajar. Han hecho un batiburrillo pretendidamente supercompatible que lo unico que hace crear un conjunto demasiado lento y pesado. Pero en fin, eso es problema de quien toma las decisiones de diseño, no del programador...

Si, pero no es libre...

creo que han hecho todo el codigo desde cero...

Tengo entendido que sí: El gecko, el necko, el XBL, etc...

Y eso es otra cosa realmente detestable...

A mí eso no me importa; por ejemplo creo que Apache 2.0 está prácticamente reescrito. Supongo que a veces es mejor romper con todo aunque sea de forma progresiva, como han hecho con Mozilla.

Por que no usaron GTK o QT para hacerlo, sabiendo que son sistemas portables?

Eso es lo que menos entiendo de Mozilla. Les hubiera salido mejor hacer una capa intermedia para poder portar. Pero no, se han currado un "UI" lentísimo.

Hola,

Para empezar deberias intentar actualizar a la ultima version de Gnumeric, en las ultimas versiones se han introducido optimizaciones importantes.
Si aun sigue igual de lenta agrega un bug en bugzilla.gnome.org con un libro que te cause problemas, el equipo de desarrollo de Gnumeric esta siempre atento al bugtracker.

A mí eso no me importa; por ejemplo creo que Apache 2.0 está prácticamente reescrito. Supongo que a veces es mejor romper con todo aunque sea de forma progresiva, como han hecho con Mozilla.

Yo no digo que no se deba escribir codigo original, lo que digo es que habiendo posibilidades alternativas, es un poco bastante absurdo e inutil hacerlo todo desde cero, sobre todo trabajando con software libre... Eso es mas propio del software propietario, donde se lo tienen que currar todo de 0...

¿Sabes lo que es trabajar en equipo?

No solo tienes que hacer las cosas de una forma que funcionen sin problemas y que tu las entiendas sino que el equipo con el que estás trabajando tambien lo entienda, si optimizas a saco todo suele ser más dificil de entender las cosas (incluso para ti unos meses más tarde) y tambien te puede ocultar fallos que no ves. Si el equipo en global no es capaz de entender lo que hace cada miembro, lo siento por ese proyecto pues no le veo mucha vida...

No es una excusa... Eso implica que los demas miembros del equipo no saben leer codigo... Por cierto, que yo eso lo pondria en primero de carrera como asignatura obligatoria...