Y la alternativa podría llamarse ObjectiveJ

Bueno, cómo es por todos los desarrolladores Java conocido que los problemas se hacen ver a simple vista (gente importante de Sun -ahora Oracle- renunciando, problemas con demandas que si con Google o cualquier otra VM Java-like, con un JCP moribundo, etc.) y muchos desarrolladores cómo yo estamos en el dilema de: "Continúo o no en Java a futuro", es decir, a día de hoy estamos básicamente en dos posiciones.
La primer posición es la de las personas pro-open source que dicen que Oracle terminará el legado de Java y ésta dejará de ser la herramienta por excelencia de los desarrolladores promedio y pasará a ser utilizado únicamente por empresas multinacionales (casi cómo lo maneja ahora con Oracle DB).
La segunda es de personas muy entusiastas que ven esta situación cómo una gran ventaja, el grande de las bases de datos con el grande en programación y sus agregados, lo cual (en teoría) nos permitirá hacer cosas muy robustas e interesantes.

¿Quién tiene la razón? El tiempo nos lo dirá. Mientras tanto creo que es buen momento para voltear al mundo y ver que más nos ofrece, ya sea por cultura general o por una alternativa en caso de que ocurra lo que la gente de la primera posición comenta.

¿Y cuales son esas alternativas?
Gracias al trabajo de muchas personas tenemos a nuestra disposición una cantidad de herramientas para aventar al cielo, desde los clásicos de clásicos lenguajes compilados (C/C++, Objective C) hasta los lenguajes con más factor boom (a día de hoy) de scripting (Ruby, Python). Sin embargo menciono pocas, porqué si bien sabemos lenguajes que corren en la JVM dependen de lo que Oracle disponga, por lo que necesitaríamos buscar algo alejado de JVM, ya después si sabemos que JVM (y su ecosistema) siguen cómo lo hacen a día de hoy, entonces será bueno echar mano de alternativas cómo Groovy, Scala, etc.

El problema de elegir un lenguaje de programación es ver "de donde vengo y a donde me dirijo". Hace unos días con un conocido hablando de este tema le comenté: "Oye pues tu eres experimentado en C++, ¿qué problema hay si tienes que regresar?" y su respuesta fue: "Precisamente regresarme, quise avanzar a alto nivel, volver a C++ no me gustaría del todo para hacer aplicaciones web.". Todo está en ver que se quiere (seguir) hacer(ciendo).

Yo por curioso, me puse a ver Python y Ruby; y la verdad que no están nada mal, me gustan; pero simplemente creo que la sintáctica de java es muy cómoda, ayuda a explicar cosas "al canto". Y seguí en mi búsqueda...hasta que por alguna extraña razón vi este framework. Mi impresión fue (al principio) de decepción porqué vi que decía: "Objective J", lo que me hizo pensar que sería lo bizarro de Objective C con palabras Java y me hizo pensar lo PEOR DE LO PEOR, que sería mono-plataforma. Después de leer la documentación toda impresión cambió.

Francamente lo veo cómo una alternativa viable, sobretodo para aquellos que ya le hemos jugado un poco con Objective C (o para aquellos que aprendieron en esta plataforma).

¿Ustedes que opinan, es viable o no utilizar Objective J? ¿De ser viable lo usarían?

Comentarios

Opciones de visualización de comentarios

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

prueba del tiempo

yo habia visto capuccino (solamente el sitio, lei algo al respecto, no lo he usado) como en 2003. Hay que ver si realmente le han estado metiendo mano en todo este tiempo o si es un proyecto abandonado... tambien hay que ver si alguien lo esta usando, si hay algun sitio o aplicacion que sea visible en internet y que haya sido hecha con este framework.

En cuanto a Objective-J, no me queda muy claro si es usar sintaxis de Java para compilar cosas a ObjC o si es usar sintaxis de ObjC para compilar a java bytecode (si es lo segundo esta mas interesante pero si es lo primero no le veo el caso). Para mi, tiene mas peso el acervo de clases y componentes que tengas a tu disposicion, que la sintaxis del lenguaje.

Nap, yo veo mucho más

Nap, yo veo mucho más factible Go e incluso D, pero no le veo mucho a ObjectiveJ el hecho de estar orientado únicamente JavaScript lo limita mucho.

Lo que es verdad ( e importante saberlo ) es que ni Java, ni C++, ni C perderán su lugar, pues son solo herramientas, solo surgirán nuevas y surgiran nuevo usos.

Re: prueba del tiempo

Pues lo que he visto en Capuccino es que se usa código tipo Objective C, pero se combina con JavaScript (a lo que me da a entender sólo compone el front-end). Es algo raro (de por sí, Objective C es algo poco estándar para el desarrollador promedio), a mi me gustó y me llama la atención.

Y cómo bien dices: "Al tiempo", sólo sabremos que pasa con Java y creo que los cambios se verán a partir de que se libere Java 7. Otra nota que leí es que al parecer si quieren extender Java, matan JavaFX Script y a JavaFX le dejan lenguaje Java =), creo que por ese lado JavaFX puede resurgir (y quizás quite las incertidumbres).

Imagen de luxspes

Objective-JavaScript

En realidad la J de Objective J, no es por Java, si no por JavaScript. Objective-J extiende a Javascript dandole una sintaxys Objective-Cera. Supongo que se le podria hacer correr fuera del browser y "sobre Java" usando Rhino. Por otro lado, Java ya perdio la batalla de las RIAs (JavaFX esta muerto), y en mi opinion bien podria pasar que en el futuro Javascript destrone a Flash (por otro lado, ActionScript es un "super javascript con extensiones para clases, asi que quiza mas bien lo "entrone?". Microsoft ya dijo que tambien se va a concentrar en Javascript y HTML5 (en ves de Silvelight) asi que bien podria ocurrir que JavaScript triunfe donde solo Flash a sido rey... (y si Objective-J realmente mejora a Javascript...)

Silverlight

Microsoft nunca ha dicho que se va a concentrar en JavaScript y HTML 5 en vez de Silverlight, lo que sí dijo es que se va concentrar en JavaScript y HTML 5 además de Silverlight.

Creo que tanto las tecnogías RIA (Flash/Silverlight/JavaFX?) como HTML/JavaScript tienen sus lugares bien definidos y no compiten entre sí, cada una se aplica a para diferentes cosas.

Imagen de ezamudio

diferentes?

Como qué cosas diferentes? yo lo que veo es que entro a una página web y está hecha con HTML y Javascript, o está hecha con Flash, o con silverlight. Si entro a mixupdigital, silverlight (y está horrible el sitio pero no sé qué tanto tiene que ver que sea silverlight y qué tanto es de que lo programaron horrible). Si entro al sitio de prácticamente cualquier restaurante de México, Flash por todos lados (creo que nadie le ha avisado a los restauranteros que sus sitios son imposibles de usar en dispositivos móviles). Esos sitios en Flash, si no usaran Flash, usarían Silverlight, o usarían HTML+AJAX. Por lo tanto yo creo que esas tecnologías sí compiten entre sí.

Incluso para aplicaciones verticales, intranets, etc, la decisión siempre es: lo hacemos con Flash/Silverlight/etc o lo hacemos con puro HTML+AJAX? Creo que eso sería la definición de tecnologías que compiten entre sí.

Una vez más desviaaaaaandonos

Una vez más desviaaaaaandonos del tema ( o mejor dicho complementandolo ) aquí les va esta presentación que ejemplifica lo que está mencionando Enrique.

http://slides.html5rocks.com/#landing-slide

( Creo que lo tienen que ver con Google Chrome )

La linea entre HTML5+Javascript y los otros es cada vez más tenue.

Diferentes

Me refiero a que cuando ves sitios con Flash/Silverlight como en los restaurantes de México, es porque no están aplicando la tecnología apropiada. Quizá debería haber aclarado que como HTML+AJAX y Flash/Silverlight son tecnologías muy diferentes, deberían tener aplicaciones diferentes. Por ejemplo, en mi caso, utilizo HTML+AJAX para portales y aplicaciones web públicas, y utilizo Silverlight sólo para aplicaciones LOB.

Imagen de Sr. Negativo

Yo continuo con JAVA...

Definitivamente.

Imagen de luxspes

Claro que compiten

Microsoft nunca ha dicho que se va a concentrar en JavaScript y HTML 5 en vez de Silverlight, lo que sí dijo es que se va concentrar en JavaScript y HTML 5 además de Silverlight.

IE9 trae soporte para animacion acelarada por hardware a nivel HTML5, en cuanto las herramientas de diseño grafico (de Adobe y mismo Microsoft) permitan generar facilmente animaciones para HTML5, sera el principio de una durisima competencia contra Flash y Silvelight por parte de precisamente sus creadores... si puedo hacer todo lo que hacen Silvelight y Flash sin tener a ninguno de los 2... para que complicarme la vida y complicarsela a la audiencia de mi sitio?

No encuentro ahorita la liga, pero recuerdo haber leido que Microsoft enfocaria a Silverlight para desarroll para WindowsPhone (el SDK de WP es basicamente Silvelight con extensiones para WP). Ahora, la unica plataforma que corre en todos los telefonos es?: HTML. no hace falta pensarle mucho para ver en que se va a enfocar Microsoft (y todos lo demas)

Creo que tanto las tecnogías RIA (Flash/Silverlight/JavaFX?) como HTML/JavaScript tienen sus lugares bien definidos y no compiten entre sí, cada una se aplica a para diferentes cosas.

Claro que compiten, y a muerte, y de todas la mas popular, y abierta es HTML/JavaScript (aunque en mi opinion sea tambien la mas atrasada y limitada tecnologicamente)

... si puedo hacer todo lo

... si puedo hacer todo lo que hacen Silvelight y Flash sin tener a ninguno de los 2...

Pero la cuestión es que con HTML 5 no se puede hacer todo lo que hacen Silverlight o Flash:

HTML 5 is no Flash or Silverlight killer
Top 10 Reasons why HTML 5 is not ready to replace Silverlight

para que complicarme la vida y complicarsela a la audiencia de mi sitio?

Ese es mi punto, que si voy a hacer un sitio, no me complico la vida y lo hago en HTML/JavaScript, pero las aplicaciones empresariales las hago en Silverlight 4 / WCF RIA Services, que para esas aún HTML 5 es complicarse mucho la vida pues Silverlight no se trata sólo de animaciones, transiciones, multimedia, etc.

Y sí, Silverlight ya es la plataforma de WP7, de hecho Nokia ya anunció que todos sus smart phones serán WP7, e IE9 trae aceleración por hardware y rendering con DirectX, pero no a costa de Silverlight.

Imagen de luxspes

Compiten, es solo que no los ha matado... (todavia)

Tu primer articulo, el HTML 5 is no Flash or Silverlight killer, es de 2009... ya estamos en 2011, acepto que hace 2 años, HTML 5 was no Flash or Silverlight. Ademas, copiaste el nombre del articulo incompleto, el nombre completo es: "HTML 5 is no Flash or Silverlight killer — yet"
que se traduce como: "HTML 5 no es todavía el asesino de Flash o Silverlight".

Que significa todavia?, segun la RAE: adv. t. Hasta un momento determinado desde tiempo anterior.

En otras palabras, esta en vias de llegar a serlo, si no, por que mencionarlo siquiera? Tendria sentido decir: PostgreSQL is no Flash or Silverlight killer, yet? o Oracle 11 Database is no Toshiba Satellite or Dell Inspiron Killer, yet? cualquiera puede darse cuenta de que no, por que efectivamente PostgresQL no compite con Flash, y la base de datos de Oracle no compite de forma alguna con las ventas de laptops de Toshiba o Dell... por otro parte HTML5 si compite directamente con Flash y HTML... el punto del articulo, es, sencillamente, que todavía falta un rato para que los mate, y en eso, estoy de acuerdo.

Por supuesto, la muerte podría tardar años en llegar o no llega nunca... todavía hay sistemas en cobol y fortran corriendo por ahi no? ;-) , pero de que compiten, compiten.

Claro, podría ser, en un

Claro, podría ser, en un futuro... en cuántos años? Silverlight cumple con los requerimientos de mis aplicaciones LOB (que no son todas) hoy, no cuando HTML 5 esté listo y tenga herramientas de desarrollo maduras, y los browsers principales tengan soporte decente, etc.

Además, cuando ese futuro llegue, no sabemos que tanto más habrán avanzado Flash y Silverlight, y si en realidad Silverlight "muere" a favor de HTML 5, será porque HTML 5 ofrezca una ventaja considerable en cuanto a facilidad y tiempo de desarrollo, herramientas, productividad, etc., y en ese caso será tiempo de poner a Silverlight en modo legacy y empezar los nuevos desarrollos en HTML 5 y todos contentos. Pero mientras ese supuesto futuro llega, utilizo lo que me funciona mejor.

Re: Claro, podría ser, en un

Creo que en este punto del partido, estoy de lado de @luxspes. Digamos, Adobe y Microsoft son sólo 2 empresas que desde luego apostaran a por todas con sus tecnologías propias. Sin embargo recordemos que W3C es algo más grande (en donde incluso Adobe y Microsoft entran al trapo), son muchísimas empresas que NECESITAN los estándares web para no tener que pagar por usar un plug-in específico o aun mejor para facilitarle la vida a los usuarios y que estos [los usuarios] y no tengan que descargar el plugin.

Si silverlight te ofrece todas las facilidades para tus aplicaciones a día de hoy que bien. Pero no quiere decir que siempre lo hará y parece que a futuro el que viene fuerte es HTML y más con las herramientas que muchas empresas/personas están desarrollando. Que con siemple HTML + CSS + JS hacen verdaderas aplicaciones RIA y lo mejor sin necesitar de herramientas en específico.

Y pues creo el otro que se les olvida mencionar es Flex, que creo que la comparación debería ser Flex vs Silverlight y no Silverlight vs Flash. ¿o estoy equivocado?

Imagen de Sr. Negativo

Este post debio titularse...

Silverligth Vs Flash/Flex Vs Javascript Vs HTML5

¿Como que se desviaron del tema... no?

Ahh si, nos pasa sieeeeempre

Ahh si, nos pasa sieeeeempre :)

Imagen de neko069

!!!!!!

En serioooooo????!!!!

Bueno, relativamente jajajaj

Bueno, "relativamente" jajajaj ( Y ahora viene Luxpes y menciona aquello de los términos absolutos y relativos y .... ) </sarcasmo>

Imagen de luxspes

Ja!

Bueno, "relativamente" jajajaj ( Y ahora viene Luxpes y menciona aquello de los términos absolutos y relativos y .... )

Ja! Ciertamente podria, pero mejor citemos a Neko citando a Jiddu Krishnammurti ;-)

(Vaya, he descubierto un bug con las anchors en Javamexico, si el comentario noe sta en la pagina 1, la liga en el titulo del comentario es incorrecta... corrigiendo manualmente...)

Imagen de luxspes

@Rafa: Los años que sean... la cosa es que si compiten...

Claro, podría ser, en un futuro... en cuántos años? ...

Bueno, fuiste tu el que dijo:

Creo que tanto las tecnogías RIA (Flash/Silverlight/JavaFX?) como HTML/JavaScript tienen sus lugares bien definidos y no compiten entre sí, cada una se aplica a para diferentes cosas.

Ahora dices que si... entonces? si o no? De ahi a que HTML+JavaScript ganen la batalla, lo que yo dije fue: "bien podria ocurrir que JavaScript triunfe donde solo Flash a sido rey", pero no asegure que pasaria, solo dije que "podria ocurrir".

Si tu punto era que no es 100% seguro que HTML+JavaScript lleguen a matar a Flash y a Silverlight, estoy de acuerdo... si tu punto era que tienen sus lugares bien definidos y no compiten entre si y cada una se aplica a para diferentes cosas (asi como PostgreSQL no compite con Dell en la fabricacion de Laptops) entonces, estaras de acuerdo, en que estabas equivocado.

Imagen de beto.bateria

Pues la historia dice que

Pues la historia dice que HTML5 es el asesino de Flex/Flash(o como quieran que le llamen) sino preguntenle a Job porque quito el soporte a FLEX en el IOS.

Respecto a Java, me pasaria inmediatamente a Python si este no tuviera una licencia tan generosa (GPL).

Trabaje dos meses con python al inicio de año y me alucionaron sus variables sin tipo, pude emular muy bien el polimorfismo(sin recargar tanto la memoria), y ademas las funciones regresan varios parametros.

Segun he leido python es muy rapido, es multiplataforma y su utilizacion va rapidamente en aumento.

Mmhh cuidado, puedes causar

Mmhh cuidado, puedes causar más confusión con lo que dices beto.bateria

Python no tiene licencia GPL, sino una licencia compatible con GPL. Aún así, tu no vas a modificar y ni siquiera deberías redistribuir Python!, tus programas pueden tener cualquier licencia y puedes hacer con ellos lo que quieras.

Luego, no entiendo porque dices que puedes emular el polimorfismo en python si es de lo más natural!

Finalmente las funciones en Python también regresan solamente 1 valor, pero sucede que tiene una literal para el tipo de dato tupla con lo que puedes regresa una tupla que tenga varios valores:

def  varios() :
   return ( 1, 2, 3, 4 )

En realidad estás regresando solo un valor.

Python es muy rápido y se está haciendo una versión autocontenida llamada PyPy ( python escrito en python ) que es más rápida que la versión principal CPython ( el interprete de python escrito en C ) pero es muy difícil que un lenguaje de tipeo dinámico alguna vez sea tan rápido como uno de tipeo estático.

En última instancia podrías usar Jython FTW :)

Imagen de beto.bateria

OscarRyz ¿puedo hacer en

OscarRyz ¿puedo hacer en Python un programa y venderlo sin dar el codigo?, ¿se puede hacer lo mismo con GPL? Eso de plano no lo sabia.

Me da la impresion que Python es mas rapido y ocupa menos recursos que Java al ejecutarse.

La verdad se me hace mejor lenguaje Python que Java(a la mejor me sacan de este foro por escribir esto).

Respecto a emular el polimorfismo, era un proyecto para obtener informacion de redes sociales, al final se obtenia informacion con una estructura igual. Hice una clase por cada red social, esta clase no heredaba de ninguna otra, asi que no podia usar polimorfismo, pero como Python usa variables sin tipo, le asignaba a la variable sin tipo todas las clases que accedian a la info de la redes sociales, y salio muy bien. Si mal no recuerdo habia que terminar rapido el sistema y no habia tiempo para buscar como usar el polimorfismo en Python.

El uso de las tuplas(no me acordaba que se llamaran asi) me ayudo al evitar crear una clase que funcionara como contenedor de la informacion obtenida.

¿Puedo hacer en Python un

¿Puedo hacer en Python un programa y venderlo sin dar el codigo?

Yeap!... es tú código y puedes hacer con él lo que quieras.

Incluso puedes re-distribuir Python mismo y venderlo, lo único que no puedes hacer es quitarle la licencia. Pero a TU código le puedes hacer lo que gustes.

Me da la impresion que Python es mas rapido y ocupa menos recursos que Java al ejecutarse

Pues eso!... la impresión. Debes de medirlo para tener la certeza ( yo la verdad es que no sé cual ocupa menos recursos )

La verdad se me hace mejor lenguaje Python que Java(a la mejor me sacan de este foro por escribir esto).

Esa es la belleza de la subjetividad. Lo que para uno puede ser mejor para otro puede ser peor.

Por ejemplo ¿que tipos de datos le puedo pasar a un método con la firma:

def  saluda ( persona,  saludo,  veces ) :

?

La respuesta? Los que sean. Funcionará? no se sabe hasta ejecutarlo.

Por lo que te entiendo lo que a tí te gustó es que el tipo de las variables sea dinámico ( Ojo de nuevo, en Python, las variables si tienen tipo, pero este se asigna dinámicamente, aún así tienen tipo y además son de "tipo duro" strong typing donde una vez asignado un entero por ejemplo, no se transforma en un string, los lenguajes que sí hacen eso se les conoce como de "tipo debil" weak typing JavaScript es un lenguaje así ) lo cual tiene ventajas y claro también tiene desventajas, pero eso es lo bueno de tener variedad.

:)

Imagen de beto.bateria

Lo de la impresion es un

Lo de la impresion es un decir, se de una empresa que hospeda sitios web que no acepta aplicaciones java porque dice que gastan muchos recursos.

Respecto a las variables dinamicas, si llevas un buen control de las instancias que creas y su tipo, no creo que haya problemas, pero muchos no lo hacen, y otros a veces nos equivocamos :S.

Imagen de neko069

Re: impresión

se de una empresa que hospeda sitios web que no acepta aplicaciones java porque dice que gastan muchos recursos.

Lo que no te dice ésa empresa es que su clúster donde albergan las aplicaciones está compuesto por:

super clúster

Sus instalaciones de redes:

super rack

Y el soporte :

tech cat

Imagen de ezamudio

jajajajajaj

buenísimo. Eso de la empresa que no acepta apps Java, pues allá ellos. Hay opciones ya además de Google App Engine, y mejores pienso yo, como CloudFoundry y muy recientemente, Heroku.

Re: Lo de la impresion es un

Pues...basta con un simple ejemplo, haz un benchmark en tu PC y verás. La cosa simple, una función recursiva, a ver cual se imprime más veces. En mi máquina (Core2Duo @ 2.4, 2GB de RAM DDR3):

#Este código llega hasta: "Vamos en 998"
def recursiva(x=0):
        print "Vamos en", x
        recursiva(x+1)

recursiva()

//Este código llega hasta: "Vamos en 10509"
class Recursivo{
       
        public static void main(String ... args){
                recursiva(1);
        }

        static void recursiva(int x){
                String s = String.format("Vamos en %d \n", x);
                System.out.println(s);
                recursiva(x+1);
        }
}

Otro benchmark simple puede ser llenar un arreglo que contenga 1000 espacios e imprimirlos en pantalla, aunque en este caso puede ser beneficiado Python (por el uso de range, y con eso no lo tenemos que llenar a mano):

#Según el Textmate este script se ejecuta en 2.08~2.10 segundos
def imprimearreglo(arreglo):
        for x in arreglo:
                pos = 1
                print "El valor de x[%d] es %d" % (pos, x)
                pos = pos+1

imprimearreglo(range(1,1000))

//Este código según Textmate se ejecuta en 2.05~2.07 segundos
class Arreglo{
        public static void main(String ... args){
                llenarArreglo(new int[1000]);
                System.exit(0);        
        }

        static void llenarArreglo(int[] arreglo){
                for(int x = 0; x < 1000; x++){
                        arreglo[x] = x;
                }
                imprimirArreglo(arreglo);
        }

        static void imprimirArreglo(int[] arreglo){
                for(int x = 0; x < 1000; x++){
                        System.out.println("El valor de x[" + x + "] es " + arreglo[x]);
                }
        }
}

Cabe mencionar que para el último benchmark fue fácil para Python, ya que no hay que llenar un arreglo. Pero, a pesar de que en Java llenas el arreglo se ejecuta con casi la misma velocidad. Sin embargo, los lenguajes de scripting consumen más memoria. Faltaría revisar también que tanto se usa procesador y demás (benchmarks en forma, esto son cosas que un simple mortal con poco tiempo puede hacer).

Imagen de ezamudio

parejo

Para que sea más parejo, el código en Java debería usar printf entonces. Con eso el tiempo de ejecución se reducirá drásticamente.

System.out.printf("El valor de x[%d] es %d%n", x, arreglo[x]);

Y si lo quieres hacer todavía más parecido al código de python, debería usar un iterador:

int x=0;
for (int i:arreglo) {
  System.out.printf("El valor de x[%d] es %d%n", x, i);
  x++;
}

Benchmark

http://shootout.alioth.debian.org/ es una pagina de Benchmark de distintos lenguajes de programacion con distintos programas de pruebas.

Python esta muy abajo de Java en rendimiento.

Re: parejo

Pues parece que fue al contrario y se ejecutó un poco más lento, mi código quedó:

int x = 0;
for(int i : arreglo){
   System.out.printf("El valor de x[%d] es %d%n", x++, i);
}

Ahora según Textmate duró: 2.14 segundos.