Ceylon: El proyecto secreto de RedHat que ha mantenido a Gavin King muy ocupado
Hace mucho tiempo, Gavin King anuncio en su blog que se iba a retirar a trabajar a un proyecto secreto que le llevaría bastante tiempo. Este lunes ha hecho un sneak peek de dicho proyecto: El proyecto Ceylon.
Aqui pueden ver muchos de los detalles de las presentaciones de Gavin King en el QCon Beijing
Y tambien ya hay entrada en la wikipedia Revisen al final de la entrada, hay unos PDFs que uso Gavin para presentarlo, no tienen desperdicio
Creo que RedHat se esta equivocado mucho con este proyecto. Se han tardado 2 años en hacerlo y dicen que a finales de año estará listo el compilador. Existen muchos lenguajes para la JVM como Groovy, Scala, Clojure, etc. que tienen mucha mas masa critica de usuarios y desarrolladores. No hace falta otro lenguaje, menos aún con lo horrible que es Ceylon.
¿Necesitamos otro lenguaje? ¿Gavin King olvido como hacer proyectos (Hibernate fue muy exitoso por ser abierto, Ceylon ha sido desarrollado a piedra y lodo)?
Ojala mejoren las cosas para Ceylon, no se tarden tanto y que RedHat no nos quiera vender otra moto (Ceylon) con un conjunto enorme de herramientas para usarlo.
¿Ustedes que opinan?
- domix's blog
- Inicie sesión o regístrese para enviar comentarios
error
En mi opinión es un error. Incluso la manera en que lo presenta (vi el Google Doc que tuiteaste anoche); parece que quiere evitar decir "nuevo lenguaje de programación sobre JVM" hasta el último momento. Primero se la pasa echándole flores a Java, esa parte está interesante porque últimamente la moda es tirarle caca al lenguaje y él resalta varias cosas buenas, luego se pasa a las cosas malas (sin tirarle caca, se ve bastante objetivo) y luego muestra que tienen un nuevo lenguaje. Pero que ni corre ahorita ni compila ni nada, está en etapa conceptual, etc.
Creo que estaba tratando de evitar la reacción que seguramente muchos (incluyéndome) tuvieron: ashhhhhhh otro lenguaje para la JVM? Y además uno que promete hacer muchas cosas que hoy ya se pueden hacer con Scala y con Groovy.
Y el último comentario en la presentación donde muestra la mundo su proyecto ultrasecreto de 2 años, es que no sirve de nada si no es como comunidad. Se me hizo hasta hipócrita.
La verdad se me hace un desperdicio, porque esos 2 años los pudo haber aprovechado (él y su equipo) en meterle mano a Groovy y/o Scala y mejorarlos, pero no, prefirió hacer su proyecto "yo también", tal vez porque cree que teniendo el respaldo de Red Hat, va a "ganarle" a los lenguajes que ya existen y funcionan hoy.
La verdad no puedo dejar de verlo como un destello de ego, nada más. Por mi parte recibirá el mismo interés que Go: sé que existe, he visto un poquito de la sintaxis, pero no lo tengo instalado ni le voy a dedicar tiempo en aprenderlo ni nada. Y si la comunidad de Ceylon va a ser tan amistosa como la de Hibernate, menos futuro le veo.
Me gusta vs No me gusta
Cosas que me agradan:
Cosas que no:
En conclusión... (hasta yo estoy sorprendido) creo que... me gusta... aunque.... pero una parte de mi cree que seria mejor emplear el esfuerzo en estabilizar a Scala (aunque por otro lado, Ceylon se ve mucho mas interesante que Go y definitivamente me gusta mas que el enfoque epiciclico de Groovy... si Scala no existiera, le veria mucho futuro a Ceylon)
Por otro lado, como dijo ezamudio: "si la comunidad de Ceylon va a ser tan amistosa como la de Hibernate", Ceylon no tiene futuro.
epiciclos
Y dale con eso... nos podrías iluminar explicándonos por qué crees que Groovy es agregarle epiciclos a Java?
Ah y "deprecated" es una anotación en Java, no sé qué tiene de novedoso en Ceylon. Y los closures, pues sí qué bonitos, pero Scala y Groovy los tienen hoy, igual que named parameters, currying (al menos Groovy lo tiene). Ceylon es prácticamente vaporware. No se ve que lo vayan a hacer abierto ni libre. Ah pero eso sí, necesitan una comunidad o no sirve de nada...
YAJVML, pero eso es bueno.
Shiaaaales ¿Por que otro lenguaje? :P
En términos generales me gusta, me gusta incluso más que Scala. Hay algo muy importante aquí, la sintaxis de Java es muy simple y eso es bueno porque genera buenos hábitos, te acostumbras fácilmente y puedes deducir como se debe de escribir algo. Me parece que este es uno de los puntos importantes que Ceylon cubrió ( o mejor dicho cubrirá ) y es donde principalmente Scala flaquea. En Scala la syntaxis varia tanto que se podría escribir algo que fuera totalmente ajeno a la familia C/C++/Java. Me parece que la razón es porque querían agradar a la comunidad Haskell y ML.
Lo que no ví en la presentación fue nada que dijera "structural type". Para mi, el structural type es la neta del planeta, lo mejor de Go, disponible en Scala pero de una forma un tanto rara y lo que más trabajo va costar implementar. Básicamente el structural type es algo como lo siguiente:Con el structural type se podría usar una instancia de cualquiera de los dos objetos. Esto es idéntico al ducktype en los lenguajes dinámicos, con la gran diferencia que es el compilador y no el runtime el que reportaría el error:
El compilador sería el encargado de revisar que el objeto pasado responda a "getName" sin necesidad de que A) herede de una clase que tenga ese método B) Tenga de declarar que implementa una interfaz.
Lo siguiente sería un error de compilación:
Pero lo siguiente funcionaría
Esta es una de las razones por la cual Go puede hacer código tan compacto y tan genérico, se pueden programar operaciones sobre un tipo sin forzar a que se implemente una interfaz específica. Es tan útil que me parece extraño que no sea desde hace ya mucho tiempo algo que todos los lenguajes tengan.
Volviendo a Ceylon cosas que me gustan y cosas que no.
- SI Top level methods.
- SI Tener cosas como anotaciones en vez de palabras reservadas.
- NO String interpolation.
- SI Default optional parameters.
- NO,NO Tener forzar el tipo opcional
-SI Inmutabilidad por default en "variables" ( bueno si son variable ya no son inmutables no?, pero así dice el slide ) . Por cierto, ¿que símbolo representaría mejor que el atributo es "variable"?. Scala lo hace con "val" para valor ( immutable igual que final en Java ) y "var" para variable ( default en Java ) Si hubiera que elegir un solo simbolo yo escogería "!" pero se confunde muchísisimo con la negacion en Java:
Pero nomás no me suena, si a alguién se le ocurre algún símbolo que represente "variable" por favor mencionarlo.
- SI shared, me gusta más que "Public", "private" ( upper y lower case ) en Go
- SI getter
- SI No usar
- SI Atributos sobreescribibles
- NO local. Solo para complacer al compilador, no me parece suficiente razón.
- NO := vs =
- Meh Falta de constructor. Puede ser muy útil para declarar subclases en linea, pero no sé. Suena peligroson.
- Meh Sequences
- SI High Order functions
- SI Closures
- No tentendí Named arguents.
- SI Sobreescrutura de operadores a la Ruby/Groovy. Me gusta esta linea ...people end up defining operators like @:+> resulting in intriguing,
executable ASCII art, not plain, readable code. Por otro lado, el no permitir la sobreescritura de operadores deriva en código terriblemente "verbose" como cuando se usa esto. Scala, Ruby y Groovy, hacen truco invocando un método cuando se espera el operador lo cual no me parece muy "limpio" pero sin duda es muy efectivo. Scala va más allá permitiendo que cualquier método pueda llamarse como un operador ( o mejor dicho, que el "." punto sea opcional ) Mi propuesta, que no haya operadores para empezar ( si ya sé creo que es la propuesta más "atrevida" y quizá una razón para verdaderamente odiar un lenguaje pero "pus. ya ni modos...". )
- SI Modelo de herencia. Similar al de Scala pero con sintaxis más "amistosa"
- NO Type narrowing
- SIEnumerated subtypes
- Paso Generics
Algo que me gusta es que al menos en apariencia es más breve y simple que Scala y que intenta traer conceptos de la programación funcional al mundo orientado a objetos, sin rayar en ser un lenguaje híbrido, más bien con un enfoque práctico.
Algo en lo que Groovy simplemente será diferente siempre, es en su naturaleza dinámica y con eso se evalúa en otra categoría.
Groovy++ y Mirah parecen tener buenos avances para traer el dinamísmo al lado del tipeo estático.
Scala sin duda va a la delantera pero sigue pareciendo un tanto complejo.
A ver si este Ceylon, logra su objetivo de ser un lenguaje que caiga en el correcto punto intermedio, justo donde ahora parece estar C#.
Supongo que debo admitir que es una cuestion medio irracional
Pues siento que es forzar a java como sintaxis, agregando elementos que sencillamente no se siente como Java mejorado, si no como Java parchado, en Scala toda la sintaxis se siente coherente, en Groovy la sintaxis nueva (al menos a mi) me parece obviamente "un agregado posterior, y de un autor diferente"
Por otro lado, por lo que leido, la similitud sintactica con Java puede resultar engañosa produciendo comportamientos inesperados. Aunque siendo sinceros supongo que debo admitir que es una cuestion medio irracional (Scala me gusta mas que Groovy por su consistencia interna)... tal vez deberia jugar un poco con Groovy ver si le agarro el gusto.
Que no solo es deprecated la que es una anotacion.
Aqui si coincido, si Scala no existiera, tal vez Ceylon haria sentido, pero como si existe...
De acuerdo de nuevo, si quiere un lugar, va a tener que pelear muy duro, y si no es ni abierto ni libre, en mi opinion morira pronto...
Re: epiciclos
Hace rato el mismo @luxspes hizo una entrada dedicada a los epiciclos javalísticos (ver entrada aquí)...Pero en pocas palabras creo que quiere decir que Groovy es Java pero más revuelto (y esa es la misma impresión que me da a mi); creo que estoy viendo muchas cosas en combinación pero no estoy viendo Groovy (o algo original), para mí Groovy es todo menos conciso.
En cambio por ejemplo Scala, se me hace más limpio y conciso (aunque claro, me dicen: "Primero aprende bien Objective C y ya me dirás si Scala no te parece un batido").
Con respecto a la entrada, creo que son suficientes los puntos que @ezamudio ha tocado: Ceylon apenas va a implementar cosas que Scala, Groovy, Clojure e incluso Python o Ruby, ya hacen y todos disponibles para la JVM. Lo que vi de Ceylon, no me agradó.
Java vs Groovy
De acuerdo con lo de los comportamientos inesperados. Esa técnica de marketing "si sabes Java, sabes Groovy" resulta engañosa cuando sabes demasiado Java :)
Y pues a ver qué dicen de Ceylon en cuanto a licencia. Sería hipócrita que no lo hagan software libre, viniendo de Red Hat (y de Gavin).
Opciones
Tanto Groovy como Scala me gustan mucho, y tengo el gusto de usarlos todos los días en problemas reales. Con Groovy trabajo desde hace mucho tiempo y me gusto mucho que pudiera usarlo muy rapido debido a la sintaxis. Me agrada mucho que se puedan hacer las cosas de muchas maneras, eso ayuda a que podamos usar el lenguaje según la experiencia de cada quien. Eso es importante para mi, porque es muy complicado encontrar a alguien que sepa Groovy o Grails. En mi equipo actual los desarrolladores escriben código como se sientan mas cómodos, eso nos ha permitido ser productivos muy rápido en un negocio que se mueve tambien muy rápido.
Esas "facilidades" de hacer las cosas diferentes, permite romper el lenguaje tanto como experiencia tenga el desarrollador, hay quien apenas tiene unos meses con Groovy y lo usa muy a la Java, pero tambien a veces a mi me gusta escribir DSLs o hacer metaprogramación. Siempre depende.
Scala es un lenguaje muy gordo, cuesta mucho aprenderlo (sobre todo el paradigma funcional, cuesta para el desarrollador Java promedio siquiera entender este paradigma, sobre todo casi siempre ha hecho programación imperativa). Las construcciones que se pueden crear en Scala son maravillosas y a veces tambien cuestionables ()
Sobre Ceylon, pues... Yo prefiero mejorar mis habilidades en Groovy y Scala como lenguajes alternativos en la JVM, que perderme en el capricho de Gavin King.
Re: Opciones
Pues aprender Scala, no me parece algo difícil. Cómo bien dices lo difícil es aprender a combinar los paradigmas Orientado a objetos y funcional. Lo de menos es aprender un lenguaje.
Gavin King ha contestado
Gavin King ha contestado algunas preguntas sobre Ceylon en InfoQ
La cuestión con Groovy, Pyhon
La cuestión con Groovy, Pyhon ( Jython ) y Ruby ( via JRuby ) es que son de tipeo dinámico. Entonces muchos de los errores que pueden ser detectados estaticamente ( por el compilador ) serán detectados hasta que el programa se ejecute ( por el runtime ), el refactoring automátizado ( sin supervisión humana ) se complica mucho y al final habrá siempre un extra de overhead.
Por ser de naturaleza dinámica no se pueden comparar justamente contra lenguajes que son de naturaleza estática, hay muchas cosas que los de naturaleza dinámica pueden hacer al vuelo ( como el duck type ) y que a los otros les cuesta mucho trabajo es una comparación injusta porque parte del trabajo que el lenguaje le quita el programador, se lo pasa al runtime.
Por cierto si alguien tiene
Por cierto si alguien tiene un link y/o me puede explicar eso de covariace y contravariance cuando se refieren a los generics por favor que me diga, porque mi cabeza siempre empieza a oir en automático "blah, blah, blah, blah" cuando veo esas dos palabras. Se me hace que puede ser algo super sencillo pero a veces así funciona mi cabeza, algunas palabras activan el modo
covariante, contravariante
covariante es cambiar el tipo de dato de algo general a algo más específico. Por ejemplo en Java 5 metieron valores de retorno covariantes. Esto significa que si extiendes un método que por ejemplo devuelve Number, tu implementación puede devolver Integer, que es una subclase de Number. O si una interfaz define un método que devuelve una interfaz, cuando tú extiendes ese método puedes devolver una implementación de dicha interfaz (bueno, más que devolver, me refiero al tipo de valor de retorno que declaras en el método). Ejemplo:
Contravariante es lo contrario: irte de algo más específico a algo más general. Esto no sería posible en tipos de retorno, pero hay quienes discuten que se debería poder con los generics. Por ejemplo:
En Java 5, no se puede hacer ninguna de las dos cosas (sí, la declaración de
Ah, y link a la descripción más completa en wikipedia.
El disparate bíblico de la Torre de Babel
con esa frase concluye García Marquez el prólogo del disco "Pablo Querido" de Pablo Milanés.
Parece ser que el Dios de la Ciencia de la Computación también está enojado porque queremos alcanzar "el cielo" y nos bombardea con numerosos lenguajes de programación.
Debo confesar que estoy de acuerdo con ese Dios, porque no me obliga a usar esos lenguajes pero me los ofrece.
Son cientos los lenguajes de programación que existen. Esa rica oferta también tiene algo extremadamente beneficioso y es que los lenguajes que ya son mainstream, se enriquecen mucho más copiando (en el buen sentido de la palabra) lo que otros lenguajes ofrecen para darnos más posibilidades.
La discusión en este hilo es una discusión que se ha dado ya, en otros tiempos. Por ejemplo en el mundo de los lenguajes basados en Lisp.
Pienso entonces que la idea de Gavin King de dispararnos otro lenguaje de programación en principio es buena, aunque por lo pronto es imposible decir si además de la idea, el lenguaje es bueno. Aunque es bastante difícil calificar de bueno absoluto a cualquier lenguaje que haya existido.
Creo también, que a pesar de lo que dicen, Gavin King respalda su ego con productos creados que toda la industria utiliza. Desconozco que disponga del background en el área de los lenguajes de programación, pero asumo que lo tiene.
Leí lo que domix referenció en su post. De las críticas que hace G. King de Java, considero que la más importante es la ausencia en Java de soluciones built-in para la modularidad, que ya existían en otros lenguajes y que por ejemplo Scala las tuvo en cuenta y las incorporó.
Honestamente no ví nada en los slides que provocara que se me cayera la quijada de asombro ante tal novedad. Quizá hace 10 años me habría asombrado.
El tiempo dirá si Ceylon se convierte en algo importante y ocupa su lugar en la Torre de Babel. Cuando veo una nueva propuesta de un lenguaje siempre me acuerdo lo que escribió el creador de Groovy James Strachan:
"I'm very impressed with Scala! I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy."
Le apuesto a Scala, pero mi forma de atacar un problema con este lenguaje es diferente a atacar el mismo problema con Java.
Coinicido con domix al decir que es un lenguaje "gordo", si con esa palabra quiere decir que es más difícil de aprender que Java . Sería bueno que los que argumentan que es fácil de aprender que pasen la receta.
Varianza en Java y en Scala
Los conceptos de covariante, contravariante e invariante son muy importantes en la teoría de tipos y forman parte de todo el rollo asociado con los tipos algebraicos, que Scala soporta con un sistema de tipos bastante complicado pero muy poderoso.
Java brinda soporte para los tres casos, pero mientras Scala define el comportamiento variante de los tipos en el sitio de declaración (declaration site), Java lo hace en el lugar de la llamada (call-site). Esa diferencia es significativa y hace que Scala sea más poderoso para manejar la varianza.
Estos conceptos pueden entenderse con ejemplos de colecciones genéricas, aunque por supuesto que se aplican para cualquier construcción del lenguaje que sea parametrizada con tipos, como es el caso de los métodos polimórficos de Scala o las clases Function1 .. Function22.
La clase
Esto asegura que por ejemplo
La interfaz
Esto implica que
Java mezcla de forma incorrecta el comportamiento variante con los "type bounds" debido a que no puede definir el comportamiento variante en la declaración del tipo genérico.
Una de las críticas que hace G. King en su presentación de Ceylon tiene que ver precisamente con esas pequeñas broncas que tiene Java con el manejo del comportamiento variante y la especificación de los lower and upper type bounds (me cuesta trabajo poner esos conceptos en español).
Así es BFerro, no hay nada
Así es BFerro, no hay nada nuevo y sorprendente en lo mostrado y la esperanza que queda es que la implementación sea buena y que al final lo que aporte Ceylon sea que todas esas cosas que ya conocemos se puedan usar más fácilmente con este lenguaje. Lo paradójico de esto es que si se mostrara algo realmente innovador sería tipo "uh... y eso para que lo queremos". Me imagino.
Hoy en día es "baratísimo" crear un lenguaje de programación para la JVM o el CLR, buena suerte a los que quieran aventarse el paquete completo de sintaxis + bibliotecas + plataforma. Sin menospreciar a los que SI saben de lenguajes de programación ( entiéndase yo no ) es tan fácil como leer la entrada y general el bytecode correspondiente, ya no hay que preocuparse por todo el ecosistema que hay alrededor, por tener que crear toda la biblioteca estándar, por tener que acceder a los diferentes procesadores y arquitecturas es casi casi como general un jsp; aclaro que esto es una sobresimplificación mía y puedo estar totalmente equivocado.
Pues si, un lenguaje más. Pero claro, no estamos obligados a aprenderlo ni nada. Supongo que es como una moda, antes todos hacían webframeworks ( bueno aún se hacen ) luego frameworks de no se que, ahora toca el turno a los lenguajes, mañana van a volver a inventar el FTP o el e-mail o hasta la línea de comandos. Lo bueno es que en cada iteración se quedan cosas buenas y se general algo de innovación que va dando pie a verdaderas innovaciones a la larga.
Esto me recuerda el siguiente video ( casi de 1 hora ) donde el anterior CTO de Google Douglas Merril, habla sobre innovación.
Algo que recuerdo es precisamente esto. Se puede innovar de dos maneras ( en mis propias palabras ) , 1.- Te levantas en la mañana y de golpe y porrazo se te ocurre algo realmente diferente. 2.- Vives en un ecosistema en el que cada vez que hace algo ligeramente diferente se innova; después de miles de iteraciones terminas con algo que es totalmente diferente a lo que existía, digamos 5 años antes. Este es el approach de Google.
Por cierto. Scala tampoco
Por cierto Scala tampoco tiene este sistema de modularización ( tipo Maven o OSGI ) y Java lo va a incluir para Java 8
Del primer PDF se lee en "Why we are frustrated":
• Lack of a language-level modularity solution resulted in the creation of
monstrous, over-complex, harmful technologies like Maven and OSGi.
Y en las respuestas en InfoQ dice:
[...] We're basing the module runtime on a project called JBoss Modules that will also form the core of JBoss AS 7.
No es ese tipo de modularización
La crítica a la que se refiere G. King con respecto a soluciones modulares es otra cosa. Lo que propone y es lo que Scala tiene, es que los mismos conceptos sean usados para programming in the small and programming in the large. Mejor copio lo que M. Odersky escribe al respecto:
Module systems of functional languages such as SML or Caml excel in abstraction; they allow very precise control over visibility of names and types, including the ability to partially abstract over types. By contrast, object-oriented languages excel in composition; they offer several composition mechanisms lacking in module systems, including inheritance and unlimited recursion between objects and classes. Scala unifies the notions of object and module, of module signature and interface, as well as of functor and class. This combines the abstraction facilities of functional module systems with the composition constructs of object-oriented languages. The unification is made possible by means of a new type system based on path-dependent types.
Sobre varianza y covarianza y contravarianza
Vaaaaya... muchisimo más claro despues de leer lo que dicen ezamudio y bferro.
Ahora si puedo volver a leer todas esas cosas en Scala y Ceylon y ya verlo con "otros ojos".
Barata las tortas del mercado
No mi estimado Oscar (OscarRyz). Crear un lenguaje de programación es algo extremadamente complicado para lo que se necesita un background extenso en varias áreas de Computer Science. En mis años mozos tuve que crear un simple lenguaje para escribir el código de las tareas de entrenamiento de un robot de pintura mediante un hand held teach control. El lenguaje final fue muy simple, pero la sangre sudor y lágrimas en el camino fueron abundantes.
@Bferro Jeje si lo sé, bueno
@Bferro Jeje si lo sé, bueno más que saberlo lo imagino. Mi punto es precisamente ese, ahora estos lenguajes no tienen que hacer toda la plataforma Java ( todo la Virtual Machine ) sino que simplemente se sientan sobre lo existente. Me imagino que en tu caso fue totalmente desde cero y entrandole directo al ensamblador del robot ese no? Es bastante diferente.
Pero sí, no los demerito, pero me parece que tiene más merito Go o incluso Ruby y Python ( ya no tan nuevos, 18 y 21 años respectivamente ) por aventarse tooodo el paquete desde cero a estos nuevo lenguajes sobre la JVM, a eso me refiero.
no confundas
Estás confundiendo lenguaje con plataforma. El lenguaje Java es una cosa, la plataforma Java es otra cosa. El lenguaje es la sintaxis que usas, las palabras reservadas, las construcciones válidas que se pueden hacer con esas palabras y la sintaxis, etc. La plataforma es todo ese ecosistema de clases del que hablas.
Crear la plataforma Java fue un esfuerzo monumental. Crear el lenguaje Java debe haber sido tan difícil como crear el lenguaje Ruby o Go, me refiero a diseñarlo. No es algo que puedas nada más empezar a hacer conforme se te ocurren cosas, es necesario mucho trabajo de diseño formal, como te mencioné alguna vez hablando de Ryz, hacer tus BNF y cosas así. A eso se refiere bferro. Sé que tú hablas de que ahora es muy fácil porque ya no tienes que crear mil clases para hacer un lenguaje orientado a objetos, simplemente "te cuelgas" de la JVM o el CLR y ya tienes un montón de clases que se pueden utilizar en tu lenguaje, solamente estás haciendo la sintaxis y las palabras reservadas y cosas así, pero eso no hace menos difícil la creación de un nuevo lenguaje, al menos no de uno que valga la pena.
Pero incluso si me hago ahorita un lenguaje "ezlang" y lo único que hago es cambiar todas las palabras reservadas de Java por otra cosa pero mantener toda la sintaxis idéntica, implementarlo no estará tan fácil, y eso que ya medio me salté toda la parte de diseño (aunque tengo que ser muy cuidadoso a la hora de escoger mis palabras reservadas para no generar alguna inconsistencia con los nombres de clases base de Java o incluso inconsistencias internas, etc).
Uy no no no. Un lenguaje no
Uy no no no.
Un lenguaje no es solamente su sintaxis. Más importante aún es la semántica e igual de importante que los dos anteriores son las bibliotecas base. Son ellas las que le dan la personalidad al lenguaje. ¿Como sería Java si
C está ligado a UNIX, C# a .NET. Incluso Groovy y Scala le dedican gran parte de sus 200+ kloc a las bibliotecas base y aún así no tuvieron que incluir ni en el diseño ni en la implementación todas las capas que conforman la JVM.
La implementación es importantísima, incluso más que el diseño hasta cierto punto. Para constatarlo basta agarrase un rato usando Javascript en IE vs. SpiderMonekey ( Firefox ) y V8 ( Google Chrome ).
La especificación de Java fue escrita después del la implementación del lenguaje y Ruby ni siquiera tiene una a la fecha.
La carreta va detrás de los bueyes
Todo lenguaje de programación se diseña y crea "from scratch" con independencia si su run time es una arquitectura de hardware, como es el caso de C, o una arquitectura de software como es el caso de Java. Por eso se llama máquina virtual, con un procesador virtual, que en el caso de Java tiene un instruction set de tipo stack con su "código de máquina y su lenguaje ensamblador muy bien definido.
Conozco profesores que enseñan arquitectura de computadoras con máquinas virtuales.
Que se diseñe desde cero no quiere decir que haya que inventar todo lo que se requiere para los procesos de parsing, translation and compiling. Todo el mundo utiliza técnicas bien establecidas para eso.
Las bibilotecas de funciones o clases se diseñan una vez que ya tengo diseñado el lenguaje. Primero los bueyes, y después la carreta.
Es mas que claro saber que
Es mas que claro saber que todos aqui estan fastidiados de los muchisimos lenguajes que se han creado... en mi caso, hasta el momento estoy pensando seriamente aprender seriamente una alternativa a Java. en mi caso he elegido Groovy por su "facilidad" y con esto no me refiero (como dice bferro) a que sea facil de aprender, pero tiene mas accesibilidad para aspectos básicos que se puedan hacer. Digamos he leido las ultimas publicaciones de Ezamudio y he visto que no todo se queda en las bondades de Groovy sobre Java, incluso he pensado que el mismisimo Groovy aun tiene cosas que seria interesante implementar como la sobre carga de operadores (mencionadas en una entrada de Enrique)
A mi no me enfada saber que viene Ceylon incluso no me da igual, porque mientras no lo pruebe no puedo saber si es mejor o peor que alguno que si haya utilizado
En cuanto al manejo de la contravarianza y covarianza yo (a mi punto de vista) digo que si las maneja Java, no de la forma que menciona enrique en su ejemplo
En java tiene su modo pues tu le dices que tipo de dato vas a trabajar en este caso en una coleccion y de ahi se hace algo (que yo conozco como) UpCast y DownCast que segun entiendo es lo mismo:
aunque es cierto que no puedes hacer directamente:
....
creo que me desvie un poco, bueno regresando a lo de Ceylon, yo le veo muchas bondades aunque si comparto que haya sido mas por vanidad del autor que por necesidad. Cuando salga su primer version ya estaremos todos o sorprendidos o desilucionados pero si es seguro que lo aqui publicado puede ser un adelanto para el momento que lo lanzen