O Linq está tendo um efeito entorpecedor nos programadores .NET?


36

Muitos de nós começaram a ver esse fenômeno com o jQuery cerca de um ano atrás, quando as pessoas começaram a perguntar como fazer coisas absolutamente insanas, como recuperar a string de consulta com o jQuery . A diferença entre a biblioteca (jQuery) e a linguagem (JavaScript) aparentemente está perdida em muitos programadores e resulta em muitos códigos complicados e inapropriados sendo gravados onde não é necessário.

Talvez seja apenas minha imaginação, mas juro que estou começando a ver um aumento no número de perguntas em que as pessoas estão pedindo para fazer coisas igualmente insanas com o Linq, como encontrar intervalos em uma matriz classificada . Não consigo entender o quão inadequadas são as extensões do Linq para resolver esse problema, mas o mais importante é o fato de o autor simplesmente assumir que a solução ideal envolveria o Linq sem realmente pensar nisso (tanto quanto eu posso dizer). Parece que estamos repetindo a história, criando uma nova geração de programadores .NET que não sabem a diferença entre a linguagem (C # / VB.NET) e a biblioteca (Linq).

O que é responsável por esse fenômeno? É apenas hype? Tendências de pega? O Linq adquiriu uma reputação como uma forma de mágica, onde, em vez de realmente escrever o código, você apenas precisa pronunciar o encantamento certo? Não estou satisfeito com essas explicações, mas não consigo pensar em mais nada.

Mais importante, é realmente um problema e, em caso afirmativo, qual é a melhor maneira de ajudar a esclarecer essas pessoas?


6
+1 em "assumiu que a solução ideal envolveria o Linq sem realmente pensar nisso". Está realmente além de mim.
Jaco Pretorius

1
Linq é lento ...

2
@ Pierre: Com que base você faz essa afirmação?
Aaronaught 21/09/10

5
@Mason: Essa é uma referência absolutamente horrível, escrita por alguém que claramente não sabe o que está fazendo. Benchmarking em carrapatos? Notação húngara? E a versão Linq nem faz a mesma coisa, tenta iterar todos os resultados em vez de parar no primeiro. Para não mencionar, toda a premissa é boba, como foi discutido acidentalmente na pergunta quente de hoje .
Aaronaught

3
E, a propósito, @Mason, o Linq tem muitas otimizações integradas. Para quase qualquer método capaz de ser otimizado, ele primeiro procura uma interface que suporte o método otimizado. Para outros métodos baseados em conjuntos, como equijoins, ele cria tabelas de hash. Ele não otimiza seu código para você, mas também não torna seu código mais lento; a maioria das desacelerações reais documentadas no mundo real se deve a lambdas / fechamentos independentes do Linq.
Aaronaught 22/09/10

Respostas:


52

É basicamente porque a programação é fundamentalmente difícil. Exige muito pensamento lógico e estruturado de uma maneira que muitas pessoas simplesmente não sabem como fazer. (Ou simplesmente não pode fazer, dependendo de quem você ouve.)

Coisas como LINQ e jQuery tornam muito mais fáceis certas tarefas comuns de manipulação de dados. Isso é ótimo para quem sabe o que está fazendo, mas o efeito colateral lamentável é que ele diminui a fasquia. Isso torna mais fácil para as pessoas que não têm idéia do que estão fazendo começar a escrever código e fazer as coisas funcionarem. E então, quando eles se tornam realidade e descobrem algo fundamentalmente difícil para o qual suas técnicas simples e de alto nível de abstração não são adequadas, elas se perdem, porque não entendem a plataforma em que sua biblioteca é construída.

Sua pergunta está no caminho certo, mas muito parecida com a controvérsia perene sobre videogames violentos "que tornam crianças violentas", ela tem a direção do link para trás. Técnicas de programação fáceis não tornam os programadores estúpidos; eles apenas atraem pessoas estúpidas para a programação. E realmente não há muito que você possa fazer sobre isso.


30
+1 para "Técnicas fáceis de programação não tornam os programadores estúpidos; eles apenas atraem pessoas estúpidas para a programação".
Steven Evers

1
Uma grande coisa sobre o LINQ é que me permite criar um protótipo de uma solução em uma abordagem funcional. Então, quando tiver uma solução sem erros, posso usá-la como um banco de testes para obter uma versão imperativa otimizada. Se a tarefa for simples o suficiente, como aplicar um único filtro, eu nem vou me incomodar.
ChaosPandion

5
Ainda estou duvidando que o LINQ atraia programadores incompetentes - pelo que vi, parece ser um dos conceitos mais difíceis para os novatos entenderem -, mas esta parece ser a melhor resposta até agora.
Aaronaught

1
Você deve colocar um copyright nessa última frase. Bem dito, senhor.
AJ Johnson

1
Engraçado. Para mim, o LINQ não é um conceito particularmente fácil de dominar. Se você estiver fazendo algo de sutileza, muito rapidamente precisará parar de pensar no volante e começar a entender a transmissão. Eu estou olhando para você lamdas!
precisa

13

Para mim, é o novo fenômeno do brinquedo. Algo novo sai (LINQ) e agora todo desenvolvedor quer brincar com ele.

Eles vêem o LINQ como um martelo e todo problema é um prego. Quem se importa se é mais simples fazê-lo de outra maneira? LINQ deve ser a resposta! Como quando todo mundo estava usando XML para TUDO! Arquivo de configuração? XML. Armazenando dados? XML. Etc etc


5
Não querendo iniciar um debate sobre XML aqui, mas vale ressaltar que o XML é realmente bom nessas duas coisas. Nem sempre é ideal - se os arquivos de configuração não precisam ser estruturados, os KVPs são melhores e, se a compatibilidade entre aplicativos não for um requisito, um formato binário é claramente melhor para armazenamento / serialização. Mas não acho que o XML seja um exemplo tão bom, porque costumava ser usado em áreas onde era meramente subótimo, em vez de totalmente inapropriado.
Aaronaught 21/09/10

4
+1: vale a pena esticar suas ferramentas para ver quantos problemas podem ter o formato de uma unha quando você está aprendendo uma tecnologia.
Steven Evers

+1: Outros exemplos desse tipo de martelo mágico são jQuery (como mencionado na pergunta) e expressões regulares. Não que essas coisas sejam ruins, na verdade elas são realmente úteis, mas não são a resposta para tudo.
Tim Goodman

14
Eu acho que a analogia "LINQ é um martelo e todo problema é um prego" está levando isso um pouco longe demais. Eu diria que o LINQ é um martelo tão bom que, quando uma grande parte do seu trabalho envolve pregos, você pode entrar em uma ranhura e não perceber que acabou de martelar um parafuso. Mesmo se você não for um programador ruim.
Carson63000

@Aaronaught: Por outro lado, o uso de XML com nomes de campos longos parecia subótimo para transmissão de dados por meio de links de rádio de baixa largura de banda e não totalmente confiáveis. Por outro lado, também foi o que pensei no design do banco de dados nesse produto.
David Thornley

10

Eu acho que o LINQ oferece uma oportunidade muito boa em C # na solução de problemas usando uma abordagem mais funcional. Não devemos descartar um novo estilo de solução de problemas apenas porque já temos algo que funciona.

Vindo de um background SQL pesado, gosto de ter a opção de usar lógica baseada em conjunto no meu C # para descrever melhor a intenção de minhas operações.

Dito isto; o contexto é rei e tudo pode ser usado em excesso.


Quem está demitindo? Eu uso o Linq o tempo todo, apenas me preocupo com o número de incidências que vejo de pessoas que o usam (ou tentam usá-lo) para problemas que são claramente iterativos e não baseados em conjuntos.
Aaronaught

Estou muito acostumado a tentar resolver problemas que precisam ser escritos em SQL e usar a lógica baseada em conjunto em vez de cursores para fazer isso. O abuso de ferramentas sempre acontecerá, mas acho que pelo menos se eles escreverem código LINQ ruim em vez de código processual ruim, uma versão subsequente do .NET será mais facilmente capaz de paralelizar isso.
dotjosh 21/09/10

2

LINQ e jQuery são os mais recentes "brinquedos" e os desenvolvedores adoram mostrar como eles podem fazer coisas usando as coisas mais recentes.


Eu concordo com essa afirmação. Não tenho tanta certeza se isso explica esse fenômeno em particular. As pessoas que fazem essas perguntas não parecem realmente os tipos de demonstração - embora ajudasse a explicar por que outros programadores tentam responder às perguntas conforme as perguntas, em vez de defender uma abordagem mais sadia.
Aaronaught 21/09/10

@Aaronaught - Sim, acho que estava pensando mais sobre por que as pessoas respondem com as perguntas usando essa abordagem.
Dan Diplo

2

Se você usar o Linq corretamente e entendê-lo sob o capô, encontrará todos os tipos de novas técnicas de programação de ponta.

Portanto, se você pensar profundamente sobre as melhorias, eu argumento que isso o torna um programador melhor. Se um determinado programador realmente faz isso ou não, não é culpa do Linq.

O mesmo argumento pode ser feito para os mapeadores objeto-relacionais. Alguém realmente escreve consultas SQL brutas em tabelas de banco de dados? :)


10
Hey, eu escrevo SQL cru ... farejar
Aaronaught

2
O SQL bruto é a melhor aposta se você souber o que está fazendo.
Fosco

1
+1 no argumento "faz de você um programador melhor". Compreender o linq e especialmente os métodos que o suportam definitivamente melhoraram minha compreensão de alguns conceitos de programação muito úteis.
John M Gant

1
Eu acho que alguém se ofendeu com o comentário ORM vs. SQL bruto. Não fui eu; Eu uso os dois, e entendi o comentário como sendo irônico.
Aaronaught 21/09/10

1
Eu nunca confiaria em minhas consultas complexas ao banco de dados com a porcaria que um ORM escreve. É bom para coisas simples, mas ugh para consultas de tipo de relatório. Novamente, nas mãos de alguém que sabe o que está fazendo ORM é uma coisa boa, nas mãos de alguém com preguiça de entender bancos de dados, desastre à frente.
HLGEM

1

Algumas dessas coisas insanas são porque as pessoas estão usando o martelo errado, outras são porque estão construindo um super-martelo realmente elegante, mas encontraram um detalhe esquisito que precisa ser superado.

Por exemplo, se você vir uma pergunta sobre o uso do linq para gerar o linq dinâmico para usar contra o linq não dinâmico, nove em cada dez vezes, a pessoa ficará curiosa se for possível ou latirá na árvore errada, mas há algumas coisas que você pode resolver dessa maneira que são difíceis a ponto de irracionais de resolver de outra forma.

Eu tomo esse tipo de pergunta em duas partes:

  1. Isso pode ser feito? Se sim, como seria?
  2. caso isso seja feito, existe um risco ou uma alternativa melhor

Descobri que quase sempre os faço nessa ordem. Ele responde à pergunta e também ajuda a explicar melhor possíveis alternativas.


0

Eu não conheço nenhum efeito entorpecedor na mente dos desenvolvedores, mas dê uma olhada aqui para ver o efeito de ferramentas / linguagens insensatas nas taxas. Fale sobre como baixar a barra!


0

Eu concordo com Mason Wheeler. No entanto, não é totalmente louco tentar resolver https://stackoverflow.com/questions/3762202/get-range-of-integers-with-linq operando em uma "sequência". O problema é que os iteradores de Java e .Net não suportam todas as três operações: valor atual, próximo valor e passam para a próxima. O Clojure pode fazer todos os 3, e suspeito que no Clojure seja mais fácil fazer isso da maneira certa. Python também tem co-rotinas, e eu quero tentar decifrar isso. http://clojure.org/sequences http://www.try-clojure.org/

De fato, se a entrada for uma sequência infinita, como http://oeis.org/A007401 , a preguiça é a única maneira.


"Linq" não significa "iteradores" nem "preguiçoso" necessariamente - na verdade, a maioria do Linq é realmente sobre árvores de expressão. Você poderia facilmente, se quisesse, implementar seu próprio agregado de 3 ou N valores com um fechamento e não muito código em C #. O problema surge quando as pessoas não têm idéia de como realmente fazer isso, ou mesmo como começar, e estão apenas procurando por um encantamento mágico que mora no System.Linqespaço para nome.
Aaronaught

@Aaronaught ... '' '"Linq" não significa "iteradores" nem "preguiçosos" necessariamente' '' - bem, o Linq pode se parecer com SQL, mas esse açúcar sintático é compilado em um código IL real que, se descompilado , seria equivalente a um monte de IEnumerable [<T>] s conectados juntos. Esse material é lento e usa enumeradores, que em outros idiomas seriam chamados iteradores. Mas sim, o problema é que o LINQ facilita a codificação e os não qualificados a experimentam. Alguns ainda podem se tornar programadores decentes, talvez. Se C # é o primeiro idioma e eles são noobs totais, eles estão lidando com um idioma grande.
Job

Claro, o Linq to Objects (não o Linq to SQL, o Linq to Entities, o Linq to DataSet ou qualquer outra ramificação do Linq) é baseado em iteradores e execução adiada, mas isso é tudo que está por trás. Os blocos do iterador e a yieldinstrução existiam antes do Linq, assim como os delegados. Os fechamentos vieram no mesmo release do Linq, mas poucas operações "Linq" puras realmente exigem captura de variável local. Perguntando "Como posso fazer [descrição da operação / função totalmente iterativa] com o Linq?" trai uma profunda ignorância tanto do próprio Linq (o que ele deve fazer) quanto da própria linguagem.
Aaronaught
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.