¿Debemos aprender una nueva forma de escribir bucles?

English version 


 


Hasta el momento, cada vez que alguien menciona los peligros potenciales que comenzarán a “rondar” al programador con la introducción de las nuevas características de C# 3.0 (la inferencia de tipos de variables locales –léase var– y los métodos extensores, principalmente), mi reacción es siempre la misma: considero que son recursos necesarios para ofrecer el soporte a las consultas integradas, no son en principio características carentes de atractivo ni mucho menos “impresentables”, y a través de la educación podremos alertar a los desarrolladores para que sean capaces de evitar los peligros que el uso de estas características podría esconder.

 

Hace unos días he visto un post de Luke Hoban que ha reforzado mi convicción en el papel que tendremos los formadores en la educación de los programadores .NET; en este caso, enseñándoles a no utilizar las consultas integradas para lo que no tiene sentido. El post en cuestión muestra cómo resolver la distribución de pesas en una balanza utilizando un enfoque de fuerza bruta: una serie de “bucles” anidados que se modelan utilizando el operador de consulta estándar Range(min, max), que produce secuencialmente los valores enteros entre min y max, ambos inclusive. Me pareció una situación en la que la consulta integrada no aporta nada con relación a bucles tradicionales, y que sí podría comprometer el rendimiento.

 

El problema en cuestión me recordó ciertos ejercicios que poníamos hace 20 años en la Universidad a los estudiantes de la asignatura “Introducción a la Programación” (bajo la inestimable dirección del Dr. Miguel Katrib). Así que decidí programar uno de estos ejercicios por las dos vías: mediante bucles “tradicionales” y “a la Hoban”, para comparar ambas implementaciones.

 

Enunciado: Escriba un programa que determine todos los números de cuatro cifras que son iguales a la suma de las cuartas potencias de cada una de las cifras que lo componen. Por ejemplo, uno de esos números es 1634:

 

                 1634 = 14 + 64 + 34 + 44

 

Solución (naïve): Iteramos en un cuádruple bucle anidado sobre todos los posibles valores de cada una de las cuatro cifras del número.

 

Al final de este post se presenta el código del programa que prueba ambas variantes; en la variante basada en bucles, hemos introducido una lista genérica para hacerla lo más parecida posible a la variante LINQ.

 

En mi portátil, la relación entre los tiempos consumidos fue de 80:95. Honestamente, esperaba un desequilibrio bastante mayor. Pero lo importante es: ¿aporta algo la utilización de una consulta integrada aquí? Las opiniones son bienvenidas.


 


//*********************************************************************


class Program


{

    static void Main(string[] args)

    {

        Stopwatch sw = new Stopwatch();

        sw.Start();


        // versión “clásica”

        List<int> cumplen = new List<int>();

        for (int i1 = 1; i1 <= 9; i1++)

        for (int i2 = 0; i2 <= 9; i2++)         for (int i3 = 0; i3 <= 9; i3++)

        for (int i4 = 0; i4 <= 9; i4++)

            if (Condicion(i1, i2, i3, i4))

                cumplen.Add(Numero(i1, i2, i3, i4));


        foreach (int n in cumplen)

            Console.WriteLine(n);

        sw.Stop();

        Console.WriteLine(“Transcurrido: “ + sw.ElapsedMilliseconds.ToString());

        sw.Start();


        // versión LINQ

        IEnumerable<int> cumplen2 =

            from j1 in Enumerable.Range(1, 9)

            from j2 in Enumerable.Range(0, 9)

            from j3 in Enumerable.Range(0, 9)

            from j4 in Enumerable.Range(0, 9)

                where Condicion(j1, j2, j3, j4)

                    select Numero(j1, j2, j3, j4);

        foreach (int n in cumplen2)

            Console.WriteLine(n);

        sw.Stop();

        Console.WriteLine(“Transcurrido: “ + sw.ElapsedMilliseconds.ToString());        Console.ReadLine();

    }

    static bool Condicion(int a, int b, int c, int d)

    {

        return Numero(a, b, c, d) == Cuarta(a) + Cuarta(b) + Cuarta(c) + Cuarta(d);

    }


    static int Numero(int a, int b, int c, int d) { return 1000 * a + 100 * b + 10 * c + d; }

    static int Cuadrado(int a) { return a * a; }     static int Cuarta(int a) { return Cuadrado(a) * Cuadrado(a); }

}


//*********************************************************************


 

¡Qué grande es el software!

El título de este post está obviamente inspirado en el lamentablemente ya desaparecido programa de José Luis Garci por la 2 de TVE.


Después de una semana anterior “movidita”, en la que aprendí no poco sobre WPF de la mano de ese fenómeno que es Cristian Manteiga, durante el fin de semana al único software que me “acerqué” lo hice como espectador. Pero ¡vaya espectáculo! Una maravilla de programa que no había visto antes y me causó tremenda impresión.


Me refiero a Pro-Tools 7.3 (http://www.digidesign.com/), una suite de herramientas para la creación de piezas musicales, edición y mezcla de audio y vídeo y muchas cosas más que en manos de “titanes” como Javier Limón, José Luis Crespo o mi propio hermano El Negro permite realizar con asombrosa facilidad tareas que hasta hace relativamente poco requerían del tiempo y esfuerzo de muchas personas a la vez. Piezas de software como ésta hacen pensar en lo que ha avanzado el mundo desde que la informática se ha hecho omnipresente en él.


Eso sí, debo decir que lo que vi en acción fue la versión para MacIntosh del producto 🙂


 

Respuestas a preguntas sobre LINQ en el Developer’s Day

Haciendo eco del post de David Salgado, reproduzco aquí las respuestas a las preguntas sobre LINQ recibidas por SMS durante el pasado Developer’s Day. Me he permitido unas ligeras adiciones, siempre que revisa al cabo de un tiempo lo que se ha escrito se encuentran maneras de mejorarlo 🙂


1.      No entiendo porqué la select está al final en LINQ ¿porqué no respeta la sintaxis SQL?


 


Piensa en la sentencia SELECT de SQL, por ejemplo:


 


            // candidatas para David Sal(Del)gado


            SELECT Nombre, Apellidos


            FROM Amigos


            WHERE Sexo = ‘M’ AND EstadoCivil = ‘S’ AND Edad <= 25


 


Después de teclear SELECT, el entorno de desarrollo no podrá darte ayuda de ningún tipo con relación a los campos que quieres seleccionar, porque aún no sabe con qué tabla(s) vas a trabajar (lo cual se indica en la cláusula FROM).


 


Con la sintaxis que propone LINQ:


 


            from f in db.Amigos


            where f.Sexo == ‘M’ and f.EstadoCivil = ‘S’ and f.Edad <= 25


            select new { f.Nombre, f.Apellidos };


 


se resuelve ese problema. Cuando tecleas ‘f.’ detrás del where, ya el entorno sabe que f es de tipo Amigo, porque db.Amigos es de tipo Table<Amigo> (que implementa IEnumerable<Amigo>).


 


Esta decisión ha sido motivo de amplias discusiones (no violentas 🙂 dentro de los equipos de desarrollo de MS. De hecho, en la Presentación Preliminar de Mayo de 2006, en VB.NET el Select se ponía delante. Ahora ambos lenguajes utilizan el Select al final.


 


2.      ¿Qué es eso del var en C# 3.0? ¿Acaso el lenguaje va a dejar de ser estáticamente tipado?


 


La sentencia var en C# 3.0 hará que el compilador infiera o deduzca el tipo de la variable en función del tipo de la expresión que se coloque del lado derecho de la asignación (var solo se podrá utilizar junto con una expresión de inicialización). Por ejemplo, en:


 


            var s = “Hola”;


 


el compilador determinará que el tipo de la variable s es string. No es object, ni Variant como en VB6, ni una variable “amorfa” como en Javascript, ni nada por el estilo. La aparición de var no implica que C# deje de ser un lenguaje con fuerte control de tipos ni mucho menos. Simplemente el lenguaje nos facilita la vida, no obligándonos a indicar el tipo de la variable y encargándose él de deducirlo. En principio, el uso de var solo es imprescindible cuando la expresión a la derecha de la asignación es de un tipo anónimo (otra nueva característica de C# 3.0).


 


Por supuesto, esta característica debe usarse juiciosamente, porque su uso indiscriminado puede llevar a que nuestro código se haga menos legible.


 


3.      Si no sabes el tipo de algo, ¿cómo sabes con qué propiedades y métodos lo manejas?


 


Esta pregunta tiene relación con la anterior. Dado que C# es un lenguaje estáticamente tipado, el compilador (y el entorno, que se apoya en él) siempre sabe el tipo de cualquier variable o expresión, ya sea porque se lo decimos nosotros o porque él lo deduce (como ocurre cuando usamos var para declarar una variable). Suponiendo que hemos definido la variable ‘s’ de la pregunta anterior, cuando tecleemos ‘s.’ dentro del editor nos aparecerá la lista de propiedades, métodos y eventos de la clase string. Y si se trata de una variable de un tipo anónimo (generado internamente por el compilador), la ayuda Intellisense nos dirá qué propiedades, métodos y eventos tenemos a nuestra disposición.


 


4.      ¿Qué rendimiento presenta LINQ respecto a la consulta directa usando el DOM para XML o sentencias SQL para BBDD?


 


Aunque no he hecho pruebas de rendimiento específicas, pienso que el rendimiento de LINQ to XML (por ejemplo, en búsquedas XPath) debe ser muy cercano al que podemos obtener hoy con el DOM. En el caso de LINQ to SQL, la diferencia podría ser algo mayor. Yo y otros compañeros hemos detectado en ocasiones que las sentencias SQL generadas por LINQ to SQL (se puede utilizar la propiedad Log del objeto de conexión para enviar las sentencias a la consola o un fichero y así poder examinarlas) son menos eficientes de lo que podría obtenerse escribiendo la sentencia “a mano”. Esto es lo que ocurre casi siempre que dejamos de hacer algo manualmente y comenzamos a apoyarnos en una herramienta automática. En defensa de LINQ to SQL hay que decir que:


 


a)      Estamos trabajando aún con una versión pre-beta, que sin lugar a dudas mejorará mucho antes de la salida del producto final.


b)      En cualquier caso, se seguirá investigando a ese respecto para futuras versionesJ.


c)      El contexto de datos tiene una propiedad Connection que da acceso a la conexión ADO.NET subyacente, a la que podremos recurrir en caso de que necesitemos obtener un rendimiento superior al que nos dé LINQ to SQL.


 


Como en todo, es cuestión de sopesar las ventajas contra los inconvenientes de una tecnología, y ver si es conveniente o no utilizarla. Para mí personalmente las ventajas (mayor expresividad y claridad del lenguaje, verificación del código en tiempo de compilación – al no tener que escribir las sentencias SQL como cadenas dentro de la aplicación-, ayuda Intellisense para las consultas integradas, mayor potencia en las API de actualización, etc.) superan a los inconvenientes en la mayoría de las situaciones en las que me encuentro habitualmente durante mi trabajo.


 


5.      Ahora mismo tengo un AMD 3200+ con 1gb de RAM y vs05 corre a tirones ¿qué necesitaré para ORCAS?


 


Para que funcione la CTP de marzo, la página de descarga recomienda un Pentium III+ con 1 GB de memoria libre (lo que queda después de la carga del sistema operativo y los servicios). Mi experiencia personal me dice que 2 MB es lo óptimo. Los requisitos finales que se necesitará para ejecutar la versión definitiva de Orcas deberán ser algo menores.


 


En cualquier caso, no está de más repetir la recomendación de siempre: ¡no instalar esta CTP en un PC de trabajo!


 


6.      ¿Hay LINQ to AS400?


 


La versión final de Orcas incorporará únicamente proveedores de LINQ to SQL para SQL Server 2000 y 2005. No obstante, ya hay otros fabricantes trabajando muy cerca de Microsoft para producir los correspondientes proveedores (no tengo la menor idea de si IBM está entre ellos).


 


Navegando por la red, hoy he encontrado este artículo en el que se habla de un gran interés de IBM hacia LINQ (y un cierto desinterés por parte de Oracle):


 


     Redmond Developer News


 


7.      ¿Mejora Windows Mobile con Orcas?


 


Windows Mobile 6 incorporará múltiples ventajas con respecto a la versión actual, aunque todo parece indicar que los desarrolladores no seremos los más beneficiados. La principal ventaja será que .NET CF vendrá incorporado ya en ROM, como puede leerse en la entrevista al Product Manager de Windows Mobile 6, en la dotNetManía de este mes (www.dotnetmania.com)


 

I’m a Plain guy

“The truth that lies before us now is plain for all to see
To grow without is not to grow within.


 


KANSAS “No one together” (1980)


 


Es para mí un orgullo anunciar mi incorporación como Development Advisor a Plain Concepts, the Microsoft technologies Know-how company, donde espero dar lo mejor de mí y crecer intelectualmente (como parece sugerir la letra de mi banda favorita) junto a excelentes amigos y grandes especialistas en sus respectivas áreas como Pablo Peláez, Iván González, Rodrigo Corral, Unai Zorrilla, Jorgito Serrano, Marco Amoedo o Cristian Manteiga, entre otros.

Arte digital con C# 3.0 y LINQ

De entre la avalancha de vídeos, documentos y enlaces que con los que nos abrumó Charlie Calvert simultáneamente con la salida de la última CTP de Orcas (marzo), me llamó especialmente la atención una referencia a un post de Wes Dyer, miembro del equipo de desarrollo de C#, en el que éste muestra una aplicación que permite, mediante un curioso algoritmo, “aproximar” una imagen en una consola DOS mediante caracteres ASCII. Algo como lo siguiente (he utilizado una foto de mi hija Diana para presumir de ella):



Aunque algunas expresiones de consulta pueden parecer algo forzadas, y se hace uso y abuso de métodos extensores, algo que está aún por ver si la práctica avalará, este programa es un buen ejemplo práctico del tipo de código C# que se podrá encontrar en un futuro nada lejano. Por ello, le recomiendo que le eche un vistazo. Si va a ejecutarlo sobre la CTP de marzo, tenga en cuenta que antes tendrá que resolver dos o tres problemillas de compilación debidos a que el autor utilizó una versión más avanzada de Orcas que la CTP. Las modificaciones del código necesarias se describen también en el blog.


 

Novedades en la CTP de Orcas de marzo de 2007

Como otros colegas ya han anunciado, está disponible desde hace unos días la CTP de marzo de Orcas, que se puede descargar desde aquí:


    http://www.microsoft.com/downloads/details.aspx?familyid=281fcb3d-5e79-4126-b4c0-8db6332de26e&displaylang=en


Yo no he tenido ni que descargármela, gracias a la gentileza de mi buen amigo Unai Zorrilla.


Aquí va un resumen de las características más relevantes de la CTP relacionadas con los lenguajes y LINQ (aunque la CTP contiene muchísimo más):


·         LENGUAJES


o        Soporte para las características de C# 3.0: Esta CTP implementa todas las características del lenguaje C# 3.0 que ofrecía la CTP de LINQ de mayo de 2006:


§         Expresiones de consulta


§         Inicializadores de objetos y colecciones


§         Métodos extensores


§         Inferencia de tipo de variables locales y tipos anónimos


§         Lambdas asociadas a delegados y árboles de expresiones


§         Soporte completo de tiempo de diseño: Intellisense, formato, colorización


o        Soporte para las características de VB 9.0: Esta CTP implementa las siguientes características del lenguaje:


§         Expresiones de consulta: soporte de consultas, filtrado y ordenación


§         Inicializadores de objetos


§         Métodos extensores


§         Inferencia de tipo de variables locales


§         Tipos anónimos


§         Literales XML


§         Propiedades XML


§         Intellisense para nueva línea y para expresiones


·         LINQ


o        LINQ to Objects


§         La API de LINQ to Objects permite consultas sobre cualquier colección .NET, como arrays y listas genéricas. Esta API se define en el espacio de nombres System.Linq dentro de System.Core.dll.


o        LINQ to XML (XLinq)


·         Añadidas las clases del espacio System.Xml Bridge, que contienen un conjunto de métodos extensores que permiten utilizar XPath y XSLT sobre árboles de LINQ to XML, producir un árbol de LINQ to XML mediante una transformación XSLT, y validar un árbol de nodos XElement contra un esquema XML.


·         Modelo de eventos, que hacen posible la sincronización eficiente de árboles LINQ to XML con una interfaz gráfica de usuario (por ejemplo, una aplicación WPF).


·         Cambios en la jerarquía de clases – añadida la clase XObject, eliminada (temporalmente) XStreamingElement.


·         Mejoras de usabilidad varias – se han realizado varias modificaciones menores en respuesta a estudios internos y sugerencias externas, para hacer la API más limpia y consistente.


o        LINQ to ADO.NET


·         ADO.NET se integra completamente con LINQ y ofrece múltiples opciones para utilizar LINQ en varios escenarios: LINQ to SQL ofrece acceso directo a tablas de bases de datos desde el entorno de programación, LINQ to Entities permite a los desarrolladores utilizar LINQ sobre modelos EDM (Entity Data Models), y LINQ to DataSet permite utilizar toda la expresividad de LINQ sobre DataSets.


·         LINQ to Entities permite a los desarrolladores programar contra una base de datos relacional utilizando una vista de los datos apropiada para la aplicación que están construyendo, independientemente de la estructura de la base de datos subyacente. El uso de modelos EDM permite a los desarrolladores diseñar modelos que sigan los conceptos naturales de la aplicación, en lugar de tener que mapearlos a las construcciones que ofrecen los almacenes relacionales. LINQ to Entities está creado sobre el modelo de proveedor de ADO.NET y permitirá trabajar contra diversos almacenes de datos relacionales, además de contra Microsoft SQL Server. Esta CTP incluye un proveedor de LINQ to Entities para SQL Server y SQL Server Compact Edition.


·         LINQ to SQL (antes conocido como DLinq) ha mejorado su funcionalidad con respecto a la CTP de mayo de 2006. Puede encontrar esta API en el espacio de nombres System.Data.Linq dentro del ensamblado System.Data.Linq.dll. Una novedad de esta edición es que la clase DataContext ofrece modos optimizados para la utilización en modo de solo lectura y la serialización. También es nuevo que la clase DataShape simplifica la carga temprana y añade la posibilidad de establecer consultas sobre relaciones.


o        Diseñador de LINQ to SQL


            ·         Ahora es posible crear métodos a partir de procedimientos almacenados y funciones dentro del diseñador.


            ·         Mejor gestión de los esquemas de bases de datos.


            ·         Soporte mejorado para la herencia en el diseñador.


 

¿Se avecina una revolución, o solo me lo parece?

“Finally the tables are starting to turn


I’m talkin’ about a revolution…”


 


Tracy Chapman


 


Hace unos días, en respuesta a un post sobre la disponibilidad de LINQ to SQL, mi admirado amigo Rodrigo Corral me escribía:



“A más de uno se nos ponen los pelos como escarpias cada vez que oímos SQL y LINQ en la misma frase … ya me gustaría leer tu opinión sobre el tema”


Aunque normalmente evito generar polémicas, y sobre todo las que conducen a “diálogos entre sordos”, como decía Gorbachev, he pensado en plasmar en este artículo mis ideas al respecto, en busca de las opiniones de algunos de los muchos desarrolladores inteligentes que escriben aquí o visitan estas páginas regularmente.


Ante todo, quiero dejar claro lo siguiente:


·         Nada más lejos de mis intenciones que atacar a nadie ni de menospreciar su trabajo.


·         No me considero ningún “gurú” ni nada por el estilo; mis opiniones pueden ser totalmente erradas. Sí soy alguien que tiene la suerte de llevar 20+ años programando y enseñando a programar con espíritu crítico, y de haber vivido casi desde cero el desarrollo de los lenguajes y sistemas de programación.


Luego quiero expresar convicciones personales adquiridas de la experiencia y de las que será difícil moverme:


·         Con sus posibles defectos, la POO es, de los paradigmas de programación hoy en uso, el que mejor permite modelar el universo en que vivimos y que mejor se adecua a las necesidades de los desarrolladores de aplicaciones. No sé si será el paradigma definitivo (“ultimate”, dirían en inglés), pero en el panorama no se vislumbra ningún otro capaz de sustituirlo a corto o mediano plazo. Sí hay que reconocer que los lenguajes .NET están también “importando” conceptos de otros “mundos” como la programación funcional, que vienen a enriquecer el modelo OO sin variar su esencia.


·         La manera en que desarrollamos hoy, por ejemplo, las aplicaciones que acceden a bases de datos corporativas lleva implícito un desajuste de impedancia provocado por la necesidad de tener que, desde lenguajes OO, usar SQL para expresar las sentencias de recuperación y almacenamiento persistente de los datos. SQL es un lenguaje diferente, basado en otro paradigma de programación, que tiene su curva de aprendizaje, y cuyas sentencias finalmente embebemos dentro de nuestras aplicaciones en forma de cadenas de caracteres que se saltan “a la torera” el control del compilador.


Bueno, después del “prólogo”, aquí va entonces mi predicción:


·         Dentro de unos pocos años, los desarrolladores de aplicaciones no escribirán ni una sola sentencia SQL en sus aplicaciones.


No sé si mi predilección por los trabajos de Hejlsberg (a quien sigo desde los tiempos de Turbo Pascal 1.0, circa 1984) me nuble la vista, pero pienso que LINQ está entre lo más relevante que ha generado el desarrollo de los lenguajes de programación en muchos años. Creo que la posibilidad de ejecutar consultas integradas en el lenguaje de manera uniforme contra los más diversos almacenes de datos, empezando por las colecciones de datos en memoria y terminando por los documentos XML y las bases de datos SQL (más todo lo demás que se tercie) es algo que hará mucho más productivos a los programadores, más claros y mantenibles a nuestros programas y que reducirá sensiblemente la curva de aprendizaje de los principiantes.


 


Pero con la aparición de LINQ no solo dejará de ser necesario escribir sentencias SELECT. Como puede leerse en el excelente post de Juan Carlos González, LINQ To SQL añadirá a las posibilidades generales de consulta un ORM ligero (“lightweight Object-Relational Mapper”) capaz de gestionar la identidad de los objetos de negocio y de suministrar operaciones de actualización que se traducirán, tras las bambalinas y de manera transparente al programador, en las sentencias SQL correspondientes.


 


Como yo lo veo, con la llegada de Orcas podremos empezar a crear aplicaciones verdaderamente 100% orientadas a objetos, a trabajar a un nivel cualitativamente más alto. Por supuesto, aún queda mucho trabajo por delante, sobre todo en lo relativo a la creación de un cuerpo teórico asociado a la arquitectura de las aplicaciones basadas en LINQ; pero (creo) ya se puede vislumbrar lo que vendrá.


 


Si has leído hasta aquí este “panfleto incendiario”, solo me resta darte las gracias. Tu opinión será bienvenida.


 


 

Sobre la ‘@’, el ‘&’ y otros "escapes"

En un reciente artículo,


    http://geeks.ms/blogs/rfog/archive/2007/02/19/el-uso-on-de-la-algarroba-dentro-de-un-programa-escrito-en-c.aspx,


mi buen amigo RFOG escribía sobre la posibilidad de utilizar en C# el carácter ‘@’ como prefijo delante de una palabra reservada, para indicar que ésta debe ser tratada como un identificador “normal”. Augusto Ruiz comentaba, correctamente, que la utilidad del uso de la ‘@’ delante de las palabras reservadas radica en que permite referirse desde C# a una clase, propiedad, método, etc. creada en otro lenguaje con un nombre que coincide con el de una palabra reservada de C#. Asimismo, indicaba que en Visual Basic para lograr ese efecto se encierra la palabra reservada entre corchetes.


Me imagino que todo lenguaje .NET que se precie debe tener algún mecanismo similar, dado el énfasis que hace la plataforma en que sea posible utilizar el código escrito en otros lenguajes. Por ejemplo, en Delphi/Object Pascal .NET el papel de la ‘@’ lo juega el ‘&’.


Un ejemplo de situación en la que la existencia de estos caracteres de “escape” es, cuando menos, sumamente útil, es la que sufrí tiempo atrás y me vino a la mente cuando leí el post de Rafa. Como todo el mundo conoce, la propiedad mediante la cual se representa al destinatario del mensaje de correo en las clases System.Web.Mail.MailMessage y System.Net.Mail.MailMessage se llama “To“. Con C# y VB no hay ningún problema, pero… ¡to es una palabra reservada de Pascal! (recuerde el típico bucle for i := 1 to 10 do Console.WriteLine(i);). Pascal además no distingue mayúsculas de minúsculas, así que cada vez que en Delphi .NET se quiere especificar el destinatario de un correo electrónico, no queda más narices que escribir:


    miMensaje.&To := ‘sleepless@seattle.com’;


 

La próxima CTP de Orcas será en marzo

Según Dinesh Kulkarni, Program Manager de Visual C#, podemos esperar la próxima CTP de Orcas para el próximo marzo:


    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1180478&SiteID=1


Dinesh confirma que en esta CTP ya estará incluida toda la funcionalidad relacionada con LINQ To SQL (tecnología anteriormente conocida como DLINQ), que permitirá utilizar las consultas integradas en el lenguaje contra bases de datos relacionales, sobre lo que no hemos visto nada nuevo desde hace algún tiempo…


 

Otra gran entrevista a Anders…

Mi viejo conocido Charlie Calvert (otro ex-Borlander) ha publicado en su blog otra entrevista a Anders Hejlsberg, arquitecto principal de C#, en la que éste habla sobre las ventajas que ofrecerá a los programadores la incorporación a C# y VB de elementos de programación funcional y de las consultas integradas en el lenguaje:



          http://blogs.msdn.com/charlie/archive/2007/01/26/anders-hejlsberg-on-linq-and-functional-programming.aspx



De esta entrevista me quedo no solo con la extraordinaria lucidez con la que Anders resume en unos pocos minutos la importancia de las funciones lambda, los árboles de expresiones o las consultas integradas en los lenguajes, sino también con la introducción preliminar de Charlie, en la que algunos encontraremos reflejada la historia de nuestras vidas.