Vi um comentário / observação em que afirmava algo - em relação ao LINQ / lambda - ao longo das linhas de: "Escreva código legível para humanos, em vez de legível para seu computador".
Eu acho que essa afirmação tem muito mérito, no entanto, considere o desenvolvedor (como eu) que passou por toda a gama de linguagens de desenvolvimento do Assembly, do procedural, do OO, do gerenciado, do aproveitamento de soluções paralelas de tarefas de alto rendimento .
Orgulho-me de tornar meu código o mais legível e reutilizável possível e a adoção de muitos dos princípios de padrão de design do GOF, a fim de fornecer sistemas e serviços de qualidade de produção em um amplo número de setores de negócios diferentes.
A primeira vez que encontrei a expressão lambda, pensei: "Que diabos é isso!?!" Foi imediatamente contra-intuitivo para minha sintaxe declarativa explícita familiar (e, portanto, confortável). Os mais jovens <5anos do trabalho, no entanto, fizeram isso como se fosse um maná do céu!
Isso ocorre porque, durante anos, pensando como um computador (no sentido sintático) traduzido com muita facilidade em sintaxe de codificação direta (independentemente do idioma). Quando você tem essa mentalidade computacional há mais de 20 anos (mais de 30 anos no meu caso), é preciso compreender que o choque sintático inicial da expressão lambda pode se traduzir facilmente em medo e desconfiança.
Talvez o colega de trabalho no OP tivesse um histórico semelhante ao meu (isto é, já andei no quarteirão algumas vezes) e tenha sido contra-intuitivo para eles naquele momento? Minha pergunta é: o que você fez sobre isso? Você tentou reeducar seus colegas para entender os benefícios da sintaxe em linha ou os criticou / ostracizou por não "estar no programa"? O primeiro provavelmente teria visto seu colega de trabalho se aproximar de sua linha de pensamento, o último provavelmente os faria desconfiar ainda mais da sintaxe LINQ / lambda, exacerbando a opinião negativa.
Para mim, eu tive que reeducar minha própria maneira de pensar (como Eric deduz acima, não é uma mudança de mente insignificante, e eu tive que programar em Miranda nos anos 80, para ter minha parcela de experiência em programação funcional) mas depois que passei por essa dor, os benefícios foram óbvios, mas - mais importante -, onde seu uso foi superutilizado (isto é, usado para fins de uso), complexo e repetitivo (considerando o princípio DRY nesse caso).
Como alguém que não apenas ainda escreve muito código, mas também precisa revisar tecnicamente muitos códigos, era essencial que eu entendesse esses princípios para poder revisar itens com imparcialidade, aconselhar onde o uso de uma expressão lambda pode ser mais eficiente / legível e também para que os desenvolvedores considerem a legibilidade de expressões lambda inline altamente complexas (onde uma chamada de método tornaria - nesses casos - tornar o código mais legível, sustentável e extensível).
Então, quando alguém diz que "não recebe lambda?" ou sintaxe LINQ, em vez de dar a eles uma tentativa luddita de ajudá-los a entender os princípios subjacentes. Afinal, eles podem ter um histórico da "velha escola" como eu.