पायथन में सभी कीवर्ड को सॉफ्ट क्यों नहीं बनाया जाता?

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

मैं इसे और अधिक संक्षिप्त बनाने के लिए अपने प्रश्न को दोबारा बदलना चाहता हूं:

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

पायथन में सॉफ्ट कीवर्ड

यदि भाषा डिजाइनर चाहते हैं कि उनकी भाषा में कम से कम आरक्षित शब्द हों (यदि यह धारणा गलत है तो कृपया मुझे सुधारें) तो वे इन कठिन कीवर्ड को सॉफ्ट में क्यों नहीं बदल देते?

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

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

< br>बल्कि, सामान्य-उद्देश्य वाले LOB भाषा डिजाइनरों के रूप में, हम मुख्य रूप से उपयोगकर्ताओं की पसंद को सीमित करना चाहते हैं ताकि उन्हें समझने योग्य प्रोग्राम लिखने के लिए प्रोत्साहित किया जा सके जिन्हें आसानी से सही माना जा सके। हमने प्रसिद्ध रूप से C# को एक ऐसी भाषा के रूप में वर्णित किया है जो "आपको गुणवत्ता के गड्ढे में फेंक देती है" - भाषा का डिज़ाइन आपको एक अच्छा, सही, समझने योग्य प्रोग्राम लिखने की तुलना में एक खराब, समझ से बाहर प्रोग्राम लिखने के लिए अधिक मेहनत करने के लिए मजबूर करना चाहिए। बहुत सारे सॉफ्ट कीवर्ड उस लक्ष्य के खिलाफ दृढ़ता से काम करते हैं, और बदले में आपको कोई अभिव्यंजक शक्ति नहीं मिलती है! व्याकरण, लेकिन समझ से परे कार्यक्रमों को लिखना आसान बनाने की कीमत पर! यह कानूनी वीबीस्क्रिप्ट है, उदाहरण के लिए:

यह बहुत अच्छा नहीं है।

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

आप ऐसा कर सकते हैं। विज़ुअल बेसिक में, लगभग किसी भी पाठ को [] में संलग्न किया जा सकता है और यह एक पहचानकर्ता बन जाता है:

यह सकल है, लेकिन कानूनी है, यदि आप वास्तव में ऐसा करना चाहते हैं।

सारांश: नरम को अधिकतम करना कीवर्ड अपने आप में एक लक्ष्य नहीं है, सुपाठ्यता के विरुद्ध काम करता है, और अभिव्यंजकता जैसे कम लक्ष्यों को प्राप्त करने के लिए अनावश्यक है। इसलिए हम ऐसा नहीं करते हैं।

सॉफ्ट कीवर्ड का बड़ा नुकसान यह है कि वे चीजों को अस्पष्ट बना देते हैं। इसका मतलब है कि हमें अस्पष्टताओं को हल करने के लिए नियम बनाने होंगे। इससे व्याकरण अधिक जटिल हो जाता है। यह प्रोग्राम और इंसान दोनों के लिए एक समस्या है:

अगर = फिर + अन्यथा जैसे कोड को कौन पढ़ना चाहता है? कौन यह याद रखना चाहता है कि इसका अर्थ कैसे समझा जाए?

मिनट