¿Por qué Gavin King y Red Hat se aventaron el tiro de Ceylon en lugar de sumarse a Scala?

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 neko069

Y?

Luego? dónde están los participantes aquí?

En mis propias palabras

En mis propias palabras porque el mmhh como llamarlo, el enfoque que tiene Scala es para ser un lenguaje muy completo y que cubra muchísimos aspectos computacionales bajo una misma implementación aún cuando esta flexibilidad traiga consigo complejidad y una curva de aprendizaje más grande.

Ceylon por otro lado tiene un enfoque más pragmático donde lo relevante es la productividad y no tanto la "hyper" flexibilidad que el lenguaje pueda dar.

Aquí escribiría un ejemplo que involucraría por ejemplo String|Nothing de Ceylon comparado con None[String] de Scala y el inexistente equivalente en Java, pero para no confundir ( me ) más, lo dejo ahí.

Imagen de ezamudio

Distintas metas

Ceylon y Scala tienen distintas metas y distintas filosofías, distintas maneras de atacar algunos de los mismos problemas, y se enfocan a distintos problemas.

A muy grandes rasgos, Ceylon pone mucho énfasis a la legibilidad del código y a tener un sistema de tipos poderoso pero simple, para que sea entendible y por lo tanto se pueda aprovechar al máximo.

¿Por qué importa tanto la legibilidad? Pues porque la realidad es que pasamos más tiempo leyendo código que escribiéndolo. Incluso en un proyecto individual, hay que estar leyendo el código que uno mismo ha escrito, y conforme un proyecto crece, hay que leer más y más porque para cualquier modificación, ya sea corregir un defecto o agregar funcionalidad nueva, o modificar la existente, hay que saber exactamente qué código hay que modificar o dónde insertar nuevo código y eso implica estar leyendo código. Y ni hablar de proyectos en equipo, donde hay que estar leyendo código propio y ajeno.

¿Por qué importa tanto el sistema de tipos? Un buen sistema de tipos te facilita el diseño de componentes, le facilita al compilador la detección de errores, lo cual le permite al programador detectarlos más temprano en el ciclo de desarrollo. Pero si el sistema de tipos es muy complejo, será difícil de entender y de aprender, y por lo tanto los programadores no le sacarán el máximo provecho o incluso lo usarán de varias maneras incorrectas, generando errores de diseño que posteriormente son muy difíciles de detectar y por tanto de corregir.

Scala ha cobrado mucha popularidad en los últimos 2 años pero es un lenguaje que ya tiene varios años en desarrollo, y durante ese tiempo su complejidad ha aumentado muchísimo. Mi experiencia personal con Scala es que al principio me pareció una opción mucho mejor a Java, me gusta el tipado estático, me gusta la idea de poder aprovechar algunos conceptos de programación funcional (aunque en realidad no haga programación funcional), pero cuando quise usar Scala en un sistema real me empecé a dar de topes con varias cosas, algunas de las cuales creo que se podrán corregir en el futuro pero otras de plano ya no. Por ejemplo, el hecho de que haya N maneras distintas de hacer lo mismo, al principio es muy atractivo, pero luego ya no sabes ni cuál es mejor, y si ves código ajeno ya no sabes por qué hicieron las cosas de esa forma, no es fácil determinar si es la manera óptima o simplemente son diferencias estilísticas (y honestamente estar analizando si sólo es cuestión de estilo al escribir código, me parece una pérdida de tiempo). Luego la sintaxis que al principio era tan atractiva, se empieza a tornar en una pesadilla cuando de verdad ya ni sabes por qué algo no compila, y peor si el compilador tarda tanto en procesar tu código. Incluso con ayuda de un IDE luego ya no sabes por qué una cosa compila y otra no, cuando según tú debería de compilar, pero pues resulta que con tantas variantes en la sintaxis de plano el compilador se hace bolas, llegaste a un caso marginal y tienes que escribir esa parte de otra forma para que compile (ya luego habrá que ver si funciona).

Y luego empiezas a pelearte con el SDK, especialmente con las colecciones... por qué hay tantas interfaces que al parecer hacen lo mismo? No hay documentación clara al respecto. Cuál es la diferencia entre Iterable, Traversable, TraversableOnce, Seq, List, IndexedSeq, etc etc etc etc? y luego para cada una de esas cosas hay dos versiones, la mutable y la inmutable, pero casi todas tienen una tercera que es como abstracta, en fin.

Y por último, una de las cosas que parecen muy padres pero rápidamente pueden tornarse en un problema sin solución: los implicits. Visto de manera simple, tú puedes meterle métodos a clases existentes sin tener acceso a fuentes. Puedes meterle un método "join" a la clase String. Pero para qué ponerle join? mejor le ponemos ~+~ porque así el código se ve mejor, porque parece que el objeto está tomando de la manita al parámetro, wow! A ver quién le entiende a eso cuando vea tu código... y luego no sabes por qué tu código "x"~+~algo ya no compila, te da un error rarísimo... ah resulta que estás usando un componente de una biblioteca que conseguiste porque te recomendaron en un foro, y resulta que al importar algo de esa biblioteca, sin saber ahí también viene un implicit que le mete el método ~+~ a String... pero después del tuyo, entonces esa implementación literalmente se plancha a la tuya, pero el error no lo deja muy claro, y pierdes horas en encontrar la razón (o simplemente nunca sabes qué pasó, pero en una de tantas iteraciones de prueba y error, decidiste renombrar tu método a unir y mágicamente ya todo funcionó otra vez).

En fin, si quieres razones de por qué concretamente no estamos todo el equipo metiéndole mano a Scala, creo que ahí están. Y no soy el único en el equipo que piensa que Scala ya no necesita que le metan más cosas, sino que al contrario, ya hay que quitarle algunas. El mismo Odersky este año ya dijo que le van a empezar a quitar algunas cosas porque ya está demasiado complejo...

Pero más allá de eso, la razón de ser de Ceylon no gira alrededor de Scala, ni de ningún otro lenguaje; ni siquiera de Java. Ceylon toma las ideas que son buenas de otros lenguajes, sean de tipado estático o dinámico, y también propone cosas que no hay en ningún otro lenguaje (los tipos unión e intersección son algo nuevo), o que no son parte oficial de una plataforma (como el sistema de módulos, del cual no he escrito aquí pero es realmente algo que va a quedar muy fregón).

Espero que ya pronto sean las siguientes OpenTalks para poder realmente explayarme en el tema.

Imagen de bferro

La necesidad de crear algo nuevo

Pueden encontrarse muchos argumentos técnicos para estar a favor de crear un nuevo lenguaje. Yo en lo personal creo que una de las razones fundamentales es la "inquietud innata" de gente muy creativa como Gavin (Seam, Hibernate, Web Beans, etc.) de crear algo nuevo.

Imagen de ezamudio

pero...

Sí, bueno, la razón de fondo generalmente es la inquietud innata del autor, pero si no hay validez técnica y nadie más apoya la idea, no pasa de ser un "pet project".

Cuando una empresa apoya financieramente un proyecto así es porque le encuentran algo de valor; no van a destinar fondos simplemente diciendo "ah sí, déjenlo que haga lo que sea a ver qué sale". Y también si otras personas deciden entrarle al proyecto es porque le ven algo de valor, no porque les sobre el tiempo o no tengan nada mejor que hacer... lo interesante es esa definición de valor, que va a ser diferente para cada quien...

Gracias por sus comentarios

Pues gracias por sus comentarios.

Me ayuda a aclarar la duda del porque, entiendo lo de la complejidad de Scala y de hecho es una queja que ya había visto reflejada en otros foros.

Habré de seguir el desarrollo de Ceylon ya que aún estoy con la impresión de que hoy está bien para experimentar, pero si quiero hacer el tipo de aplicaciones que suelo hacer (aplicaciones empresariales) pues hay que seguirle con Java y su vasto ecosistema.

En ese sentido Scala ha madurado hasta un punto tal que también podría utilizarlo para hacer ese tipo de aplicaciones.

Es interesante ver que haya alternativas, en el linaje de Java, que compitan con la tiranía de Oracle, bien por ustedes.

Gracias por sus comentarios.

Reciban un cordial saludo

J. Reynaga

Otra pregunta provocadora

Siendo que Ruby es un lenguaje que busca también ser amigable para el programador, y que ya existe una larga experiencia con él y ha sido muy exitoso en los últimos años con RoR.

¿Por qué RedHat se avienta el tiro de hacer un nuevo lenguaje con Ceylon en lugar de empujarle a Ruby y a TorqueBox?

No son ganas de embromar, solamente quiero conocer los puntos de vista de la comunidad desarrolladora.

Saludos cordiales

J. Reynaga

@jreynaga Por el tipado

@jreynaga Por el tipado estático básicamente

Imagen de ezamudio

tipado estático

JRuby y Groovy son dos lenguajes para la JVM que ya tienen bastante popularidad y son muy buenos, pero son de tipado dinámico. El tipado dinámico es muy cómodo para trabajar pero básicamente te llevas todos los problemas a tiempo de ejecución: que si un método no existe, que si esa clase no responde a él, que si recibe 3 parámetros y le mandaste nomás 2, que si el tipo de retorno es otra cosa, etc. Por eso es tan importante hacer pruebas unitarias, y eso aplica sin importar el lenguaje que uses, pero a mi algo que no me gusta de Groovy es que hay que probar hasta lo más básico porque luego por un error tipográfico (si se te va y estás invocando objeto.toSting() por ejemplo) tu aplicación truena en tiempo de ejecución.

El tipado estático te permite detectar muchísimos problemas en tiempo de compilación, pero si el sistema de tipos es muy complejo, esa ventaja se puede convertir en una desventaja, cuando llegas a pasar más tiempo peleándote con dicho sistema que realmente haciendo algo con un fin específico. Y un sistema de tipos demasiado simple pero limitado pues no te va a permitir hacer muchas cosas que serían extremadamente simples de hacer quitando una vil validación o teniendo alguna característica que dicho sistema no tiene, etc.

Aún no estoy seguro si hace falta otro lenguaje

Hola.

Ciertamente la comprobación estática de tipos representa una enorme ventaja como ustedes lo mencionan, sin embargo Scala también tiene un sistema estático de tipos, aunque ciertamente ese polimorfismo de operadores y otras cosas más, hacen que Scala resulte intimidante.

No estoy seguro si el mundo necesita otro lenguaje, me da la impresión de que más bien Ceylon surge como expresión de una postura que se opone al rol que Oracle está teniendo con Java (que a mí en lo personal no me está gustando mucho).

Algo que no me gusta de Java no tiene que ver con Java per se, sino con el hecho de que exista una compañía que ejerce el papel de tirano controlando la evolución del lenguaje y probablemente inhibiéndola.

¿Consideran ustedes que eventualmente Ceylon debería ser estandarizado de alguna manera, preferentemente por un organismo reconocido de estandarización? ¿O se sienten cómodos con algo como el JCP o una dictadura benevolente (al estilo Python)?

Gracias de antemano

Saludos

J. Reynaga

Imagen de ezamudio

estándares

No hay por ahí un refrán que dice que los estándares son para romperse? O me lo acabo de inventar? Cuando salió .NET recuerdo que MS cacareaba mucho el hecho de que habían registrado C# y el CLR con ECMA para que fuera un estándar. Pero obviamente encima de dicho estándar hay mil cosas que ya son propietarias de MS (todo winforms en aquel entonces, cuando menos). No sé si las siguientes versiones de C# siguen siendo estandarizadas o si todas esas monerías como LINQ ya son propietarias de MS y no forman parte del estándar en ECMA. En fin, eso sería la demostración de que los estándares en realidad no sirven para nada en estos casos.

Ceylon en vez de un dictador benevolente tiene un demócrata malévolo ;) (chiste interno). Ya en serio, pueden politizar Ceylon todo lo que quieran; la realidad es que no hay nada de eso porque la idea no viene de una empresa, sino de una persona, que al final consiguió financiamiento de una empresa. Y la intención no es protestar contra Oracle ni derrocar su tiranía ni nada de eso. Consideramos que la JVM es una excelente plataforma, pero el lenguaje Java se ha quedado atrás en cuanto a características (lambdas apenas para Java 8, Jigsaw ya lo aplazaron para Java 9, etc).

Lo que mencionas de Scala que resulta intimidante, por qué te resulta intimidante? Es la sintaxis, el sistema de tipos tan complejo, o la combinación de ambas? Y ni hablar de los implicits... esos son algunos aspectos que queremos evitar en Ceylon y que de hecho son totalmente opuestos a las metas de este lenguaje: que sea simple, regular y legible.

Hasta ahora el sistema de la democracia malévola ha funcionado bien; las discusiones son bastante racionales y podemos ponerle o quitarle cosas al lenguaje, a la plataforma y al SDK siempre y cuando haya razones técnicas válidas para ello.

Porque resulta intimidante

Básicamente me resulta intimidante porque maneja más abstracciones de las que manejan los lenguajes que he utilizado habitualmente.

Eso significa más tiempo para aprenderlo, aunque la recompensa supongo debe ser gratificante.

En cuanto a Ceylon, no es que quiera politizar (cuando quiero politizar me muevo en el campo de la política real), simplemente es un deseo de entender la motivación de crear este nuevo lenguaje y cuestionar por que quienes lo están implementando han decidido que ninguno de los lenguajes existentes satisface esa motvación.

Estoy seguro que entendiendo esa motivación podré entender mejor que clase de problemas es conveniente resolver con Ceylon, soy un firme creyente de que cuando tu única herramienta es un martillo todo tiene cara de clavo, y pues hay de clavos a clavos :-p

Saludos

Imagen de bferro

Siempre hará falta otro lenguaje y otras cosas

La creación de algo nuevo (de valor como comentó Enrique), en este caso de un lenguaje de programación, siempre será necesario, y en lo personal le doy la bienvenida pues puede llegar a convertirse en una herramienta valiosa para hacer cosas de manera diferente, con más elegancia, mejores, etc.
Que eso se logre, depende de muchos factores, y de esos factores, muchos apenas tienen que ver con el valor del lenguaje.
Basta ver "el fracaso industrial" de excelentes lenguajes de programación que se han inventado y que por esas razones no técnicas no han podido convertirse en mainstream.
No es el momento aun para saber si Ceylon ocupará un lugar importante en la familia de lenguajes de uso amplio en la industria. Yo en lo personal considero que tiene posibilidades, pero más que por la potencia del lenguaje, lo creo por una razón no técnica y esa es que Gavin es su autor y sus ideas han demostrado muy útiles. Hibernate es el ORM más usado en la plataforma Java.
No es lo mismo la pelea en el campo de los ORM, que en el campo de los lenguajes de programación; en este último hay más contrincantes muy fuertes y que ya tienen un camino adelantado. El tiempo dirá, pero por lo pronto vale la pena cosechar las nuevas ideas y otras que no son tan nuevas que van surgiendo con Ceylon.

Imagen de Sr. Negativo

Fracaso industrial ...

Basta ver "el fracaso industrial" de excelentes lenguajes de programación que se han inventado y que por esas razones no técnicas no han podido convertirse en mainstream

Esto me suena a Python o Ruby será ??

A mi me parece que Ceylon tiene buenas cosas (comprehensiones, manejo de los objetos null, etc ... y lo que falta.), la verdad los desarrolladores se están "aventando" un buen proyecto.

Imagen de bferro

de una empresa o de una persona

Casi todos los lenguajes de programación que conozco han surgido por ideas de personas y no de empresas.

Imagen de Sr. Negativo

Ceylon vs Java

Según lo que he leído Java fue creado para programar electrodomésticos (lavadoras, refrigeradores, etc.), los programadores (de SUN) querían usar un lenguaje portable, al principio pensaron en usar C, pero al no tener buenos resultados optaron por crear uno propio.

El lenguaje no tuvo mucha aceptación al principio, pero poco a poco fue ganando popularidad. El problema (por tomar un ejemplo) que Java no fue pensado para el desarrollo web de ahí que existan muchos frameworks y librerías que extienden demasiado al lenguaje (entre otras cosas más).

Los nuevos lenguajes como Scala, Groovy y Ceylon pretenden ser una solución a los problemas que tiene Java. Ahora es decisión propia si los quieren usar para el desarrollo (serio) o solo "por diversión".

0_o

Imagen de bferro

No existía el Web como lo conocemos al crear Java

Sr. Negativo, Java sí fue creado pensando en la computación en red (network computing), pero por supuesto tomando el estado del arte de la computación en red en el año 1991.
La idea de network computing era tan atractiva que se pensó que sería muy padre la unión de dispositivos digitales programables de uso diario con servers, usando las técnicas de sistemas distribuidos. El grupo "Green Team" encabezado por Gosling se dio a la tarea de diseñar una plataforma y un lenguaje que más tarde se convertiría en lo que hoy conocemos como Java.
El concepto resultó demasiado revolucionario para esa época, además de que encontró enemigos entre las industrias que desarrollaban esos dispositivos programables y que hacían uso de tecnología propietaria para programar esos dispositivos. Fue entonces que surgió la idea de dar a conocer el lenguaje en los browsers de aquel momento.
RMI (Remote Method Invoaction) está presente en Java desde la versión JDK 1.1 de 1997 para dar soporte en el diseño e implementación de sistemas distribuidos usando ese middleware.
El resto es la historia que conocemos.

Imagen de Sr. Negativo

@bferro Gracias por la

@bferro

Gracias por la aclaración.