Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Aprendiendo a programar

gonzotba's Diary
Por gonzotba
departamento Esta es la buena , Sección Diarios
Puesto a las Tue Jul 20th, 2004 at 02:32:47 PM CET
Cada dos por tres siento el impulso de aprender a programar. Cuando los veranos eran largos yo hacía mis pinitos en Basic, pero de aquello ya ha llovido. En la universidad hice algunas prácticas con C, pero también ha llovido otro tanto y aquello ni siquiera me acabó de gustar.

Parece que lo de aprender a programar algo útil es algo recursivo en mi vida, y a pesar de que me digo que ya tengo bastantes aficiones y que maldita la falta que me hace una más, no hay manera de quitarse la mosca de detrás de la oreja.

 


Así pues, lo que a mí me gustaría es, hemos quedado, aprender a programar. Digo aprender porque poco sé de esctructura seria de programación y hace mucho tiempo que no hago un programa que haga algo, quitando algún scriptillo de bash.

Como soy cauto y me gusta ir poco a poco, lo perfecto sería coger un lenguaje de programación sencillo y resultón y luego, si veo que me vicio y quiero más, ya meterme con otras cosas. Pero sobre todo despacio. No quiero empachos.

Lo que yo busco en un lenguaje de programación es:

  • Que sea grato: Es decir, que con las menos líneas posibles los resultados sean ya aparentes.
  • Que luzca: No tiene necesariamente que ver con el punto anterior, pero puede. Es decir, que pueda hacer algo que abra ventanas de KDE y que quede resultón. Y todo con el menor número de líneas posible.

Ya sé que estoy pidiendo peras al olmo, pero oiga, para eso estamos ;)

Llevo un par de intentos con python. Python me parece limpio, sencillo (a mi limitado alcance), y por lo visto es bastante potente a pesar de que yo nunca haya llegado a hacer nada serio con él. Sé que tiene cosas para trabajar con QT y, en resumidas cuentas, me parece un lenguaje (si es que se le puede llamar así) bastante potente y resultón para mí.

Hace poco le eché un ojo a Gambas con motivo de un anuncio en Barrapunto, y la verdad es que me parece que tiene buena pinta. Todo parece bastante visual, luce mucho y el lenguaje es "similar" al Basic de mis tiempos. Sin embargo la documentación está algo más limitada que en el caso de Python y el entorno está algo verde, aunque yo también lo estoy.

Ya sé que todos los que andáis por aquí sois frikis del código y os será difícil poneros en mi lugar (conocimientos nulos y requerimientos altos) pero, ¿cuál sería vuestro consejo para un polluelo como yo? ¿Qué debería utilizar alguien que sólo quiere aficionarse a esto y que no pretende programar drivers para meter en el kelmer?

< Un vistazo a PHP5 (I) (8 comments) | Lenguajes de Desarrollo Libre y Puestos de Trabajo (14 comments) >
Enlaces Relacionados
· Gambas
· More on gonzotba's Diary
· Also by gonzotba

Encuesta
Lo que tú necesitas es...
· Un par de hostias a ver si se te pasa la tontería... 33%
· Python 34%
· Gambas 14%
· Visual Basic, para que te enteres... 7%
· Lazarus 0%
· Perl 9%

Votos: 63
Resultados | Otras Encuestas

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
Aprendiendo a programar | 37 comentarios (37 temáticos, editoriales, 0 ocultos)
Sobre Gambas (4.50 / 2) (#15)
por jorginius ("jorginius" en Google Mail) a las Fri Jul 23rd, 2004 at 02:27:52 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Hace poco le eché un ojo a Gambas con motivo de un anuncio en Barrapunto, y la verdad es que me parece que tiene buena pinta.

Pues yo sólo conocía Gambas de oídas pero lo he instalado esta tarde, después de leer esta entrada en el diario, he trasteado un poco con él y es muy majete.

El lenguaje, a pesar de ser muy sencillote, incluye su declaració de eventos, su tipado estático, sus excepciones para manejar los errores, orientación a objetos "leve" (ojo con la herencia, que el comportamiento de los constructores es un tanto extraño) y un montón de azucar sintáctico en general.

El IDE cumple bastante bien: tienes un editor con realzado de sintaxis, corrector de estilo y despliegue de listas de métodos y propiedades a los IntelliSense, un depurador, una herramienta para la traducción de nuestro aplicación (todo en Gambas es UTF-8 internamente), un generador de formularios muy resultón que mantiene separado los forms del código y que incluye en el editor la declaración de los eventos de cada control con un solo click.

El despliegue de las aplicaciones de Gambas es bastante cómodo. El runtime es pequeño (no pasa de 300 KB) y el "compilador" genera binarios autocontenidos, uniendo código "objeto" y todos los recursos que necesite la aplicación (imágenes, archivos de texto, iconos, traducciones, etc) en un sólo archivo. Por si fuera poco, desde el propio IDE hay un asistente para crear directamente los paquetes RPM y DEB de nuestro proyecto, para cuatro distribuciones de Linux.

El API de los componentes "básicos" (gb, gb.qt*) más simple que el mecanismo de un chupete y el aspecto es bastante bueno: Qt pero podemos también usar los diálogos y algunos controles de KDE (como una vista HTML vía KHTML). Como curiosidad, lo único que queda raro son los menús que no usa los controles de Qt sino que Gambas los dibuja por su cuenta.

Fuera de esos componentes, las API andan un poco verdes:

La parte de conexión a base de datos patina porque hay que escribir las querys a mano, lo cual no es precisamente sencillo y no pega con la simplicidad del lenguaje. Tampoco se pueden leer bases de datos SQLITE dentro de los binarios autocontenidos que genera Gambas.

Las expresiones regulares brillan por su ausencia. En realidad haberlas haylas pero o muy limitadas, en el propio lenguaje usando LIKE, o a través de una interfaz con libpcre bastante farragosa que tampoco pega con Gambas.

El tema de la red, a nivel de socket (INET y UNIX), tiene mejor pinta: con soporte genérico para servidores y clientes y protocolos de aplicación como FTP, HTTP y TELNET pero no incluye nada específico para CGI (aunque se pueden hacer aplicaciones para consola), ni nada de SOAP. Una carencia gorda es que no hay un componente para trabajar con XML.

Falta también el soporte multihilo y la multiprogramación en general está algo limitada. Hay una clase para servir peticiones de red de forma concurrente, instrucciones para leer un ejecutable del disco, crear el proceso y leer/escribir en él, pero no parece que haya nada como un fork(). En fin, para que no se bloqueen nuestras aplicaciones habrá que echar mano de un Timer.

Sobre la documentación, no es pésima o al menos no lo es el según el estandar del software libre. La tienes siempre en línea en el IDE y en la web del proyecto se va completando en el Wiki. Hay funciones sin documentar, ejemplos que no funcionan porque han ido cambiado cosas del lenguaje y algunas mentiras desperdigadas como que MoveNext devuelve TRUE cuando no hay más campos en el resultado de la query, pero en líneas generales no está tan mal.

La conclusión es que Python y cía seguramente le dan mil vueltas por sus impresionantes bibliotecas de clases de todo tipo, por las propias funcionalidades de cada lenguaje y por la documentación, pero Python y cía no tienen un IDE tan chulo como éste, ni un depurador que funcione también en las aplicaciones en modo gráfico que usen wxPython, PyGtk o PyQt (Boa Constructor debería ser la caña pero la última vez que lo probé se moría cada dos por tres y el depurador no chutaba dentro de las callback), ni tipado estático. Por otra parte, a pesar de todas sus carencias Gambas da bastante de si: el gambas-ide está escrito a su vez en Gambas y el gambas-database-manager también y ambas aplicaciones son razonablemente complicadas y bastante resultonas. Es muy prometedor.



 
La 'P' de LAMP (4.00 / 1) (#9)
por suy (suy21.existe-en.lycos.es) a las Thu Jul 22nd, 2004 at 01:24:17 AM CET
(Información Usuario) http://lacurva.net/

Si quieres hacer algo resultón, en lo que estarás bien apoyado por la comunidad, creo que cualquiera de Python, Perl o PHP son buenas opciones. PHP igual es demasiado orientado a la web (aunque se pueden hacer GUIs), pero es muy, pero que muy fácil de usar.

Si sabes hacer algo en bash, y alguna vez has tocado algo de awk, Perl creo que es un paso bastante natural. Si quieres hacer cosas resultonas, perl puede hacer algunas. Así se hace el grep:
$exp = shift;
while (<>) {
    print if (/$exp/);
}


Que conste que lo he copiado de un mensaje; no sé Perl, aunque me he leído algo, lo suficiente como para entender algo de código, y entretenerme un rato.

De Perl también sé que es una barbaridad la cantidad de módulos que hay para Perl. Carlos Escribano me comentó que había tanto código en el CPAN, que no entraba en un CD.

De Python he hecho menos aún que Perl, sólo me leí un libro (no recuerdo si es el que han citado antes), que trata de introducción a la programación, en un curso de primero, y que enseña tanto C como Python. El enfoque parecía interesante, y si te interesa hacer GUIs, PyQt parece popular. (Aunque como siempre, todo es relativo; si sólo quieres hacer GUIs, yo miraría directamente kjsembed, en que escribes en javascript, más fácil imposible.)


Esto será mi vida, porque es lo único importante en ella.
Y, si fracaso, moriré, porque para mí no existe nada más.

Raistlin Majere


 
Ruby (none / 0) (#1)
por davinci (davinci at ecol org) a las Tue Jul 20th, 2004 at 03:17:20 PM CET
(Información Usuario)

Por no hacer míos las palabras ni el concepto, citaré las frases introductorias del libro Programming Ruby, que resumen a la perfección un hecho que comparto plenamente:

This book is a tutorial and reference for the Ruby programming language. Use Ruby, ad you'll write better code, be more productive, and enjoy programming more.

These are bold claims, but we think that after reading this book you'll agree with them. And we have the experience to back up this belief.

El libro está al completo en el enlace apuntado. No estaría de más que le echases un vistazo antes de tomar tu decisión definitiva.


¡Es la guerrrrrrra!


 
Kommander (none / 0) (#2)
por melenas a las Tue Jul 20th, 2004 at 09:05:39 PM CET
(Información Usuario)

Usa Kommander y aprende a hacer programas gráficos con shell scripts :-)


FDO. ER_MELENAS No te preguntes sólo que puede hacer el S.L. por ti sino también que puedes hacer tú por él.


 
Difícil elección (none / 0) (#3)
por atopos a las Tue Jul 20th, 2004 at 11:17:36 PM CET
(Información Usuario) http://los-pajaros-de-hogano.blogspot.com

Desde mi limitida, pero que muy limitada experiencia, todo depende de cuál sea tu objetivo en eso de "aprender a programar".

Si se trata de conocer los entresijos de la programación, quizá lo mejor sea Ensamblador o C. Respecto de este último, siempre hay que recordar su relación con Unix (estamos pues en casa), así como el hecho de que quizá uno de los mejores libros sobre programación jamás escritos sea el superclásico The C Programming Language (lo cito en inglés, porque la traducción castellana no me gusta nada).

Si se trata de adentrarse en el mundo de la programación de un modo menos "duro", creo que Python puede ser una buena elección. Como dices, hay documentación, y también hay proyectos de formación básica interesantes como:

Ahora mismo yo estoy aprendiendo Python ---curiosa coincidencia---, y la prueba de que lo básico de Python es sencillo es que después de dos o tres días leyendo el Tutorial de Guido van Rossum, ya he empezado a hacer un pequeño programa para una amiga (y tratándose de mí ---que soy un lerdo para estas cosas---, tiene que ser muy fácil).

Si se trata de escribir con las menos líneas posibles, uno de los reyes es Perl, pero a costa de que puede llegar a ser muy, pero que muy "ofuscado".

Otros planteamientos de aprendizaje clásicos prefieren elegir lenguajes funcionales como Scheme (una variante de Lisp). Por ejemplo, un texto muy utilizado para el aprendizaje de la programación es Structure and Interpretation of Computer Programs

En fin, que hay donde elegir para todos los gustos.

Desde aquí te animo a que continúes. Y te lo digo yo que soy un principiante continuo en todos los lenguajes que acabo de citar. Justo el hecho de que tus aficiones sean tantas y tan dispares, puede ser una buena razón para que surjan programas también excepcionales. Que tal, por ejemplo, un programa de inteligencia artificial con Bilo y Nano como protagonistas ;-)

Esperemos a ver qué opinan los que saben :)



 
Jejeje... (none / 0) (#4)
por advocatux a las Tue Jul 20th, 2004 at 11:26:29 PM CET
(Información Usuario)

GonzoTBA, no tengo ni idea de si serás bueno programando pero si me atrevo a vaticinar que los comentarios en el código serán para descoj^H^Htroncharse :)
--
- Por una Europa libre de Patentes de Software - EuropeSwPatentFree


 
Python (none / 0) (#5)
por porras a las Wed Jul 21st, 2004 at 11:28:42 AM CET
(Información Usuario) http://www.lacoctelera.com/porras

En el Congreso Hispalinux de Móstoles (donde conocí a algunos de vosotros, si alguien se acuerda), asistí a una ponencia de unos profesores de primero de Informática (programación, claro) que presentaban un libro, en el cual habían cometido la osadía de sustituir C por Python. Aunque sólo lo he ojeado, me gustó bastante porque no se trata de un libro de Python donde se enseñen los intríngulis de Python, sino un libro sobre los conceptos básicos de la programación, con los ejemplos en Python, con la legibilidad que ello significa. Recuerdo que pensé quién lo hubiera pillado hace unos añitos, antes de ponerme a tirar estupi-código, empezando la casa por el tejado. El libro en cuestión está aquí.

--
Con las cosas que no sé, se podrían escribir 10.000 Enciclopedias Británicas.


 
Perl, por dar color (none / 0) (#6)
por pbenavent a las Wed Jul 21st, 2004 at 11:46:21 AM CET
(Información Usuario) http://www.benavent.org

Parece que tus intenciones están más decantadas y Python es una opción tal y como la planteas.

Aunque solo sea por darle vida al asunto: Perl. Y ahí van mis razones:
  • lenguaje con abundantisima documentación [Perldoc]
  • es maduro, lo que significa que tienes resuelto desde hace tiempo muchas cosas: acceso a BD's, CGI's, acceso a funciones POSIX, [CPAN] entorno gráfico TK [por ejemplo esta introduccion a TK]
  • realmente portable, puedes hacer un script para extraer informacione de Apache (algo muy típico para Perl) y se ejecutará en Linux, Solaris, Hasefroch 2003 Server...
Es falso -a pesar de tu buenísima tira- que Perl sea oscuro. Oscuro es el desarrollador que sabe mucho Perl, escribe rápido para resolver un problema sin documentar, sin comentarios y luego ni él mismo sabe que leches a hecho. (para escribir bien man perlstyle)

ATENCIÓN, si Orcero lee esto acude en auxilio de un recién llegado a perl! 8-)

Saludos


--
"El hombre es la medida de todas las cosas"
Protágoras


 
Ommmm... (none / 0) (#7)
por d Orb a las Wed Jul 21st, 2004 at 03:45:29 PM CET
(Información Usuario) http://skint.shef.ac.uk/

Yo creo que lo de programar es algo que puede ser util para muchos que nos ganamos la vida programando (en Fortran95, tambien para dar sabor :D). Cuando yo empece la carrera, teniamos una asignatura de Modula2 (en otros sitios era Pascal), en la que te ensenhaban los fundamentos de programacion. Yo habia hecho BASIC y algun pinito en C que deje por imposible. Todo dios se quejaba de que el Modula2 no lo pedian en ningun lado, que habia que aprender C++ y tal. Y el profesor solto que lo importante era entender la metodologia, no el lenguaje. Creo que tenia razon. He tenido que programar en varios lenguajes, y siempre he podido mas o menos salir adelante sin demasiado esfuerzo (excepcion hecha de IDL!).

Volviendo a la pregunta, Python es una buena opcion. Primero, porque bastante gente cree que es un buen lenguaje de programacion para introducir a la gente al tema (alguien ha dado toda una serie de enlaces antes). Otra ventaja es que gran cantidad de librerias y demas que estan adaptadas para trabajar con ellas de Python. Y realmente, se hacen cosas rapidamente (mira este tutorial, p. ej. :D).

Lo dicho en el parrafo anterior es casi todo aplicable a perl, aunque a mi me sigue gustando mas python. Principalmente por scipy y por f2py.
Skint resources <http://skint.shef.ac.uk>


 
Java no (none / 0) (#8)
por man ls a las Thu Jul 22nd, 2004 at 01:08:27 AM CET
(Información Usuario)

Es curioso lo de las modas en programación, hace unos años mucha gente te habría recomendado aprender Java. Ahora la gente se ha dado cuenta de la terrible realidad: aunque sea una especie de C++ simplificado, Java sigue siendo complicado.

Tras cuatro años ganándome la vida en eso, yo ya estoy harto de programar en Java. Así que voy a aprender Lisp, ¡hale! Y por dar la nota, te lo recomiendo también.

De regalo, un enlace interesante sobre los problemas de la ingeniería del software, en inglés. Confío en vuestro fino sentido del humor.



¿Lisp? (none / 0) (#10)
por thuban a las Thu Jul 22nd, 2004 at 09:08:34 AM CET
(Información Usuario)

Lo vas a flipar.

Vas a estar contando p**os parentesis hasta que al Real Madrid le den el Premio Nobel...

[ Padre ]


Poder expresivo (none / 0) (#25)
por man ls a las Fri Jul 23rd, 2004 at 07:08:57 PM CET
(Información Usuario)

Quiero explicar un poco por qué Lisp. Cuando uno programa en un lenguaje, acaba por pensar en ese lenguaje; resulta difícil salirse del marco que te fija, con lo que resuelves los problemas de una manera determinada. En esencia, el lenguaje acaba pensando por ti.

Pero a veces notas las limitaciones del lenguaje que estás usando. Por ejemplo, yo empecé con mi humilde Amstrad CPC a programar en Basic, y al poco tiempo ya te dabas cuenta de los problemas que trae el tener que numerar las líneas. Después empezabas a aburrirte de sus cortísimas variables (8 caracteres). El gfBasic del Atari ST resolvía estos problemas, pero para entonces ya hacía cosas más complicadas, y también se me quedó corto.

La programación orientada a objetos (primero en Perl, luego en C++ y finalmente en Java) fue una liberación. ¡Podías encapsular un montón de datos en un solo objeto! y pasarlo como parámetro para hacer otras cosas. Sin embargo, todavía noto ciertas faltas:
  • la absurda distinción entre métodos (o funciones en C++) y variables, que te lleva a crear métodos de acceso a tutiplén;
  • la incapacidad de ejecutar código que venga en una cadena, que sería tan útil para evaluar expresiones aritméticas;
  • no poder definir nuevos operadores, al menos en Java (en C++ por lo menos se pueden sobrecargar los operadores aritméticos, así que se puede usar '+' para sumar lo que quieras).
Algunas de estas restricciones las llevo sintiendo desde los tiempos de Basic. Me han prometido que Lisp es más flexible, y estoy dispuesto a escribir paréntesis hasta que las monas se afeiten con tal de poder superarlas.

[ Padre ]


Pop (none / 0) (#35)
por nya a las Sat Jul 24th, 2004 at 02:03:37 PM CET
(Información Usuario)

No sé si ya lo conocerás, pero hace tiempo DopeRider escribió un buen artículo sobre Poplog que quizás te interese.

[ Padre ]


Qué fuerste (none / 0) (#36)
por man ls a las Sat Jul 24th, 2004 at 10:29:47 PM CET
(Información Usuario)

Pues sí, coincide totalmente con lo que yo andaba buscando. Lástima que el soporte del lenguaje parece un poco pobre, pero sería interesante echarle un vistazo.

¡Gracias a ti y a DopeRider!

[ Padre ]


 
Paréntesis (none / 0) (#39)
por xan (xan en gnome punto org) a las Wed Jul 28th, 2004 at 03:43:33 PM CET
(Información Usuario)

La razón de que LISP tenga esa extraña y tediosa apariencia es en realidad increiblemente profunda e importante.

LISP nació como una entelequía matemática en los años 50 cuyo propósito podría definirse como la axiomatización de la programación. En concreto, la función "eval" de LISP actúa como un intérprete universal. Pero para su existencia sea posible necesitamos poder expresar el código LISP como datos, que serán pasados como argumentos a dicha función. De este modo, la sintaxis (¡mejor dicho ausencia de ella!) de LISP no es en realidad otra cosa que los árboles que se generan al parsear código, ¡que a su vez están hechos de listas!. Esto es importante: la representación de los datos y el código en LISP es idéntica.

Esto puede parecer confuso, pero al poder expresar código con la misma notación que los datos se obtienen cosas como las macros LISP, que son programas que generan nuevos programas. Explicar lo asombroso y potente que es esto es díficil si no se ha experimentado, pero en mi opinión es una de las características primordiales (si no la primodrial) que hacen a LISP el lenguaje más bello y poderoso que existe.

Si el tema te parece mínimamente atrayente te recomiendo que leas los ensayos sobre el tema en www.paulgraham.com o el libro Structure and Interpretation of Computer Programs, entre otros :)
--
Sirviendo al Comité Revolucionario Permanente de los Hombres Topo desde 2002.
[ Padre ]


 
Una lanza por Lisp (none / 0) (#12)
por jorginius ("jorginius" en Google Mail) a las Thu Jul 22nd, 2004 at 03:22:27 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Es el lenguaje más coherente que conozco y precisamente por eso es el más sencillo de aprender.

Es lexicológicamente mínimo, sólo hay tres o cuatro tokens y puedes definir fácilmente el léxico entero en menos de diez líneas formalmente. Esto conlleva que que el comportamiento sea absolutamente regular: "asignaciones", operaciones sobre funciones, llamadas a función, "operadores"... Todo se realiza de la misma manera y todo lo que "ves" tiene las mismas propiedades. En este sentido es un regalo del cielo si vienes de lenguajes como C o Perl. También el paradigma de programación funcional te permite abordar algunos problemas de forma distinta (y más cómoda).

Además hay compiladores eficientes, buenos entornos de desarrollo y extensiones de todo tipo, incluidas las peregrinas, como las que permiten programación orientada a objetos por ejemplo.

Es una buena idea dedicarle un poco de tiempo a aprenderlo, incluso si no se tiene pensado hacer nada serio con él, es un lenguaje que aporta una nueva perspectiva, sobre todo si nunca has salido de lenguajes como C y sus primos.

[ Padre ]


 
Java si (none / 0) (#14)
por dodger (dodgerNOSPAM@NOSPAMseastorm.org) a las Thu Jul 22nd, 2004 at 10:11:13 PM CET
(Información Usuario) http://www.seastorm.org

Pues por llevar la contraria, yo si recomendaría Java.

Muy potente, y los IDEs actuales te dan suficiente trabajo hecho como para que sea facil empezar.

--
dodger
http://www.seastorm.org
"Hacer software basado en requisitos es igual que caminar sobre el agua: Es fácil, si están congelados"
[ Padre ]


Jo qué troll soy (5.00 / 1) (#16)
por man ls a las Fri Jul 23rd, 2004 at 02:57:38 AM CET
(Información Usuario)

La verdad es que seguramente debería haber explicado un poco más mi postura, porque si no quedo demasiado de troll.

Los motivos por los que no recomiendo Java son:
  • Es lo bastante bajo nivel como para que te hagan falta un montón de librerías...
  • que por otro lado no son tan fáciles de encontrar, al final te las acabas currando tú. Yo por ejemplo he terminado por hacerme mi pool de conexiones a base de datos, mi librería de pruebas para servlets, mi librería de (!) parseado de xml...
  • No hay nada parecido al CPAN para Perl: un repositorio monstruoso de código contribuido por usuarios. Sólo existe Jakarta, que me han desengañado mucho a lo largo del tiempo.
  • Al mismo tiempo, es lo bastante alto nivel como para que no aprendas demasiado de tu plataforma. Esto a mí me parece bueno, pero siempre habrá a quien le fastidie.
  • La supuesta multi-plataformidad se queda en nada: Solaris, Linux y Windows. Vamos, que el ANSI C más perretero corre en mil veces más sitios.
  • Además, Sun planeaba que fuera ubicuo. Buena suerte encontrando un JDK > 1.1 en una máquina cliente encontrada al azar.
  • El monstruoso tamaño del JDK se corresponde con el afán megalómano de Sun. En la última entrega (1.4.X) incluyen ¡el parser de xml Xerces y la librería de xsl Xalan! como si uno no supiera cómo bajársela cuando le haga falta.
  • Las librerías gráficas incluídas (el infame Swing) tienen una pinta más fea que pegarle a un padre paralítico. La única librería gráfica útil que he visto, SWT (parte de Eclipse), no tiene el soporte de Sun.
  • Es más, parece que Sun ignora las cosas buenas que se hacen en Java (desde IBM). Y si no, pasen y vean lo que dice Gosling sobre Eclipse.
  • Pues que no es libre. Siempre puedes probar con gcj para compilarlo a código nativo con un compilador libre, pero mis experiencias no han sido del todo satisfactorias.
Me daría cosa recomendarlo en estas condiciones. Para eso, mejor aprender Lisp que por lo menos es multiplataforma de verdad, y más abstracto.

[ Padre ]


 
Tu veras lo que quieres hacer (none / 0) (#11)
por thuban a las Thu Jul 22nd, 2004 at 10:07:03 AM CET
(Información Usuario)

A mi me parece que con el bash vas (redundante) que chutas, porque te sirve para lo que necesitas, que es la gracia de programar.

Pero si quieres aprender a programar, lo que se dice programar, dejate de mariconadas, instalate un compilador de pascal (bueeeeeno, modula2 tambien puede servir) y compar un libro titulado "Programacion Metodica", olvidate de las Qt, las Gtk, los graficos y demas mariconadas con puntillas y aplicate a los punteros ("flechitas").

Con eso aprenderas a PROGRAMAR.

Despues, si quieres aprender programacion orientada a objetos, compra uno de Herbert Schildt de C++, que te enseñara C (el *autentico* lenguaje de programacion), C++ y programacion orientada a objetos.

Despues, tardaras una semana en defenderte en cualquier lenguaje, seras productivo en tres semanas y un guru en dos meses, porque sabras PROGRAMAR.

Pero sera un camino largo al final del cual *solo* sabras programar. Despues, para hacer cositas aparentes, tendras que aprender a usar las librerias graficas que mas te gusten (que en Linux son unas cuantas), las librerias de comunicaciones que prefieras (que en Linux son unas cuantas mas), las de... Pero sabras PROGRAMAR.

La alternativa es aprender Java (y solo Java), Python (y solo Python), PHP (y solo PHP), C (y solo C) o el lenguaje que mas te guste (y solo ese).

Pero aprenderas con las limitaciones del lenguaje que uses (unos no tienen punteros, en otros te despreocupas de lo que gastas porque un mago llamado GC se encarga de todo...) y te costara mas pasar de un lenguaje a otro. Y segun lo que elijas, podras seguir aprendiendo o no. Por ejemplo, si te decides por Java (que es muy bueno y me gusta mucho) olvidate del paso siguiente que es aprender algoritmos, porque la mayoria de los algoritmos de verdad usan punteros, que java no tiene.

Ya sabes, el reverso tenebroso de la fuerza es mas rapido, mas comodo, pero no mas poderoso.

¿Aun tienes ganas?



Un ejemplo o algo, por favor (none / 0) (#13)
por Draco a las Thu Jul 22nd, 2004 at 06:00:47 PM CET
(Información Usuario)

Por ejemplo, si te decides por Java (que es muy bueno y me gusta mucho) olvidate del paso siguiente que es aprender algoritmos, porque la mayoria de los algoritmos de verdad usan punteros, que java no tiene.

Obviando el resto de tu mensaje con el que no estoy demasiado de acuerdo (aunque siguiendo ese camino fue como aprendí a programar), me gustaría que justificases un poco esa afirmación y muestres qué le faltan a las referencias de Java para poder implementar "algoritmos de verdad", porque no veo demasiadas diferencias más allá de no poder hacer aritmética de punteros o referencias a métodos...
There are two major products to come out of Berkeley: LSD & BSD Unix. I don't believe this to be a coincidence.
[ Padre ]


Arboles, grafos... ¡¡MEMORIA!! (none / 0) (#17)
por thuban a las Fri Jul 23rd, 2004 at 09:56:08 AM CET
(Información Usuario)

Si, ya se que hay clases que lo tienen implementado, que puedes hacerlo usando referencias (aunque es muy forzado) y tal... pero si los objetos no se liberan cuando tu quieres que se liberen la eficiencia no existe, y si no hay eficiencia ¿para que marearse implementando un ArbolB?

PD: En java puedes pasar metodos como parametro aunque es una chapuza (hack, lo llaman algunos). Pasas el nombre de la clase y del metodo como Strings, los parametros como dios te de a entender (mejor si no tienes parametros) y entre la clase java.lang.Class y el paquete java.lang.reflect puedes ejecutar el metodo que pasas por parametro. Aunque es lento, desperdicia memoria y todas esas cosas que hacen que aunque se pueda hacer cualquier cosa en cualquier lenguaje de programacion (al fin y al cabo esto son ceros y unos), unos sean mejores que otros para segun que cosas.

Aqui (http://java.sun.com/docs/books/tutorial/reflect/index.html) tienes la pagina del turorial que lo trata. "Manipulating Objects" es la seccion que va al grano, aunque siempre esta bien leerlo todo.



[ Padre ]


Todo parece un clavo con un martillo en la mano (none / 0) (#18)
por jorginius ("jorginius" en Google Mail) a las Fri Jul 23rd, 2004 at 10:32:49 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Si, ya se que hay clases que lo tienen implementado, que puedes hacerlo usando referencias (aunque es muy forzado) pero si los objetos no se liberan cuando tu quieres que se liberen la eficiencia no existe, y si no hay eficiencia ¿para que marearse implementando un ArbolB?

Pues no, ni es más forzado, ni es menos eficiente y ni siquiera es más difícil implementar un árbol con referencias e iteradores (en C++, en Java, en Python o en lo que quieras), y lo más seguro es que el api sea mucho más limpio y seguro que la contrapartida en C con punteros y estructuras recursivas.

A lo de liberar los objetos y la eficiencia no le encuentro el sentido.

PD: En java puedes pasar metodos como parametro aunque es una chapuza

En Java, y en la POO en general, no tiene sentido hablar de "pasar un método" solo, sin más, a menos que éste sea estático. Lo que se le suele pasar a un algoritmo genérico en el mundo real es una referencia a un objeto functor con parámetros adicionales a los esperados encapsulados en el propio functor. Ese es el patrón estándar y, desde luego, no es ninguna chapuza.

[ Padre ]


Depende de lo que busques (none / 0) (#19)
por thuban a las Fri Jul 23rd, 2004 at 12:46:19 PM CET
(Información Usuario)

Si no le encuentras sentido a la eficiencia, pues enhorabuena. Vives en un mundo de recursos ilimitados. 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.

¿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. Pero eso si, es seguro. Ahora, ¿no es un poco triste que el diseñador del lenguaje reduzca tus posibilidades para que no puedas meter la pata? ¿No te jode que un tipo desde un despacho decida que eres un torpe? O que decida que si le pasas un entero a una funcion te vas a equivocar si le cambias el valor dentro y no te deje pasarlo por referencia (¿no te joden los p**tos IntHelper cuando programas con Corba?).

Yo prefiero un lenguaje que me deje hacer todo lo que pueda hacer el ordenador y encargarme yo de *programar* las devoluciones de memoria, las comprobaciones... No se trata de volver al ensamblador, pero tampoco de limitarse a lo que un teorico ha decidido que es un "paradigma de programacion".

En Java se pueden hacer muchas cosas y es un lenguaje cojonudo. Pero para aprender a programar algoritmos o para hacer cualquier cosa en la que la eficiencia sea importante, hay mejores opciones.

Y ni siquiera se puede decir que el Java libre de los errores debidos a los punteros salvajes. Si no eres cuidadoso la cagas igual. Como en Java todo es muy facil y no hay punteros, en pocos manuales se distingue entre la referencia y el valor apuntado por la referencia, por ejemplo, en los String. Es facil encontrase con codigo por ahi donde de pronto donde dijo "Digo" dice "Diego" porque desde dos sitios diferentes se tiene la misma referencia del mismo String (los dos punteros apuntan al mismo valor) y al cambiar los datos en uno se cambia en los dos.

Como nadie distingue entre puntero y valor, los que no tienen el concepto del puntero no ven problemas en este codigo:
import java.util.*;

class Prueba {
  public String nombre;
  
  Prueba( String nom) {
    nombre = nom;
  }
  
  public static void main( String args[]) {
    Vector vec = new Vector();
    
    Prueba p = new Prueba( "Digo");
    vec.add( p);

    p.nombre = "Diego";
    
    Prueba g = (Prueba)vec.elementAt( 0);
    System.out.println( g.nombre);
  }
}
(Para los que no lo ejecuten, el programa escribe "Diego" aunque muestra el valor recien sacado del vector, que se metio diciendo "Digo". Mucha gente piensa que el valor dentro del Vector esta a salvo de modificaciones y se dan cuenta cuando su vector con 32324 objetos tiene valores incorrectos)

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

p = new Prueba( "Diego"); //p.nombre = "Diego";

Alguien que empieza a programar no necesita lidiar estos problemas sin que nadie le explique porque ocurren, y no te imaginas la cantidad de veces que he tenido que explicar esto a gente que se habia tirado de los pelos delante del monitor sin comprender porque todos los objetos de su vector tenian el mismo valor.

Porque nadie espera que eso pase en Java porque es seguro.

Y la diferencia en la velocidad de comprension entre alguien que habia programado en C o Pascal y sabia lo que es un puntero y entre alguien que habia aprendido a programar en Java sin necesitar punteros se mide en cuartos de hora...

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

Y en cuanto a lo de pasar metodos a las funciones, yo ni entro ni salgo en si tiene sentido pasar funciones como parametros. De hecho, pocas veces he tenido que hacerlo. Yo solo digo que se puede y donde puede leer como se hace. Y es una chapuza porque es lento. Yo hablo de ejecutar un metodo donde sea y tu hablas de pasarle una funcion a un algoritmo generico, que si las clases estan diseñadas como es debido no tiene sentido porque, como bien dices, se pasa dentro del objeto y no es una chapuza porque forma parte de la gracia de la POO. Hablamos de cosas diferentes.

[ Padre ]


Nunca sé qué poner aquí (none / 0) (#21)
por Draco a las Fri Jul 23rd, 2004 at 02:04:30 PM CET
(Información Usuario)

¿Y si el GC tarda en entrar? La memoria se queda ocupada. Simplemente.

Si el GC tarda en entrar, es probablemente porque no hay suficientes objetos para recolectar y memoria más que suficiente, por lo que estamos haciendo un mejor aprovechamiento de la CPU gracias a un buen uso de la memoria. Probablemente también, cuando se dé dicha recolección, se liberarán zonas contiguas del heap, reduciendo la fragmentación... hay muchos factores y es difícil determinar cuando es mejor recolección automática o manual.

Es facil encontrase con codigo por ahi donde de pronto donde dijo "Digo" dice "Diego" porque desde dos sitios diferentes se tiene la misma referencia del mismo String (los dos punteros apuntan al mismo valor) y al cambiar los datos en uno se cambia en los dos.

Pués precisamente las Strings en Java son inmutables por lo que justo ése caso no va a pasar nunca.

Respecto al ejemplo, no sé qué querías demostrar ¿que la referencias Java son parecidas a los punteros? ¿quién lo ha negado? Más bien hemos sostenido lo contrario...
There are two major products to come out of Berkeley: LSD & BSD Unix. I don't believe this to be a coincidence.
[ Padre ]


Yo tampoco (none / 0) (#27)
por thuban a las Fri Jul 23rd, 2004 at 08:02:15 PM CET
(Información Usuario)

El mejor momento para liberar la memoria ocupada por algo que no se va usar mas es... el momento en el que se sabe que no se va a usar mas. Cuanto antes mejor.

Y si quieres esperar, si eres tu el que libera, puedes retrasar ese momento. Porque quieres y porque tienes esa opcion. Si no tienes la opcion, te aguantas con lo que te dan.

En el ejemplo lo que queria demostrar es que Java no es tan seguro como se dice por ahi (decir "seguro" cuando se habla de lenguajes es decir "tipado". Por eso Ada es "muy seguro") y que la misma problematica de los punteros salvajes que tienes en C, que lo hacen inseguro e inadecuado para aprender, la tienes en Java, pero sin que nadie te avise... Y ademas no te puedes beneficiar de lo que te dan los punteros.

En el ejemplo, pasa. No se si me he expresado bien, pero en el ejemplo, pasa.

De hecho, la parte de las referencias Java no las tiene bien resueltas. Si pasas un int a una funcion y cambias el valor dentro, al salir vuelves a tener el valor original porque se pasa por valor. Si ese entero esta dentro de otro objeto, el valor ha cambiado porque se ha pasado por valor la referencia del objeto, no el objeto en si. Si piensas en terminos de punteros es perfectamente logico, pero como en Java no hay punteros, alguien que aprenda con Java no puede pensar en terminos de punteros y se lia con ello.

[ Padre ]


Yo me lo invento: punteros trampa (none / 0) (#28)
por man ls a las Fri Jul 23rd, 2004 at 08:45:56 PM CET
(Información Usuario)

la misma problematica de los punteros salvajes que tienes en C, que lo hacen inseguro e inadecuado para aprender, la tienes en Java, pero sin que nadie te avise...
Pero, pero eso es hacer trampa. El pobre GonzoTBA, si no sabe programar, pensará: "oh, entonces es mejor usar punteros". ¡Ni de coña! Lo mismo que tú explicas con punteros, se puede explicar con objetos:
En el ejemplo, pasa. No se si me he expresado bien, pero en el ejemplo, pasa.
Sí, claro que pasa: que estás reusando un objeto donde no debes. Y para muestra un botón:

  // creo un botón de Swing
  JButton boton = new JButton("perico");
  // lo meto en un vector o conjunto de objetos
  Vector vector = new Vector();
  vector.add(boton);
  // ahora cambio el texto del botón
  boton.setText("juanico");
  // adivina el texto del botón en el vector?
  JButton enVector = (JButton)vector.get(0);
  System.out.println(enVector.getText());
> "juanico"
  // pues claro! porque es el mismo botón  
El objeto de dentro del vector lo sigues usando fuera; si lo modificas, en el vector seguirás teniendo el objeto pero modificado. No dudo que mucha gente no lo comprenda: es que la programación orientada a objetos cuesta un poco pillarla.

Y más:
Si pasas un int a una funcion y cambias el valor dentro, al salir vuelves a tener el valor original porque se pasa por valor. Si ese entero esta dentro de otro objeto, el valor ha cambiado porque se ha pasado por valor la referencia del objeto, no el objeto en si.
De nuevo, no hace falta saber ni lo que es pasar por valor, ni por referencia ni nada. Sólo tienes que saber que: los objetos se tratan como objetos, y los tipos primitivos (int, long y tal) no son objetos. Así que no se modifican.

No sé, a mí me parece perfectamente lógico. Hay gente que aboga por eliminar los tipos primitivos y tratar a todos los objetos por igual, y creo que es buena idea (aunque al principio se pierda rendimiento; ya se optimizará). Mientras tanto, se tratan de distinta manera.

Mira que Java tiene sus cosas, y me he hinchado a criticarlas un poco más arriba; pero a mí esta discusión me parece un poco bizantina.

[ Padre ]


Pero si estamos casi online... (none / 0) (#31)
por thuban a las Fri Jul 23rd, 2004 at 09:27:48 PM CET
(Información Usuario)

Pues si es una discusion bizantina, si...

Para mi tambien tienen logica esos errores, pero he mirado libros de Java y en niguno (o casi ninguno, que siempre hay un contra-ejemplo) me han prevenido contra esos errores. En todos me han contado que Java es muy listo y se encarga el de las referencia, de la asignacion de memoria, que ya nos olvidamos de problemas con los punteros salvajes que tiene el C++... Cuando no es verdad. Y lo peor es que ni siquiera se ponian a explicar ese caso de error, igual que no explican lo de los parametros por valor y porque unas veces las cosas cambian y otras no cuando se pasan a una funcion. Con prueba y error se deduce que cuando lo que cambias esta dentro de un objeto se cambia y cuando va por su cuenta y riesgo no. Pero hay que probar, y darse cuenta, porque no se explica para no entrar en contar lo que es un puntero. Y cuando lo entiendes, se explica "como lo de dentro si y lo de fuera no" porque como no sabes lo que es un puntero no lo sabes explicar mejor.

Y tambien pasa con objetos porque en realidad en Java TODOS los objetos son punteros a objetos. No hay objetos estaticos como puedes declarar en C++ o en Pascal ¿con objetos?. Tooooodos se crean con new y se pueden desasignar igualandolos a null. Talmente como si fueran punteros a objeto.


Gonzotba. No estas obligado a usar punteros. De hecho, los punteros dan dolores de cabeza. Pero estan ahi de una forma u otra aunque te los intenten esconder, asi que cuanto mejor comprendas como funcionan, mejor te ira.

[ Padre ]


Me despisté unas horillas (none / 0) (#34)
por man ls a las Sat Jul 24th, 2004 at 02:35:39 AM CET
(Información Usuario)

Pues aclarado. Que conste que yo veo más interesante aprender cómo hacer las cosas con objetos que cómo funcionan los punteros, pero son dos puntos de vista complementarios.

[ Padre ]


 
más sobre basura (none / 0) (#37)
por Draco a las Sun Jul 25th, 2004 at 09:01:09 PM CET
(Información Usuario)

Y si quieres esperar, si eres tu el que libera, puedes retrasar ese momento. Porque quieres y porque tienes esa opcion. Si no tienes la opcion, te aguantas con lo que te dan.

Es muy normal que la decisión de liberar y cuándo sea mejor tomarla en ejecución, y éso pasa por recolectores de basura o "memory pools" lo que implica "desperdiciar memoria" en forma de pedir más de la que necesitas o retrasar su liberación. Si en Java, Lisp o Python tienes un recolector(o varios) de basura, bienvenido sea.

los punteros salvajes que tienes en C, que lo hacen inseguro e inadecuado para aprender, la tienes en Java, pero sin que nadie te avise... Y ademas no te puedes beneficiar de lo que te dan los punteros.

Yo diría que es al revés. Casi todo lo bueno de los punteros y muchos menos riesgos. De todas formas, hay que saber cómo funcionan las referencias, está claro
There are two major products to come out of Berkeley: LSD & BSD Unix. I don't believe this to be a coincidence.
[ Padre ]


 
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 ]


El GC y el tiempo real (y 2. El bueno) (none / 0) (#24)
por ridiculum a las Fri Jul 23rd, 2004 at 06:16:13 PM CET
(Información Usuario)

El otro comentario no tiene un forma decente, este se lee mejor.

Se supone que los sistemas de tiempo real esta terminantemente prohibido el empleo de recolectores de basura por el indeterminismo que introducen, asi que la solucion que ofrence la RTSJ (Real Time Specification for Java) es algo similar al mlock que hay en POSIX.
Haciendo un cut && paste:

The main issue with Java derives from its foundation in object-oriented programming. The problem isn't so much with efficiency--the overhead of dynamic binding needn't be more than an extra level of indirection on the method call--but rather with the apparent unpredictability or latency incurred by garbage collection. The approach taken in the RTSJ is to allow the program to define memory areas that aren't subject to garbage collection and to define certain kinds of threads that aren't allowed to access the garbage-collected heap; such threads may preempt the garbage collector

Respecto a Ada, mejor no comentar nada, que me saldrian demasiados exabruptos :P

[ Padre ]


 
Re: La eficiencia (none / 0) (#30)
por thuban a las Fri Jul 23rd, 2004 at 09:09:26 PM CET
(Información Usuario)

Pues si tiene relacion. Es absurdo enredarse con los algoritmos si toda la memoria que puedas ahorrar machacandote para reducir las colisiones de una funcion hash y asi poder tener una zona de colisiones mas pequeña en el array, se van a perder porque por otro lado te dejas sin liberar la memoria de un auxString que creas en el interior del bucle que rellena la tabla. No merece la pena el esfuerzo. (Y si quieres una Hashtable con tratamiento decente de colisiones te la tienes que hacer tu)

Y el problema es que estas pensando en un mal programador. Como el programador es malo hacemos el trabajo por el. No le dejamos liberar memoria, ni le damos punteros... ¿No seria mejor convertir al mal programador en buen programador? Hacerle responsable de su codigo y explicarle que tiene que soltar lo que coje. Especialmente cuando aprende, como quiere hacer Gonzotba.

Y en cuanto a la seguridad del Java... Pues si, es seguro porque se supone que un lenguaje tipado y sin punteros reduce errores de programadores poco cuidadosos (otra vez) y por tanto es seguro. Pero mal codigo es mal codigo. Y despistes se pueden tener igual como en el ejemplo que he puesto (visto en el mundo real, con mas lineas por medio). Si java no me proteje de los dolores de cabeza que dan los punteros salvajes ¿que gano con no tener punteros? Peos aun. Si tengo el problema de los punteros, ¿por que nadie me cuenta que tengo el problema de los punteros?

Yo programo con java desde la version 1.0 del lenguaje, y aunque me gusta, y mucho, no me parece que sea un lenguaje para aprender a programar ni para meterse a hacer con el ciertas cosas (como arbolesB). Para eso esta el C++ o un Modula2, un lenguaje que tenga de todo y que no aisle al que aprende de la problematica de la programacion. Si no se aprende al principio, ¿cuando?

Los punteros existen aunque en Java se llaman referencias. Y eso de que cualquier lenguaje con PEEK y POKE los tiene... Pues si. Supongo que tambien se puede hacer programacion orientada a objetos en ensamblador, pero que se busquen a otro que yo me tengo que lavar el pelo...

El java no es adecuado para aprender porque pierdes todo lo que puedas aprender de punteros, la sobrecarga de operadores, la utilidad de los destructores... Menos los operadores, lo demas se puede poner en java, de acuerdo, pero ¿sirve para algo el metodo finalize? ¿Es util un destructor que no sabes cuando se lanza? ¿Puedes confiar en el para liberar una conexion a una base de datos? Con o sin pool, el problema es el mismo.

Es mas facil aprender en C++ y olvidar cosas segun el lenguaje en el que aterrices que aprender en Java y tener que aprender sobre la marcha y con prisas lo que no sabias porque java no daba.


[ Padre ]


Sintetizando (none / 0) (#32)
por jorginius ("jorginius" en Google Mail) a las Sat Jul 24th, 2004 at 01:06:20 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

* Si tal y como la escribes la implementación de tu tabla hash en Java no cumple los requisitos cambia la implementación. A lo mejor es que no necesitas un objeto cadena sino un array de caracteres que sea mutable o algo así. El algoritmo puede ser bueno pero la realización no. De todas formas no se me ocurre porque tenía que no marchar en el ejemplo que pones. En el caso de que te quedes sin memoria por las cadenas auxiliares que vas creando, el recolector entrará en acción y en paz.

* No pienso en que es mejor para el mal programador, pienso en que el buen programador en ese escenario al final tendría que programar un esquema de asignación de memoria similar al que usa el GC en el lenguaje con recolector. Usar un Allocator adecuado, si usa contendores STL, que anticipe memoria para más objetos de los necesarios inicialmente y sobrecargar new para construir los objetos en esa zona. La GC no es malvada en según que casos.

* Una referencia de Java sólo sustituye parcialmente a un puntero porque no puede contener más que una dirección válida (o que lo haya sido) o nula, no nos deja modificarla aparte de asignarle otra del mismo tipo ni la expone explicitamente.

* Un lenguaje sin punteros pero con instrucciones tipo PEEK y POKE permiten lo mismo que los punteros de C y no son más puñeteras (lo digo por la comparación que me haces con la OO y ensamblador), salvo quizás porque el compilador de C hace magia y arregla la aritmética de punteros acorde con el tamaño de lo que apuntan (magia que da más problemas que otra cosa cuando por ejemplo intentas comunicar dos procesos en máquinas diferentes o portar tu código a otra máquina/compilador, pero esa es otra historia).

* En Java la única posibilidad de que una referencia apunte a un objeto que no es válido pasa porque el objeto haya pasado al limbo del recolector o le hayamos asignado explícitamente valor nulo. Un puntero de C puede apuntar a un objeto válido, a uno inválido o a cualquier sitio en cualquier momento. La mejora es evidente y la probabilidad de meter la pata por despiste en Java es menor.

* Java no tiene destructores así que no es que no sepas cuando se llaman, es que no se llaman nunca. Finalize es otra cosa distinta y si quieres liberar una conexión a una base de datos en un momento determinado, manda un mensaje entonces antes de que el objeto abandone el ámbito y pase a depender del recolector. Finalize no es para hacer esas cosas y nadie dijo que Java fuera como C++.

* Precisamente C++ es uno de los lenguajes más puñeteros de aprender, con más peculiaridades retorcidas, más formas de hacer las cosas y más puñetitas. Mucho más que C y eso ya es decir. Nunca oirás que "ya he aprendido a programar en C++" porque aprender C++ es un proceso que lleva toda una vida X-). Todo el mundo que conozco y que programa en C++ se restringe a un sub-sub-sub conjunto de lo que es el lenguaje, un subconjunto que suele coincidir bastante con Java por otra parte, sobre todo ahora que han incluido plantillas. Aprender Java primero (y orientación a objetos y una forma "sana" de organizar el código también) creo que es una buena idea para abordar C++ después.

* Para no seguir desbarrando: el padre de este hilo decía que los algoritmos sólo se podían implementar en C por los punteros. La respuesta es que que cualquier algoritmo lo puedes codificar en el lenguaje que quieras, con punteros o sin ellos. De forma más sencilla o más complicada pero los mismos algoritmos con el mismo rendimiento. Que luego corran más o menos dependerá de la máquina, del compilador o de lo listos que seamos, pero el algoritmo es el que es y no hay más que rascar.

Precisamente C es bastante malo para expresar según qué algoritmos: normalmente la expresión de un algoritmo en C suele ser bastante más complicada que la misma en otros lenguajes más "pegados" al dominio (por ejemplo comparar un algoritmo sobre un grafo en Lisp con el mismo algoritmo implementado en C).

* Esta conversación se ha ido de madre. Conmigo no cuentes para continuarla.

[ Padre ]


char[] o StringBuffer (none / 0) (#33)
por jorginius ("jorginius" en Google Mail) a las Sat Jul 24th, 2004 at 01:34:14 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Si tal y como la escribes la implementación de tu tabla hash en Java no cumple los requisitos cambia la implementación. A lo mejor es que no necesitas un objeto cadena sino un array de caracteres que sea mutable o algo así.

El "algo así" podría ser un StringBuffer. Y ya puestos... Me comí un ":-D" al final del mensaje anterior y sin eso parece como si estuviera rebotado. Vamos, que aunque se salga de madre yo seguiré contestando, me temo :-).

[ Padre ]


 
No tiene que ver (none / 0) (#20)
por Draco a las Fri Jul 23rd, 2004 at 01:20:09 PM CET
(Información Usuario)

La gestión automática de memoria no tiene por qué ser peor que la gestión manual y aunque así fuese difícilmente va a anular el efecto de usar un algoritmo superior.

No conocía la librería reflect, puede ser interesante para hacer ciertas cosas.... Lo que sí conocía era la solución "ortodoxa" de la que habla jorginius. Declaras un interface en los parámetros del método y en ejecución pasas un objeto que implemente dicho interface. Dicho sea de paso, esa solución me parece un coñazo por muy estrictamente OOP que sea. En Python puedes pasar referencias a funciones, métodos bound y unbound y es mucho más sencillo y cómodo.

Respecto al itinerario que tú propones, creo que consigue el efecto contrario al que se desea: aprender a programar.

Yo aprendí a programar en Ada en primero de carrera (algo hice con el BASIC del Spectrum pero me cansé pronto), y recuerdo que me daba de cabezazos con el compilador, que si me había dejado un with, que si no había instanciado las Bounded Strings(como si en aquel entonces supiera que coño significaba aquello)... al final me pasaba más rato intentando desentrañar en la documentación los errores del compilador(¡o esperando que acabara la compilación!) que resolviendo problemas, que es lo central de programar.

Cada vez tengo más dudas de que ése fuese un buen camino. Hay una gran cantidad de profesores universitarios que opinan que Scheme(una variante "suave" de Lisp) debería ser el primer lenguaje en enseñarse porque los principios básicos son muy sencillos. De hecho el famoso Wizard's Book es un libro de introducción a la programación antes que de Lisp/Scheme.

Yo creo que actualmente Python es una mejor elección, porque tiene bastante de lo bueno que se le atribuye a Scheme(sin los puñeteros paréntesis) y se parece más al resto de lenguajes de programación (por una vez, coincido con Bruce Eckel).

Claro que luego pasar a un lenguaje con tipado fuerte y estático puede ser un como un proceso bastante doloroso...
There are two major products to come out of Berkeley: LSD & BSD Unix. I don't believe this to be a coincidence.
[ Padre ]


¡¡ADA!! (none / 0) (#26)
por thuban a las Fri Jul 23rd, 2004 at 07:47:16 PM CET
(Información Usuario)

Es que empezaste con uno de los mas feos... Aun recuerdo la de tacos que soltaba cuando el compilador me decia que dos variables del mismo tipo pero declaradas en lineas diferentes no eran del mismo tipo... Y que decir de esa entrada/salida... Si yo hubiera empezado con Ada lo hubiera dejado. Cuando por ahi arriba alguien hablaba de "seguridad" estuve a punto de decir que para seguro, seguro, el Ada. Me alegro de no haberlo escrito.

En cuanto a lo de reflect, es que hablabamos de cosas diferentes.

El hablaba de pasarle una funcion a un algoritmo generico, por ejemplo, una funcion Hash adaptada a un objeto de una clase definida por ti. En ese caso, el metodo de interfaz, clase base, funcon hash que se machaca con tu definicion... es lo correcto y no es tan pesado como parece.

Yo hablaba de psarle una funcion a otra. Simplemente eso. Yo lo he usado para cargar plugins definidos en un fichero XML, que no tiene nada que ver con nada de lo que hemos hablado hasta ahora.

[ Padre ]


 
sugerencias de un (casi) ingeniero en informática (none / 0) (#38)
por fortran a las Tue Jul 27th, 2004 at 10:18:33 PM CET
(Información Usuario)

Buenas, Gonzo, he hecho el esfuerzo de registrarme y todo para darte algún consejillo, al menos sobre algunos de los lenguajes que conozco.
  • Java: es mi lenguaje "nativo" y como la cabra tira al monte, pues es lo que te recomendaría...
    • pros: gestión automática de memoria, impide hacer ciertas chapuzas, tipado estático fuerte (algunos dirán que no es un pro), fantásticos entornos de programación disponibles (eclipse y netbeans por poner 2 ejemplos), un API muy completa y muy bien documentada (árboles, listas, tablas hash, algoritmos de búsqueda, manejo de strings y expresiones regulares, acceso a bases de datos, etc.), solución universal: desde la web hasta sistemas empotrados...
    • contras: swing y awt dan un poquito de asco... pero se puede llegar a vivir con ellos. la eficiencia no creo que sea un problema, ya que las jvm's actuales son realmente rápidas.
  • C/C++: pues eso, que si no vas a programar el kelmer, no te los recomiendo... demasiados quebraderos de cabeza extra para un supuesto incremento del rendimiento que al final dependerá de tu habilidad como programador. por desgracia, las cosas chulas como el 3d (OpenGL, DirectX) están pensadas principalmente para usarse desde C y C++.
  • Python: es bastante cuco y resultón, he hecho algunas chapuzas con él y creo que su mayor ventaja es el manejo de estructuras dinámicas como listas de una forma muy flexible.
  • Lisp: es un lenguaje majete, pero lo veo innecesario para hacer guarrerías... si te sales de la programación funcional el código se hace bastante poco legible. eso sí, si quieres hacer algoritmos genéticos es la opción.
  • Fortran: juassssssss... aunque es mi nick, no lo recomiendo. no hay compiladores libres decentes y se trata de una reliquia un tanto forzada para los tiempos de hoy. la sintaxis es fea y la posible ganancia en eficiencia se basa en todas las optimizaciones estáticas que puede hacer el compilador.
  • Pascal: los buenos viejos tiempos... algunos dirán que es para que los niños aprendan, pero es un lenguaje bastante capaz y elegante. por otra parte, es demasiado parecido a C en cuanto a funcionalidad, aunque Lazarus es una baza interesante.
  • Prolog: pues aunque ya recuerdo poco de éste, si te gusta escribir pocas líneas de código es la opción. eso sí, hay que pensar antes de ponerse a escribirlas. ah, de las ventanitas olvídate, si las quieres, tendrás que mezclarlo con algo.
  • TCL/TK: para hacer bocetos rápidos de aplicaciones está bastante bien, pero la sintáxis era bastante rebuscada (parecido al bash, es otro intérprete de comandos).
  • ...
(Mi) conclusión: Aprende Python, que es lo más facilón, y para cuando se te quede corto, prueba con Java y Jython, así podrás usar un lenguaje de más peso y reutilizar todo el código que ya tuvieses... por otra parte, también hay versiones de Prolog (y de Ruby, de Lisp...) que funcionan sobre la Máquina Virtual de Java, así que piensa seriamente en Java como lenguaje de integración.



 
Aprendiendo a programar | 37 comentarios (37 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:

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