"के बारे में कारण करने के लिए आसान" - इसका क्या मतलब है? [बन्द है]

Question

मैंने कई बार सुना है जब अन्य डेवलपर्स उस वाक्यांश का उपयोग कुछ पैटर्न या "सर्वोत्तम प्रथाओं" को विज्ञापित करने के लिए करते हैं। अधिकांश समय इस वाक्यांश का उपयोग तब किया जाता है जब आप कार्यात्मक प्रोग्रामिंग के लाभों के बारे में बात कर रहे हों।

वाक्यांश "ईज़ी टू रीज़न" का उपयोग किसी भी स्पष्टीकरण या कोड नमूने के बिना किया गया है। तो मेरे लिए यह अगले "बज़" -शब्द की तरह हो जाता है, जो अधिक "अनुभवी" डेवलपर्स अपनी वार्ता में उपयोग करते हैं।

प्रश्न: क्या आप "के बारे में तर्क करने में आसान नहीं" के कुछ उदाहरण प्रदान कर सकते हैं, इसलिए इसकी तुलना "आसान से आसान कारण" के साथ की जा सकती है?

Comments

@MartinMaat एक अधिक सटीक वाक्यांश है जिसका व्यापक रूप से उपयोग किया जाता है, यह तर्क संगत तर्क है, मैं सुझाव दूंगा कि यह वही हो सकता है जो फैबियो के बाद है

— jk।

मैं इस तरह की चीज़ के लिए "संज्ञानात्मक भार" वाक्यांश का उपयोग करना पसंद करता हूं ।

— बाल्ड्रिक

क्या आप जानते हैं कि कार्यक्रमों के बारे में तर्क क्या है?

— बर्गी

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

— जिम्मीजेंस

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

— एरिक लिपर्ट

Answer 1

मेरे दिमाग में, वाक्यांश "आसान कारण के बारे में", कोड को संदर्भित करता है जो "आपके सिर में निष्पादित करना" आसान है।

जब कोड के एक टुकड़े को देखते हैं, अगर यह संक्षिप्त नाम, अच्छे नामों और मूल्यों के न्यूनतम उत्परिवर्तन के साथ लिखा जाता है, तो मानसिक रूप से काम करता है कि कोड क्या करता है (अपेक्षाकृत) आसान काम।

खराब नामों के साथ कोड का एक लंबा टुकड़ा, चर जो लगातार मूल्य बदलते हैं और जटिल ब्रांचिंग को आमतौर पर वर्तमान राज्य का ट्रैक रखने में मदद करने के लिए एक कलम और कागज के टुकड़े की आवश्यकता होगी। इस तरह के कोड को आसानी से सिर्फ आपके दिमाग में काम नहीं किया जा सकता है, इसलिए ऐसे कोड के बारे में तर्क करना आसान नहीं है।

Comments

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

— स्टीव जेसप

मैं अपने सिर में कोड निष्पादित नहीं करना चाहता। मेरे लिए, "के बारे में तर्क करना आसान नहीं है" का अंतिम शो होगा। मैं इस बारे में भविष्यवाणियां करने में सक्षम होना चाहता हूं कि कंप्यूटर इसे निष्पादित किए बिना क्या करेगा । कोड जो "के बारे में तर्क करना आसान है" कोड है जिसे आपके सिर में निष्पादित नहीं किया जाना है, इसके बजाय इसके बारे में तर्क दिया जा सकता है।

— Cort Ammon

औपचारिक सत्यापन का उल्लेख किए बिना भी कोड के बारे में तर्क के बारे में एक प्रश्न का उत्तर कैसे दिया जा सकता है ? यह उत्तर बताता है कि कोड के बारे में तर्क अनौपचारिक और तदर्थ है। यह नहीं है, इसका आमतौर पर बहुत ध्यान और गणितीय दृष्टिकोण के साथ किया जाता है। कुछ गणितीय गुण हैं जो एक वस्तुगत अर्थ में कोड "के बारे में तर्क करने में आसान" (शुद्ध कार्य, बहुत आसान उदाहरण लाने के लिए) बनाते हैं। चर का नाम है कुछ भी नहीं है कम से कम कोई औपचारिक अर्थ में नहीं, कितना आसान है "कारण" कोड के बारे में करने के लिए है के साथ क्या करना।

— पॉलीगनॉम

@Polygnome कोड के बारे में तर्क आमतौर पर बहुत महान देखभाल और गणितीय दृष्टिकोण के साथ नहीं किया जाता है। जैसा कि मैंने यह लिखा है, कोड के बारे में अनौपचारिक रूप से लोग गणितीय दृष्टिकोणों को लाखों से एक, कम से कम, या इसलिए मैं अनुमान लगा रहे हैं।

— कज़

@Polygnome "Code easy to reason about" almost exclusively alludes to its mathematical properties and formal verification- यह मोटे तौर पर सवाल के जवाब की तरह लगता है। आप टिप्पणी में (व्यक्तिपरक) उत्तर के बारे में असहमत होने के बजाय एक उत्तर के रूप में पोस्ट करना चाह सकते हैं।

— जुगल

Answer 2

एक तंत्र या कोड का टुकड़ा इस बारे में तर्क करना आसान है कि जब आपको यह अनुमान लगाने के लिए कुछ चीजों को ध्यान में रखना होगा कि यह क्या करेगा, और जिन चीजों को आपको ध्यान में रखने की आवश्यकता है, वे आसानी से उपलब्ध हैं।

कोई साइड इफेक्ट्स और कोई राज्य के साथ सही कार्य करना आसान नहीं है क्योंकि आउटपुट पूरी तरह से इनपुट द्वारा निर्धारित किया जाता है, जो कि मापदंडों में वहीं है।

इसके विपरीत, राज्य के साथ एक वस्तु के बारे में तर्क करना बहुत कठिन है, क्योंकि आपको इस बात पर ध्यान देना होगा कि किसी विधि को किस स्थिति में कहा जाता है, जिसका अर्थ है कि आपको यह सोचना होगा कि किन स्थितियों में वस्तु को अंदर ले जाया जा सकता है। विशेष राज्य।

इससे भी बदतर वैश्विक चर हैं: एक वैश्विक चर को पढ़ने वाले कोड के बारे में तर्क करने के लिए, आपको यह समझने की आवश्यकता है कि आपके कोड में कहां परिवर्तनशील सेट किया जा सकता है और क्यों - और उन सभी स्थानों को ढूंढना भी आसान नहीं हो सकता है।

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

Comments

मैं इस उत्तर से सहमत हूं, लेकिन यहां तक ​​कि शुद्ध कार्यों के साथ, घोषणात्मक दृष्टिकोण (जैसे सीएसएस, या एक्सएसएलटी, makeया यहां तक ​​कि सी ++ टेम्पलेट विशेषज्ञता और फ़ंक्शन ओवरलोडिंग) आपको पूरे कार्यक्रम पर विचार करने की स्थिति में वापस रख सकते हैं। यहां तक ​​कि एक बार जब आपको लगता है कि आपने किसी चीज़ की परिभाषा पा ली है, तो भाषा इसे ओवरराइड करने के लिए कार्यक्रम में कहीं भी अधिक विशिष्ट घोषणा की अनुमति देती है। आपकी आईडीई इसमें मदद कर सकती है।

— स्टीव जेसोप

मुझे लगता है कि बहुपरत परिदृश्य में आपको यह भी समझना होगा कि आपके कोड के निचले स्तर को क्या निर्देश देते हैं, इसकी एक गहरी समझ है: एक ऑपरेशन जो स्रोत में परमाणु दिखता है, वास्तविक निष्पादन में अप्रत्याशित रुकावट बिंदु हो सकता है।

— जेरेड स्मिथ

@SteveJessop: वास्तव में, इस बिंदु को अक्सर अनदेखा किया जाता है। एक कारण है कि C # आपको यह कहता है कि जब आप चाहते हैं कि चुपचाप डिफ़ॉल्ट रूप से ओवरराइड करने के बजाय एक तरीका अधिक से अधिक उपयोग योग्य हो; हम यह कहते हुए एक झंडा लहराना चाहते हैं कि "आपके कार्यक्रम की शुद्धता उस कोड पर निर्भर हो सकती है जो आप संकलन समय पर नहीं पा सकते हैं"। (उस ने कहा, मैं यह भी चाहता हूं कि "सील" सी # में कक्षाओं के लिए डिफ़ॉल्ट था।)

— एरिक लिपर्ट

@EricLippert sealedडिफ़ॉल्ट न होने के अंतिम कारण क्या थे ?

— ज़ेव स्पिट्ज़

@ZevSpitz: यह निर्णय मेरे समय से बहुत पहले किया गया था; मुझे नहीं पता।

— एरिक लिपर्ट

Answer 3

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

दूसरी ओर, OO आमतौर पर इस कारण से अधिक कठिन होता है क्योंकि उत्पादित "आउटपुट" प्रत्येक शामिल ऑब्जेक्ट की आंतरिक स्थिति पर निर्भर करता है। विशिष्ट तरीके से यह प्रकट होता है अप्रत्याशित दुष्प्रभाव : जब कोड के एक हिस्से को बदलते हैं, तो एक दिखाई देने वाला असंबंधित हिस्सा टूट जाता है।

... कार्यात्मक प्रोग्रामिंग का नकारात्मक पहलू यह है कि व्यवहार में, आप जो करना चाहते हैं वह बहुत कुछ है IO और प्रबंध राज्य।

हालांकि, बहुत सी अन्य चीजें हैं जिनके बारे में तर्क करना अधिक कठिन है, और मैं @Kilian से सहमत हूं कि संगामिति एक प्रमुख उदाहरण है। वितरित सिस्टम भी।

Answer 4

व्यापक चर्चा से बचना, और विशिष्ट प्रश्न को संबोधित करना:

क्या आप "के बारे में तर्क करने में आसान नहीं" के कुछ उदाहरण प्रदान कर सकते हैं, इसलिए इसकी तुलना "आसान से तर्क के बारे में" उदाहरणों से की जा सकती है?

मैं आपको "द स्टोरी ऑफ मेल, ए रियल प्रोग्रामर" का उल्लेख करता हूं , जो प्रोग्रामर लोकगीत का एक हिस्सा है जो 1983 से शुरू होता है और इसलिए हमारे पेशे के लिए 'किंवदंती' के रूप में गिना जाता है।

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

एक स्पष्ट अनंत लूप वास्तव में इस तरह से कोडित किया गया था जैसे कि कैरी-ओवरफ्लो त्रुटि का लाभ उठाने के लिए। 1 को एक निर्देश में जोड़ना जो "पता x से लोड" के रूप में डिकोड किया गया, सामान्य रूप से "पता x + 1 से लोड" प्राप्त हुआ। लेकिन जब एक्स पहले से ही सबसे अधिक संभव पता था, तो न केवल पते को शून्य के आसपास लपेट दिया गया था, बल्कि 1 को बिट्स में ले जाया गया था, जिसमें से ओपकोड को पढ़ा जाएगा, जिसमें ओपकोड को "लोड" से "जंप" तक बदल दिया जाएगा। कि पूरा निर्देश "आखिरी पते से लोड" से "शून्य को संबोधित करने के लिए कूद" में बदल गया।

यह कोड का एक उदाहरण है जो 'के बारे में तर्क करना मुश्किल है'।

बेशक, मेल असहमत होगा ...

Comments

+1 मेल की कहानी को संदर्भित करने के लिए, मेरे बारहमासी पसंदीदा में से एक।

— जॉन बोलिंगर

मेल की कहानी यहां पढ़ें , क्योंकि विकिपीडिया लेख इससे लिंक नहीं करता है।

— TRIG

पेज पर @TRiG फुटनोट 3, नहीं?

— आकाशम

@AakashM किसी तरह यह याद करने में कामयाब रहे।

— TRIG

Answer 5

मैं एक उदाहरण प्रदान कर सकता हूं, और एक बहुत ही सामान्य।

निम्नलिखित सी # कोड पर विचार करें।

// items is List<Item>
var names = new List<string>();
for (var i = 0; i < items.Count; i++)
{
    var item = items[i];
    var mangled = MyMangleFunction(item.Name);
    if (mangled.StartsWith("foo"))
    {
        names.Add(mangled);
    }
}

अब इस विकल्प पर विचार करें।

// items is List<Item>
var names = items
    .Select(item => MyMangleFunction(item.Name))
    .Where(s => s.StartsWith("foo"))
    .ToList();

दूसरे उदाहरण में, मुझे पता है कि यह कोड एक नज़र में क्या कर रहा है। जब मैं देखता हूं Select, मुझे पता है कि वस्तुओं की एक सूची को किसी और चीज की सूची में परिवर्तित किया जा रहा है। जब मैं देखता हूं Where, मुझे पता है कि कुछ वस्तुओं को फ़िल्टर किया जा रहा है। एक नज़र में, मैं समझ सकता हूं कि क्या namesहै और इसका प्रभावी उपयोग करना है।

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

अंत में, यहाँ के बारे में तर्क करना आसान होना भी LINQ तरीकों Selectऔर समझने पर निर्भर करता है Where। यदि आप उन्हें नहीं जानते हैं, तो दूसरा कोड शुरू में तर्क करना कठिन है। लेकिन आप उन्हें केवल एक बार समझने की कीमत चुकाते हैं। forजब भी आप एक बार उपयोग करते हैं और हर बार बदलते हैं, तो आप एक लूप को समझने की लागत का भुगतान करते हैं। कभी-कभी लागत का भुगतान करने लायक होता है, लेकिन आमतौर पर "आसान कारण के बारे में" अधिक महत्वपूर्ण होता है।

Answer 6

एक संबंधित वाक्यांश (I paraphrase) है,

यह कोड के लिए " कोई स्पष्ट कीड़े नहीं है" के लिए पर्याप्त नहीं है : इसके बजाय, इसमें " स्पष्ट रूप से कोई बग " नहीं होना चाहिए ।

RAII हो सकता है "अपेक्षाकृत आसान कारण" के बारे में एक उदाहरण ।

एक अन्य उदाहरण घातक आलिंगन से बच सकता है : यदि आप एक ताला पकड़ सकते हैं और दूसरा ताला प्राप्त कर सकते हैं, और बहुत सारे ताले हैं, तो यह सुनिश्चित करना मुश्किल है कि कोई परिदृश्य नहीं है जिसमें घातक आलिंगन हो सकता है। एक नियम जोड़ना जैसे "केवल एक (वैश्विक) लॉक" है, या, "जब आप एक पहला लॉक रखते हैं तो आपको दूसरा लॉक हासिल करने की अनुमति नहीं होती है", इस प्रणाली को अपेक्षाकृत आसान बनाता है।

Comments

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

— कॉडी ग्रे

मेरा मतलब था अपेक्षाकृत आसान (C ++ की तुलना में C): उदाहरण के लिए भाषा-समर्थित कंस्ट्रक्टर के अस्तित्व का मतलब है कि प्रोग्रामर एक ऐसी वस्तु का निर्माण / उपयोग / उपयोग नहीं कर सकते हैं जिसे वे प्रारंभ करना भूल जाते हैं, आदि

— क्रिसडब्ल्यू

यह COM-आधारित उदाहरण समस्याग्रस्त है क्योंकि यह शैलियों, यानी C ++ - शैली स्मार्ट पॉइंटर ( CComPtr<>) को C- शैली फ़ंक्शन ( CoUninitialize()) के साथ मिलाता है । मुझे यह एक विचित्र उदाहरण लगता है, भी, जहां तक ​​मुझे याद है कि आप मॉड्यूल दायरे में CoInitialize / CoUninitialize का आह्वान करते हैं और पूरे मॉड्यूल जीवनकाल के लिए, उदाहरण के लिए mainया DllMainकुछ छोटे अल्पकालिक स्थानीय फ़ंक्शन में नहीं, जैसा कि उदाहरण में दिखाया गया है ।

— क्रिस डब्ल्यूडब्ल्यू

यह उदाहरण के उद्देश्यों के लिए एक अत्यधिक सरल उदाहरण है। आप पूरी तरह से सही हैं कि COM को मॉड्यूल के दायरे में शुरू किया गया है, लेकिन mainएक आवेदन के लिए प्रवेश बिंदु ( ) फ़ंक्शन होने के नाते रेमंड के उदाहरण (लैरी के उदाहरण की तरह) की कल्पना करें । आप स्टार्टअप पर COM को इनिशियलाइज़ करते हैं, और फिर बाहर निकलने से ठीक पहले आप इसे अनइंस्टॉल कर देते हैं। आपके पास वैश्विक वस्तुएं हैं, जैसे COM स्मार्ट पॉइंटर्स, RAII प्रतिमान का उपयोग करके। मिक्सिंग स्टाइल्स के बारे में: एक वैश्विक वस्तु जो COM को इसके ctor में इनिशियलाइज़ करती है और इसके डोर में uninitialized काम करने योग्य है, और रेमंड सुझाव देता है, लेकिन यह सूक्ष्म और आसान नहीं है।

— कोडी ग्रे

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

— कोडी ग्रे

Answer 7

प्रोग्रामिंग का क्रूस केस विश्लेषण है। एलन पेर्लिस ने एपिग्राम # 32 में इस पर टिप्पणी की: प्रोग्रामर को उनकी सरलता और उनके तर्क से नहीं बल्कि उनके मामले के विश्लेषण की पूर्णता से मापा जाना चाहिए।

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

उदाहरण के लिए, एल्गोरिथ्म का एक पुनरावर्ती संस्करण, आमतौर पर एक अपरिमेय संस्करण की तुलना में तर्क करना आसान होता है, क्योंकि यह उन अतिसारी मामलों में योगदान नहीं करता है, जो सहायक राज्य चर के म्यूटेशन के माध्यम से उत्पन्न होते हैं जो पुनरावर्ती वर्जन में प्रकट नहीं होते हैं। इसके अलावा, पुनरावृत्ति की संरचना ऐसी है कि यह एक गणितीय प्रूफ-बाय-इंडक्शन पैटर्न में फिट बैठता है। हमें लूप वेरिएंट जैसी जटिलताओं पर विचार करने की जरूरत नहीं है और सबसे सख्त पूर्व शर्त और कमजोर नहीं है।

इसका एक अन्य पहलू केस स्पेस की संरचना है। ऐसी स्थिति के बारे में तर्क करना आसान है, जिसमें एक पदानुक्रमित मामले की स्थिति की तुलना में मामलों में फ्लैट, या ज्यादातर फ्लैट विभाजन है: उप-मामलों और उप-उप मामलों के साथ मामले और इतने पर।

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

Answer 8

ज़रूर। संगामिति लें:

म्यूटेक्स द्वारा लागू किए गए महत्वपूर्ण खंड: यह समझना आसान है क्योंकि केवल एक सिद्धांत है (निष्पादन के दो धागे महत्वपूर्ण खंड में एक साथ प्रवेश नहीं कर सकते हैं), लेकिन अक्षमता और गतिरोध दोनों का खतरा है।

वैकल्पिक मॉडल, जैसे लॉक-फ्री प्रोग्रामिंग या एक्टर्स: संभवतः बहुत अधिक सुरुचिपूर्ण और शक्तिशाली, लेकिन समझने में मुश्किल है, क्योंकि आप अब (प्रतीत होता है) मूलभूत अवधारणाओं पर भरोसा नहीं कर सकते हैं जैसे कि "अब उस स्थान पर यह मान लिखें"।

किसी कारण के लिए आसान होना एक विधि का एक पहलू है। लेकिन किस विधि का उपयोग करने के लिए संयोजन में सभी पहलुओं पर विचार करने की आवश्यकता है ।

Comments

-1: वास्तव में, वास्तव में बुरा उदाहरण जो मुझे लगता है कि आपको समझ में नहीं आता है कि वाक्यांश का अर्थ क्या है। "म्यूटेक्स द्वारा लागू किए गए महत्वपूर्ण खंड" वास्तव में सबसे कठिन चीजों में से एक हैं, जिनके बारे में तर्क करने के लिए - बहुत ज्यादा हर कोई जो उनका उपयोग करता है वह दौड़ की स्थिति या गतिरोध का परिचय देता है। मैं आपको लॉक-फ्री प्रोग्रामिंग दूंगा, लेकिन अभिनेता मॉडल के पूरे लानत की बात यह है कि इसके बारे में तर्क करना बहुत आसान है।

— माइकल बोर्गवर्ड

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

— कोडी ग्रे

Answer 9

आइए हम कार्य को औपचारिक तर्क तक सीमित करें। क्योंकि हास्य या आविष्कार या काव्यात्मक तर्क के अलग-अलग कानून हैं।

फिर भी, अभिव्यक्ति को स्पष्ट रूप से परिभाषित किया गया है, और इसे सख्त तरीके से सेट नहीं किया जा सकता है। लेकिन इसका मतलब यह नहीं है कि यह हमारे लिए इतना मंद रहना चाहिए। आइए हम कल्पना करें कि एक संरचना कुछ परीक्षण से गुजर रही है और विभिन्न बिंदुओं के लिए अंक प्राप्त कर रही है। हर बिंदु के लिए अच्छे अंक का मतलब है कि संरचना हर पहलू में सुविधाजनक है और इस प्रकार, "आसान कारण के बारे में"।

संरचना "आसान कारण के बारे में" निम्नलिखित के लिए अच्छे अंक प्राप्त करना चाहिए:

• आंतरिक शब्दों में उचित, आसानी से प्रतिष्ठित और परिभाषित नाम हैं। यदि तत्वों में कुछ पदानुक्रम है, तो माता-पिता और बच्चे के नामों के बीच का अंतर भाई-बहन के नामों के बीच के अंतर से अलग होना चाहिए।
• संरचनात्मक तत्वों के प्रकार की संख्या कम है
• प्रयुक्त प्रकार के संरचनात्मक तत्व आसान चीजें हैं जिनके हम आदी हैं।
• शायद ही समझ में आने वाले तत्व (पुनरावृत्तियां, मेटा स्टेप्स, 4+ डायमेंशनल ज्योमेट्री ...) अलग-थलग हैं - सीधे एक-दूसरे के साथ नहीं। (उदाहरण के लिए, यदि आप 1,2,3,4..n..dimensional क्यूब्स के लिए बदल रहे कुछ पुनरावर्ती नियम पर सोचने की कोशिश करेंगे, तो यह बहुत जटिल होगा। लेकिन यदि आप इनमें से प्रत्येक नियम को किसी सूत्र में बदल देंगे। एन के आधार पर, आपके पास प्रत्येक एन-क्यूब के लिए अलग से एक सूत्र होगा और अलग से इस तरह के फॉर्मूले के लिए एक पुनरावर्ती नियम होगा। और यह कि दो संरचनाओं के बारे में आसानी से सोचा जा सकता है)
• संरचनात्मक तत्वों के प्रकार स्पष्ट रूप से भिन्न होते हैं (उदाहरण के लिए, 0 और 1 से शुरू होने वाली मिश्रित सरणियों का उपयोग नहीं करना)

परीक्षण व्यक्तिपरक है? हाँ, स्वाभाविक रूप से यह है। लेकिन अभिव्यक्ति भी व्यक्तिपरक है। एक व्यक्ति के लिए क्या आसान है, दूसरे के लिए आसान नहीं है। इसलिए, विभिन्न डोमेन के लिए परीक्षण अलग-अलग होने चाहिए।

Answer 10

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

एक तर्क प्रणाली के उदाहरण के लिए, पीआई-कैलकुलस में, एक अनिवार्य भाषा में प्रत्येक उत्परिवर्तनीय स्मृति स्थान को एक अलग समानांतर प्रक्रिया के रूप में प्रस्तुत किया जाना चाहिए, जबकि कार्यात्मक संचालन का एक क्रम एक एकल प्रक्रिया है। LFC प्रमेय कहावत से चालीस साल बाद, हम GB के साथ काम कर रहे हैं, इसलिए सैकड़ों प्रक्रियाएँ एक समस्या से कम नहीं हैं - मैंने C ++ की कुछ सौ लाइनों से संभावित गतिरोधों को दूर करने के लिए पाई-कलन का उपयोग किया है, प्रतिनिधित्व सैकड़ों होने के बावजूद। प्रक्रियाकर्ता ने लगभग 3GB में राज्य स्थान को खाली कर दिया और एक आंतरायिक बग को ठीक कर दिया। यह 70 के दशक में असंभव था या 1990 के दशक की शुरुआत में एक सुपर कंप्यूटर की आवश्यकता थी, जबकि समान आकार के एक कार्यात्मक भाषा कार्यक्रम का राज्य स्थान तब तक वापस करने के लिए पर्याप्त छोटा था।

अन्य उत्तरों से, वाक्यांश वाक्यांश-वाक्यांश बन रहा है, भले ही बहुत कठिनाई जिसने इसे अनिवार्य भाषाओं के बारे में तर्क करना कठिन बना दिया हो, मूर के नियम से मिट जाता है।

Answer 11

के बारे में आसान कारण सांस्कृतिक रूप से विशिष्ट शब्द है, यही कारण है कि ठोस उदाहरणों के साथ आना बहुत मुश्किल है। यह एक शब्द है, जो लोगों को तर्क करने के लिए लंगर डाला जाता है।

"के बारे में कारण करने के लिए आसान" वास्तव में एक बहुत ही आत्म वर्णनात्मक वाक्यांश है। यदि कोई कोड को देख रहा है, और यह क्या करना चाहता है, तो यह आसान है =)

ठीक है, इसे तोड़कर। यदि आप कोड देख रहे हैं, तो आप आमतौर पर कुछ करना चाहते हैं। आप यह सुनिश्चित करना चाहते हैं कि यह वही करे जो आपको लगता है कि इसे करना चाहिए। तो आप इस सिद्धांत को विकसित करते हैं कि कोड क्या होना चाहिए, और फिर आप इसके बारे में तर्क करने की कोशिश करने का कारण बनाते हैं कि कोड वास्तव में क्यों काम करता है। आप एक मानव की तरह कोड के बारे में सोचने की कोशिश करते हैं (बल्कि कंप्यूटर की तरह) और कोड क्या कर सकते हैं इसके बारे में तर्क को तर्कसंगत बनाने का प्रयास करें।

"आसान से तर्क" के लिए सबसे खराब स्थिति यह है कि कोड के सभी तरीकों के लिए ट्यूरिंग मशीन की तरह कोड के माध्यम से लाइन-बाय-लाइन जाने के लिए कोई मतलब नहीं है। इस मामले में, कोड के बारे में कुछ भी करने का एकमात्र तरीका खुद को कंप्यूटर में बदलना और इसे अपने सिर में निष्पादित करना है। ये सबसे खराब स्थिति के उदाहरण अस्पष्ट प्रोग्रामिंग प्रतियोगिताओं में आसानी से देखे जाते हैं, जैसे कि पेरोल की ये 3 लाइनें जो आरएसए को डिक्रिप्ट करती हैं:

#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

जैसा कि आसान कारण है, फिर से, यह शब्द अत्यधिक सांस्कृतिक है। आपको विचार करना होगा:

• तर्ककर्ता के पास क्या कौशल है? कितना अनुभव?
• कोड के बारे में तर्ककर्ता के पास किस प्रकार के प्रश्न हो सकते हैं?
• कैसे निश्चित करने के लिए तर्क की आवश्यकता है?

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

यह भी विचार करें कि पाठक के पास क्या मुहावरे हो सकते हैं। यदि आप किसी विशेष सिंटैक्स में FFT को पहचानने के लिए अपने रीडर पर भरोसा कर सकते हैं, तो कोड के बारे में "आसान कारण" है यदि आप उस सिंटैक्स से चिपके रहते हैं। यह उन्हें टेक्स्ट फाइल को कैनवास के रूप में देखने देता है, जिसे आपने एफआईटी पर चित्रित किया है, न कि किटी ग्रिट्टी विवरण में लाने के बजाय। यदि आप C ++ का उपयोग कर रहे हैं, तो पता करें कि आपके पाठक stdपुस्तकालय के साथ कितने सहज हैं । वे कार्यात्मक प्रोग्रामिंग को कितना पसंद करते हैं? कुछ मुहावरे जो कंटेनरों के पुस्तकालयों से निकलते हैं, बहुत निर्भर करते हैं कि आप किस मनोहारी शैली को पसंद करते हैं।

यह समझने में भी महत्वपूर्ण है कि पाठक किस तरह के प्रश्नों का उत्तर देने में दिलचस्पी ले सकता है। क्या आपके पाठक ज्यादातर कोड की सतही समझ से चिंतित हैं, या वे आंतों में गहरे कीड़े की तलाश कर रहे हैं?

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

Comments

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

— कज़