Linq a-t-il un effet hallucinant sur les programmeurs .NET?

36

Beaucoup d'entre nous ont commencé à voir ce phénomène avec jQuery il y a environ un an lorsque des gens ont commencé à demander comment faire des choses complètement folles, telles que récupérer la chaîne de requête avec jQuery . La différence entre la bibliothèque (jQuery) et le langage (JavaScript) est apparemment perdue pour de nombreux programmeurs, ce qui entraîne l'écriture de nombreux codes inappropriés et compliqués là où ils ne sont pas nécessaires.

C’est peut-être juste mon imagination, mais je jure que je commence à voir une légère augmentation du nombre de questions où les gens demandent à faire des choses aussi folles avec Linq, comme trouver des plages dans un tableau trié . Je ne peux pas comprendre à quel point les extensions Linq sont tout à fait inappropriées pour résoudre ce problème, mais plus important encore, le fait que l'auteur présume que la solution idéale impliquerait Linq sans y penser réellement (pour autant que je sache). Il semble que nous répétions l’histoire, en créant une nouvelle génération de programmeurs .NET qui ne peuvent pas faire la différence entre le langage (C # / VB.NET) et la bibliothèque (Linq).

Qu'est-ce qui est responsable de ce phénomène? Est-ce juste un battage publicitaire? Tendances Magpie? Linq a-t-il acquis une réputation de magie dans laquelle, au lieu d'écrire du code, il suffit de prononcer la bonne incantation? Je suis à peine satisfait de ces explications, mais je ne peux pas penser à autre chose.

Plus important encore, s'agit-il vraiment d'un problème et, dans l'affirmative, quel est le meilleur moyen d'aider à éclairer ces personnes?

programming-practices .net

— Aaronaught
source

6

+1 pour "supposé que la solution idéale impliquerait Linq sans y penser réellement". C'est vraiment au-delà de moi.

— Jaco Pretorius

1

Linq is slow ...

2

@Pierre: Sur quelle base faites-vous cette réclamation?

— Aaronaught

5

@Mason: C'est un repère absolument horrible écrit par quelqu'un qui ne sait clairement pas ce qu'il fait. Analyse comparative dans les tiques? Notation hongroise? Et la version Linq ne fait même pas la même chose, elle essaie d'itérer chaque résultat au lieu de s'arrêter au premier. Sans parler du fait que la prémisse dans son ensemble est stupide, comme cela a été discuté de manière concidente dans la question brûlante d’aujourd’hui .

— Aaronaught

3

Et, accessoirement, @Mason, Linq intègre de nombreuses optimisations. Pour presque toutes les méthodes pouvant être optimisées, il recherche tout d'abord une interface prenant en charge la méthode optimisée. Pour d'autres méthodes basées sur des ensembles, comme les équijoins, elle crée des tables de hachage. Cela n'optimise pas votre code pour vous, mais ne le ralentira pas non plus; la plupart des ralentissements réels documentés sont dus à des lambdas / fermetures indépendantes de Linq.

— Aaronaught

52

C'est essentiellement parce que la programmation est fondamentalement difficile. Cela nécessite beaucoup de réflexion logique et structurée d'une manière que beaucoup de gens ne savent tout simplement pas faire. (Ou tout simplement ne peut pas faire, en fonction de qui vous écoutez.)

Des choses comme LINQ et jQuery facilitent beaucoup certaines tâches courantes de manipulation de données. C’est formidable pour ceux d’entre nous qui savent ce que nous faisons, mais l’effet secondaire regrettable est que cela abaisse la barre. Cela facilite la tâche aux personnes qui n'ont aucune idée de ce qu'elles font pour commencer à écrire du code et faire fonctionner les choses. Et ensuite, quand ils se rendent compte de la réalité et trouvent quelque chose de fondamentalement difficile pour lequel leurs techniques simples de niveau d'abstraction élevé ne sont pas bien adaptées, ils sont perdus, car ils ne comprennent pas la plate-forme sur laquelle leur bibliothèque est construite.

Votre question est en quelque sorte sur la bonne voie, mais un peu comme la controverse éternelle sur les jeux vidéo violents "qui transforment les enfants en violence", le sens du lien est inversé. Les techniques de programmation faciles ne rendent pas les programmeurs stupides; ils attirent simplement des personnes stupides à la programmation. Et vous ne pouvez vraiment rien faire à ce sujet.

— Maçon Wheeler
source

30

+1 pour "Les techniques de programmation simples ne rendent pas les programmeurs stupides; elles attirent simplement des personnes stupides vers la programmation".

— Steven Evers

1

Un grand avantage de LINQ est qu'il me permet de prototyper une solution dans une approche fonctionnelle. Ensuite, une fois que j'ai une solution sans bug, je peux l’utiliser comme banc d’essai pour une version impérative optimisée. Si la tâche est assez simple, comme appliquer un seul filtre, je ne vais même pas m'embêter.

— ChaosPandion

5

Je doute toujours que LINQ attire des programmeurs incompétents - d'après ce que j'ai vu, il semble que ce soit l'un des concepts les plus difficiles à comprendre pour les débutants - mais cela semble être la meilleure réponse à ce jour.

— Aaronaught

1

Vous devriez mettre un copyright sur cette dernière phrase. Bien dit, monsieur.

— AJ Johnson

1

Drôle. Pour moi, LINQ n'est pas un concept particulièrement facile à maîtriser. Si vous faites quelque chose de subtil, très rapidement, vous devez cesser de penser au volant et commencer à comprendre la transmission. Je te regarde, lamdas!

— Brian MacKay

13

Pour moi, c'est le nouveau phénomène du jouet. Quelque chose de nouveau est sorti (LINQ) et maintenant chaque développeur veut jouer avec.

Ils considèrent LINQ comme un marteau et chaque problème est un clou. Qui se soucie s'il est plus simple de le faire autrement? LINQ doit être la réponse! Comme quand tout le monde utilisait XML pour TOUT! Fichier de configuration? XML. Stocker des données? XML. Etc

— PSU_Kardi
source

5

Ne pas vouloir lancer un débat XML ici, mais il convient de souligner que XML est réellement bon dans ces deux domaines. Ce n'est pas toujours optimal - si les fichiers de configuration n'ont pas besoin d'être structurés, les KVP sont préférables, et si la compatibilité entre applications n'est pas une exigence, un format binaire est nettement préférable pour le stockage / la sérialisation. Mais je ne pense pas que XML soit un si bon exemple, car il avait tendance à se retrouver utilisé dans des domaines où il était simplement sous-optimal, par opposition à totalement inapproprié.

— Aaronaught

4

+1: Il vaut la peine d'étirer vos outils pour voir combien de problèmes peuvent être réduits à la forme d'un clou lorsque vous apprenez une technologie.

— Steven Evers

+1: D'autres exemples de ce type de marteau magique sont jQuery (comme mentionné dans la question) et les expressions régulières. Non pas que ces choses soient mauvaises, en fait elles sont vraiment utiles, mais elles ne sont pas la réponse à tout.

— Tim Goodman

14

Je pense que le "LINQ est un marteau et que chaque problème est un clou", l'analogie le pousse un peu trop loin. Je dirais que LINQ est un si bon marteau que lorsqu'une grande partie de votre travail implique des clous, vous pouvez vous enfoncer dans un sillon et ne pas vous rendre compte que vous avez enfoncé une vis. Même si vous n'êtes pas un mauvais programmeur.

— Carson63000

@Aaronaught: Par ailleurs, l'utilisation de XML avec des noms de champs longs me semblait sous-optimale pour la transmission de données via des liaisons radio à faible bande passante et non entièrement fiables. Là encore, c'est aussi ce que j'ai pensé de la conception de la base de données sur ce produit.

— David Thornley

10

Je pense que LINQ offre une très bonne opportunité en C # de résoudre des problèmes en utilisant une approche plus fonctionnelle. Nous ne devrions pas rejeter un nouveau style de résolution de problèmes simplement parce que nous avons déjà quelque chose qui fonctionne.

Venant d'un contexte SQL chargé, j'aime bien avoir la possibilité d'utiliser une logique basée sur les ensembles dans mon C # pour mieux décrire le but de mes opérations.

Cela dit; le contexte est roi et tout peut être surutilisé.

— DOTJOSH
source

Qui est en train de congédier? J'utilise Linq tout le temps, je m'inquiète seulement du nombre d'incidents de personnes l'utilisant (ou tentant de l'utiliser) pour des problèmes clairement itératifs et non basés sur des ensembles.

— Aaronaught

Je suis très habitué à essayer de résoudre des problèmes nécessitant une écriture en SQL et à utiliser une logique basée sur des ensembles plutôt que des curseurs. Il y aura toujours des abus d’outil, mais au moins, s’ils écrivent un code LINQ médiocre au lieu d’un code procédural médiocre, une version ultérieure de .NET sera plus facilement au moins en mesure de le paralléliser.

— dotjosh

2

LINQ et jQuery sont les derniers "jouets" et les développeurs aiment montrer comment ils peuvent faire des choses en utilisant les dernières nouveautés.

— Dan Diplo
source

Je suis d'accord avec cette affirmation. Je ne suis pas sûr que cela explique ce phénomène particulier. Les personnes qui posent ces questions ne semblent pas vraiment être du genre à montrer - bien que cela aiderait à expliquer pourquoi d'autres programmeurs tentent de répondre aux questions telles qu'elles sont posées au lieu de préconiser une approche plus saine.

— Aaronaught

@Aaronaught - Ouais, je suppose que je réfléchissais davantage à la raison pour laquelle les gens répondent aux questions en utilisant cette approche.

— Dan Diplo

2

Si vous utilisez correctement Linq et le comprenez sous le capot, vous découvrirez toutes sortes de nouvelles techniques de programmation de pointe.

Donc, si vous réfléchissez profondément aux améliorations, je soutiens que cela fait de vous un meilleur programmeur. Que ce soit ou non un programmeur, ce n’est pas la faute de Linq.

Le même argument peut être fait pour les mappeurs relation-objet. Est-ce que quelqu'un écrit réellement des requêtes SQL brutes sur des tables de base de données? :)

— Robert Harvey
source

10

Hé, j'écris du SQL brut ... sniff

— Aaronaught le

2

Le SQL brut est le meilleur choix si vous savez ce que vous faites.

— Fosco

1

+1 pour l'argument "fait de toi un meilleur programmeur". La compréhension de linq et plus particulièrement des méthodes qui l’utilisent a définitivement amélioré ma compréhension de certains concepts de programmation très utiles.

— John M Gant le

1

Je pense que quelqu'un s'offusqua du commentaire ORM par rapport au commentaire SQL brut. Ce n'était pas moi J'utilise les deux et j'ai compris que la remarque était ironique.

— Aaronaught

1

Je ne ferais jamais confiance à mes requêtes de base de données complexes à la merde qu'un ORM écrit: c'est bien pour des choses simples, mais beurk pour signaler des requêtes de type. Encore une fois, entre les mains de quelqu'un qui sait ce qu'il fait ORM est une bonne chose, entre les mains de quelqu'un qui est trop paresseux pour comprendre des bases de données, le désastre à venir.

— HLGEM

1

Certaines de ces choses insensées sont dues au fait que les gens utilisent le mauvais marteau, d’autres parce qu’elles construisent un super-marteau très élégant, mais elles ont rencontré un détail insolite qui doit être surmonté.

Par exemple, si vous voyez une question sur l'utilisation de linq pour générer linq dynamique à utiliser contre linq non dynamique neuf fois sur dix, la personne est simplement curieuse de savoir si cela est possible ou aboie le mauvais arbre, mais il existe quelques Ce que vous pouvez résoudre de cette manière est difficile au point de devenir déraisonnable autrement.

Je prends ce genre de questions en deux parties:

peut-il être fait, et si oui à quoi ressemblerait-il
devrait-il être fait, y a-t-il un risque ou une meilleure alternative?

J'ai constaté que je les fais presque toujours dans cet ordre. Il répond à la question et vous aide également à mieux expliquer les alternatives potentielles.

— Facture
source

0

Je ne connais aucun effet anormal sur les esprits des développeurs, mais jetez un coup d'œil ici à l'effet des outils / langages insensés sur les taux. Parlez de baisser la barre!

— Pete Wilson
source

0

Je suis d'accord avec Mason Wheeler. Cependant, il n'est pas complètement fou d'essayer de résoudre https://stackoverflow.com/questions/3762202/get-range-of-integers-with-linq en opérant sur une "séquence". Le problème est que les itérateurs de Java et .Net ne prennent pas en charge les 3 opérations: valeur actuelle, valeur suivante et passage à la suivante. Clojure peut faire les 3, et je soupçonne qu’il est plus facile de le faire correctement. Python a également des co-routines, et je veux essayer de résoudre ce problème. http://clojure.org/sequences http://www.try-clojure.org/

En fait, si l'entrée est une séquence infinie, telle que http://oeis.org/A007401 , alors paresseux est le seul moyen.

— Emploi
source

"Linq" ne signifie pas nécessairement "itérateurs", ni "paresseux" - en fait, la plupart des Linq sont en réalité des arbres d'expression. Vous pouvez facilement, si vous le souhaitez, implémenter votre propre agrégat à 3 valeurs ou à N valeurs avec une fermeture et pas beaucoup de code en C #. Le problème survient lorsque les gens ne savent pas comment faire cela, ou même comment s'y prendre, et cherchent simplement une incantation magique qui vit dans l' System.Linqespace de noms.

— Aaronaught

@Aaronaught ... '' '"Linq" ne signifie pas "itérateurs" ni "paresseux" nécessairement' '' - eh bien, Linq peut ressembler à SQL, mais ce sucre syntaxique est compilé en un code IL réel, qui, s'il est décompilé , ressemblerait à un groupe de IEnumerable [<T>] connectés ensemble. Ce genre de choses est paresseux et utilise des énumérateurs, qui dans d'autres langues s'appelleraient des itérateurs. Mais oui, le problème, c’est que LINQ facilite le codage et l’essaye sans réserve. Certains pourraient encore devenir des programmeurs décents peut-être. Si C # est leur langue maternelle et qu'ils sont totalement noobs, ils ont affaire à une langue large.

— Job

Bien sûr, Linq to Objects (et non Linq to SQL, Linq to Entities, Linq to DataSet ou toute autre branche de Linq) est basé sur des itérateurs et une exécution différée, mais tout est sous le capot. Les blocs d'Iterator et la yielddéclaration existaient avant Linq, tout comme les délégués. Les fermetures ont été publiées dans la même version que Linq, mais peu d’opérations "Linq" pures nécessitent en réalité une capture de variable locale. Demander "Comment puis-je faire [description d'opération / fonction entièrement itérative] avec Linq?" trahit une profonde ignorance à la fois de Linq lui-même (ce qu'il est censé faire) et de la langue elle-même.

— Aaronaught