La Fundación Eclipse lanza su lenguaje para la JVM: Xtend

Me gusta ....en serio me gusta. Sobre todo por Eclipse, desde que lo manejo he dejado un poco el NetBeans.

Es bonito/curioso encontrar similitudes entre Xtend y Ryz ( y otros NJVMPL ) , pero no son coincidencias fortuitas, más bien creo yo que tienen muchísimo sentido en el contexto de que es claro lo que le sobra a Java y también es claro lo que hace atractivo a otros lenguajes. Entonces estas similitudes son el resultado de esas deficiencias.

Por ejemplo ( y sin ánimo de robarme el hilo ni nada ) los métodos de extensión. En ambos, si un objeto no responde a un mensaje y se encuentra en el scope un método que reciba como parametro al objeto, entonces se puede utilizar como método del objeto ese método ( diablos creo que por ser preciso me vi algo difuso )

Entonces si tenemos la clase persona:

Que no tiene la función "fullName" ( en Xtend se llaman funciones y no métodos, que es básicamente lo mismo , pero no es igual ) y si la intentaramos usar nos marcaría error de compilación.

Pero si se define una función con ese nombre que reciba a una persona como parametro se puede usar como método de extensión:

Y este ya se puede usar, así de simple

En Ryz es básicamente lo mismo.
 

Este feature lo tiene C# desde hace mucho y Scala tiene algo similar pero más potente ( hace una transformación de tipos ). Otros lenguajes como Ruby o Python ( y probablemente Groovy ) no lo necesitan porque en ellos se puede escribir un nuevo método para una clase existente:

Otra coincidencia es que en Xtend y en Ryz el modificador de acceso por omisión para los atributos es   y para los métodos y classes es  .

Este tipo de cosas han sido comunes porque resulta atractivo tenerlas en otros lenguajes y Java mismo no las va a incluir ( y que bueno ) pero van dando pie a que otros lo hagan. Xtend tiene varias otras características interesantes como lo "dispatch functions" pero luego que sepa bien de que se tratan les cuento.

Una nota importante a recalcar es que Xtend surge aparentemente de un proyecto de Eclipse llamado Xtext que es un framework precisamente para hacer lenguajes de programación. Básicamente tiene las herramientas para hacer y definir todos los elementos del lenguaje en una aplicación basada en eclipse y como tal el resultado final puede además del producto original del lenguaje ( .class, archivos .java, o whatever ) un IDE listo para el lenguaje mismo.

Dicho en otras palabras, Xtext te permite crear el lenguaje y el IDE al mismo tiempo. Eso esta muuuuy interesante y al parecer Eclipse está consumiendo su propia comida de perro con este lenguaje.

No estoy muy seguro que Jetbrains haya hecho lo mismo ( es decir, no hay nada que lo evidencie , no necesariamente que demuestre que no lo hicieron ). A lo que me refiero es que desde hace también mucho tiempo Jetbrains tiene también un producto llamado MPS ( meta programming system ) que tarmbién permite escribir herramientas de lenguaje ( como un compilador ) y te da el IDE el mismo tiempo. Supongo que Kotlin surgió de ahí, pero ... quién sabe.

Yo estuve revisando estas dos herramientas cuando estaba empezando con Ryz pero aunque facilitan el desarrollo de aplicaciones de lenguaje, al final lo que me faltaba era tener fundamentos teóricos y mucha, mucha paciencia, así que yo me fui como el Borras, y empecé a hacer mi trabajo a mano.

En fin. Que bueno que existan estos esfuerzos.

Por cierto si alguien quiere hacer algo realmente interesante y quiere aventarse la implementación del algoritmo de Hindley–Milner para la inferencia de tipos en java, que me avise y yo la incluyó en Ryz :) :)

Por cierto, la razón por la cual genere .java en vez de .class es para poderlo usar en otros ambientes no Java ( o que no usan Java bytecode ) como Android y GWT. Interesante no?

Pues, francamente no veo que proponga algo sustancialmente diferente o novedoso, como que lo veo muy enfocado a que sea sencillo y fácil (hablo de Xtend, no te calientes).

En javamexico poco se discute sobre el desarrollo de software basado en modelos y de su importancia en el mundillo del software.
Al comentar sobre Xtend conviene que aquellos interesados "acudan" a lo mucho de lo que hace Ecilpse para fomentar todo lo relacionado con MDA (Model Driven Architecture) y MDD (Model driven Development). Xtend es parte de esas tecnologías basadas en modelos, aunque no lo parezca.

Hace ya unos cuantos años, Eclipse comenzó con el proyecto "Eclipse Modeling Project", que se dedica a fomentar las tecnologías de desarrollo de aplicaciones basadas en modelos, lo que es algo muy importante y que debe ser conocido por todos los que cortan código.

EMP (el acrónimo de Eclipse Modeling Project) trata de unificar un conjunto de tecnologías que basan parte del desarrollo de software en la creación de modelos, y a partir de ellos generar parte de los recursos (fuentes, configuraciones, etc.) que la aplicación final tendrá. Es necesario leer un poco sobre MDA y MDD para entender todo ese rollo. De otra manera, uno puede perderse por la cantidad de cosas relacionadas con la modelación que EMP cubre.
Son varias las "formas" que EMP utiliza para documentar todo lo que contiene y hacernos la vida más fácil para poder utilizar el chingo de cosas que en estos momentos tenemos disponibles con Eclipse.

EMP describe los grupos siguientes de técnicas y herramientas:

• Desarrollo de sintaxis abstracta
• Desarrollo de sintaxis concreta
• Herramientas para modelar
• Transformación de modelos
• Técnicas de modelación generativas
• Integración de Modelos

Cada uno de estos grupos incluyen un conjunto de técnicas y herramientas para la modelación y la generación de código a partir de modelos. En el grupo de desarrollo de sintaxis abstracta se incluye a EMF (Eclipse Modeling Framework) y varios de sus acompañantes. EMF es el marco de trabajo de modelación y generación de código en clases de Java más conocido de EMP y que se incluye en la distribución de Eclipse.
En el grupo de Desarrollo de Sintaxis Concreta está TMF (Textual Modeling Framework) para el desarrollo de sintaxis textuales y sus editores correspondientes basados en EMF. Parte de TMF es Xtext para diseñar DSL's textuales basados en EMF.
Xtext es un marco de trabajo con sus correspondientes herramientas para crear DSL´s externos. Describimos la gramática del DSL que deseamos con la gramática EBNF. Con el generador creamos el parser,el modelo de sintaxis abstracta implementado con EMF y el editor de texto en Eclpise para el lenguaje generado.
La versión actual de Xtext incluye lo necesario para generar lenguajes destinados a correr en la máquina virtual de Java (todo el mundo reconoce lo bueno).
Con Xtext y Xbase se diseña Xtend, que Eclipse lo define como un lenguaje template de tipado estático destinado a generar código de Java para ejecutarse en la JVM.
Coincido con benek que en estos momentos incluye cosas "sencillas", aunque es bueno mencionar que se trata de uno de los proyectos de EMP que está mereciendo mucha atención.
Tiene entre sus competidores varios lenguajes para la máquina virtual que ofrecen lo mismo y muchas más cosas.
Creo que echarle un vistazo es saludable. Varias de sus cosas ayudan a entender mejor la programación orientada a objetos. Una de ellas, la de dar soporte al despacho múltiple ayuda a madurar algunos conceptos importantes de OOP.
De resultar interesante este post, escribiré algo sobre EMF, en particular el uso de ATL (Atlas Transformation Language) para transformar modelos.

.... Son varias las "formas" que EMP utiliza para documentar todo lo que contiene y hacernos la vida más fácil para poder utilizar el chingo de cosas que en estos momentos tenemos disponibles con Eclipse"

Coincido en que puede ser muy interesante conocer sobre el desarrollo basado ( o dirigido por) en modelos y conocer/usar las herramientas que provee Eclipse.

El desarrollo guiado/dirigido por modelos es una metodología de software que promueve la calidad en el diseño y desarrollo de software.

A veces por desidia (y/o por que nos "urge terminar" un proyecto) preferimos escribir código lo más rápido posible sin realizar un previo análisis de requerimientos, pruebas de calidad, diseño de modelos, etc. y nos "saltamos" el uso (o algunos pasos esenciales) de la metodologías de desarrollo.

O peor aún, ni las conocemos y creemos que nunca nos servirán.

Esta deliciosamente dulce la azucar sintactica de Xtend (que por cierto creo que tiene un nombre que le encantara a a la empresa donde trabajo), pero creo que la verdadera estrella es Xtext.

Me pregunto que tan mas facil es hacer algo mas raro.. como por ejemplo un compilador Rel a SQL usando Xtext... O inclusive un Rel a JVM... Me pregunto que tan poderoso y facil de usar es comparado con algo como Antlr

Ya tomando en cuenta lo que dicen del modelado, pues tal vez habrá alguna justificación posterior cuando el lenguaje ya sea algo más completo, pero la verdad así como está actualmente, no me parece algo bueno.

En G+ terminamos bferro y yo (entre otros) discutiendo acerca de lenguajes JVM (qué raro). Unos abogaban por Groovy, que yo opino que es una buena opción para empezar a probar otros lenguajes Java porque la curva de aprendizaje puede ser tan empinada o tan planita como uno quiera. Pero ya que uno ve Groovy como un lenguaje, "the big picture", pues tiene varias cosas que no tiene Java: es dinámico, tiene closures, metaprogramación, son sus principales características. Compila directo a bytecode pero hay cierta interoperabilidad.

Por su parte bferro opina que por ejemplo Scala, si vas a aprender Scala, pues mejor te saltas Groovy y te metes directo a Scala. La razón es que si aprendes Groovy tal vez ya no te interese aprender Scala, probablemente por lo mismo de la curva de aprendizaje, porque para Scala sí hay que hacer cambios de paradigmas y aprender varias cosas nuevas (sobre todo con las colecciones, de entrada, y mucho de la sintaxis). Si además pensamos en la adopción de uno de estos lenguajes en la industria, yo creo que Scala ha tenido menor adopción por la dificultad inicial para aprenderlo. Con Groovy el principal argumento en contra es generalmente el desempeño, pero con cada versión que sacan, y las sacan seguido, esto es un tema cada vez menos importante porque el desempeño de Groovy continúa mejorando y para la versión 2.0 habrá varias optimizaciones que permitirán ya dejar atrás esa discusión/preocupación/pretexto del desempeño.

Pues bien, siguiendo esa línea, yo creo que Xtend puede hacer más daño que beneficio respecto a la adopción de otros lenguajes JVM. Dado que no compila a bytecode sino a código Java, puedo perfectamente imaginarme empresas donde los programadores actualmente están pidiendo la oportunidad de probar otros lenguajes JVM como Groovy y/o Scala, y que la empresa por diversas razones se resiste, y de repente ven Xtend... es más fácil decirles a los programadores "orale, quieren usar otro lenguaje" pues usen Xtend, total, se compila a Java así que si uno de ustedes programa en Xtend y luego se larga, compilaremos su código a Java y los demás lo modificarán a partir de ahí; no pasa nada. Ya no hay necesidad de que quieran meter cosas no-enterprise como Groovy y Scala, que son mafufadas que sólo ustedes van a conocer y después vamos a sufrir mucho aquí encontrando quién pueda leer ese maldito código tan extraño escrito en lenguajes esotéricos".

Y además, si el lenguaje simplemente se traduce a Java (porque ya incluso "compilar" me suena un poco glorificado en este caso), entonces no puede ofrecer nada que Java no tenga. Es, como dice luxspes, un montón de azúcar sintáctica; si lo usan nomás se van a empalagar.

Ahhh y porque no invitaron a esa discusión? Será porque los tengo el el círculo de "Dudes a ir a golpear en taxi?" :):):) En fin.

Todo es finalmente azúcar de otra cosa, si se requiere compilar a bytecode basta ponerle una capita más de pintura ( chale ya sueno a non-programmer / architect ) y dejar que el producto en vez de escribir .java nomás escriba bytecode, no hay mucha diferencia en realidad.

Por ejemplo si se toma el compilador de Scala y se habilita la opcióoooon.... la opciooooon... mmhh no la tengo a la mano un compilador de Scala, pero hay una opción tipo   o algo así ( ver las opciones extra ) que va imprimiendo todo el trabajo intermedio del compilador y va mostrando como esas toda esa magia de inferencia de tipo y demás se va convirtiendo en algo más parecido a Java. Creo que en la versión anterior o antes de esa 2.6 o 2.7 por ahí lo que generaba al final era un archivo .java plano y puro donde la ultima fase era finalmente pasar a bytecode.

En fin, que el punto es que todo es azúcar de otra cosa hasta llegar a los rayos cósmicos que cambian los bits en el disco duro y no es tan descarado llamarle compilador a algo que escribe .java ( lo mismo dirían quizá los hardcore de C del compilador de Java por ejemplo, al no escribir directamente a ensamblador )

Sobre la adopción en la industria creo que el factor decisivo es el producto en el que se pueda usar ese lenguaje. Por ejemplo, Scala tomo muchísima relevancia cuando Twitter lo empezó a usar fuertemente. PHP con el web1.0, C con UNIX, bueno, hasta Objective-C que duró 10-15 años en letargo resurgió con el advenimiento del iPhone, JavaScript ... ni se diga. Es ese tipo de cosas las que le hacen falta a un lenguaje para tener adopción. La otra parte importante es el mérito técnico, pero en realidad no creo que fuera decisivo. Si el día del mañana alguien utiliza Haskell ( o SML ) para una industria nueva ( como nueva fue la industria web o iOS ) entonces seguro que ese lenguaje de adoptará , sin importar que tan difícil parezca, pero es precisamente por esta falta de cosas, que lenguajes tan buenos como Smalltalk no son mainstream.

Total que malo malo que venga uno nuevo, no es. Lo malo sería en todo caso estar forzado a usarlo. Por ahí tiene algo interesante de dispatch functions que peude tener algo novedoso.

@luxpes yo hice un ejercicio para hacer un lenguaje de programación hola mundo con Xtext y después de un rato de estarle ahí dando ( tampoco fue mucho, soy muy impaciente ) abandoné el esfuerzo. Quizá es porque entonces me faltaban fundamentos y no entendía varias cosas.

La discusión comenzó en un post de Pedro Galván acerca de lo que él consideraba las top 10 tecnologías que todo programador debe conocer (incluyó Groovy pero no Scala, o Scala pero no Groovy, no recuerdo).

Si, sí, todo es azúcar de otra cosa, pero en términos prácticos, sin tonterías bizantinas de que si C es azúcar de ensamblador y ensamblador es azúcar de bits y los bits son azúcar para impulsos de voltaje... no dije que fuera malo, nada más que no le veo realmente una ventaja a Xtend, más allá de escribir menos código. Pero eso me lo ofrece ya Groovy. Inmutabilidad por default, inferencia de tipos? Scala. Si Xtend ofreciera además closures y tipado dinámico, o funciones de primer nivel, no estaría ofreciendo nada que otros lenguajes más maduros ya nos ofrecen hoy.

Creo que no me estoy explicando bien, en fin. La bronca que le veo a Xtend es que parece que su mayor atractivo es que compila a Java, su mejor característica es que es más breve de Java, y ya. Qué bueno que haya una opción más, pero qué mal si alguna empresa o equipo de desarrollo o incluso un programador por su cuenta, estaba tentado a probar las mieles de otros lenguajes para JVM, y en vez de Scala o incluso Groovy (o Clojure, o JRuby), decide probar Xtend porque se ve más fácil y tiene "rueditas" (como cuando aprendes a andar en bici) porque compila a Java y no a bytecode. Y luego ahí se queda; no hubo cambio de paradigma, no hubo ventajas adicionales, nada más hubo la ilusión de cambiar de lenguaje cuando realmente sigue siendo Java.

El mundo de los lenguajes de programación se asemeja cada vez más a la corte del Rey Arturo; inventar cada día alguna novedad para mantener a los caballeros entretenidos.
Coincido con luxspes (extraña coincidencia) en que lo importante es Xtext. Así lo expresé en mi primer aporte a este hilo. Pero al entrarle a Xtext te percatas entonces que lo verdaderamente importante es EMF y la posibilidad de generar lenguajes a partir de modelos ( en este caso modelos textuales con Ecore).
Coincido también con lo que comenta ezamudio, aunque estoy casi convencido ( nadie me lo ha dicho) que una de las intenciones de Xtend, más allá de ofrecer un DSL a lo Java, es llamar la atención de los desarrolladores de Java a acercarse un poco más al campo del desarrollo basado en modelos.
A ver si me animo y escribo algo sobre EMF.