18/05/2009
02/06/2009
18/06/2009
En realidad el título en inglés es "Top 10 reasons why Java sucks ass" pero no encontré como traducirlo adecuadamente :-P. El autor es un desarrollador de Ruby llamdo Obie Fernández. Como podrás ver muchas de sus razones no tienen sentido alguno pero en mi opinión son una muestra del tipo de ideas preconcebidas existentes en el mundo del desarrollo de software contra Java. Aquí va la lista:
"1) Java tiene un compilador. Al demonio con los compiladores y su falso sentido de seguridad. Con demasiada frecuencia código malo es subido e incluso desplegado en servidores simplemente porque es compilado. En ruby no tenemos ese lujo." Si alguien entiende este punto que me lo explique. Supongo que tiene que ver con que a menudo se confía en los compiladores para que nos indiquen errores u optimicen el código mientras que en lenguajes interpretados es el programador quien realiza esa labor.
"2) Lo creadores de los frameworks Java no son desarrolladores de aplicaciones." Pone como ejemplo a los empleados de JBoss. Bueno, este punto es tan estúpido que no vale la pena debatirlo. Creo que la gran mayoría de los frameworks Java han sido creados por desarrolladores de aplicaciones buscando facilitarse la vida.
"3) La mayoría de los programadores Java son tontos". Aquí el brillante autor realiza simple estadística, dice que si hay 2 millones de programadores Java, es imposible que todos sean buenos porque el número de buenos programadores en el mundo es menor. Sin comentarios.
"4) Java está demasiado fragmentado". Por fin un buen argumento, ese sí es un problema real de Java: demasiadas opciones que confunden a los principiantes sobre el camino a seguir. Pero decir que Ruby es mejor porque solo tiene Rails me parece una tontería. Basta ver lo que paso con Twitter donde Rails no pudo con la escalabilidad y se tuvieron que crear un framework propio.
"5) Java es demasiado lento". Otra idea preconcebida que data de los tiempos de java 1.2 y 1.3; pero sobre todo un argumento muy raro para defender a Ruby que es más lento incluso que Groovy que a su vez es 30 veces más lento que Java.
"6) Java no tiene blocks ni closures". Bueno, closures los tendrá a partir de la 7,
"7) Java tiene IDEs. (...) Todos saben que los buenos programadores usan VIM o Emacs. (..). Si necesitas un IDE no sirves, punto". ¿Alguién quiere debatirlo? Si las herramientas existen, úsalas. Si te permiten desarrollar en menor tiempo y cometer menos errores, ¿por qué no?.
"8) Java tiene buen soporte para debugging. (...) Ruby tiene un soporte ridículo para debugging, lo que quiere decir que nuestro código debe ser probado y legible". Supongo que este punto es una broma.
" 9) Java genera mucho dinero para las empresas". Un buen punto a debatir, ¿hasta qué punto los intereses corporativos han ayudado o perjudicado el mundo Java? Al parecer el mundo Java tiene su mayor fuerza en los proyectos open source y en los desarrollos independientes que han moldeado en gran medida el lenguaje y la forma en que lo usamos. Por ejemplo, las empresas han apoyado EJB2 (incluyendo esos horribles EJB de entidad), JSQL, BPEL; mientras que los desarrolladores los contenedores ligeros, el ORM y el uso intensivo de POJOs. ¿Qué es lo que usamos actualmente en nuestros desarrollos?
"10) Java no tiene a DHH." DHH-> David Heinemeier Hansson, el creador de Ruby. Pues no, no lo tiene ..¿y?.
En fin, bastante encendida y llena de ideas preconcebidas esta lista. La verdad nunca he entendido porque los de Ruby siempre han criticado con tanto ahínco a Java, vamos creo que ni Microsoft y eso que es su verdadero rival, mientras que Ruby tiene un mercado un tanto distinto (más enfocado a creación de aplicaciones web 2.0, mientras que Java si bien sirve para eso obtiene sus mayores ingresos de aplicaciones empresariales -basadas en la web o no- y móviles).
La lista también está siendo debatida en Javalobby quienes han propuesto su lista por las que Ruby sucks ass.
Etiquetas: otro, otro, otro, otro, otro, otro, otro, otro, otro, otro, otro, otro, otro
'suck ass' es bastante soez. Sin el ass podria traducirse como 'apesta', 'birria'.
Yo creo que había que reformular la razón 8.
Cualquier lenguaje tiene mejor soporte para depuración que ensamblador sobre tarjetas perforadas, así que cualquier lenguaje apesta.
Lo que me molesta de la blogocosa es que cualquier idiota puede escribir sus tonterías en un lugar diferente al cuarto de baño de la estación de autobuses, y obtiene sus cinco nanosegundos de fama. ¿Discutir? ¿Pero que hay que discutir? Con un troll no se discute, se le ignora y punto, programe en lo que programe.
Porque ningún programador serio (sea del lenguaje que sea) puede tomarse esta tontería como un punto de partida de un debate técnico y/o interesante. Y ahora en javalobby que Ruby caca, culo, pedo, pis. Pues vale, cuante gente sin habilidades sociales frente a una pantalla de ordenador...
Salu2
Pues yo creo que el punto 2 es bastante acertado y relevante. No, no creo que la mayoría (ni siquiera una apreciable minoría) de frameworks de Java hayan surgido de desarrolladores de aplicaciones. O por lo menos no en el mismo sentido.
Cosas como JSF, por ejemplo, o incluso Spring (y lo digo a pesar de que me gusta Spring, no así JSF que me da bastante mal rollo), no surgen realmente de la idea de "vamos a tomar este tipo de aplicaciones que estamos haciendo contínuamente y vamos a sacar una base común que facilite el desarrollo" sino de otra ligeramente diferente que podría ser algo como "vamos a definir una serie de modelos y herramientas que luego puedan utilizarse para hacer aplicaciones".
La diferencia podría no parecer muy grande, pero lo es, es fundamental. En un caso, el framework es resultado directo de cómo son las aplicaciones para las que se va a usar y en el otro son las aplicaciones las que se convierten en resultado de cómo está pensado el framework. Y si no, decidme que no habéis pasado horas y horas resolviendo situaciones de tipo "y ahora, cómo hago que encaje X con esto?".
Lo siento pero precisamente ese creo que es un punto fundamental y es justo lo que lleva a que luego haya tantas opciones. Van cayendo frameworks y frameworks desde lo alto esperando que alguno se quede.
Aparte de que este tipo se lo tenga algo creído, os invito a leer su post original en:
http://www.jroller.com/obie/entry/top_10_reasons_why_java
Está clasificado como "humor", pero desgraciadamente hay muchas personas que todavía hoy siguen criticando a Java con estos mismos argumentos de magazine matinal de Telecinco.
Un saludo,
//Mr.Solo desde El Geek Errante
Hola venkman,
Yo me quejo algunas veces de la frameworktitis de Java... pero justo el ejemplo que has puesto de Spring no es muy afortunado: porque de hecho sí que nació como una respuesta a los infumables EJB2.0 desde el punto de vista de programadores del día a día que pensaban que podían hacerse las cosas de otra manera más productiva y ligera.
Lo que sí que veo es que muchos estándares intentan dejar contentos a los miembros del JCP más que solucionar la vida a los programadores. Pero desde el open source esos es más raro, ya que no hay tantas servidumbres: ¿Para que gastar mi tiempo libre no remunerado en una solución que no sea útil?
Pero vamos, que el post del insigne blogger simplemente recopila las críticas simplonas de siempre ."Java crea un framework para matar al dragón...." me parece mucho más crítico, respetuoso con la herramienta que muchas personas utilizan en su trabajo y divertido.
Salu2
DHH no es el creador de Ruby, es el creador de Ruby on Rails.
El ejemplo de Spring era intencionado, Ibon.
Pero fíjate en tu respuesta. Spring surge como respuesta a EJB. Perfecto, sí, se trata de simplificar. Me encanta Spring y me parece estupenda su idea. Ahora bien, la respuesta sigue sin ser cierto que Spring surja directamente del desarrollo de aplicaciones. Parte, de nuevo, de un concepto determinado y crece a partir de ahí.
Es lo que quería señalar, que hay una diferencia con otros "entornos lingüisticos". Que en Java se parte más "desde atrás". Que no es necesariamente peor, ojo, pero sí es diferente. La historia de Spring no es la de una serie de gente extrayendo componentes, estructuras, utilidades y patrones de aplicaciones concretas y juntándolas sobre una infraestructura común. Si no más bien es "estos conceptos (EJB) son una mierda para hacer aplicaciones. Vamos a hacer un framework basado en otros conceptos más simples".
Como dicen los anglos: "don't feed the trolls".
Sin más.
"El ejemplo de Spring era intencionado, Ibon."
jejejeje, vale, he mordido el anzuelo :-)
Pero no estoy de acuerdo: la inyección de dependencias no es precisamente un concepto "sencillo" y desde luego parte de la experiencia ---> ¿Cómo conseguir realmente el desacoplamiento? Que me parece anterior a los EJB's. Si quieres, Spring vino a decir "oye que no hace falta ese pedazo de framework para hacer aplicaciones empresariales, que ya tenemos Java y hemos comprobado que se puede hacer" :-). Y de hecho sí que se basaron en la experiencia concreta de "gentes" (Martin Fowler entre otros) que en sus desarrollos veían patrones y arquitecturas sin necesidad de seguir un framework a pies juntillas.
Sé lo que quieres decir pero creo que por donde tira el tipejo podría ser más comparable Struts con Rails, por ejemplo. Y la verdad es que yo también soy crítico a veces con la sobreingeniería: Hibernate me gusta en muchos aspectos, pero el lazy loading ha obligado a tantos absurdos y a crear nuevas capas y soluciones para usarlo que a veces echo de menos simplemente cargar yo los objetos cuando y donde me apetezca, como en los viejos tiempos. Pero eso es un problema de lo que hace la gente con los martillos, no del martillo en sí.
Salu2
¡Comparto el tema de la frameworktitis de java! hay demasiados fw par todo. Y no vengan con que "uno puede elgir el mejor", no hay tiempo para probar 3 frameworks. Se elige en parte por prejuicio y en parte por experiencia, y uno siempre se queda pensando que quizás se podría haber hecho todo en otro. Y, en general, los frameworks de java no dan la impresión de haber sido hechos por desarrolladores de aplicaciones, sino por "teóricos del framework"
La crítica a JAVA es irónica y humorística, pero siempre se puede aprender algo. La idea de que "los buenos programadores usan VIM o EMACS" o que el soporte de debugging hace que todos escribamos peor código es una estupidez....pero tiene algo de cierto. Hace poco tuve que dejar de usar el eclipse y escribir java a mano por un trabajo puntual, y eso hace maravillas por la legibilidad y la efectividad del código. Pero creo que eso se ralaciona con la fragmentación: es imposible recordar las mil librerías que se usan en cualquier proyecto java. Así y todo, prefiero usar un IDE siempre! Y Ruby tiene mas de un IDE, incluso alguno excelente, como el NetBeans.
10) Nosotros tenemos a Gosling
Increíble que cualquier tonto escriba estupideces en un blog y ésto se replique y salga en portadas de webs más serias como Javahispano, pero al fin y al cabo es lo que tenemos que pagar por la "democratización" del Internet.
Sobre el contenido del artículo no hay ni que discutir, ya que claramente fue escrito por alguien que no tiene ni la más mínima idea de Java, excepto sus prejuicios adquiridos. Lo feo de todo este asunto de Ruby vs Java (que en realidad debería de ser Ruby on Rails vs Frameworks de Java), es que existen personas de ambas partes que se dedican a difamar y deslegitimizar al oponente con absurdos argumentos, lo cual hace afecta la calidad y objetividad de la comunidad, es algo parecido a la guerra Windows vs Linux o KDE vs Gnome.
Lo peor de todo es que por estar inmersos en esas tontas batallas, los programadores pierden objetividad y comienzan a parecerse más a una religión, donde todos los dioses ajenos son falsos. No solo Ruby, sino cualquier lenguaje, debe aprender mucho de Java, pues éste lleva años de experiencia, pero los desarrolladores de Java también deben aceptar y mejorar sus falencias. Finalmente, como en todo, solo quedan los prejuicios en la mente de las personas. Una lástima porque esto afecta la fama de un par de excelentes lenguajes.
Por cierto, por favor no confundas Ruby con Ruby on Rails. El primero es un excelente lenguaje con una apacible comunidad.
Anónimo: sí, es absolutamente increíble que el precio que haya que pagar porque tú (anónimamente) puedas decir tu opinión es que cualquiera pueda decir la suya.
Oh, perdón, ya me callo :)
El 99% de las criticas que hace este personaje que se hace llamar "programador" son solo de una persona que esta encasillada en un solo lenguaje sin conocer pros y contras, en este caso de Java.
En cuanto a lo de los frameworks, tienes toda la razon venkman, hay veces que en vez de facilitarte las cosas te las complican porque no sabes exactamente como hacerlo encajar con lo que ya se tiene o con lo que se va a hacer.
Saludos
Cualquier persona que emita un comentario asi sobre cualquier lenguaje o tecnología sencillamante deberia ser ignorado, cada lenguaje o plataforma tiene su razon de ser, sus pro y contras pero no por eso se debe decir que es una porqueria o no sirve, sencillamente este tipo de personas lo que buscan es ganar protagonismo de otra forma que no sea demostrando sus conocimientos. Ademas de demostrar inmadurez como profesional, si es que lo es.
saludos
Java con compilador???
Es bueno que este cabezon lea que son los traductores y entre esta linea que son interpretes y compiladores. Ademas que ventajas tiene un lenguaje interpretado (java) de uno compilado.
Para los que se les escapo el humor de la lista, algunas clarificaciones: http://www.jroller.com/obie/entry/what_subtelty_and_suck_ass
Vamos... defiendan a Java a gusto pero Java ES lento.
Saludos
http://fernandorferrari.blogspot.com
Yo tengo preparados unos cuantos:
- 10 razones por las que los que se dejan barba no son hackers si programan en Ruby
- 21 razones por las que un tio que se apellida fernández es subnormal
- 39 motivos por las que quien programa en Rails es tonto del bote
- 51 maneras de promocionar la mierda de libro que he escrito sobre como coño aprendí Ruby copiando código de Internés
- 27 maneras de decir que tengo un blog sobre Rails cuando todos los posts son o sobre el sexismo en las IT o bromas divertidisimas.
Y verás que panzá de reir y cuantos hits consigo en mi mierda de blog. Hala, ya ha perdido un lector de su libro.
Salu2
lento tu blog macho, con tanta chorradita 2.0... XD
Estimado Fernando, si java es tan lento (?), me gustaría que nos explíques por qué los últimos benchmarks de JRuby, muestran que tiene mejor desempeño que la implementación oficial de Ruby. ;)
Por cierto, parece que aquí tenemos un concepto novedoso: Los lenguajes tienen velocidad. Amigos, les sugiero que dejen de hablar en Español porque es un lenguaje muy "lento" Ni hablar del lenguaje de señas. XDBueno, dejar la frase "Java es lento" y nada más en una comunidad sobre Java es una buena forma de recibir visitas en el blog. Ni con web nueva desaparecen los trolls.
Respecto la noticia.... se tendrá que empezar a ver el programa "El rey de la comedia" a ver si vemos un tal Obie Fernandez :P.
Saludos.
Hola amigos.
Que triste es ver de un una persona que critica de un lenguaje de programación si no tiene el conocimiento del potencial que maneja java.
no se si conoceras muy bien:
Java no es lento, quien lo hace lento es su desarrollador, por la falta de conocimiento de la arquitectura que quiere emplear en su aplicación WEB.
Pero siempre al hacer una critica se tiene que demostrar.
solo te comento que IBM, ORACLE, CLARO, HP y otras compañias de renombre invirtieron en JAVA.
ahora te pregunto: ¿si el lenguaje fuera lento que interes tendrian en invertir en JAVA?.
bueno sin comentarios.
att. Istvan
¿Como ha llegado esta tonteria a portada? ¿Llegaria a portada un blog sobre las 15 mejores maneras de limpiarse las pelotillas del ombligo?
Java es un lenguaje multiproposito, mientras que Ruby no. Me gustaría ver como se las
apañan los programadores de Ruby para crear una aplicación que acceda a puertos serie RS/232!!!!!
Hola a todos.
Yo tengo claro que Java en aplicaciones web no es lento, o al menos no es más lento que cualquier otra tecnología. Ahora bien, voy a hacer una pregunta, y por favor que no se me malinterprete porque me encanta Java y en modo alguno pretendo crear polémica barata ni malestar en el foro.
Sí tengo compañeros de facultad que se quejan de que Java es lento, sobre todo en el ámbito del escritorio. Quizá sea porque ejecutan aplicaciones Java en equipos antiguos (Pentium IV por poner un ejemplo) o quizá porque no son aplicaciones optimizadas. Yo quisiera preguntar si la misma aplicación (de escritorio, claro, porque en web para mí no hay duda de que Java no es más lento como ya he dicho) hecha en C++ por ejemplo es más o menos veloz que hecha en Java.
¿Es posible que si alguna aplicación de escritorio escrita en Java resulta lenta -ahora mismo no se me ocurre ninguna- pueda deberse a una mala programación o que está empleando un jdk antiguo?
Gracias de antemano.
Un saludo,
José María
Java con compilador???
Es bueno que este cabezon lea que son los traductores y entre esta linea que son interpretes y compiladores. Ademas que ventajas tiene un lenguaje interpretado (java) de uno compilado.
Tambien algunos deberian mirarse lo que es "compilar a bytecode", "compiladores dinamicos" etc. Java interpretado... ains que bueno. Como mucho se interpreta, suponiendo que no uses HotSpot, el bytecode... pero Java no ha sido interpretado en la vida.
vaya por Dios, me expiró la sesión. El último anónimo soy yo
>¿Es posible que si alguna aplicación de escritorio escrita en Java resulta lenta -ahora mismo no se me>ocurre ninguna- pueda deberse a una mala programación o que está empleando un jdk antiguo
Según mi experiencia, no mucha, llevo poco más de un año programando en swing. La lentitud de java en el escritorio en equipos lentos se debe a una mla gestión de la memoria disponible. Según vamos programando nos olvidamos de todo lo que tenemos en memoria y seguimos metiendo más y más cosas. Yo aceleré bastante la aplicación simplemente evitando que cada vez que se abra una ventana de clientes, por ejemplo salga la lista de todos los clientes en la pantalla, como hacen la mayoría de los programas. Puse un edittext para que pudieran hacer un filtro preliminar y sólo sacar los listados a petición del usuario.
Otro problema, el trabajo con threads. SwingWorker soluciona muchos problemas. Además recomiendo https://appframework.dev.java.net/ facilita mucho las cosas y es muy simple.
Otra cosa muy importante es escoger un look&feel austero. Sí, ya sé que lo de los sombreados, los efectos y tal están bien. Pero una vez le has enseñado la aplicación al cliente/jefe ya puedes poner un estilo estandar que en un ordenador normalito pintará mucho más rápido.
Mmmh.. Claro, sobre el post... ;) Creo que las ventajas de que cualquiera pueda escribir superan a las desventajas de... que cualquiera pueda escribir. Al fin y al cabo este post tiene muchos más comentarios que todos los de ésta página juntos.
Al final los trolls cumplen su labor... Nos animamos a escribir aunque sólo sea para cerrarles la boca. Y al final siempre sale algo interesante.
Sobre los frameworks, tengo un compañero que se está mordiendo las uñas porque tiene que hacer un pequeño proyecto en struts y aún se está preguntando porqué siguen esos programadores todavía en la calle, con lo peligrosos que son para la salud. Según las pesadillas que me cuenta no tienen perdón. ;)
Yo por el contrario estoy probando seam, y lo del JSF pues aún no le he visto problema, aunque supongo que no he llegado al nivel de dificultad suficiente para valorarlo adecuadamente, la verdad es que estoy encantado con éste. Quizá ha llegado tarde, pero ha llegado y es un framework realmente orientado al programador, simple y potente.
Lo de spring... Lo probé pero me mosquea mucho. Estuve trabajando con ejb2 y reconozco que en su momento podría haber sido de ayuda. Ahora no veo qué puede ofrecerme, cuando puedo coger un jboss, crear mi aplicacioncita en seam que con el asistente se crea el esqueleto en 5 min y deployear sin tocar ni un xml, todo a base de simples anotaciones, cuando hay que ponerlas que en la mayoría de los casos van implicitas. Y si después me da por ahí, pues lo meto en un cluster, o le pongo una cache L2. Lo de que spring es "lightweight" mi madre cuanto odié esa palabra XDD era ligero en la medida que no le añadieras nada. Cuando necesitabas un tomcat, webservices, remoting, clustering y cache, pues era tan lightweight como un trailer de elefantes XDD
Supongo que en la próxima versión de JEE se resolverá el mayor de los problemas actualmente, hacerlo realmente modular para poder quitar y añadir componentes fácilmente.
Aunque reconozco que no pude valorar bien spring, porque nadie llegó a convencerme. Escribí a algunos colegas que trabajaban con spring para que trataran de deslumbrarme con sus maravillas y porqué iba a dejar mi flamante jboss colgado por una nueva visión de las cosas... Pero esa revelación no llegó, y todo me parecía más humo que otra cosa. Aunque siempre se queda la espinita de pensar que hay algo que no has visto ;)
la verdad es que java si es lento en el escritorio..... Optimizar dicen por ahi.... mmm como.... por favor enseñen.... jejejej tendrian que enseñar hasta a los programadores de SUN miren cuanto de RAM se morfa el netbeans 6 ... es una burla..... encambio el querido eclipse (IBM) creo ... =D es mas rapidito... mmm pero no hay que abrir muchas pestañas..... Ahora java en animacion... han visto el librito de Roman Guy... es una burla el tipo paradea con las huevaditas que hace.... super pesadas... ni hablen de javafx script.... prefiero numas a flash o XAML pero.... despues de todo no hay nada que hacer nadie para a java.. es lo mejor... tiene mucho mas Soporte... entra donde sea... quien sabe si dios nos programo en JAVA....jejejje ... ojala no se vuelva un monopolio para empresas apendejadas.... desde bolivia.... tarija..... GRACIAS....
no deberia llamarse rubby sucks ass, sino rubby sucks balls
Java es potente, pero me uno a los que dicen que es lento.
Porque las aplicaciones java son lentas???
alguna respuesta con sentido???
Veamos, para decir que algo es "lento" hay que compararlo contra otra cosa, y ubicarse en el contexto del dominio de problema que se intenta resolver. Para desarrollar una aplicación gráfica para PC, java será más lento que c++, pero será más veloz que Ruby, por ejemplo. Por otro lado, si deseas desarrollar una aplicación para móviles, creo que no te quedan muchas más opciones que java, así que en ese caso no puedes comparar con otros lenguajes. Esto es similar a decir que JavaScript es lento. Por supuesto que JavaScript es más lento que c++ si quiero hacer un cálculo de series de Fourier, sin embargo no conozco a nadie que haya desarrollado una aplicación AJAX en c++. Por otro lado, java suele ser más "veloz" que Ruby, pero sin embargo no conozco a nadie que prefiera a java por sobre Ruby para resolver DSLs. Parece que algún sentido tiene la definición de Atributos de Calidad que siempre me pareció tan superflua: Desde el inicio de la informática, performance se ha contrapuesto con portabilidad y tiempo de desarrollo XD
Saludos ;)
El anónimo que dijo que Eclipse es "lento" supongo que estará comparando a Eclipse contra KDevelop. Perfecto, KDevelop es más "veloz" que Eclipse. Ahora bien, tengo un par de preguntas para él: ¿sobre cuántas arquitecturas corre KDevelop?¿Los plugins de KDevelop, compilados por única vez, corren sobre todas las arquitecturas por igual?
Gracias.
"alguna respuesta con sentido???"
A ver si te vale esta.
El codigo generado por Java es lento la primera vez que se usa. Despues es tan rapido como cualquier compilado y su velocidad depende de lo habilidoso que sea el que ha escrito el compilador (y el de Java debe ser muy bueno optimizando porque es en lo que mas empeño ponen los desarrolladores).
Tu escribes una clase, la compilas y javac te la deja en un emsablador raro que llamamos "bytecode". Despues, cuando la ejecutas, java emsambla ese ensamblador y lo convierte en codigo maquina y lo guarda en una cache para la proxima vez que lo uses. Eso le lleva un rato, asi que la primera vez que pasas por ese codigo tarda mas en ejecutarse, pero las demas veces ya es como si estuviera escrito en C++.
¿Que sensacion tienes tu cuando usas una aplicacion de escritorio escrita an Java? Pues que la primera vez que abres un cuadro de dialogo este es mas lento que en otras aplicaciones porque la clase que lo implementa se tiene que compilar, pero las demas veces que lo abras te ira bien. Si en el trabajo normal de una aplicacion abres 15 dialogos 50 veces, esperaras 15 y te ira rapido 49, pero probablemente te quedaras con la primera sensacion.
¿En las aplicaciones web? Pues como se arranca un servidor y mientras este levantado devuelve siempre las mismas clases, el primero esperara (y culpara a su ADSL) pero los demas tendran su pagina muy rapido. Por eso Java ha tenido mas exito en los servidores que en el desktop (politica de marketing de Sun aparte).
Esto en teoria. Despues depende de como se programe, en que maquina estes, que JDK uses, etc. Como todo. Y de tu capacidad de observacion, porque si te vale como ejemplo, yo en un Core2Duo no noto ninguna diferencia al desplegar un menu de una aplicacion Java y de otra aplicacion (y uso un laf que es bastante lento desplegando menus).
La fama de lento de Java viene de cuando surgio, que lo mas rapido que habia en las mesas era un pentium (1) y los de marketing de Sun, Netscape, IBM y todas esas que se querian (y aun siguen erre que erre) cargar a Microsoft se empeñaban en que todas las aplicaciones iban a ser Java descargadas de internet (por un modem de 56k) y asi no seria necesario ni Windows ni disco duro. Y claro, con un pentium y un modem de 56K... Java sufrio las pajas mentales de unos gurus ambiciosos durante la fase esa de las .com.
Mis dos centimillos.
Muchas gracias nilojg.
Tu explicación ha sido clarísima y me ha ayudado a entender el porqué de ciertos comentarios injustamente parciales con respecto a Java. Tus dos centimillos, al menos esta vez, han valido miles.
Un saludo,
José María
Si todas las notícias tienen que tener comentarios tan ricos como el que ha dejado nilojg por mi que todas las notícias sean así.
Saludos, olope.
Metiendome en una discución de la qué no tengo cabida, por el poco conocimiento que poseo de Java, creo a mi entender que gastarse en discutir Java vs Ruby es totalmente inútil.
Ruby es un buen lenguaje, pero Java es un lenguaje en serio, como todo tendra sus punto debiles o no pero las 10 razones que dio son las más estupidas que uno puede encontrar, creo que para criticar, antes tendría que haber tenido sus años desarrollando en Java y Ruby, sino no esta a la altura de la circunstancia y realmente por lo que deja entreveer sus exposiciones, son burdas, con falto de conocimiento de programación y sentido crítico y lógico.
Más halla de todo, hace poco empecé con Java y justamente fué por ideas preconcebidas, entre las que encontramos las inestabilidad, lentitud y gastadero de recursos, ideas que con el conociemento del lenguaje y prueba y error se superan de lleno.
Saludos y a no gastar tiempo en criticarlo que no lo vale!!!
Llego tarde pero había uno por ahí que preguntó...
>¿Es posible que si alguna aplicación de escritorio escrita en Java resulta lenta -ahora mismo no se me>ocurre ninguna- pueda deberse a una mala programación o que está empleando un jdk antiguo?
Sí. Si no analizaas/diseñas/programas multihilo y con JDK inferio al 5.0 tienes que montártelo _muy_ bien para ser rápido en el escritorio.
Escribe tu comentario