Otra seta, perdón, libro sobre LINQ

Cuando comparo este libro con una seta (y la seta sale ganando al final) no es sólo por la capacidad de propagación por esporas de los libros sobre LINQ sino, principalmente, por su potencial alucinógeno. Leo un par de páginas y alucino. Luego viene la resaca. Pasa un par de horas y siento el mono de volver a comprobar cuán malo es el libro. Y así, entre risas y risas, me lo he leído. Pero las setas tienen fibra y son buenas para el colon.

Vale, me he pasado. Si a usted le cuesta leer en pantalla, este libro puede sustituir a la ayuda en línea, siempre que renuncie al índice, a las búsquedas y a ese estilo seco de los documentos de Microsoft que tanto gusta a los amantes del dolor. De todos modos, supongo que tengo que justificarme. Ahí va eso...

El principal problema de (joder, qué pedazo de título)... bueno, de este título, es la bisoñez del autor, acompañada de un exceso de entusiasmo, buenrrollismo y grandes dosis de soberbia injustificada. Este es un libro de apenas 380 páginas, con los típicos listados sin abreviar y con un tipo de letra más grande que la del texto. A pesar de todo esto, el autor se permite escribir un ditirambo de cuarenta páginas en honor a los ORM... demostrando de paso que no tiene ni pajolera idea del asunto. Ahí va un sabroso "tip" (página 5):

Note: Writing stored procedures does not equate to bad design. On the contrary, stored procedures if managed correctly are an excellent alternative to dynamic SQL. If you use a code generator to create your CRUD stored procedures, or if you develop them by hand and have good oversight, in many cases you will be able to use them in conjunction with an ORM tool.

¡Gracias, gran Vijay (así se llama el pavo), por perdonar nuestras viles existencias! Pero siento interrumpir: usted, ¿ha entendido algo? ¿Son buenos o no los procedimientos almacenados? ¿Sólo si se escriben a mano, o si los crea una herramienta? Ah, ¿en ambos casos? Entonces, ¿para qué mencionar que mañana lloverá o no? El problema está en que el Gran Vijay "sabe" que los procedimientos almacenados sólo son buenos si sirven a los propósitos del Gran ORM. Pero soltar tal chorrada es peligroso. Te puede enemistar con esa bestia cejijunta del DBA (en cristiano, el Administrador de Bases de Datos). Los DBA's, cuando se enfadan, te dejan sin índices secundarios y te echan sal en el café.

"Claro, Marteens, cabronazo, pero nos has ocultado el contexto de la parida". Bien aquí tiene el contexto: el señor Mehta nos explica que la compañía X ha escrito software para un fabricante de comida para perros. ¿Y sabe qué?, pues que usaron procedimientos almacenados. La cosa se les escapa de las manos (claro, porque son unos pecadores relacionales). Y de repente, llega la gran oportunidad: pueden vender la aplicación a un fabricante de comida para gatos. Aquí viene la Segunda Parida:

With the increased development costs, Company X won't be making enough money to justify this deal [...] so they hire a consulting company to help reduce their overhead.

Vijay, hermanito, que nunca se te ocurra montar una empresa con los ahorros de papá, que te los vas a fundir. La consultoría, evidentemente, les endiña un ORM a la Compañía X, y según palabrita del niño Vijay, (they) optimize and normalize the company database. Lamento señalar que:

• Lo de "optimizar y normalizar" suele resultar bastante costoso. Es como empezar de cero. Para que resulte viable, es obligatorio que la consultoría subcontrate programadores en algún país remoto del Tercer Mundo. Quizás los tiros vayan por ahí.
• Ah, de repente la base de datos carece de "normalización". ¿Esa es una consecuencia de utilizar procedimientos almacenados?

Pero la diversión continúa:

Company X is able to eliminate the thousands of stored procedures (que ya funcionaban) and instead use "automagic" mapping features to generate its SQL. Development costs go down, profits go up and everyone is happy [...]

... especialmente el niño Vijay, que ya tiene el ejemplo canónico que siempre se escribe en los primeros capítulos. Menos mal que enseguida nos aclara que "this is an oversimplified example". Menos mal. Porque cuando la magia entra por la puerta, la inteligencia salta corriendo por la ventana.

Vale, reconozco que los escritores solemos rellenar los primeros capítulos con la misma alegría con la que los chinos echaban melamina en la leche para bebés. El problema es que los problemas continúan a lo largo del libro... excepto en las páginas que contienen información irrelevante, o en las que se limitan a tirar de la ayuda. Para no hacer esta masacre demasiado larga, aquí tiene un botón de muestra, sumamente divertido y revelador. El hermanito Vijay intenta explicarnos por qué prefiere no usar var para declarar variables locales con tipo implícito (p. 149):

The reason to be explicit with the types is the same reason that you strongly type variables in the world of software development: to make it easier to understand and gain a negligible performance increase.

Las negritas son mías, por supuesto: resulta que este señor no comprende un sencillísimo truco del lenguaje en que programa, y sin embargo, le recomienda pasar a un sistema que exige un conocimiento en profundidad de ese mismo lenguaje y de su modelo de objetos.

Claro, que si usted se siente molesto conmigo puede dar ejemplo de solidaridad y comprarse el engendro. Pero recuerde que, cada vez que alguien compra un libro malo, el Diablo aparece y mata un cachorrito.

---

La verdad es que me extrañó un poco el ejemplo de la comida para perros. Pero luego recordé que son los musulmanes quienes consideran que el perro es un animal impuro. Los hindúes, en realidad... bueno, no recuerdo si los consideran seres divinos o si se los comen.

Hat tip to Alfredo Novoa: se casan con ellos.