Barrapunto

javascript: puta para todo, bueno porque tiene un sistema de objetos bastante sencillo y como tengo mala memoria, me resulta facil recordar su sintaxys.. aunque con los años he aprendido lo mas dificil de la programacion orientada a objetas: no usarla para todo :D

perl sin modulos: es como C, potente y versatil y artistico y sucio, la solucion para todo. lo que uso para la mayoria de los problemas que ..con un script se ventilan.

perl con modulos: no lo uso, ose no programo scripts con modulos.. quizas para hacer algo asi prefiera delphi.. que ya no es un lenguaje de script.. pero es que perl tampoco es un lenguaje de script sino que es un lenguaje de programacion serio y rotundo (con modulos y sabiando debe ser la leche).

python: (päiton que dice la gente que no traduce la informatica y que tambien dicen jäiva (que pijos, por dios)) prometo meterle caña, porque se ve gueno, pero ¿me lavara mas blanco que mi perl? lo dudo. Mi perl es mucho perl.

Por cierto, si esta noticia es un intento de provocar una guerra religiosa de lenguajes dominguero, sus corto las pelotas :D

guen rollo, guenos alimentos :D

Tras haber pasado por Perl y Python, creo que Ruby es de lo mejorcito que hay.

Orientación a Objetos pura y dura, mix-ins (ok, no es herencia múltiple, pero funciona), garbage collector, closures, etc.

Lo malo: que no tiene un Zope o un CPAN detrás, pero eso es porque se trata de un lenguaje relativamente joven.

La única pega que no tenga el CPAN detrás (que no es poco). A pesar de todo, tiene bindings para Tk, GTK y QT (aunque menos maduros que los de python o perl).

Auténtica orientación a objetos ; aquí _sí_ que todo es un objeto, ¡hasta las clases! NOTA: el que piense que esto no tiene sentido o que desvarío, que se lea esto. "hola, mundo".length, Object.type

Iteradores con closures

un_hash.keys.each { |x| puts "#{x} es una llave }

Las closures almacenan en sí el contexto en el que estaban, por ejemplo el valor de las variables locales del bloque en el que estaban, aún después de que las variables hayan salido de su scope. Pongo un ejemplo porque los que venimos de C/C++/Java etc, no solemos ver estas cosas (sacado del libro de AW):

def nTimes(aThing)
return proc { |n| aThing * n }
end
p1 = nTimes(23) # define la closure
p1.call(3) # resultado 23*3
p1.call(4) # resultado 23*4
p2 = nTimes("Hello ") # haremos 'Hello' * n
p2.call(3) # 'Hello Hello Hello '

Nótese que el parámetro formal aThing ha "muerto" antes de llegar a las llamadas.

mix-ins (como interfaces en Java pero con código, básicamente clases no instanciables, pero no forman ciclos en la jerarquía de clases).

acceso uniforme (no se diferencia entre atributos computados y guardados en memoria). Por ejemplo, para las instancias de la clase Fecha, podríamos tener dos atributos distintos, comoTexto y enSegundos (desde 1/1/1970, por ej). Internamente se guarda el valor en segundos, pero se puede hacer

fecha.comoTexto = "24/02/2002" porque en la clase nosotros definimos el método comoTexto=()

No faltan otras cosas habituales como threads, regexps, excepciones (con añadidos como ensure, que no tiene nada que ver con las aserciones de Eiffel), sobrecarga de operadores (pero no sobrecarga sintáctica... ¿cómo podría si es untyped?)... Y el GC no es por reference counting, sino mark & sweep, así que no da problemas con las estructuras cíclicas (creo que eso sí le pasaba a perl).

Al contrario de lo acostumbrado en otros OOPL, éste es absolutamente dinámico:

• puede añadirse métodos a clases ya existentes a cuyo código no se tenga acceso
• puede añadirse métodos a objetos existentes (lo llaman singleton methods), parecido a las inner classes de java
• los métodos pueden redefinirse a sí mismos (y a los demás) en tiempo de ejecución, permite por ejemplo implementar fácilmente los patrones Adapter, Decorator, Proxy, State...
• introspección (reflection)

Como consecuencia de todo ello, el lenguaje es realmente extensible. Un sistema de objetos distribuidos se puede escribir en 200 líneas de Ruby. Muchos componentes del lenguaje se consiguen extendiéndolo a partir de la base. Por ejemplo attr_reader (crea métodos de acceso a atributos), once (permite que el resultado de un método se compute únicamente la primera vez que se ejecuta), etc...

Funciona en UN*X, Windows, DOS, MAC... En Windows puede usar Win32API. Existe un módulo para Apache (también puede usarse eruby, similar a eperl) para procesar páginas web como PHP.

Además el libro de AW se distribuye según la licencia Open Publication License. Puede verse online aquí [rubycentral.com], bajarse como HTML, XML o PDF aquí [pragmaticprogrammer.com]. En debian, apt-get install rubybook.

He estado trabajando bastante tiempo con PHP, y la verdad es que siempre que he necesitado algo lo he encontrado. Tiene unas librerías muy amplias lo abarcan todo (bueno, casi todo). Lo he usado tanto para generar páginas html como de propósito general.

También he usado Javascript, pero sólo incrustado en páginas web. El problema es el de siempre, que hay cosas que programas y que funcionan en un navegador pero no en otro, y te tienes que romper la cabeza para que funcione en todos los navegadores, o hacer una versión para cada navegador.

Sólo quería remarcar que algunas de las cosas que comentas Python 2.2 también las tiene, y otras ya las podía hacer anteriormente, por ejemplo:

Iteradores, todo es un objeto (y generadores): Lo tiene desde la 2.2.

Acceso uniforme: También desde la 2.2, mediante 'propiedades' (anteriormente se podía hacer con __getattr__ pero no era tan claro como ahora).

GC mejorada: Python, desde la versión 2.0, tiene un añadido a la recolección de basura por conteo de referencias que elimina los problemas que mencionas (y sigue siendo rapidísima).

Añadir métodos a clases y objetos existentes (aunque no se tenga acceso al código): Python puede hacer esto desde hace bastante tiempo, lo probe con la 1.5.2 y funcionaba, es más, si añades un método a una clase existente automáticamente todas las instancias ya creadas incorporan ese nuevo método.

Métodos que se redefinen a si mismos: También lo puede hacer Python, por eso sería tan dificil compilarlo.

Introspección: Por supuesto :)

Sobre lo de los objetos distribuidos... yo en Python lo haría con cPickle (permite serializar objetos) y no creo que me ocupase mucho más de 200 líneas ;)

Saludos.

Estas palabras hay que absorverlas en el castellano e ir olvidando la pronunciacion inglesa, porque la pronunciacion inglesa en un paladar castellanizado es una mostruosidad.

  Ademas puede provocar ambiguedades:
Diferencia de pronunciacion de esto:

30 Kw
30 KB

¿habra gente que pronuncie kilovaits, y kilovaites? Es un horror, prefiero mucho mejor kilovatios y kilobytes

Otra cosa:

Aun en la informatica no existe una regla para esto:

30 Kb
30 KB

¿Que son kilobits y que son kilobytes?
En mi universidad, el profesor Mallen tiene esta opinion:

"Depende del contexto", dijo. Y en aplicacion, muchas veces los usa indistintamente....

HORROR, AMBIGUEDAD!!!

Creo que seria necesario YA que nos pusieramos de acuerdo para eliminar estas ambiguedades.

Yo propongo esto:
Kb -> b de bits -> kilobits
KB -> B de bytes -> kilobytes

¿Como nos vamos a entender si no uniformizamos estas cosas?

ale!

NO.

Sin son scripts y los compilas, pierde la gracia. Si ganas algo de velocidad,.. no creo que sea algo dramatico, perl SE COMPILA (es un decir) cuando se carga sobre la memoria... bien, de todos los pasos que son una compilacion, solo sigue los primeros. Por esto mismo dar los ultimos pasos hasta el lenguaje de maquina nativo no suele ser una GRAN ventaja. Ademas que inherentemente los lenguajes de scripts hacen cosas que deben ser EVALUADAS en tiempo real, con lo que tu ejecutable sigue siendo un script aunque no lo parezca.. (porque se va evaluando a si mismo todo el tiempo, con preguntas a los kennen brannan ¿Es esto una cadena o un numero?¿bla?)..

Si realmente era importante la velocidad para la aplicacion, quizas se debio hacer en C.

Si realmente se quiere optimizar la cosa, quizas seria mejor re-escribirla con un mejor algoritmo. Los experimentos se hacen con gaseosa y no creo que se garantize la funcionalidad correcta de un script compilado (en perl no recuerdo si lo hacian, pero si lo hacen yo sigo sin fiarme)

De echo, imaginate un lenguaje de script con una linea como esta

$cosa = ;
eval($cosa);

Ahora compila esto ;D (no recuerdo si existe eval en perl pero es igual, esto te da una idea de la naturaleza "peculiar" de los lenguajes de scripts)

Muy bonito de la traducción (yo mismo soy un gran fan, y adalid de la causa), pero metemo que mientras que digo Java en lugar de "Yava" (o similares), y digo CeMásMás y no CePlusPLus, sí digo "paizon", y no "pitón", porque deriva de un nombre propio del inglés que no conozo yo que tenga una "traducción" habitual en castellano (no es lo mismo que con Java, ya que igualmente decimos "Londres" y no "London", pero es un nombre que hemos heredado de antiguo... hoy en día tomamos los toponímicos nuevos tal cual, o adaptándolos a nuestra grafía).

La traducción "a ultranza" es tan patética y ridícula como la adopción por sistema de las palabras originales sin comprobar si es pertinente o no traducir.

yo siembre he dicho los hermanos monti piton, con peliculas como el circo volante, los caballeros de la mesa cuadrada, o la vida de braian.

  lo de que puede resultar ridiculo, ssii.. pero tenemos algo a favor, y es que el lenguaje funciona por reglas economicas, y elimina lo que no tiene sentido, segun esas reglas me guio yo y hago "futurologia" de lo que me parece a mi que no solo no tiene sentido ahora, sino que tendera a desaparecer, y lo que tendera a desaparecer mas rapido es la pronunciacion inglesa de palabras tecnicas de la informatica, y lo creo porque no podemos ampliar el catalogo de sonidos que un castellanohablante tiene que dominar para manejar un idioma aceptando la pronunciacion extranjera de las palabras, no creo que ocurra. Es mucho mas ahorrativo Traducir, y hacer de Yava, java. Me parecen (como todo, es una opinion)

Por cierto, si esta noticia es un intento de provocar una guerra religiosa de lenguajes dominguero, sus corto las pelotas :D

Parece que no :-) (Por lo menos en este hilo) Asi que, buen rollo... puedes guardar la faca :-D

• No aprendí Perl, oscuro y ofuscado.
• No aprendí Java, propietario, "grande" y engorroso de instalar.
• No aprendí JavaScript, fácil pero ineficiente.
• No aprendí PHP, aunque quizá debería.

Pero Python .. ¡Es harina de otro costal!
Como dijo alguien: insultantemente fácil de aprender, e insultantemente fácil de leer.
Potente, rápido, extensible (en C, y por lo tanto compilable en C), modular (con un gran número de módulos disponibles), suficientemente (para mí) orientado al objeto, y con más que sobradas capacidades para aplicaciones matemáticas.

Sólo me interesaría en estos momentos por Ruby si este tuviera dos características que sí tiene Python:

1. La facilidad para su extensión en C/C++.
2. La facilidad para resolver un problema dado: en Python no existen multiples formas de resolver un problema, sólo existe una y esa es la más obvia.

Por otra parte hay que considerar el esfuerzo (tiempo de aprendizaje, adaptación al lenguaje y al nuevo estilo de hacer las cosas,..) necesarío para aprender un nuevo lenguaje.

...existen unos bindings para PHP, en las que puedes usar GTK. yo lo probe hace algun tiempecillo y estan muy buenos......

Imaginate tu programita con GTK pero escrito enteramente en PHP!!!!

El pollito

Nosotros llevamos más de un año haciendo una aplicación de gestión para una empresa (gestión de proyectos, pedidos, facturación, personal, tesorería, ...) a medida con python y wxPython.

> la vida de braian

Mmm... imagino que querrás decir la vida de Brián,
¿no? :-)
Sinceramente, tan hortera me resulta oir
"siplasplas" (c++, por si no lo pillásteis a la primera) como "ceplusplús" o "emeesedeoese"
(MS-DOS, y conste que los angloparlantes separan
todas las letras). Eso sí, cada cual escoja su
pronunciación, que igual que me río por lo bajo
yo de la suya, ellos se reirán de la mía (y todos
nos reímos al final).

He estado bastante tiempo trabajando para el Gobierno de canarias, y programé varias cosas en Python. Entre ellas está la versión Internet del Boletín Oficial de Canarias. Inicialmente se programó en PERL, ya que la aplicación tira bastante de las expresiones regulares, pero finalmente preferí pasar a Python por su mejor orientación a objetos.

Ambos lenguajes son exelentes, pero me parece que Python es más adecuado, entre otros casos, desde que haya más de un programador.

Yo digo "la vida de braian", y escribir.. creo que escribiria "la vida de brian" (sin acento, pues no existe en ingles, creo).

c++ lo leo "ce plus plus" y no "ce mas mas", aunque entiendo esto. Nunca le he oido pronunciar a la gente c++ en ingles, lo de "plus" me salio solo, la primera vez que lei c++ ..y no tiene porque ser ingles, puede ser el "plus ultra" latino. C++ es un C muy mejorado :D

msdos lo pronuncio emesedos, asi es mas rapido y facil.

En el castellano, y en cualquier lengua, lo que manda, es la economia. La forma correcta es la mas corta y mas facil de pronunciar, pero sobretodo la que mas se usa, que con el tiempo siempre es la mas comoda. La pedanteria, y el conocimiento de idiomas, tienen las de perder, y tambien tienen las de perder monostruosidades como escribir cederon... aunque la batalla es dificil, y no hay soluciones perfectas para muchas cosas. Mi interes esta en tomar las palabras inglesas y pronunciarlas como españolas, españolizandolas un poco sin destruir lo que las hace reconocibles. Byte es una palabra española, y se debera pronunciar en castellano como bi-te.. ¿ok?.. no funcionara (simplemente) pronunciarlo como va-it

esto es solo mi opinion, claro ( y creo que redundante, pues esto ya lo comente antes )