La decepción para el final, o ¿Hace falta leer libros?

Hace un rato, estaba viendo una reciente entrevista a Mads Torgersen, Senior Program Manager de C#.


La entrevista, aunque nada brillante en mi humilde opinión, tenía sus elementos de interés, y se dejaba ver. Hasta que llegó la última pregunta, que me dejó atónito:


    Q. What’s your favorite computer book?


    A. I never read computer books. That is boring.


¿Puede alguien que está trabajando en la frontera de la innovación no leer ningún libro de su especialidad? Por otra parte, ¿puede decirlo públicamente y quedarse tan fresco como una lechuga (no “ponerse colorao”, como diría mi abuela)? Son preguntas para las que no tengo una respuesta inmediata.


De entre los “meros mortales”, el caso similar más relevante que recuerdo es el de mi ilustre compatriota José Raúl Capablanca, varias veces campeón mundial, que se jactaba de nunca haber leído ningún libro sobre ajedrez. Capablanca indudablemente fue un genio, pero hay que decir que eran los años 20 del siglo pasado y el mundo del ajedrez no era ni mucho menos lo que es hoy (imitando a mi compañero Pablito Doval – ¡genial idea la de los rock tips!, me permito citar un tema de rock que habla sobre eso: “When the world was young“, del álbum “Somewhere to Elsewhere“, KANSAS, año 2000).


De entre los “inmortales” (personajes de ficción), recuerdo que Sherlock Holmes (que no sabía que la Tierra giraba alrededor del Sol y juró olvidarlo lo antes posible cuando se lo dijeron, porque ese hecho no le servía para su labor detectivesca), reconocía no leer nunca ningún libro, exceptuando los que le aportaran algo para su trabajo.

 

¿Qué piensa usted, estimado lector?

 

La relación entre LINQ y Don Knuth

Este post es en buena medida continuación de otro anterior, y trata sobre otra de las “pegas” habituales que me encuentro durante las charlas (formales o informales) relacionadas con LINQ.


A la que voy a comentar hoy yo la llamo “el síndrome de la obsesión por el rendimiento”, y se manifiesta en el hecho de mi interlocutor, desde la primera vez que oyó hablar sobre LINQ, decidió que esa tecnología a él no le vale porque “afecta el rendimiento”.


La mayor parte de las veces (aunque no siempre – a veces también he hablado sobre la complejidad algorítmica de los operadores en LINQ to Objects, por ejemplo), esto tiene relación con lo que mencionábamos en el post anterior: se confunde a LINQ como un todo con LINQ to SQL en particular, y de lo que se trata en el fondo es del temor de esa persona a la pérdida de control que representa dejar la generación de “sus” sentencias SQL en manos de una API del sistema. Es curioso que, en algunas ocasiones, la actitud de la persona en cuestión rezuma hostilidad, como si le fuera la vida (o el empleo) en ello.


En primer lugar, todos sabemos que “el rendimiento” es un concepto muy relativo: lo que puede no ser aceptable para un cierto tipo de aplicaciones sí lo es para otros, y lo que puede no ser aceptable hoy sí lo será mañana, con máquinas más rápidas y mejor dotadas.


Pero lo más cuestionable, a mi modo de ver, de estas actitudes, es que dan una idea de que quienes las asumen aplican en su trabajo diario un “performance-driven development” que seguramente les impide alcanzar los niveles de productividad a los que podrían llegar si dejaran de tratar de poner la carreta delante de los bueyes.


De más está decir que hay ciertas aplicaciones que tienen como requisito primario y esencial un rendimiento excepcional. No es a ese tipo de aplicaciones al que me estoy refiriendo aquí, sino a la típica aplicación corporativa en la que prevalecen mantenimientos en los que es relativamente irrelevante que la ejecución de una consulta demore tres segundos ó cinco (siempre que no sean sesenta, por supuesto).
 
Una frase de uno de los genios de la informática, Donald Knuth (con cuya obra hemos aprendido varias generaciones de programadores), que nunca he olvidado es “Premature optimization is the root of all evil” (“Optimizar antes de tiempo es la raíz de todos los males”). Mi interpretación de esa frase consiste en que, como regla general, un programa se debe atacar utilizando las herramientas de más alto nivel que uno tenga a su disposición y sean adecuadas para la tarea, para solo después, como consecuencia de un perfilado, optimizar las partes en las que merezca la pena mejorar el rendimiento.


Es en ese espíritu en el que creo que debe verse a LINQ en todas sus variantes: como un artefacto que permitirá multiplicar por N ( N > 1 🙂 nuestra productividad, sin impedirnos bajar al nivel subyacente cuando (pero solo cuando) ello sea necesario.


Nota: Este post refleja única y exclusivamente mis opiniones personales.


 

Uno sobre ortografía

El interesante post de El Bruno sobre la corrección ortográfica de recursos de texto en VS 2008 me ha dado la idea de escribir este post relacionado con un tema colateral (pero necesario para todos los que escribimos) como es la ortografía. Concretamente, quería presentar uno de los fallitos ortográficos más comunes que tenemos que corregir en dotNetManía (conjuntamente con Paco Marín, gran conocedor de ese tema), algo seguramente ayudado por el hecho de que el corrector ortográfico de Word no lo puede resolver automáticamente.


Se trata de la acentuación de la palabra “solo”. Si no sois demasiado más jóvenes que yo, recordaréis la regla que decía: “Solo” deberá llevar tilde cuando ejerza función de adverbio en la oración; es decir, cuando se pueda sustituir por “solamente”. Pues bien, en cierto momento esa regla cambió, y la regla actual dice: “Solo” deberá llevar tilde cuando ejerza función de adverbio en la oración, pero solo en caso de que hubiese posibilidad de confusión entre el uso adverbial y el uso como adjetivo, para significar “sin compañía” (ver la regla oficial aquí). Eso implica que la mayor parte de las veces que antes poníamos la tilde ahora no tenemos que hacerlo. Únicamente habría que poner la tilde en los casos de posible ambigüedad, como por ejemplo en “Se permite fumar sólo en las áreas habilitadas al efecto“. Por cierto esta frase está “basada en una historia real”: puede verse en varios lugares del Aeropuerto de Barajas. La duda que me entra es si los de AENA pusieron la tilde con conocimiento de causa, o les salió bien por simple fortuna :-).


En general, a mí me parece preferible la regla vieja… Cabría preguntarse si al cambiar la regla los señores académicos solo (sin tilde 🙂 se basaron en el criterio economicista de que ahora hay que levantar menos el lápiz a la hora de escribir (sobre todo en esta época de utilización masiva del ordenador :-).


 ¡Felices fiestas!


 


 

More on LINQPad

El excelente post de Juan Carlos González Martín sobre LINQPad ha vuelto a llamar mi atención sobre esta útil herramienta, que conocí cuando aún estaba “en pañales” y a la que había perdido la pista últimamente. Y resulta que LINQPad ha ganado en funcionalidades, permitiendo no solo ejecutar consultas LINQ contra bases de datos de SQL Server (para lo que obviamente se apoya en la herramienta sqlMetal, encargada de generar las clases de entidad correspondientes), sino también de compilar y ejecutar grupos de sentencias cualesquiera escritas en C# o VB, algo que probablemente hará apoyándose en el DOM o llamando directamente a los compiladores de línea de comandos. Lo que sí brilla aún por su ausencia es cualquier tipo de documentación, lo que hace necesario un poco de “prueba y fallo”…


La ejecución de sentencias que incluyan consultas LINQ to Objects parece trivial. Se abre una nueva consulta, se indica que el tipo (Type) es “C# statements” (para quienes usan C#) y que Database es “None”. Y ya se puede teclear en la ventana código como el siguiente:



string[] paises = { “España”, “Cuba” };
foreach (string p in paises)
  p.Dump (“Nombre”);


¡No hay Intellisense, claro! Al pulsar el botón de ejecución, LINQPad compila en fragmento (seguramente envolviéndolo en un método adecuado) y lo ejecuta.


Para ejecutar consultas LINQ to XML, es necesario utilizar la opción Query | Advanced properties del menú y agregar una referencia al ensamblado System.Xml.Linq.dll () e importar el espacio de nombres System.Xml.Linq. Entonces podremos ejecutar consultas como ésta:



XElement paises = XElement.Parse (
@”<paises>
    <pais>
      <nombre>España</nombre><codigo>ES</codigo>
    </pais>
    <pais>
      <nombre>Cuba</nombre><codigo>CU</codigo>
    </pais>
  </paises>”);
foreach (XElement p in paises.Elements())
   p.Element(“nombre”).Value.Dump (“Nombre”); 


¿Qué es el método Dump() al que se llama desde estos ejemplos? No lo dice por ningún lado, pero es obvio que es un método extensor que los creadores de LINQPad han definido más o menos así:



public static class ExtensionesLINQPad
{
    public static void Dump(this object obj, string header)
    {
        // RT1 es el control de texto enriquecido
        // en la parte inferior de la ventana
        RT1.Lines.Add(header);
        RT1.Lines.Add(obj.ToString());
    }
}


De todos los recursos asociados a LINQPad a los que Juan Carlos hace referencia en su post, el que más me ha impresionado es el LINQQuiz, un examen que sinceramente recomiendo a todo el que quiera comprobar sus conocimientos sobre LINQ. Alguna vez tuve la idea de poner ejercicios al final de cada capítulo de mi libro, pero eso quedará para la próxima edición 😉

[OT] A big Thanks! to my PLAIN-pals

No descubro ningún secreto cuando digo que a los verdaderos amigos y compañeros se les conoce en los momentos difíciles. Es en tales situaciones cuando de verdad puedes calibrar la calidad humana de quienes te rodean día a día y cuánto realmente te aprecian.


Durante el pasado mes de noviembre la vida me puso en una situación así. Y ahora que todo ha pasado, quisiera agradecer aquí públicamente a mis compañeros de Plain Concepts, que han estado a una altura inmensa: desde las constantes muestras de solidaridad hasta el acomodo voluntario de mis tareas en sus ya apretadas agendas para que yo pudiera estar con mi familia, me he sentido arropado por ellos en todo momento.


Thank you, my friends!


P.S. Hago extensivo este agradecimiento a Paco Marín, Marino Posadas, José M. Alarcón, Miguel Katrib, Ian Marteens y muchos otros amigos que han estado en contacto con nosotros a lo largo de estos días.

LINQ es mucho más que LINQ to SQL

Uno de los “mind stoppers” con los que me encuentro con más frecuencia durante las charlas sobre LINQ es la idea preconcebida de que al hablar de LINQ se está hablando única y exclusivamente de una tecnología para acceder a bases de datos relacionales “encapsulando” la generación de las sentencias SQL. Tales opiniones frecuentemente equiparan LINQ como un todo con un mapeador objeto-relacional (ORM) como nHibernate o IdeaBlade DevForce, por solo mencionar algunos de los más conocidos.


Como intento demostrar en mi libro, esto *NO* es así. En primer lugar, aunque menos relevante dado que las expresiones de consulta de C# y VB en el fondo son mero “azúcar sintáctico” construido alrededor de llamadas a métodos extensores predefinidos en los proveedores, está el hecho de que, al estar soportado directamente en los lenguajes, LINQ ofrece un nivel de “inmersión” superior al que puede lograrse mediante el uso exclusivo de librerías.


En segundo lugar, y lo fundamental, LINQ es una tecnología genérica para acceder a cualquier almacén de datos que pueda verse como una secuencia o conjunto de secuencias de elementos de un cierto tipo: arrays, colecciones, documentos XML, DataSets o bases de datos relacionales son algunos ejemplos de las posibles fuentes LINQ para los que .NET 3.5 ofrece soporte predefinido; al ser también LINQ una tecnología abierta, es posible agregar ese soporte para fuentes no soportadas de manera predefinida: proveedores para sistemas de ficheros, ficheros binarios, tuberías (pipes) o bases de datos de información de proyectos en TFS son algunos de los ejemplos que se desarrollan en el libro. En general, como dijo Dinesh Kulkarni, precisamente Program Manager de LINQ to SQL, pronto tendremos hasta “LINQ to CoffeeMachine”: habrá proveedores LINQ para acceder a las más disímiles fuentes de datos.


En ese contexto, y con la práctica continuada, iremos avanzando hasta alcanzar lo que yo llamo el “nirvana LINQ”: el momento en que los programadores reconozcan al momento la posibilidad de utilizar una consulta integrada en el lenguaje para representar casi cualquier bucle o iteración en general que incluya selección, proyección, ordenación o agrupación, entre otras operaciones.


LINQ to SQL y el futuro LINQ to Entities son única y exclusivamente dos aplicaciones más de esa tecnología genérica; dos muy importantes, indudablemente, pero que no pueden ni deben “opacar” a las demás: LINQ, como Talonotel, es mucho más.