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.


 

Octavio Hernandez

Desarrollador y consultor en tecnologías .NET. Microsoft C# MVP entre 2004 y 2010.

9 comentarios en “La relación entre LINQ y Don Knuth

  1. Buenas Octavio,

    Estas discusiones siempre nos las hemos encontrado en nuestro trabajo diario, DataSets Tipados Vs Clases, DataAdapter Vs DataReader,etc.

    No nos sirven las mismas soluciones para todo, como dijo Unai en una charlas “Cuando tienes un martillo todo parecen clavos”.

    Hay que utilizar cada solución de la manera adecuada y siempre que sea necesario.

    Pero bueno que te voy a contar 😉

    Haber cuando tengo la suerte de asistir a otra charla tuya.

    Saludos y Felices Fiestas.

  2. ¡Hola, Espinete!

    No me llames señor, yo no mando ni en mi casa 🙂

    Lo que describo es algo que me ocurre con bastante frecuencia, no me dirijo aquí a nadie en concreto.

    Sí que trataré de escribir sobre el rendimiento de LINQ to SQL, aquí o en la segunda edición de mi libro (http://www.campusmvp.com/CampusMVP/C_Sharp_3.0_y_LINQ.htm)… De momento, los enlaces que recomendó Juan Carlos González (http://geeks.ms/blogs/ciin/archive/2007/12/17/linqpad-191-adios-a-sql-server-management-studio-creo-que-no-pero.aspx) son muy buenos.

    Mira también el post de Rodrigo sobre cómo la elección de la arquitectura de las aplicaciones muy frecuentemente determina el rendimiento (http://geeks.ms/blogs/rcorral/archive/2007/12/22/un-enfoque-225-gil-para-la-optimizaci-243-n.aspx). Pienso que ese post (más orientado al “programming-in-the-large”) se complementa con el mío, más orientado al “programming-in-the-small”.

    Saludos – Octavio

  3. Hola Octavio,

    Eso de dejar las optimizaciones para el final está muy bien, pero siempre que luego se pueda optimizar. Mejor aun sería que el sistema se optimizase él solo. Pero LinQ to Objects es tan simple y rígido que ni una cosa ni la otra. Si quieres optimizar tendrías que dejar de usarlo.

    A lo mejor en muchos casos no importa que las cosas vayan 30 veces más lentas, pero como producto LinQ es una cosa muy cutre.

    Otra cosas que no hay que confundir es la optimización temprana con una buena arquitectura. Con una buena arquitectura las cosas pueden ir muy rápido desde el principio y puede que nunca sea necesario optimizar. Con una mala arquitectura por mucho que optimices irá lento igual.

    Saludos

  4. Hola Octavio,

    Ante todo, debo reconocer que me gusta mas la idea de trabajar con objetos de dominio – que es la idea que esta impulsando LINQ – que con un tipo específico, llamese DataSet Tipeado, DataSet o RecordSet para aquellos que tienen mas de una decada en esto. :).

    Mi pregunta es muy sencilla ¿Que fecha de caducidad tiene LINQ? Cada dos o tres años MS cambia “su manera” de acceder a datos (DAO, ADO, ADO.NET, LINQ y quien sabe como se llamara la próxima)

    ¿cuanto tiempo – y dinero – hubieramos ahorrado en formación? ¿no crees que sería mas rentable tener nuestra manera de acceder a datos, de llenar las entidades, de ordenarlas, y de enlazarlas a los controles que estar cambiando cada x tiempo? Que cambie un control lo puedo entender – incluso entiendo el cambio que representa WPF – pero que cambie tanto algo básico como el acceso a datos no lo entiendo.

    Por otro lado tu hablas de “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.” ¿no crees que ese temor esta bien fundado? Para mi más que un temor es una realidad ¿o no has visto el pedazo de UPDATE que te genera un TableAdapter, por dar un ejemplo? El que se quema con leche, cuando ve la vaca, llora. Ademas ¿Crees que es tan dificil – o friki – hacer un template de una sentencia update y reusarlo? Si no recuerdo mal, ese template ya te lo da el SQL Server 2005.

    Creo que no sufro “el síndrome de la obsesión por el rendimiento” o que me deje la vida en esto. Yo no se si LINQ es 3 o 30 veces mas lento que trabajar con tus propias queries como menciona Alfredo. Lo que sí se es que no me gusta que me vendan motos. Ese es mi problema. Que me digan que las expresiones Lamba se discontinuan en VB5 porque son malas malisimas y me lo colocan 10 años después. O que me digan que con .Net 1.0 todos las variables seran tipeadas, que eso del variant en VB6 es malo malisimo, que el que usa variant es que no sabe trabajar con programación orientada a objetos y con clases abstractas, y ahora – a la tercera version del mismo producto – me vengan con un tipo var.

    Saludos.

  5. Alfredo,

    >> como producto LinQ es una cosa muy cutre.

    ¿Qué puedo responder a eso? La única posible respuesta que me dejas es que debo ser un ignorante, no he visto otras cosas mejores y por eso LINQ me parece tan gran asunto… (porque no creo que alguien piense en la variante “malévola” de que sé que es malo, pero alguien me paga para que diga que es bueno. Fíjate lo que te digo – ojalá fuera así: iría a ver a mi madre tres veces al año en vez de una vez cada tres años. Pero no lo es).

    Si sigo con tantas ganas lo de LINQ, pienso que ante todo se debe a que llevo 25 años siguiendo el trabajo de ese genio (en mi opinión, claro) que es Anders Hejlsberg.

    LINQ probablemente no sea la solución definitiva, pero yo pienso que es un paso en el camino correcto. Como siempre, el tiempo pondrá todo en su lugar.

    Saludos – Octavio

  6. Hola, Daniel!

    >> …me gusta mas la idea de trabajar con objetos de dominio…

    A mí también: es más orientado a objetos y se presta muchísimo mejor para el modelado conceptual. Para mí, todo lo que sea elevar el nivel de abstracción de la programación y acercarla a los conceptos del dominio del problema que se modela es positivo.

    >> ¿Qué fecha de caducidad tiene LINQ?

    Bueno, yo no trabajo en MS, pero estoy seguro de que Hejlsberg y compañía han intentado hacer “something that would last” (“algo que dure” – esta frase la he “robado” de una canción de uno de mis grupos favoritos – KANSAS).

    Yo seriamente no creo que el cambio en la manera de acceder a datos sea por vender la moto. Simplemente, la nuestra es una ciencia joven, en plena efervescencia, y este proceso es parte de la “búsqueda de la verdad”, en la que quién mejor que ellos, que tienen a muchos científicos de enorme relieve trabajando allí (el desaparecido Jim Gray, especialista en bases de datos y premio Turing de Informática -que te digan lo que te digan, no se lo dan a cualquiera- trabajaba allí), para enfrascarse.

    Las razones por las que creo que LINQ ha llegado para quedarse las he expuesto en veinte lugares: porque está integrado en el propio lenguaje, porque es un mecanismo uniforme y abierto para acceder a todo tipo de fuentes de datos, entre otras. Que se puede mejorar – seguramente. Pero una vez que termine la estandarización ECMA de C# 3.0, no habrá quien pueda “desacoplar” las consultas integradas del lenguaje C#.

    En cualquier caso, como le decía a Alfredo, el tiempo pone todo en su lugar.

    Ojo, que yo no propugno dejar ipso facto todo lo que tenemos ahora y lanzarse a desarrollar aplicaciones de bases de datos con LINQ to SQL (que solo vale para SQL Server). ADO.NET 3.5 solo estará completo dentro de unos meses, cuando salga el Entity Framework, y probablemente lo mejor sea esperar a que eso ocurra para empezar a desarrollar las *NUEVAS* aplicaciones de bases de datos…

    Eso sí, creo que desde ya hay que irse preparando, porque allí LINQ también jugará un papel esencial, y porque creo *HONESTAMENTE* que las consultas integradas han llegado para quedarse para siempre. Con mi libro traté de escribir sobre los *FUNDAMENTOS GENERALES* en los que se apoya LINQ. A LINQ to SQL se le dedica solo el Capítulo 14, unas 25 páginas, porque no habría estado completo sin eso.

    >> ¿No has visto el pedazo de UPDATE que te genera un TableAdapter?

    Si la tabla tiene 50 campos, el UPDATE será enorme en cualquier caso… Aunque en principio nada difícil de entender si conoces la sintaxis de SQL y lo que son los parámetros de una sentencia. Las que general LINQ to SQL son parecidas.

    En cualquiera de los dos casos, para mí lo importante creo que es que esas sentencias se generan automáticamente, ¡NO LAS TIENE QUE ESCRIBIR UNO!

    >> El variant en VB6 es malo malisimo … y ahora me vengan con un tipo var.

    ¡Cuidado! ¡La palabra ‘var’ de C# no tiene nada que ver con el tipado dinámico (que es de lo que iba el Variant de VB6)! Echale un vistazo a este excelente post de J.M. Aguilar en este mismo sitio:

    geeks.ms/…/variables-locales-implic-237-tamente-tipadas-en-c.aspx

    Saludos – Octavio

  7. Octavio,

    Puedes probar a leer el Tercer Manifiesto o a mirar el lenguaje D4, y seguro que después LinQ te parecerá una porquería. Ni siquiera tiene instrucciones de actualización y LinQ to Objects no optimiza nada, es ingenuo a tope. Cuanto de más alto nivel es un lenguaje, más sofisticado tiene que ser el optimizador para no perder mucha velocidad, y aquí nada de nada.

    LinQ es un paso tan torcido que no se muy bien si se acerca o se aleja.

  8. Octavio,

    Jim Gray era conocido por decir enormes barbaridades sobre bases de datos. Era un buen ejemplo de hiperespecialización. Sabía mucho de transacciones basadas en bloqueos, pero ni idea de casi todo lo demás.

    El tiempo pone a todo en su sitio, pero en informática suele tardar demasiado. Cuando eso pase como mínimo estaremos todos jubilados.

  9. Alfredo,

    a) Ante todo, mis discupas por la respuesta anterior, creo que me pasé un poco. Tú en el fondo solo pusiste tu opinión.

    b) Estuve mirando D4 hace unos meses, precisamente recomendado por tí, pero…honestamente, no es lo mío. D4 indudablemente está muy bien, pero *no* me parece un lenguaje de propósito general, lo que *sí* creo que sigue siendo C# después de LINQ.
    Por cierto, cuando visité la Web de alphora me llamó la atención que hacía más de un año que no la actualizaban. Y ahora ha desaparecido completamente. Aunque ya sé (en general estoy de acuerdo) que nuchas veces lo más avanzado no triunfa comercialmente.
    Estaría muy bien poder preguntarle a Hejlsberg si conoce sobre D4 y otros lenguajes de la familia…

    c) De Gray mejor no hablar, EPD.

    d) Me parece que la informática se desarrolla a una velocidad tal, que seguro veremos en qué termina todo esto.

    Slds – Octavio

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *