O uso das expressões LINQ e Lambda leva a um código menos legível? [fechadas]

Estou tendo uma discussão com um colega de trabalho no Linq, vou copiar aqui:

Colega de trabalho: Vamos ser honestos aqui. A sintaxe do Linq é uma porcaria. É confuso e não intuitivo.

Eu: ah, vamos lá, mais confuso que o T-SQL?

Colega de trabalho: sim.

Eu: possui as mesmas partes básicas, selecione, onde e de

Colega de trabalho: Linq, para mim, é uma bastardização do relacional + OO. Colega de trabalho: Não me interpretem mal - é incrivelmente poderoso, mas eles redirecionaram o SQL para usar novamente coleções de objetos.

Sou da opinião de que o uso do Linq + Lamda é muito poderoso (ele concorda) e também facilita a leitura do código (ele discorda nesse ponto):

pickFiles = from f in pickFolder.GetFiles("*.txt")
where ValidAuditFileName.IsMatch(f.Name)
select f;

ou

var existing = from s in ActiveRecordLinq.AsQueryable<ScannedEntity>()
where s.FileName == f.FullName && s.DocumentType != "Unknown"
select s;

ou (código VB aqui)

   Dim notVerified = From image In images.AsParallel
     Group Join verifyFile In verifyFolder.GetFiles("*.vfy").AsParallel.Where(
      Function(v) v.Length > 0
      ).AsParallel
   On image.Name.Replace(image.Extension, ".vfy") Equals verifyFile.Name
     Into verifyList = Group
    From verify In verifyList.DefaultIfEmpty
    Where verify Is Nothing
    Select verify

Para mim, isso é limpo e fácil (pelo menos mais fácil do que as alternativas) de ler, quais são suas opiniões sobre isso?

Não consigo mais encontrar o post certo, mas Eric Lippert (e possivelmente vários outros softies) opinaram em várias ocasiões sobre como o Linq é declarativo , o que, para várias classes de problemas, é muito mais intuitivo do que a sintaxe imperativa .

O Linq permite escrever código que expressa a intenção , não o mecanismo .

Você me diz o que é mais fácil de ler. Este:

IEnumerable<Customer> GetVipCustomers(IEnumerable<Customer> source)
{
    List<Customer> results = new List<Customer>();
    foreach (Customer c in source)
    {
        if (c.FirstName == "Aaron")
        {
            results.Add(c);
        }
    }
    results.Sort(new LastNameComparer());
    return results;
}

class LastNameComparer : IComparer<Customer>
{
    public int Compare(Customer a, Customer b)
    {
        return x.LastName.CompareTo(b.LastName);
    }
}

Ou isto?

IEnumerable<Customer> GetVipCustomers(IEnumerable<Customer> source)
{
    return from c in source
           where c.FirstName == "Aaron"
           orderby c.LastName
           select c;
}

Ou até isso?

IEnumerable<Customer> GetVipCustomers(IEnumerable<Customer> source)
{
    return source.Where(c => c.FirstName == "Aaron").OrderBy(c => c.LastName);
}

O primeiro exemplo é apenas um monte de clichê inútil para obter os resultados mais simples. Qualquer um que pense que é mais legível do que as versões do Linq precisa ser examinado. Não apenas isso, mas o primeiro desperdiça memória. Você não pode nem escrever usando yield returnpor causa da classificação.

Seu colega de trabalho pode dizer o que ele quer; pessoalmente, acho que o Linq melhorou imensamente minha legibilidade de código.

Também não há nada "relacional" no Linq. Pode ter algumas semelhanças superficiais com o SQL, mas não tenta, de forma alguma, implementar o cálculo relacional. São apenas várias extensões que facilitam a consulta e o projeto de seqüências. "Consulta" não significa "relacional" e, de fato, existem vários bancos de dados não relacionais que usam sintaxe semelhante ao SQL. O Linq é puramente orientado a objetos, por acaso trabalha com bancos de dados relacionais por meio de estruturas como Linq para SQL por causa de algum vodu da árvore de expressão e design inteligente da equipe C #, tornando funções anônimas implicitamente conversíveis em árvores de expressão.

Colega de trabalho: Vamos ser honestos aqui. A sintaxe do Linq é uma porcaria. É confuso e não intuitivo.

Você não pode argumentar com essa crítica. Para o seu colega de trabalho, é uma merda . Falhamos em projetar uma sintaxe que, para eles, era clara e intuitiva. Essa é a nossa falha, e você pode passar minhas desculpas ao seu colega de trabalho. Fico feliz em receber sugestões sobre como torná-lo melhor; o que especificamente seu colega de trabalho considera confuso ou pouco intuitivo?

No entanto, você não pode agradar a todos. Minha opinião pessoal, e a opinião da maioria das pessoas com quem conversei sobre o assunto, é que a sintaxe de compreensão da consulta é muito mais clara que a sintaxe imperativa equivalente. Claramente, nem todos concordam, mas felizmente não exigimos consenso de todos os milhões de nossos clientes quando fazemos o design de idiomas.

No entanto, sobre o que é "intuitivo", lembro-me da história do lingüista inglês que estudou muitas línguas diferentes e finalmente concluí que o inglês era o melhor de todos os idiomas porque, em inglês, as palavras vêm na mesma ordem em que você pense neles . Ao contrário do francês, onde eles estão constantemente dizendo coisas como "o cachorro branco come a carne vermelha". Quão difícil deve ser para os franceses pensarem as palavras na ordem correta e depois as dizerem na ordem francesa ! Francês é tão pouco intuitivo! É incrível que os franceses consigam falar. E alemão? onde eles pensam "o cachorro come a carne", mas depois tem que dizer "o cachorro a carne come"!?!

Frequentemente, o que é "intuitivo" é apenas uma questão de familiaridade. Levei meses trabalhando com o LINQ antes de eu parar de iniciar minhas consultas com a cláusula "select". Agora é uma segunda natureza, e a ordem SQL parece bizarra.

Qual é! As regras de escopo estão todas bagunçadas no SQL. Algo que você pode apontar para seu colega de trabalho é que o LINQ foi cuidadosamente projetado para que (1) a introdução de variáveis ​​e escopos aconteça da esquerda para a direita (*) e (2) a ordem em que a consulta aparece na página é a ordem em que é executada. Ou seja, quando você diz

from c in customers where c.City == "London" select c.Name

o c aparece no escopo à esquerda e permanece no escopo à direita. E a ordem na qual as coisas acontecem são: os primeiros "clientes" são avaliados. Em seguida, o "onde" é avaliado para filtrar a sequência. Em seguida, a sequência filtrada é projetada pelo "select".

SQL não tem essa propriedade. Se você diz

SELECT Name FROM Customers WHERE City = 'London'

então "Nome" é trazido ao escopo por algo à sua direita, não à sua esquerda, e a consulta é executada em uma ordem completamente confusa; a cláusula do meio é avaliada primeiro, depois a última e depois a primeira. Isso agora parece louco e pouco intuitivo para mim, tendo trabalhado apenas com o LINQ por tanto tempo.

(*) As regras de escopo são um pouco estranhas no LINQ com cláusulas de junção. Mas, além disso, os escopos se encaixam bem.

Como qualquer outra coisa no mundo da programação, você precisa se acostumar com a sintaxe e, então, é (potencialmente) mais fácil de ler.

Como qualquer outra coisa no mundo da programação, existe o potencial para código de espaguete ou outros abusos.

Como qualquer outra coisa no mundo da programação, você pode fazer dessa maneira ou de outra maneira.

Como qualquer outra coisa no mundo da programação, sua milhagem pode variar.

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.

As expressões Lambda levam a um código menos legível se as consultas forem muito longas. No entanto, é muito melhor do que muitos loops aninhados .

É melhor com uma mistura dos dois .

Escreva no Lambda se for mais rápido (você precisa ser rápido) ou mais fácil de ler.

Eu acho que depende, na maioria dos casos (exceto quando se faz algo muito bizarro), se você quer dizer "legível" como alguém tendo a idéia do que está acontecendo ou se pode encontrar facilmente todos os pequenos detalhes.

Acho que o link ajuda com o primeiro, mas muitas vezes (principalmente na depuração) prejudica o segundo.

IMHO, quando eu estou olhando para o código, eu não estou familiarizado com o primeiro, é imensamente mais importante que o último, então eu o acho muito mais legível.

Acho a sintaxe do LINQ intuitiva e fácil de ler, principalmente porque eles colocam o FROM no início, onde ele pertence, em vez de no meio, como no SQL. Mas as lambdas da OMI são confusas e dificultam a leitura do código.

Concordo com você que a sintaxe do Linq não é significativamente diferente do T-SQL. Eu acho que seu colega de trabalho pode realmente estar se opondo a coisas relacionais se misturando em seu código OO agradável e brilhante. Por outro lado, a programação funcional leva um pouco de tempo para se acostumar e uma disposição para se acostumar.

Depende. Obviamente, o T-SQL fornece exclusivamente algumas soluções relacionais de banco de dados. Obviamente, o LINQ fornece exclusivamente algumas soluções OO.

Contudo; "mais confuso que T-SQL?" - é discutido / solicitado na pergunta inicial. Isso implica claramente alguns recursos que nenhuma das respostas existentes aborda, acusando o crítico (obviamente familiarizado com o SQL) de ficar preso no passado.

Portanto, embora eu aprecie o LINQ por certas qualidades e não discorde muito das respostas existentes aqui, sinto que o contraponto merece representação:

Anos depois de me familiarizar com o LINQ, executar certos tipos de operações de grupo, junções externas e não equivalentes, trabalhar com chaves compostas e outras operações no LINQ ainda me fazem estremecer. (Especialmente ao direcionar um back-end relacional com perguntas sensíveis ao desempenho.)

from c in categories
join p in products on c equals p.Category into ps
from p in ps.DefaultIfEmpty()

Se você acha que é intuitivo, mais poder para você. ;)

Provavelmente existe uma razão pela qual o Linq é péssimo, apenas tente fazer exemplos do mundo real, em vez desses exemplos de livros didáticos.

tente mostrar essa função em linqlamdathings e verá que toda a beleza se foi, enquanto a maneira clássica permanece legível. Sem mencionar problemas de execução adiados e configuração de pontos de interrupção.

A verdade é que LinqLambda é muito útil em alguns casos e não se pensa que substitua toda a orientação bacana que você nunca entendeu

    public IList<Customer> GetVipCustomers(IList<Customer> source, int maxCount)
    {
        var results = new SortedList<string,Customer>();

        foreach (Customer c in source)
        {
            if (maxCount == results.Count)
                break;

            if (c.IsVip && c.FirstName== "Aaron" || c.SecondName== "Aaron")
                results.Add(c.LastName, c);
        }

        return results.Values;
    }