Barrapunto

Bien, en una maquina a 1900 has conseguido la misma velocidad perceptible que en un 300 con similares en c++

Pues si, en las aplicaciones que he nombrado (aplicaciones de interfaz de usuario grafica) no notarias la diferencia en velocidad si no las conocieras y no te dijera cual es Java y cual es C++.

Yo clientes tipo limewire conozco alguno mas en Java, pero me daba verguenza usarlos porque no podia arranzar un abiword simultaneamente.

Pues mira, yo estoy usando Limewire ahora mismo, Mozilla, KDE3.1 al completo, Konsole con 4 terminales abiertos y Kate, y ninguna de las aplicaciones me va lento, ni lo va el sistema (256 megas de RAM tengo, no es para tirar cohetes). Pero esta claro que eres un troll y no vas a razonar, asi que para que vamos a razonar, si la logica no cabe en tu misero cerebro.

Se te ve que sabes tanto de C++ como de Java

Basta de hablar, enseñame tu codigo y yo te enseño el mio, mamarracho. ¿Sabes hacer otra cosa que no sea hablar? Yo puedo demostrar lo que digo, aparte de desarrollos privados hay mucho codigo mio en una aplicacion que usan MILES de personas bajo entorno Linux y es uno de las aplicaciones GUI mas utilizadas. Pero como te digo si no sabes hacer otra cosa que no sea hablar no me vaciles con que si yo se o no se; enseñame tu codigo (que estoy seguro, no existe) y yo te enseñare el mio.

Caracteristicas nuevas de C++ pocas la verdad

No tienes ni puta idea y cada vez lo demuestras mas dejandote en ridiculo a ti mismo:

• Plantillas
  
• Excepciones
  
• casts dinamicos
  
• Identificacion de objetos
  
• Las STL (no son parte del lenguaje, pero si del estandar).
  
• Espacios de nombres
  
• etc etc etc
  

Hazte un favor y deja de hablar de cosas que no sabes ni comprendes. Vuelve arrastrandote al agujero del que has salido a hacerte pajas pensando que sabes algo (y aprende ortografia de paso).

Mira en grandes sistemas...para que decirte, bueno, mejorare tu "esa afirmacion es incorrecta, miralo en un libro". Los sistemas grandes en primer lugar son HETEROGENEOS, es decir, hay una realidad, ningun sistema "grande" se hace en un solo lenguaje, sea el que sea. Lo son por el mero hecho de que el software nace, crece, crece, crece, crece, ... y con ello se adapta. Un sistema grande puede usar normalmente un minimo de cuatro o cinco lenguajes. Entre ensamblador, c, c++ y un par de ellos de scripting.

Como cambiamos de tema ¿eh? Me dices que C++ es mejor que Java para grandes sistemas, y cuando te doy los argumentos tecnicos de que puede que eso no sea asi me sales por peteneras. ¿Tiene hora? Si, hace buen tiempo...

Es mi ultimo mensaje respondiendo a este troll, porque se descalifica asi mismo con sus afirmaciones, pido perdon a los contertulios por las palabras subidas de tono, pero tenia que deshaogarme.

Creo que estamos diciendo lo mismo, no te lies...

Si dejamos de lado partidismos y vamos directos a la cuestión, es decir, es Java rápido ó lento. Os aconsejo que echeis un vistazo a esta comparativa sobre la velocidad de los lenguajes donde por lo que he visto podemos llegar a la conclusión que en algunas facetas predomina la velocidad de c y c++, mientras que en otras se destacan los lenguajes funcionales como pueden ser caml ó haskell, quedando Java bastante por detrás de estos (ojo en velocidad, que no quiero que os abalanceis sobre mi)

He cambiado las prioridades en la página esa, siguiendo el enlace que dice "scorecard", para primar lo que personalmente le pido a un lenguaje. No me he esmerado mucho, simplemente he hecho cambios que me parecen elementales, como premiar que sean rápidas las tareas necesarias en un servidor. Seguro que encontráis otras combinaciones interesantes. Con esta mía a bote pronto, cambia la clasificación de forma muy curiosa:

Ocaml ocaml 33230
Ocaml ocamlb32750
Pike pike 30450
Perl perl 30380
Python python 30130
C++ g++ 29520
Ruby ruby 29380
Scheme bigloo 28031
Common Lisp cmucl 27930
Scheme guile 27730
Lua lua 27572
Forth gforth 27092
C gcc 26640
SML mlton 25640
Tcl tcl 25203
Awk mawk 24406
Java java 24350
Icon icon 22827
Haskell ghc 22135
Lisp rep 21933
Awk gawk 21356
SML smlnj 21220
Javascript njs 20655
Mercury mercury 17708
Erlang erlang 17678
PHP php 17579
Eiffel se1 7074
EmacsLisp xemacs 16259
Forth bigforth 139410
Bash bash 99514
Scheme stalin 82317

Dialecto XML?... valgame Dios!...

JSP acrónimo de Java Server Pages...

O sea,.. por lo menos en el significado tiene algo que ver con Javita no?...

Honestamente creo que no tienes ni la más remota idea de lo que es, y de lo que se puede hacer con los JSPs... no se porque te pones a discutir cosas que no conoces...

:P

En fin...

Estoy de acuerdo,...

ulises31 tiene toda la facha de un niño Macromedia, que todo lo quiere resolver con Flash y con DW...

No puedes ni debes hacer comparaciones del tipo Flash vs Java,.. olvídalo,.. ni siquiera vienen al caso. Te quedaste con la idea de que Java únicamente vive dentro de una página web,.. mal.. mal... mal...

Evidentemente no conoces el campo de aplicación de Java, pero si tienes real interés en conocer en donde se puede usar Java, y que proyectos se están realizando, nadamás echale una visita a sourceforge (conoces sourceforge no?)...

Saludos!

En todos los grupos de Java es frecuente la Pregunta ¿Que IDE me recomiendan? y la respuesta casi siempre es Kawa, Emac, Notepad, etc. como recomendables, todos estos entornos no estan hechos en Java. Y los entornos que menos se recomiendan son Forte, Jbuilder, etc. Entornos realizados en Java.

¿Por que será?, estamos hablando que son los propios usuarios de java los que recomiendan esto.

... pero Jambala no parece demasiado "grande" (lo que sí deberá ser grande, sin duda, será la máquina en que corra :)); no es más que un servidor de aplicaciones.

Me uno al colega de los del Olimpo, para recordar a los dioses los fundamentos de la OOP, que no el pregón
abstraccion, polimorfismo, encapsulación y herencia (y nunca he oido que TENGA que ser multiple)
Mmmmm
Es mejor callar y parecer tonto, que no hablar y despejar las dudas definitivamente... (Groucho Marx)

Jsp se compila como un servlet java, creo que no tienes mucha idea de java, ademas de que empresas como timofonica tiene grandes desarrollos en J2EE, al igual que otras y que ahora es de lo que mas se demanda (a las consultoras), ademas de tener desarrollos mixtos tuxedo (c-c++) con jolt (java puro y duro , con clientes java hechos con visualAge y te estoy hablando de proyectos muy grandes como podria ser su facturacion) y lo se de buena tinta porque trabaje alli.

Como siempre, en Barrapunto empiezas un comentario por un sitio, te sacan la noticia a portada y tus comentarios desaparecen. El debate se inició en este punto y estaba la cosa muy interesante. Seguiré respondiendo por aquí.

Una cosa que no entiendo; y tomo las matemáticas como base. Si el tiempo de ejecución de una tarea es 'T', suponiendo que programemos en cualquier lenguaje no interpretado obtendremos que se estarán ejecutando instrucciones (no se cómo llamarlas, no es el término mas apropiado) productivas todo ese tiempo 'T'. En un lenguaje como Java (y cualquier lenguaje interpretado) tendremos un tiempo 't' en el cual la máquina virtual (o el intérprete, o...) usa ciclos de CPU para_lo_que_sea. Consecuentemente, de todo ese tiempo 'T' del que disponemos, realmente el tiempo en el que se están ejecutando instrucciones útiles es de 'T-t'. Y perdonadme que os diga, pero de siempre me han demostrado que:

        T > T-t para todo t > 0 --> caso de lenguajes interpretados
        T = T-t para t = 0 --> caso de lenguajes no interpretados

Por mucho que se optimice, por mucho que se quiera mejorar Java, 't' seguirá teniendo siempre un valor, que hará que la ecuación que se cumpla sea la primera. Consecuentemente, dos algoritmos implementados idénticamente correrán siempre mejor en un lenguaje compilado que en uno interpretado.

Y no me estoy metiendo con la portabilidad, si es más fácil programar en uno que en otro... eso va para otro artículo.

Pues a mi siempre me ha llamado la atencion la ventana MS-DOS con una tacita en la esquina que aparece cuando inicias Kawa, y desaparece cuando se abre... Como no lo se, no lo afirmo... pero parece java.
Notepad un IDE? Emacs un IDE? Vale, entonces el mejor IDE es ed :)))
Que tal si hablamos de jEdit?

el nokia 3410 que me voy a comprar, por 82 euros (con ofertas claro) tiene J2ME, es mas ayer iba a comprarlo y se habia agotado, he tenido que pedir que me lo reserven, mas cosas java chaval que te veo desinformado hay otra cosa llamada personalJava que esta para pda's y si te vas a la web de Zaurus (www.myzaurus.com) y veras que hay desarrollos un project hecho en java para la pda y mas igual que los hay para palm en j2me pues el mismo programa vale para el telefono y para la palm y muchas mas cosas que tiene java tv-HOteles con interfaz java (con la intervencion de nokia) etc

SÍ

Pero vamos a ver, te hablo de algo que están utilizando unos 20 millones de nipones, y que muy pronto utilizarán (si no lo hacen ya) cientos de millones de europeos, americanos, etc... te hablo de algo que, si es por tamaño, ocupa pero que muuuuuchos megas, te hablo de algo que funciona y que ya está presente en varias telecos...
Entonces ¿con que cara me hablas tú de que no hay grandes sistemas Java? el que TÚ ni los conozcas ni los veas no quiere decir que no existan, estás lanzando juicios muy atrevidos pero basados en la simple ignorancia:'si yo no los veo, no están...' ¡eso sí que es un juicio razonado! ole!
'es difícil encontrar aplicaciones java' MENTIRA, sólo en SourceForge hay una foundrie dedicada sólo a Java. Date un paseo, anda.
'Java no se usa en videojuegos' MENTIRA (podemos hablar de los teléfonos móviles... ¿puedes hacer juegos en C para móviles que funcione en más de dos? ¿puedes? ¿eh?, venga, contesta ¿puedes?
'tampoco en sistemas' ¿de qué sistemas me hablas?
'tampoco en IA' MENTIRA (¿sabes lo que son las arquitecturas para agentes? ¿a que no?, ¿y qué te parece esto? ¿sabes lo que es un framework para redes neuronales?)
'tampoco en investigación' MENTIRA
'tampoco en aplicaciones de escritorio' MENTIRA (OpenOffice utiliza soporte java por debajo, sólo por ponerte un ejemplo)
'apenas en el web' ¿QUÉÉÉ? pero ¿tú en que mundo vives? ¿pero tú sabes que es un servidor de aplicaciones?, y ya puestos, ¿cuántos conoces hechos en C?
Y ya que te gusta reirte de las faltas de ortografía de los demás, te aconsejo que releas tu primer mensaje y su exceso de 'ha's ... no quise mencionarlo porque no tiene mucho que ver con lo que hablamos, pero bueno, parece que además de 'iluminado casero' te gustan los golpes bajos.
Por otro lado, no he dicho si me creo o no el tema del rendimiento, pero no veo que tengas que llamar a nadie zelote por haberte pillado con los pantalones bajados y decirte cosas que no te gustan oir, cretino.
Ya que estamos, dime cualquier otro lenguaje con la mitad de la implantación que tiene java en el campo de los sitemas distribuidos, que tan gustosamente te olvidas de mencionar.

Qt, Qt, Qt.... Aqui puedes leer todas las plataformas que soporta Qt, y en cada una, los problemas que presenta... aparte de tener que compilar para cada una (Que igual no dispones de las maquinas o el compilador no te da opcion a ese formato) tienes que estar pendiente de los problemas que "podria" presentar... ademas.... No puedes probarlo... Y hablamos de Qt, no de otras librerias que puedas tener que usar.... En Java, si usas librerias 100% Pure Java, te olvidas.

... visites esto: nada menos que un sistema operativo desarrollado enteramente en Java. Como ejercicio lo veo bien, como entretenimiento también... ¿A alguien se le ocurre alguna utilidad mas?, a mi no.

>> Java no tiene rival en el servidor

¿Has visto C#?...

He estudiado bastante el shootout y creo que lo mejor hacer caso al autor: el mejor lenguaje es el acordeon.

En realidad este hombre empezo probando lenguajes de script, para luego extenderlo a todo tipo de lenguajes. El metodo que emplea es muy sencillo, y puede ser adeacuado, pero no debemos sacar verdades sagradas de estas pruebecillas. El autor es el primero en no tomarselo demasiado en serio.

Para el caso particular de java, la metodologia me parece particularmente floja, hice unas pruebas con el reloj dentro del propio programa y los resultados son bastante distintos.

Y precisamente, lo que el señor del JRockit nos dice precisamente es que él opina (¿o sabe?) que unas pequeñas pruebas sinteticas, como por ejemplo el shootout, ya no son realistas para un compilador JIT.
 

Utilizo el forte, columba, mi servidor web utiliza jsp, mi programa de mp3 esta programado en java, el gui del edonkey es el de java....
Vamos que no utilizo java para nada......
Por cierto, lo de lenguaje pobre de donde lo sacas???

No estoy de acuerdo con los "T" y "para todo T"... :-)

Quizá te falta una variable en tu "ecuación", llamada "JIT"....

Tu has mirado la web de Nokia??? porque los telefonos de nokia van con un SO llamado symbian te suena? es la nueva version de Epoc si si no me mires con cara de asombro, primero informate y luego habla s, pero informate de verdad. Por cierto symbian tiene un estupendo soporte de java oHHHHHHHHHH, del cual se estan hciendo juegos ohhhhhhhhhhhhhh, pero tu chaval como puedes decir esas cosas? como se nota que no tienes ni idea ni de java ni de moviles ni de na (excepto de c++ :-P)

Java no es exactamente un lenguaje interpretado, es un lenguaje compilado como C, solo que corre en una maquina virtual. La maquina virtual, los JIT y compan~ia pueden hacer que el programa en java corra con instrucciones nativas, especialmente bucles y cosas por el estilo. Un programa en java lo compilas una vez y luego lanzas el ejecutable en la maquina (virtual) correspondiente. Y no digo que se pueda comparar con C compilado.

  Por otro lado un compilador estatico no produce necesariamente codigo mas rapido que uno dinamico, aunque en la practica seguramente si. Pero no es una evidencia matematica. Podria darse el caso por ejemplo de una zona de codigo con una combinacion de bucles muy largos que estan unos dentro de otros, combinados, etc. Puede darse el caso de que el compilador estatico tenga que elegir entre optimizar de una manera favoreciendo un aspecto u otro, pero no sabe en realidad que bucle tendra mas peso en un porcentaje alto de las ejecuciones y decide optimizar de una forma determinada. En cambio un compilador dinamico puede ajustar esas optimizaciones en base a los resultados que le da a medida que la aplicacion se ejecuta una y otra vez, de manera que al final da con la combinacion optima.

  Aunque en las grandes aplicaciones corporativas, como en la que estoy trabajando en java, si un determinado proceso tarda 2050 milisegundos en vez de 2025 no importa en absoluto, porque seguramente 2000 de esos milisegundos se los pasa esperando que oracle o los back-end le devuelda un resultado.
Lo que si es una ventaja importante de java en estos casos es su manejabilidad, seguridad, escalabilidad, facilidad para mantener, velocidad de desarrollo... comparado con C++ por ejemplo. Estas cualidades en gran proyecto las puedes enunciar tambien como: dinero, dinero, dinero, dinero... ahorrado. Y pueden ser la diferencia entre el exito o el fracaso de un proyecto, el tiempo.

  Y la velocidad de ejecucion 'global' te aseguro que sera la misma. Estoy hablando de aplicaciones corriendo en servidores unix como dios manda que estan interconectadas con infinidad de otras maquinas, no hablo de una aplicacion tipo autocad, quake o un programa de escritorio.
Vamos, yo diria que java en estos entornos a barrido y los sres de microsoft lo estan viendo y estan luchando por hacerse un sitio. Su .NET no esta nada mal, especialmente si algun corre en maquinas de verdad.

   

Bueno, que quede claro que no le quiero hacer publicidad a Ericsson ;-). Simplemente aprovecho mi experiencia allí para opinar sobre si Java se utiliza o no (que sí hombre, creedme...)

Habría que definir que se entiende por 'grande', por ejemplo un servidor de aplicaciones cualquiera lo puedes tomar como 'grande', según con que lo compares. Pero bueno, aceptemos que un servidor de aplicaciones en sí no es lo bastante 'grande'.
Lo realmente importante en Jambala es que aporta las librerías necesarias para temas tales como creación de servicios para la IN (Red Inteligente, ejecuta servicios que la red de conmutación no puede realizar) y gestión de estos servicios y sus usuarios, etc... lo cual te aseguro que no es moco de pavo. ¡¡Que nadie se piense que esto es gestionar la base de datos de un videoclub!! :-P.

El tamaño total del 'bicho', en megas, no te lo sé decir, ¡pero es mucho!. Pero más importante que el tamaño en bytes es que se va a utilizar a gran escala, es una plataforma sobre la que correran servicios con millones de usuarios potenciales (por cierto, muchos de los cuales seguramente tendrán un móvil con la J2ME ¿qué cosas, no? ;-P ).

¿Y por qué en Java y no en otro lenguaje? pues habría que preguntar a los suecos, pero creo que se basan en la idea de que siempre que haces algo así de grande, asumes el riesgo de que en cualquier momento aparezcan errores no detectados , pero al menos en Java ese riesgo es menor que por ejemplo en C (al menos es más fácil controlar que no haya punteros perdidos por ahí :-P). Ese mismo razonamiento se aplica a los servicios que desarrollarán más adelante sobre la plataforma: si están hechos en Java, serán menos propensos a que un programador meta la gamba que si se hacen en C . Es decir, aporta más fiabilidad. Aparte de eso, supongo que contó el hecho de disponer de cosas como log4j y jUnit para los desarrollos (los usamos), y que utilizando Java el esfuerzo y tiempo de creación de nuevos servicios se acorta (eso está demostrado), aparte de que hace más sencillo el soporte (tuve que mantener cosas hechas en C++ en Telefónica I+D, y créeme, era cómo una pesadilla ;-)... y ahora que me acuerdo, lo último que estaban haciendo cuándo me fuí de allí era una plataforma que permitiera desarrollar y ejecutar servicios creados en VoiceXML... y la estaban haciendo en Java :-P ).

¡Pero si nos ha visitado :-) Tarzán!. Que yo sepa no he dicho nada para que respondas así, ¿o es que trabajas en el proyecto en cuestión y te ha dolido el comentario?.

Java, por lo que yo se, es un lenguaje interpretado. Y es dificil que se lo maneje como si
fuera compilado porque no se penso asi. De modo que podemos esperar poco de una
optimizacion para hacerlo correr tan rapido como los lenguajes compilados. Respecto a las
optimizaciones para hacerlo correr mas rapido que los compilados.. bien, el dia que los
lenguajes interpretados inventen una de estas, los compiladores dejaran la suficiente parte
del lenguaje sin compilar para aprovecharse de ellas.

Tenemos que pensar que los lenguajes interpretados se benefician de muchas ventajas por ser
interpretados, pero que esas ventajas no son gratis, sino que cuestan ciclos de maquina. El
trabajo que un compilador hace una sola vez, lo tiene que hacer cada vez un lenguaje
interpretado pobre (he dicho pobre).

A dia de hoy el milagro no existe, y Java no tiene mas remedio que ser otro lenguaje
interpretado ademas con la sobrecarga de aguantar sobre sus hombros todo un framework. Creo
que todos sabemos que un mismo programa de escritorio escrito en C o en Java cambia mucho.
En java puede ser multiplataforma, pero sera horriblemente lento comparado con C.

Obviamente un escritorio no es el unico lugar donde corre un programa, sino que estan los
servidores, y estan protocolos algo viejos ya como el cgi. Puede ser verdad que un .jsp sea
mas rapido que un .cgi si lo que hace es el cgi no representa mucho trabajo. Desde siempre
estas cosas son verdad por la simple razon de que hay tareas que se hacen mas rapidos con
lenguajes de script, y muchas veces los .jsp eso es lo que hacen, el trabajo de un script.
Pero yo a los scripts no los llamo programas, si acaso aplicaciones... extirando mucho el
castellano.

En los grandes sistemas financieros, donde la eleccion de ISO9000 o Java es una decision
politica, seguido de muchas decisiones logicas. Pues ahi el mismo sistema escrito en C++ es
mas rapido, o habria sido mas rapido si alguien lo hubiera/hubiera podido montar. Hay que
reconocer que cuando se construyen grandes sistemas uno no puede estar tan cerca del
hardware como esta C, asi que un lenguaje de mas alto nivel como es Java, te permite hacerlo
y.. obviamente, siempre sera mas rapido algo que existe que algo que no :DD Peeeero, si
Visual Basic no fuera el lenguaje de Bill Gates, y lo hubieran diseñado de forma seria,
quizas Visual Basic seria competidor de Java. Esto lo quiero decir porque quiero hacer ver
que en estos sistemas no es la velocidad punta la que gana, sino la "seriedad" del lenguaje.

Java, cada vez que he ejecutado algo echo en el, siempre me ha resultado infinitamente mas
lento que su contrapartida C. Y esta es probablemente la impresion que mucha gente hemos
sacado de java. Es una pena, y probablemente Java nunca se podra quitar de encima ese
estigma. No se. Hay gente que cree que no se puede trabajar con cadenas en C, y hay gente
que cree que Java es lento. El mundo es muy injusto.

Hablaba de Editores/IDEs escritos en Java ;)

Lo que no se puede ejecutar es un método virtual puro, que es el que no tiene código, pero un método virtual tiene código. De hecho, prueba a no ponerle código y verás como falla la compilación.
Y el otro PH lo que estaba diciendo es que cuando invocas un método virtual no se puede intercambiar la llamada al método con su código porque un método virtual puede ser rescrito por una clase hija, y por tanto no hay forma de saber en tiempo de compilación si la invocación se va a realizar sobre la clase padre o la hija. Por ejemplo, es posible que el hecho de que un puntero del tipo de la clase padre apunte a una u otra clase hija dependa de una entrada de teclado del usuario, y en tiempo de compilación es imposible saber qué entrada hará el usuario, obviamente.

Cuando declaras un método como virtual en C++, se está indicando al compilador que se permite que una clase hija rescriba el método. En Java es al revés, si no se permite a los hijos rescribirlo se pone final, pero por defecto está permitido. Son dos sintaxis diferentes para representar el mismo concepto.
El compilador de C++ para resolver ese "problema", crea asociado a los atributos de esa clase una tabla de métodos virtuales que no son otra cosa que punteros a función. Por defecto apuntan al método de la clase en cuestión (o a un valor no-valido si es virtual puro, para detectarlo en tiempo de ejecución), y si se instancia una clase hija, esa clase hija sobreescribe ese puntero para que apunte a *su* implementación, si la tiene, o lo deja tal cual si no se reimplementa el método virtual.

El caso es que según las pruebas que he hecho, Java resulta más rápido cuando se trabaja mucho con métodos reimplementados por las clases hijas (quizás porque al ser todos virtuales por defecto, era importante optimizar ese aspecto). Y a pesar de todo, una implementación de polimorfismo en C resulta más rápida tanto que C++ como que Java.

Yo en el trabajo programo en C++, porque hago programación gráfica y no puedo permitirme que haya una máquina virtual ejecutando mis algoritmos de procesamiento de imagen en tiempo real, pero me gusta más el lenguaje Java, porque me parece más cómodo para programar, y desde luego las compilaciones son muchisimo más rápidas (a años luz de C++), fundamentalmente porque en general el hecho de cambiar una clase, no te obliga a recompilar todas las clases que la utilizan. Cosa que en C++ es inevitable en la mayoría de los casos, porque añadir un atributo a una clase hace que todas las referencias estáticas a métodos de otras clases se invaliden, porque ya no se encuentran en la misma dirección de memoria relativa a la dirección de la instancia. Y por tanto no quedan mas huevos que recompilar las otras clases también para que actualizen sus referencias. En Java prácticamente solo se recompilan otras clases si se se cambia el nombre de un método usado desde las otras, cosa menos habitual que añadir un atributo o un método nuevo.

Y finalmente no me gustan los gestores de memoria que se utilizan en las JVM que he probado, prefiero utilizar punteros inteligentes de C++ (en Java no se pueden implementar porque supondría llamar al recolector de basura cada vez que se deja de referenciar una instancia, y además serían mucho más incómodos por no tener plantillas), me gusta que la memoria se libere en el momento en que deja de ser referenciada, y no cada x segundos, aunque obviamente, el sistema de punteros inteligentes tiene el problema de no gestionar bien las referencias cíclicas, pero hasta ahora en todos los programas que he hecho conseguí salvar bastante bien ese problema.

El instalador de oracle es la basura más grande que me he encontrado en tiempo reciente en el entorno de programas comerciales. Y no lo digo como una provocación sino bastante objetivamente.

Y no solo el instalador. Todas las herramientas administrativas están en java.

Y son igual de basura (y las uso mucho), fallan mucho (no controlan bien las ventanas de tipo modal y se bloquean con facilidad) y son extremadamente lentas en comparación a las versiones anteriores no-java.

El java en general ni me va ni me viene, pero precisamente las herramientas de oracle son el ejemplo horroroso (solo han mejorado el aspecto gráfico pero al ser java se ha convertido en un error).

¿La parte servidor?

¿Oracle hecho en java? No lo verás en tu vida.

La parte cliente de un sistema cliente/servidor tal vez, a no ser que para tí una página web es parte de una aplicación cliente/servidor.

No conozco aplicaciones cliente/servidor en las que el servidor sea java.

Pero claro, si a alguien que habla cuando otro escucha lo llamas aplicacion cliente/servidor....

Java no es exactamente un lenguaje interpretado, es un lenguaje compilado como C, solo que corre en una maquina virtual. La maquina virtual, los JIT y compan~ia pueden hacer que el programa en java corra con instrucciones nativas, especialmente bucles y cosas por el estilo. Un programa en java lo compilas una vez y luego lanzas el ejecutable en la maquina (virtual) correspondiente. Y no digo que se pueda comparar con C compilado.

  Por que un programa en un lenguaje de script no es un programa? porque es interpretado? Incluso los bytes en codigo maquina son interpretados por la cpu y el micro-codigo correspondiente, apurando un poco, je, je.

    Por otro lado un compilador estatico no produce necesariamente codigo mas rapido que uno dinamico, aunque en la practica seguramente si. Pero no es una evidencia matematica. Podria darse el caso por ejemplo de una zona de codigo con una combinacion de bucles muy largos que estan unos dentro de otros, combinados, etc. Puede darse el caso de que el compilador estatico tenga que elegir entre optimizar de una manera favoreciendo un aspecto u otro, pero no sabe en realidad que bucle tendra mas peso en un porcentaje alto de las ejecuciones y decide optimizar de una forma determinada. En cambio un compilador dinamico puede ajustar esas optimizaciones en base a los resultados que le da a medida que la aplicacion se ejecuta una y otra vez, de manera que al final da con la combinacion optima.

    Aunque en las grandes aplicaciones corporativas, como en la que estoy trabajando en java, si un determinado proceso tarda 2050 milisegundos en vez de 2025 no importa en absoluto, porque seguramente 2000 de esos milisegundos se los pasa esperando que oracle o los back-end le devuelda un resultado.
Lo que si es una ventaja importante de java en estos casos es su manejabilidad, seguridad, escalabilidad, facilidad para mantener, velocidad de desarrollo... comparado con C++ por ejemplo. Estas cualidades en gran proyecto las puedes enunciar tambien como: dinero, dinero, dinero, dinero... ahorrado. Y pueden ser la diferencia entre el exito o el fracaso de un proyecto, el tiempo.

    Y la velocidad de ejecucion 'global' te aseguro que sera la misma. Estoy hablando de aplicaciones corriendo en servidores unix como dios manda que estan interconectadas con infinidad de otras maquinas, no hablo de una aplicacion tipo autocad, quake o un programa de escritorio.
Vamos, yo diria que java en estos entornos a barrido y los sres de microsoft lo estan viendo y estan luchando por hacerse un sitio. Su .NET no esta nada mal, especialmente si algun dia corre en maquinas de verdad.
 

Una gameboy la usa más gente y no es un gran sistema.
No confundamos.

Grande es un servidor de datos de teradata. O un programa GIS. O los servidores transaccionales de la red 4b.

Cualquier cosa que se use en un dispositivo portatil se usará por mucha gente. Eso no lo hace grande. Muchos millones de lavadoras usan programas que no ocupan 20 kb. ¿Son grandes por eso?
¿Es WAP algo grande? Un servidor WAP no tiene una gran aplicación. Tiene un gran hardware.

No tiene por qué darte razones. La pregunta es si es lento, no por qué es lento :-)

Como veo mucho comentarios en contra de la herencia múltiple, pues resulta que la herencia múltiple es MUY útil.

De hecho hay muchos problemas que son más fáciles de modelar con herencia múltiple que sin ella y por tanto más fáciles de resolver y entender.

Yo personalmente soy más que un sólo término (persona, programador, hijo, hermano,... etc etc).
Un pena que no encuentre en Dr. Dobb's un artículo que habla precisamente de esto.

Salu2,
Edu

¿y qué pasa cuando el "frameworks" tiene un BUG?, cosa por otro lado frecuente (nos ha pasado varias veces)...

Es un verdadero desastre (como el soporte de Sun)... por experiencia.

--edu

Por lo que se ve tienen bastante experiencia sobre el tema que hablan ¿Por qué no se registran y comentan con su propio nombre? Seguro que podrían aportar bastante a barrapunto.

¿ Os doy otra pista :) ?.
   
Con permiso del sensei Jim Abrash.
 

¿Suena?

"Adaptive Optimization in the JIKES (Jalapeño) JVM:
We anticipate that the bulk of the computation on a Java application will involve only a fraction of the Java source code. Jalapeño's optimizing compiler is intended to ensure that these bytecodes are compiled efficiently. The optimizing compiler is dynamic: it compiles methods while an application is running. In the future, the optimizing compiler will also be adaptive: it will be invoked automatically on computationally intensive methods. The goal of the optimizing compiler is to generate the best possible code for the selected methods on a given compile-time budget. In addition, its optimizations must deliver significant performance improvements while correctly preserving Java's semantics for exceptions, garbage collection, and threads. Reducing the cost of synchronization and other thread primitives is especially important for achieving scalable performance on SMP servers."

  Ya se que aun es mas bien experimental, pero no esta muy lejos en el horizonte, mas sabiendo que esta ibm metida de cabeza. Algunas de las cosas investigadas y probadas con esta maquina ya han pasado al compilador de ibm y su vm (una de las mas potentes) y a alguna otra.
Otra curiosa caracteristica:

"A distinguishing characteristic of the Jikes RVM is that it is implemented in the Java™ programming language and is self-hosted i.e., its Java code runs on itself without requiring a second virtual machine.
In contrast, almost all other virtual machines for the Java platform are either written in native code or written in the Java programming language with a reliance on a second underlying virtual machine to execute its Java code"

  Corre sobre si misma! ¿Como puede ser posible? Pues si, es logico.

PD: Como estan algunos! Mas quemaos quel palo un churrero!

Sois tan bobos que hasta os lo creeis. El catalan se habla en cataluña, y se acabo. Mas viejo que el castellano....sigh, os lavan el cerebro.

OpenGL no es mas rapido que directx ni en windows, payasote. Y si un dislexico mental hace las pruebas no es mi culpa.

"the real thing" -> "lo fetén"

:-)

EL USO DE JAVA PORCENTUALMENTE ES MARGINAL. CLARO QUE HAY PROYECTOS EN JAVA. PERO SU USO ES MARGINAL EN COMPARACION CON OTRAS TECNOLGIAS. EL QUE LO USEN UN 0.1% DE LOS PROYECTOS DE IA NO QUIERE DECIR QUE SE USE PARA IA, QUIERE DECIR QUE ALGUIEN LO ESTA USANDO. IDEM PARA EL RESTO. OPENOPFFICE USA JAVA PORQUE ESTA BASADO EN TECNOLOGIAS DE SUN. EN CUANTO A JUEGOS QUE EL 0.05% DE LOS MISMOS SE HAGA EN JAVA NO QUIERE DECIR NADA. SIEMPRE HABRA ALGUIEN QUE LO USE, LO QUE NO QUIERE DECIR QUE SEA ALGO GENERAL NI HABITUAL. Si no sabes ortografia no critiques haz el favor anda. Si no sabes la regla del "a con h" en castellano vuelve al colegio. Pero no es mi culpa.

Ahora te lo digo yo. CRETINO. TE LO REPITO EL USO DE JAVA EN COMPARACION CON C++ (POR EJEMPLO) ES MARGINAL, LO MIRES DONDE LO MIRES. COGE DEBIAN 3 Y COMPRUEBALO TU MISMO, JODER, QUE HAY QUE EXPLICARLO TODO. PAYASO.

Apache e ISS lo usan el 95% de servidores web. Hechos en C/C++. El media player, xmms, winamp son el 90% del mercado y estan en C/C++. El gui de edonkey no usa java, al menos la version que yo tengo, porque no tengo la runtime y me rula. Claro que hay algunas, cito MUY POCAS, cito PORCENTUALMENTE. En un mundo de 6000 millones de personas es facil que haya "MUCHAS" aplicaciones en lenguajes de uso minoritario. Cuando muchas son un pequeño puñado.

Bien, quiero aclarar algunas cosas. En primer lugar pedir disculpas a todos las personas que sin malas intenciones han participado en el thread, y se hayan podido ver ofendidas por mis comentarios. Aunque es evidente que hay algunos que han entrado en veda con la unica intencion de faltar e insultar, con comentarios que buscaban la provocacion. El tono de la discusion ha ido subiendo progresivamente y al final se ha vuelto insostenible.

Me cole con lo de las JSP, habia leido un articulo y me hice malas ideas acerca de lo que era. Reconozco el error.

Lo peor de todo es que la mayoria de las respuestas a mi comentario han venido fuera del nucleo principal del mismo. Ni se ha comentado una linea sobre el tema de los benchmarks y de las arquitecturas EPIC, cuando es lo que critico del articulo que da pie a la noticia.

Cuando hablo del poco uso de Java me refiero al poco uso en proporcion a otros lenguajes, nada mas, es decir, porcentualmente. Si alguien se pone a buscar encontrara aplicaciones hechas en el, naturalmente. Pero creo que es logico hablar en general si hablamos acerca de si abundan las aplicaciones hechas en tal o cual lenguaje.

Basicamente a lo que me referia con que el uso de Java es escaso, es a que si miramos al usuario medio de escritorio, desarrollador o entorno servidor Java no ocupa una porcion relevante para el, pongo como ejemplo el entorno de MacOSX, WinXP, Gnome, Kde, etc... En cuanto a lo del sistema grande creo que ha habido algunas confusiones, para mi, sistema grande no es un sistema del cual hay muchas copias funcionando, sino un entorno de dimensiones considerables, especialmente desde el punto de vista de codigo fuente. Y recalco que para mi, para considerar que una tecnologia se usa en un campo concreto no basta con que haya ejemplos, si el campo es grande los habra con casi cualquier tecnologia, sino que dicho lenguaje que debe ser una herramienta "habitual" en dichos campos.

Espero haber aclarado algunas cuestiones. Y recalco que en el articulo principal cite que "no digo que el lenguaje sea malo ni nada por el estilo".

Saludos.

Don't feed the trolls... demasiada tentación :)

Tu 'cortar y pegar equivocado' de otro mensaje demuestra que simplemente eres un troll que va de conversación en conversación provocando, y sin un indicio de respeto ni educación, que encima es tan tonto de publicar algunos mensajes como Cobarde anónimo y luego se equivoca y se deja sin marcar la casilla (pero bueno, eso lo puede ver cualquiera que lea tus mensajes).

Muchas de las características que nombro son tan 'viejas' como del 98 y el 99, parece mentira que no lo sepas con TODO lo que has demostrado que sabes a lo largo de esta conversación.

Con respecto al código y a mi habilidad o falta de ella con C++, sigo sin ver tu código con lo cual puedo suponer correctamente que no existe y que lo único que tienes es una boca muy grande (y un cerebro muy pequeño). Para que no dudes de mí, ahí va una URL donde puedes consultar código mío (para más comodidad, grep):
Pincha

Con respecto a tu código, sigo sin verlo.

Repito, compara porcentualmente. Y vuelvo a repetir, hablame de resultados, productos, programas. Java "esta de moda", es logico que lo pidan, por pedir que no quede.

¡Se trata de hablar si Java es lento o no!
   
    Pero ya que lo has mencionado, en Java se puede conseguir emular la herencia múltiple con múltiples interfaces. Es más trabajoso pero tiene la ventaja de dar menos problemas.

    Para el ejemplo que ha puesto colapso: en Java puede haber un objeto alberto que sea de tipo interfaz Programador. El interfaz Programador extenderá a (será hijo de) Persona, al igual que el interfaz Hijo y el interfaz Hermano. El interfaz Hijo, por ejemplo, estará definido por un método getPadre() que devuelva un objeto Persona.

    Una vez definidos varios interfaces puedes crear una clase ProgramadorConFamilia que implemente Programador, Hijo, Hermano y lo que quieras... y defines el método getPadre y los otros métodos de los otros interfaces.

    Creo que Java no tiene H. Múltiple ni falta que le hace... menos problemas que tiene así ¿no? ¿conoceis el problema del diagrama del diamante?

Es cierto que debería haber contado sólo las páginas que se refieren a Java como lenguaje (o como tecnología). Yo ya lo hice hace tiempo buscando "Java language" (así como "C language") y envié la comparación a Barrapunto: había muchas más páginas web donde aparecía "Java language"...

    Respecto a applets y servlets son palabras que no existen en inglés y que inventaron para referirse a cosas de Java, así que me extraña que se relacionen con otros lenguajes...

Lo que sí es cierto es que no es muy justo buscar en la web cosas relacionadas con la web como applets y servlets... porque es algo íntimamente relacionado con la web. Así como no es muy justo buscar en Debian código Java... y extrapolar como hizo alguien.

C#, aparte de ser sólo un lenguaje, no tiene de momento tanto presente y futuro como Java en el lado del servidor.
    Y será así mientras lo programado en C# no corra en Solaris, en máquinas gordas de IBM... y en resumen en todas las plataformas hardware que son más comunes en el lado del servidor. El proyecto Mono es un acercamiento pero todavía le falta mucho.

    En aplicaciones gráficas, para el lado del cliente (dominado por Wintel) si que será mucho mejor C# que Java.

1- Relee tu mensaje, simpaticote, y verás de lo que hablo cuando digo exceso de 'ha's
2- En debian apenas hay proyectos java, cierto. En parte se deba a que (aún) no hay ni máquina virtual ni compilador que sean a la vez libres y certificados por Sun. Este hecho ha provocado un rechazo tradicional de gran parte de la comunidad Open Source a Java, pero gracias a posturas y aportaciones constructivas (no destructivas y snobs como la tuya) como la de Jason Hunter (vice de la Apache Software Foundation) eso está a punto de cambiar. Tiempo al tiempo, sobre todo con el nuevo JSPA ya en marcha (¿no sabes lo que es eso?, entonces, ¿qué pintas aquí despotricando contra Java?).
3- Repito. el que sea marginal en tu PC no significa que sea marginal en el resto del mundo. Aunque me parece que a ti lo de 'el resto del mundo' es un concepto que no consigues entender. Sigue en tu cueva, no salgas, no incordies.