Disclaimer: This is a personal web page. Contents written here do not represent the position of my employer.

Monday, October 08, 2007

 

Curiosidades sobre lenguajes

Como buen seguidor del omnipresente lenguaje C#, me complace mucho enlazar a un artículo muy interesante que nos introduce a una palabra clave del lenguaje bastante poco conocida, e infrautilizada: yield.

Por supuesto, éste lenguaje no es perfecto, y prueba de ello son algunas voces que critican bastante la nueva versión 3.0, que incluye bastantes modificaciones sobre todo debidas a LINQ. Algunos de estos cambios nos traen capacidades típicas de los lenguajes funcionales, y aquí voy a enlazar a un blog que incorpora una serie de artículos para que poco a poco vayamos cambiando el chip.

En otro orden de cosas, y ya que éstamos hablando de lenguajes, me gustaría mencionar algo de VB.NET (a pesar de que se ha criticado bastante, por mí y por otros): según este blog, están pensando funcionalidades para la nueva versión, y en esa misma entrada Rolf (el desarrollador del compilador de VB de Mono) propone bastantes cosas interesantes (algunas para que el VB deje de ser tan basura, y otras para que siga teniendo las [pocas] ventajas sobre otros lenguajes). Yo también he comentado algo en la entrada, con mi wishlist particular.

Y hablando de wishlists, en breves días publicaré también una lista de cambios que me gustaría se incorporaran en la próxima versión de C# (está basada en la 2.0, pero como ya sale la 3.0, tendré que actualizarlo...).

Actualización [unos minutos después de publicar]: Ya que estamos, también voy a hablar de Java. No hay que olvidar que en mi AntiFUD de Mono pongo a éste lenguaje en un pedestal (sobre todo por su reciente liberación, gracias a Sun), aunque sigo pensando que tiene inconvenientes con respecto a C#/Mono. En general, lo que opino se puede resumir en lo mismo que opina Zac Bowling (un desarrollador de Mono) en este artículo:

Honestly, I believe Java has a lot of inherit issues that pretty much can’t get fixed without breaking most backward compatibility (too many things to cite here), which is why I contribute to and support Mono and .NET. For the record though, I don’t hate Java though, and I spend a good amount of time at work developing in it. It just seems like there are so many better alternatives.

One of the only things good about it all is that at least Java isn’t entirely proprietary anymore (although good many of the common libraries, frameworks, and implementations remain that way).


Actualización [unas horas después de publicar]: También me vienen a la mente mis queridos lenguajes de programación de tipado dinámico, los de las tres P's y la R: Perl, Python, PHP, Ruby.

Me parece genial que estén surgiendo iniciativas para que estos lenguajes compilen a código CIL de .NET, para que así haya interoperabilidad entre todos (IronPython, IronRuby, ...). Pero sigo pensando que no deberían usarse para cosas medianas-grandes, por los problemas que dan en el medio-largo plazo.

Y es que los avances en la informática no hacen más que dar la razón a la gente que opta por cosas como Java o .NET, plataformas mucho más evolucionadas. Ejemplo de ello es, pongamos, el hecho de que PHP en su próxima versión vaya a soportar namespaces, o que Python, en su próxima versión, vaya a soportar una condición de compilación opcional para hacerlo estáticamente tipado. ¿Es que no se dan cuenta que constantemente están poniendo funcionalidades que ya tienen C# y Java de hace mucho?

Actualización 22-OCT-2007: Me ha encantado una entrada de otro desarrollador de Mono que opina de forma similar a mí: Gnome3 debería estar basado en Mono, quitando C++ y C, sustituyendo Python por IronPython, Ruby por IronRuby, etc...

Actualización 31-OCT-2007: Para que se entienda mejor lo que quiero decir sobre los lenguajes estáticamente tipados, es decir, los derroteros por los que han derivado las conversaciones en esta entrada, voy a citar texto de una entrada de Joe Shaw, uno de los desarrolladores de Beagle:

And lastly, having worked with Trow on a reasonably big desktop Python app, we wanted a strongly typed language. Writing real applications in Python requires a discipline that unfortunately most people (including myself) are unwilling to adhere to, and this easily leads to buggy and hard to maintain programs. You have to be very diligent about unit tests and code coverage for every line of code, because you can’t rely on the compiler to catch errors for you. We had been burned by this a bit, and wanted to get back to a strongly typed, but still easy to use language that integrated well with the desktop.

Actualización 17-DIC-2007: Proyecto super cursioso a destacar: LINQ para Java.

Actualización 02-ENE-2008: Super interesante esta entrada de Miguel de Icaza en la que habla de benchmarking de plataformas de desarrollo, y de la que me gustaría citar un fragmento:

  • Close to the metal languages are the first tier (C, C++, D, Pascal, even Eiffel).
  • (...)

I just noticed that Eiffel is on the first tier, performance wise, but has pretty much all the properties and features of the third tier (garbage collection, strong typing, bounds checking). This means that you get the best of both world with it (and Eiffel's compiler is now also open source).


Conclusión A: ¿no es Eiffel acojonante? Creo que voy a dejar de usar Mono...

Conclusión B: Va a ser importante eso del "static typing" si también lo dice Miguel de Icaza ...

Labels: , , ,


Comments:
Hola Knocte!

C# 3 se sale por todos lados :-) Aunque la verdad es que como la mitad de esto se materialice, Java 7 sería también la bomba.

También me parece que Java tiene muchas cosas que son difíciles de actualizar, en plan que puede incluir muchas mejoras a nivel de lenguaje pero actualizar cosas en la API de Java que romperían compatibilidad con aplicaciones actuales sería inabordable. Sin embargo, hay que recordar dos cosas: la primera, que no todo lo que usas son "la API de Java", y a muchas librerías externas no les importa sacar una nueva versión que rompa compatibilidad (ej. junit 3.x y junit 4.x). La segunda, que ese problema es derivado de que Java sea tan "viejo", pero sin embargo eso le aporta la grandísima ventaja de la cantidad de frameworks que hay que no tienes disponibles en otras plataformas (incluyendo .NET/Mono).

Por último, me parece un poco atrevido hablar en términos de Y es que los avances en la informática no hacen más que dar la razón a la gente que opta por cosas como Java o .NET, plataformas mucho más evolucionadas. Algunas de las mejoras que C# 3 (o Java 7) trae (la palabra reservada var, las funciones lambda, aproximaciones a lenguajes funcionales, tipos anónimos...), llevan años en lenguajes como Python (y otros). El yield de C# 2 venía ya en Python 2.3, de una manera además bastante más fácil de usar. No en vano hay quien se plantea que se puede utilizar C# 3 como un Python con llaves.

Con esto no pretendo entrar en un flame de si uno es mejor que otro o viceversa, ni mucho menos. Simplemente, son diferentes herramientas, y me gusta tener varias en mi caja de herramientas. Usaré el destornillador de estrella en unas situaciones y el plano en otras.

Me encantó ver las mejoras de C# 3 como también me encantó ver que en Python 2.5 por fin ponían algo similar a using, o la idea que apuntas de usar anotaciones para marcar tipos de datos (que luego otros frameworks o IDEs utilizarán) de Python 3 (que no es compilación estática opcional, ojo), y estoy flipando con las posibles próximas novedades de Java (mi favorita, hasta ahora sólo lo había visto en lenguajes de laboratorio o compiladores especiales etc., no por defecto en un lenguaje mainstream).

Entonces eso, yo personalmente, sí me doy cuenta que constantemente están poniendo funcionalidades que ya tienen C# y Java de hace mucho, y me gusta, como también me doy cuenta de que en Java y C# están constantemente poniendo características dinámicas que otros lenguajes hace años que tienen, también me parece un avance, y no voy a ponerme a pensar para nada en términos de el tiempo da la razón a los talibanes de lenguajes de scripting, ¿hasta cuándo durarán?. :-)
 
Vaya, sin duda un comentario brillante, muchas gracias por todos esos enlaces y por sacarme de algunos errores que he cometido.

Sin embargo, me gustaría puntualizar algunas cosas:

C# 3 se sale por todos lados :-) Aunque la verdad es que como la mitad de esto se materialice, Java 7 sería también la bomba.

Eso parece.

También me parece que Java tiene muchas cosas que son difíciles de actualizar, en plan que puede incluir muchas mejoras a nivel de lenguaje pero actualizar cosas en la API de Java que romperían compatibilidad con aplicaciones actuales sería inabordable.

¿Seguro que es de API? Precisamente los cambios de API son mucho menos traumáticos, y si a Java no quieren romperle la compatibilidad hacia atrás, será por algo más grave. Por ejemplo me viene a la cabeza el tema de la forma en la que están implementados los genéricos en Java, de forma que no hay nuevo bytecode (y así son compatibles hacia atrás) con el inconveniente de que no son tan eficientes como los de .NET y no son tan seguros a nivel de interoperabilidad de ensamblados.


Sin embargo, hay que recordar dos cosas: la primera, que no todo lo que usas son "la API de Java", y a muchas librerías externas no les importa sacar una nueva versión que rompa compatibilidad (ej. junit 3.x y junit 4.x). La segunda, que ese problema es derivado de que Java sea tan "viejo", pero sin embargo eso le aporta la grandísima ventaja de la cantidad de frameworks que hay que no tienes disponibles en otras plataformas (incluyendo .NET/Mono).


Eso es cierto.


Por último, me parece un poco atrevido hablar en términos de Y es que los avances en la informática no hacen más que dar la razón a la gente que opta por cosas como Java o .NET, plataformas mucho más evolucionadas. Algunas de las mejoras que C# 3 (o Java 7) trae (la palabra reservada var, las funciones lambda, aproximaciones a lenguajes funcionales, tipos anónimos...), llevan años en lenguajes como Python (y otros). El yield de C# 2 venía ya en Python 2.3, de una manera además bastante más fácil de usar. No en vano hay quien se plantea que se puede utilizar C# 3 como un Python con llaves.


Pues igual que tú tienes esa opinión, yo tengo otra distinta. Y no me parece atrevido hablar en esos términos, sobre todo con respecto a la compilación estática, que me parece FUNDAMENTAL (mucho más que cualquier chorrada funcional o del estilo de yield). Y dentro de poco pondré una entrada en el blog enorme sobre el tema.


Con esto no pretendo entrar en un flame de si uno es mejor que otro o viceversa, ni mucho menos. Simplemente, son diferentes herramientas, y me gusta tener varias en mi caja de herramientas. Usaré el destornillador de estrella en unas situaciones y el plano en otras.


Es un argumento/simil muy socorrido, y yo no pretendo ser más listo que nadie, pero sí opino que existen herramientas que son mejores que otras (me refiero en términos globales; por supuesto que Python puede ser mejor que C# en algunas cosas, pero yo hablo de grandes números, es decir, me gustaría poder contrastar resultados reales de proyectos de software en función del lenguaje/plataforma utilizado).


Me encantó ver las mejoras de C# 3 como también me encantó ver que en Python 2.5 por fin ponían algo similar a using, o la idea que apuntas de usar anotaciones para marcar tipos de datos (que luego otros frameworks o IDEs utilizarán) de Python 3 (que no es compilación estática opcional, ojo), y estoy flipando con las posibles próximas novedades de Java (mi favorita, hasta ahora sólo lo había visto en lenguajes de laboratorio o compiladores especiales etc., no por defecto en un lenguaje mainstream).


Muy chulo lo del using. Sin embargo lo de Java no le encuentro demasiado atractivo ahora, creo que no lo he necesitado nunca por el momento.


Entonces eso, yo personalmente, sí me doy cuenta que constantemente están poniendo funcionalidades que ya tienen C# y Java de hace mucho, y me gusta, como también me doy cuenta de que en Java y C# están constantemente poniendo características dinámicas que otros lenguajes hace años que tienen, también me parece un avance, y no voy a ponerme a pensar para nada en términos de el tiempo da la razón a los talibanes de lenguajes de scripting, ¿hasta cuándo durarán?. :-)


Yo no digo que vayan a desaparecer los lenguajes de scripting. Pero sí digo que seguramente la mayoría migren todos a un modelo más estáticamente tipado, o sólo se queden como poco habituales en la industria para proyectos medianos-grandes (o para partes donde es más necesario el scripting, como lanzadores de deploy o configuradores, o como herramienta de administradores, nunca como uso en el desarrollo de software profesional).
 
¿Seguro que es de API? Precisamente los cambios de API son mucho menos traumáticos, y si a Java no quieren romperle la compatibilidad hacia atrás, será por algo más grave. Por ejemplo me viene a la cabeza el tema de la forma en la que están implementados los genéricos en Java, de forma que no hay nuevo bytecode (y así son compatibles hacia atrás) con el inconveniente de que no son tan eficientes como los de .NET y no son tan seguros a nivel de interoperabilidad de ensamblados.

Sí, precisamente al estar en la API que todo el mundo usa, tanto en .NET como en Java tuvieron que hacer "algo" para que el código viejo fuese compatible. En una librería externa, sacas una versión "4.0" que es incompatible con la anterior, y te quedas tan ancho. Pero en la API ese cambio tan traumático no puedes hacerlo, y tienes que o bien hacer que siga siendo compatible vía deprecated o bien repetir la funcionalidad en otro paquete. Es especialmente peliagudo el tema con enumerados. Desde Java 1.5 tienes enumerados. Pero a lo largo y ancho de toda la API de Java tienes que si Color.RED y tal que ni son enums ni van a cambiar a enums. Y a ver quién se atreve a cambiar eso.

Pues igual que tú tienes esa opinión, yo tengo otra distinta. Y no me parece atrevido hablar en esos términos, sobre todo con respecto a la compilación estática, que me parece FUNDAMENTAL (mucho más que cualquier chorrada funcional o del estilo de yield). Y dentro de poco pondré una entrada en el blog enorme sobre el tema.

Espero ansioso esa entrada :-)

Es un argumento/simil muy socorrido, y yo no pretendo ser más listo que nadie, pero sí opino que existen herramientas que son mejores que otras (me refiero en términos globales; por supuesto que Python puede ser mejor que C# en algunas cosas, pero yo hablo de grandes números, es decir, me gustaría poder contrastar resultados reales de proyectos de software en función del lenguaje/plataforma utilizado).

No sé, me encanta stetic para hacer mi aplicación gráfica en linux, y programar servicios web en Mono, pero también soy fan de GWT (a pesar de que Java 1.4 no me guste nada) y en el curro ahora tengo que trabajar con Jena. ¿Qué herramienta es mejor, C# o Java?

Espera, que cuando trabajo con Java en Gumstix (donde no puedo trabajar con C# -al menos de manera sencilla y pudiendo buscar relativamente fácilmente información de otra gente que lo ha hecho; no he probado a compilar mono-) veo que la máquina virtual de Java JamVM no gestiona bien los procesos y mejor eso lo implemento en C (que no C++, que aunque se pueda no quiero líos para algo que debe ser extremadamente simple). Pero no me gustaría que APIs de alta capacidad de cómputo de criptografía estuviesen programadas en el lenguaje interpretado que esté usando, sino en C o C++. Y para proyectos grandes en plan juegos y así que sean grandes pero necesiten alto rendimiento, supongo que C++ estará genial (si te gusta la OOP como supongo que es el caso, descarta C y descarta bytecodes al menos en el core del proyecto).

Y si no me importa el rendimiento, cuando cacharreo con algoritmos me encanta trabajar con Python, por claridad (¿o vas a pedir a Peter Norvig que implemente su solucionador de sudokus en C#?). Porque la claridad es importante. Por ejemplo, para explicar xUnit, su creador en el libro Test Driven Development recurre diréctamente a PyUnit (aunque JUnit sea con toda seguridad mucho más usado). O cuando quieres implementar algoritmos tú mismo trabajando con criptografía, el poder hacer 2**512 % 9 sin despeinarte (sin usar enmarronar el código con BigIntegers y sus métodos) es un lujo, y más aún si lo haces en tu móvil en clases de criptografía (que claro, en ese momento piensas ¿compilar? ¿para?). Incluso, es más, en proyectos más grandes, cosas como decorators (que van más allá de los aspectos desde el momento en el que tienes estado o controlas el número de veces que se llaman a los métodos o decides si lanzar los métodos en otros hilos), generadores dinámicos de código (en plan fácil sin rayarte a hacer bytecode a pelo ni nada), o incluso iteradores (vía yield), todo ello fácil y para toda la familia, te alegra los dedos, pudiendo escribir bastante más funcionalidad en mucho menos código (y menos tiempo). No sé, cuando gurús de la Ingeniería del Software del tamaño de Kent Beck o Martin Fowler hablan bastante (y bien) de lenguajes de tipado dinámico como ruby, tan malos no pueden ser.

Muy chulo lo del using. Sin embargo lo de Java no le encuentro demasiado atractivo ahora, creo que no lo he necesitado nunca por el momento.

Bfff, pues yo estoy deseando verlo ya en Java y C#. Cuando trabajo con lenguajes de tipado estático, quiero poder corregir el máximo número de fallos en tiempo de compilación (y definir cosas como "esto no debería ser nunca null" y que en tiempo de compilación se compruebe me parece sencillamente brutal, igual que otras características que la propia industria solicita). El resto de fallos (bueno, su mayoría), ya los encontraré en tests unitarios (exáctamente igual que en lenguajes de tipado dinámico ;-D).

Yo no digo que vayan a desaparecer los lenguajes de scripting. Pero sí digo que seguramente la mayoría migren todos a un modelo más estáticamente tipado, o sólo se queden como poco habituales en la industria para proyectos medianos-grandes (o para partes donde es más necesario el scripting, como lanzadores de deploy o configuradores, o como herramienta de administradores, nunca como uso en el desarrollo de software profesional).

Yo no lo llamaría más estáticamente tipado cuando nunca van a dar el salto a que se compilen estáticamente (y más cuando tipado estático es una propiedad "boolean"). Cosas como las anotaciones de Python para definir algunas funciones vienen bien si quieres exportar un servicio en algún tipo de middleware (para generar WSDL, por ejemplo), o incluso para que los entornos de desarrollo puedan entender mejor de lo que hacen ahora tu código (y por tanto proveer más refactorings de los que te ofrecen ahora, que son bastante de mofa). Seguiré mi código que genera dinámicamente clases e instancias de esas clases, y al final de todo ese código, podré además indicar a modo de documentación (y para el IDE) que el resultado final de un montón de operaciones no tipadas hay una instancia que implementa al menos un interfaz concreto. Cosas que se introducen en Python 3 como Abstract Base Classes también vienen genial (especialmente que vengan con el propio lenguaje, no como hasta ahora los interfaces) para detectar cuanto antes posibles fallos, pero no tanto como "en tiempo de compilación".

La cuestión es que el encontrar para los errores "cuanto antes" está la compilación en lenguajes de tipado estático, los tests, la integración continua, las revisiones de código, etc., y de ellas sólo una (y no creo que justo la más importante) está presente en los lenguajes de tipado estático y no en los de tipado dinámico, por lo que me parece un poco exagerado pensar que es algo tan FUNDAMENTAL, y mucho más exagerado que sea "en todas las situaciones". En cuanto a proyectos grandes que usan lenguajes de scripting, acuérdate de lua en diferentes proyectos que conoces.

Saludos :-)
 
Knocte también existe la posibilidad de usar conjuntamente ambos lenguajes. Por ejemplo Java con algún lenguaje dinámico o de scripting como podría ser Groovy. De forma que dentro de un proyecto utilices ambas, dejando la potencia de hacer más cosas con menos código y de forma más simple en las partes que creas necesario

Saludos
 
Post a Comment

Links to this post:

Create a Link



<< Home

This page is powered by Blogger. Isn't yours?

Categories

RSS of the category Gnome
RSS of the category Mono
RSS of the category C#
RSS of the category Programming
RSS of the category Mozilla
RSS of the category Web Development
RSS of the category Security
RSS of the category Open Source
RSS of the category Engineering
RSS of the category Misc
RSS of the category Politics

Contact with me:
aaragonesNOSPAMes@gnNOSPAMome.org

Archive
My Photo
Name:
Location: Hong Kong, Hong Kong
Follow me on Twitter