Portada
mis comunidades
otras secciones
#8:
#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, ...
- 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, ...
#2:
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.
En lo que se veía venir: En una puta mentira.
#14:
#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
https://plus.google.com/+DouglasCrockfordEsq/posts/FeZkpuHKPWN
#106:
#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.
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.
#11:
#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.
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.
#79:
#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.
- 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.
#67:
#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.
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.
#17:
#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.
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.
#41:
#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...
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...
#62:
"¿En qué quedó el sueño de programar una vez, ejecutar en cualquier lugar?" Pues en html5.
Comentarios
#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, ...
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.
Respecto a la compatibilidad ...
#1 ¿Hablas de aquel que con gráficos de los 90 requiere hardware del 2020?
#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.
#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
#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.
#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...
#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.
Por poner un ejemplo en "cierto" juego de cubos.
Javascript apesta ampliamente.
Para hacer chorradas bien, pero para hacer cosas medianamente grandes es demasiado inconsistente.
Java permite hacer código mantenible y fiable.
#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
¿En qué quedó el sueño? En un lenguaje vetusto y engorroso que todos quieren matar pero nadie sabe cómo. Como Cobol.
#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.
#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 ) .
#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.
#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
#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).
"¿En qué quedó el sueño de programar una vez, ejecutar en cualquier lugar?" Pues en html5.
#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...
#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.
#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???
#36 c++ es más eficiente pero menos mantenible y menos estandarizado. ¿ Qué necesitas en tus proyectos ?
Hay muchos lenguajes porque hay muchas necesidades.
#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.
#26 Veo que sabes poco de lo que es java...
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.
#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.
¿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.
¿No sería más bien compilar una vez?
#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
#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.
#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....
#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!
#7 Con U++ o cualquier otro framework multiplataforma C++ sigue pateando el culo de Java.
#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.
Compile once, debug everywhere.
Espero con paciencia el día cuando la gente diferencie entre "sobretodo" y "sobre todo".
#36 Si no te importa multiplicar por 10 el tiempo de desarrollo...pues sí.
Y te aseguro que sé de que hablo.
Yo me llamo Ralph!
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?
#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
#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...
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...
#12 Bendita es la ignorancia
#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.
#120
sip, java no te deja hacer spageti code. Te lo pone más difícil al menos.
C++ permite que hagas desde un código no estructurado, optimizado para un microchip concreto, hasta una programación de objetos pura con gestión de memoria automática (mediante librerías).
Si necesitas punteros locos apuntando a cualquier parte de la memoria, c++ es tu opción. Si quieres tener la seguridad de no tener ninguno y olvidarte del tema, puedes plantearte usar un lenguaje limitado como java.
Java vende esas limitaciones como una ventaja, pero somos conscientes que el que sea ventaja o inconveniente depende de tu proyecto y tus necesidades.
cc/ #106
El eclipse y netbeans son una puta mierda. Queda dicho.
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.
#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)
#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.
#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.
Esto parece un hilo de Barrapunto de hace 10 años. Qué penoso
#18 Eso digo yo....
#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.
#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.
Pensar que un lenguaje es mejor que otro sin tener cuenta el entorno en el que se usa es de pobres.
#91 Me gusta tu paralelismo... ¡Te lo tomaré prestado!
#134 dijo sartre que la libertad es el origen de toda la felicidad y la infelicidad.
#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?
#98 Menos mal que alguien se molesta...
http://gluonhq.com/products/downloads/
#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.
#138 Lo pongo en el post. Madrid y Londres. En Madrid tienes una forma bastante buena de acceder a ofertas que es apuntarte a meetups de angular, y vas recibiendo las ofertas cómodamente a tu correo. Al haber tanta demanda pero tan poca gente en el mercado que sepa, se crea una burbuja genial de ofertas de salarios cojonudos.
#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.
#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....
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
#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....
#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.
#40 J2EE es un mounstruo come ninios....
Despues de meter 50 capas no se puede esperar que nada funcione fluidamente...
#28 Sí, se sigue pudiendo, de hecho es la gran ventajaTM 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.
Cuando se habla de java lo primero que hay que tener claro es si estamos hablando del lenguaje o de la máquina virtual. El lenguaje, como es lógico, se ha ido quedando viejuno y los avances no son ni todo lo rápidos ni todo lo profundos que deberían serlo, pero hay que tener en cuenta la enorme dificultad de evolucionar un lenguaje como java manteniendo la compatibilidad hacia atrás.
Por otro lado, la JVM permite la ejecución multiplataforma de java y otros muchos lenguajes que sin esas cargas de compatibilidad pueden innovar muchísimo más y presentar nuevos paradigmas y formas de programar para la JVM, sin duda los más destacados estos tres:
- groovy -> inspirado en lenguajes como ruby y python, muy fácil de aprender para cualquiera que sepa java.
- Scala -> un lenguaje multiparadigma (funcional y OO) con tipado explicito pero una buena inferencia de tipos al menos. James gosling, el creador de java, dijo hace años que era el lenguaje que más le interesaba.
- Clojure -> lenguaje funcional realmente elegante, una maravilla de Rich Heaky.
Vamos que el lenguaje java se seguira usando mucho años por pura inercia, pero realmente hoy en día no tiene mucho sentido empezar un proyecto "green field" en lenguaje java cuando incluso se puede seguir usando la jvm con otros lenguajes.
#108 el usuario ni se entera porque la mayor parte de código java va a servidor.
Salvo que contemos los teléfonos android que la mayor parte de sus apps están escritas en java y no veo que la gente deje de comprar teléfonos.
#50 El sexo anal es bueno, otra cosa es que le tengas miedo.
#66 Programar javascript es divertido, aunque lo odies como #8. Programar java es un coñazo.
#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.
Lo que más me gusta de java es lo bien que va en los iPhone (un telefonillo de esos que a lo mejor conocéis)
#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.
#4 A los fabricantes de RAM les gusta tu idea
#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
#95 donde esta mi salido? ^^
#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.
#144 la verdad es que tuve mucha suerte, no se ven apenas ofertas en España de Scala (sólo conozco Stratio y alguna otra del grupo de Meetup en Madrid) Me falta todavía rodaje en conceptos avanzados de programación funcional, y tengo poca experiencia, pero creo que voy por buen camino.
Una cosa que me gustaría hacer sería poder contribuir a proyectos de software libre para impulsar esa experiencia más allá de lo que hago en el trabajo, donde no hay nadie del que aprender. Y formación pagada por la empresa, por ejemplo de Spark
La verdad es que es una gozada Scala, supuso un cambio profundo en mi forma de pensar, y afectó incluso a código que programo en otros lenguajes, como Javascript.
#11 "Yo por ejemplo, esperaré a que tenga GUIs decentes."
GTK+
#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.
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.
#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
#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.
#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.
#c-109" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2416303/order/109">#109 Hay que diferenciar la comparación entre entre lenguajes y plataformas, otro punto importante es el ecosistema, es decir, el número de liberías y herramientas que se pueden encontrar para una y otra plataforma. A nivel de lenguaje si comparas java y c# lo siento pero no hay color, esto te lo dice un javero de años y años y ahora llevo algo menos de un año en un proyecto con c#, es lógico, c# es un lenguaje más moderno que obviamente se inspira en java y lo mejora en algunos aspectos, por citar algunas cosas:
- inferencia de tipos, el compilador de c# hace un muy buen trabajo de inferencia.
- Genéricos de verdad, los genéricos de java no existen en runtime son sólo "sintactic sugar", los de c# si existen en tiempo de ejecución.
- Autoproperties, no es una característica que me entusiasme pero simplifica los getters&setters.
- LinQ: Una maravilla, por lo menos la parte para trabajar con colecciones en memoria, no tanto como acceso a datos universal que no lo termino de ver.
- lambdas: en java8 por fin, después de 8 años desde java 7, hay lambdas, en c# llevan mucho tiempo disponibles.
- Await y async para trabajar con código asincrono: otra cosa muy a tener en cuenta, una implementación a nivel de lenguaje que simplifica enormemente el trabajo con código asincrono.
- Excepciones, no tiene excepciones "checked" que es una de las cagadas de java.
Luego a nivel infraestructura ya es otro cantar, c# es microsoft y microsoft es windows, te casas con windows con todo lo que eso implica.
Ecosistema, aqui java también es superior, por longevidad, el número de librerías y herramientas y su estado de madurez en java le saca varios cuerpos a sus contrapartidas en el mundo .net. Por esos existen cosas como hibernate.net o akka.net, o por ejemplo resharper, el plugin más famoso de visual studio, es de la misma gente que hace IntelilliJ IDEA el mejor IDE java con diferencia.
Si no te importa casarte con windows .net y c# son una buena opción, personalmente en un proyecto nuevo rara vez tiraría por ahí y preferiria hacer algo sobre la JVM pero desde luego no en lenguaje java, groovy es mi favorito, scala si no queda más remedio, y si le echas valor quizá clojure.
#125 Ay, cuánto se echa de menos al de la milanesa...
#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.
#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?
Java 20 años y sin una biblioteca para hacer aplicaciones gráficas decentes.
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
#64 ¿a qué te refieres con que "el resultado" no es el mismo?
Javascript es una virgueria, y con ella van asociadas todo tipo de locuras y logicas que parecen irracionales.
Un ejemplo, > 2 + "2"
#111 Yo llevo usándo Qt muchos años. Para mí, en escritorio, es la herramienta que elijo por defecto.
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?
#22 go get github.com/mattn/go-gtk/gtk
Java es un auténtico fraude y sus frameworks una mierda.
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?
#85 ami me gustan ambos.