17/03/2008
17/09/2008
11/06/2008
21/02/2008
10/03/2008
26/03/2008
Sí, es verdad, el título busca provocar. Pero en el buen sentido, para animar a que surja un debate interesante. Siguiendo una noticia publicada en planeta javaHispano en la que se comenta que Jonathan Schwartz afirma que están pensando en quitar la J de JVM, he llegado, por medio de un enlace, al conocimiento de la existencia de un proyecto llamado Máquina de Da Vinci de Sun. Se trata de una tecnología que permite mejorar el soporte para la ejecución de múltiples lenguajes en la JVM. En el fondo, supone un cambio sustancial en la actual JVM y de algún modo una aproximación a la filosofía de .NET. ¿Créeis que eso favorecerá a Java? ¿Créeis que realmente se llevará a cabo y se logrará algo semejante a lo que ha hecho Microsoft pero con un soporte de verdad para Linux y Solaris?
Soy javero y de tanto en tanto hago cosas en .NET, por lo parecido de ambas plataformas no tengo ningún problema. Sinceramente la característica "multi lenguaje" de .NET es probablemente la funcionalidad más tonta y la mayor idiotez de dicho framework.
Lo de idiotez es una consecuencia directa de que sea una funcionalidad tonta. Hacer eso hace el framework muy complicado. Cuando lo aprendes te vas dando cuenta de detalles sobre su diseño que son muy poco elegantes, y ves que esas cosas son así para poder proporcionar algunas funcionalidades tontas como esa.
Ahora toca justificar por qué es una funcionalidad tonta. No aporta valor real, es markenting. Llegas a la conclusión de que para lo único que sirve es para atraer a la plataforma a gente de otras culturas. De otras culturas no quiere decir simplemente que usen otro lenguaje, si no que además sean tan perezosos como para no aprender otros lenguajes. Si son perezosos para no aprender nuevos lenguajes no digamos nuevos paradigmas (OO para uno que viene de VB!!!!). Pero observas cómo es el nuevo Visual Basic .NET y te das cuenta que a esa gente le va a tocar cambiar el chip de todos modos .... yo veo un absurdo ahí.
Esa no es la única de las tonterias e idioteces. Yo, por ejemplo soy de los que no pondría el soporte de closures en Java ... pues .NET lo tiene. Otro ejemplo de complicar el sistema sin aportar valor, ya que lo que haces con closures/delegados lo podias hacer antes.
Qué Sun quiere hacer lo mismo?, pues sinceramente creo que Sun quiere hacer una idiotez. No obstante, mientras sea un proyecto a parte y no modifique la JVM de siempre estoy tranquilo ... y si no también.
TuXsY
a mi realmente el unico lenguage que me interesaria que se pudiera usar en una VM ademas de java, es C++, eso es lo unico que le envidio a .NET (C++/CLI) que permite mezclar codigo nativo con codigo manejado en el mismo archivo de codigo fuente, cuando se compila se crea un ensamblado que puede ser utilizado en los otros lenguajes como C# (este es el unico que he usado aparte de C++/CLI) y desde codigo Nativo. Hay algo parecido en java que es el compilador de GNU para java, pero no es lo mismo porque compila toodoo a nativo y esta un poco atrasado encuanto a la espeficiacion.
En .NET, C++/CLI tiene la opcion de compilar a un ensamblado manejado puro, obviamente aqui solo usas librerias manejadas y nada de nativo. Pero esto no es muy interesante porque mejor seria usar C#, en el caso de Java me gustaria algo asi como: C++/J o JC++, que permite la mezca de codigo nativo y manejado. Ojo, no me refiero que se puedan hacer instrucciones C++ en Java, sino utilizar las librerias manejadas bytecodes hechas en java desde C++ y compilar C++ ha bytcode mezclado con nativo..
algo asi:
String^ MyClase::hacerAlgo(String^ nombre, Persona^ p){
ClaseNativaPura *objNativo = new ClaseNativaPura(parse(nombre),parse(p->getAlgo());
objNativo->hacerAlgoMasNativo();
String^ resultado = parse(objNativo->getResultado());
return resultado;
}Puntualización por lo poco que se .Net no tiene clousures, lo mas cercano que tiene es funciones lambda. Que tiene "cierto" parecido pero no es ni de largo lo mismo (de echo ¿será un subconjunto uno del otro?). A parte de eso en la última versión también metieron otras ñapas intentando imitar a los lenguajes dinámicos, pudiendo añadir a una interfaz nuevos métodos. Pero diooos que cerdada es, cuando te explican un poco de python y ves eso, no sabes si reir o llorar.
Yo lo que creo es que mucha gente anda bastante perdida en este tema y realmente no sabe ni lo que hay ni en lo que estan trabajando.
Soporte para otros lenguajes sobre la JVM lo ha habido desde el principio, lo unico es que antes Sun no "promocionaba" ningun otro lenguaje mas que Java y ahora ha cambiado de estrategia. Lo que nos llamarían corregir un error, otros lo llaman "dejarse arrastrar y no tener criterio". Si no lo haces por que no lo haces, si lo haces por que lo haces. En fin.
Y en la ultima reunion de la gente de de Microsoft y los de Sun, vieron lo parecidas que eran algunas de sus posturas pero que la JVM le lleva varios años de ventaja a la de .NET y que el soporte multilenguaje de Da Vinci y la nueva MV multilenguaje de .NET es sustancialmente diferente y en el caso de .NET significara un rendimiento bastante más pobre.
En cuanto a Da Vinci, lo unico que estan haciendo es introducir cambios en la MV para que los lenguajes que ya se ejecutaban en la MV no tengan que dar tantas vueltas y su rendimiento mejore muuucho sobre lo que ya es por si misma de las mejores MV que hay.
En cuanto a mezclar distintos lenguajes en el mismo codigo fuente... uff, miedo me da. Yo uso lenguajes de Scripting, si, pero cada lenguaje por su lado sin mezclar las fuentes.
Y para acabar de redondear el tema... con lo jugoso que esta la cosa y el hype disparado sobre los lenguajes de scripting, la gente no hace mas que saltar a conclusiones en cuanto alguien estornuda. ¿Lo ha hecho con Java? ¿Se ha sonado con un pañuelo JEE? ¿Nooooo?, Entonces es que Java va a morirrrrrr!!!
S!
Gracias greeneyed, por aportar un poquito de cabeza al tema. Hay una confusión de base que creo que se da entre, principalmente, los que nunca han tenido entre manos más de 2000 líneas de código. Normalmente son los directores de proyecto y niveles superiores.
Veréis, algún genio del Marketing de Microsoft les ha vendido que es una gran idea poder utilizar la CLR/CLI de .NET para poder mezclar código de diferentes lenguajes. Lo cual, en cualquier proyecto de tamaño ligeramente mediano es, simplemente, suicida. Un proyecto hecho con 4 lenguajes diferentes, cuando tenga que reemplazar a un desarrollador que se va, las va a pasar canutas. Eso sin mencionar que los interfaces entre lenguajes no son que digamos transparentes, porque por mucha CLI que haya debajo, simplemente hay conceptos en un lenguaje que no se pueden mapear de forma sencilla a otro.
Y no digamos ya cuando el sistema entre en mantenimiento. Me da la risa sólo de pensar que hay que convencerle al responsable del mantenimiento que necesita 4 personas, cada una especialista en un lenguaje diferente, para mantener cada parte de una aplicación, cuando probablemente una sola persona podría hacerlo.
Es por eso que enuncio la "regla del anónimo" Vale, no es mía, viene de las "Nerd Laws of Software Development" que dice que "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common List." Pues yo la extiendo y digo, "cualquier aplicación lo suficientemente compleja y que tiene éxito usa como mucho dos lenguajes: uno para el núcleo y otro de scripting"
Lo que SI tiene valor, y mucho, es la facilidad con que puedes llamar a bibliotecas en distintos lenguajes, más que nada porque te supone un ahorro sustancial no tener que tirar código a la basura que te ha costado dinero y encima funciona. Es cierto que .NET es un paso adelante y quizá lo simplifica bastante, pero no más que Java. El hecho de que no exista "Managed C++" que genere bytecode para la JVM es simplemente porque el mercado no lo demanda, no porque no sea posible, y sin que haga falta modificar profundamente la JVM.
Por dios, si el debate es que si JPhyton es mejor que IronPhyton... , venga, vamos a terminarlo ya. Porque es una pérdida de tiempo. Nadie usa Phyton para nada grande, por la sencilla razón de que hay un mercado mucho mejor surtido de "cabezas" en Java, más baratas y más fácilmente reemplazables ¿es que nadie ve el sentido económico de las cosas? ¿nadie se pregunta por qué se abordan desarrollos bastante gordos en PHP? ¿por qué hay COBOL para la JVM? La respuesta queda como ejercicio para el lector. Pista: Sun y MS se han gastado un pastón en generar un mercado de programadores que conocen sus lenguajes "preferidos" (Java/C#) Excepto para llamar código ajeno, lo demás son florituras (y se que este último punto no es muy cierto, pero lo dejo sólo por chinchar)...
Que a gusto se queda uno...
sabia que alguien no iba a ver cuando dije esto: "Ojo, no me refiero que se puedan hacer instrucciones C++ en Java", depronto no se entendio, pero me referia a NO mezclar dos lenguajes.. guaarr da ganas de vomitar solo pensar en eso.
Mezclar dos lenguaje es una muy mala pesadilla, es mas algo parecido a como hace JRuby o Jyton que permiten utilzar codigo echo en JAVA (es decir, bycode, .class, los jars, NO EL LENGUAJE). Pero en vez de Ruby/Java o Python/Java, seria C++/Java
bueno ahora me acorde de JNA (Java Native Access), por ahora es lo mas facil para usar codigo nativo desde java, porque puedes invocar directamente los metodos que exportan las DLLs o los SOs pero no es lo mismo :D jeje
La idea me parece correcta. Llamar igual a la tecnologia y al lenguaje, limita y confunde a los usuarios (de la tecnologia y del lenguaje). Hay muchos lenguajes que se utilizan para producir código nativo de una máquina X, por que no puede pasar lo misma para una máquina virtual, o para la VM de Sun... Eso si mezclar lenguajes de alto nivel en una misma unidad de compilación/interpretación, es feo (a mi modo de ver).
Yo es que como la opcion de JNI (tediosa pero ahi esta), JNA, JNIEasy... etc. ya están y luego leyendo esto:
es lo unico que le envidio a .NET (C++/CLI) que permite mezclar codigo nativo con codigo manejado en el mismo archivo de codigo fuente.
Pues de ahí lo entendí ;).
Lo que si parece una tendencia clara es, por un lado, poder mezclar lenguajes a nivel de libreria. Seguro que alguno de ahi saca usar varios lenguajes en el mismo proyecto a lo bruto, pero ya se las compondra. La idea en cambi, me parece a m, es mas, por ejemplo, poder utilizar desde Quercus (PHP sobre la JVM) los drivers JDBC/Datasources para poder acceder a cualquier BDD accesible desde Java y con sus pools etc. sin tener que re-escribir el codigo en PHP. Y que además, no hay que hacer otra MV para PHP desde cero con su GC, su Hotspot...
Uno de los puntos fuertes de Java hoy en día es la cantidad de librerías que tiene para muchas cosas y lo eficiente que ha acabado siendo su MV. Pero el lenguaje no es a gusto de todos ni adecuado para algunas cosas... pero optar por otro lenguaje hasta ahora significaba renunciar a las librerias y la MV, y eso es lo que se esta cambiando. Pero Java se seguirá utilizando mucho tiempo por que sigue siendo adecuado para muchas cosas, hasta que lo sustituya algo que cubra ese hueco.
Creo que es bueno que se pueda usar mas de un lenguaje...y ademas siempre se pudo, no tenía mucho éxito. Alguien dijo que usar varios lenguajes en un mismo proyecto es suicida. Ahora, en la práctica, cualquier proyecto web decente se hace en varios lenguajes: Java, HTML, javascript, SQL...se que uno podría hacer java puro usando GWT (por ejemplo)..e hibernate para persistencia....pero es muy dificil cuando hay partes "legacy" en el proyecto. En mi experiencia, todos los proyectos incluyen algo en otro lenguaje.
Y como programador de c#, lo único que le extraño cuando estoy en Java (aparte de alguna mejora de sintaxis) es el pinvoke. Obvio que es mas fácil para M$ que para SUN hacer eso, pero a esta altura alguno debería copiar el sistema de pinvokes.
No estamos hablando de usar lenguajes diferentes para distintas cosas en el mismo proyecto, estamos hablando de usar varios lenguajes para la misma cosa. De la misma forma que uno no suele hacer la mitad de su logica de negocio accediendo con Hibernate, la otra con Ibatis y luego un poco mas alla JDO, pues igual. Pero combinar varias cosas esta claro que si. Es mezclar sin ton ni son lo que no tiene sentido, ni ahora ni antes.
En cuanto al pinvoke... pues como no se lo que es, seguro que no lo echo de menos :).
Segundo Anónimo: "Puntualización por lo poco que se .Net no tiene clousures, lo mas cercano que tiene es funciones lambda. Que tiene "cierto" parecido pero no es ni de largo lo mismo (de echo ¿será un subconjunto uno del otro?). A parte de eso en la última versión también metieron otras ñapas intentando imitar a los lenguajes dinámicos, pudiendo añadir a una interfaz nuevos métodos."
Tienes razón, es poco lo que sabes de .Net. .net como plataforma sólo tiene delegados que son referencias a métodos, los lenguajes para .Net son los que implementan o no closures. Si te referías a C#, las funciones almbda de C# 3.0 sólo son simplificaciones sintácticas de los delegados anónimos que existen desde la versión 2.0, y que sí son verdaderos closures porque capturan las variables de su entorno sin tener que pasarlas como parámetros. Tampoco se pueden añadir nuevos métodos a una interfaz como en Python, sino más bien al estilo de Groovy, la interfaz, o clase, sigue intacta mientras que es al método (método de extensión) al que se le indica como primer parámetro a qué clase o interfaz va a extender. Pero esto es sólo para que un método estático se vea sintácticamente como si fuera un método de instancia de la clase o interfaz.
Greeneyed:
No se como va a ser en Da Vinci, pero en .Net no puedes mezclar varios lenguajes a nivel código fuente, sólo a nivel de librerías compiladas cada una en su lenguaje. Es cierto que si se abusa de esto el mantenimiento de los proyectos se vuelve un caos, pero te da la libertad de elegir entre varios lenguajes y estandarizar el desarrllo con ese mismo. Por ejemplo en mi empresa usamos sólo C# y conozco otras donde utilizan sólo VB.Net y otras donde sólo utilizan Delphi.Net, pero en niguna mezclamos los tres lenguajes.
He mirado en google y pinvoke es invocar servicios de la plataforma (me imagino que llamadas al sistema operativo y cosas así).
Respecto a los comentarios, estoy de acuerdo de que sólo es útil tener varios lenguajes cuando se complementan y ofrecen cosas distintas (SQL, JavaScript, Java, etc). Por eso, yo veo útil tener varios lenguajes cuando me ofrecen cosas distintas y puedo elegir entre uno y otro para distintas partes de mi aplicación, por ejemplo escribir la configuración de mi aplicación o desarrollar un prototipo rápido de algún elemento o capa de una aplicación con un lenguaje como JPython y que compile a Bytecode, o incluso escribir las reglas de negocio en un lenguaje específico que sea tan sencillo y claro que hasta un usuario pueda validar el propio código. Todo eso ya existe, pero si el compilador es capaz de generar bytecode nos ahorramos los intérpretes y ganamos en rendimiento.
De todas maneras la propia Microsoft también ha jugado a la inversa, creando un único lenguaje común de consultas (el LINQ) con pobres resultados (hablo de oidas de otros compañeros que trabajan 100% en dotNet).
Si con soporte multilenguaje tenemos una máquina virtual mejor y más eficiente, bienvenida sea. Me imagino que si los lenguajes son de propósito general como Java, entonces, el 99% de la gente usará un único lenguaje.
Rincew
A lo mejor así se puede arreglar la genericidad chapucera que han implementado en Java ¿o no tiene nada que ver?
Genericidad chapucera???
Explicate por favor
Está implementada por borrado porque la MV no entiende de genericidad realmente, a diferencia de .NET que sí implementa genericidad de verdad, a costa de perder compatibilidad hacia atrás, claro. Para la MV, List sigue siendo List por mucho que tú en el código fuente pongas List. Un artículo interesante es http://gafter.blogspot.com/2006/11/reified-generics-for-java.html
Falta algo arriba...
"por mucho que tú en el código fuente pongas List < Manzana >"
Escribe tu comentario