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

¿Dónde está el nicho de mercado para Ceylon?

Un video corto pero interesante. Gavin y Stef hablando de Ceylon en Devoxx France 2015.

Recomendable, dura sólo 10 minutos, me gustaría leer sus opiniones.

https://www.voxxed.com/blog/2015/04/wheres-the-market-niche-for-ceylon/

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.

La relevancia de lo superflo.

Es curioso y hasta cierto punto contradictorio que la elección de lenguajes de programación tenga mucho que ver inicialmente con lo que aparenta ser o por como se ve desde fuera más que por sus características internas. Y no solo en los lenguajes de programación, supongo que así somos los humanos en nuestras elecciones; primero nos fijamos en lo externo y si nos parece interesante seguimos con lo interno para ver si nos gusta completamente (por eso dicen que no hay que juzgar a un libro por su cubierta, porque todo mundo lo hace). Las cosas que internamente carecen de substancia son descartadas en muy poco tiempo, las cosas que carecen de buena apariencia ni siquiera son probadas.

Me parece que un aspecto que pasó por alto Ceylon es el tener esa buena apariencia inicial a la vista de los desarrolladores. Puede que su diseño y los features que ofrece son muy buenos y completamente acordes a cubrir el mercado "Enterprise" que tiene Java: modularidad, mantenibilidad, interoperabilidad con el código legado (Java), un solo lenguaje para frontend/backend, no más NPE, etc. pero para que esto suceda debe de haber uno o varios individuos altamente motivados que digan: "Voy a usar Ceylon para este proyecto porque me gusta y quiero aprenderlo" y esa motivación es inicialmente emocional y luego cuantitativa. Cuando se vea que funcionó en ese proyecto van poco a poco adoptandolo en otros proyectos y la comunidad va creciendo tanto dentro de la empresa como fuera. Pero para que estas personas estén muy motivados tienen que haber sido atraídos por el lenguaje desde el principio, y para ello tienen que encontrar algo que los haga decir "Woah que padre esta esto, quiero probarlo" muchas veces esta motivación inicial viene de proyecto open source donde tal o cual persona hizo un proyecto X en el nuevo lenguaje simplemente porque le gustó. A mi parecer (y desde un punto de vista totalmente subjetivo y quizá hasta superficial) Ceylon cubre cosas estándar u objetivos empresariales pero carece de un elemento "Woah", y eso puede obstaculizar que sea adoptado. Si la adopción fuera simplemente con un checklist de características, podría fácilmente ponerse en comparación cuantitativamente con otros lenguajes y ganaría y sería adoptado a nivel empresarial, pero no funciona así, generalmente, como ya dije, se necesita a alguien muy motivado y que diga "Voy a probar esto ahora porque me gusta mucho y quiero aprenderlo"

Hay varios ejemplos de este entusiasmo, por ejemplo, Node.js es muy favorecido por programadores frontend que necesitan algo en el backend, y no les importa que Javascript sea ... bueno, todo lo que es, porque ese es su lenguaje favorito, incluso desdeñan versiones mejoradas de Javascript (como CoffeeScript, Typescript, Dart) porque estan acostumbrados a su javascript y node.js (sin ser un lenguaje nuevo lo sé) pero les atrae porque tiene ese elemento woah, escribir su mismo javascript en el servidor (dios nos libre)

Otros ejemplos fueron Python anteriormente: la elegancia y el poder de hacer cosas sin tanto rollo, o Ruby que además tener el paradigma OO con flexibilidad máxima. Scala atrajo a los que querían hacer cosas funcionales sin tener que cambiar de plataforma totalmente, Rust tiene ya desde antes de ser liberado una gran adopción y entusiasmo por que se ofrece como un lenguaje de sistema mejor que C y C++ pero más "moderno" (hay quien incluso hizo ya un OS en Rust - chiquito, pero lo hizo-) Go el performance y facilidad de usarlo/aprenderlo, lo diseñaron inicialmente para atraer a los programadores de C++ para que escribieran en algo más amigable pero esta teneiendo mucho éxito con gente de Ruby, Node.js que quieren seguir escribiendo en algo ligero pero no perder performance. Java mismo tuvo mucho éxito porque ofrecía un ambiente donde las versiones el API y todo el ecosistema no cambiará cada año y pudieran escribir en una sola plataforma (recuerdo que compilar en windows y desplegar en unix era woah)

Ceylon por otro lado no aparenta tener ningún plus, porque efectivamente fue diseñado como un mejor Java, pero como tal muchos que ya escriben en Java dicen mejor le sigo con Java, y los que escriben en otros lenguajes y nos les gusta Java dicen: esque corre en la VM.

Así pues, algo tan superfluo que es el "como se ve" resulta ser importante pues de ahí nace el "voy a investigar más", pero cosas como shared y variable hacen que la primera impresión sea de rechazo. Si, sé la razón de esos dos keywords y si, me parecen muy buenos features una vez que sé la historia detrás, pero he visto y leído en foros que mucha gente le nace adversión solo de ver eso y ya no investigan más. Supongo que esa es la relevancia de lo superfluo.

Imagen de ezamudio

keywords

Jejej shared y variable no son keywords, son anotaciones. Una de las cosas chidas de la sintaxis de Ceylon es que si tienes anotaciones que no reciben argumentos, las puedes poner sin paréntesis. Es algo que se puede hacer porque las anotaciones es algo que se considera en el diseño inicial, no es un parche como fue en Java y que por eso se tienen que poner con @ para que el parser las reconozca.

En cuanto al factor whoa (o wow), yo creo hay algunas cosas de Ceylon que por sí solas lo tienen: los tipos unión e intersección es algo que hasta la fecha no tiene ningún otro lenguaje, y es bastante útil. El sistema de tipos en general es bastante bueno porque es poderoso pero simple de entender y de usar. Lo que tal vez no es muy wow cuando solamente lo lees pero sí cuando lo empiezas a usar es precisamente el hecho de que te das cuenta que lo que odias no es los lenguajes de tipado estático o los sistemas de tipado estático, sino las implementaciones mal hechas, o ineficientes, o complicadas en extremo. En vez de aprovechar el sistema de tipos de tal o cual lenguaje, terminas peleándote con él, y es cuando viene la frustración y el "esto no sirve para nada". A mi me ha pasado. Pero con Ceylon la meta es que el sistema de tipos no sea algo que solamente te ayuda a no cometer algunos errores, a expensas de tener que estar lidiando con él y tener que tolerarlo, sino que sea algo que realmente puedes aprovechar para mejorar la calidad de tu trabajo.

Por otra parte, algo que sí nos falta (y es en gran parte culpa mía) es facilitar el uso del backend en Javascript. Creo que ese puede ser un buen factor wow: Escribe una aplicación usando un solo lenguaje, algunas partes corren en JVM en el server y otras en JS en el browser. Serializa objetos de un backend a otro. Cosas así.

Y a fin de cuentas, entiendo lo que dices del factor wow, pero pues cuando adoptas algo por el factor wow que te da una de sus características, luego te metes en broncas. Yo empecé a adoptar Scala por el factor wow de que era muy terso y lo abandoné muy pronto porque tres semanas después de haber escrito unas pocas líneas de código, las leí y no entendía nada. Me tardé mucho en entender lo que había escrito. En Ceylon tal vez ninguna de sus características tenga ese factor wow de manera aislada (aunque no veo cómo alguien que ha usado Java no le parezca wow lo de los tipos unión e intersección, con todas las consecuencias que esas dos cosas tienen para todo el sistema de tipos y el diseño de componentes y aplicaciones), pero ver todas las características ya de manera general es lo que lo hace una excelente opción.

Incluso creo que el problema que tenemos es que hay demasiadas cosas que mostrar... ayer en JaverosMX di una presentación haciendo demo con live coding, y había decidido clavarme solamente en la parte del lenguaje, mostrando sus características principales que lo distinguen de Java; nada de meterme con lo del sistema de módulos o ver los módulos adicionales del SDK, etc; puras cosas con el módulo de lenguaje, lo más básico. Uta... se me fueron dos horas y nomás no terminé de mostrar todo lo que hay; "solamente" pude mostrar:

  • funciones de nivel tope
  • funciones de orden superior
  • comprensiones
  • flow typing
  • funciones anidadas
  • lambdas
  • clases, interfaces
  • herencia múltiple
  • tipos unión e intersección
  • operadores is, exists, nonempty
  • switch sobre tipos
  • map/filter/find sobre iterables y secuencias
  • invocaciones posicionales, por nombre, con spread
  • deconstrucción
  • singletons
  • métodos y propiedades en clases e interfaces
  • funciones con listas de parámetros múltiples
  • propiedades nivel tope
  • inferencia local de tipos

es una lista extensa. Sin embargo me faltó:

  • constructores
  • expresiones inline: if, switch, object
  • expresiones con let
  • interop con Java
  • interop con JS
  • compilación de tipos con miembros nativos en JS
  • varianza y covarianza en los generics
  • parámetros con valores default
  • generics con valores default
  • metamodelo
  • referencias a métodos

Y como dije, todo esto sin meterme en cosas que no sean del lenguaje: nada del sistema de módulos, Herd, los módulos adicionales del SDK (colecciones, pruebas, tiempo, IO, base de datos, etc), generador de documentación, plugins para el CLI, plugins de ant, soporte para android...

Y la bronca es que he querido ordenar este tipo de cosas como por orden de importancia, y nomás no... todo va entrelazado, todas estas características van relacionadas entre ellas, es difícil enseñar algunas de manera aislada, al menos de una forma que tenga sentido. Tal vez esa es la bronca: tenemos que buscar una manera de mostrar varias de las características de manera simultánea para que digas "aaaaaaaaah ahora sí entiendo y todo eso junto está bien chido".

Incluso soy de la idea que debemos tener como varias presentaciones distintas: una para gente que viene de Java, una para los clavados en la programación funcional, una para los que vienen de lenguajes dinámicos, etc; y mostrar primero las cosas de Ceylon que son más relevantes para cada audiencia.

En la presentación de ayer creo que sí se llevaron una buena impresión por ejemplo del sistema de tipos en general: hay cosas que te abren los ojos a decir "ah chale creo que realmente nunca he usado el sistema de tipos de Java a mi favor, solamente hago lo más básico con él". En Ceylon el uso del sistema de tipos va mucho más allá de validar qué cosas le puedes pasar a un método.

Imagen de Sr. Negativo

el factor "Woah" en Ceylon

Ceylon por otro lado no aparenta tener ningún plus, porque efectivamente fue diseñado como un mejor Java, pero como tal muchos que ya escriben en Java dicen mejor le sigo con Java, y los que escriben en otros lenguajes y nos les gusta Java dicen: esque corre en la VM

A mi me llama la atención este lenguaje desde el momento en que leí iba a ser un "mejor Java" y que se podía seguir trabajando con los proyectos escritos en Java sin ningún problema. Es obvio que muchas empresas y desarrolladores no van a abandonar un lenguaje como Java (con su ventajas y desventajas) por un nuevo lenguaje. Sin embargo, si este lenguaje promete que se puede seguir trabajando en los proyectos Java sin ningún problema creo se le debería dar una oportunidad.

¿En que falla Ceylon?
A mi parecer es que no es un lenguaje totalmente terminado, en el cual hay bastantes cambios y hasta que empiezas a escribir código te das cuenta que hay cosas nuevas. Considero que el factor Woah al que se refiere @OscarRyz se debe también a la nula motivación por difundir el lenguaje; hacer ejemplos de como usarlo, las ventajas con respecto a otros lenguajes, rendimiento, etc. Si a los programadores les hablas de funciones de nivel superior, de anotaciones, de programación funcional, etc. terminan aburriéndose y desinteresándose, lo que ellos quieren es ver un ejemplo de "la vida real" usando un lenguaje de programación.

Imagen de ezamudio

motivación

nula motivación por difundir el lenguaje

Whoa... cómo que nula motivación por difundir el lenguaje? Tenemos la página con un blog en donde vamos informando del progreso del proyecto y de ejemplos interesantes que surgen: la entrada más reciente al momento que escribo esto es precisamente acerca de cómo se puede implementar el patrón Observer/observable con seguridad de tipos, algo que no es posible en otros lenguajes, gracias a varias de las características del sistema de tipos de Ceylon. Varios miembros del equipo van a cuanta conferencia es posible para dar charlas y talleres, no sólo a conferencias grandes internacionales, sino también a JUGs locales.

Lo de las ventajas sobre otros lenguajes... hemos decidido no tomar ese camino al menos en publicaciones en línea porque es la mejor manera de atraer trolls. En cuanto dices que tienes algo mejor que X lenguaje, te caen encima los trolls/extremistas/jihadistas/comoquierasllamarles de ese lenguaje. Y no en buen plan, para tener una discusión racional con buenos argumentos y fundamentos para hablar del tema civilizadamente...

Tenemos ejemplos que si bien no son "de la vida real" porque no son sistemas en producción, sirven como muestra de la integración de varias cosas. Hay por ahí un servidor HTTP, una aplicación MVVM que corre totalmente en el browser, web apps en vert.x con verticles hechos en Ceylon, etc. En el blog hay varios ejemplos como el que menciono de Observable.

Pero pues si a los programadores no les interesa escuchar de las características de un lenguaje de programación, entonces... pues chale. Pero honestamente, eso no suena como que sea un problema de parte del equipo de Ceylon.

Imagen de Sr. Negativo

re:motivacion

... se debe también a la nula motivación por difundir el lenguaje

Me refería a los demás programadores, no al equipo de Ceylon. Yo he escrito varios post sobre este lenguaje, pero veo que a muchos todavía se quedan con la cara de "¿Que cosa es esto?" ...

Imagen de arterzatij

Bueno de mi parte puedo

Bueno de mi parte puedo opinar que al igual que Oscar, falta el wow y no desde la parte de la sintaxis etc etc etc. Por que, bueno por que a muchos la verdad no les interesa. Y menos en la fiebre que vivimos actualmente las startups y lo "agile". Que te piden una pagina web "completa" no se de donde sacan los clientes eso de completa.

Y esto nos lleva a lenguajes que mas que lenguajes son los frameworks que estan delante de ellos, al menos yo no escuche nada como, lo he escuchado y vivido como con Node(no es un lenguaje pero bueno, algunos lo ven asi.). Node nació fuerte y como dicen por personas que ya sabían js y dijeron woow puede estar mi código en el server.

Pero que paso con Ruby o con Python, yo los vi mas populares por Rails o por Django. Y ahora mas Node son Sails.

Y adoptan a los frameworks muy rápido y no por el lenguaje, si no por lo que te resuelven, yo veo 5 cosas.

- Curva de aprendizaje
- MVC por convencion
- Y algo que a muchos les gusta demasiado el active-record
- versionamiento de la DB (migraciones)
- CLI integrado al framework para generar código

Y no voltean a ver si el lenguaje es bueno, si no que les ayuda en lo superficial como lo indico Oscar, en este caso generar tu app lo mas rápido posible. Después arreglamos los pedos de escalabilidad, performance, etc etc.

Ahora por la parte de la difusión, tal vez haya tutoriales de como resolver cosas de la vida real, pero la gente esta buscando algo como, un todolist en 10 min, más no como ordenar cosas en 2 lineas de código. Son cosas que actualmente lo dejan al final, por que pues tenemos maquinas de 6GB de ram y pues no nos preocupa el servidor de 8GB que utilizan cientos de usuarios.

Y a eso sumale que en la escuela a los alumnos nos enseñan "y si así con estos clics puedes generar un WS en visual studio", o sea, ni siquiera dicen el lenguaje.

Así que resumiendo creo que deberían promover mas, el hecho de resolver el todolist en 4 min. por que en sails es en 5min (solo un decir) que decir puedes integrar Hibernate, no muchos lo conocen, no fuera del mundo de Java o .net

Y ahora en lo que a mi se refiere.

Ya no me agrada eso de generar HTML o proveer JS desde el back-end. Ya estoy cambiando mi filosofía a que si es backend es una API o servicio web. Claro hay cosas que no las puedes delegar por completo al front-end. Sin embargo, aun puedes generar templates que tengan restricciones desde el back-end para el front-end. Cosa que me gusto mucho en rails (ven de nuevo un framework mas no el lenguaje) en java se que existe velocity y esas cosas pero mucha configuración y no es nativo en el framework o lenguaje.

Así que un lenguaje que me diga, que con código puede generar html, yo me remonto a cuando hacia las app de escritorio que odie mucho. Y no me llama mucho la atención. Me llamaría mas la atención un lenguaje que desde su nacimiento o que se encuentre en la API, resolviera cosas de la actualidad.

- REST services
- WS
- Autenticacion
- Migraciones
- websockets

Es decir, que no tenga la necesidad de un framework para hacer algo. Y si deseo usar un framework pues adelante.

Y muchas de las cosas que en liste ya las hace java, pero no de la mejor manera y por eso vienen librerías, dependencias, etc. Y no por que a "es que me gusta mas esta especificación". Si no por que es difícil de implementar o toma demasiado tiempo.

Pero igual los equipos multidisciplinarios, solo los he visto en las startups, mas no en el enterprise.

Y pues bueno eso es lo que opino.

Y cosas como estas estaría genial que fueran parte del lenguaje, desde un inicio, cosa que a Node le favorecio.

http://sparkjava.com/

Imagen de ezamudio

frameworks

¿Por qué no hay tantos frameworks en Ceylon?

Los que somos parte del equipo de Ceylon pues estamos bastante ocupados con el lenguaje y la plataforma mismos. Ya hay gente que ha empezado a crear módulos para cosas un poco más concretas, como un web server, un framework para aplicaciones web, etc. Son los early adopters.

Algo como esto para web? https://modules.ceylon-lang.org/repo/1/cayla/0.2.0/module-doc/index.html

Websockets en Ceylon sobre vert.x https://github.com/vert-x/vertx-examples/blob/master/src/raw/ceylon/webs...

Lo que leo aquí es que lo ven como "oh qué desastre, no hay nada para hacer un WS". Sólo necesitamos alguien que piense "mira, no hay nada para WS, qué buena oportunidad para hacer algo"...

Concuerdo con arterzatij , a

Concuerdo con arterzatij , a eso me refería con efecto wow, no es que Ceylon no tenga características chidas, claro que las tiene, fue especialmente diseñado para eso, pero en efecto había olvidado el efecto que me causó ver un CRUD en RoR sin apagar la app fue así de woah... O por ejempo ezamudio recordará como eran las cosas con webobjects (un webframework escrito en Objective-C que en 1996 estaba haciendo cosas como Ruby on Rails, desgraciadamente la web estaba muy inmadura aún para él y murió) que te hacían pensar que retrasadas estaban todas retrasadas.

Ceylon fue diseñado para complementar/reemplazar gradualmente a Java, pero le falta ese "algo" que va a cubrir perfectamente otro "algo" específico. Ceylon tiene features que cubre muchas carencias de Java ( modularidad, nulls, y bueno ver la lista de arriba ) en cuanto a calidad y número de características creo que no le falta nada (quizá hasta le sobran tantitas).

Yo creo que el equipo de Ceylon esta haciendo un excelente trabajo para difundir, pero para alcanzar magnitudes web (twitter, feis, google, stackoverflow) se necesita una comunidad entusiasmada que empiece a utilizarlo y a hablar de como les salvó la vida y les curó el cáncer y les ayudó a encontrar el amor de su vida (ya saben ese tipo de cosas exageradas que dicen los fanboys) y entonces la bola de nieve empezará a rodar (chale ya me estoy agringando con mis dichos).

Que taaaal un framework que te ayude aaa aa... no sé usar implementar Continuous Delivery de la misma forma que Hibernate ayudó a implementar ORM y todos quisieron usarlo, este framework estará escrito en Ceylon y nomás le acerques un jar a la máquina en luna llena, tu empresa empezará a hacer CD y ... y .. curará cáncer etc. etc. Pero ese framework no puede salir del equipo de Ceylon mismo, tiene que salir de la comunidad donde alguien encuentre una característica de Ceylon ( por ejemplo los módulos) y diga, con esto resolvimos blah blah blah de mi empresa que blah blah blah.

Paciencia supongo.

.... o que Gavin King se deje

.... o que Gavin King se deje la barba ( queeeee... le funcionó a Ruby y a Python )

Imagen de arterzatij

No es que ya pidamos

No es que ya pidamos frameworks, de hecho en lo particular a mi me gusta mucho que no tenga la necesidad de un framework para extender la API si puedo prescindir de el mejor.

Librerías como guava, gson, jodatime y otras mas me gustaria que ya fueran parte de API y no batallar con dependencias cada que inicio un proyecto.

Y si muchos ven un desastre al no ver esas cosas como las que comentas, sin embargo, por que cayla es framework y no parte del API. A mi en lo particular y como lo ha esta haciendo apple me parece muy bueno. Las cosas que se ven bien y funcionan se vuelven parte del API y no un tercero. Ese tipo de cosas generan lealtad a algo al saber que seras parte de y no un tercero. Lo cual generara mas apoyo de la comunidad.

Node como comente pues ya es parte de una especificación y con su modulo HTTP generas web en un script, pero es parte del API no necesitas instalar un modulo.

Eso es lo wow que muchos esperan. Y se en lo personal que están creciendo y esta tomando buen rumbo el lenguaje. Y los felicito muchachos por eso.

Ya me pondré a jugar de nuevo con ceylon, lo deje por que mi lap murio y solo tenia la lap de la oficina :'(

Imagen de ezamudio

guava

Bueno con Ceylon no veo por qué necesitarías guava. Bueno incluso si usas Java 8 creo que ya no necesitas guava (ni jodatime). En Ceylon tenemos un módulo para tiempo también. Es cosa que le echen un ojo al SDK.

No entiendo bien qué dices con "parte del API". Cayla es un módulo como cualquier otro. Supongo que te refieres a que sean parte del developer kit básico, parte del "core". Pero eso va justo en contra del concepto de modularidad... Pero tendrías que ver cómo funciona la modularidad en Ceylon para darte cuenta que no necesitas un monolito gigante con todo incluido, sino que puedes tener varios módulos pequeños y que se irán cargando conforme los necesitas y no necesitas preocuparte de eso. Si lo que no te gusta es tener que estar manejando dependencias, es precisamente algo que también odiamos y por eso Ceylon incluye modularidad. Creo que todo mundo sabe que manejar dependencias es un dolor de cabeza (y otras partes del cuerpo) y por eso hasta Java quiere arreglar ya esa bronca con Jigsaw (pero pues ya nos adelantamos nosotros).

Para usar Cayla (o cualquier otro módulo del SDK) en Ceylon simplemente agregas nombre y versión del módulo que quieres en la definición de tu módulo y listo. Si ese módulo a su vez tiene dependencias, el CMR (Ceylon Module Resolver) se las va a traer, tanto para compilar como en tiempo de ejecución.

Imagen de arterzatij

Creo que a eso se referían

Creo que a eso se referían con las comparativas, se que no desean atraer trolls pero es un mal necesario, en ocasiones, no sabia de esa bondad del CMR, que a diferencia del NPM de node lo tienes que instalar y manejar las dependencias. Esas son los wow que esperamos escuchar "leer".

Y si como parte del core, que a pesar de que son módulos, y los resuelve el CMR (ahora que lo se) que sabemos que el equipo lo adopto y no es algo que pueden quitar o dejar de darle mantenimiento, eso genera mayor confianza.

Y por lo del guava era solo un ejemplo :) que se me bino a la cabeza.

Y sacar esas bondades de modulos para tiempo que a final de cuentas son comparativas de lenguajes :'( tristemente. Es la manera que demuestras por que es mejor un lenguaje sobre otro.

Imagen de ezamudio

CMR

El lunes que estaba dando la presentación me di cuenta que ya estoy a veces tan adentrado en algunas cosas de Ceylon, que hay varias que ya doy por sentado y que ps no las presumo lo suficiente... lo del CMR es una. Sé que es algo muy útil y que resuelve muchas broncas, pero como ya está ahí y funciona pues no le pongo más atención al asunto (hasta que se descompone por algo entre un release y otro jej).

Está bueno, haré un post del CMR en particular para explicar un poco al respecto.

Imagen de Cid

Re: Presentaciones Distintas

Incluso soy de la idea que debemos tener como varias presentaciones distintas: una para gente que viene de Java, una para los clavados en la programación funcional, una para los que vienen de lenguajes dinámicos, etc; y mostrar primero las cosas de Ceylon que son más relevantes para cada audiencia.

Hace como 2 semanas me di una vuelta por el tour de ceylon (tutorial) que ofrecen en su página y pues no he tenido tiempo de regresar, yo provengo de java y hay cosas que explican ahí que son fáciles de entender, pero el otro dia leía una nota de una encuesta que levantaron en stackoverflow que más de la mitad de los que contestaron no provenían de una carrera de ingería en sistemas o afin, y eran autodidactas, y me surge una duda "Ceylon podría tener una audiencia que no se haya vuelto un fan de tal o cual lenguaje de programación (para aprender a programar)", sus tutoriales y presentaciones podrían mejorar para llegar a este tipo de audiencia y ojo no estoy diciendo que sus presentaciones y tutoriales estén mal.

Saludos.

Imagen de ezamudio

Claro

Dentro de eso de las distintas presentaciones, una debe ser para una audiencia que apenas va a empezar a programar. Obvio primero hay que presentar varios conceptos fundamentales, pero eso sí se sale del enfoque del proyecto yo creo; pero una vez que has visto algunos conceptos, no es complicado hacer un "hello, world", que si lo ejecutas en el IDE en línea, pues es una sola sentencia en código.

http://try.ceylon-lang.org/

Imagen de javatlacati

Otro IDE? Basado en eclipse!

En IDE en línea está mega lento, ya sabes browser en México y sudamérica el internet está para llorar, a mí me tarda cerca de 10 segundos desde que le doy click al botón run hasta que se muestra una salida.
Ahora en cuanto a la adopción... si revisas la página ceylon-lang.org te darás cuenta que lo primero que sale es un pedazo de código que no se sabe para que sirve, segundo tres columnas bellamente pintadas en las que esencialmente piden que lo uses y finalmente las ventajas. Pienso que las ventajas deberían de ir primero, pero tal vez sea únicamente mi percepción.
En cuanto a las ventajas se traducen de manera sencilla en lo siguiente:

* potencial, al referirse a poderoso quieren decir que ´puedes construir lo que sea, no que sea rápido, seguro, nunca se habla de las ventajas económicas que pudiera suponer...

* legibilidad, con estructuras arbóreas, sintaxis regular... esas palabras no alientan ni a invertir ni a estudiarlo.

* predecibilidad, complejidad, compilador, errores no son palabras que a uno le guste leer en el mismo párrafo aunque sea en sentido positivo,

* plataforma, un montón de cosas que descargar para sacarle provecho ( una vez que las descargues todas ). Por cierto allí habla de Java y javascript, eso es lo único que yo en lo personal dejaría de plataforma.

* modularidad, herramientas sdk compilación, repositorios... nada suena agradable, ni te indicca que se simplifique el flujo de trabajo

* herramientas es como la décima parte que se mencionan las herramientas y las gran herramienta es un ide basado en Eclipse ¿Qué?! Otro ide basado en eclipse para la colección porque.. nunca son suficientes o sí? Si tan sollo fuera el dueño de la página http://ihateeclipse.com creo que ya me hubiera hecho millonario.

¿Dónde está la sección de preguntas frecuentes?¿Es que nadie ha hecho preguntas?

En suma... una página estática, que ni siquiera es responsiva con gráficos que distraen en una época audiovisual, con el mercado de los dispositivos móviles inundando la red, es algo por decir algo bizarro.

Concuerdo co el buen Oscar, eso no es echarle ganas, yo de primera página pondría un video del tipo cómo hacer una red social en 20 minutos usando ceylon.

Respeto su trabajo y sé quienes son, pero a pesar de su reputación, lo que necesitan es una visión, un sueño que compartir.

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