Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Ver: Modo: Orden:
Aprendiendo a programar | 37 comentarios (37 temáticos, editoriales, 0 ocultos)
La eficiencia (none / 0) (#22)
por jorginius ("jorginius" en Google Mail) a las Fri Jul 23rd, 2004 at 04:33:14 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Pero para los que nos preocupamos por la eficiencia, es absurdo usar un lenguaje en el que no controlas cuando se libera la memoria. ¿Y si el GC tarda en entrar? La memoria se queda ocupada. Simplemente.

¿Lo qué?, tu comentario anterior se refería a los algoritmos y la eficiencia de un algoritmo no tiene nada que ver con el recolector o que lo implementes con tal o pascual lenguaje, con o sin recolector... Como si quieres "implementarlo" con un lapiz, papel y un ábaco. La eficiencia es la misma la midas respecto a lo que la midas. ¿De qué estamos hablando?, ¿de algoritmos? ¿de código?, ¿de qué?

De todas formas, por seguir un poco el tema, el recolector tiene sus cosas buenas y sus cosas malas: la parte positiva es, aparte de la comodidad que aporta, que suele ser más eficiente que un mal programador: si éste se dedica a crear unos cuantos miles de objetos pequeños en el heap (como cadenas de caracteres o nodos de un árbol n-binario o AVL, por ejemplo) y reserva memoria por cada uno, el recolector hará un trabajo mucho mejor que él "de serie".

Y buceando un poco en los detalles, es cierto que con GC se reserva más memoria en el heap pero el sistema operativo no asigna realmente todos esos marcos hasta que la aplicación los use, y el GC ya se dará prisa en liberar recursos si escasea la memoria, así que tampoco es tanto el despilfarro.

La parte más negativa es que al no saber cuando entra el recolector, estás pillado si tienes restricciones temporales (que poco o nada tiene que ver con la eficiencia). De todas formas, existen extensiones de Java para tiempo real. Nunca las he usado y no sé como manejan el problema del GC no determinista.

¿Seguridad? Pues si, el java es muy seguro porque si no te deja hacer nada donde puedas meter la pata no metes la pata. Por el camino te pierdes el control sobre TU programa.

Bueno, si quieres meter la pata con Java aún puedes. Java te evita algunos despistes, simplifica algunas cosas que hacen más fácil que varios programadores "se entiendan" (al no haber tantas posibilidades para hacer lo mismo, la codificación de varias personas resulta semejante) y refuerza algunos hábitos buenos de programación.

Además, supongo que desde C no se ve así pero en verdad Java no es demasiado rígido. Desde luego no llega al nivel de "cuadriculación" de otros lenguajes como Ada.

A mí Java me deja frío. En realidad no he programado mucho con él: he hecho mis pinitos con el J2ME, applets y algo de programación de escritorio con gráficos junto con JDBC. Tampoco es el lenguaje que escogería para hacer programación de sistemas ni para expresar mi "vena artística" X-) pero me parece un lenguaje muy válido para "hacer programas" (que no tiene porque ser igual que "programar" :-)) y hay buenas y baratas herramientas por ahí fuera para trabajar con él. Es más adorable que otros que conozco, sin duda.

Pero los que saben lo que es un puntero se dan cuenta de que lo correcto es...

... Primero saber que quieren hacer, segundo tener claros los conceptos de qué es una referencia y que es un objeto segundo y tercero leerse la documentación del contenedor. Eso sería lo correcto, supongo :-).

Si los punteros existen y estan ahi agazapados dandote por culo, al menos que te cuenten lo que son. Y si estan ahi, ya seria un gesto que te permitan aprovecharte de ellos si quieres...

Tanto como que existen... Un puntero de C o Pascal no es más que un entero con un montón de azucar sintáctico por encima. Donde realmente hay algo que entender no es ahí, sino en el código ensamblador que genera el compilador y en cómo funciona la máquina que hay por debajo (sea real o virtual). En cualquier lenguaje que tenga instrucciones para leer/escribir en direcciones (aunque éstas se llaman PEEK y POKE X-) puedes hacer lo mismo, aunque no haya nada explicitamente llamado puntero.

Y en cuanto a lo de pasar metodos a las funciones, yo ni entro ni salgo en si tiene sentido pasar funciones como parametros.

Funciones como parámetros sí, tiene mucho sentido y es de lo más habitual. En la biblioteca estandar de C tienes ejemplos y la parte de algoritmos de la biblioteca estandar de C++ le saca mucho partido. El tema está en que los métodos pertenecen a un objeto y en teoría no tiene sentido hablar de pasar un método solo sin pasar el objeto al que pertenece. Una clase functor es lo más apropiado en un lenguaje OO.

[ Padre ]


Aprendiendo a programar | 37 comentarios (37 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:
Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda