Barrapunto

Enumeraciones:

Me parece muy bien pero, ¿por qué no sacarlo desde el principio? Java cuando salió tuvo detalles que me hicieron desistir como lenguaje (lentitud, paso por valor y no por referencia, falta de enumeraciones y estructuras, etc). Con la excusa de "los buenos programadores no hacen eso" caparon a C++ en vez de mejorarlo.

Así que tras aprender java 1.0 a la siguiente versión lo abandoné porque no satisfacía mis necesidades, que es lo principal en un lenguaje de programación.

Pasaron los años y no he necesitado un lenguaje como Java, me he dedicado a la administración de sistemas y según la ocasión Perl, GTK o QT han sido mis lenguajes.

Ahora he vuelto a programar a lo grande y, reconozco que sin ver en qué estado se encuentra Java, miré C# y mono. Sencillamente me encantó. C# tiene lo que Java, lo que Java le faltaba cuando empecé a programar y además cosas nuevas como las Propiedades, que no sé como he podido vivir sin ellas.

Y el soporte de Mono es perfecto, incluso para ASP.NET. ¡Ah! Y por supuesto que puedes programar tus página ASP a mano. Nadie te obliga a usar un IDE, pero para eso están.

Sobre la documentación de .NET la tienes entera en la web de microsoft y en español. Además te la puedes descargar si quieres.

Conclusión: Esta es otra discusión estúpida, como las de KDE vs Gnome, o BSD vs Linux vs Windows. Cada uno que use lo que quiera. ¡¡¡Lo malo sería no poder elegir!!!

Todos sabemos lo "facil" que es usar servicios COM

Bueno... lo que de verdad mola es currar manteniendo las aplicaciones monstruosas construidas en COM en el periodo 1995/1999... Pagan un paston brutal porque casi no queda nadie que sepa lo que es un apartment. Me veo dentro de 10 anhos en la misma situacion en la que estan ahora los del COBOL en Endesa.

No soy el mismo que en el otro post pero sigamos con este juego de "lo mio es mejor por que lo digo yo aunque la mayoria de las comunidades de desarrolladores piensen de otra forma"

¿He dicho eso? Para empezar, ni de palo habré dicho "porque yo lo digo", estoy argumentando lo que diga, aceptando las críticas fundadas a los argumentos. Para seguir, no dudo que hace 5 años y durante varios años Java haya sido la mejor plataforma de desarrollo, y por tanto se haya creado la comunidad e inversiones de diferentes grandes empresas alrededor de Java. Lo que pongo en duda es que siga siendolo ahora de una manera tan descarada.

Para aplicaciones de usuario en Debian por ejemplo tienes que si Muine, Tomboy y demás (Mono), o juegos como slune (Python), mientras que de Java creo que ni una. Y en servidores no dudo que J2EE se coma muchísimo más que Python, como no dudo que la industria vaya migrando a .NET por ejemplo

Vamos, que te ahorres el tono de vaya de prepotente, que creo que sobra mucho.

enum Numeros { Uno, Dos, Tres, Cuatro, Cinco } [...] Numeros num = Numeros.Uno; System.out.println(num); No se si eso es suficiente.

Sí, es suficiente, y me mola :-)

Lo único es una pena que en la API de Java no se use mucho (veo que Transparency.OPAQUE sigue siendo un int), pero vamos, mola.

Sobre lo de los delegates, en java existen los listeners, que a mi modo de ver es mas elegante y respeta mas los mecanismos OO.

Ahí simplemente difiero: a mí me gusta más los delegates que los listeners, pero para gustos los colores, supongo.

No se si necesitaras que te ponga un ejemplo del Timer hecho con listeners.

No, tranquilo

Ademas eso de los delegados anonimos me parece el mismo mecanismo ( poco elegante y legible ) que las clases anonimas en java que implementan una interfaz.

Sí, salvo que ocupan el triple de código (tienes que declarar el new Interfaz{ public tipo metodo(parametros){ antes de escribir el código), y no accede a variables locales (salvo que sea final, que ya ves de qué te sirve un final int). Es como decir que puedes hacerlo con java.lang.Method: sí, puedes, pero compara.

BufferedReader br = new BufferedReader(new FileReader("mifichero.txt")); String a = br.readLine();

Complejisiiiimo eh ;)

Hombre, pues si añades los try/catch y los comparas con Pascal, C, C++, Python o C#... no es demasiado fácil / intuitivo.

O sea, si el 90% de usuarios el 90% de su tiempo va a hacer el BufferedReader de un FileReader... ¿por qué no tiene una clase que lo haga automáticamente? A eso es a lo que me refiero con que me parece engorrosa la API. Sobre papel, preciosa, pero a la hora de programar, raya

Por cierto leer de consola, tambien un infierno BufferedReader br = new BufferedReader(new InputStreamReader(System.in)); String a = br.readLine(); Dios casi se me cae el pelo de pensarlo.

Lo mismo de antes. Creas un BufferedReader de un InputStreamReader de System.in y luego llamas a un método del BufferedReader. Tanto cuesta poner algo como System.in.readLine() ? (o vamos, como en Pascal, C, C++, Python, C#...). Obviamente no es más de dos líneas (sin try/catch correspondientes), pero es que solo faltaba.

Pues seguramente te saltara un NullPointerException,

Meeec. Se me queda colgado, y escupe una excepción en otro hilo. Parecido a crear ImageIcons con imágenes que no se han cargado del todo o cosas así. Pero vamos, supongo que es un bug, reconozco que es un abuso por mi parte :-D

Ahora me diras que las excepciones estan muy bien implementadas en c# y entonces ya nos reimos juntos xD

Pues... la verdad es que... sí, nos reimos un rato juntos :-). Porque la rayada que mete Java obligándote a meter en try/catch todo (así es seguro, pero resulta que una RuntimeException te puede petar todo de la misma manera, y como sólo cojas las que Java te avisa y te salte un