20 años de Java: ¿En qué quedó el sueño de programar una vez, ejecutar en cualquier lugar?

Java cumple hoy 20 años. El 23 de Mayo de 1995 vió la luz de forma pública, durante la conferencia SunWorld ¡Qué tiempos! La compañía Sun Microsystems presentó el lenguaje en el que había estado trabajando durante más de cinco años de forma interna el equipo de James Gosling (el padre de la criatura). Un auténtico lenguaje moderno concebido para funcionar en cualquier dispositivo, esa fue la idea.

[#2 Aitor]

20 años de Java: ¿En qué quedó el sueño de programar una vez, ejecutar en cualquier lugar?

En lo que se veía venir: En una puta mentira.

[#3 Desactivado]

#2 sin embargo: Java vuelve a liderar el índice TIOBE

http://www.javahispano.org/portada/2015/5/10/java-vuelve-a-liderar-el-indice-tiobe.html

[#7 ur_quan_master]

#2 prueba a hacer programas multiplataforma en c++ y luego me lo cuentas.
Java sigue siendo una maravilla en cuanto a productividad. Te permite concentrarte en el problema en lugar de bregar con el lenguaje.

[#15 Pingocho]

#7 Si lo comparas con C++, obviamente la multipataforma de Java es una gran ventaja. Yo lo compararía mejor con Python que, además de multiplataforma, su sintaxis, simpleza y enorme librería son del gusto de muchos programadores (incluyéndome ) .

[#16 ur_quan_master]

#15 Me gusta python como lenguaje, me parece elegante. Pero mi escasa experiencia con el fue frustrante debido a la falta de compatibilidad entre versiones. Modulos no compatibles entre la version 2.6 2.8 y 3? Claramente mejorable.

[#19 Pingocho]

#16 Entre 2.5, 2.6 y 2.7 (nunca se lanzó la 2.8) no hay mucha diferencia, salvo unas cuantas librerías que no se encuentran en una u otra, pero siempre puedes encontrar soluciones en la comunidad.

Entre la 2 y la 3 sí hay bastantes, tanto que tu código en 2 puede no ser compatible en la 3, pero no hay mucho problema con esto ya que siempre puedes instalar una u otra versión del runtime (en Linux vienen las dos preinstaladas), o si compilas a .exe te empaqueta la versión adecuada.

No recomendaría pasarse de la 2 a la 3 a menos que sea un proyecto pequeño o estés preparado a hacer cambios en buena parte de tu código, aunque las ventajas de la 3 bien puede valer la pena, como el uso de Unicode por defecto.

[#115 Pingocho]

#75 goto #19

Si tu proyecto es grande y está escrito en Python 2 no te pases a Python 3, no necesitas hacerlo. Todo lo que te ofrece el 3 está en el 2.

[#24 Desactivado]

#16 exacto. Yo he compilado un millón de lineas escritas con java1.4 en java 7 y ningún problema. En fin, hay gente que prefiere evitarse los corchetes...

[#88 SXema]

#15 El problema de Java es que necesitas levantar todo un estadio para echar un ratoncico a correr, en cuanto a Python siempre me ha parecido un lenguaje muy hippy

[#36 Desactivado]

#7 Con U++ o cualquier otro framework multiplataforma C++ sigue pateando el culo de Java.

editado:

y no olvidemos qt, que está de aniversario.

[#38 Desactivado]

#36 c++ es más eficiente pero menos mantenible y menos estandarizado. ¿ Qué necesitas en tus proyectos ?
Hay muchos lenguajes porque hay muchas necesidades.

[#106 Desactivado]

#38 menos mantenible y menos estandarizado

C++ es igual de "mantenible" que Java. Ni más, ni menos: igual. E igual que Python, e igual que Golang.

En cuanto a estándares, C++ tiene estándares. El último es el C++14, del año pasado.

Si ves un proyecto en c++ inmantenible y que no sigue ningún estándar, échale la culpa al programador, no al lenguaje.

[#120 Desactivado]

#38 c++ es igual de mantenible que Java o cualquier otro lenguaje y está estandarizado, otra cosa es que te dediques a hacer spaguetti code, elijas un lenguaje no adaptado a lo producto, uses metodologías de desarrollo que han probado ser ineficientes o no tengas planificación alguna, y entonces los problemas de tiempo de desarrollo y mantenibilidad los tendrás uses el lenguaje que uses.

Cc #44 (te aseguro que yo también sé de qué hablo)

[#44 ur_quan_master]

#36 Si no te importa multiplicar por 10 el tiempo de desarrollo...pues sí.
Y te aseguro que sé de que hablo.

[#111 Blackmoon]

#36 LLevo unos meses aprendienco c++ y hace poco que me enteré de qt. La verdad es que me ha sorprendido mucho, aunque el tema de las licencias me tiene un poco mosca.

[#108 Desactivado]

#7 Sí, pero luego para el usuario es una puta mierda.

[#132 Desactivado]

#7 Pues mira, c++ está soportado de forma nativa en: Windows, Linux, MacOSX, iOS, Android ,Windows Phone....

Siempre digo lo mismo, Java no es multiplataforma, lo son las máquinas virutales en las que se ejecuta.

[#28 Shotokax]

#2 pregunto desde la ignorancia: ¿no se puede seguir ejecutando un programa en Java desde cualquier máquina, siempre y cuando esta tenga la Máquina Virtual de Java instalada?

[#32 dreierfahrer]

#28 Sipes.

Ademas es bastante eficiente, por mucho que digan...

Eso si, como existe J2EE en la que le ponen 50 millones de capas a cada aplicacion hay gente que piensa que es lento cundo no lo es.

[#64 Aitor]

#28 Sí, se sigue pudiendo, de hecho es la gran ventaja^TM de Java. Pero lo de que el resultado sea el mismo... ya es más discutible.

#32 No, no es que haya gente que piense que es lento. La ejecución en Java ES lenta, lenta y pesada en cuanto a recursos además, porque requiere la capa adicional de la máquina virtual. El equipo ejecuta la máquina virtual que es la que interpreta el código. No es lo que diga la gente, es que haces un programa, incluso uno sencillo, en Java y en C++ por ejemplo, haces medidas de tiempos y rendimiento, y te das cuenta.

[#67 dreierfahrer]

#64 Te das cuenta de que? De que son del mismo orden?

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=gpp&lang2=java

La ejecucion de java no es pesada: funciona en lavadoras y hasta en nokias 3210.

Las mierdas que se hacen en java son pesadas y lentas, pero el lenguaje en si NO.

[#68 Desactivado]

#65 +1 ami python no me convence por mierdas asi.

#67 ¿tu crees que no es mas pesada una aplicacion que pasa por la maquina virtual de java que una que no lo hace? Yo no creo que sea muy apreciable en estos tiempos pero la verdad hace no tanto o en equipos viejos si que noto un tipo de aplicacion sencilla en java frente a una en c. Que puede ser que por dentro la de java este fatal, pero yo veo como la interfaz grafica por ejemplo es algo que se nota mucho mas lenta en la mayoria de programas escritos en java y en pcs un poco viejos, sera jswing o las librerias que usen o sera que pasan por una mv.

[#69 dreierfahrer]

#68 Esa mierda que digo, especificamente, se corresponde (intuyo, aunque no tengo dudas al respecto) a que llego un tio nuevo y echo 'su meadita'; lo marcó para que quedara como 'suyo'....

A cuenta de que se cambia el nombre de los paquetes de una subversion a otra... acaso es tan importante eso como para que TODO lo que hay escrito en ese framework deje de ser actualizable?

[#73 dreierfahrer]

#c-68" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2416303/order/68">#68 En los benchmarks sale 3 veces mas lento que C++ o C, como C#....

El resto es problema de librerias y de como esta programado, de abandono de las aplicaciones de escritorio y sobre todo de capas y capas sobre capas....

[#78 Aitor]

#67 Ehm... ¿Cómo es eso de decir que los tiempos y recursos son del mismo orden poniendo como referencia un benchmark en el que de 8 medidas sólo en una (mandelbrot) son equivalentes, sólo en otra (binary trees) Java gana, otra no se puede comparar porque Java falla y en el resto es batido, en varias de ellas por efectivamente un orden de magnitud (por lo que no son del mismo orden)?

Vale que he mirado todo muy rápido y sobre todo la tabla de benchmarks, pero sin leer mucho la otra tabla decía en qué proporción de tiempo respecto a Java se ejecutaba algo equivalente en C++ y he visto muchas fracciones...

Que no sé, que igual lo he mirado todo mal y lo he entendido todo mal...

PD: Por otra parte, sí, muchos sistemas empotrados como lavadoras y demás ejecutan Java... Pero eso es irrelevante si estamos hablando de ejecución en PCs por dos motivos: Uno, porque los programas que ejecutan en sistemas empotrados son enormemente menos complejos. Y dos, porque esos mismos sistemas empotrados ejecutan Java sobre ARM, que tiene la genial característica de poder ejecutar Java bytecode (lo que se genera al compilar Java, que luego ejecuta la máquina virtual) de forma nativa. Jazelle, se llama, para quien lo quiera mirar.

[#121 Desactivado]

#67 Sí, se utiliza en sistemas donde el tiempo de respuesta no es determinante. Pues ya ves.

[#155 mangrar_2]

#67 Exacto, totalmente de acuerdo.

[#74 Shotokax]

#64 ¿a qué te refieres con que "el resultado" no es el mismo?

[#80 Aitor]

#74 A cambios de apariencia en la interfaz (no deseados y no habiendo dejado cosas por defecto o "como esté en el sistema"), a funcionamientos distintos de elementos de esa interfaz con los que se interacciona (botones, etc.), a fallos de ejecución en unos entornos que no se dan en otros, a diferencias de rendimiento bestiales...

[#100 Desactivado]

¿En qué quedó? En una máquina virtual, la JVM, con 20 años de optimizaciones, que ahora puede ser aprovechada para crear nuevos lenguajes sobre ella y además como bonus tener compatibilidad con todo el ecosistema generado a lo largo de todos esos años.

Lo que pasa con Java es que, como dice #32, te pones a ver código de proyectos J2EE, ves la inmensa bola de mierda que son, capa sobre capa, y te echa para atrás. Pero afortunadamente ahora mismo hay alternativas mucho más ligeras, sobre todo para desarrollos web.

#9 Es que no se trata de eso. Se trata de que el lenguaje ayude al programador, no que exija atención a detalles estúpidos que fomentan los errores rutinarios, a eso se refería #8 en parte. Ejemplos, a cascoporro: problemas de tipos, gestión manual errónea de la memoria, índices fuera de rango, etc. Ejemplo de lenguaje que ayuda al programador, y que enlaza con lo que decía en el primer párrafo: Scala.

Ojo, me gusta javascript porque se puede trabajar con un paradigma funcional con él y eso le da una potencia enorme, siendo el lenguaje de facto para navegadores. Pero tiene lagunas, y si surgen alternativas como TypeScript bienvenidas sean.

Puede que esté algo sesgado en este tema porque trabajo programando en Scala, pero es una gozada que el compilador trabaje para ti, y detectar muchísimos errores comunes estáticamente, y no en tests, o peor aún, en producción.

[#144 peperojoizquierdo]

#100 ¿Programas en Scala? Realmente eres un tío afortunado. Yo enseño programación, y lo hago utilizando Scala. Despúes de más de 25 años programando, es el mejor lenguaje de programación práctico que he encontrado. Martin Odersky es un genio.

[#91 Penetrator]

#2 Decir que Java es estupendo porque funciona en cualquier plataforma es como decir que el sexo anal es estupendo porque funciona con todos los géneros.

[#93 Aitor]

#91 Me gusta tu paralelismo... ¡Te lo tomaré prestado!

[#94 Penetrator]

#93 No es mío, pero yo te lo presto igual.

[#124 Desactivado]

#91

[#154 mangrar_2]

#2 mentira? yo trabajo en una aplicación en mi curro que instalamos tanto en windows como en linux sin ningún cambio. Donde esta la mentira?

[#50 Desactivado]

Respecto a la compatibilidad ...

[#147 KaborlllLLLONE]

#50 El sexo anal es bueno, otra cosa es que le tengas miedo.

[#14 cream]

#11 Douglas Crackford (creador de Javascript): "Estaba tratando de explicar a alguien la diferencia entre Java y JavaScript. Es como la diferencia entre Star Trek y Star Wars. Java es Star Trek. Fue la primera, y todo son uniformes, reglamentos y alertas rojas. JavaScript es Star Wars. Polvo, caos y misticismo"

https://plus.google.com/+DouglasCrockfordEsq/posts/FeZkpuHKPWN

[#71 anje]

Como se nota que estamos en fin de semana.
#8 Confundes Java con JavaScript, son dos conceptos muy diferentes, cada uno vale para lo que vale, que eso aquí ya se ha discutido mucho, y por tanto, no esperes hacer lo mismo y de la misma forma en un programa y en otro. Es una manía que cuando venimos de un lenguaje queremos que el siguiente se comporte lo mismo que el anterior.

#14 Como se entere Brendan Eich de lo que has dicho:
http://es.wikipedia.org/wiki/Brendan_Eich

[#76 cream]

#71 Cierto, Douglas Crackford es el creador de JSON, no de JavaScript.

[#92 anje]

#82 Antes de empezar, te aclaro que JavaScript esta hecho para trabajar al lado del cliente y no esperes más de lo que un lenguaje no tiene, y por tanto como casi todo, entender y dominar algo es una gran ventaja (yo no cumplo las dos premisas pero me esfuerzo).

Por tanto aludiendo lo que has dicho:
- Falta de estandarización de cómo definir módulos y cargar otros módulos, y más entre servidor y cliente.
JavaScript NO fue creado para trabajar al lado del servidor ( se han creado Node.js, Jaxer o RingoJS para trabajar de manera sícrona, callbacks etc.)
Y acerca de los módulos:

// Module definition
MyLibrary = (function ()

return ,

anotherPublicMethod ()
}
}());


- Tipado dinámico. Es muy gracioso para hacer cosas pequeñas, pero para que sea seguro requiere una cantidad de test unitarios que a veces pierde el sentido. Por otro lado, la flexibilidad y falta de tipado que tiene hace que hacer mocks sea muy sencillo.
Te falto terminar la frase. JavaScript tiene un tipado dinámico blando o débil.
Pero para los puritanos:
var foo = new Boolean( ‘true’ ); ...

- No estandarización de cosas tan básicas como Array.prototype.forEach, o String.prototype.trim
Intenta con esto:
-Array.prototype.forEach.call
-Array.prototype.forEach.apply
-Array.prototype.forEach = funtion()
Y lo mismo para trim.

- El infierno del scope, que es muy gracioso para hackear el lenguaje, pero es un sinsentido mayúsculo para conseguir hacer algo funcional.
Aqui un par de sugerencias para tu infierno:
var person = function ()  return {
  getName : function () {
   return name;
  ">,
  setName : function (newName)
 };
}();

o esta:
(function ()  alert(dog);
">)();

Tu te crees que si el panorama es como lo pintas, las grandes multinacionales de internet no ya lo habrían cambiado. Evidentemente, todos los lenguajes tienes sus pro y sus contras pero sin eso, perderían su gracia.

Algunas referencias: Gordon Dickens Why Java Developers Hate JavaScript, Dean Edwards o john resig entre otros

#76

[#148 KaborlllLLLONE]

#92 TL;DR;

"[...]te aclaro que JavaScript esta hecho para trabajar al lado del cliente[...]". Eso, simplemente, no es cierto y afirmarlo muestra un profundo desconocimiento del lenguaje. Y, apoyándome en eso sospecho de que el resto de tu comentario está mal y se basa en premisas falsas y erróneas.

Un saludo.

[#82 ktzar]

#71 Sé que no puedo esperar hacer lo mismo en JS que en Java, o utilizar la misma aproximación a un problema. JS tiene cosas maravillosas, pero padece de una herencia en cuanto a diseño e intérpretes terrible. Si te riges por Javascript: The good parts, tienes un lenguaje razonable, el problema como comenta #79 es que sólo un 1% de los que programan JS saben qué partes te van a morder.

Por cierto, sí que ha tenido gracia lo de algo funcional. Esas funciones ya están en ECMA 5, ... A lo que voy es que hay lenguajes que implementan todas estas funcionalidades, pero con una ruta clara, estándar, ... Creo que la frase que lo resume es "Javascript no tiene una forma idiomática de hacer las cosas". Y que esto no exista en cosas tan del día a día como cargar módulos, definir parámetros opcionales en funciones, etc... me hierve la sangre. Y ya, ECMA 6 estará muy bien, pero sus características se podrán empezar a usar de verdad en un año en entornos muy específicos: apps tipo PhoneGap o NodeWebkit, servidor con io.js o node.js, o extensiones de Chrome... que no es poco, pero me parece que tendremos que seguir teniendo cuidado durante muchos años.

Salud

[#1 ronko]

Por poner un ejemplo en "cierto" juego de cubos.

[#5 Pingocho]

#1 ¿Hablas de aquel que con gráficos de los 90 requiere hardware del 2020?

[#12 dreierfahrer]

Javascript apesta ampliamente.

Para hacer chorradas bien, pero para hacer cosas medianamente grandes es demasiado inconsistente.

Java permite hacer código mantenible y fiable.

[#18 Desactivado]

#12 Bendita es la ignorancia

[#29 dreierfahrer]

#18 Eso digo yo....

[#25 Shotokax]

#12 es que no son equivalentes. JavaScript es un lenguaje de cliente web y Java es un lenguaje de propósito general que se puede usar para hacer aplicaciones de muchos tipos.

[#30 dreierfahrer]

#25 Si lo dejas ahi estoy contigo, pero hay degenerados que quieren hacer fullstack con javascript!!!!!!!!

Pq demosnios alguien querria hacer eso cuando hay alternativas???

[#136 Desactivado]

#30 pues como toda degeneración:

Alguien te dice que mola...

Un día lo pruebas...

Cuando te quieres dar cuenta estás enganchado 💜 💜 💜

Eso de usar JavaScript en el cliente, en el server y en la base de datos, es... Una golosina.

[#6 Pingocho]

¿En qué quedó el sueño? En un lenguaje vetusto y engorroso que todos quieren matar pero nadie sabe cómo. Como Cobol.

[#62 Desactivado]

"¿En qué quedó el sueño de programar una vez, ejecutar en cualquier lugar?" Pues en html5.

[#41 ktzar]

#39 Usé AngularJS en un proyecto comercial en 2013, intento usar 6to5 (o como se llame ahora) en la actualidad, e hice un proyecto comercial con TypeScript en 2012 (sí, cuando salió). No son el futuro. Y que existan no hace que JS deje de ser un lenguaje bastante chunguete...

Aunque sí es cierto que, con autodisciplina y disciplina de equipo en hacer las cosas siempre de la misma manera, con un linter que te pare las builds si algo no está como debería, y con paciencia con los nuevos desarrolladores que entran al equipo, y con una buena dosis de unit tests, y un sistema decente de definir módulos (requireJS estricto, por ejemplo) se puede escribir JS sin perder la cabeza... Yo lo hago todos los santos días.

El problema es que los lenguajes decentes vienen con todo eso de serie y te hacen difícil no seguirlo. Javascript es un chiste, para que digan de PHP...

[#45 Desactivado]

#41 A ver, javascript como lenguaje, lo detesto. Con ES6 y Typescript mejora, ya hay tipado, hay anotaciones (pones encima de una clase el@Component con Angular 2.0 y automáticamente es una directiva), hay genéricos,... Pero se sigue quedando muy atrás de Java.

Eso no quita que sea un lenguaje muy veloz y que se está trabajando mucho, y con muchísima demanda y muy bien pagado (sobre todo la gente de angular, en Madrid se está pagando hasta 46K a gente con 1 año de experiencia en angular).

Ahora mismo es un lenguaje "trending topic", echa un ojo por ejemplo al estado de las ofertas de trabajo de UK:
http://www.itjobswatch.co.uk/jobs/uk/angularjs.do

En enero del 2013 ninguna oferta de angular. En enero del 2014 el 2% de las ofertas incluían angular en sus peticiones. A día de hoy, casi el 10%, y la curva es ascendente, con salario medio de 63.291€ en UK, si hablamos de Londres un salario medio de 73.839€, por un lenguaje por el cual piden un año de experiencia normalmente.

[#54 ktzar]

#45 Lo curioso es que cuando Angular1 está empezando a ser popular, aparece Angular2 que usa TypeScript, y es que hay mucha gente que lleva mucho tiempo echando pestes de Angular. Porque hacer el típico tutorial o la típica aplicación chorra es sencillo, pero llega un punto en el que desearías haber elegido otra cosa. En mi caso lo uso para cosas internas pequeñas y la app en la que usé Angular, ... pues bueno, llega cierto punto donde hay cosas que no son fáciles de "overcome" y la verdad, te acabas peleando con una librería más que con la lógica que estás intentando aplicar.

No sé... creo que es bueno intentar no dejarse llevar por ciertas tendencias que no son si no modas. En cambio, TypeScript me parece un buen conjunto de decisiones para llevar adelante a JS.

iSaludos!

[#138 Desactivado]

#45 tengo 2 años de experiencia en mean fullstack.

¿dónde dices que pagan eso?

Porque en oviedo me han ofrecido sólo 24k

[#157 mangrar_2]

#45 Hombre, en UK o Irlanda en Java se paga bastante bien

[#40 padix]

Bueno me preparo para los cuchillos...

La verdad es que Java, en la experiencia que llevamos acumulada de varios años, diremos que como mínimo es frustrante. Estoy hablando de aplicaciones J2EE, corriendo en weblogic, coherence, etcétera, vamos un stack clásico en aplicaciones empresariales, el resultado son constantes problemas de rendimiento, problemas de trazabilidad, y sobretodo muy poca productividad. No puedo decir que nuestra experiencia sea un criterio válida para juzgar una tecnología pero la realidad es que tardamos 1/3 en hacer las mismas aplicaciones en C# y con muchos menos problemas. Lo dicho igual el problema es nuestro, o tenemos mas experiencia en c# pero la realidad es que esta diferencia de productividad no deja de llamarme la atención, incluso he hablado con compañeros que pasaron de c# a Java, y prácticamente todo comparten este punto...

Por otro lado conozco bien un caso de intento de migración de aplicaciones c# a phyton, y en este caso parece ser que la experiencia esta siendo muy grata en términos de productividad, escalabilidad de las soluciones, y TCO.

Lo dicho, es una opinión sin mas valor que la experiencia propia.

[#63 dreierfahrer]

#40 J2EE es un mounstruo come ninios....

Despues de meter 50 capas no se puede esperar que nada funcione fluidamente...

[#109 Acido]

#c-40" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2416303/order/40">#40
" he hablado con compañeros que pasaron de c# a Java, y prácticamente todo comparten este punto..."

Sinceramente, me parece curioso que no te des cuenta tú mismo del sesgo que tiene esa afirmación. Es como decir que el español o el latín es peor que el portugués porque tomas como muestra gente de Portugal y les intentas enseñar español o latín y les cuesta, no se desenvuelven igual que con el idioma al que llevan años acostumbrados. La crítica es obvia: si tomas a un español también le costará desenvolverse en portugués... es evidente. Si hablas con compañeros que pasaron de Java a C# también empezarán siendo menos productivos en C#. Y el número de programadores de Java es notablemente mayor.

Otro sesgo: posiblemente (casi con seguridad) se trate de hacer aplicaciones para Windows... entonces, claro, el entorno de desarrollo creado por Microsoft para hacer aplicaciones que corren en Sistema Operativo Windows de Microsoft resulta que está más integrado y más "a la última" ... obvio. Ahora dime qué pasa cuándo quieres llevar tu programa de C# a un servidor Linux... existirá Mono pero me da que vas a tener más problemas.

Vamos a ver, si hablamos de lenguaje: C# es sintácticamente muy similar a Java, yo diría que casi idéntico... no se tarda más en escribir con uno que con otro, en ese sentido diría que la productividad es idéntica. De hecho, C# salió varios años más tarde que Java y todo el mundo lo veía como una copia de Java que hacía Microsoft para no depender de la marca registrada Java y poder poner los nombres que quería a las cosas sin que le acusaran de querer romper la compatibilidad de Java...

Ahora bien, esto que he dicho de productividad idéntica es si se trata de hacer algo completamente nuevo, no dependiente de cosas anteriores. Como dije antes, si quieres hacer algo que se base en la última biblioteca de funciones de Microsoft pues, lógicamente, con C# se supone que podrás hacer llamadas a esa biblioteca de forma más sencilla. Ahora bien, creo que ese puede ser un problema bastante específico, si se trata de problemas generales probablemente sea más fácil encontrar una biblioteca de Java que resuelva el problema, más fácil que encontrar una de C# ... hablo sobre todo de software libre, y de encontrar ejemplos de código para resolver una necesidad o problema.

Como resumen de estos dos párrafos: si quieres hacer algo nuevo que no dependa de otras cosas hechas por otros antes, la productividad es la misma. Si quieres algo que se apoye en código hecho antes por otros creo que en Java vas a encontrar más cosas hechas y eso que te ahorras de programar tú mismo, salvo en casos específicos de Microsoft.

Si no hablamos de lenguaje ni productividad en el sentido de resolver un problema o acabar una aplicación en menos tiempo, si hablamos de otros aspectos como el coste que puede tener una aplicación de servidor en producción y cosas así creo que puede salir ganando Java: puedes tener una aplicación Java corriendo en cosas como Tomcat sobre Linux (ambos gratuitos) mientras que C# exigirá Windows con la correspondiente licencia. Mirad precios de hosting en máquinas con Windows y otras con Linux y veréis la diferencia. Esta creo que una prueba de las implicaciones reales de la portabilidad de Java: poder desarrollar en un entorno amigable para el desarrollador (Mac, Windows... quizá Linux para algunos desarrolladores) y poner en producción en otra plataforma diferente (Linux, Android, etc). Si comparas con un weblogic pues Java sale perdiendo, seguramente la licencia y los requisitos de hardware sean mayores, pero eso en mi opinión es o bien hacer trampa o desconocer las posibilidades reales que tienes. Si soy yo el que desconoce C# y con Mono funciona todo perfecto en Linux pues dímelo pero me temo que no es así.

Por otro lado, dado que el número de programadores de Java es mayor, si se elije hacerlo en Java y alguien del equipo se va o enferma será más fácil reemplazarle por otra persona. Si se elije hacer en C# puede ser más difícil encontrar otra persona. Aunque hay bastantes personas en cada caso, no es un problema gravísimo, pero siempre viene bien el caso que tiene más disponibles.

Quizá haya parecido un fanboy de Java pero creo que he dado argumentos objetivos, incluso reconociendo ventajas de C# en algunos casos, pero es posible que mi escaso conocimiento de C# me impida ver más ventajas.

[#27 llou]

¿No sería más bien compilar una vez?

[#56 Desactivado]

Yo me llamo Ralph!

[#34 matias.el.cinico]

Compile once, debug everywhere.
Espero con paciencia el día cuando la gente diferencie entre "sobretodo" y "sobre todo".

[#43 ED209]

se quedó en "write once, debug everywhere"

oops no te ví #34 , busqué en el hilo "write" 😅

[#51 Rydra]

Hola, es aquí donde se habla de la productividad, la pulcritud y la versatilidad con la que se programa en .Net con respecto a Java? Han hecho ya un Visual Studio de Java?

[#4 Desactivado]

La manera de programar una vez actualmente se consigue con Javascript y Html5. Páginas web (frontal y backend), aplicaciones móviles, aplicaciones de escritorio multiplataforma...

[#8 ktzar]

#4 Trabajar con Javascript es una mierda:
- 20 formas diferentes de encapsular código, extender funcionalidad, crear constructores, ... para ser productivo quiero que haya una clara.
- Falta de estandarización de cómo definir módulos y cargar otros módulos, y más entre servidor y cliente.
- Tipado dinámico. Es muy gracioso para hacer cosas pequeñas, pero para que sea seguro requiere una cantidad de test unitarios que a veces pierde el sentido. Por otro lado, la flexibilidad y falta de tipado que tiene hace que hacer mocks sea muy sencillo.
- No estandarización de cosas tan básicas como Array.prototype.forEach, o String.prototype.trim
- El infierno del scope, que es muy gracioso para hackear el lenguaje, pero es un sinsentido mayúsculo para conseguir hacer algo funcional.

Y lo peor... que una de cada 10 personas que dice saber Javascript sólo sabe copiar y pegar bloques de jQuery mal estructurado.

Cada día me gusta más Golang. Sencillo, claro, una forma de hacer cosas. Muy cercano a código máquina con muy poca magia por debajo. Con lo que uno espera encontrar en una librería estandar en 2015: http, sync de coroutines, listas, mapas, unit test, compresión de ficheros, ...

[#11 Pingocho]

#8 Sin quitarte razón, porque la tienes, hay que entender que el caos de Javascript se debe a su convulsionada evolución. A pesar de todo, sí que se estandariza, sólo que lo hace muy lentamente y siempre queda a merced de la adopción por parte de los navegadores. Por ejemplo, la ECMAScript 6 estandariza los módulos y las clases, que es una de tus críticas. De momento, hay soluciones externas como TypeScript, que incorpora POO.

Golang es un lenguaje que pinta muy bien, su paradigma de interfaces es genial, aunque no entiendo muy bien el concepto de no tener excepciones, a mi parecer es más una excusa que una característica planeada. Además, el hecho de que pueda ser interpretado o compilado a nativo es algo que esperé mucho de lenguajes como Java o Python, y nunca se dio. Pero, por desgracia y como todo lo de Google, tiene una etapa experimental excesivamente larga, tanto que ya muchos hemos perdido la esperanza de verlo pronto adoptado por grandes proyectos. Yo por ejemplo, esperaré a que tenga GUIs decentes.

[#13 ktzar]

#11 Probé TypeScript en un proyecto en mi antigua empresa, y me gustó bastante. Ahora estoy usando Golang en un proyecto personal bastante grande que procesa juegos antiguos, ... y estoy enamorado.

Hay excepciones, pero sólo hay un tipo. Y visto todo lo que se abusa de las cientos de excepciones y la jerarquía de las mismas en Java, ... me parece bunea opción. En mi actual empresa hay proyectos en los que se está haciendo todo en Golang.

Un saludo

[#21 Desactivado]

#11 "Yo por ejemplo, esperaré a que tenga GUIs decentes."

GTK+

[#22 Pingocho]

#21 Bueno, por "decente" también me refería a "estable". Preferiría ver un bind de Qt tan bien adaptado y estable como el de Python.

[#23 Desactivado]

#22 go get github.com/mattn/go-gtk/gtk

[#33 dreierfahrer]

#11 Esa es otra de JS:

Tiene 20 y tantos años y aun no existe un GUI decente para ella

Lo cual da una imagen de lo usable que es para hacer cosas complejas....

[#112 Pingocho]

#33 Y quizás no lo tendrá porque está hecho para aplicativos web, no de escritorio. Tal vez en algún momento a alguien se le ocurra hacerlo (o ya lo hizo), pero no pasará de ser un experimento, como las GUIs de PHP, que es otro lenguaje que han querido mudar al escritorio sin mucho éxito.

[#46 ED209]

#8 #11 #17 #31 #37 javascript es para echarse a reír o llorar, según el día:
https://www.destroyallsoftware.com/talks/wat

[#17 Desactivado]

#8 #4 Cuando me refiero a Javascript, no hablo de cuatro chorradas de cambiar el color de un botón, on un evento para mostrar un mensaje. Si no a utilizar un framework que transforma Javascript en un lenguaje muy potente (AngularJS, Backbone o Ember), lo cual uniendolo con NodeJS tienes un entorno multiplataforma en el cual los desarrollos son muy rápidos y de calidad.

Yo es que estoy enamorado de JS desde hace un tiempo, y antes le tenia mucho odio irracional, y todo porque no entendía la forma de trabajar con el correctamente, no me entraba en la cabeza las ventajas que tiene el tipado dinámico y como javascript lo explota.

[#140 Desactivado]

#17 En mi antiguo trabajo decidieron hacer uno de los proyectos full-stack js: node, express, backnone y mongo, porque uno de los desarrolladores era también un enamorado. Tiene cosas buenas, sí, pero todavía está demasiado verde. Bugs extraños,interniacionalización de risa, librerias que cada semana sacan una versión nueva arreglando fallos pero volviendose incompatible con la anterior, y documentación de risa, en caso de que la haya. Ojo, que poder,se puede hacer un proyecto grande con JS. Pero también con Visual Basic, y eso no lo convierte en la mejor opción.

[#20 Desactivado]

#8 JS es más como LISP

Golang es como el C++ del siglo 21, pero bien hecho.

[#143 dotromas]

#20 C++14 es un lenguaje "todo en 1", complicado dominarlo en profundidad, pero sigue siendo muy poderoso y versatil (mas que Golang también).

Personalmente creo que quien domine C++ y Lisp en profundidad, no habrá lenguaje ni paradigma que se le resista.

[#31 dreierfahrer]

#9 No, el problema es que en JS veras a 15 tios haciendo lo mismo de 15 maneras diferentes y te cagaras cundo tengas que mantener eso...

Basicamente lo primero que dice #8....

[#37 Desactivado]

#8 A mí me gusta javascript, entre otras cosas por algunas de las que enumeras como negativas, pero te voto positivo porque creo que nunca había visto hablar de javascript a alguien que evidentemente sabe de lo que habla y tiene criterio para juzgarlo (aunque no coincida contigo).

[#39 Desactivado]

#8 Hola, vengo del futuro para hablarte de Angular.JS, de ECMAScript 6 y de typescript.

[#79 court]

#8

- 20 formas diferentes de encapsular código, extender funcionalidad, crear constructores, ... para ser productivo quiero que haya una clara.

Es un lenguaje multiparadigma con la libertad y flexibilidad que eso supone. Ideal para programadores muy versados ya en muchos lenguajes diferentes y que quieren lo mejor de cada uno. Si sólo quieres aprender una forma de hacer las cosas y burocratizar el código, desde luego ECMAScript no es tu lenguaje.

- Falta de estandarización de cómo definir módulos y cargar otros módulos, y más entre servidor y cliente.

Hay muchos frameworks y entornos y cada uno sigue sus propias normas y tiene sus propios módulos y extensiones, sólo tienes que elegir el que más se adecue a tu forma de trabajar. Personalmente espero que algo así no se estandarice nunca; porque una sola forma no puede ser adecuada a todas las situaciones.

- Tipado dinámico. Es muy gracioso para hacer cosas pequeñas, pero para que sea seguro requiere una cantidad de test unitarios que a veces pierde el sentido. Por otro lado, la flexibilidad y falta de tipado que tiene hace que hacer mocks sea muy sencillo.

Como todo, esto tiene sus ventajas y desventajas. Puedes hacer mucho más en menos líneas y con un poco de cuidado no habrá riesgos. En cualquier caso, entre muchas otras cosas, es una consecuencia de poder expandir clases y objetos en tiempo de ejecución; un precio pequeño para una feature tan grande.

- No estandarización de cosas tan básicas como Array.prototype.forEach, o String.prototype.trim

Mira ECMAScript 6.

- El infierno del scope, que es muy gracioso para hackear el lenguaje, pero es un sinsentido mayúsculo para conseguir hacer algo funcional.

¿Clausuras? ¿Cálculo lambda? Tiene muchísima gracia que utilices el término "algo funcional" quejándote de las clausuras http://es.wikipedia.org/wiki/Clausura_(inform%C3%A1tica) ¿te suena la programación funcional? http://es.wikipedia.org/wiki/Programaci%C3%B3n_funcional

Y lo peor... que una de cada 10 personas que dice saber Javascript sólo sabe copiar y pegar bloques de jQuery mal estructurado.

1 de cada 10? En realidad 99 de cada 100. Y ese es el mayor lastre del lenguaje, la gente que se cree que aprender un lenguaje es conocer su sintaxis. Y en muchos casos ni eso...

Es un lenguaje en el que puedes hacer verdadera magia en muy poco tiempo, y si eres cuidadoso será tan robusto como tu quieras. Por supuesto siempre habrá proyectos para los que no sea adecuado, como todo... es cuestión de estudiar qué necesitas.

[#95 piki.g.saraza]

#79 coincidió contigo y con #86, programar en js es como diseñar tu moto y montarla con la melena al viento, java es un camión de reparto, si robusto útil, profesional, pero muy monótono y aburrido.
Js es como el inglés todo el mundo dice que lo habla pero lo habla mal.
A mi las colecciones de java (pilas, colas,listas arrays) y si elección, aunque entiendo su utilidad en el rendimiento y análisis, me parece un coñazo.
Me recuerda este debate a cuando en mi trabajo la gente pedía uniforme "para no pensar que ponerse".
Js te da la libertad para que expreses tu programa si no quieres pensar hazlo siempre igual.

Bueno esa es mi opinión, un salido a todos

[#107 Desactivado]

#95 donde esta mi salido? ^^

[#85 scalvo]

#66 Programar javascript es divertido, aunque lo odies como #8. Programar java es un coñazo.

[#89 Desactivado]

#85 ami me gustan ambos.

[#134 Desactivado]

#8 ¿no te gusta la libertad?

[#156 mangrar_2]

#8 El javascript va a evolucionar. La próxima versión ya trae clases, así que veremos lo que pasa.

Golang molará, pero es para backend, no lo puedes usar en el navegador.

[#9 SeuMadruga]

#4 El problema es que javascript es un lenguaje muy complejo, y bastante más propenso a errores que otros. Por eso hay menos programadores capaces de hacer correctamente una misma tarea en javascript que en otros lenguajes como java. Y al final, eso se traduce en más coste, y ya sabes qué es lo que suelen opinar las compañías al respecto.

[#83 sid]

#4 A los fabricantes de RAM les gusta tu idea

[#96 Desactivado]

El eclipse y netbeans son una puta mierda. Queda dicho.

[#90 sotanez]

Mucho llorar todo el mundo pero ahí sigue el tío, y con cuerda para rato.
A mí como programador me facilita bastante la vida, frente a otros lenguajes más modernos, más sexys y con más hype que a la hora de desarrollar algo serio y crítico o eres una super estrella de la programación de esos a los que acude Silicon Valley a su puerta o más vale que te prepares para unos cuantos palos.

[#75 dreierfahrer]

#72 Claro... cosicas de cada framework......

PYTHON 3 NO ES COMPATIBLE CON PYTHON 2



Te entiendo, si, generlemente coges una version para desarrollar y punto... si cambias de version puedes tener problemas....

Pero es que con python olvidate! no vas a poder cambiar nada!!! no es que puedas tener problemas es que directamente olvidalo

Por lo demas, por el lenguaje en si, me encanta python.

[#77 Desactivado]

#75 pero vamos a ver, si vas a hacer un proyecto o estas en uno en una version q necesite rular en 2.7 no vas a irte a ponerte en python 3.x y hacerte una bola de drama infinita. Enserio haceis muchisimo ruido por cosas como esas donde no lo hay. Yo no lo entiendo

Es algo tan facil de entender como el mecanismo de un chupete , esa pega q has puesto me parece de ponerse /cry xq print "hola mundo" no tira en 3.x.

[#42 derosmc]

Pensar que un lenguaje es mejor que otro sin tener cuenta el entorno en el que se usa es de pobres.

[#99 superplinio]

#98 Menos mal que alguien se molesta...
http://gluonhq.com/products/downloads/

[#135 Desactivado]

#99 ¡Pues muchas gracias macho, porque yo lo estaba buscando y no lo encontraba por ningún lado!

[#48 ptijeras]

se nota que muchos de aquí sois desarrolladores... a mi me suena a penalizaciones para una navegación tranquila, siempre hay versiones que actualizar, incompatibilidades con la máquina virtual (OSX 10.9) y me tengo que instalar la beta o para desarrolladores, applets que no cargan y en la que tienes que trampear y empezar a poner excepciones escondidas en menús imposibles de encontrar, con lo que deja de ser "seguro"... vamos de cada al usuario, un verdadero infierno, un por culo constante esto del Java, cada vez que aparece es para incordiar

[#86 Desactivado]

#84 No lo he expuesto bien, usaba el simbolo ">" para mostrar que es codigo, pero has pillado la idea perfectamente

La pregunta es, deberiamos poder sumar un entero con un caracter ? Sin mas ? Como si tal cosa oye. Este tipo de detalles puede inducir a un porronazo de errores segun quien escriba el codigo.

[#70 NapalMe]

Si si, pero algo hecho en JS se ejecuta en cualquier navegador pelado sin hacer nada, para que ejecute algo en JAVA, dando por supuesto que esté instalado, hay que actualizarlo y darle darle permiso expreso para que ejecute.
Hablando claro, alguien puede hacer una aplicación en JS y mandarle un enlace a su madre para que lo ejecute, en java, no.
Para temas "empresariales" me parece estupendísisimo.

[#52 Desactivado]

Java 20 años y sin una biblioteca para hacer aplicaciones gráficas decentes.

[#55 superplinio]

#52 Swing es muy completo y para reemplazarlo le están dando mucha importancia ahora a JavaFX.

Quizá la explicación esté en que la aplicaciones de escritorio nunca fueron el campo de desarrollo principal de Java, que siempre estuvo en el desarrollo web y ahora en el desarrollo para móviles con el "java" de Android

[#57 Desactivado]

#55 Swing de completo no tiene nada y SwingX, que incluye mejores controles, está medio abandonado y con errores graves. JavaFX estará bien si la propia Oracle le diera más importancia pero ni Netbeans trae un diseñador de interfaces gráficoa para el.

[#98 superplinio]

#57 Tienes el JavaFX Scene Builder.

El problema es que han dejado de distribuir los binarios WTF!

No parece la mejor forma de promocionar una tecnología

[#114 Pingocho]

#55 ¿JavaFX? Ya, si no te molesta esperar (y hacer a esperara a tus usuarios) hasta un minuto para que renderice un simple rectángulo. No tiene nada qué hacer comparado con HTML5 (o incluso Flash). Teniendo HTML5 la ventaja de saber que tus usuarios siempre podrán reproducirlo sin tener que descargar o actualizar nada.

[#81 Desactivado]

Javascript es una virgueria, y con ella van asociadas todo tipo de locuras y logicas que parecen irracionales.

Un ejemplo, > 2 + "2"

[#84 scalvo]

#81 Creo que te falta algo antes del signo de >...
No querrías decir algo como: 5 > 2 +"2" //false

[#87 Desactivado]

#81 esa es la tipica mierda de js q hace q te implote la mente mientras intentas no suicidarte mientras vas haciendo scroll por toda la funcion.

[#10 duend]

Los applets que comentamos eran “la moda” y muchas páginas web de su tiempo te exigían instalarlo para ejecutar cierta funcionalidad.

No sé yo si llegó a tanto ¿eh?

[#53 habitante5079]

Java es un auténtico fraude y sus frameworks una mierda.

[#66 Desactivado]

porque estais casi todos hablando de javascript?.
Y java no es multiplataforma? obviamente una aplicacion para escritorio no te va a funcionar en un android pero mientras haya una jvm si. A que nos referimos al decir que se quedo en un sueño a que no puedes ejecutarlo en tu frigorifico?

[#59 Mandela]

y siguen sin eliminar el desastroso CLASSPATH, y sin ofrecer un entorno de desarrollo moderno.
A ver para cuándo una renovación real.

[#61 miguelpedregosa]

Molaría un Android con Golang en lugar de Java

[#60 Desactivado]

Trabajar con la administración electrónica y sus firmas en Java son un dolor.

[#26 Desactivado]

Murió en el momento en el que cada vez que mi navegador quiere ejecutar una aplicación JAVA tengo que descargar una actualización.

[#35 dreierfahrer]

#26 Veo que sabes poco de lo que es java...

[#47 KaborlllLLLONE]

Hola a todos, especialmente a aquellos que dicen que javascript es una mierda o no sirve como full-stack (se dice así?), yo también vengo del futuro y vengo a posta a hablaros de Meteor.

[#97 reivax_dj]

Yo, después de 8 años trabajando con Java/J2EE, hace mes y medio empecé nuevo trabajo y ahora programo con Caché. Apuesto a que casi nadie sabrá qué es.

[#58 Desactivado]

javascript debe de morir como todos su mierda frameworks asociados. Menuda jodida peste.

Por otro lado para mi gusto python > java

[#65 dreierfahrer]

#58 python me gusta, pero tambien tiene sus mierdas....

Ejemplo:

Django 1.4 no es compatible con django 1.5.... Entre otras cosas han cambiado LOS NOMBRES DE LOS PAQUETES.... por $....

[#72 Desactivado]

#65 pero eso son cosucas propias de cada framework python no se reduce a django, de todas maneras cuando desarrollas un proyecto en una version django tendras q ceñirte a la version q uses. Esas mierdillas te las vas a encontrar en cualquier lado. Echar mierda a python por eso es tristisimo.

Yo por mi parte uso flask.

[#104 Desactivado]

#65

Tu ejemplo no es sobre Python. Es sobre un framework para desarrollo de aplicaciones web escrito en Python.

En cuanto a "Django 1.4 no es compatible con Django 1.5"... yo he migrado (varios) proyectos de Django 1.3 a Django 1.5 cuando se liberó aquella versión en el sitio donde curraba en aquel entonces... y no puedo decir que fuese algo "traumático" ni que costase horas y horas de desarrollo, sino más bien un proceso rutinario de mantenimiento.

Y aquí dejo documentación para que me digas dónde "se cambiaron los nombres de los paquetes" https://docs.djangoproject.com/en/1.8/releases/1.5/#backwards-incompatible-changes-in-1-5 De todos modos, la política de Django incluye poner DeprecationWarning's en todo lo que se va a ir cambiando a 2 ó 3 versiones vista. Con lo cual, si no haces caso de dichos warnings o te los pasas por el forro... pues seh, si llega un día que tienes tu proyecto corriendo en una versión del framework y decides instalar dos versiones más adelante, pues no va a ser "hice un pip install y todo fue solo".

Al final, todo son manías personales. Pero precisamente decir que el desarrollo de Django "hace incompatible una versión del framework con la siguiente" es decir una puta burrada.

[#49 TristeTraidor]

Lazarus.freepascal.org

[#113 Pingocho]

#49 Peta un día sí y otro también. Si eres fan de Pascal (es decir, te gusta describir al detalle qué hará cada cosa en tu código y repetirlo varias veces para que al compilador le quede bien claro), mejor te pagas una licencia de Delphi que, aunque costosa, vale la pena.