Vi un comentario / comentario donde decía algo, en relación con LINQ / lambda, en la siguiente línea: "Escriba un código legible para los humanos, en lugar de legible para su computadora".
Creo que esta declaración tiene muchos méritos, sin embargo, considere al desarrollador (como yo) que ha estado en toda la gama de lenguajes de desarrollo desde Assembly, pasando por procedimientos, pasando por OO, pasando por gestionado, aprovechando el alto rendimiento. soluciones paralelas de tareas.
Me enorgullezco de hacer que mi código sea tan legible y reutilizable como sea posible y de adoptar muchos de los principios de diseño de GOF para ofrecer sistemas y servicios de calidad de producción en una gran cantidad de sectores empresariales dispares.
La primera vez que encontré la expresión lambda pensé: "¡¿Qué demonios es eso ?!" Inmediatamente fue contraintuitivo para mi sintaxis declarativa explícita familiar (y, por lo tanto, cómoda). El más joven < 5 años en el trabajo ¡los muchachos, sin embargo, lo tomaron como si fuera el maná del cielo!
Esto se debe a que, durante años, pensar como una computadora (en el sentido sintáctico) se tradujo muy fácilmente en sintaxis de codificación directa (independientemente del idioma). Cuando ha tenido esa mentalidad computacional por más de 20 años (30+ en mi caso), debe apreciar que el shock inicial sintáctico de la expresión lambda puede traducirse fácilmente en miedo y desconfianza.
¿Quizás el compañero de trabajo en el OP tenía antecedentes similares a los míos (es decir, he estado alrededor del bloque unas cuantas veces) y era contraintuitivo para ellos en ese momento? Mi pregunta es: ¿qué hiciste al respecto? ¿Intentó volver a educar a sus compañeros para que comprendieran los beneficios de la sintaxis en línea o los impidió o no para "estar en el programa"? El primero probablemente hubiera visto a tu compañero de trabajo llegar a tu línea de pensamiento, el último probablemente haría que desconfiaran aún más de la sintaxis de LINQ / lambda y, por lo tanto, exacerbando la opinión negativa.
Para mí, tuve que volver a educar mi propia forma de pensar (como dice Eric, no es un cambio de mentalidad insignificante, y tuve que programar en Miranda en los años 80, así que tuve mi parte de funcional experiencia de programación) pero una vez que pasé por ese dolor, los beneficios fueron obvios pero, lo que es más importante, donde se usó en exceso (es decir, se usó para usarlo), sobre complejo y repetitivo (considerando el principio DRY en esa instancia).
Como alguien que no solo escribe muchos códigos, sino que también tiene que revisarlos técnicamente, era imperativo que entendiera estos principios para poder revisar los elementos de manera imparcial, informar dónde podría ser el uso de una expresión lambda más eficiente / legible, y también para que los desarrolladores consideren la legibilidad de expresiones lambda en línea altamente complejas (donde una llamada de método haría que el código sea más legible, mantenible y extensible).
Entonces, cuando alguien dice que "no se hacen lambda?" o la sintaxis de LINQ, en lugar de calificarlos de luddite para ayudarlos a comprender los principios subyacentes. Después de todo, pueden tener antecedentes de "vieja escuela" como yo.