#3013 Por qué dices que Java como lenguaje es apestoso? No por nada, me interesa tu opinión simplemente xD.
PD: Si, acabo de ver ese mensaje ahora xD
#3061 Clase nombreVariable = new Clase();
Creo que sólo se puede ser más rendundante si te hiciera repetir también el nombre de la variable, por si acaso te has equivocado! 
#3062 Hombre si el constructor va a ser el de por defecto pues igual suena redundante. Pero creo que es así en todos los lenguajes que me vienen a la mente (de los compilados me refiero, de web no hablo). La única diferencia igual es C++, pero porque ahí puedes elegir en que zona de la memoria se almacenará el objeto.
#3063 no, mi propuesta es al revés:
var nombre = new Clase()O quizá:
nombre = new Clase()El ejemplo que puse es incluso suave. Si usas genéricos es aún más odioso:
ArrayList<Clase> nombre = new ArrayList<Clase> ();Y, ¡ojo! No estoy en contra del tipado en tiempo de compilación, pero donde haya una buena inferencia de tipos...
Me sobran también los ; y las {}. Me falta que los métodos sean de primera clase, funciones anónimas, una buena gestión de las closures y el nesting...
Tener que escribir los accesores a mano y no tener algo como "propiedades"... o incluso mejor, la solución de Scala, que un método y un atributo son lo mismo y son intercambiables según necesites (así si cambia la implementación sólo tienes que implementar tu atributo como un método con su lógica extra.)
No hay literales para las listas. No puedo hacer:
cosa.hacer([1, 2, 3, 4]);Sino que tengo que hacer:
int[] array = {1, 2, 3, 4};
cosa.hacer(array);Los imports no permiten "aliasear" clases (en Python tienes "from somewhere import something as something_else".)
No poder sustituir operadores lleva a código como:
BigInteger result = x.add(y.multiply(BigInteger.valueOf(7))).pow(3).abs().setBit(27);Volviendo al tema de las closures... una clase anidada sólo puede cerrarse sobre... ¡atributos final! ¡A TOMAR POR CULO!
Si nos salimos del lenguaje y nos vamos a la implementación.. lo que más me ha tocado los cojones es que cuando Java es compilado la información de los genéricos se pierde en las signaturas (¿firmas?) de los métodos por lo que la reflexión es simplemente un dolor de culo. Tampoco puedes saber qué tipo contiene un ArrayList (y esta es la razón por la que tienes que hacer un cast tras cualquier get en lugar de poder coger el objeto en su tipo original y castear SÓLO si es necesario...) Ejemplo de por qué me duele:
import java.util.ArrayList;
class Clase {
public void func(ArrayList<Long> listaLong) { }
public void func(ArrayList<String> listaString) { }
}¡ESTO NO PUEDE COMPILAR!
int no es lo mismo que Integer. char no es lo mismo que Character. etc. etc. Y muchas veces provoca dolores de cabeza donde no debería.
NO puedes saltarte el GC por encima. Si tengo un objeto y lo quiero liberar, mi mejor baza es ponerlo a null y rezar por que el GC salte pronto.
No puedo hacer que una interfaz tenga métodos estáticos (dolor, os lo aseguro) ni miembros, ni semi-inicializar mierda (tiene que estar 100% vacío, no puedo declarar un valor por defecto.) La solución es usar herencia, pero sin herencia múltiple te vuelve a atar de pies y manos...
Se preocupan por la velocidad (unboxed primitives) pero no me permiten forzar un método a inline.
El sistema de concurrencia es un dolor de ojete y te hace pensar demasiado.
Las @anotaciones son una solución muy cutre a un problema grave.
Y como mayor dolor de culo: EL CLASSPATH, la gestión de bibliotecas y dependencias (y Maven/Ant no te creas que lo simplifica mucho.)
#3065 yo SÍ te recomiendo Java, sobre todo si ya lo conoces.
Y si no, JavaScript.
Y si no, si te la suda que sea multiplataforma, C#.
Aléjate de todo lo que sea bajo nivel. Para juegos quieres resultados, no comerte la cabeza gestionando la memoria y preocupándote de leaks. No creo que ninguno vayamos a hacer el nuevo Quake 
Pero eso asume que una variable debe tener el tipo de objeto que instancia, y no siempre es así.
Por ejemplo, si usas polimorfismo, te puede interesar tener una variable de una clase que instancie un objeto de una de sus subclases.
#3066 entonces propones hacer var nombre = new int() o nombre = new int() ??
Yo prefiero hacer int i;
Y C# es multiplataforma.
#3068 En realidad no lo es, tienes mono, pero tienes muchísimas cosas que no puedes hacer en él.
Por cierto, c# ya permite usar var variable = new Clase();
#3067 ni yo ni Scala vemos el problema 
var variable: SubClase = new Clase()Si poder declarar tipos está bien, pero... ¿obligarte a ser explícito siempre? ¿Por qué?
#3068 C# es tan multiplataforma como mis cojones.
Ojo, he ampliado (y sigo ampliando) el rant xD
EDIT: rant finalizado (y remozado desde el principio.) Esperando a que BLZKZ me lleve la contraria en 3, 2, 1... xDDDD Habrá cosas que sea cuestión de gustos (;{}, tipado, etc.), pero el tema de las funciones de primera clase, closures, signaturas, etc. y sobre todo la gestión de dependencias es IM-PE-PI-NA-BLE.
En Node tenemos NPM. En Clojure, Leiningen. En Ruby, RubyGems. En Python easy_setup/setuptools/pip (este es para echarle de comer aparte.)
En Java, ¿Maven? ¿Ant? Deja que me ría xD
#3066 Obviamente no voy a hacer nada del otro mundo, por lo menos al empezar xD
Pero darme me da igual el lenguaje, por que de java he visto algo orientado a servlets y me manejo con el tema clases y tal, por eso lo digo, ya en la intro del hilo he visto que puedes programar de mil formas diferentes,en mil plataformas... y pues no tenia ni zorra de si había algo mas centrado en programar a videojuegos o no (royo UdK).
#3070 casi todo sobre lo que estas rajando lo soporta C# desde hace la tira (lambdas, var, inport/using, forzado de GC). Y si ya te pones a investigar sobre Linq, te vas a correr.
Y C# SI es multiplataforma hostiaputaya, que los que decis que a Mono le faltan features por todos lados se nota que no lo usais desde 2005.
#3073 C# NO es multiplataforma. Te pego la conversación con BLZKZ en el IRC:
[09:22] <@blzkz> kaoD: puta
[09:22] <@blzkz> que no puedes hacer con mono a ver
[09:22] <@blzkz> xD
[09:22] <@kaoD> blzkz: yo qué sé
[09:22] <@kaoD> pero si tengo que depender del soporte de una biblioteca de software libre
[09:22] <@kaoD> que la propia Microsoft no aprueba...
[09:23] <@kaoD> apaga y vámonos
[09:23] <@blzkz> llevo años dependiendo de tios en pijama como dice tamy
[09:23] <@blzkz> yavestu que problema
[09:23] <@blzkz> xD
[09:27] <@kaoD> blzkz: coño
[09:28] <@kaoD> pero es que no dependes de tíos en pijama
[09:28] <@kaoD> si esos tíos en pijama dejan Mono tú tienes el código
[09:28] <@kaoD> y puedes seguir
[09:28] <@kaoD> eso me suda los huevos
[09:28] <@blzkz> entonces el problema es que a microsoft no le gusta?
[09:28] <@kaoD> me dan más miedo los TíosConCorbata™ de Redmond
[09:28] <@blzkz> yavestu
[09:28] <@blzkz> xD
[09:28] <@kaoD> cuando se cansen y digan
[09:28] <@kaoD> "a la mierda Mono, todo Dios que use C# a Windows y punto"
[09:29] <@kaoD> te vas a reír cuando pase eso
[09:29] <@blzkz> no les interesa
[09:29] <@kaoD> PD: XNA NO FUNCIONA EN LINUCS
[09:29] <@kaoD> no les interesa hasta que les interesa
Un hack NO ES SOPORTE MULTIPLATAFORMA. Es como decir que la Nintendo DS está soportada en Windows porque hay emuladores, o que Windows está soportado en Linux porque hay WINE... NOPE.
Microsoft ya ha dejado en la estacada VARIAS VECES a los desarrolladores (véase el abandono de XNA por DX+CPP en W8.) ¿Por qué me iba a fiar? ¿Por qué iba a dar mi tiempo y esfuerzo a una empresa que NO me da garantías?
Si Microsoft me deja en la estacada, me deja en la estacada y punto. Soy utilitarista. Hay mil alternativas con mejores garantias que dotNET.
#3075 Tampoco te pases, no todos tenemos la necesidad de trabajar en Linux, hay mercados dominados 100% por Windows y no merece la pena desarrollar en Linux, amos, te lo digo yo.
#3076 si yo no digo que no. En #3066 recomiendo C#, pero decir que es multiplataforma es faltarle a la verdad.
Por no decir que lo de Linux es el menor de sus problemas. Yo hablo de que Microsoft te deja en la estacada y punto. Hoy deprecan XNA en favor de DX+CPP y te obligan a pasarte a Win8 para usar VS2012. Mañana dejan de soportar C# porque les sale de los cojones.
Toda la gente que desarrolló con C#XNA por la portabilidad entre Windowses y XBOX360... ¿ahora qué hace? Porque su código ya no vale nada en Windows8. El esfuerzo de portar no corre a cargo de Microsoft
#3077 En realidad VS2012 funciona en Windows 7 tb, aunque más abajo no.
De todas formas, eso que dices ha pasado con Microsoft siempre. Dejaron de dar cobertura a Windows Mobile en VS2010 y quien tenía software desarrollado en ello (casi todas las PDAs) tuvieron que quedarse en VS2008.
#3078 eso que dices ha pasado con Microsoft siempre
Más razón para mí xD
Insisto en que yo todo esto lo veo de una forma utilitarista. No es una cruzada contra Microsoft. Simplemente creo que fiarse de la buena voluntad de una empresa es ser algo ingenuo... y más cuando "siempre han sido así".
#3080 cuánta razón con lo del IDE. El gran paso atrás de Linux para el desarrollador (aunque supongo que es por el dominio de consola + emacs/vi, que se "sobreponen" a un IDE tradicional.)
#3081 pero usa el símil del IRC hombre:
[12:43] <@blzkz> por cierto soltrac soltando que C# no es multiplataforma porque WPF no va con mono
[12:43] <@blzkz> y mi polla no es multiplataforma porque no se la meto a tios
[12:43] <@blzkz> no te jode
#3079 No no, si yo no digo que te equivoques. Es más, yo soy el primero que reconoce lo de que no es multiplataforma y que dejan tecnologías atrás, pero yo trabajo en .NET porque desarrollo para windows y me va bien porque así uso el mejor IDE que ha existido nunca, que es el Visual Studio, con el que se ahorra un tiempo increible (sin contar los cuelgues raros que tiene, que los tiene).
#3074 WPF no es C#, C# en sí es multiplataforma, por mucho que no lo apoye ms en otras plataformas.
Que un dia dado MS se lo quiera cargar pues bueno, pero eso de momento no es lo que hay.
Edit: gasta cojones que hablemos de librerias y tecnologías que pululan cerca de c# en windows para justificar que le faltan funcionalidades a mono.
Pues mi teléfono no soporta windows!
#3081 Ah disculpe, no sabía que solo podíamos contar las DLLs que nos salieran del nabo para contar que algo es multiplataforma o no.
Si porto System.Net es multiplataforma, pero si no porto System.Windows no importa.
Ok ok.
PD: Tu comparación de teléfonos es ridícula, si pretendes ridiculizarme utiliza otro truco por favor.
A ver si te vale esta, MONO no tiene completos los frameworks desde el 3.5 hacia delante, te vale? Ah no, que eso tampoco es C#, c# es multiplataforma.
.NET Remoting no está implementado en MONO, te vale está también? (Edito, del todo, que me acabo de mirar la documentación y tienen algunas cosas implementadas)
Discúteme lo que te salga del nabo, pero llevo trabajando en .NET 8 años. Te puedo sacar mil ejemplos de cosas que no puedo hacer en mono, te guste o no.
#3082 tu escribes un programa con c# y puedes generar un binario en linux? 
Entonces c++ tampoco es multiplataforma, porque no puedo usar WPF en linux.
PD: ¿El ejemplo de las pollas que ha puesto kaod te parece más adecuado?
"llevo XX haciendo YY por eso tengo razón." Bonitas falacias.
#3083 Desde cuando puedes usar WPF en C++? Tú sabes lo que es WPF? Es que creo que tienes un lío de conceptos que no te aclaras.
Y te lo estoy intentnado explicar, puedes generar programas en C# que NO funcionan en linux, si quieres te escribo uno y lo intentas ejecutar en linux.
Es que eres la polla en serio, te estoy diciendo que faltan funciones de la API a partir de 3.5, te estoy diciendo que .NET Remoting no está implementado completamente y sigues con la misma tontería.
No te lo voy a explicar otra vez porque o una de 2, o te estoy hablando de conceptos de los que no has oído hablar y prefieres seguir ladrando o simplemente me ignoras.
Mi falacia es que mi programa que está escrito en C# no funciona en linux. Quizás con eso te sea suficiente.
Por cierto, sacado de google:
At this point, no group in the Mono project has plans to implement Windows Presentation Foundation APIs as part of the project.
We do not have any plans because the project is too large and there has not been any serious interest from the community to make this effort move forward.
Some bits have been implemented for WindowsBase and they are distributed with Mono (mostly because System.IO.Packaging is part of WindowsBase). Various classes and stubs were developed and live in the Olive module.
Entiendes a partir de aquí que tu relación de C++ y WPF es como intentar cruzar un perro y un gato? O también quieres que te lo explique. Te lo digo porque los de Mono sacaron Moonlight como implementación de Silverlight, que tampoco es C#, pero lo que no te queda claro es q mono no es un port de C# para hacerlo multiplataforma, es un port de las tecnologías .NET
#3084 que no que? primera respuesta de google http://stackoverflow.com/questions/6427578/wpf-with-c-its-possible
Poco has usado .net, porque yo sí lo usé con c++
Hola a todos! recién llegado al foro! Visto que este hilo trata sobre precisamente mis intereses esenciales y el asunto que me ocupa este año, invito a todos a pasarse por el hilo que he creado buscando colaboradores para el proyecto de final de grado en el que estoy trabajando. Es un proyecto simple pero detallado que creo que puede ser una grata experiencia para todos los que se animen a participar.
Y soy tan majo que hasta pongo el enlace y todo: http://www.mediavida.com/foro/9/iniciativa-noche-mas-larga-noviembre-464770
#3085 Using WPF in your C++ app can be achieved using hwndSource, but its not the optimal solution, for that you will have to create C# or VB.NET GUI app, and use it to communicate with your C++ app via some form of IPC.
Dios mío, .NET con C++, estás hablando de llamar a funciones a través de IPC. Yo también he usado entonces Java con C++....y C...y ¿todos los lenguajes? XDD. La GUI la estás creando en .NET, dkasjdklasadjk dios, es que parece que me has buscado el primer link de google q has visto cuando parece que estoy hablando con un tío q no sabe de nada.
Paso de seguir hablando de tonterías, estás empezando a enredar y me conozco esta situación, te estoy explicando todo el tiempo q no es posible compilar cualquier programa de .NET en Linux me saltas por la tangente.
Pues venga, lo que querías, tú ganas. .NET es 100% multiplataforma, lo dices tú y los demás te creemos.
#3088 es que en practicamente cualquier lenguaje de programación cualquier codigo según la plataforma puede no compilar.
Estas diciendo una salvajada, tengo cosas hechas con c++ en linux que no compilan en windows ni a tiros (y de c) y es obvio, con que tenga una llamada a sistema ya no va a compilar xD
#3089 con una llamada al sistema no compila? Don't think so.
Crash o no hará nada, pero compilar compila.
