style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">

Primeras impresiones de Ceylon

Como bien saben, hace un par de días contamos con la presencia de Gavin King en las Opentalks, hablando de Ceylon, un nuevo lenguaje de programación que en el que ya lleva cerca de 3 años trabajando. Es un proyecto prioritario dentro de RedHat, pues la intención es tener un nuevo lenguaje de nivel enterprise que sustituya a Java.

Esto no es una reseña del evento; quiero enfocarme a hablar del lenguaje Ceylon, algunas de mis impresiones en este primer contacto que tuve (porque la verdad, no había tenido tiempo de meterme a fondo, más allá de ver aquellos slides que se habían filtrado hace unos meses de una conferencia en China o no sé dónde). He estado pensando acerca de si es mejor hacer una comparativa con otros lenguajes o simplemente hablar de las características de Ceylon sin hablar de ningún otro lenguaje, más que acaso Java, ya que finalmente será un lenguaje que funciona sobre la JVM. Y pues creo que habrá momentos para hacer comparaciones y otros donde es mejor sólo hablar de Ceylon.

Razón de ser

Ceylon surge por razones muy similares a las que han salido otros lenguajes para JVM: Java está evolucionando muy lentamente, se ha vuelto más complicado cada vez, hay que escribir demasiado código para realizar tareas simples, etc. Pero a diferencia de otros lenguajes, la intención de Ceylon es tener adopción a nivel enterprise; es un lenguaje pensado para hacer sistemas grandes con equipos de desarrollo grandes (varios integrantes trabajando sobre una misma base de código, etc). Una consideración importante en el diseño de Ceylon es la legibilidad, tomando en cuenta que en desarrollos grandes, un programador generalmente pasa más tiempo leyendo código ajeno (y propio) que escribiendo código. Por eso es que la legibilidad es una característica muy importante.

Algo que influye mucho en el diseño de Ceylon ha sido aprender de errores pasados con Java, tanto en el diseño como en la práctica. Java ya tiene suficiente tiempo en la industria como para saber muy a detalle cuáles son los principales problemas en muchos sistemas, las trampas y malas prácticas en las que suelen caer los programadores, etc. Pero también se queda con lo bueno, no sólo de Java, sino de otros lenguajes no sólo de la JVM (ya será otro tema a discutir si ciertas características son tomadas directamente de otros lenguajes o simplemente forman parte de Ceylon como resultado de hacer un buen diseño). Veamos, pues, las principales características de Ceylon:

Características de Ceylon

  • Tipado estático - Ceylon utiiza tipos estáticos, porque esto permite atrapar muchos errores al momento de compilación. Pero el sistema de tipos es bastante distinto del de Java por varios detalles que veremos a continuación.
  • null es un tipo estático - A diferencia de Java, donde null es simplemente una palabra reservada para denotar una referencia a un objeto que realmente no apunta a nada, en Ceylon es un objeto de un tipo determinado y hay ciertas reglas para que un objeto pueda ser nulo.
  • Tipos opcionales - Por default, al definir un valor o variable, no puede ser nula, a menos que se indique así en su declaración (la sintaxis para esto es ponerle una interrogación después del tipo, para indicar que la variable podría en algún momento ser nula). Las variables no marcadas como opcionales, no pueden ser null nunca (el compilador marca un error si detecta que se quiere pasar null o podría recibir null en algún momento). Y cuando se trabaja con valores opcionales, siempre se debe dar una alternativa en el código para manejar el caso de que el valor sea nulo, de lo contrario el código no compila.
  • Colecciones vacías - al trabajar con colecciones, éstas indican si permiten estar vacías o no; esto permite que el compilador nos indique errores cuando queremos tomar un elemento de una lista que puede estar vacía, para evitar problemas en tiempo de ejecución.
  • Validaciones - el lenguaje contiene validación de precondiciones para ciertos bloques. Es algo más sofisticado que simples asserts.
  • Unión e intersección de tipos - esta fue una de mis características favoritas. En Ceylon puedes hacer declaraciones usando uniones o intersecciones de tipos. Por ejemplo, tener una variable tipo Runnable&Serializable que solamente puede hacer referencia a objetos que implementan ambas interfaces, o tipo String|Int que entonces puede hacer referencia a un entero o una cadena. Esta característica es tan importante que influye en algunas otras cosas del lenguaje, como poder tener colecciones heterogéneas, no necesitar sobrecarga de métodos, etc.
  • Todo es un objeto - no hay tipos nativos. Ya el compilador podrá hacer optimizaciones para manejar algunas operaciones con tipos numéricos usando nativos, pero a nivel código, todo es un objeto.
  • Inmutabilidad - por default, todo es inmutable. Más que definir variables, se definen valores; se les asigna un valor al momento de declararlos y ya no se pueden modificar después. Para marcar una propiedad como mutable, hay que usar la palabra reservada variable. Esto es algo importante pues influye en el diseño de aplicaciones, bibliotecas, y no sólo por temas de concurrencia: cuando una clase tiene un constructor que recibe algunos parámetros, dichos parámetros serán inmutables, no hay manera de darle la vuelta a esto; la razón es que si se construye un objeto con ciertos valores, dichos valores se consideran parte de la identidad de un objeto (similar a una llave primaria en bases de datos).
  • Visibilidad simplificada - Hay dos niveles de visibilidad: pública (marcada con la palabra reservada shared) y privada. Se considera que los otros dos niveles de visibilidad existentes en Java (package y protected) no tienen una utilidad real.
  • Sobreescritura de métodos - por default, los métodos de una clase no se pueden sobreescribir. Unicamente se pueden sobreescribir métodos marcados como formal, y para sobreescribirlos hay que declararlos en la subclase con la palabra reservada actual.
  • No hay sobrecarga de métodos - en Java podemos sobrecargar métodos, es decir, tener varios métodos con el mismo nombre pero que reciben distinto número de parámetros (o parámetros de distinto tipo). En Ceylon esto no se puede hacer, pero no es realmente necesario por dos cosas: se pueden declarar defaults a los parámetros de un método (eliminando la necesidad de tener varios métodos con distinto número de parámetros) y los tipos unión e intersección (eliminando la necesidad de tener varios métodos que reciben parámetros de distinto tipo). Un ejemplo típico es el método que recibe un URL y el que recibe un InputStream; al ver las implementaciones, generalmente uno termina llamando al otro (el que recibe un URL obtiene un InputStream y llama al segundo método); en Ceylon se declara un método que recibe URL|InputStream e internamente se maneja el caso de recibir URL para obtener el InputStream y continuar con la ejecución, en el mismo método.
  • Sobrecarga de operadores controlada - Ceylon permite la sobrecarga de operadores, de una manera controlada. Solamente se pueden sobrecargar ciertos operadores, por ejemplo suma, resta, multiplicación, división, pero para hacerlo, se necesita implementar una interfaz que define el método a implementar. Por ejemplo, la interfaz Summable define el método plus y con objetos que la implementan se puede hacer a+b. Pero no se puede implementar un operador <+|:-) (que realmente ni siquiera se podría considerar un operador; en realidad los lenguajes que permiten esto, lo que permiten es tener métodos con nombres que tengan casi cualquier símbolo, en ocasiones incluyendo Unicode). La razón para controlar la sobrecarga es asegurarse que en todo momento tenga sentido y que haya consistencia; el operador + debe usarse para sumar siempre. De lo contrario empiezan los problemas cuando una aplicación utiliza 3 librerías y las 3 tienen clases que implementan el operador + de manera distinta (una para agregar elementos, otra para escribir a un stream, otra para incrementar un valor, etc).
  • Inferencia local de tipos - Para mejorar la legibilidad es bueno evitar la redundancia, y esto de paso también sirve para escribir menos código. Por eso Ceylon tiene inferencia de tipos, cuando se declaran valores o variables. Pero la inferencia es únicamente local (cuando se declaran valores), para evitar problemas de desempeño en el compilador
  • Funciones de primer nivel - Ceylon permite declarar funciones en cualquier parte del código; dentro de una clase, afuera de una clase, dentro de un método, dentro de otra función... esto es algo muy de moda en lenguajes JVM recientes, curiosamente Gavin había omitido mencionar esta característica hasta que alguien preguntó, porque en su opinión esto es algo que todo lenguaje debería tener. Y por supuesto, las funciones se pueden pasar como parámetros a otras funciones, y puede haber funciones (y métodos) que devuelvan funciones.
  • Varianza y contravarianza - Cuando se usan generics, se puede usar varianza y contravarianza en las declaraciones de los tipos. Esto es con las palabras reservadas in y out. Pero antes que piensen que esto podría complicar mucho las cosas, deben saber que el manejo de generics en Ceylon es bastante más sencillo que en Java, donde se llegan a ver cosas como <?-capture-of-T> que nadie sabe qué significan. Nuevamente, esto en Ceylon se resuelve gracias a los tipos unión/intersección.
  • Patrón object builder - En Ceylon, el patrón object builder está integrado en el lenguaje. Se pueden construir instancias de objetos usando este patrón (muy popular en varias aplicaciones y bibliotecas de Groovy por ejemplo) y es código Ceylon válido. Para Gavin, esta es una de las características más importantes porque será la que evite muchísimo código al desarrollar ciertas partes de aplicaciones, tales como interfaces de usuario; incluso se puede usar para inyección de dependencias, evitando la necesidad de un manejador externo.

Lo que falta

Otras cosas que el lenguaje tendrá pero aún no cuenta con ellas, o son están incompletas aún, son anotaciones y módulos. La parte de módulos es muy importante, pues es un problema que no se tuvo contemplado al crear Java y por tanto cuando surgió, se crearon diversas soluciones, de las cuales la más conocida es Maven, que es famoso por su complejidad, sin embargo su manejo de dependencias es indudablemente el más utilizado en proyectos Java. Pero tiene muchos problemas aún; otra solución que surgió para problemas similares pero a otro nivel, fue OSGi, que también es algo bastante complejo.

Ceylon desde el inicio pretende contar con un sistema de módulos; no está claro aún cómo van a funcionar pero la idea es que cada módulo (contenido en un archivo CAR, por Ceylon ARchive, análogo a un JAR) contenga un descriptor indicando su versión y las dependencias con otros módulos (incluyendo sus versiones). Suponiendo que tenemos una aplicación que utiliza directamente dos módulos A y B, y que el módulo A utiliza un módulo C con una versión y mientras que el módulo B utiliza también el módulo C pero una versión distinta e incompatible de la que usa el módulo A, nuestra aplicación podrá usar estos módulos sin ningún problema porque el módulo A utilizará su versión del módulo C sin tener conflictos de que el módulo B utilice su propia versión del módulo C. Incluso la aplicación podría usar también de manera directa una tercera versión del módulo C sin tener problemas (hasta que comiencen a interactuar objetos del módulo C con los del módulo A, pero tal vez eso se pueda resolver al momento de compilar y no hasta tiempo de ejecución).

El lenguaje no está terminado aún, faltan varias cosas, entre ellas varios módulos básicos. Lo que se pretende es no tener un core demasiado grande, sino tenerlo todo bien modularizado. Incluso, el manejo de concurrencia no se tiene contemplado como parte del lenguaje, más allá de manejar todo como inmutable, sino que será delegado a módulos, para poder tener de entrada no solamente una manera de manejar concurrencia sino varias distintas. Seguramente a nivel muy bajo se seguirán utilizando Threads como en Java (esto es inevitable) pero esperemos que pronto haya mecanismos más avanzados como candados, thread pools, actores, memoria transaccional en software, etc.

Y como dijo Gavin: el éxito o fracaso de un proyecto como Ceylon depende en gran medida de la comunidad que se forme a su alrededor. Yo por mi parte pienso revisar periódicamente su progreso y tal vez, si el tiempo me lo permite, contribuir con algo.

Ligas

Página oficial de Ceylon

Especificación del lenguaje (en la parte de issues hay varios temas en los que se puede participar, para decidir cómo deberían ser ciertas construcciones del lenguaje

Ceylon en GitHub - el compilador, ambiente de ejecución, lenguaje, plugin para Eclipse, etc.

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

compilador!

Algo importante que olvidé mencionar es el diseño del compilador: está dividido en frontend y backend. El frontend procesa el código fuente de Ceylon y devuelve un AST (abstract syntax tree), y lo pasa al backend, que simplemente usa javac para convertir el AST en bytecode. Esto es interesante porque si bien fue la manera tal vez más rápida y sencilla de lograr un compilador reutilizando lo que ya se tiene a la mano, tiene algunas ventajas adicionales, como poder pasar ese AST a otro compilador, lo cual permitiría compilar Ceylon para otras plataformas (Android, .NET, etc).

Imagen de domix

Mi impresión

Gavin y RedHat saben lo que hacen, como bien lo mencionaste, se están enfocando a las empresas grandes, que tienen muchos proyectos y que seguramente se la pasan subcontratando a consultorias. Hay muchas cosas interesantes en Ceylon, lo del compilador "en capas" esta muy bueno, se podrá extender muy facilmente a otros lados.
En cuanto lo terminen y este listo y maduro veremos como lo adoptan las empresas. Tambien veremos nuevos productos de RedHat sobre Ceylon. Posiblemente nuevos frameworks de web, persistencia (tal vez una capa sobre Hibernate/JPA y JSF).
El futuro luce muy prometedor en ese ambito, al menos, mucho mas amplio. Gavin es un gran ingeniero y tiene mucha visión, ojalá la industria coincida con la visión.

Imagen de hguerrero

comments

Uno de los puntos que me parecen claves en la presentacion de Ceylon es precisamente el enfoque que le dio Gavin a la parte de mantenimeinto de software. Se que podemos desarrollar un ERP en otros lenguajes, pero aun no veo a las grandes consultoras haciendolo en este momento, por lo menos en Mexico. Ceylon, por lo que vi, buscara hacer una transicion a este tipo de software a los nuevos lenguajes de JVM. Java fue una solucion decente en su momento, pero definitivamente le urge un "extreme makeover" para dar el ancho a las necesidades que tenemos 20 años despues. Que tan facil puede ser la transicion? no tengo idea!

Imagen de Sr. Negativo

Impresión(es)


Es un proyecto prioritario dentro de RedHat, pues la intención es tener un nuevo lenguaje de nivel enterprise que sustituya a Java.

Algún día puede pasar ... que los programadores (y las empresas) fijen su mirada hacia otras altenativas más pometedoras.

.
Y como dijo Gavin: el éxito o fracaso de un proyecto como Ceylon depende en gran medida de la comunidad que se forme a su alrededor

Creo es lo más importante de un lenguaje más si que sea bonito, sencillo y barato. Que los programadores se animen a USARLO (¿se acuerdan de Jabaco ?).

mmm habrá que echarle un vistazo a este lenguaje.

Imagen de greeneyed

my POV

Gracias por la explicación. A mí es un lenguaje que me interesa, ya que sí lo veo como un candidato a reemplazar a Java a largo plazo. Así como otros lenguajes los veo como complementarios, éste está dirigido a sustituirlo y me alegra saber que se lo toman con pragmatismo, aprendiendo de lo bueno y de lo malo.

El problema de Java en este sentido, que por otro lado es una cosa buena, es todo el legado que ya tiene y que, desde un punto de vista empresarial, no puede desatender sin cometer un auto-suicidio. Para "hacer las cosas realmente bien" hace falta un lenguaje que empiece desde cero sin todo ese bagaje que arrastrar y que le pesa.

Al mismo tiempo, para sustituir a Java en su plaza fuerte, hace falta algo más que "ser guay" o "escribir con menos carácteres" etc. así que bienvenidos sean estos experimentos un poco más realistas. Dado que esta RedHat detrás, esperemos que llegue a buen puerto aunque no creo que Oracle se rinda sin pelear. Lo mejor para nosotros sería un acuerdo, pero con Oracle de por medio...

Imagen de Jvan

Yo también creo que Ceylon

Yo también creo que Ceylon tiene un gran potencial, tiene muchos puntos a favor (y esta respaldado por un peso pesado) y como lo mencionan antes, parece que la intención de Red Hat de remplazar a Java va muy en serio y qué bueno que existan estas iniciativas, lo que me da un poco de temor es que Oracle en su afán de querer mantener vigente a Java empiece a meterle tantas cosas a la rápida que terminen por hacerlo un frankenstein y sea un revoltijo de paradigmas, frameworks, etc.

Me gusta que para Ceylon se esté analizando lo bueno y malo de varios lenguajes y se tome lo mejor, que se enfoque al ámbito empresarial y que tengas disponible todo el código para verlo, descargarlo, etc. La parte del compilador en 2 partes que menciona ezamudio es una gran idea que podría darle un auge muy grande para hacerlo muy muy portable.

Ya veremos en algunos años que le depara el destino, por lo pronto nos mantendremos muy al tanto de este lenguaje.

Y que opinan de DART (lenguaje que está creando Google) que la intención es remplazar Javascript, aunque por ahí se dice que las verdaderas intenciones de Google es que DART sea un lenguaje tanto para el lado cliente como para el server (creo que podrás correrlo en los navegadores como javascript y aparte tendrá su máquina virtual), que sea multiplataforma y no solo eso, se menciona que podrían reescribir Android para deshacerse de demandas, y algunos otros dicen que con el poderío de Google podría impulsar a DART para desbancar a Java y darle un duro golpe a Oracle.

Como sea, la diversidad en la JVM está aumentando y eso me parece muy bueno, ya veremos cual lenguaje toma ventaja sobre los demás.

Imagen de bferro

Serie de artículos sobre Ceylon

En In relation To, sitio del blog de Gavin King y otros, disponemos de una serie de artículos( Introduction to Ceylon) sobre Ceylon.
Por lo pronto, la serie se compone de 12 artículos con una introducción excelente del lenguaje. Vale la pena leerlos

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">