Estamos hablando de Black, que por Colin Vearncombe le conocían en su casa a la hora de comer. Ya sabía lo de su accidente hace unos días y la verdad es que no pintaba nada bien.
#141 Sí, es de Google, pero cualquier lenguaje compilado es más rápido que uno interpretado por la necesidad del paso intermedio de "interpretación". El código binario va directamente a la CPU, mientras que el bytecode hay que adaptarlo a la arquitectura.
Anda que no he dropeado yo en Windows programas en Java por su comportamiento errático y/o lento. Por nombrar algunos ejemplos: Azureus (Vuze) -> uTorrent, JDownloader -> Mipony, NetBeans -> Eclipse...
#130 Si quieres que nos pongamos tiquismiquis, como decías antes, nos ponemos. Aunque creo que no deberías tomarte tan a pecho las cosas que te comento, ya que tanto si son punteros como si son patatas asadas a ti y a mi nos van a dar lo mismo.
Lo que maneja el programador en Java mucha gente lo llama referencias, precisamente por el hecho de que te prohibe las operaciones aritméticas manuales. Sin embargo, tampoco son referencias propiamente dichas: pueden contener valores nulos y pueden cambiar de valor, entre otras cosas. Además, el número de "referencias" a un mismo objeto en Java es lo que usa el recolector de basura para eliminar la memoria. Esto es en realidad un concepto que existe en C++ antes de la aparición de Java: el concepto de Smart Pointer. La única diferencia con un Smart Pointer real es que Java no te deja acceder a su valor contenido, para que no manosees y cometas errores.
La política de Java, igual que la de Apple, está muy bien descrita en este trozo de documentación que pones aquí: los programadores meten la pata cuando se les da acceso a detalles de más bajo nivel. ¿Solución? Quitarles responsabilidad para que no metan la pata. Más seguridad, menos potencia. La ausencia de potencia disponible de por los programadores se soluciona con el aumento de potencia de los equipos informáticos. Simple, y sencillo.
Como te decía antes, no pretendía molestarte. Veo que da igual, que te molesta mucho lo que digo. Te pido disculpas por las molestias y, para que veas que no pretendo molestar te doy la razón: no tienen todas las funcionalidades de un puntero, por tanto, aunque apunten a memoria, no son punteros. Llamémoslos referencias, como hacen los demás, y asunto zanjado.
#105 El rendimiento (y los derechos que quería tener Oracle) fueron los motivos de que Android se pasara a compilar y dejara las máquinas virtuales de Java. Es también otro motivo de que en general los móviles Android parezcan menos fluidos que los iPhone pese a tener mucha más potencia (en gama alta). Adjunto gráfica.
Edit: Un palillo de pie (en vertical) es muy inestable, como puede demostrarse con un sencillo experimento mental.
#122 No era mi intención molestarte, y te agradecería que no me ataques ad-hominem, pues yo no lo he hecho. Da igual quién sea yo, o como de tiquismiquis sea: que el lenguaje te haga pensar que una variable es un objeto, cuando en realidad es un puntero, no significa que no lo sea.
Apple sigue la línea de muchos otros al hacer lenguajes cada vez más gestionados: quitarle trabajo al programador para que produzcan más, y quitarle también responsabilidades para que se equivoquen menos. Eso no significa que un puntero siga siendo lo que es.
De todas formas, tampoco tiene sentido seguir discutiendo. Programa como más te guste y con lo que más te guste y entiéndelo como prefieras, que para gustos, colores.
Esto es un error clásico de concepto. En realidad no es así: en Java todo son punteros. Los "beneficios" de Java en realidad están en el hecho de que muchas cosas están implementadas a más alto nivel y el programador no tiene que controlarlas. De hecho, eso es lo que produce que la mayoría de gente piense que java no tiene punteros.
Desde mi punto de vista siempre digo lo mismo: usar lenguajes de alto nivel es genial, y ahorra muchísimo. Sin embargo, es necesario primero dominar los conceptos de bajo nivel, si se quiere llegar a ser un buen programador. De lo contrario, muchas cosas se construyen como castillos en el aire.
Por otra parte, que nadie piense que los lenguajes de más bajo nivel como ensamblador o C van a desaparecer o están en desuso. Siempre es necesario que alguien implemente las capas de bajo nivel del hardware para que otros puedan programarlas a alto nivel desde cualquier lenguaje moderno. Y hay muchas más capas de bajo nivel de las que uno se imagina hasta que trabaja con ellas. Por algo C y ensamblador siguen siendo lenguajes muy usados.
#51 En eso te doy toda la razón. Para programar en C hay que ser muy metódico o tienes leaks por todas partes.
No obstante, yo diría que lo peor de Java es precisamente su ineficiente máquina virtual. La gran mayoría de los programas hechos en Java tienen la estabilidad de un palillo de pie porque los programadores confían pletamente en su JVM.
Lástima de 10 segundos perdidos.