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

Episodio 1 de la temporada 1 - ViveCodigo.org - Ceylon con @chochosmx

Nuevo episodio de la nueva temporada de ViveCodigo la temporada 01 en esta ocasión el capitulo 01, en la cual tuvimos el gusto de entrevistar a nuestro compañero Enrique Zamudio – @chochosmx. Un gran desarrollador con muchos años de experiencia y uno de los contribuidores del lenguaje Ceylon, nos comparte como incluso a estas alturas de su carrera el sigue aprendiendo y enfrentando retos que no había enfrentado antes.
Disfruten esta amena entrevista sobre Ceylon, un lenguaje que corre sobre la JVM y que nos ofrece características de tipado estático muy interesante, sin duda un grata charla y una demo en la cual nos da una serie de ejemplos del funcionamiento de Ceylon.
¡Espero lo disfruten! y apreciamos mucho cualquier comentario que nos puedan dejar, pronto mas capítulos de la temporada 01.

ViveCodigo 01x01 - Ceylon con Enrique Zamudio from MakingDevs on Vimeo.

ViveCodigo 01x01 - Ceylon Demo from MakingDevs on Vimeo.

Ceylon AtrasDeCamaras from MakingDevs on Vimeo.

Se pueden suscribir al feed de ViveCodigo.org o encuentranos en iTunes como: ViveCodigo.org – VideoCast

Fuente original: http://vivecodigo.org/2013/08/15/episodio-1-de-la-temporada-1-ceylon-con...

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 rodrigo salado anaya

Súper plus el "DeTrasDeCamara"!!!

Súper plus el "DeTrasDeCamara"!!! Muy buenos aportes cggg88 (según yo eres Felipe, disculpa si me equívoco)!

No es Felipe!

LOL, No es felipe!
Es Jorge Acosta que está trabajando en MakingDevs ! :P
Pasa a veces, pasa....

Imagen de ingscjoshua

Mis comentarios

Enrique una enorme felicitación por el lenguaje!!!!, como mexicano un orgullo ver gente de tu nivel haciendo cosas para otros de tan grande impacto.

Pasando a otra cosa, respecto al plus. totalmente deacuerdo son un mal necesario los jefes asi, porque te ayudan a saber como NO hacer las cosas. Alguna ocasión un PM me dijo "YA ME DIJISTE COMO NO AHORA DIME COMO SI" inversamente proporcional seria ya vimos como "NO hacer un proyecto, ahora como SI hacer un proyecto?".

Respecto a el crecimiento como desarrollador, totalmente de acuerdo es necesario estar en un ambiente de disciplina para crecer y auto disiplinarte.!!!

y para mi lo mas importante es, "La vida de la programación debe ser, divertirse, aprender y crear cosas cool!!!"

Imagen de ezamudio

Gracias

Y pues sí, esa plática pensé que no la estaban grabando jajajajaj pero qué bueno que quedó ahí para la posteridad, porque creo que fue una buena discusión.

Imagen de Cid

Buenas platicas

Que bien han comenzado estas platicas de ViveCodigo una felicitación al equipo de Making Dev y @neodevelop, y ya entrando en materia pues la charla con @chochosmx estuvo extensa e interesante y me surgio interes por conocer ceylon así como algunas dudas acerca de la platica y bueno aqui las dejo:

1.- Respecto a con covarianza o contravarianza podria utilizar uniones parecidas a las del siguiente código:

interface ejemplo <out String | Number>{
}

2.- En el caso de contravarianza o covarianza pueden servir para agregar o escribir mas datos sin que den esos errores tan raros que dan en Java ?. Por ejemplo el siguiente código en java no corre porque el usar covarianza solo permite leer pero no escribir en la coleccion.

 
public void modifica(List<? extends Algo> list){
        list.add(new Algo());
}

3.- Entonces el is es como un instanceof pero va mas alla pues el is de Ceylon si te dice si es de determinado tipo y con génericos ?

4.- Podriamos decir que las interfaces aqui no son como lo pensabamos (viniendo yo de un mundo java básico) aqui se redefinen como estructuras de código que definen una firma y probablemente un semi-comportamiento que podran definir de forma absoluta en quienes las implementen (satisfagan literalmente segun la palabra reservada de Ceylon).

5.- Mencionan que Gavin King si dejo utilizar el true en sentencias como el if existen los assert como parte del modulo principal de Ceylon y en caso de que no proyectan incluirlo o se deshecha por las inferencias obvias que no te permite hacer el compilador mismo ?

6.- Los varargs son igual que en java en cuestion de que solo podemos tener uno por metodo y debe ser el del final en la firma del metodo ? o puedo meter mas de uno y no importa su posicion.

7.- Eso de poder usar los metodos que heredeas y sobre escribes de un supertipo de tu clase padre directamente con el nombre de la clase esta bien chido (pareceria magia en java porque es imposible) y que en java no se podia hacer imaginandonos muchas veces hacer lo siguiente que es erróneo en Java:

class A{
        public void metodo(){
        }
}

class B extends A {
        public void metodo(){          
        }
}      
       
public class C extends B {
    public void metodoX(){
                //Error no se puede hacer asi:         
                super.super.metodo();
                //Error tampoco te deja asi:
                A.metodo();
        }                      
}      

8.- Yo se que a la mayoria de ustedes no les convence eso de las certificaciones, pero me surge tambien esa duda, y quiero pensar que cuando surgan versiones posteriores al primer release o incluso en el primero, proyectaran algun libro y certificaciones, Enrique participaras en la realizacion de alguno de ellos ?

En general esta muy interesante la charla aunque hay algunos conceptos que aun no he aplicado o conocido a fondo como las funciones de orden superior y la comprensiones que alguna vez me di un clavado a Scala pero de verdad no son tan bueno como pensaba para poder entender algo tan complejo y creo que Ceylon si se ve a primera vista un lenguaje sencillo y fácil de usar por lo que el eslogan podria ser "keep simple, code fast".

Por otra parte como comentan la mayoria de los programadores seriamos mas productivos desde casa pero a veces tambien hay que sufrir como comentan el yugo de los jefes y creo que algunas empresas asi lo empiezan a adoptar con eso del "home office".

Esperando una respuesta a mis dudas y reiterando la felicitacion a @chochosmx, @neodevelop y el equipo de making dev por su trabajo y el espacio que otorgan mediante estas charlas para hablar del mundo de la programación.

Imagen de ezamudio

dudas

Respecto de tus dudas:

1. La definición correcta es definir un parámetro de tipo, ponerle la covarianza, y luego restringir ese parámetro:

interface Ejemplo <out Algo>
    given Algo of String|Number {
}

Esto te permitiría usar Ejemplo con instancias directas de String (que es una clase final) y con implementaciones de Number (que es una interfaz).

2. La diferencia principal en cuanto a varianza entre Java y Ceylon es que Java usa varianza en el sitio de uso mientras que Ceylon usa varianza en el sitio de declaración. Esto significa que la varianza de un parámetro de tipo en Java la defines donde vas a usar el objeto, mientras que Ceylon la defines en la declaración de ese tipo. En el ejemplo anterior definimos Algo como un parámetro covariante, por lo que siempre se tomará como covariante cuando alguien use Ejemplo. Es decir, el diseñador de una clase o interfaz que use generics en Ceylon es quien debe decidir la varianza de dichos generics, mientras que en Java le dejas esa bronca a los usuarios de la clase o interfaz. Hay una ventaja adicional a todo esto: el compilador de Ceylon verifica que el código de la clase o interfaz que tiene definidos generics covariantes o contravariantes, realmente use los parámetros de esa forma.

3. El operador is de Ceylon es equivalente a instanceof de Java. En Ceylon puedes escribir cosas como x is List<Integer> porque tenemos generics reificados, es decir, los argumentos de tipo están disponibles en tiempo de ejecución.

4. Sí, las interfaces en Ceylon pueden tener métodos con implementación, y desde ahí puedes llamar a otros métodos de la misma interfaz que sólo estén definidos pero no tengan implementación. Al tener métodos con implementación están ya teniendo comportamiento, no son sólo un contrato.

5. No los alcancé a mencionar pero efectivamente tenemos assert en Ceylon:

List<Integer> numeros = [1,2,3,4];
"La lista debe tener al menos tres elementos"
assert(exists tercero = numeros[2]);
if (tercero > 5) {
  ...
} else {
  ...
}

El assert de Ceylon recibe una condición (o varias condiciones separadas por comas) y asegura que todas se cumplan, arrojando una excepción si una no se cumple. Le puedes poner una anotación anónima (una simple cadena) para documentar lo que estás validando y eso se vuelve parte del mensaje de la excepción que se arroja. Y si usas los operadores nonempty y exists definiendo nuevos valores como en este ejemplo, entonces si se cumplen las condiciones esos valores quedan disponibles en el alcance donde está el assert. Es decir, en este caso, ya tienes un valor tercero de tipo Integer disponible después del assert.

6. Sólo puedes tener un parámetro variádico por método y debe ser el último, esto es porque la limitante es la misma que en los otros lenguajes que los usan: a la hora de invocar el método, todos los argumentos que "sobren" se van al variádico (o si "falta" exactamente un argumento, se considera que el variádico va vacío). La diferencia aquí es que puedes indicar si tu parámetro variádico requiere al menos un argumento:

metodo1(String* params);
metodo2(String+ params);
metodo1(); // OK
metodo2(); // ERROR de compilacion, necesitas pasar al menos un argumento

Y dentro del código del método también hay una diferencia: el parámetro variádico con + se toma como un tipo Sequential, que en Ceylon es una colección que tiene cuando menos un elemento (nunca puede estar vacía) y por lo tanto puedes pedirle su primer elemento sin tener que validar su existencia.

8. Espero participar en la edición de un libro de Ceylon, pero por el momento no hay planes al respecto, aunque es muy probable que hagamos algo a mediano plazo. En cuanto a certificaciones pues eso es un tema medio complicado; más allá de que si creemos o no en las certificaciones en general, el caso de particular de Ceylon es al ser un proyecto open source es más difícil definir quién es (si es que hay) una autoridad central que pueda emitir certificaciones, porque pues no van a venir firmadas por el equipo de desarrollo ni por Gavin personalmente; tiene que ser una empresa... supongo que con Red Hat se puede definir un programa de capacitación y certificación, pero eso no impide que otras empresas hagan sus propios programas de capacitación y certificación. Y entonces, qué certificación pesa más? A nivel industria tal vez tenga más prestigio la de Red Hat, pero pues igual puedes tener una del instituto patronics. A nivel personal no creo poder dedicar el tiempo a dar capacitación personalmente, al menos no en general; no hemos discutido este tema aún pero yo supongo que lo más factible será definir un curso de capacitación orientado a instructores, que los miembros del equipo de desarrollo de Ceylon podamos impartir a personas que después se van a dedicar a dar cursos de programación en Ceylon. Un curso así tendría que ser algo extenso y vernos más estrictos porque ahí sí deberíamos tener algún tipo de examen al final para poder certificarlos como instructores... mmm supongo que eso es lo que podría al final tener algo más de peso a la hora de tomar un curso, que tú te fijes que te lo imparta un instructor certificado... en fin, estoy nomás alucinando barato planes a futuro, por ahora debemos enfocarnos a sacar M6 y luego la 1.0 antes que termine el año.

Imagen de ezamudio

TRY!

Ah y recuerda, si hay algo que quieras probar del lenguaje, puedes hacerlo en http://try.ceylon-lang.org/ - el único problema es que ahí está todavía la versión M5 y algo del código que yo hice en la demo y que puse en mi post anterior ya es M6. Las diferencias principales:

- No hay anotaciones anónimas aún, tienes que usar doc
- No hay parámetros variádicos con al menos un argumento (sólo hay T* todavía no hay T+)
- el switch es para puros tipos y objetos, no acepta literales aun
- no hay referencias estáticas a métodos
- La invocación a métodos de interfaces era diferente en M5, era Supertipo::miembro y en M6 cambió a (super of Supertipo).miembro

Esas son las cosas que recuerdo ahorita, al menos de lo que he mencionado en este post y en la demo.

Imagen de Cid

Ok gracias

Así es cuando tenga tiempo entrare a la página y existe documentacion como las javadocs en Ceylon ?, digo es que la verdad estoy verde y no he usado aun github, igual y ahi esta pero no tengo cuenta y aparte no se como usarlo, pero pronto tendre que saber.

Con respecto a tus respuestas de los assert mencionas que puedes tener una variable a tu alcance como "tercero" pero esto no genera errores cuando la usas con los if-else que pusiste en el código si los assert estan desactivados ? o en su caso si lo transformas a js esto como se maneja o esto lo elimna del código ?.

En cuanto a los parametros variádicos entonces el "+" y el "*" funcionan como las regular expressions.

Y ya para poner fin a tanta duda jajaja aparte de la pagina de try.ceylon existe documentación o alguna página donde pueda uno familiarizarse con la sintaxis de m5 y en su caso cuando salga la de m6 ?

Imagen de ezamudio

Herd

Otra cosa que ya no alcancé a mencionar y que también es una diferencia importante entre cosas como las groovy Grapes y los módulos de Ceylon es que nosotros tenemos nuestro propio repositorio, un repositorio público central tipo Maven Central y aparte puedes bajar el software para instalar tu propio repositorio privado de módulos de Ceylon.

Obvio tenemos compatibilidad con Maven para poder tener dependencias con libs de Java que estén en repos de Maven...

Y bueno, nuestro repositorio se llama Herd (manada en inglés, por aquello de los elefantes), y está aquí http://modules.ceylon-lang.org/ ahí puedes ver la documentación del módulo de lenguaje y del SDK que tenemos publicados ahí.

Puedes generar el "ceylon doc" tipo javadoc, con un procesador especial que genera la documentación a partir de las anotaciones de documentación que se encuentre en los fuentes que le pases.

El assert de Ceylon se genera como un if que arroja una excepción si no se cumplen las condiciones definidas. La diferencia con usar un simple if, aparte de la obvia excepción que se arroja, es que ya no tienes que estar anidando el código en bloques:

//Con if
if (exists tercero=lista[2]) {
  //Aqui adentro tercero es un valor del tipo definido como elemento de la lista
}
//Aqui afuera tercero ya no existe

//Con assert
assert(exists tercero=lista[2]);
//De aquí en adelante hay un valor "tercero" definido con el tipo del elemento de la lista.

En ambos casos puedes tener una lista de condiciones para no tener que anidar muchos ifs, en caso que no te interese manejar los "else" de cada condición:

if (exists tercero=lista[2]) {
  //Aqui tercero digamos que es un Integer
  if (tercero > 5) {
    //hacer una cosa
  } else {
    //hacer otra cosa
  }
} else {
  //hacer una tercera cosa porque no existió el elemento
}
if (exists tercero=lista[2], tercero>5) {
  //Aquí sólo entras si el tercer elemento de la lista es mayor a 5
} else {
  //Aquí entras si no existió el elemento o si es menor o igual a 5
}

assert(exists tercero=lista[2], tercero > 5);
//Si no existe el elemento o es menor o igual a 5 se arroja excepción y el código de aquí abajo ya no se ejecuta

Los assert de Ceylon no son como los de Java que se pueden desactivar; en Ceylon, los asserts siempre se van a ejecutar.

Imagen de ezamudio

Ceylondoc

Ya cuando navegues en Herd puedes llegar a esto, la documentación del módulo de lenguaje:

http://modules.ceylon-lang.org/modules/ceylon.language/0.5/doc

Imagen de Cid

Manadas y elefantes

Ceylon es por Ceylan imagino yo creo que un pais asiatico con selva o algo así. Gracias por la información y que bien esperemos que salga todo bien ya este año.

Muy util ese tipo de documentación.

Gracias.

Imagen de ezamudio

Ceylon y Java

El lenguaje Java se llama así por la isla de Java, famosa por su café.

El lenguaje Ceylon se llama así por Ceylán, ahora llamado Sri Lanka, famoso por su té.

Imagen de Jvan

Excelente

Excelente entrevista!

Últimamente he estado echándole un vistazo a Scala y veo algunas similitudes prácticamente la parte de los Trais de Scala para soportar la herencia múltiple (mixin) veo que en Ceylon es muy parecido si no hasta igual, eso me parece un gran acierto, además de que están haciendo algo como lo del "Some". Otra cosa que me gustó es que se estén enfocando bastante en la parte de que el código quede entendible, creo que eso es fundamental y es algo de lo que efectivamente carece Scala y muchos otros nuevos lenguajes. Pero sin lugar a dudas lo que más me gustó fue lo de "union" para los tipos, eso no lo había visto en ningún lenguaje (como tal).

Me llama mucho la atención la parte de JSON, es decir, tienen la idea de integrar una API para JSON como parte del lenguaje? sería genial tener la misma API del lado del server como del lado del cliente (Javascript)

Sé que la charla fue de Ceylon pero cual es la perspectiva del equipo de Ceylo hacia "Kotlin"? ya que en varios sitios los ponen como rivales :p

Imagen de ezamudio

JSON

En el SDK hay un módulo para JSON, disponible en Herd y está compilado a bytecode y JS para poder usarlo en ambos lados.

De Kotlin prefiero no hablar.

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