क्या .NET प्रोग्रामर्स पर लिनक का दिमाग सुन्न हो रहा है?


36

हम में से बहुत लोगों ने लगभग एक साल पहले jQuery के साथ इस घटना को देखना शुरू किया था जब लोगों ने पूछना शुरू कर दिया था कि jQuery के साथ क्वेरी स्ट्रिंग को पुनः प्राप्त करने जैसी बिल्कुल पागल चीजें कैसे करें । लाइब्रेरी (jQuery) और भाषा (जावास्क्रिप्ट) के बीच का अंतर स्पष्ट रूप से कई प्रोग्रामर पर खो जाता है, और बहुत से अनुचित, जटिल कोड लिखे जा रहे हैं, जहां यह आवश्यक नहीं है।

हो सकता है कि यह सिर्फ मेरी कल्पना है, लेकिन मैं कसम खाता हूं कि मैं उन सवालों की संख्या में एक उतार-चढ़ाव देखना शुरू कर रहा हूं, जहां लोग लिनक के साथ उसी तरह की पागल बातें करने के लिए कह रहे हैं, जैसे एक क्रमबद्ध सरणी में पर्वतमाला खोजें । मैं इस समस्या को हल करने के लिए लिनेक एक्सटेंशन कितना अनुचित है, इस पर नहीं पहुंच सकता, लेकिन इससे भी महत्वपूर्ण तथ्य यह है कि लेखक ने यह मान लिया कि आदर्श समाधान वास्तव में इसके बारे में सोचे बिना लिनक को शामिल करेगा (जहां तक ​​मैं बता सकता हूं)। ऐसा लगता है कि हम इतिहास को दोहरा रहे हैं। .NET प्रोग्रामर की एक नई पीढ़ी को जन्म दे रहे हैं जो भाषा (C # / VB.NET) और लाइब्रेरी (Linq) के बीच अंतर नहीं बता सकते।

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

इससे भी महत्वपूर्ण बात यह है कि क्या यह वास्तव में एक समस्या है, और यदि हां, तो इन लोगों को ज्ञान देने में मदद करने का सबसे अच्छा तरीका क्या है?


6
+1 के लिए "यह मान लिया कि आदर्श समाधान वास्तव में इसके बारे में सोचे बिना लिनक को शामिल करेगा"। यह वास्तव में मेरे से परे है।
जैको प्रीटोरियस सेप

1

2
@ पियरे: आप किस आधार पर यह दावा करते हैं?
हारून को

5
@ मैसन: यह एक बिल्कुल भयानक बेंचमार्क है जो किसी व्यक्ति द्वारा लिखा गया है, जो स्पष्ट रूप से नहीं जानता है कि वे क्या कर रहे हैं। टिक्सेस में बेंचमार्किंग ? हंगेरियन संकेतन? और Linq संस्करण भी एक ही काम नहीं करता है, यह पहली बार में रोकने के बजाय हर एक परिणाम को पुनरावृत्त करने की कोशिश करता है। उल्लेख नहीं करने के लिए, पूरा आधार मूर्खतापूर्ण है, जैसा कि आज के गर्म प्रश्न में अज्ञात रूप से चर्चा की गई थी ।
आरोनॉन

3
और, संयोगवश @ मेसन, लाइनक में कई अनुकूलन किए गए हैं। लगभग किसी भी विधि के लिए जो अनुकूलित होने में सक्षम है, यह पहली बार अनुकूलित पद्धति का समर्थन करने वाले इंटरफ़ेस की तलाश करता है। अन्य सेट-आधारित विधियों जैसे कि समभुज के लिए, यह हैश टेबल बनाता है। यह आपके लिए आपके कोड का अनुकूलन नहीं करता है, लेकिन यह आपके कोड को किसी भी धीमा बनाने वाला नहीं है; अधिकांश वास्तविक प्रलेखित वास्तविक-दुनिया की मंदी लैंबडास / क्लोजर के कारण होती है जो लिनक से स्वतंत्र हैं।
Aaronaught

जवाबों:


52

यह मूल रूप से है क्योंकि प्रोग्रामिंग मौलिक रूप से कठिन है। इसके लिए बहुत सारे तार्किक, संरचित विचार की आवश्यकता होती है, जो बहुत सारे लोग अभी नहीं जानते हैं कि कैसे करना है। (या आप जो सुनते हैं, उसके आधार पर बस नहीं कर सकते ।)

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

आपका सवाल सही रास्ते पर है, लेकिन हिंसक वीडियो गेम के बारे में बारहमासी विवाद की तरह "बच्चों को हिंसक बनाने वाले", यह लिंक की दिशा में पीछे की तरफ है। आसान प्रोग्रामिंग तकनीकें प्रोग्रामर्स को बेवकूफ नहीं बनाती हैं; वे सिर्फ बेवकूफ लोगों को प्रोग्रामिंग के लिए आकर्षित करते हैं। और वास्तव में बहुत कुछ नहीं है जो आप इसके बारे में कर सकते हैं।


30
+1 के लिए "आसान प्रोग्रामिंग तकनीक प्रोग्रामर को बेवकूफ नहीं बनाते हैं; वे सिर्फ बेवकूफ लोगों को प्रोग्रामिंग के लिए आकर्षित करते हैं।"
स्टीवन एवर्स

1
LINQ के बारे में एक बड़ी बात यह है कि यह मुझे एक कार्यात्मक दृष्टिकोण में एक समाधान को प्रोटोटाइप करने की अनुमति देता है। फिर एक बार मेरे पास एक बग नि: शुल्क समाधान है मैं इसे एक अनुकूलित अनिवार्य संस्करण के लिए एक परीक्षण बेंच के रूप में उपयोग कर सकता हूं। यदि कार्य इतना सरल है कि एक भी फ़िल्टर लागू करना मुझे परेशान नहीं करेगा।
चोसपांडियन

5
मुझे अब भी शक हो रहा है कि LINQ अक्षम प्रोग्रामर को आकर्षित करता है - मैंने जो देखा है, उसे समझने के लिए newbies के लिए सबसे कठिन अवधारणाओं में से एक लगता है - लेकिन, यह अब तक का सबसे अच्छा जवाब लगता है।
हारून पकड़ा गया

1
आपको उस अंतिम वाक्य पर एक कॉपीराइट लगाना चाहिए। अच्छा कहा, सर।
एजे जॉनसन

1
मजेदार। मेरे लिए, LINQ एक अवधारणा नहीं है जो विशेष रूप से मास्टर करना आसान है। यदि आप कुछ भी उपसर्ग कर रहे हैं, तो बहुत जल्दी आपको स्टीयरिंग व्हील के बारे में सोचना बंद करना होगा और ट्रांसमिशन को समझना शुरू करना होगा। मैं तुम्हें देख रहा हूँ लामदास!
ब्रायन मैकके

13

मेरे लिए यह नई खिलौना घटना है। कुछ नया (LINQ) सामने आता है और अब हर डेवलपर इसके साथ खेलना चाहता है।

वे LINQ को एक हथौड़ा के रूप में देखते हैं और हर समस्या एक कील है। कौन परवाह करता है अगर यह एक और तरीका करना आसान है? LINQ का जवाब होना चाहिए! जब हर कोई हर किसी के लिए XML का उपयोग कर रहा था! विन्यास फाइल? एक्सएमएल। आकड़ो का भंडारण किया जा रहा हैं? एक्सएमएल। आदि आदि


5
यहां XML बहस शुरू नहीं करना चाहते हैं, लेकिन यह इंगित करने योग्य है कि XML वास्तव में उन दोनों चीजों में अच्छा है। यह हमेशा इष्टतम नहीं है - यदि कॉन्फ़िगरेशन फ़ाइलों को संरचित करने की आवश्यकता नहीं है, तो KVPs बेहतर हैं, और यदि क्रॉस-एप्लिकेशन संगतता की आवश्यकता नहीं है, तो भंडारण / क्रमांकन के लिए एक द्विआधारी प्रारूप स्पष्ट रूप से बेहतर है। लेकिन मुझे नहीं लगता कि एक्सएमएल एक ऐसा बेहतरीन उदाहरण है क्योंकि यह खुद को उन क्षेत्रों में इस्तेमाल करने के लिए प्रेरित करता है जहां यह पूरी तरह से अनुचित के विपरीत उप-इष्टतम था।
एरॉन को

4
+1: जब आप एक तकनीक सीख रहे हों, तो यह देखने के लिए कि आपके उपकरण को नाखून के आकार में कितनी समस्याओं का सामना करना पड़ सकता है, अपने उपकरणों को फैलाने के लायक है।
स्टीवन एवर्स

+1: जादू हथौड़ा के इस प्रकार के अन्य उदाहरण jQuery के हैं (जैसा कि प्रश्न में उल्लेख किया गया है) और नियमित अभिव्यक्ति। ऐसा नहीं है कि ये चीजें खराब हैं, वास्तव में वे वास्तव में उपयोगी हैं, लेकिन वे हर चीज का जवाब नहीं हैं।
टिम गुडमैन

14
मुझे लगता है कि "LINQ एक हथौड़ा है और हर समस्या एक कील है" सादृश्य इसे बहुत दूर धकेल रहा है। मैं कहूंगा कि LINQ इतना अच्छा हथौड़ा है कि जब आपके काम के एक बड़े हिस्से में नाखून शामिल होते हैं, तो आप एक खांचे में जा सकते हैं और ध्यान नहीं दे सकते कि आपने बस एक स्क्रू में हथौड़ा मारा है। भले ही आप एक खराब प्रोग्रामर नहीं हैं
कार्सन 63000

@ चेतावनी: दूसरी ओर, लंबे समय तक नाम के साथ XML का उपयोग मुझे कम-बैंडविड्थ और नहीं-पूरी तरह से विश्वसनीय रेडियो लिंक के माध्यम से डेटा ट्रांसमिशन के लिए उप-विषयी लग रहा था। फिर फिर से, मैंने उस उत्पाद पर डेटाबेस डिजाइन के बारे में भी सोचा।
डेविड थॉर्नले

10

मुझे लगता है कि LINQ एक अधिक कार्यात्मक दृष्टिकोण का उपयोग करके समस्याओं को हल करने में C # में एक बहुत अच्छा अवसर प्रदान करता है। हमें समस्या हल करने की एक नई शैली को खारिज नहीं करना चाहिए क्योंकि हमारे पास पहले से ही कुछ है जो काम करता है।

एक भारी एसक्यूएल पृष्ठभूमि से आ रहा है, मुझे अपने ऑपरेशन के इरादे का बेहतर वर्णन करने के लिए अपने सी # में सेट आधारित तर्क का उपयोग करने का विकल्प पसंद है।

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


कौन खारिज कर रहा है? मैं हर समय Linq का उपयोग करता हूं, मैं बस उन लोगों की संख्या के बारे में चिंतित हूं जिन्हें मैं इसका उपयोग करने वाले लोगों (या इसका उपयोग करने का प्रयास) की समस्याओं के बारे में बताता हूं जो स्पष्ट रूप से पुनरावृत्त हैं और सेट-आधारित नहीं हैं।
हारून

मैं उन समस्याओं को हल करने की कोशिश करने का आदी हूँ, जिन्हें एसक्यूएल में लिखने की आवश्यकता है, और ऐसा करने के लिए कर्सर के बजाय सेट-आधारित तर्क का उपयोग करना। टूल का दुरुपयोग हमेशा होगा, लेकिन मुझे लगता है कि कम से कम यदि वे खराब प्रक्रिया कोड के बजाय खराब LINQ कोड लिखते हैं, तो .NET का एक बाद का संस्करण अधिक आसानी से कम से कम इसे समानांतर करने में सक्षम होगा।
डॉटजॉश

2

LINQ और jQuery के नवीनतम "खिलौने" हैं और डेवलपर्स को यह दिखाना पसंद है कि वे नवीनतम चीज़ों का उपयोग करके सामान कैसे कर सकते हैं।


मैं इस बात से सहमत हूं। मुझे यकीन नहीं है कि अगर यह इस विशेष घटना की व्याख्या करता है। इन प्रश्नों को पूछने वाले लोग वास्तव में शो-ऑफ प्रकार के नहीं लगते हैं - हालांकि यह समझाने में मदद करेगा कि अन्य प्रोग्रामर सवालों के जवाब देने की कोशिश क्यों करते हैं क्योंकि वे एक सान्द्र दृष्टिकोण की वकालत करते हैं।
Aaronaught

@Aaronaught - हाँ, मुझे लगता है कि मैं इस बारे में अधिक सोच रहा था कि लोग इस दृष्टिकोण का उपयोग करके प्रश्नों का उत्तर क्यों देते हैं।
दान डिपलो

2

यदि आप Linq का उपयोग ठीक से करते हैं, और इसे हुड के नीचे समझते हैं, तो आप सभी प्रकार की नई अत्याधुनिक तकनीकों को पाएंगे

इसलिए यदि आप संवर्द्धन के बारे में गहराई से सोचते हैं, तो मेरा तर्क है कि यह आपको एक बेहतर प्रोग्रामर बनाता है। किसी दिए गए प्रोग्रामर को वास्तव में ऐसा करना है या नहीं, यह लिनक की गलती नहीं है।

ऑब्जेक्ट-रिलेशनल मैपर के लिए भी यही तर्क दिया जा सकता है। क्या कोई भी वास्तव में डेटाबेस तालिकाओं के खिलाफ कच्चे एसक्यूएल प्रश्न लिखता है? :)


10
अरे, मैं कच्ची एसक्यूएल लिखता हूं ... सूँघता
हारून को

2
यदि आप जानते हैं कि आप क्या कर रहे हैं तो रॉ एसक्यूएल सबसे अच्छा दांव है।
फॉस्को

1
+1 के लिए "आपको बेहतर प्रोग्रामर बनाता है" तर्क। लाइनक को समझना और विशेष रूप से इसे समर्थन करने वाले तरीकों ने निश्चित रूप से कुछ बहुत ही उपयोगी प्रोग्रामिंग अवधारणाओं की मेरी समझ में सुधार किया है।
जॉन एम गेंट सेप

1
मुझे लगता है कि किसी ने ओआरएम बनाम कच्ची एसक्यूएल टिप्पणी के लिए अपराध किया। यह मैं नहीं था; मैं दोनों का उपयोग करता हूं, और मैंने टिप्पणी को जीभ-इन-गाल होने के रूप में समझा।
हारून

1
मैं अपने जटिल डेटाबेस प्रश्नों को उस बकवास पर कभी भरोसा नहीं करूंगा जो एक ORM लिखता है, यह साधारण सामान के लिए ठीक है, लेकिन प्रकार के प्रश्नों की रिपोर्टिंग के लिए ugh। फिर, किसी के हाथों में जो जानता है कि वे ओआरएम क्या कर रहे हैं, अच्छी बात है, किसी के हाथों में जो डेटाबेस, आपदा को समझने में बहुत आलसी है।
HLGEM

1

उन पागल चीजों में से कुछ इसलिए हैं क्योंकि लोग गलत हथौड़ा का उपयोग कर रहे हैं, अन्य इसलिए हैं क्योंकि वे एक बहुत ही शानदार सुपर-हथौड़ा का निर्माण कर रहे हैं, लेकिन वे एक विषम विस्तार में चले गए हैं जिसे दूर करने की आवश्यकता है।

उदाहरण के लिए, यदि आप दस में से नौ बार गैर-गतिशील linq के खिलाफ उपयोग करने के लिए linq का उपयोग करने के बारे में एक प्रश्न देखते हैं, तो व्यक्ति या तो बस जिज्ञासु है यदि यह संभव है, या गलत पेड़ को भौंक रहा है, लेकिन कुछ हैं ऐसी चीजें जिन्हें आप इस तरह से हल कर सकते हैं कि अन्यथा सुलझाना अनुचित नहीं है।

मैं इन प्रश्नों को दो भागों में लेता हूँ:

  1. यह किया जा सकता है, और यदि ऐसा है तो यह कैसा दिखेगा
  2. क्या यह किया जाना चाहिए, क्या कोई जोखिम है, या एक बेहतर विकल्प है

मैंने पाया है कि मैं लगभग हमेशा उन्हें उसी क्रम में करता हूं। यह प्रश्न का उत्तर देता है और संभावित विकल्पों के लिए बेहतर व्याख्या करने में भी आपकी मदद करता है।


0

मुझे डेवलपर्स के दिमाग पर कोई सुन्न प्रभाव के बारे में नहीं पता है, लेकिन दरों पर सुन्न दिमाग वाले उपकरणों / भाषाओं के प्रभाव के लिए यहां एक नज़र डालें । बार को कम करने के बारे में बात करो!


0

मैं मेसन व्हीलर से सहमत हूं। हालांकि, यह एक "अनुक्रम" पर काम करके https://stackoverflow.com/questions/3762202/get-range-of-integers-with-linq को हल करने की कोशिश करने के लिए पूरी तरह से पागल नहीं है । समस्या यह है कि जावा के .Net के पुनरावृत्तियां सभी 3 परिचालनों का समर्थन नहीं करते हैं: वर्तमान मान, अगला मान, और अगले पर जाएं। क्लोजर सभी 3 कर सकते हैं, और मुझे संदेह है कि क्लोजर में यह अधिकार करना आसान है। पायथन में भी सह-दिनचर्या है, और मैं इसे क्रैक करने की कोशिश करना चाहता हूं। http://clojure.org/fterences http://www.try-clojure.org/

वास्तव में, यदि इनपुट अनंत अनुक्रम है, जैसे कि http://oeis.org/A007401 , तो आलसी एकमात्र तरीका है।


"लाइनक" का अर्थ "पुनरावृत्तियों" नहीं है और न ही "आलसी" आवश्यक रूप से - वास्तव में, लिनक के अधिकांश अभिव्यक्ति पेड़ों के बारे में वास्तव में हैं। आप आसानी से, यदि आप चाहते थे, एक बंद के साथ अपने खुद के 3-मूल्यवान या एन-मूल्यवान एग्रीगेट को लागू कर सकते हैं और सी # में बहुत अधिक कोड नहीं। परेशानी तब होती है जब लोगों को पता नहीं होता कि वास्तव में ऐसा कैसे किया जाता है, या यहां तक ​​कि कैसे शुरू किया जाए, और बस कुछ जादू की तलाश है जो System.Linqनामस्थान में रहता है ।
आरोन

@Aaronaught ... '' '' Linq '' का अर्थ "iterators" नहीं है और न ही "आलसी" जरूरी "'' -", ठीक है, Linq SQL की तरह दिख सकता है, लेकिन यह सिंथैटिक शुगर एक वास्तविक IL कोड में संकलित करता है, जो यदि डी-संकलित है , IEnumerable [<T>] के झुंड के बराबर दिखेगा। वह सामान आलसी है और प्रगणकों का उपयोग करता है, जिसे अन्य भाषाओं में पुनरावृत्तियों कहा जाएगा। लेकिन हां, समस्या यह है कि LINQ कोडिंग को आसान बनाता है, और अयोग्य इसकी कोशिश करता है। कुछ अभी भी शायद सभ्य प्रोग्रामर बन सकते हैं। यदि C # उनकी पहली भाषा है और वे कुल नॉब हैं, तो वे एक बड़ी भाषा के साथ काम कर रहे हैं।
जॉब

ज़रूर, Linq to Objects (Linq to SQL, Linq to Entities, Linq to DataSet या Linq का कोई अन्य ब्रांच) iterators और deferred निष्पादन पर आधारित है , लेकिन यह सब हुड के नीचे है। Iterator ब्लॉक और yieldविवरण Linq से पहले मौजूद था, जैसा कि प्रतिनिधियों ने किया था। क्लोजर लिनक के रूप में एक ही रिलीज में आया था, लेकिन कुछ शुद्ध "लिनक" संचालन को वास्तव में स्थानीय चर कैप्चर की आवश्यकता होती है। पूछते हुए कि "मैं लिनक के साथ पूरी तरह से चलने वाले संचालन / कार्य का वर्णन कैसे कर सकता हूं?" दोनों ही Linq (क्या यह करने के लिए है) और भाषा ही की एक अज्ञानता पर गहरा विश्वास करता है।
आरोन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.