.NET vs Java vs Qt… resultado, mas leña al fuego…
A día de hoy hay cosas meridianamente claras de cara al futuro 2011…:
1. Cloud Computing
2. Mobile Apps y Media Tablets
…
5. Social communication and collaboration
Los nuevos entornos de desarrollo tienen que lidiar con la nube, las múltiples plataformas y otras tendencias.
Os acordáis de la magnífica idea: “Toda la información, en cualquier lugar, en cualquier momento y en cualquier dispositivo”.
Esta idea es la ley motive de la concepción de .NET y en buena medida de Java.
¿Consigue .NET o Java llevar a plenitud esta idea?
Respondan ustedes, yo no voy a entrar en detalle, pero quiero dejar claras dos realidades:
- .NET no es capaz, ya que no es multiplataforma (ni siquiera Silverlight).
- Java aun siendo multiplataforma sufre desde hace mucho tiempo de algo llamado “fragmentación”.
¿Qué es la fragmentación?: Es la imposibilidad de una plataforma de garantizar su operación correcta en todos los sistemas donde se ejecuta.
Para aclarar los problemas de Java recomiendo la lectura de algún artículo:
http://diegocg.blogspot.com/2010/09/oracle-y-el-trono-perdido-de-java-me.html
http://www.gamasutra.com/view/feature/2770/dealing_with_a_fragmented_java_.php
Los ‘pájaros enfadados’ atacan la fragmentación de Android
Android
iOS
La batalla más importante de esta nueva era tecnológica se librará en la multiplataforma (soporte multiplataforma + sistemas operativos + hardware)
Nokia ya lo tiene claro, Qt es actualmente el único conjunto de librerías que puede llevar a buen puerto la multiplataforma. Qt es “un diamante en bruto” que hay que pulir. Para pulirlo hay que sumar fuerzas:
- Más software, menos hardware: ¿Alguien se dio cuenta de quien es el nuevo CEO de Nokia? Un tipo del mundo software Stephen Elop es el nuevo CEO de Nokia, alto ejecutivo de empresas de software (Macromedia–>Adobe–>Juniper Networks–>Microsoft–>Nokia). ¿y eso?… fácil, el hardware cada día tiene menos importancia, Nokia así lo cree. http://arstechnica.com/open-source/news/2010/11/nokia-cto-its-all-about-the-applications.ars, nosotros también lo creemos.
- Soporte multiplataforma: Más dinero para Qt, muerte a GTK+ y otros conjuntos de librerías obsoletas.
- Sistemas operativos I: Mayor inversión en Qt para mejorar el soporte de algunos sistemas operativos actuales Windows/Linux/MacOSX/Embedded Linux en decremento de otros Windows CE/Windows Mobile/Symbian/Unix…
- Sistemas operativos II: Desarrollo de un sistema operativo multiplataforma real. A este agujero negro (pura inversión) lo llamaremos Meego “futuro tecnológico de Nokia” para la multiplataforma basado en Qt.
- Hardware: Soporte de los grandes fabricantes hardware ARM, Intel, AMD e integración en sectores industriales estratégicos:
http://qt.nokia.com/qt-in-use
http://qt.nokia.com/qt-in-use/qt-in-mids-netbooks
Qt no es perfecto, a día de hoy no hay soporte para muchas plataformas actuales. ¿y? ¿Qué tiene esto que ver eso con el futuro? ¿tiene algo que ver eso con Qt? ¿no es más bien un problema legal? ¿o comercial?…
Un buen amigo un día me dijo… Jorge, hoy aprendí una cosa muy importante de ti: El camino recto siempre es el más corto, aunque no siempre sea el más cómodo…
«Java aun siendo multiplataforma sufre desde hace mucho tiempo de algo llamado “fragmentación”.»
«¿Qué es la fragmentación?: Es la imposibilidad de una plataforma de garantizar su operación correcta en todos los sistemas donde se ejecuta.»
¿Has utilizado por nombrar una aplicación, p.e. OpenOffice?
Dime un lenguaje de programación web que funcione en cualquier navegador web y tenga acceso a los recursos del sistema nativo, independientemente de cual sea.
¿Te has parado a pensar que lo que tú utilizas es lo mejor, y lo de los demás está lleno de taras?
¿Cómo puedes defender una plataforma móvil que sólo funciona en un dispositivo?
No sé … no me cuadra.
Conozco OpenOffice desde hace mucho tiempo, funciona muy bien en las plataformas mayoritarias, pero al igual que otras muchas aplicaciones java no puede garantizar su ejecución en todas (sobre todo cuando tienes múltiples aplicaciones que ejecutar que utilicen VM’s de versiones distintas). Roberto, seguro que sufriste alguna vez de la fragmentación de Java con Apache/Tomcat/JBoss y aplicaciones distintas (yo sufrí en algunos clientes con sus productos Java).
No hay ningún lenguaje web (JSP,ASP,PHP,RUBY) que de por sí solo funcione en cualquier navegador (la incompatibilidad entre browsers es algo con lo que tenemos que convivir diariamente).
Respecto al acceso a recursos máquina nativos podemos decir que el lenguaje como tal no tiene la capacidad, si hablamos de plataformas (Java, NET, PHP, Python, Ruby…) casi todas pueden acceder a la mayoría de los recursos de la máquina a alto nivel (no veo grandes diferencias entre plataformas a este aspecto).
No pienso que lo que utilizo sea lo mejor, más bien todo lo contrario. Las plataformas que utilizo diariamente sufren de unos u otros problemas (por ello utilizo varias aunque en este blog hablo fundamentalmente de Velneo). Más bien elijo la tecnología que necesito en cada caso, .NET/ASPNET para desarrollos empresariales e integración de plataformas, Java/Apache/Tomcat/JBoss/JSP… idem que .NET (aunque abandoné Java hace años me toca lidiar con estas tecnologías en nuestros clientes), ASPNET/PHP/Python para la web, C++ para bajo nivel, Velneo/Qt para el futuro de nuestras aplicaciones empresariales en SaaS.
No defiendo la plataforma móvil de Velneo ya que actualmente es insuficiente. Defiendo Qt/Velneo por creer en su buen hacer y eso de cara al futuro de Velneo y PaaSOS es lo más importante. Actualmente Velneo solo soporta Windows/Linux/Mac/Maemo/Megoo pero seguramente eso cambie a medio plazo por lo que no me preocupa el hoy, me ocupo del mañana. Además es una cuestión de sumar no de restar. Si sumas PHP+Velneo+Ruby+Phyton+Java+.NET+… lo tienes todo (utiliza lo que quieran los clientes y pon el foco donde creas conveniente.)
@Jorge
«Roberto, seguro que sufriste alguna vez de la fragmentación de Java con Apache/Tomcat/JBoss y aplicaciones distintas (yo sufrí en algunos clientes con sus productos Java).»
Es evidente que Java no funciona igual de bien en TODAS las plataformas con distintas JVMs, pero la solución es muy sencilla …. cambia la JVM y punto. Es evidente que si desarrollas una aplicación en OpenJava que tiene poco de estándar y la quieres hacer correr en la de Sun (ahora Oracle) la cosa no va a ir muy bien. Pero como he dicho anteriormente se resuelve muy fácil, no tengo ni que desisntalar/instalar nada, cambiando el path a la jvm que me interese ya está solucionado.
«No hay ningún lenguaje web (JSP,ASP,PHP,RUBY) que de por sí solo funcione en cualquier navegador (la incompatibilidad entre browsers es algo con lo que tenemos que convivir diariamente).»
Estoy totalmente en desacuerdo. Voy a hablar de lo que conozco, una JSP (página web servida por Java, que no lenguaje) lo que hace es pintar html puro y duro en la máquina del cliente. La conversión la hace el servidor Web en la máquina que hace de servidor, con lo que la compatibilidad es absoluta en cualquier navegador capaz de interpretar html. Otra cosa son los css que acompañan a una página web, pero como de costumbre la nota disonante es Microsoft con su ie, eternamente fuera de los estándares. Por esto mismo una página servida por un tomcat funcionará igual en linux, windows, mac y cualquier otro dispositivo capaz de leer html. En esto Velneo está muy por debajo (sinceramente expreso aquí mi desilusión), porque en vez de realizar esto mismo en web, lo que hace es incrustar un objeto en el navegador que será siempre dependiente de las versiones, actualizaciones y evoluciones de éstos. Otra vez de nuevo Velneo no apuesta por una respuesta estándar.
«No defiendo la plataforma móvil de Velneo ya que actualmente es insuficiente. Defiendo Qt/Velneo por creer en su buen hacer y eso de cara al futuro de Velneo y PaaSOS es lo más importante. Actualmente Velneo solo soporta Windows/Linux/Mac/Maemo/Megoo pero seguramente eso cambie a medio plazo por lo que no me preocupa el hoy, me ocupo del mañana.»
En esta reflexión voy a copiar las palabras de un buen amigo. El gran problema que está teniendo Velneo es que utiliza QT como una plataforma de desarrollo y no como unas simples librerías. Establecer como base de desarrollo en una plataforma una dependencia absoluta en unas librerías, tiene como consecuencia precisamente eso … dependencia absoluta.
«Además es una cuestión de sumar no de restar. Si sumas PHP+Velneo+Ruby+Phyton+Java+.NET+… lo tienes todo (utiliza lo que quieran los clientes y pon el foco donde creas conveniente.)»
Ya me contarás como haces para intereacturar de forma bidireccional con otros lenguajes en una plataforma cliente servidor desde Velneo que no sea una dll y una línea de comando. Hablo desde la ignorancia …. ¿puede Velneo recibir una orden de por ejemplo una función de Java que levante un formulario o cambie el valor de un campo? Y no es que quiera criticar, pero tanta benevolencia hacia la plataforma, tanta miel y tan pocas críticas no es bueno ni para Velneo ni para nosotros los desarrolladores cuando es evidente que todavía falta muy pero que muy mucho.
Un saludo. Roberto Blasco.
@Roberto; No entiendo ninguna de las diserciones que haces… por lo que no voy a repetirme.
» Reconoces que Java sufre de la temida fragmentación incluso das una solución posible.
» Reconoces que los distintos navegadores sufren de problemas de compatibilidad (solo CSS dices). Bueno la verdad es que la incompatibilidad entre navegadores no solo es culpa de los CSS también de HTML y JavaScript.
» Todas las plataformas utilizan algo por debajo y tienen dependencia sobre ellas. En windows todo depende de las MFC’s, C++Runtimes y APIWin32 en Linux (aun siendo más modular) de libxxx, gtk o Qt… Sinceramente, no entiendo lo que dice tú amigo, si desarrollas con .NET dependes de .NET, si desarrollas con Java dependes de la VM java de turno (entre VM’s de distintos fabricantes nadie me garantiza la compatibilidad, aun siendo teóricamente compatibles siempre hay matices “fragmentación”)
» Respecto a lo último, ¿acaso tienes el hábito de llamar a los formularios Java desde C++? ¿Sueles implementar así las integraciones entre los distintos sistemas? ¿No utilizas servicios web para las integraciones?…
Unas últimas aclaraciones;
Velneo es una plataforma para desarrollar aplicaciones de gestión empresarial (cliente/servidor y SaaS). No está pensado para desarrollar aplicaciones Web.
El vWebClient no es un entorno de ejecución Web por lo que no es comparable con ASPNET, JSP, PHP, Ruby u otros similares. Si lo puedes comparar con algo es con Flash, JavaFX o Silverlight. Fundamentalmente es para distribución de aplicaciones en modo RIA.
Para la web Velneo dispone de un módulo que permite integrar cualquier tecnología web compatible con Apache con el motor de datos y de procesos de Velneo.
:0 :0 Acojonado con tanta sapiencia junta. Chapeau, mon dieu.
Felicidades a ambos. Aunque sinceramente esto me recuerda a aquellas discusiones de los teólogos bizantinos sobre el sexo de los ángeles o de si el Hijo era consustancial o no con el Padre y el momento exacto de la transustanciación en la Eucaristía. Damos vueltas y vueltas y más vueltas. Cada cual desde su posición.
No os pondreis de acuerdo nunca. Mejor, como dicen los franceses, vive la difference.
Mientras tanto , yo ,desde mi humildad, sigo ahorrándome el dinero de la v7 e invirtiéndolo en mayores conocimientos de conexión de mi viejo pero seguro Audi 6 con TODAS las plataformas de móviles. Y más cosas, claro 🙂
Un saludo.
@Jorge. Está claro que no nos entendemos y sigues con tu misma letanía.
¿Fragmentación? ¿He admitido que haya fragmentación? No he dado una solución, he dado la forma de actuar. Lo que no hay que hacer es levantar las manos al cielo y clamar justicia por algo tan trivial.
Me hablas de distintas JVMs … ¿cómo pretendes que haya compatibilidad absoluta entre ellas? en ese caso serían una misma, es obvio. ¿Funciona el mismo código compilado de C++ en Linux en Windows o Mac? Eso sí que es fragmentación ya que incluso compilado en el sistema donde se quiera ejecutar la compatibilidad no está asegurada ni mucho menos. Comparemos ratios de ejecución de programas de distintas plataformas hechos en C/C++ o en Java y podremos hablar de verdaderas diferencias.
Que Javascript o CSS no funciona igual en todos los navegadores (mejor dicho ie y el resto de los navegadores) no es culpa ni de Java ni de ningún otro lenguaje, hasta ahí podíamos llegar. De todas formas hay formas de programar seguras que aseguran la compatibilidad con los estándares, el problema son los malos programadores. Lo mismo pasará con las páginas web en los objeos html de Velneo, ¿o es que sólo utiliza un motor web para presentarlos?
¿Que si tengo el hábito de llamar a los formularios desde otras plataformas? Por supuesto. Ya me contarás sino, como hago para comunicar (por poner uno de miles ejemplos) google maps (que por cierto utilizas en tu aplicación) con la aplicación de forma interactiva. ¿De qué te sirve pintar un menu html en tu aplicación si no puedes utilizarlo?
Los servicios web son para intercambio de datos y/o ejecución de funciones remotas de distintas plataformas en el lado del servidor … no mezclemos peras con naranjas.
No defendamos lo indefendible, y sobre todo no ataquemos a los demás para ensalzar lo nuestro. No me digas lo que va a hacer y dime lo que hace.
No quise responder en el foro de Velneo vs Java porque las comparaciones son siempre odiosas y Velneo no está ahora a demasiados faroles por que cuando se levantan las cartas pierde la mano.
Y una última aclaración …. sobre JVMs que es lo que más me afecta. ¿Has intentado compilar un proyecto de VC++ en Borland C++? Sólo una pista, el código es el mismo.
@Agustín, como sabes @Roberto es un gran profesional y su punto de vista es siempre de agradecer. Entiendo la visión de Roberto y aun no compartiéndola me gusta escuchar sus opiniones.
@Roberto tiene la visión de una gran organización que utiliza Java/Oracle/+++ desde hace tiempo por lo que si yo estuviera en su lugar seguramente tendría la misma opinión de Java.
Si estuvierais en la piel de la mayoría de mis clientes tendríais la visión de Microsoft .NET/SQL/+++.
@Agustín también entiendo tú postura respecto al uso de V6.
Ahora bien, la visión que intento focalizar en mis artículos y reflexiones es una visión de futuro. V6/.NET/Java no entran en esta visión por ser tecnologías “antiguas” desde la perspectiva que me da el conocimiento de todas ellas y por eso soy tan crítico. Todas las tecnologías tienen su fuerte, pero no creo en V6/.NET/Java para la nueva era tecnológica a la que nos enfrentaremos en unos años.
Nuestra apuesta de futuro es por la suma de las siguientes tecnologías:
PHP/Ruby on Rails/Python para la web y servicios.
Linux como sistema operativo para servidores en la nube.
Velneo para el desarrollo de aplicaciones empresariales.
Apache/lighttpd como servidores web.
Amazon EC2 como proveedor de servicios.
Hola, hola , hola.
Buenas noches.
Mi razón fundamental para usar comercialmente v6 y no v7 es teológica.
la fragmentación es el signo mas bello de libertad y la mayor garantía de que se avanza, el que crea que la fragmentación es mala no se entera