C vs C++ (u oop vs estructurado)

[Vicente]

TAO son bindings para .NET de muchas librerias (OGL, SDL,...). Así puedes acceder a ellas desde .NET (antes tenías también CsGl, pero está muerto).

Las especificaciones de .NET 3.5 no están aún liberadas (están en proceso). Te busco el draft (son menos de 10 páginas creo). Recuerda que 3.5 son solo mejoras a nivel de sintaxis: métodos extensionales, LINQ, árboles de expresiones, expresiones lambda,...

Respecto a si Mono es un contrasentido para linux no me meto.

Un saludo!

Vicente

[lord_taran]

Que haya linuxeros que no puedan ver a Microsoft en nada de lo que hace no convierte Mono en un contrasentido. En mi opinión más contrasentido era Java, realmente, hasta que lo liberaron.
Lo que ya no sé es hasta que punto se puede programar en C# una aplicación y que sea directamente multiplataforma sin ningún tipo de cambios, y si es comparable a hacer una aplicación con Java. Y no es una acusación ni una opinión: es una pregunta.
Lo que si es importante en la comparación Java-.Net en cuestiones multiplataforma es que en el primer caso es la misma Sun la que saca la máquina virtual, mientras que para .Net hemos de esperar, por lo que siempre se va con retraso con respecto a Windows.

[Vicente]

Hola,

Fran:

Estos links he encontrado:

http://msdn2.microsoft.com/en-us/vcsharp/aa336745.aspx

Te puedes bajar el doc llamado "C# 3.0 Language Specification" que es la nueva especificación del lenguaje (al genio del marketing que se le ocurrió sacar el framework 3.0 con el cli 2.0 habría que fusilarlo...).

Respecto a estandares tenéis más información por aquí:

http://msdn2.microsoft.com/en-us/netframework/aa569283.aspx
http://www.ecma-international.org/publications/standards/Ecma-335.htm
http://isotc.iso.org/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm

Respecto a lo de estar el cli 3.0 en proceso de estandarización me colé, parece ser que aún no lo está (Wikipedia http://en.wikipedia.org/wiki/C_Sharp#C.23_3.0_new_language_features):

"C# 3.0 was unveiled at the 2005 Professional Developers Conference. A preview with specifications is available from the Visual C# site at Microsoft. It is not currently standardized by any standards organisation, though it is expected that it will eventually become an ECMA and then ISO standard, as did its predecessors."

Respecto al tema de las licencias (de la wikipedia http://en.wikipedia.org/wiki/.NET_Framework#Criticism):

"The Microsoft .NET Framework is the predominant implementation of .NET technologies. Other implementations for parts of the framework exist. Since the runtime engine is described by a ECMA/ISO specification, other implementations of it are unencumbered by copyright issues. It is more difficult to develop alternatives to the base class library (BCL), which is not described by an open standard, and may be subject to copyright restrictions. Additionally, parts of the BCL have Windows-specific functionality and behavior, so implementation on non-Windows platforms can be problematic."

El acuerdo de Novell y Microsoft se refiere a la BCL (ya que ellos están portando la BCL a Mono).

lord_taran: respecto a multiplataforma sin cambios: una aplicación de Mono en Linux correrá igual en Mono en Windows (o debería), pero de una aplicación Mono Linux a una aplicación .NET Windows lo mismo te sale alguna cosa (que no debería). De .NET Windows a Mono Linux según que uses te dará problemas (por funcionalidad que no esté aún implementada). Si tienes mucho interés me informo (porque yo lo he usado de pasada, con chorradas).

Por cierto que se me había olvidado otra opción, la "Shared Source Common Language Infrastructure", la implementación libre no comercial de la propia Microsoft del CLI para Windows, FreeBSD, y MacOS (http://en.wikipedia.org/wiki/Shared_Source_Common_Language_Infrastructure).

Un saludo!

Vicente

[Lex]

...

[lord_taran]

Pues si, si puedes infórmate, aunque tampoco corre prisa :P Vamos, si puedes darme una visión general... Me parece que Windows.Forms es lo que aun necesita mucho desarrollo ¿no? De todas formas ya miraré un poco más a fondo cuando tenga tiempo.
De todas formas vuelvo a decir lo mismo que antes: el problema real de .Net con respecto a java, hablando de ser multiplataforma, es que para cuando Microsoft saque el .Net 3.0 con suerte estará casi todo el 2.0 implementado en Mono, mientras que al ser Sun la que implementa todas las versiones de la máquina virtual de java pues no existe ese retraso (que yo sepa)

[MrK]

Pues eso, buscate un argumento mejor ;) Un saludo!

mi ordenador se muere cuando ejecuto algo en .net XDDD

bromas a parte, no confio en microsoft ni en nadie que haga lo mismo
(tal y como tampoco confiaba mucho en sun para java antes que sacaran el codigo)
para cualquier cosa que le digan multiplataforma y no den el codigo, ofrezcan un
programa con el que te "ayuden" a portar dicho interprete a cualquier maquina,
y te aseguren cierta continuidad. Por que? Pues porque puedes estar haciendoles
programas con su .NET, y un dia pueden decidir que cierran el grifo al resto
de plataformas, y entonces TU les has ayudado a expandir su lenguaje, y posteriormente
a crear una dependencia entre tus usuarios y su sistema operativo (de que me
sirve que yo haga un gestor de correo en .NET que se puede ejecutar en Mac OS,
si despues al pasar a la version 3.0 los de Mac OS no pueden usarlos, y ya tienen
una razon mas para pasarse a windows. No en mi nombre.)

Con Sun puede pasar, pero veo mas posible que microsoft use como caballo de troya
el .NET para 'absorbir' usuarios de otros sistemas operativos hacia el suyo. De todas
formas nunca he sido un amante de estos lenguajes autodenominados multiplataforma.

Excepto para cosas embedded (navegadores y cosas de estas), veo mucho mas
practico usar C/C++ estandar y portable, y usar alguna libreria estilo GTK
que tiene implementaciones libres para la mayoria de sistemas conocidos.
Si te has estado 2 anyos para hacer una aplicacion, la excusa de que "no hace
falta compilarlo 4 veces" me parece muy pobre. Es como la gente que hace un
juego chapeau y despues ponen los menus con Comic Sans MS.

Todo esto lo digo acerca del "codigo multiplataforma", si uno ya directamente
quiere hacerlo solo para windows, eso es otra cosa.

[Vicente]

lord_taran: te lo miro y te contesto por privado.

MrK: que más da que MS no libere el CLI 3.0? El que desarrolle en Mono se ceñirá normalmente a Mono y su máquina virtual, y no a la de Microsoft (y aunque no lo hiciera, lo podría hacer si las cosas se ponen malas). Si tu haces una aplicación ahora en Mono, que más te da lo que haga MS? Tu programa seguirá funcionando y a correr.

Si te miras la especificación de Mono, igual que en ciertas cosas va por detrás de la de .NET (principalmente WinForms aunque creo que ya están bastante al día), en otras cosas han currado más que MS. Ejemplo: el draft del CLI 2.0 incluía tipos de retorno covariantes, cosa que Mono implementó pero que MS al final decidió no hacer. O en el tema de certificados, donde la librería de Mono provee más funcionalidad.

Lo liberado y estandarizado, liberado y estandarizado está. Si en el futuro MS corta el grifo, nada impedirá a Mono crecer como algo independiente en vez de portar las librerías de MS (como por ejemplo han hecho con TAO, GTK#,...).  Otra cosa es argumentar si Novell tendría fuerza para hacer despegar Mono como hizo Sun con Java como plataforma individual.

Nos podemos poner a especular, pero para mi que el liberar la especificación fue simplemente para que llegara a más sitios (es algo que sabían que la gente pedía a SUN y hacerlo les daba puntos). Es igual que sacar VB.NET para no perder a la gente de VB6 (o más en general el tema de multilenguaje para que la gente trabaje sobre su plataforma). Pero vamos, esto último es opinión totalmente personal ;)

Un saludo!

Vicente

[Lex]

...

[AK47]

Yo por lo poco que he salseado con Visual C# Express, puedo decir que me alegraria sobremanera que fuese multiplataforma. Es una herramienta cojonuda :)

[MrK]

Vicente deja de perder el puto tiempo, y haz el editor, que al menos eso lleva a alguna parte.

nah, es mucho mas divertido evangelizar al personal, o hacer ver a la gente lo tonta que es por empezar a programar juegos con una cosa que no sea un pacman :)

Por cierto, lo estamos haciendo en C# así que tened cuidado, que podríamos estar conspirando contra todos vosotros.

por cierto, el juego sera multiplataforma? :)

[Mars Attacks]

Es un poco offtopic, pero ¿qué cachos de programa exactamente puede hacer un humano de forma más óptima en ensamblador que un compilador?

No sé, yo también pienso que los compiladores de hoy en día son la releche, y además alguien que sepa cómo ensamblar "guay" también tendrá nociones de cómo programar para que el compilador no ensamble mal, ¿no?

[MrK]

Es un poco offtopic, pero ¿qué cachos de programa exactamente puede hacer un humano de forma más óptima en ensamblador que un compilador?

No sé, yo también pienso que los compiladores de hoy en día son la releche, y además alguien que sepa cómo ensamblar "guay" también tendrá nociones de cómo programar para que el compilador no ensamble mal, ¿no?

Por mi experiencia personal los ultimos tiempos (ensamblador ARMs, no se como estara el tema en x86,mips o powerpc), el compilador la caga a la hora de asignar los registros para diferentes tareas y de reordenar la memoria para poder trabajar mejor. Dificilmente encontraras un compilador que te cargue/descargue un bloque de memoria con un stmfd o ldmia (unas instrucciones para guardar/cargar registros a memoria y viceversa, una especie de ?pushad? selectivo) ni que tengas 4 instrucciones consecutivas que le digan que carguen los registros con esas mismas posiciones consecutivas.

La gran ventaja que tienes haciendo ensamblador, es que sabes lo que quieres hacer, y puedes reordenar los datos de tal forma que despues los puedas cargar mas rapidamente, o decidir cuales quieres retener cuando te faltan registros y cuales guardas en memoria. Un compilador hace muy buen trabajo, pero no deja de ser un "programa tonto" que hace su faena .

Por poner un ejemplo, una vez tuve que escribir un texture mapper para ARM y la funcion en C optimizada me tardaba un 60% aproximadamente mas que la misma funcion en ASM, una vez todo traducido y reordenando los datos para que fuera mas rapido. Despues intente aplicar esas optimizaciones al C y no hubo forma.

Un 60% mas en una rutina que se ejecuta 3 veces por frame y gasta un 0.01% de cpu es una chorrada hacerla en asm, pero una rutina que se tira el 90% del tiempo ahi,es la diferencia entre ir a 15 fps e ir a 25 fps.

[Mars Attacks]

Gracias para la aclaración. Mi cerebro lo ha traducido como "magia oscura de programadores de verdad, que no puedes alcanzar a comprender". Yo aún sigo siendo más tonto que los compiladores XD