Linq sta avendo un effetto strabiliante sui programmatori .NET?

Molti di noi hanno iniziato a vedere questo fenomeno con jQuery circa un anno fa, quando le persone hanno iniziato a chiedere come fare cose assolutamente folli come recuperare la stringa di query con jQuery . La differenza tra la libreria (jQuery) e il linguaggio (JavaScript) è apparentemente persa su molti programmatori e si traduce in un sacco di codice inappropriato e contorto che viene scritto dove non è necessario.

Forse è solo la mia immaginazione, ma giuro che sto iniziando a vedere un aumento del numero di domande in cui le persone chiedono di fare cose altrettanto folli con Linq, come trovare intervalli in un array ordinato . Non riesco a capire quanto siano inopportune le estensioni di Linq per risolvere quel problema, ma soprattutto il fatto che l'autore abbia semplicemente supposto che la soluzione ideale avrebbe coinvolto Linq senza pensarci (per quanto ne so). Sembra che stiamo ripetendo la storia, generando una nuova generazione di programmatori .NET che non sanno distinguere tra il linguaggio (C # / VB.NET) e la libreria (Linq).

Qual è il responsabile di questo fenomeno? È solo hype? Tendenze gazza? Linq ha guadagnato una reputazione come una forma di magia, dove invece di scrivere effettivamente il codice devi solo pronunciare l'incantesimo giusto? Non sono soddisfatto di queste spiegazioni, ma non riesco davvero a pensare ad altro.

Ancora più importante, è davvero un problema e, in tal caso, qual è il modo migliore per aiutare a illuminare queste persone?

È fondamentalmente perché la programmazione è fondamentalmente difficile. Richiede un sacco di pensiero logico e strutturato in un modo che molte persone semplicemente non sanno come fare. (O semplicemente non puoi farlo, a seconda di chi ascolti.)

Cose come LINQ e jQuery rendono molto più semplici alcune attività comuni di manipolazione dei dati. È fantastico per quelli di noi che sanno cosa stiamo facendo, ma lo sfortunato effetto collaterale è che abbassa la barra. Rende più facile per le persone che non hanno idea di quello che stanno facendo iniziare a scrivere codice e far funzionare le cose. E poi quando si imbattono nella realtà e trovano qualcosa di fondamentalmente difficile a cui le loro tecniche semplici e di alto livello di astrazione non sono adatte, si perdono, perché non capiscono la piattaforma su cui è costruita la loro biblioteca.

La tua domanda è un po 'sulla buona strada, ma proprio come la polemica perenne sui videogiochi violenti "che trasformano i bambini violenti", ha la direzione del collegamento all'indietro. Le semplici tecniche di programmazione non rendono stupidi i programmatori; attraggono solo persone stupide alla programmazione. E non c'è davvero molto che puoi fare al riguardo.

Per me è il nuovo fenomeno dei giocattoli. Viene fuori qualcosa di nuovo (LINQ) e ora tutti gli sviluppatori vogliono giocarci.

Vedono LINQ come un martello e ogni problema è un chiodo. A chi importa se è più semplice farlo in un altro modo? LINQ deve essere la risposta! Come quando tutti usavano XML per TUTTO! File di configurazione? XML. Memorizzazione dei dati? XML. Ecc. Ecc

Penso che LINQ offra davvero un'ottima opportunità in C # per risolvere i problemi usando un approccio più funzionale. Non dovremmo respingere un nuovo stile di problem solving solo perché abbiamo già qualcosa che funziona.

Proveniente da un intenso background SQL, mi piace avere la possibilità di utilizzare la logica basata su set nel mio C # per descrivere meglio l'intento delle mie operazioni.

Detto ciò; il contesto è re e tutto può essere abusato.

LINQ e jQuery sono gli ultimi "giocattoli" e gli sviluppatori adorano mostrare come possono fare cose usando le ultime novità.

Se usi Linq correttamente e lo capisci sotto il cofano, troverai ogni sorta di nuove tecniche di programmazione all'avanguardia.

Quindi, se pensi profondamente ai miglioramenti, sostengo che ti rende un programmatore migliore. Che un determinato programmatore lo faccia o meno, non è colpa di Linq.

Lo stesso argomento può essere fatto per i mappatori relazionali di oggetti. Qualcuno scrive davvero query SQL non elaborate su tabelle di database? :)

Alcune di queste cose folli sono perché le persone usano il martello sbagliato, altre perché stanno costruendo un super-martello davvero elegante, ma si sono imbattute in un dettaglio strano che deve essere superato.

Ad esempio, se vedi una domanda sull'utilizzo di linq per generare linq dinamico da usare contro linq non dinamico nove volte su dieci, la persona è o semplicemente curiosa di sapere se è possibile, o abbaia l'albero sbagliato, ma ci sono alcuni cose che puoi risolvere in questo modo che sono difficili al punto da irragionevole da risolvere altrimenti.

Prendo questo tipo di domande in due parti:

1. può essere fatto, e in tal caso come sarebbe
2. in caso affermativo, esiste un rischio o un'alternativa migliore

Ho scoperto che li faccio quasi sempre in quell'ordine. Risponde alla domanda e ti aiuta anche a fare una spiegazione migliore per potenziali alternative.

Non conosco alcun effetto paralizzante sulle menti degli sviluppatori, ma dai un'occhiata qui per l'effetto di strumenti / linguaggi intorpiditi sulle tariffe. Parla di abbassare la barra!

Sono d'accordo con Mason Wheeler. Tuttavia, non è del tutto folle cercare di risolvere https://stackoverflow.com/questions/3762202/get-range-of-integers-with-linq operando su una "sequenza". Il problema è che gli iteratori di Java e .Net non supportano tutte e 3 le operazioni: valore corrente, valore successivo e passaggio a successivo. Clojure può fare tutti e 3, e sospetto che in Clojure sia più facile farlo bene. Python ha anche delle routine condivise e voglio provare a risolverlo. http://clojure.org/sequences http://www.try-clojure.org/

In effetti, se l'input è una sequenza infinita, come http://oeis.org/A007401 , allora pigro è l'unico modo.