knocte :: MonoTema

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