Czy Linq ma oszałamiający wpływ na programistów .NET?

Wielu z nas zaczęło widzieć to zjawisko w jQuery około rok temu, kiedy ludzie zaczęli pytać, jak zrobić absolutnie szalone rzeczy, takie jak odzyskiwanie ciągu zapytania za pomocą jQuery . Różnica między biblioteką (jQuery) a językiem (JavaScript) jest najwyraźniej zatracona przez wielu programistów i skutkuje tym, że tam, gdzie nie jest to konieczne, powstaje wiele nieodpowiedniego, skomplikowanego kodu.

Może to tylko moja wyobraźnia, ale przysięgam, że zaczynam dostrzegać wzrost liczby pytań, w których ludzie proszą o zrobienie podobnie szalonych rzeczy z Linq, takich jak znajdowanie zakresów w posortowanej tablicy . Nie mogę się pogodzić z tym, jak całkowicie niewłaściwe są rozszerzenia Linq do rozwiązania tego problemu, ale co ważniejsze, fakt, że autor po prostu założył, że idealne rozwiązanie wymagałoby Linq bez myślenia o tym (o ile wiem). Wygląda na to, że powtarzamy historię, tworząc nową generację programistów .NET, którzy nie potrafią odróżnić języka (C # / VB.NET) od biblioteki (Linq).

Co jest odpowiedzialne za to zjawisko? Czy to tylko szum? Tendencje sroka? Czy Linq zyskał reputację jako forma magii, w której zamiast pisać kod, wystarczy wypowiedzieć właściwą inkantację? Nie jestem zadowolony z tych wyjaśnień, ale tak naprawdę nie mogę wymyślić nic innego.

Co ważniejsze, czy to naprawdę problem, a jeśli tak, jaki jest najlepszy sposób, aby pomóc oświecić te osoby?

Dzieje się tak, ponieważ programowanie jest zasadniczo trudne. Wymaga dużo logicznej, ustrukturyzowanej myśli w taki sposób, że wiele osób po prostu nie wie, jak to zrobić. (Lub po prostu nie da rady, w zależności od tego, kogo słuchasz).

Rzeczy takie jak LINQ i jQuery znacznie ułatwiają niektóre typowe zadania związane z manipulowaniem danymi. To wspaniałe dla tych z nas, którzy wiedzą, co robimy, ale niefortunnym efektem ubocznym jest to, że obniża pasek. Ułatwia to osobom, które nie mają pojęcia, co robią, aby zacząć pisać kod i sprawić, by wszystko działało. A kiedy wpadną w rzeczywistość i znajdą coś fundamentalnie trudnego, na co nie pasują ich proste techniki na wysokim poziomie abstrakcji, gubią się, ponieważ nie rozumieją platformy, na której zbudowana jest ich biblioteka.

Twoje pytanie jest trochę na właściwej drodze, ale podobnie jak odwieczna kontrowersja dotycząca brutalnych gier wideo „zmieniających dzieci w przemoc”, ma kierunek odsyłacza do tyłu. Proste techniki programowania nie powodują, że programiści są głupi; po prostu przyciągają głupców do programowania. I naprawdę niewiele można na to poradzić.

Dla mnie to nowe zjawisko związane z zabawkami. Wydaje się coś nowego (LINQ), a teraz każdy programista chce się tym bawić.

Widzą LINQ jako młotek, a każdy problem to gwóźdź. Kogo to obchodzi, jeśli łatwiej jest to zrobić w inny sposób? LINQ musi być odpowiedzią! Tak jak wtedy, gdy wszyscy używali XML do WSZYSTKIEGO! Plik konfiguracyjny? XML. Przechowywanie danych? XML. Itd itd

Myślę, że LINQ oferuje naprawdę dobrą okazję w języku C # w rozwiązywaniu problemów przy użyciu bardziej funkcjonalnego podejścia. Nie powinniśmy odrzucać nowego stylu rozwiązywania problemów tylko dlatego, że mamy już coś, co działa.

Wychodząc z dużego tła SQL, lubię mieć możliwość korzystania z logiki opartej na zestawie w moim C #, aby lepiej opisać cel moich operacji.

To mówi; kontekst jest królem i wszystko może być nadużywane.

LINQ i jQuery to najnowsze „zabawki”, a programiści uwielbiają pokazywać, jak mogą robić rzeczy przy użyciu najnowszych rzeczy.

Jeśli właściwie używasz Linq i rozumiesz to pod maską, znajdziesz wiele nowych, najnowocześniejszych technik programowania.

Jeśli więc głęboko zastanawiasz się nad ulepszeniami, twierdzę, że dzięki temu jesteś lepszym programistą. To, czy dany programista faktycznie to robi, czy nie, nie jest winą Linq.

Ten sam argument można wysunąć dla odwzorowań obiektowo-relacyjnych. Czy ktoś naprawdę pisze już surowe zapytania SQL względem tabel bazy danych? :)

Niektóre z tych szalonych rzeczy są spowodowane tym, że ludzie używają niewłaściwego młotka, inni dlatego, że budują naprawdę elegancki super młot, ale natrafili na dziwny szczegół, który należy pokonać.

Na przykład, jeśli pojawi się pytanie o użycie linq do wygenerowania dynamicznego linq do użycia przeciwko niedynamicznemu linq dziewięć razy na dziesięć, osoba jest albo ciekawa, czy to możliwe, albo szczeka na niewłaściwe drzewo, ale jest kilka rzeczy, które możesz rozwiązać w ten sposób, które są trudne do tego stopnia, że ​​nierozsądne jest rozwiązanie w inny sposób.

Takie pytania zadaję w dwóch częściach:

1. czy można to zrobić, a jeśli tak, to jak by to wyglądało
2. czy należy to zrobić, czy istnieje ryzyko lub lepsza alternatywa

Przekonałem się, że prawie zawsze robię je w tej kolejności. Odpowiada na pytanie, a także pomaga w lepszym wyjaśnieniu potencjalnych alternatyw.

Nie wiem o jakimkolwiek odrętwiającym wpływie na umysły programistów, ale spójrz tutaj na wpływ zdezorientowanych narzędzi / języków na stawki. Mów o obniżeniu poprzeczki!

Zgadzam się z Masonem Wheelerem. Jednak próba rozwiązania https://stackoverflow.com/questions/3762202/get-range-of-integers-with-linq nie jest wcale szalona, działając na „sekwencji”. Problem polega na tym, że iteratory Java i .Net nie obsługują wszystkich 3 operacji: bieżącej wartości, następnej wartości i przejścia do następnej. Clojure może zrobić wszystkie 3 i podejrzewam, że w Clojure łatwiej to zrobić poprawnie. Python ma również wspólne procedury i chcę spróbować to złamać. http://clojure.org/sequences http://www.try-clojure.org/

W rzeczywistości, jeśli wejście jest sekwencją nieskończoną, taką jak http://oeis.org/A007401 , wtedy leniwy jest jedynym sposobem.