LINQ और लैम्ब्डा एक्सप्रेशन के उपयोग से कम पठनीय कोड होता है? [बन्द है]

Question

मैं Linq पर एक सहकर्मी के साथ चर्चा कर रहा हूं, मैं यहां कॉपी करूंगा:

सह-कार्यकर्ता: यहाँ ईमानदार होना चाहिए। Linq सिंटेक्स बेकार है। यह भ्रामक और गैर-सहज है।

Me: ओह, टी-एसक्यूएल की तुलना में अधिक भ्रामक है?

सह-कार्यकर्ता: उह, हाँ।

Me: इसमें एक ही मूल भाग हैं, चयन करें, जहां, और से

सह-कार्यकर्ता: Linq, मेरे लिए, संबंधपरक + OO का कमीनेपन है। सह-कार्यकर्ता: मुझे गलत मत समझो - यह अविश्वसनीय रूप से शक्तिशाली है, लेकिन उन्होंने एसक्यूएल को फिर से ऑब्जेक्ट संग्रह का उपयोग करने के लिए पुनर्निर्मित किया।

मेरी राय है कि Linq + Lamda का उपयोग करना बहुत शक्तिशाली है (वह सहमत हैं), और कोड को पढ़ना भी आसान बनाता है (वह उस बिंदु पर असहमत है):

pickFiles = from f in pickFolder.GetFiles("*.txt")
where ValidAuditFileName.IsMatch(f.Name)
select f;

या

var existing = from s in ActiveRecordLinq.AsQueryable<ScannedEntity>()
where s.FileName == f.FullName && s.DocumentType != "Unknown"
select s;

या (VB कोड यहाँ)

   Dim notVerified = From image In images.AsParallel
     Group Join verifyFile In verifyFolder.GetFiles("*.vfy").AsParallel.Where(
      Function(v) v.Length > 0
      ).AsParallel
   On image.Name.Replace(image.Extension, ".vfy") Equals verifyFile.Name
     Into verifyList = Group
    From verify In verifyList.DefaultIfEmpty
    Where verify Is Nothing
    Select verify

मेरे लिए यह साफ और आसान है (कम से कम विकल्प के रूप में पढ़ने के लिए आसान है), इस पर आपकी क्या राय है?

Comments

मनुष्य, सामान्य रूप से, घृणा परिवर्तन। एक बड़ा प्रतिशत इससे बहुत नफरत करता है कि वे वास्तव में इससे डरते हैं।

— टोनी

चलो इसका सामना करते हैं ... linq सिर्फ एक डंबल है नीचे कार्यात्मक प्रोग्रामिंग सिंटैक्स को C # और VB.Net में जोड़ा गया है। लिंचिंग और लैम्ब्डा एक्सप्रेशंस को मूल रूप से "FP बेकार" कहा जा रहा है। वही आपके सहकर्मी कह रहे हैं। मुझे लगता है कि बहस कहीं और बाहर हो गई है।

— स्कॉट व्हिटलॉक

क्या यह किसी और को परेशान करता है कि लोग "सहज" शब्द का उपयोग करते हैं जब उनका वास्तव में "परिचित" मतलब होता है?

— लैरी कोलमैन

वैसे भी, सी # टीम (एरिक लिपर्ट सहित) यह समझाने के लिए अपने रास्ते से बाहर हो गई है कि लिनक एसक्यूएल का पोर्टिंग नहीं था , इसे अन्य विशेषताओं की तरह जमीन से डिजाइन किया गया था। मुझे कहना पड़ेगा कि आपका सहकर्मी एक लुडाइट है।

— Aaronaught

क्या यह की कीमत के लिए: मैं सिर्फ अपनी पत्नी (कार्यालय व्यवस्थापक - शून्य व्यावहारिक प्रोग्रामिंग अनुभव के बगल में) था aaronaught के 3 उदाहरणों पर गौर और LINQ और लैम्ब्डा उदाहरण के इरादे को समझने के लिए कर रहा था अब तक परंपरागत जरूरी उदाहरण की तुलना में अधिक आसानी से।

— स्टीवन एवर्स

Answer 1

मुझे अब सही पोस्ट नहीं मिल रही है, लेकिन एरिक लिपर्ट (और संभवत: कई अन्य नरमी) ने कई मौकों पर इस बात पर विचार किया है कि कैसे लिनाक घोषणापत्र है , जो कई वर्गों की समस्याओं के लिए अनिवार्य वाक्यविन्यास की तुलना में कहीं अधिक सहज है ।

Linq आपको ऐसा कोड लिखने में सक्षम बनाता है जो आशय व्यक्त करता है , न कि तंत्र ।

आप मुझे बताएं कि कौन सा पढ़ना आसान है। इस:

IEnumerable<Customer> GetVipCustomers(IEnumerable<Customer> source)
{
    List<Customer> results = new List<Customer>();
    foreach (Customer c in source)
    {
        if (c.FirstName == "Aaron")
        {
            results.Add(c);
        }
    }
    results.Sort(new LastNameComparer());
    return results;
}

class LastNameComparer : IComparer<Customer>
{
    public int Compare(Customer a, Customer b)
    {
        return x.LastName.CompareTo(b.LastName);
    }
}

या यह?

IEnumerable<Customer> GetVipCustomers(IEnumerable<Customer> source)
{
    return from c in source
           where c.FirstName == "Aaron"
           orderby c.LastName
           select c;
}

या यह भी?

IEnumerable<Customer> GetVipCustomers(IEnumerable<Customer> source)
{
    return source.Where(c => c.FirstName == "Aaron").OrderBy(c => c.LastName);
}

पहला उदाहरण परिणामों के सबसे सरल प्राप्त करने के लिए व्यर्थ बायलरप्लेट का सिर्फ एक गुच्छा है। जो कोई भी सोचता है कि यह लिनक संस्करणों की तुलना में अधिक पठनीय है, उसके सिर की जांच करने की आवश्यकता है। केवल इतना ही नहीं, बल्कि पहले की याददाश्त बर्बाद हो जाती है। आप इसे yield returnछँटाई के कारण भी नहीं लिख सकते हैं ।

आपका सहकर्मी कह सकता है कि वह क्या चाहता है; व्यक्तिगत रूप से, मुझे लगता है कि लिनक ने मेरे कोड पठनीयता में सुधार किया है ।

लिनक के बारे में कुछ भी "संबंधपरक" नहीं है। इसमें एसक्यूएल के लिए कुछ सतही समानताएं हो सकती हैं लेकिन यह संबंधपरक कलन को लागू करने के लिए किसी भी आकार या रूप में प्रयास नहीं करता है। यह सिर्फ एक्सटेंशन का एक गुच्छा है जो क्वेरी और प्रोजेक्ट अनुक्रम को आसान बनाता है। "क्वेरी" का अर्थ "रिलेशनल" नहीं है, और वास्तव में कई गैर-रिलेशनल डेटाबेस हैं जो एसक्यूएल जैसे सिंटैक्स का उपयोग करते हैं। Linq विशुद्ध रूप से ऑब्जेक्ट-ओरिएंटेड है, यह बस संबंध रेखा के साथ काम करने के लिए होता है जैसे Linq से SQL जैसे कुछ एक्सप्रेशन ट्री वूडू और C # टीम के चतुर डिजाइन के कारण, अनाम फ़ंक्शंस को अभिव्यक्ति के पेड़ के लिए परिवर्तनीय बनाते हैं।

Comments

+1 अगर आपको LINQ पसंद नहीं है, क्योंकि "आप इसे सही नहीं कर रहे हैं" :)

— Darknight

Linq is purely object-orientedइसके लिए +1। यही कारण है कि हमारी टीम शैली गाइड क्वेरी सिंटैक्स पर धाराप्रवाह सिंटैक्स का उपयोग करने के लिए लागू होती है। मुझे लगता है कि सी की तरह भाषाओं में संकेतन पर किसी को इस्तेमाल करने के लिए लिंक के OO प्रकृति को अधिक स्पष्ट करता है।

— SBI

मुझे पता है कि पोस्ट 7 साल पुरानी है। लेकिन यहाँ सवाल यह है: क्या आपने लिनक से मिलने से पहले अपने मुख्य उपकरण के रूप में कार्यात्मक भाषाओं का उपयोग किया था?

— सर्गेई.इक्विओक्सैक्सिस। इवानोव

बहुत स्पष्ट रूप से, मैं फ़ॉर लूप को पसंद करता हूं, क्योंकि तब मैं राइट-दूर देखता हूं, जहां हम कर सकते हैं और NULL-reference अपवाद होंगे, कैसे नल को संभाला जाता है, और यह निष्पादन को स्थगित नहीं करता है जो डीबगिंग को कठिन बनाता है, और यह n सूचियां नहीं देता है साथ ही, इसलिए लूप भी अधिक कुशल है।

— Quandary

@ चेतावनी, यदि आप होर्स्टमन शैली में प्रक्रियात्मक कोड को छँटाई और सुधार करते हैं , तो मैं कहूंगा कि यह LINQ संस्करण की तुलना में अधिक पठनीय है । और एकल जिम्मेदारी के सिद्धांत के अनुसार, छंटाई वास्तव में नहीं होती है GetVipCustomers(), जो कि, जैसा कि इसके बहुत नाम से पता चलता है, केवल मनमाने क्रम में वीआईपी ग्राहकों का एक संग्रह लौटाएगा। के लिए दुर्लभ मामलों में जहां क्रम महत्वपूर्ण है, इस तरह के स्क्रीन पर आउटपुट के रूप में, कॉलर प्रकार संग्रह करते हैं।

— Ant_222

Answer 2

सह-कार्यकर्ता: यहाँ ईमानदार होना चाहिए। Linq सिंटेक्स बेकार है। यह भ्रामक और गैर-सहज है।

आप उस आलोचना के साथ बहस नहीं कर सकते। अपने सहकर्मी के लिए, यह बेकार है । हम एक वाक्यविन्यास डिजाइन करने में विफल रहे, जो उनके लिए, स्पष्ट और सहज था। यह हमारी असफलता है, और आप अपने सहकर्मी से मेरी क्षमा याचना पर पारित कर सकते हैं। मुझे सुझाव है कि इसे बेहतर बनाने के लिए सुझाव देने में खुशी होगी; क्या विशेष रूप से आपके सहकर्मी को भ्रमित या अनपेक्षित लगता है?

हालाँकि, आप सभी को खुश नहीं कर सकते। मेरी व्यक्तिगत राय, और इस विषय पर जिन लोगों से मैंने बात की है, उनमें से अधिकांश की राय यह है कि क्वेरी कॉम्प्रिहेंशन सिंटैक्स समतुल्य अनिवार्य सिंटैक्स की तुलना में अधिक स्पष्ट है। स्पष्ट रूप से हर कोई सहमत नहीं है, लेकिन सौभाग्य से हमें भाषा डिजाइन करते समय हमारे सभी लाखों ग्राहकों की आम सहमति की आवश्यकता नहीं होती है।

इस विषय पर कि "सहज" क्या है, हालांकि, मुझे अंग्रेजी भाषाविद् की कहानी याद आ गई, जिन्होंने कई अलग-अलग भाषाओं का अध्ययन किया और अंत में यह निष्कर्ष निकाला कि अंग्रेजी सभी भाषाओं में सर्वश्रेष्ठ थी क्योंकि अंग्रेजी में शब्द उसी क्रम में आते हैं जो आप उन्हें सोचो । फ्रेंच के विपरीत, जहां वे लगातार "कुत्ते सफेद मांस खाते हैं" जैसी चीजें कह रहे हैं। फ्रेंच लोगों के लिए शब्दों को सही क्रम में सोचना कितना कठिन होगा और फिर उन्हें फ्रांसीसी क्रम में कहना होगा ! फ्रेंच इतना अचूक है! यह आश्चर्यजनक है कि फ्रांसीसी इसे बोलने का प्रबंधन करते हैं। और जर्मन? जहाँ उन्हें लगता है कि "कुत्ता मांस खाता है" लेकिन फिर कहना होगा कि "कुत्ता मांस खाता है"!?!

अक्सर "सहज" क्या केवल परिचित का मामला है। इससे पहले कि मैं "चुनिंदा" खंड के साथ अपने प्रश्नों को शुरू करने से पहले मुझे LINQ के साथ काम करने में महीनों लगे। अब यह दूसरी प्रकृति है, और SQL ऑर्डर विचित्र लगता है।

जो यह है! स्कोपिंग नियम SQL में गड़बड़ हैं। कुछ चीज़ जो आप अपने सहकर्मी को इंगित करना चाहते हैं, वह यह है कि LINQ को सावधानीपूर्वक डिज़ाइन किया गया था ताकि (1) वेरिएबल्स और स्कोप्स का परिचय बाएं से दाएं (*) हो, और (2) यह आदेश पृष्ठ पर क्वेरी दिखाई दे। जिस क्रम में इसे निष्पादित किया जाता है। यानी जब आप कहें

from c in customers where c.City == "London" select c.Name

सी बाईं ओर के दायरे में दिखाई देती है, और दाईं ओर दायरे में रहती है। और जिस क्रम में चीजें होती हैं: पहले "ग्राहकों" का मूल्यांकन किया जाता है। फिर अनुक्रम को फ़िल्टर करने के लिए "जहां" का मूल्यांकन किया जाता है। फिर फ़िल्टर किए गए अनुक्रम को "चयन" द्वारा अनुमानित किया जाता है।

SQL के पास यह गुण नहीं है। अगर आप कहते हैं

SELECT Name FROM Customers WHERE City = 'London'

तब "नाम" को उसके दाईं ओर कुछ के दायरे में लाया जाता है, उसके बाईं ओर नहीं, और क्वेरी को पूरी तरह से गड़बड़ क्रम में निष्पादित किया जाता है; मध्य खंड का पहले मूल्यांकन किया जाता है, फिर अंतिम खंड और फिर पहला खंड। यह अब मेरे लिए पागल और अनजाना लगता है, केवल LINQ के साथ इतने लंबे समय तक काम किया है।

---

(*) स्कूपिंग नियम लिंड क्यू में थोड़े अजीब होते हैं। लेकिन इसके अलावा, scopes घोंसला अच्छी तरह से।

Comments

नाइटपिक: जर्मन में, "डेर हंड फ्रिसस्ट दास फ्लेश्च" वास्तव में अंग्रेजी में उसी तरह का आदेश है, "कुत्ता मांस खाता है" :) इसके अलावा, मुझे लिनक्यू क्वेरी वाक्यविन्यास बहुत आसानी से मिल गया जब मैंने महसूस किया कि यह एसक्यूएल नहीं था ।

— माइकल Stum

@ जीबीजैनब: मैं LINQ सिंटैक्स को पूरी तरह से व्यक्तिपरक आधार पर अधिक समझने योग्य नहीं ठहरा रहा हूँ । इसके बजाय, मैं इसे पूरी तरह से वस्तुनिष्ठ आधार पर सही ठहरा रहा हूं कि यह उपकरण को डिजाइन करने के लिए बहुत आसान है जो LINQ प्रश्नों के निर्माण में उपयोगकर्ता की सहायता करता है क्योंकि LINQ सिंटैक्स को ध्यान में रखते हुए बनाया गया था, और यह मानसिक रूप से समझने में आसान है जिस क्रम में एक क्वेरी में घटनाएं होती हैं क्योंकि वे उसी क्रम में आते हैं।

— एरिक लिपर्ट

एरिक, घोषणात्मक शैली के एक प्रोग्रामिंग परिप्रेक्ष्य से मैं समझता हूं कि एसक्यूएल की तुलना में लिनक उपयुक्त है (आई डी डी पठनीय)। लेकिन क्या यह SQL की तुलना में अधिक मानव पठनीय है? बिल्कुल नहीं। यदि 'कुत्ता मांस लाल खाता है ’कठिन है, तो रसोई से जहां रंग लाल होता है, चाकू कितना आसान है? वास्तव में हम सभी बात करते हैं और सोचते हैं कि 'उस चाकू को प्राप्त करें जो कि रसोई से मेज के ऊपर है'। और वह यह है कि जहां SQL LINQ की तुलना में वास्तविक जीवन के करीब है।

— नवाफल

मुझे स्टारबक्स से एक कप कॉफी चाहिए जहां स्टोर आधी रात तक खुला रहता है। क्या यह आपको परिचित लगता है? यह SQL क्वेरी के समान सटीक क्रम में है। हाँ, LINQ एक मानक SQL क्वेरी को निष्पादित करने के लिए आपके द्वारा उत्पन्न अनावश्यक कोड की तुलना में अधिक पठनीय हो सकता है, लेकिन LINQ SQL क्वेरी से अधिक पठनीय नहीं है। तो हाँ; यह LINQ डेवलपर्स के लिए बाएं से दाएं क्षेत्र के लिए फायदेमंद हो सकता है, लेकिन एक उपयोगकर्ता के रूप में, मुझे क्यों परवाह है? मुझे केवल प्रयोज्य की परवाह है।

— काइलएम

@ केलीएम: बेशक; प्रयोज्य LINQ डिजाइन का एक बहुत ही महत्वपूर्ण पहलू था। विशेष रूप से, उत्पादकता साधनों के लिए उत्तरदायी होना महत्वपूर्ण था। क्योंकि LINQ क्वेरी में लिखने के लिए बाईं ओर से स्कूपिंग बहती है, तब तक जब आप c.IDE टाइप करते हैं तो आपको पहले से ही इसका प्रकार पता है cऔर आपको IntelliSense दे सकता है। LINQ में आप कहते हैं "c में ग्राहकों से जहाँ c।" और उछाल, तुम IntelliSense के सदस्यों को सूचीबद्ध करने में आपकी मदद करते हैं Customer। SQL में जब आप "ग्राहकों से चयनित नाम" टाइप करते हैं, तो आपको यह बताने में कोई भी मदद नहीं मिल सकती है कि "नाम" एक अच्छा विकल्प है क्योंकि आपने name पहले टाइप किया थाcustomers ।

— एरिक लिपर्ट

Answer 3

प्रोग्रामिंग की दुनिया में कुछ और की तरह, आपको सिंटैक्स की आदत हो जाएगी, और फिर यह (संभावित) पढ़ने में आसान है।

प्रोग्रामिंग की दुनिया में किसी भी चीज़ की तरह, स्पेगेटी कोड या अन्य अपशब्दों की संभावना है।

प्रोग्रामिंग की दुनिया में कुछ और की तरह, आप इसे इस तरह से या किसी अन्य तरीके से कर सकते हैं।

प्रोग्रामिंग की दुनिया में कुछ और की तरह, आपका माइलेज अलग हो सकता है।

Answer 4

मैंने एक टिप्पणी / टिप्पणी देखी जहां इसने कुछ कहा - LINQ / lambda के संबंध में - की तर्ज पर: "अपने कंप्यूटर के लिए पठनीय के बजाय मनुष्यों के लिए पठनीय कोड लिखें"।

मुझे लगता है कि इस कथन में बहुत योग्यता है, हालांकि, डेवलपर (जैसे खुद को) पर विचार करें, जो विधानसभा से विकास भाषाओं की पूर्ण सरगम ​​के माध्यम से, प्रक्रियात्मक के माध्यम से, OO के माध्यम से, प्रबंधित के माध्यम से, उच्च throughput कार्य समानांतर समाधान के माध्यम से ।

मैंने अपने कोड को संभव के रूप में पठनीय और पुन: प्रयोज्य बनाने पर जोर दिया है और कई विस्तृत व्यापार क्षेत्रों में उत्पादन गुणवत्ता प्रणाली और सेवाओं को वितरित करने के लिए GOF डिज़ाइन पैटर्न सिद्धांतों को अपना रहा है।

पहली बार जब मैंने लैम्बडा अभिव्यक्ति का सामना किया, तो मैंने सोचा: "वह क्या है!" यह मेरे परिचित (और इसलिए आरामदायक) स्पष्ट घोषणात्मक वाक्यविन्यास के लिए तुरंत प्रति-सहज था । नौकरीपेशा लोगों में युवा <5yrs ने इसे वैसे ही लपक लिया जैसे स्वर्ग से मन्ना!

ऐसा इसलिए है क्योंकि सालों तक एक कंप्यूटर की तरह (सिंटैक्टिक अर्थ में) बहुत आसानी से डायरेक्ट कोडिंग सिंटैक्स (भाषा के बावजूद) में अनुवाद किया जाता है। जब आप लगभग 20 + वर्ष (मेरे मामले में 30+) के लिए कम्प्यूटेशनल मानसिकता रखते हैं, तो आपको सराहना करनी होगी कि लैम्ब्डा अभिव्यक्ति का प्रारंभिक सिंटैक्टिक झटका आसानी से भय और अविश्वास में बदल सकता है।

हो सकता है कि ओपी में सह-कार्यकर्ता एक समान पृष्ठभूमि से खुद के रूप में आया था (यानी कुछ समय ब्लॉक के आसपास रहा था) और यह उस समय उनके लिए काउंटर-सहज था? मेरा सवाल है: आपने इसके बारे में क्या किया? क्या आपने इनलाइन सिंटैक्स के लाभों को समझने के लिए अपने सहकर्मी को फिर से शिक्षित करने की कोशिश की, या क्या आपने "प्रोग्राम के साथ नहीं होने" के लिए उन्हें स्तंभित / अपकृत किया? पूर्व ने शायद आपके सहकर्मी को आपकी सोच की रेखा के करीब आते देखा होगा, बाद वाले शायद उन्हें LINQ / लैम्ब्डा सिंटैक्स को और भी अधिक गलत बना देंगे और इस तरह नकारात्मक राय को बढ़ा देंगे।

खुद के लिए मुझे अपने सोचने के तरीके को फिर से शिक्षित करना पड़ा (जैसा कि एरिक ऊपर बता रहा है, यह एक बेहूदा सोच-बदलाव नहीं है, और मुझे 80 के दशक में मिरांडा में कार्यक्रम करना था, इसलिए मेरे पास कार्यात्मक प्रोग्रामिंग अनुभव का हिस्सा है) लेकिन एक बार जब मैं उस दर्द से गुज़रा तो लाभ स्पष्ट था - लेकिन अधिक महत्वपूर्ण बात - जहाँ इसका उपयोग खत्म हो गया था (यानी इसका उपयोग करने के लिए इस्तेमाल किया गया था ), जटिल और दोहराव से अधिक (उस उदाहरण में DRY सिद्धांत को देखते हुए)।

जैसा कि कोई है जो अभी भी न केवल बहुत सारे कोड लिखता है, बल्कि जिसे तकनीकी रूप से बहुत सारे कोड की समीक्षा करनी है, यह अनिवार्य था कि मैं इन सिद्धांतों को समझूं ताकि मैं निष्पक्ष रूप से आइटमों की समीक्षा कर सकूं, सलाह दूं कि एक लंबोदर अभिव्यक्ति का उपयोग अधिक कुशल हो सकता है / पठनीय, और अत्यधिक जटिल इनलाइन लैम्ब्डा अभिव्यक्तियों (जहां एक विधि कॉल होती है - उन मामलों में - कोड को अधिक पठनीय, बनाए रखने योग्य और एक्स्टेंसिबल बनाते हैं) की पठनीयता पर विचार करने के लिए डेवलपर्स को प्राप्त करने के लिए भी।

तो जब कोई कहता है कि उन्हें "लंबोदा नहीं मिलता है?" या LINQ सिंटैक्स, ब्रांड के बजाय एक लुडाइट उन्हें अंतर्निहित सिद्धांतों को समझने में मदद करने की कोशिश करता है। आखिरकार उनके पास "पुराने स्कूल" की पृष्ठभूमि भी हो सकती है।

Comments

दिलचस्प टिप्पणी - मेरे पास यह तब था जब मैंने दृढ़ता से टाइप की गई, स्थिर भाषाओं से गतिशील भाषाओं में स्विच किया। समायोजित करने के लिए मुझे कुछ समय लगा (भय और अविश्वास) और अब मुझे ईमानदारी से वापस जाना मुश्किल है।

— दोपहर का भोजन 317

Answer 5

यदि प्रश्न बहुत लंबे हैं तो लैम्ब्डा एक्सप्रेशंस कम पठनीय कोड की ओर ले जाता है। हालाँकि यह बहुत से नेस्टेड लूप्स से बेहतर है ।

यह दो के मिश्रण के साथ बेहतर है ।

अगर यह तेज़ है (तो आपको इसे तेज़ करने की ज़रूरत है) या पढ़ने में आसान होने पर इसे लैम्ब्डा में लिखें।

Comments

हाँ, लेकिन क्या यह linq / lamda पढ़ने के लिए आसान नहीं होगा ?

— कालाधन

क्षमा करें, विकल्प की तुलना में पढ़ना आसान नहीं था।

— कालाधन

Answer 6

मुझे लगता है कि यह ज्यादातर मामलों में निर्भर करता है (कुछ बहुत विचित्र करने के अलावा) अगर आप "पठनीय" का मतलब है कि किसी को क्या हो रहा है या अगर वे आसानी से सभी छोटे छोटे विवरण पा सकते हैं।

मुझे लगता है कि लिंक पूर्व के साथ मदद करता है, लेकिन अक्सर (विशेषकर जब डीबगिंग) बाद में दर्द होता है।

IMHO जब मैं कोड देख रहा हूं तो मैं पूर्व से अपरिचित हूं, बाद की तुलना में बेहद महत्वपूर्ण है, इसलिए मुझे यह अधिक पठनीय लगता है।

Comments

अच्छी बात। उत्तरार्द्ध आमतौर पर अच्छी इकाई परीक्षण द्वारा कवर किया जाता है।

— स्कॉट व्हिटलॉक

तो आपको लगता है कि लिनक मूल्यांकन के इंटर्नल सभी विवरणों को खोजना मुश्किल बनाता है? क्या आप इसका उदाहरण दे सकते हैं कि यह कब हो सकता है?

— ब्लैक डेसी

@ डेविड: लिनक एक्सप्रेशन सिर्फ आलसी मूल्यांकन नहीं हैं, वे एक्सप्रेशन हैं । एक linq अभिव्यक्ति का प्राप्त कोड वास्तव में अभिव्यक्ति को संशोधित कर सकता है इसलिए यह पूरी तरह से कुछ अलग करता है, जैसे कि एस-एक्सप्रेशन पर काम कर रहे एक लिस्प मैक्रो। उदाहरण के लिए, जब SQL के लिए linq के साथ काम करते हैं, यह वास्तव में अभिव्यक्ति लेता है where e.FirstName == "John"और अनुवाद करता है कि SQL क्वेरी में! ऐसा लगता है कि असंबद्ध (लेकिन पार्स) अभिव्यक्ति को देखते हुए, यह FirstNameएक स्थायी इकाई पर कहे जाने वाले संपत्ति की तुलना है, और यह एक स्ट्रिंग की तुलना कर रहा है, आदि बहुत कुछ चल रहा है।

— स्कॉट व्हिटलॉक

@ सामान्य तौर पर जब तक आप खुद के खिलाफ लाइनक का उपयोग शुरू नहीं करते, तब तक मुझे विवरण मुश्किल नहीं लगता। इसका एक "सरल" उदाहरण जिसने मुझे अपना सिर लपेटने में लंबा समय लगा दिया, वह यह है: बग़्क़ाश .blogspot.com / 2008 / 07 / y-combinator-and-linq.html लेकिन कुछ और आवश्यक उदाहरण हैं चीजों को लोग गतिशील, डायनामिकओबजेक्ट और IDynamicMetaObjectProvider क्षेत्रों में अभिव्यक्तियों के साथ कर रहे हैं। जहां आप लाइन आकर्षित करते हैं कि लाइनक क्या बहस का विषय है, लेकिन जैसा कि सभी बिंदुओं में स्कॉट बताते हैं कि लाइनक में / के लिए उपलब्ध है क्योंकि लाइनक एक ही अभिव्यक्ति पेड़ों का उपयोग करता है।

— बिल

@ सब ठीक है, मैं तुम्हें देता हूँ कि कठिन है, लेकिन y- combinator और उच्च आदेश कार्यों हमारे सिर के अधिकांश चोट करने जा रहे हैं, यह पुनरावृत्ति की तरह है, आप इसे प्राप्त करते हैं या आप नहीं करते हैं। पढ़ने के लिए उस आसान का पुनरावर्ती कार्यान्वयन है (यदि आप एक भी नहीं जानते थे)?

— कालाधन

Answer 7

मुझे LINQ सिंटैक्स सहज और पढ़ने में आसान लगता है, खासकर जब से वे FROM को शुरू में रखते हैं, जहां वह SQL की तरह बीच में नहीं है। लेकिन IMO लंबोदर भ्रमित कर रहे हैं और कोड को पढ़ना मुश्किल बना रहे हैं।

Comments

आपको क्यों लगता है कि लंबोदर भ्रमित हैं? क्या यह प्रकार का अनुमान है?

— चाओसपांडियन 17

@ChaosPandion: पहला प्रकार का निष्कर्ष, और दूसरा, प्रतीक। एक = और a> को एक साथ रखने पर एक> = लगता है कि किसी ने खराब कर दिया है और पीछे की ओर लिखा है, और यह मेरे मस्तिष्क को एक लूप के लिए फेंक देता है।

— मेसन व्हीलर

@ मेसन - क्या आपको हास्केल ( \x -> x * x) या एफ # ( fun x -> x * x) का वाक्यविन्यास पसंद है ?

— चाओसपांडियन 19

@ChaosPandion: नहीं, विशेष रूप से नहीं। लैम्ब्डा लिखना जल्दी हो सकता है, लेकिन मुझे उन्हें पार्स करना मुश्किल लगता है, खासकर जब वे जटिलता में गैर-तुच्छ हो जाते हैं। आपके उदाहरण उस बुरे नहीं हैं, लेकिन वे बहुत बुरा हो जाते हैं।

— मेसन व्हीलर

@ मेसन: ऐसा लगता है कि आप लामाओं के साथ दुर्व्यवहार कर रहे हैं, बजाय इसके कि आप लैमदास के विचार पर आपत्ति जताएं।

— आनन।

Answer 8

मैं आपसे सहमत हूं कि Linq सिंटैक्स T-SQL से काफी अलग नहीं है। मुझे लगता है कि आपका सहकर्मी वास्तव में संबंधपरक सामान को मिलाए जाने पर आपत्ति जता सकता है जिसमें उसका अच्छा और चमकदार OO कोड हो। दूसरी ओर, कार्यात्मक प्रोग्रामिंग का उपयोग करने के लिए थोड़ा सा समय लगता है, और इसके लिए अभ्यस्त होने की इच्छा होती है।

Answer 9

निर्भर करता है। जाहिर है, टी-एसक्यूएल विशिष्ट रूप से कुछ डीबी-रिलेशनल समाधान प्रदान करता है। जाहिर है LINQ विशिष्ट कुछ OO समाधान प्रदान करता है।

हालाँकि; "टी-एसक्यूएल से अधिक भ्रामक?" - प्रारंभिक प्रश्न में चर्चा / पूछा गया है। यह स्पष्ट रूप से कुछ विशेषताओं का तात्पर्य है जो मौजूदा उत्तर पते में से कोई भी नहीं है, इसके बजाय (स्पष्ट रूप से एसक्यूएल-परिचित) आलोचक पर अतीत में फंसने का आरोप लगाते हैं।

इसलिए यद्यपि मैं कुछ गुणों के लिए LINQ की सराहना करता हूं, और यहां मौजूदा उत्तरों से बहुत असहमत नहीं हूं, मुझे लगता है कि काउंटरपॉइंट प्रतिनिधित्व का हकदार है:

LINQ से परिचित होने के वर्षों बाद, कुछ प्रकार के समूह संचालन, बाहरी जुड़ाव और गैर-समरूप कार्य करना, समग्र कुंजियों के साथ काम करना, और LINQ में अन्य संचालन करना अभी भी मुझे परेशान करता है। (विशेषकर प्रदर्शन-संवेदनशील प्रश्नों के साथ संबंधपरक बैक-एंड को लक्षित करते समय।)

from c in categories
join p in products on c equals p.Category into ps
from p in ps.DefaultIfEmpty()

यदि आपको लगता है कि आप के लिए सहज, अधिक शक्ति है। ;)

Answer 10

शायद एक कारण है कि लिनक बेकार है, बस इन पाठ्यपुस्तकों के उदाहरणों के बजाय वास्तविक दुनिया उदाहरण बनाने की कोशिश करें।

इस फ़ंक्शन को linqlamdathings में दिखाने का प्रयास करें और आप देखेंगे, कि सभी सुंदरता चली गई है, जबकि क्लासिक तरीका पठनीय है। आस्थगित निष्पादन समस्याओं और विराम बिंदुओं का निर्धारण करने के लिए नहीं।

सच्चाई यह है कि LinqLambdaThings कुछ मामलों में बहुत उपयोगी हैं और वे सभी निफ्टी ऑब्जेक्ट ओरिएंटेशन को बदलने के लिए नहीं सोचा जाता है जिन्हें आप लोग कभी नहीं समझते हैं

    public IList<Customer> GetVipCustomers(IList<Customer> source, int maxCount)
    {
        var results = new SortedList<string,Customer>();

        foreach (Customer c in source)
        {
            if (maxCount == results.Count)
                break;

            if (c.IsVip && c.FirstName== "Aaron" || c.SecondName== "Aaron")
                results.Add(c.LastName, c);
        }

        return results.Values;
    }

Comments

मुझे लगता है कि यह source.Where(c => c.IsVip && c.FirstName == "Aaron" || c.SecondName == "Aaron").Take(maxCount).OrderBy(d => d.LastName);आपकी मुश्किल है लेकिन मुझे पढ़ने में आपकी गलती हुई होगी;)

— jk।

किस तरह से आपने इन्हें पाठ्यपुस्तक उदाहरण माना? यह वास्तव में उत्पादन उपयोग कोड है। यदि आप अपने क्लासिक "पठनीय" कोड और लाइनक / लैम्डा दोनों संस्करण प्रदान करते हैं, तो यह तुलना करने के बजाय सभी को इसे बदलने की अपेक्षा करेगा।

— BlackICE

क्या आपने विशेष रूप से LINQ के बारे में शिकायत करने के लिए पंजीकरण किया था?

— KChaloux

@KCououx मुझे लगता है कि वे सिर्फ ईमानदार होने के लिए ट्रोल कर रहे थे

— jk।