Linq tem um efeito entorpecedor em programadores .NET?

35

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

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

O que é responsável por esse fenômeno? É apenas hype? Tendências da pega? Linq adquiriu uma reputação como uma forma de magia, onde, em vez de escrever código, você tem que proferir o encantamento certo? Eu dificilmente 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?

    
por Aaronaught 21.09.2010 / 19:42
fonte

8 respostas

51

É basicamente porque a programação é fundamentalmente difícil. Requer muito pensamento lógico e estruturado de uma forma 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 certas tarefas comuns de manipulação de dados muito mais fáceis. Isso é ótimo para aqueles de nós que sabem o que estamos fazendo, mas o efeito colateral é que ele diminui o nível. Isso torna mais fácil para as pessoas que não têm idéia do que estão fazendo para começar a escrever códigos e fazer as coisas funcionarem. E então, quando se deparam com a realidade e encontram algo fundamentalmente difícil que suas técnicas simples, de alto nível de abstração, não são adequadas, estão perdidas, porque não entendem a plataforma sobre a qual sua biblioteca é construída. / p>

Sua pergunta está no caminho certo, mas muito parecida com a controvérsia perene sobre videogames violentos "transformando as crianças em violentos", 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 não há muito que você possa fazer sobre isso.

    
por 21.09.2010 / 20:01
fonte
13

Para mim, é o novo fenômeno dos brinquedos. 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 fazer isso 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

    
por 21.09.2010 / 20:03
fonte
10

Acho que o LINQ oferece uma boa oportunidade em C # para resolver problemas usando uma abordagem mais funcional. Não devemos descartar um novo estilo de resolução de problemas só porque já temos algo que funciona.

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

Dito isto; o contexto é rei, e qualquer coisa pode ser usada em excesso.

    
por 21.09.2010 / 20:25
fonte
2

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

    
por 21.09.2010 / 21:15
fonte
2

Se você usar o Linq corretamente, e entender o assunto, você encontrará todos os tipos de novas técnicas de programação de ponta.

Então, se você pensar profundamente sobre os aprimoramentos, eu argumento que isso faz de você 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 mapeadores relacionais de objetos. Alguém realmente escreve consultas SQL brutas em tabelas de banco de dados? :)

    
por 21.09.2010 / 20:06
fonte
1

Algumas dessas coisas insanas são porque as pessoas estão usando o martelo errado, outras porque estão construindo um super-martelo realmente elegante, mas elas se deparam com detalhes estranhos que precisam ser superados.

Por exemplo, se você vir uma pergunta sobre o uso do linq para gerar o linq dinâmico para usar o linq não-dinâmico nove vezes em dez, a pessoa ficará curiosa se for possível, ou latindo na árvore errada, mas não são algumas coisas que você pode resolver desta forma que são difíceis ao ponto de não razoável para resolver o contrário.

Eu recebo esse tipo de pergunta em duas partes:

  1. pode ser feito e, em caso afirmativo, qual seria a aparência
  2. deve ser feito, existe um risco ou uma alternativa melhor

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

    
por 21.09.2010 / 23:06
fonte
0

Eu não sei sobre nenhum efeito entorpecente nas mentes dos desenvolvedores, mas dê uma olhada aqui para o efeito de ferramentas / linguagens numble-minded em taxas. Fale sobre abaixar a barra!

    
por 03.05.2011 / 13:27
fonte
0

Concordo com Mason Wheeler. No entanto, não é totalmente louco tentar resolver link operando em uma "sequência". O problema é que os iteradores do Java e do .net não suportam todas as três operações: valor atual, próximo valor e mover para o próximo. Clojure pode fazer todos os 3, e eu suspeito que no Clojure é mais fácil fazer isso direito. Python também tem co-rotinas, e eu quero tentar quebrar isso. link link

De fato, se a entrada for uma sequência infinita, como o link , então a preguiça é o único caminho.

    
por 26.06.2011 / 06:34
fonte