Essential C# 2.0 y The C# Programming Language

El primero es de Mark Michaelis, y el Segundo de Anders Hejlsberg, Scott Wiltamuth y Peter Golde, y en conjunto suman unas mil cuatrocientas páginas; estas han sido mis dos últimas lecturas profesionales. Y la verdad es que ambos libros valen el dinero que cuestan (más los portes desde Estados Unidos).

Nadie que quiera aprender C# debería obviar estas dos obras, pero si realmente tiene que elegir entre una de las dos, mi recomendación es que se quede con la de Michaelis.

Mientras que la segunda es muy árida y cubre el lenguaje desde un punto de vista estricto y meramente descriptivo, la primera vive el C#. Y encima trae páginas completamente imprescindibles, esos Advanced Topics no tienen precio para entender de verdad el lenguaje.

A esta pareja les falta CLR via C#, que lo tengo en las listas de Amazon esperando la siguiente compra, que no creo que tarde mucho a hacer, ya que vuelven a tener stock de otros que pensaba comprar…

Quizás el mayor problema de esos libros sea el idioma, inglés, aunque es bastante sencillo y claro de entender, aunque el de Hejlsberg sea un poco más difícil, cualquier programador acostumbrado a leer la documentación del Visual Studio no debería tener problemas en entenderlos (hasta yo lo he hecho).

En ninguna de las dos vas a encontrar mucho .NET Framework, ya que son libros sobre C# (que en teoría es un lenguaje sin relación con ninguna implementación concreta de .NET). Hejlsberg apenas hace mención de clases o elementos .NET, Michaelis no se corta en especificar alguna que otra cosa, justo lo imprescindible para hacer esta obra más entendible y más lógica que la otra, y es por eso que la recomiendo puesto que C# sin .NET (o mono, o dotgnu) no es nada.

Aprendí C# y .NET hace unos años con el libro C# Professional 2.0 de la casa Wrox, y me quedaba el prurito de aprehenderlo de verdad, por lo que pregunté a Octavio Hernández (gracias, master) que me recomendara el mejor libro sobre C# sin .NET que hubiera en el mercado, y él respondió con los dos que nos ocupa.

Porque aprender .NET es una chorrada: tan sólo hay que ir a la documentación y mirar qué clases hay y cuáles son sus métodos, de la misma forma que cuando uno necesita hacer algo en Win32 se acerca a su API y la consulta. Otro tema es que encuentres lo que buscas, o que esté pero no seas capaz de encontrarlo, que me imagino nos pasa a todos con mayor o menor frecuencia.

Pero un programador debe conocer el lenguaje que usa con profundidad, por eso quería verlo desnudo, sin el arropamiento de su biblioteca de clases. Y siendo sincero, no me ha gustado. No estoy diciendo que sea un mal lenguaje, estoy diciendo que no me ha gustado mucho, básicamente por esa dualidad indefinida entre los tipos básicos y los objetos, entre los encajamientos y desencajamientos que creo haber entendido bien, aunque al parecer no cuándo se producen.

Desde luego tiene cosas maravillosas, como los atributos, la reflexión, ciertas construcciones, pero no me gusta mucho. Eso no quiere decir que no vaya a seguir usándolo.

Tengo pendiente una entrada sobre los atributos y la reflexión, aunque no sé si al final la escribiré o no. También se queda en el tintero comprobar de forma práctica cómo funcionan los box/unbox y su rendimiento, por lo menos hasta más adelante que tenga más tiempo libre.

MSDN Castellano: Visual C# Express: Final en inglés ejecuta C# Express Beta 2

Menos mal que me he dado cuenta antes de enmierdar mi Vista de 32 bits. La página principal para descargas de las versiones de Visual Studio Express en castellano, (esta: http://www.microsoft.com/spanish/msdn/vstudio/express/default.mspx), tiene problemas con los contrastes de color y apenas se distingue qué te vas a bajar, al menos en lo que respecta al C# y al C++. Primera chapuza.


La segunda es todavía peor. Elegimos descargar C#, por lo que entramos a la página http://www.microsoft.com/spanish/msdn/vstudio/express/VCS/default.mspx y desde ahí hacemos clic para bajarnos la versión final en inglés del Visual C# Express… El link al que llama es este: http://go.microsoft.com/?linkid=2676891.


 ¿Final? Noooooooooooooooooooooooo…. BETA 2


 Ja ja juas, je. Menudas risas. Menos para el que lo instale, lo que me lleva a preguntarme: ¿Lo ha instalado alguien?


 Saludos y sean buenos.

Novedades para C++ y C++/CLI del nuevo Orcas

Antes de ayer el Visual C++ Team publicó en su blog una entrada contándonos las novedades que el futuro Visual Studio va a traernos a los desarrolladores de C++ nativos y de C++/CLI. Mi intención era poner esto ayer, pero por falta de tiempo no pudo ser. Y justo en el día de ayer algunos blogs en inglés se hacen eco de dichas novedades.

Menuda expectación, je je.

Lo que se dice revolucionarias, revolucionarias, no hay ninguna mejora, aunque sí bastante interesantes todas ellas. La única que podría serlo es la STLCLR, pero como ya se esperaba su inclusión no llama en exceso la atención.

STLCLR

O por otro nombre STL.NET. Toda una gozada, oiga. Hasta ahora, el programador que hubiera querido utilizar la STL nativa con estructuras de datos .NET se habría encontrado con un serio problema tanto de rendimiento como de implementación: dicho uso requiere que los elementos .NET a tratar fueran envueltos en objetos proxy y utilizados de forma cuidadosa para evitar extraños efectos laterales y una caída drástica de la funcionalidad. Por lo que al final se terminaban utilizando los genéricos, que no son lo mismo.

Pero como dice el anuncio, «el frotar se va a acabar». La STLCLR implementa la STL por completo de forma manejada y para tipos .NET. O sea, que a partir de Orcas vamos a disponer de nuestra querida STL completamente integrada dentro del .NET. Que no es poco ni moco de pavo. Esperemos que lo hayan hecho bien y que no sea otra pesadilla en cuanto a bugs.

Elegir qué versión de .NET utilizar

A partir de Orcas podremos elegir sobre qué .NET generar, desde la versión 2.0 en adelante. Como la 2.0 es una castaña en cuanto a una serie «seria» de bugs relacionados con el C++/CLI (léase problemas con los constructores estáticos, problemas con variables sin inicializar, y un largo etcétera), la 3.0 no está soportada (es decir, usa lo mismo que la 2.0), sólo nos queda la 3.5 que, según he podido comprobar, soluciona unos cuantos de los bugs citados.

Biblioteca «Marshaling»

Junto a las técnicas de «ijt» (es decir, incluye el fichero cabecera y haz la llamada al código nativo) y las de interop típicas del .NET, vamos a disponer de una nueva forma de pasar y convertir variables nativas y manejadas mediante una nueva biblioteca con estructura similar a la de las plantillas. Otra nueva gozada.

Asmmeta y /MP

Quien haya programado con C++/CLI, y más aún, con código nativo y manejado simultáneamente habrá descubierto cómo los tiempos de compilación se incrementan hasta niveles insospechados, y cómo el uso de cabeceras precompiladas apenas solucionan el tema. Habrá visto que un pequeño cambio en un fichero fuente implica la recompilación del proyecto completo sin mucha lógica aparente.

Pues dos nuevas opciones vienen a intentar mejorar dichos temas. La primera consiste en integrar el programa asmmeta.exe dentro del IDE para que minimice las dependencias y sólo se compile el código estrictamente necesario.

La segunda es la nueva opción /MP del compilador, que distribuye la compilación en entornos multiprocesador/multinúcleo de forma más efectiva. Hasta ahora, en los entornos multiprocesador, y siempre que la solución tuviera más de un proyecto, la compilación se realizaba de forma paralela respecto a los proyectos. Con esta nueva opción (que impide otras opciones como las cabeceras precompiladas) la compilación se realiza por fichero/núcleo, agilizando, según la documentación, en un 40% los tiempos de compilación para un QuadCore frente a un procesador normal.

Diálogos comunes

Como era de esperar, se actualizará toda la parafernalia de los nuevos controles comunes del Vista, la nueva forma de entender los cuadros de diálogo y los nuevos controles que el Vista trae incorporados.

En concreto se amplían las clases MFC para dar cabida a todo esto, el editor de recursos se mejora y se actualiza (hoy otro amigo del Visual C++ Team ha puesto una nueva entrada sobre ello aquí) para poder crear todos estos nuevos controles y en general se hace lo que debe hacerse. Aquí no hay ninguna ventaja ni ninguna mejora que no sean las obvias.

Otros

Entre las nuevas cosas con menor relevancia, está el soporte de plantillas amigas, es decir, la posibilidad que otros compiladores estándar tienen y el Visual C++ no.

También se va a realizar un mejor control de versionado de las bibliotecas de tiempo de ejecución (runtimes) para que aplicaciones realizadas con diferentes .NET y diferentes versiones del Visual Studio puedan funcionar lado a lado sin problemas.

Se actualizan temas relativos al UAC para que las aplicaciones entiendan y sepan moverse con esta nueva característica. Lo más importante es que a la hora de crear un nuevo ejecutable podremos decirle cuáles son sus privilegios y sus necesidades.

En el otro lado, retiran el soporte para ATL, ISAPI y alguna que otra tecnología.

Lo que falta

Y no es poco. Quizás lo añadan, pero de momento no han dicho nada. Hace tiempo Microsoft se comprometió a soportar con MFC todo lo que los nuevos .NET soportaran pero de momento no hay nada sobre ello. Y por no haber no está ni la página WEB con el compromiso, aunque sí otras que hacen referencia a la misma:

Mi pregunta que dejo en el aire es: ¿Ha vuelto a mentir Microsoft de nuevo y está matando a la chita callando las MFC?

El gran libro del PC interno, autor: Luis Durán Rodríguez

Antes de nada quiero comentar que voy a ser muy duro con el citado libro, quizás en exceso, pero creo que me debo a mi propia rigurosidad y considero que el libro merece las críticas que voy a verter.

Para aquellos que sean demasiado jóvenes o que simplemente no hayan tenido tiempo en su momento de estar al día con las novedades editoriales, he de comentar que Marcombo editó hace unos años tres ediciones de un libro alemán. El título era PC interno, y cubrió la versión 1, 2 y 5 de la edición alemana. A partir de ese momento no se volvió a hablar ni se publicó nada en relación a él. El libro estaba dividido en dos partes, la primera estaba dedicada al hardware de un PC que explicaba a fondo –pero verdaderamente a fondo- toda la electrónica y el funcionamiento del mismo. Por ejemplo, explicaba cómo acceder al disco duro mediante la modificación de los registros de la controladora, aparte de explicar los formatos y el funcionamiento mecánico de los mismos. En la segunda parte se hablaba de las aplicaciones de software de sistemas, como trabajar directamente con el vídeo o como trastear con las funciones internas de la bios y del ms dos. Posterior versiones fueron incluyendo partes de la programación de sistemas bajo Windows, pero el encanto ya se había perdido.

Este libro, que según el propio autor es una colaboración con él a la cabeza, es una mera sombra de aquellas ediciones, aunque a veces trate temas bastante interesantes. Justo al revés que en las ediciones originales, este libro comienza con la programación de sistemas bajo Windows y finaliza con lo que pretende ser una profunda descripción del hardware de un pc y se queda en un mero salpicar, y encima, completamente desactualizado.

No lo he leído por completo, pero sí lo he hojeado en profundidad y leído por completo los capítulos del once al trece, que cubren explicaciones sobre la bios, lo que hay dentro de una placa base, los chipsets, la memoria caché y las interrupciones. Y el resultado ha sido desolador. Si como creo todo el libro (o al menos toda la parte relativa al hardware del mismo) es igual, el asunto se queda en una mera enumeración desactualizada de características y conceptos unida a lo que sospecho es una mera traducción de pedazos de manuales técnicos de los fabricantes. No explica nada, se centra únicamente en enumerar esto y aquello, en poner tablas de patillajes y de señales eléctricas sin explicar, y en contarnos un montón de cosas que hace varios años que no se usan, como los chips de cache en la placa base, opciones de las bios de los 485 o historias sobre plug and play ISA.

También nos habla del ms dos, de las direcciones y registros de la bios en modo real y, en otras partes que todavía no he leído pero sí visto, nos explica cómo acceder al hardware mediante ejemplos de programas que posiblemente ni siquiera se ejecuten bajo Windows 95, menos aún en Windows XP o en Windows Vista. Nos explica, por ejemplo, cómo leer y escribir en un puerto serie directamente utilizando los registros de la UART en modo ms dos.

También trae una risible sección de creación de hardware personalizado para utilizar junto al PC en el que se nos muestra cómo crear placas de expansión ISA (recordemos que hace unos años –bastantes años- que las placas base no traen ese tipo de slots), y lo mejor de todo, sobre cómo programarlas mediante ms dos.

La única parte que se salva, y no mucho, es la de programación de sistemas bajo Windows, en la que nos habla de los procesos, de los hilos, la sincronización, la memoria virtual, las bibliotecas de enlaces dinámicos, y de cuestiones similares, finalizando con una » introducción a los sistemas operativos» en la sólo habla de Windows xp.

Al libro lo acompaña un CD sin índice ni ningún indicativo en el cual se recogen una serie de PDF con ampliaciones al libro; los que no están por completo obsoletos (hablan de ms dos y de escritura directa en hardware) son meros escaneados de lo que supongo ediciones anteriores del PC interno o de otros libros de la editorial.

Poco me hubiera costado acercarme a mi biblioteca (tan sólo tengo que cruzar una habitación) y echarle un ojo a las tres ediciones de PC interno que poseo, justo las tres que han sido editadas en castellano. Pero prefiero no hacerlo y así me evitaré quizá decir algo de lo que pudiera arrepentirme. Además, tampoco he terminado de leer este libro. Quizás más adelante, conforme vaya avanzando en su lectura, cambie de opinión y mejore mi concepto del mismo. Si es así, os lo haré saber.

Hay cosas del C# que no puedo comprender…

… y que rompe por completo las reglas de todo lenguaje de programación, de toda lógica y lo que es peor, del mismo concepto de orientación a objetos. Por lo menos así lo creo, y me gustaría estar equivocado (y que alguien me lo demostrara).

El primer tema es el hecho de que los tipos básicos, las enumeraciones, las estructuras y los delegados hereden automática y ocultamente de clases .NET. Y la palabra clave es «ocultamente». ¿Por qué? Entiendo el tema del «encajado» y «desencajado», pero no puedo entender esa ocultación. Como en la teoría cuántica, hay elementos que son objetos y que no lo son, y de la misma forma que en la teoría cuántica la medición de un objeto lo colapsa, así ocurre con el C#: cuando miramos un elemento de los citados, o es un objeto o un elemento básico, con la sobrecarga que eso conlleva: si antes era lo contrario, hay que convertirlo al nuevo valor, con pérdida de tiempo y de recursos.

Pero también ocurren otras cosas un tanto extrañas. Veámoslo con un ejemplo. Una enumeración hereda de System.Enum, pero sin embargo dicho System.Enum no es una enumeración, sino una clase. Y justo al revés, una enumeración es una enumeración (en el concepto tradicional) que podemos convertir en objeto y que así pase a ser algo alojado en el montículo y que tiene los miembros de System.Enum. Y yo me digo, ¿qué más da que esté en la pila o en el montículo? Es un objeto y ya está. O no lo es. ¿Por qué cuando está en la pila no podemos usar sus métodos miembros y sí cuando está en el montículo? Y lo más incomprensible para mí: cada vez que usamos una enumeración como tal, la tenemos en la pila, y cuando la usamos como un objeto, debemos pasarla al montículo, y de nuevo al revés. Me vais a perdonar pero no lo entiendo.

Lo que veo (y me gustaría no ver) es lo que considero una serie de errores de concepto garrafales en todo el .NET; la propia idiosincrasia del .NET está mal, al menos en los aspectos que cito. ¿Por qué toda esa manía de que todo sea un objeto cuando evidentemente muchas cosas no lo son? Repito que es una apreciación personal, pero de momento es la que tengo. Y se va confirmando conforme voy leyendo el libro de Hejlsberg.

Otro tema que me trae de cabeza son los destructores. ¿Los hay? Según Hejlsberg sí, pero resulta que se implementan mediante la sobreescritura del método Finalize de la clase System.Object. Pero entonces no son destructores, sino algo que el sistema en tiempo de ejecución llama cuando el recolector de basura así lo decide. Al final, en las pocas páginas en las que se trata el tema (352-354) no queda nada claro, pero nada de nada la finalidad y el objeto de los destructores, así como el uso de Finalize. Y tampoco menciona qué pasa con Dispose. La verdad es que parece que ni el propio creador del lenguaje se entera. ¿Cómo vamos, pues, a enterarnos los mortales comunes?

Todavía queda una cosa más: la palabra reservada extern en constructores, destructores y demás elementos de una clase. Parece ser que son elementos que no tienen implementación. Pero no se dan más explicaciones. Ni dónde se podría encontrar, ni cómo, ni para qué sirven. En otros lenguajes con extern indicamos que dicho elemento está implementado en otro lugar, pero que dicha implementación existe en algún lugar. Hejlsberg no nos dice nada sobre ello. Pero aquí hay truco, aunque venga después. No sé si el libro lo documenta, pero espero que sí. Dejamos al lector que se imagine para qué puede servir dicho extern, pero diremos que desde mi punto de vista es otra de esas «cosas raras» que no me gustan un pelo del C# y por extensión del .NET

Me vais a perdonar la expresión, pero considero que por estos aspectos (y alguno más que ya he mencionado con anterioridad) el .NET y el C# (y por supuesto el VB.NET y el C++/CLI que es CLI) es un aborto, carente de mucha lógica y consistencia.