¿Eres un programador de SL indeciso?

Mira qué video he hecho para que tengas otra opción más cuando quieras realizar una aplicación libre con entorno gráfico o multiplataforma:

Esta entrada va dirigida a todos aquellos programadores que se preguntan a veces de qué forma realizar una aplicación para un sistema libre o multiplataforma. De tal manera que he hecho un video en el que se muestra el proceso de crear un pequeño “hola mundo” en un entorno gráfico como es GTK2, sobre python (lo que ofrece todas las ventajas que conocemos). Espero que os guste:




Imagen
Me ha gustado!! [oki]

No conocía Glade, y no pensaba que hacer una interfaz gráfica fuera tan 'fácil' o 'sistemático'.

Cuando pueda me pondré un poco con esto. [jaja]
No es por joder, pero esto no tiene que ver con desarrollar software libre o propietario, sino con desarrollar con python y gtk.

EDITO: Por otra parte, usar música en vez de comentar lo que se está haciendo, no sirve de mucho para el que no sabe.

Un saludo.
bastian escribió:No es por joder, pero esto no tiene que ver con desarrollar software libre o propietario, sino con desarrollar con python y gtk.

EDITO: Por otra parte, usar música en vez de comentar lo que se está haciendo, no sirve de mucho para el que no sabe.

Un saludo.
Es un video para "vender" una nueva forma de hacer las cosas que puede que la gente no conozca. He decidido que con música de fondo se queda más amigable y bonito.
Si alguien quiere una explicación más despacito pues puede preguntar, pero no era el objetivo del video.

Sobre lo primero que dices, tiene que ver que todo lo que se utiliza es enteramente libre, y principalmente es para desarrollar aplicaciones enteramente libres.
A mi ha conseguido perderme... ha habido varios momentos en los que he sido incapaz de seguir el ratón y entender lo que estabas haciendo. Además, creo que das demasiada vuelta para algo que son cosa de 20 líneas en C.

Se vería la ventaja de utilizar glade/python si hicieras algo más complicado...

- ferdy
Si, soy un toca huevos, pero... podias subirlo a youtube? o stage6, o algo similar?
Es que ODIO rapidshare, megaupload y demás :(
GRACIAS!!!
e-Minguez escribió:Si, soy un toca huevos, pero... podias subirlo a youtube? o stage6, o algo similar?
Es que ODIO rapidshare, megaupload y demás :(
GRACIAS!!!
te lo puedo pasar directamente si quieres verlo, es que en google video al menos que he probado se recomprime de tal forma que no se distingue las letras de la pantalla. Por eso era el tema de verlo "offline".
yo en la facultad use glade con eiffel... y lo que haciamos era hacer una interfaz simple, ver que comandos eran (porque eGTK no tenia mucha documentacion) y luego hacerlo nosotros a mano, porque glade metia mucha "morralla"

el video esta bien, pero como dicen, mejor si lo comentases, y si las cosas fuesen un poquito mas despacio...

a ver si aprendo python...
Es distinta la situación, aquí usa glade + libglade, y no glade + generador de código.

- ferdy
Precisamente estoy empezando una serie de artículos - tutoriales sobre Python. Puede que a alguno le interese:
¿Qué es Python
¿Por qué Python?

Y una noticia que a más de uno le gustará:
Python, lenguaje del año 2007 para TIOBE
zootropo escribió:Precisamente estoy empezando una serie de artículos - tutoriales sobre Python. Puede que a alguno le interese:
¿Qué es Python
¿Por qué Python?

Y una noticia que a más de uno le gustará:
Python, lenguaje del año 2007 para TIOBE


pues me da en la nariz que me voy a empezar a pasar mas a menudo por tu blog :P
Subo este hilo para dejar colgado un ejemplillo que he hecho de prueba, de libre disposición para todo el mundo.

Estas son las tecnologías que utiliza:

Imagen



El resultado es el siguiente:

Imagen


No incluye dentro archivos sobre la licencia. Pero lo especifico en este post: es de libre disposición [risita] .

Adjuntos

CyBeR PeReZ escribió:Subo este hilo para dejar colgado un ejemplillo que he hecho de prueba, de libre disposición para todo el mundo.

.


/PYTHON$ python practica.py
Traceback (most recent call last):
File "practica.py", line 43, in
import nltk
ImportError: No module named nltk



Por otro lado, alguien está tyeniendo problemas para pdoer hacer copy/paste con Firefox ??

Desde hace unos dias no puedo.......
phaeton escribió:Por otro lado, alguien está tyeniendo problemas para pdoer hacer copy/paste con Firefox ??

Desde hace unos dias no puedo.......


Con el editor avanzado nuevo falla el pegar textos que sean enlaces. ¿Qué otros problemas te refieres? O es en general por la navegación fuera de eol?

Sí, te falta el paquete de reconocimiento de lenguaje natural (NLTK): apteguea a python-nltk :-|

Edito: La verdad es que para probarlo hay que bajarse los diferentes módulos que he reutilizado ( por eso he preparado un video que enseño el código y el funcionamiento ). Pero vamos, que el código está clarito y puede ayudar a alguien que quiera hacer un programa interactivo con reconocimiento del lenguaje (que es algo más avanzado que simples comparaciones de cadenas).

Saludos.
CyBeR PeReZ escribió:
Con el editor avanzado nuevo falla el pegar textos que sean enlaces. ¿Qué otros problemas te refieres? O es en general por la navegación fuera de eol?


Solo es con EOL 8 Es la unica que visito asiduamente, y participo, en las demas solo leo)

El fallo me lo ha dado al inmtentar pegarte el texto de la terminal, no creo que llevara ningun enlace
phaeton escribió:El fallo me lo ha dado al inmtentar pegarte el texto de la terminal, no creo que llevara ningun enlace


Pero si le das con el botón derecho -> pegar es como falla, al menos a mi y con el editor avanzado. Con las teclas sí que me pega bien :? . Pregúntalo si no lo consigues en el hilo del editor que tiene churly en feedback (suerte).
Una pregunta, seguramente, tonta: ¿no es más sencillo hacerlo en Java con el Netbeans? Más rápido, más sencillo, multiplataforma...
Darkoo escribió:Una pregunta, seguramente, tonta: ¿no es más sencillo hacerlo en Java con el Netbeans? Más rápido, más sencillo, multiplataforma...

Python es multiplataforma. Varios de los frameworks de desarrollo de interfaces para Python también, como PyGTK.

Y Python es bastante más sencillo y rápido que Java.
Y Python es bastante más sencillo y rápido que Java.


No no... no comulgamos con ruedas de molino. Eso te lo has sacado de la manga. Demuéstralo.

- ferdy
Ferdy escribió:
No no... no comulgamos con ruedas de molino. Eso te lo has sacado de la manga. Demuéstralo.

- ferdy

Yo no me saco cosas de la manga.

Y paso de discutirlo contigo vistas las formas.

Usa Google si te apetece.
¿Qué formas? Te he dicho la verdad, aquí no se comulga con ruedas de molino, si pretendes decir algo así, tendrás que demostrarlo. Vamos... que no creo que haya dicho nada raro...

- ferdy
holamundo.java:
public class holamundo {

        public static void main(String[] args) {
                System.out.println("Hola Mundo");
        }

}

holamundo.py
#!/usr/bin/python
print "Hola mundo"


time java holamundo
Hola Mundo

real   0m0.183s
user   0m0.068s
sys   0m0.031s

time ./holamundo.py
Hola mundo

real   0m0.049s
user   0m0.010s
sys   0m0.009s


[/post de coña] [jaja]
No es tan de coña, es un claro ejemplo de que la JVM ha tardado más en cargar que el intérprete de Python. Aunque habría que ver qué partes de uno y de otro se han recuperado del disco, etc etc...

- ferdy
¿No te parecen malas formas insinuar que una persona, por no compartir tu opinión se inventa las cosas? Porque es a lo que suena un "eso te lo has sacado de la manga. Demúestralo".

Demuestra tú lo contrario, no te jode.

Por cierto, me refería a rapidez a la hora de programar, que es de lo que hablaba Darkoo si os fijáis en la conversación en la que estábamos antes de esa sobrada. No rapidez a nivel de ejecución, que es algo que, francamente, a mí no me importa ni me interesa.


De todas formas a alguien le puede interesar esto, ya que estamos en el tema: Make Python run as fast as C with Psyco using Psyco, the Python specializing compiler


Y por si hay algún cretino que pueda pensar que tengo algún tipo de animadversión por Java:

http://mundogeek.net/archivos/2007/01/27/hibernate/
http://mundogeek.net/archivos/2007/01/27/jdbc/
http://mundogeek.net/archivos/2007/01/26/servlets/
http://mundogeek.net/archivos/2007/01/25/jsp-javaserver-pages/
http://mundogeek.net/archivos/2006/04/04/apache-y-tomcat-en-windows/
http://mundogeek.net/archivos/2006/04/03/apache-y-tomcat-en-linux/
http://mundogeek.net/archivos/2006/03/20/sockets-en-java/
http://mundogeek.net/archivos/2004/10/04/una-no-tan-breve-historia-de-java/
¿No te parecen malas formas insinuar que una persona, por no compartir tu opinión se inventa las cosas? Porque es a lo que suena un "eso te lo has sacado de la manga. Demúestralo".


No, no me parecen malas formas. Más que nada porque no he insinuado que te lo inventaras. No se me ocurriría...

Y si, mientras lo 'fácil' o 'difícil' de un lenguaje es una cosa bastante opinable, la rapidez de desarrollo no lo es. La rapidez de desarrollo es la que deberías argumentar un poco.

Demuestra tú lo contrario, no te jode.


No, no me jode... pero es una buena práctica. Es una forma de no tratar al personal como idiotas que se creen cualquier cosa.

No es por nada... pero... ¿no te estás tomando esto demasiado mal? Mi intención ha sido que dieras datos de esa 'mayor rapidez de desarrollo', entre otras cosas, porque me interesa y porque estoy seguro de que los tienes y así me ahorro el trabajo de buscarlo.

- ferdy

-------------------

PD: Si realmente crees que he insinuado eso, te pido disculpas. No era mi intención.

- ferdy
Ok, lo siento mucho si te he malinterpretado. Es lo que tiene un foro, que te falta información como el tono de la persona.


Explicar todas las cosas buenas que tiene Python llevaría hojas, pero resumiendo mucho y explicando poco algunas cosillas son:
tipado dinámico

de tipo duck typing, por lo que cuando lo sacas de una colección no tienen que usar polimorfismo y supercastearlo a una clase genérica y luego tú hacer un casting de nuevo a lo que fuera.

atajos muy cómodos para trabajar con las colecciones, como el slicing. y sus colecciones son un gustazo. y los métodos de las cadenas.

todo son objetos de verdad. incluidas funciones, o los propios archivos de código python. lo que permite entre otras cosas programación funcional.

funciones lambda.

atajos increíblemente útiles para navegar por colecciones. Más compactos incluso que los iteradores de Java, y no digamos que hacer un bucle for de 0 a la longitud de la colección. Por ejemplo si tengo una lista mi_lista:
for elemento in mi_lista:
...print elemento

generadores

metaclases

decoradores

elses para los bucles y los try.

una sintaxis mucho más compacta. necesitas escribir mucho menos código para hacer lo mismo en ambos lenguajes. como el ejemplo típico del hola mundo en donde en java tienes que declarar la clase y el punto de entrada a la aplicación.


Baste decir por ejemplo que Bruce Eckel, que es el escritor del libro de introducción a Java que más me gusta (Thinking in Java) afirmaba hace un tiempo que con Python se podía multiplicar la productividad hasta ¿por 5?
A mi siempre me ha gustado python, aunque si es cierto que ahora toco más java por obligación.

Las cosas que dice Zootropo estan bien, aunque eso de:

for i in mi_lista:

se podria hacer en java con:

for (tipo variable : lista)

(foreach vaya) si no me equivoco.

A mi lo que me gusta de python es la cantidad inmensisima de librerías que tiene y desde hace un tiempo para acá, no paran de salir cosas hechas en python, se ve que gusta.

Realmente me gusta más python que java, aunque creo que me gusta más la sintaxis de Java, tipado estatico entre otras cosas. Aunque no hay nada que java pueda hacer ante la flexibilidad que python da.

Y si, python puede ser más productivo, pero java es más ligero pero su VM chupa más ram.
Bueno, el foreach de Java no es igual al for in de Python. Para usar el foreach tienes que recurrir a parametrizar el vector o la colección que sea (menos los array, que ya le indicas el tipo al crearlos). Por lo que o haces supercasting a Object de todo lo que tengas que meter y luego haces downcasting o sólo puedes meter objetos de una clase. Aunque el casting sea parte de la construcción. Es mínimamente mejor que usar un iterador pero sigo prefiriendo el modo de Python. Aunque esto es más debido a la colección en sí más que a la forma de iterar sobre ella.

Pero es que además puede ser incluso más compacto. Por ejemplo para modificar una lista puedes hacer algo como esto:

lista = [0, 1, 2]

lista2 = [x ** 2 for x in lista]

lista2
[0, 1, 4]

Y ahora que lo pienso. También es un coñazo tener que pasar los tipos primitivos por las clases wraping correspondientes para poder meterlas, ya que no son objetos.
zootropo escribió:
Por cierto, me refería a rapidez a la hora de programar, que es de lo que hablaba Darkoo si os fijáis en la conversación en la que estábamos antes de esa sobrada.



Yo me refería a todo un poco. Es verdad que yo Python no he tocado en la vida, pero justo el ejemplo del hilo, un "hola mundo" gráfico, en Java se hace mucho más rápido. O por lo menos a mi me parece.
Bueno, el foreach de Java no es igual al for in de Python. Para usar el foreach tienes que recurrir a parametrizar el vector o la colección que sea (menos los array, que ya le indicas el tipo al crearlos). Por lo que o haces supercasting a Object de todo lo que tengas que meter y luego haces downcasting o sólo puedes meter objetos de una clase. Aunque el casting sea parte de la construcción. Es mínimamente mejor que usar un iterador pero sigo prefiriendo el modo de Python. Aunque esto es más debido a la colección en sí más que a la forma de iterar sobre ella.


Esto no es cierto. Puedes hacer un foreach en Java sobre cualquier clase que implemente Iterable. Además, no existe ni downcasting ni upcasting, los tipos parametrizados NO EXISTEN en tiempo de ejecución. Así que al runtime le da lo mismo.

Es más, internamente, no existe tampoco la construcción foreach, el compilador te genera un while.

Y ahora que lo pienso. También es un coñazo tener que pasar los tipos primitivos por las clases wraping correspondientes para poder meterlas, ya que no son objetos.


Tampoco es cierto, Java 1.5 tiene autoboxing.

- ferdy

------------

El gran problema que tienes con esto:

Pero es que además puede ser incluso más compacto. Por ejemplo para modificar una lista puedes hacer algo como esto:

lista = [0, 1, 2]

lista2 = [x ** 2 for x in lista]

lista2
[0, 1, 4]


Es esto:

>>> lista = [0, 1, 2]
>>> lista2 = [ x ** 2 for x in lista ]
>>> lista2
[0, 1, 4]
>>> x
2
>>>


Que es extremadamente no-intuitivo para cualquiera que programe en otros lenguajes de programación.

No todo se reduce al número de líneas, si no que también hay que tener en cuent las cosas 'inesperadas' que pueden ocurrir en esas líneas.

- ferdy
Esto no es cierto. Puedes hacer un foreach en Java sobre cualquier clase que implemente Iterable. Además, no existe ni downcasting ni upcasting, los tipos parametrizados NO EXISTEN en tiempo de ejecución. Así que al runtime le da lo mismo.

Es más, internamente, no existe tampoco la construcción foreach, el compilador te genera un while.

Me parece que no me has entendido. Tienes que parametrizar el vector para decirle qué tipo vas a guardar. Luego si quieres meter objetos de más de un tipo tendrás que indicarle un supertipo de todos ellos. Bien Object o cualquier otra cosa, o una clase o interfaz que tú hayas creado. Y luego en el código, hacer downcasting a lo que fuera, a menos que lo que te interese sea un comportamiento común que tengas definido en la superclase. A eso me refería, aunque es una tontería...

Tampoco es cierto, Java 1.5 tiene autoboxing.

Cierto. Últimamente lo único que he hecho con Java ha sido dentro de un proyecto con GWT cuyo compilador sólo implementa Java 1.4.2.

Que es extremadamente no-intuitivo para cualquiera que programe en otros lenguajes de programación.

Pues yo no veo qué tiene de poco intuitivo. ¿Qué crees que debería devolver? :-? Es una variable que estás usando para iterar. Yo le veo mucha lógica a que contenga el último valor que se le ha asignado. ein?
Lo suyo es que no exista en ese contexto:

unsigned n = 0;
for (int i = 0; i < 100; i++) {
    int x = n * i;
    n += x;
}
// no existen ni 'x' ni 'i' en este contexto


- ferdy
Darkoo escribió:

Yo me refería a todo un poco. Es verdad que yo Python no he tocado en la vida, pero justo el ejemplo del hilo, un "hola mundo" gráfico, en Java se hace mucho más rápido. O por lo menos a mi me parece.


En PyGTK, sin evento para cerrar la ventana ni nada semejante:

import pygtk, gtk
window = gtk.Window()
window.add(gtk.Label("Hola mundo"))
window.show_all()
gtk.main()
zootropo escribió:Bueno, el foreach de Java no es igual al for in de Python. Para usar el foreach tienes que recurrir a parametrizar el vector o la colección que sea (menos los array, que ya le indicas el tipo al crearlos). Por lo que o haces supercasting a Object de todo lo que tengas que meter y luego haces downcasting o sólo puedes meter objetos de una clase. Aunque el casting sea parte de la construcción. Es mínimamente mejor que usar un iterador pero sigo prefiriendo el modo de Python. Aunque esto es más debido a la colección en sí más que a la forma de iterar sobre ella.


Vaya un ejemplo.Y mira que hay cosas por las que se puede criticar a java, pero básicamente lo estás criticando por ser fuertemente tipado, y para un caso de dudosa utilidad.

Sobre la sintaxis, a mí alguna cosa que he visto de python también me ha dado un poco de repelús (sobre todo el usar espacios para indentar).
bastian escribió:
Vaya un ejemplo.Y mira que hay cosas por las que se puede criticar a java, pero básicamente lo estás criticando por ser fuertemente tipado, y para un caso de dudosa utilidad.

Sobre la sintaxis, a mí alguna cosa que he visto de python también me ha dado un poco de repelús (sobre todo el usar espacios para indentar).

Python es fuertemente tipado.

Yo mismo he dicho que era una tontería.

No es lo único que he escrito.

No estoy criticando a Java.

¿Espacios para indentar? ¿Y qué vas a usar? ¿Letras griegas? Si te refieres a indentar el código para definir bloques de código, es una buena idea porque el código es más sencillo de leer. Indentar es una buena práctica, y en este caso es una obligación.
zootropo escribió:Python es fuertemente tipado.

Quería decir de tipado estático. (*)

¿Espacios para indentar? ¿Y qué vas a usar? ¿Letras griegas? Si te refieres a indentar el código para definir bloques de código, es una buena idea porque el código es más sencillo de leer. Indentar es una buena práctica, y en este caso es una obligación.

Sí, me refería a usar el indentado para definir bloques. (*)
Creo que todos estamos de acuerdo en que indentar es una buena práctica, pero usar la indentación para eso particularmente a mi no me gusta nada. No creo que haga el código más sencillo de leer, más bien al contrario.

Un saludo.

(*) (Nota mental: No volver a postear recién salido de currar.)

Ah, y para indentar tampoco uso espacios, sino el tabulador. [666]
Si estás de acuerdo en que lo correcto es indentar el código, porque se ve la estructura del programa de un golpe de vista y es más fácil de leer... ¿Qué tienes en contra de que indentar sea obligatorio?

Es más, si fuera por mí sería obligatorio hasta añadir cadenas de documentación a las funciones, los módulos... [toctoc]

(Para el que no lo sepa si lo siguiente al def de una función en Python es una cadena, esta se guarda en una variable especial de la función, dado que la función es un objeto, la variable __doc__. Lo mismo ocurre con el módulo en el que está escrito el código, dado que ¡¡¡también es un objeto!!!)
Una estúpida anécdota....

Hace unos meses, durante la transición a python-2.5, un desarrollador de Gentoo quería comprobar que ciertos ficheros python cumplían ciertas reglas con respecto al PEP 0263. Pensó que molaba hacerlo en python y le dije que era una mala opción. ¡ Había un reto !

Su código python empezó con tres líneas y acabó con un número de líneas similar al de líneas 'interesantes' de mi versión en C. Sin embargo, el código en C lo programé mientras el código en python hacía su trabajo. Es más, el código en C incluso acabó de trabajar ANTES que el de python. Al final hubo que parar el script en python, simplemente era muy lento.

No se cómo de bueno sería tal script, el código en C está aquí: http://dev.gentoo.org/~ferdy/stuff/check_pep0263.c

La velocidad y facilidad de desarrollo pueden tener precios.. es más, en este caso, el precio fue demasiado alto. El script era varios órdenes de magnitud más lento que el código en C. No creo que nadie pueda decir que la versión en C es mucho más dificil de programar o entender que algo similar hecho en python. Es más... no tiene muchos hacks ni nada oscuro, es lo primero que se me vino a la cabeza y fue suficientemente rápido como para necesitar optimizarlo.

En mi opinión, no hay una herramienta universal. Como dice ESR en el TAOUP, es bueno dominar: "C, un lenguaje orientado a objetos, un lenguaje de scripting y un lenguaje funcional". Es la única forma de tener herramientas para atacar (casi) cualquier tipo de problema.

- ferdy
zootropo escribió:Si estás de acuerdo en que lo correcto es indentar el código, porque se ve la estructura del programa de un golpe de vista y es más fácil de leer... ¿Qué tienes en contra de que indentar sea obligatorio?

Estoy de acuerdo en que indentar correctamente el código mejora la legibilidad. Usarlo para algo más, no me gusta demasiado. Para mí son más legibles las llaves. Y creo puede provocar bugs tontos difíciles de encontrar.
A mi personalmente me cuesta mucho seguir código python con el que no estoy familiarizado justo por ese tema... pero entiendo que será cuestión de acostumbrarse. El problema es que casi todos los demás lenguajes con los que trato utilizan marcadores explícitos así que acostumbrarse es más complicado aún.

Haskell usa un sistema similar... algo molesto al principio.

- ferdy
39 respuestas