कार्यों के लिए पारित तर्कों की मात्रा पर आधारित एक भाषा

Question

यह विचार तथ्य संचालक जैसे +, -,% इत्यादि से प्रेरित है, या तो एक या दो तर्कों के साथ कार्य किए जा सकते हैं, और कोई दुष्प्रभाव नहीं। I या किसी और को मानकर, एक ऐसी भाषा लिखता है जो दो से अधिक तर्कों को पारित होने से रोकती है, और केवल रिटर्न वैल्यू के माध्यम से भी काम करती है:

a) क्या ऐसी भाषा से कोड समझने में आसानी होगी?

बी) कोड का प्रवाह स्पष्ट होगा? (अधिक चरणों में मजबूर, संभावित कम बातचीत के साथ 'छिपा'

ग) क्या प्रतिबंधों से भाषा अधिक जटिल कार्यक्रमों के लिए भारी हो जाएगी।

घ) (बोनस) पेशेवरों / विपक्ष पर कोई अन्य टिप्पणी

ध्यान दें:

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

Comments

नमस्ते। पेशेवरों और विपक्षों की सूची खराब उत्तर देने के लिए है। क्या कोई तरीका है जिससे आप अपने प्रश्न को पुनः प्राप्त कर सकते हैं फिर भी आपको जो जानकारी चाहिए वह प्राप्त कर सकते हैं लेकिन दूसरे प्रारूप में?

— मेटाफाइट

आपका तर्क भी मेरे लिए समझ में नहीं आता है। कुछ कार्यों के कुछ तर्क होते हैं तो चलो सभी कार्यों को सीमित करते हैं? आम तौर पर जब कोई मनमाना प्रतिबंध लगाता है, तो एक कारण होता है, कुछ हासिल करना होता है। मैं यह नहीं देख सकता कि यह आपको क्या लाभ दिला सकता है।

ऐसा नहीं है कि 'क्या अगर' सवाल के साथ स्वाभाविक रूप से कुछ भी गलत है (हालांकि वे कभी-कभी @MetaFight कहा के रूप में जवाब देने के लिए कठिन हैं), लेकिन अगर आप भी, जो बात के बारे में सोचा था और एक सवाल पूछने के लिए पर्याप्त परवाह की, वास्तव में कोई नाम नहीं दे सकता लाभ, तो मुझे यकीन है कि मेरी प्रारंभिक प्रतिक्रिया "क्या? नहीं! यह बेवकूफ है कि आप ऐसा क्यों करेंगे" सटीक है।

काफी कुछ भाषाएं हैं जो प्रति फ़ंक्शन केवल एक तर्क की अनुमति देती हैं: लैम्ब्डा कैलकुलस पर आधारित कुछ भी। परिणाम आमतौर पर एक फ़ंक्शन होता है जो एकल सूची तर्क देता है, या एक फ़ंक्शन ऐसा फ़ंक्शन देता है जो अगले तर्क लेता है जब तक कि सभी तर्क संसाधित नहीं किए जाते हैं result = f(a)(b)…(z):। एमएल लैंग्वेज परिवार जैसे हास्केल में यह मामला है, लेकिन यह वैचारिक रूप से अन्य भाषाओं जैसे लिस्प, जावास्क्रिप्ट, या पर्ल में भी है।

— अमन

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

— Jörg डब्ल्यू मित्तग

Answer 1

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

बॉब मार्टिन कहाँ है IMHO सही है: एक कोड गंध के लिए 3 या अधिक पैरामीटर वाले कार्य अक्सर संकेतक होते हैं। बहुत सारे मामलों में, मापदंडों को एक संयुक्त डेटाटाइप बनाने के लिए एक साथ रखा जा सकता है, अन्य मामलों में, यह फ़ंक्शन के लिए एक संकेतक हो सकता है बस बहुत अधिक कर रहा है।

हालाँकि, मुझे नहीं लगता कि इसके लिए एक नई भाषा का आविष्कार करना एक अच्छा विचार होगा:

• यदि आप वास्तव में अपने कोड में इस तरह के नियम को लागू करना चाहते हैं, तो आपको बस मौजूदा भाषा के लिए एक कोड विश्लेषण उपकरण की आवश्यकता है, इसके लिए पूरी तरह से नई भाषा का आविष्कार करने की आवश्यकता नहीं है (उदाहरण के लिए, C # 'fxcop' जैसी किसी चीज का शायद उपयोग किया जा सकता है। )।

• कभी-कभी, एक नए प्रकार के मापदंडों को संयोजित करना केवल परेशानी के लायक नहीं लगता है, या यह एक शुद्ध कृत्रिम संयोजन बन जाएगा। उदाहरण के लिए, .net ढांचे से यह File.Openविधि देखें । यह चार पैरामीटर लेता है, और मुझे पूरा यकीन है कि उस एपीआई के डिजाइनरों ने जानबूझकर ऐसा किया था, क्योंकि उन्हें लगा था कि यह कार्य करने के लिए विभिन्न मापदंडों को प्रदान करने का सबसे व्यावहारिक तरीका होगा।

• कभी-कभी वास्तविक विश्व परिदृश्य होते हैं जहां 2 से अधिक पैरामीटर तकनीकी कारणों से चीजों को सरल बनाते हैं (उदाहरण के लिए, जब आपको मौजूदा एपीआई के लिए 1: 1 मैपिंग की आवश्यकता होती है जहां आप सरल डेटाटाइप्स के उपयोग के लिए बाध्य होते हैं, और अलग-अलग संयोजन नहीं कर सकते हैं एक कस्टम ऑब्जेक्ट में पैरामीटर)

Comments

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

— पीटर बी

@ पीटर: बेशक, मेरा संपादन देखें।

— डॉक ब्राउन

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

— jpmc26

@ jpmc26: दूसरे दृष्टिकोण से, एक कोड गंध एक संभावित समस्या है, न कि किसी एक का संकेत; ;-) यह सब कोड गंध की सटीक परिभाषा पर निर्भर करता है (और एक बार जब यह बदबू आती है, तो यह खराब हो गया है, नहीं ?)

— हॉफमैले

@PieterB क्या वास्तव में कोई ऐसा करता है? अब आपको हर बार एक नया व्यक्ति उदाहरण तैयार करना होगा जब आप बीएमआई की गणना दो मनमाने मूल्यों के साथ करना चाहते हैं। निश्चित रूप से, यदि आपका आवेदन पहले से ही शुरू करने के लिए व्यक्तियों का उपयोग करता है और आप अपने आप को अक्सर कुछ ऐसा कर पाते हैं जैसे कि f (person.length, person.height) तो आप इसे थोड़ा साफ कर सकते हैं लेकिन विशेष रूप से समूह मापदंडों के लिए नई वस्तुओं का निर्माण करना अधिक मुश्किल लगता है।

— कानूनविद

Answer 2

बहुत सारी भाषाएं हैं जो पहले से ही इस तरह से काम करती हैं, जैसे हास्केल। हास्केल में, प्रत्येक फ़ंक्शन ठीक एक तर्क लेता है और ठीक एक मान देता है।

एक फ़ंक्शन को बदलना हमेशा संभव होता है जो एक फ़ंक्शन के साथ n तर्क लेता है जो n-1 तर्क लेता है और एक फ़ंक्शन देता है जो अंतिम तर्क लेता है। इसे पुनरावर्ती रूप से लागू करना, एक फ़ंक्शन को प्रतिस्थापित करना हमेशा संभव होता है जो एक फ़ंक्शन के साथ मनमानी संख्या लेता है जो बिल्कुल एक तर्क लेता है। और यह परिवर्तन एक एल्गोरिथ्म द्वारा, यंत्रवत् रूप से किया जा सकता है।

इसे हास्केल करी ने 1950 के दशक में बड़े पैमाने पर शोध किया, मूसा स्कॉफिंकेल, जिन्होंने इसे 1924 में वर्णित किया, और गोटलोब फ्रेज, जिन्होंने 1893 में इसका पूर्वाभास किया था, के बाद इसे फ्रेज-स्कोनफिंकलिंग, शॉनफिंकलिंग, शॉनफिंकल-करी, या करींग कहा जाता है।

दूसरे शब्दों में, तर्कों की संख्या को सीमित करने से शून्य प्रभाव पड़ता है।

Comments

यदि आप फ़ंक्शन को वापस करने की अनुमति देते हैं, तो निश्चित रूप से। यहां तक ​​कि अगर नहीं, तो आपको केवल इतना करना होगा कि अगला कार्यक्रम मुख्य कार्यक्रम में बुलाया जाएगा। यानी आपके पास 1 + 1 + 1 हो सकता है जहां पहला जोड़ एक फ़ंक्शन है जो अतिरिक्त जोड़ के लिए एक फ़ंक्शन देता है, या इसे बस दो बार कहा जा सकता है। बाद की शैली होगी, सिद्धांत रूप में, क्लीनर, या क्या मैं गलत हूं?

"बिल्कुल शून्य प्रभाव पड़ता है" - ओपी का सवाल था कि क्या कोड की रीडिबिलिटी बढ़ेगी या घटेगी, और मुझे लगता है कि आप दावा नहीं करते कि किसी भाषा के लिए इस तरह के डिजाइन निर्णय का उस पर कोई प्रभाव नहीं पड़ता है, क्या आप?

— डॉक ब्राउन

@DocBrown शालीन शक्ति और ऑपरेटर के साथ ओवरलोडिंग के कारण, मैं एक करी भाषा ले सकता हूं और इसे एक अविवाहित भाषा की तरह बना सकता हूं। उदाहरण: एक श्रृंखला शुरू करने के लिए f *(call_with: a,b,c,d,e) अधिभार call_with :, श्रृंखला ,का विस्तार करने के लिए, और *LHS पर श्रृंखला के fप्रत्येक सामग्री को एक बार में पारित करके आह्वान करना । एक पर्याप्त रूप से कमजोर ऑपरेटर ओवरलोडिंग सिस्टम सिर्फ वाक्यविन्यास को बोझिल बनाता है, लेकिन यह ऑपरेटर की गलती से कुछ भी अधिक लोड हो रहा है।

— याक

वास्तव में, हास्केल की करी एक फ़ंक्शन के लिए n तर्कों के साथ एक फ़ंक्शन को कम करती है, जिसमें एक तर्क n - 1 तर्कों के साथ दूसरे फ़ंक्शन को वापस करता है।

— रेयान रीच

@RyanReich आप सही हैं कि आप अपने प्रकार हस्ताक्षर में हास्केल फ़ंक्शन के "तर्कों की संख्या" का "भूत" देख सकते हैं। यह एक सच्चे हस्ताक्षर के बजाय एक भूत है क्योंकि सामान्य तौर पर आपके पास यह जानने का कोई तरीका नहीं है कि हस्ताक्षर में अंतिम प्रकार का चर भी एक फ़ंक्शन प्रकार है। किसी भी दर पर, यह भूत वहां होने से इस तथ्य को अमान्य नहीं किया जाता है कि हास्केल में सभी फ़ंक्शन 1 तर्क लेते हैं और या तो एक गैर-फ़ंक्शन मान या कोई अन्य फ़ंक्शन लौटाते हैं जो 1 तर्क भी लेता है। इसे ->:: a-> b-> c - a -> (b-> c) की संगति में बनाया गया है। इसलिए आप यहां ज्यादातर गलत हैं।

— इयान

Answer 3

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

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

Comments

आह, इसलिए यह सरणियों को खुद के साथ बातचीत करने की अनुमति देता है।

Answer 4

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

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

आपको यह भी जानना होगा कि प्रोग्रामर आपकी बाधाओं के आसपास काम करेंगे । यदि उन्हें 3 या अधिक तर्कों की आवश्यकता होती है, तो वे उन्हें कम-तर्क कॉल में बदलने के लिए करी जैसी तकनीकों का उपयोग करेंगे। हालांकि, यह अक्सर इसे सुधारने के बजाय पठनीयता की कीमत पर आता है।

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

Comments

यह सबसे अच्छा जवाब है।

— जेरेड स्मिथ

Answer 5

आपको दो चीजों की आवश्यकता होगी:

• समापन
• समग्र डेटा प्रकार

मैं Jörg W Mittag द्वारा लिखित उत्तर को समझाने के लिए एक गणितीय उदाहरण जोड़ूंगा ।

गौसियन फ़ंक्शन पर विचार करें ।

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

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

दूसरे चरण में, हम एक समग्र डेटा प्रकार बनाते हैं जो माध्य और विचरण को एक चीज में जोड़ता है।

तीसरे चरण में, हम दूसरे चरण में बनाए गए समग्र डेटा प्रकार से बंधे गॉसियन फ़ंक्शन के एक क्लोजर को बनाकर गाऊसी फ़ंक्शन का एक पैरामीटर बनाते हैं।

अंत में, हम तीसरे चरण में बनाए गए क्लोजर का मूल्यांकन करते हैं, जो इसके लिए नि: शुल्क चर xका मान पास करते हैं ।

संरचना इस प्रकार है:

• मूल्यांकन (गणना)
  • ParameterizedGaussian (बंद करना: सूत्र, और कुछ बाध्य चर)
    • GaussianParameters (समग्र डेटा प्रकार)
      • औसत मूल्य)
      • भिन्नता (मूल्य)
  • X (मुक्त चर का मूल्य)

Answer 6

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

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

3. को देखो हास्केल और एमएल प्रोग्रामिंग भाषाओं (एमएल सरल है)। वे दोनों लैम्ब्डा कैलकुलस पर आधारित हैं और अवधारणात्मक रूप से प्रति फ़ंक्शन केवल एक पैरामीटर है (यदि आप थोड़ा सा स्क्विंट करते हैं)।

4. जोश बलोच का आइटम 2 है: "कई बिल्डर मापदंडों के साथ सामना करने पर एक बिल्डर पर विचार करें।" आप देख सकते हैं कि यह कैसे क्रिया है , लेकिन यह एक एपीआई के साथ काम करने के लिए एक खुशी है जो इस तरह से लिखा गया है।

5. कुछ भाषाओं ने मापदंडों का नाम दिया है जो विशाल विधि हस्ताक्षरों को नेविगेट करने में बहुत आसान बनाने के लिए एक और दृष्टिकोण है। उदाहरण के लिए कोटलिन ने तर्कों का नाम दिया है ।