Linq, .NET programcıları üzerinde zihin uyuşukluğu yaratıyor mu?


36

Birçoğumuz jQuery ile bu fenomeni görmeye başladık, yaklaşık bir yıl önce insanlar jQuery ile sorgu dizgisini geri almak gibi kesinlikle delice şeyler yapmayı sormaya başladılar . Arasındaki fark kütüphanesinden (jQuery) ve dilin (JavaScript) görünüşe göre pek çok programcılar üzerinde kaybolur ve gerekli olmadığı uygunsuz, dolambaçlı kod bir çok sonuç yazılıyor.

Belki de sadece hayal gücüm, ama yemin ederim, insanların sıralı bir dizideki aralıkları bulmak gibi, Linq ile benzer şekilde çılgınca şeyler yapmak istedikleri soru sayısında sert bir artış görmeye başladım . Linq uzantılarının bu problemi çözmek için ne kadar uygunsuz olduğunu bilemiyorum, ama daha da önemlisi, yazarın ideal çözümün Linq'u gerçekten düşünmeden düşündüğünü söylemek zorunda kalacağını varsaydığı gerçeği . Dili tekrarlıyoruz, dil (C # / VB.NET) ve kütüphane (Linq) arasındaki farkı söyleyemeyen yeni nesil bir .NET programcısı üretiyoruz.

Bu olaydan ne sorumlu? Sadece yutturmaca mı? Saksağan eğilimleri? Linq, bir sihir şekli olarak ün kazandı mı, aslında kod yazmak yerine sadece doğru çıkarımı yapmanız gerekiyor mu? Bu açıklamalardan pek memnun değilim ama gerçekten başka bir şey düşünemiyorum.

Daha da önemlisi, bu gerçekten bir sorun mu ve eğer öyleyse, bu insanları aydınlatmak için en iyi yol nedir?


6
+1, "ideal çözümün gerçekten düşünmeden Linq'i içereceğini varsaydı". Gerçekten benden öte.
Jaco Pretorius

1
Linq yavaş ...

2
@Pierre: Bu iddiayı hangi temelde yapıyorsunuz?
Aaron,

5
@Mason: Bu, ne yaptıklarını açıkça bilen birisinin yazdığı kesinlikle korkunç bir kriter. Kenelerdeki kıyaslama mı? Macar gösterimi? Linq versiyonu da aynı şeyi yapmıyor, ilk başta durmak yerine her bir sonucu yinelemeye çalışıyor. Bahsetmiyorum bile, tüm öncül aptal, bugünün sıcak soruda yanlışlıkla tartışıldığı gibi .
Aaron,

3
Ayrıca, @Mason, tesadüfen yerleşik olarak birçok optimizasyona sahiptir. Optimize edilebilen neredeyse tüm metotlar için, önce optimize edilmiş metodu destekleyen bir arayüz arar. Equijoins gibi diğer set tabanlı yöntemler için, karma tabloları oluşturur. Kodunuzu sizin için optimize etmiyor ancak kodunuzu da yavaşlatmayacak; Gerçek belgelenen gerçek yavaşlamaların çoğu, Linq'den bağımsız olan lambda / kapaklardan kaynaklanmaktadır.
Aaron,

Yanıtlar:


52

Temel olarak programlama temelde zordur. Pek çok insanın nasıl yapılacağını bilmediği bir şekilde çok fazla mantıklı, yapılandırılmış düşünce gerektirir. (Ya basitçe, yapamaz dinlemek kim bağlı.)

LINQ ve jQuery gibi şeyler, bazı genel veri işleme görevlerini çok daha kolay hale getirir. Bu ne yaptığımızı bilenler için harika, ama talihsiz yan etkisi de barı düşürmesi. Kod yazmaya başlamak ve işlerin yürümesini sağlamak için ne yaptıklarını bilemeyen insanlar için kolaylaştırır. Ve sonra gerçekliğe rastladıklarında ve basit, yüksek soyutlama seviyeli tekniklerinin uygun olmadığı, temelden zor bir şey buldukları zaman, kaybedilirler, çünkü kütüphanelerinin üzerine inşa edildiği platformu anlamıyorlar.

Sorunuz biraz doğru yolda, ancak şiddetli video oyunlarının "çocukları şiddetli hale getirme" konusundaki çok uzun süren tartışmalara benziyor. Kolay programlama teknikleri, programcıları aptallaştırmaz; sadece aptal insanları programlamaya çekiyorlar. Ve bu konuda yapabileceğiniz pek bir şey yok.


30
+1 "Kolay programlama teknikleri, programcıları aptallaştırmaz; sadece aptal insanları programlamaya çeker."
Steven Evers

1
LINQ ile ilgili harika bir şey, bir çözümü fonksiyonel bir yaklaşımla prototiplememe izin vermemdir. Sonra bir kez hatasız bir çözüm var sonra optimize bir zorunluluk sürümü için bir test tezgahı olarak kullanabilirsiniz. Görev, tek bir filtre uygulamak gibi yeterince basitse, hiç uğraşmam bile.
ChaosPandion

4
Hala LINQ'nun yetersiz programcıları çektiğinden şüpheliyim - gördüğümden beri , yeni başlayanlar için anlaşılması en zor kavramlardan biri gibi görünüyor - ama bu, şu ana kadarki en iyi cevap gibi görünüyor.
Aaron,

1
Son cümleyle ilgili bir telif hakkı vermelisin. İyi dedin efendim.
AJ Johnson,

1
Komik. Bana göre LINQ ustalaşması kolay bir kavram değil. Eğer herhangi bir şey yapıyorsanız, direksiyon simidini düşünmeyi bırakmanız ve şanzımanı anlamaya başlamanız gerekir. Sana bakıyorum Lamdas!
Brian MacKay

13

Bana göre bu yeni oyuncak olgusu. Yeni bir şey çıkıyor (LINQ) ve şimdi her geliştirici bununla oynamak istiyor.

LINQ'u çekiç olarak görüyorlar ve her sorun bir çivi. Başka bir şekilde yapmanın daha kolay olup olmadığını kim umursar? LINQ cevap olmalı! Herkesin her şeyi için XML kullandığı gibi! Yapılandırma dosyası? XML. Veri depolama? XML. Vesaire vesaire


5
Burada bir XML tartışması başlatmak istememekle birlikte, XML'in bu iki konuda da gerçekten iyi olduğunu belirtmekte fayda var. Her zaman optimum değildir - yapılandırma dosyalarının yapılandırılması gerekmiyorsa, KVP'ler daha iyidir ve çapraz uygulama uyumluluğu bir gereklilik değilse, depolama / seri hale getirme için ikili format açıkça daha iyidir. Ancak XML'in çok iyi bir örnek olduğunu düşünmüyorum, çünkü kendisini tamamen uygunsuzluğa karşılık sadece alt-optimal olduğu alanlarda kullanmaya meyilliydi.
Aaron

3
+1: Bir teknolojiyi öğrenirken ne kadar problemin bir çivinin şekline sokulabileceğini görmek için aletlerinizi gerdirmek önemlidir.
Steven Evers

+1: Bu tür sihirli çekiçlerin diğer örnekleri jQuery (soruda bahsedildiği gibi) ve düzenli ifadelerdir. Bu şeylerin kötü olması değil, aslında çok faydalılar, ancak her şeyin cevabı değiller.
Tim Goodman

13
Bence "LINQ bir çekiç ve her sorun bir çivi" benzetmesi onu biraz fazla zorluyor. LINQ'un çok iyi bir çekiç olduğunu söyleyebilirim , işinizin büyük bir kısmı çivi içerdiğinde, bir yivin içine girebilir ve bir vidaya çarptığınızı fark edemezsiniz. Hatta eğer olmayan kötü bir programcı.
Carson63000

@Aaronaught: Öte yandan, XML'in uzun alan adlarıyla kullanımı düşük bant genişliğine sahip ve tamamen güvenilir olmayan radyo bağlantıları aracılığıyla veri iletimi için bana yetersiz görünüyordu. Sonra tekrar, bu üründe veritabanı tasarımı hakkında düşündüğüm şey de buydu.
David Thornley

10

Bence LINQ daha işlevsel bir yaklaşım kullanarak problem çözmede C # konusunda gerçekten iyi bir fırsat sunuyor. Yeni bir problem çözme biçimini reddetmemeliyiz, çünkü işe yarayan bir şeyimiz var.

Ağır bir SQL arkaplanından geliyorsa, operasyonlarımın amacını daha iyi tanımlamak için C # programımda set tabanlı mantığı kullanma seçeneğine sahip olmayı seviyorum.

Bahsedilen; bağlam kraldır ve her şeyden fazla yararlanılabilir.


Kim kovuyor? Ben her zaman Linq kullanırım, sadece yinelemeli ve ayarlı olmayan problemler için onu kullanan (veya kullanmayı deneyen) insanların gördüğüm olayların sayısı hakkında endişeliyim.
Aaron,

SQL'de yazılması gereken sorunları çözmeye çalışmaya ve imleç yerine set tabanlı mantığı kullanmaya çok alışığım. Aracı kötüye kullanmak her zaman olacaktır, ancak en azından kötü prosedür kodu yerine zayıf LINQ kodu yazarlarsa, .NET'in sonraki bir sürümü daha kolay bir şekilde en azından paralel hale gelebilecek.
dotjosh

2

LINQ ve jQuery en son "oyuncaklar" dır ve geliştiriciler en son şeyi kullanarak işleri nasıl yapabildiklerini göstermeyi severler.


Bu açıklamaya katılıyorum. Bu özel olayı açıklar mı bilmiyorum. Bu soruları soran insanlar gerçekten dezavantajlı türler gibi görünmüyor - bununla birlikte diğer programcıların neden daha mantıklı bir yaklaşımı savunmak yerine sorulan soruları cevaplamaya çalıştıklarını açıklamaya yardımcı olacaktır .
Aaron,

@Aaronaught - Evet, sanırım insanların neden bu yaklaşımı kullanarak sorulara cevap verdiklerini düşünüyordum.
Dan Diplo

2

Linq'i doğru kullanırsanız ve başlık altında anlarsanız, her türlü yeni programlama tekniklerini bulacaksınız .

Bu yüzden, gelişmeler hakkında derin düşünürseniz, bunun sizi daha iyi bir programcı yaptığını savunuyorum. Belirli bir programcının bunu yapıp yapmaması, Linq'in hatası değildir.

Aynı argüman Nesne-İlişkisel Eşleştiriciler için de yapılabilir. Artık kimse gerçekten ham SQL sorgularını veritabanı tablolarına karşı yazıyor mu? :)


9
Hey, ham SQL
yazarım

2
Ham SQL, ne yaptığınızı biliyorsanız en iyi bahis.
Fosco

1
"Seni daha iyi bir programcı yapar" argümanı için +1. Linq'i ve özellikle onu destekleyen yöntemleri anlamak, bazı çok yararlı programlama kavramlarını anlamamı kesinlikle geliştirdi.
John M Gant

1
Birisinin ORM'ye karşı ham SQL yorumuna alındığını düşünüyorum. Ben değildim; Her ikisini de kullanıyorum ve sözlerin yanak dili olduğunu anladım.
Aaron

1
Karmaşık veritabanı sorgularımda bir ORM'nin yazdığı saçmalıklara asla güvenmezdim, Basit şeyler için sorun değil, ancak tip sorguları bildirmek için de ugh. Yine, ne yaptıklarını bilen birinin elinde ORM iyi bir şey, veritabanlarını anlayamayacak kadar tembel olan birinin elinde felakettir.
HLGEM

1

Bu çılgınca şeylerden bazıları, insanların yanlış çekiç kullanması, diğerleri ise gerçekten zarif bir süper çekiç ürettikleri, ancak üstesinden gelinmesi gereken tuhaf bir ayrıntıya girdikleri için.

Örneğin, 10'dan dokuz kez dinamik olmayan linq'e karşı kullanmak için dinamik linq üretmek için linq kullanma hakkında bir soru görürseniz, kişi ya mümkünse meraklı olur ya da yanlış ağaca havlar. bu şekilde çözebileceğiniz şeyler, aksi halde çözülmesi makul olmayan noktalara zordur.

Bu tür soruları iki bölümden alıyorum:

  1. yapılabilir mi ve eğer öyleyse nasıl görünürdü
  2. yapılmalı, risk var mı yoksa daha iyi bir alternatif mi var?

Neredeyse her zaman onları bu sırayla yaptığımı buldum. Soruyu cevaplar ve ayrıca potansiyel alternatifler için daha iyi bir açıklama yapmanıza yardımcı olur.


0

Ben geliştiricilerin kafasında herhangi duyarsızlaştırdığı hakkında bilmek ama bir bak yok burada oranlarına ilişkin numble görüşlü araçları / dillerin etkisi. Çıtayı düşürmekten bahsedin!


0

Mason Wheeler ile aynı fikirdeyim. Ancak, https://stackoverflow.com/questions/3762202/get-range-of-integers-with-linq adresini "sırayla" çalıştırarak çözmeye çalışmak tamamen delice değil . Sorun şu ki, Java ve .NET'in yineleyicileri 3 işlemi de desteklemiyor: geçerli değer, sonraki değer ve bir sonrakine geçme. Clojure 3'ü de yapabilir ve Clojure'de bunu doğru yapmanın daha kolay olduğundan şüpheleniyorum. Python'un ayrıca rutinleri de var ve bunu kırmayı denemek istiyorum. http://clojure.org/sequences http://www.try-clojure.org/

Aslında, giriş, http://oeis.org/A007401 gibi sonsuz bir sekanssa , tembel olan tek yoldur.


"Linq", "yineleyiciler" veya "tembel" anlamına gelmez - aslında, Linq’in çoğu ifade ağaçlarıyla ilgilidir. İsterseniz, kendi 3 değerli ya da N değerli topluluğunuzu, C # 'da bir kod ile kapatılarak ve çok fazla kod kullanmadan kolayca uygulayabilirsiniz. Sorun, insanların bunu nasıl yapacaklarını, hatta nasıl başlayacaklarını bilmiyorlarsa ve sadece System.Linqisim alanında yaşayan sihirli bir büyü arayışındayken ortaya çıkıyorlar .
Aarona

@Aaronaught ... '' '"Linq", "yineleyiciler" veya "tembel" anlamına gelmez "anlamına gelmez - peki, Linq, SQL gibi görünebilir, ancak bu sözdizimsel şeker, derlendiğinde derlenen gerçek bir IL koduna derlenir birlikte bağlanmış bir grup IEnumerable [<T>] ile eşdeğer görünür. Bu şey tembeldir ve diğer dillerde yineleyici olarak adlandırılacak olan sayıcılar kullanır. Ama evet, sorun şu ki LINQ kodlamanın kolay görünmesini sağlıyor ve niteliksiz deniyor. Bazıları belki de iyi bir programcı olabilir. Eğer C # ilk diliyse ve toplam noobs ise, o zaman büyük bir dille uğraşırlar.
Meslek

Tabii, Linq - Nesneler (Linq - SQL değil, Linq - Varlıklar, Linq - DataSet veya Linq'ın herhangi bir dalı) yineleyicilere ve ertelenmiş işlemlere dayanır , ama hepsi bu başlık altında. Yineleyici bloklar ve yieldifade, delegelerin yaptığı gibi, Linq'ten önce vardı. Kapaklar, Linq ile aynı sürümde geldi, ancak çok az sayıda saf "Linq" işlemi aslında yerel değişken yakalama gerektiriyor. "Linq ile [tamamen yinelemeli işlem / işlevin tanımı] nasıl yapabilirim? hem Linq'in (ne yapılması gerektiği) hem de dilin derin bir cehaletine ihanet ediyor.
Aarona
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.