संक्षिप्तता ही शक्ति है

मई 2002

"बीजगणितीय चिह्नों द्वारा एक छोटे से स्थान में संकुचित अर्थ की मात्रा, एक और परिस्थिति है जो तर्क को सुविधाजनक बनाती है जिसका हम उनके सहायता से उपयोग करने के आदी हैं।"

• चार्ल्स बैबेज, इवर्सन के ट्यूरिंग अवार्ड लेक्चर में उद्धृत

रिवेंज ऑफ द नर्ड्स द्वारा उठाए गए मुद्दों पर LL1 मेलिंग सूची में चर्चा में, पॉल प्रेस्कोड ने कुछ ऐसा लिखा जो मेरे दिमाग में अटक गया।

पायथन का लक्ष्य नियमितता और पठनीयता है, संक्षिप्तता नहीं।

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

पायथन का लक्ष्य नियमितता और पठनीयता है, शक्ति नहीं।

और यह एक समझौता नहीं लगता (अगर यह है एक समझौता) जो आप करना चाहेंगे। यह कहने से बहुत दूर नहीं है कि पायथन का लक्ष्य एक प्रोग्रामिंग भाषा के रूप में प्रभावी होना नहीं है।

क्या संक्षिप्तता = शक्ति? यह मुझे एक महत्वपूर्ण प्रश्न लगता है, शायद भाषा डिजाइन में रुचि रखने वाले किसी भी व्यक्ति के लिए सबसे महत्वपूर्ण प्रश्न है, और एक ऐसा प्रश्न जिसका सामना करना उपयोगी होगा सीधे तौर पर। मुझे अभी तक यकीन नहीं है कि उत्तर एक साधारण हाँ है, लेकिन ऐसा लगता है शुरू करने के लिए एक अच्छा परिकल्पना।

परिकल्पना

मेरी परिकल्पना यह है कि संक्षिप्तता शक्ति है, या काफी करीब है कि रोग संबंधी उदाहरणों को छोड़कर आप उन्हें के रूप में मान सकते हैं समान।

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

यदि छोटा स्रोत कोड उच्च-स्तरीय भाषाओं का उद्देश्य है, और किसी चीज़ की शक्ति यह है कि वह अपने उद्देश्य को कितनी अच्छी तरह से प्राप्त करती है, तो एक प्रोग्रामिंग भाषा की शक्ति का माप यह है कि यह आपके कार्यक्रमों को कितना छोटा बनाती है।

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

मेट्रिक्स

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

एक और आसान परीक्षण एक कार्यक्रम में वर्णों की संख्या है, लेकिन यह बहुत अच्छा नहीं है; कुछ भाषाएँ (पर्ल, उदाहरण के लिए) बस दूसरों की तुलना में छोटे पहचानकर्ता का उपयोग करें।

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

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

डिजाइन

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

यदि एक कार्यक्रम का वैचारिक भार इसकी जटिलता के समानुपाती है, और एक दिया गया प्रोग्रामर एक निश्चित वैचारिक भार को सहन कर सकता है, तो यह पूछने जैसा है, मैं प्रोग्रामर को सबसे अधिक काम करने में सक्षम बनाने के लिए क्या कर सकता हूं? और यह मुझे पूछने के समान लगता है, मैं एक अच्छी भाषा कैसे डिज़ाइन कर सकता हूँ?

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

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

तुलना

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

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

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

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

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

क्षेत्र से रिपोर्ट, हालांकि वे जरूरी कम सटीक होंगे "वैज्ञानिक" अध्ययन, अधिक अर्थपूर्ण होने की संभावना है। उदाहरण के लिए, एरिक्सन के उल्फ विगर ने किया अध्ययन जो निष्कर्ष निकाला कि एर्लांग सी ++ की तुलना में 4-10 गुना अधिक संक्षिप्त था, और आनुपातिक रूप से तेजी से विकसित करने के लिए इसमें सॉफ्टवेयर:

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

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

स्वाद परीक्षण

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

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

मैं अकेला नहीं हूं। मैं कई लिस्प हैकर्स को जानता हूं जिनके साथ ऐसा हुआ है से। वास्तव में, प्रोग्रामिंग की सापेक्ष शक्ति का सबसे सटीक माप भाषाएँ वह प्रतिशत लोग हो सकते हैं जो भाषा जानते हैं जो कोई भी नौकरी लेगा जहाँ उन्हें उस भाषा का उपयोग करने को मिलेगा, चाहे वह कुछ भी हो अनुप्रयोग डोमेन।

प्रतिबंध

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

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

मुझे लगता है कि अधिकांश (नब्बे प्रतिशत?) प्रतिबंधात्मकता की भावना कार्यक्रम बनाने के लिए मजबूर होने से आती है आप भाषा में लिखते हैं जो आपके सिर में मौजूद एक से लंबा है। प्रतिबंधात्मकता ज्यादातर संक्षिप्तता की कमी है। तो जब कोई भाषा प्रतिबंधात्मक महसूस होती है, तो इसका मतलब (ज्यादातर) यह है कि यह पर्याप्त संक्षिप्त नहीं है, और जब कोई भाषा संक्षिप्त नहीं होती है, तो यह प्रतिबंधात्मक महसूस होगा।

पठनीयता

जिस उद्धरण से मैंने शुरुआत की थी, उसमें दो अन्य गुणों का उल्लेख किया गया है, नियमितता और पठनीयता। मुझे यकीन नहीं है कि नियमितता क्या है, या क्या लाभ है, यदि कोई हो, तो कोड जो नियमित और पठनीय है, उसके पास कोड है जो केवल पठनीय है। लेकिन मुझे लगता है कि मुझे पता है कि पठनीयता से क्या तात्पर्य है, और मुझे लगता है यह भी संक्षिप्तता से संबंधित है।

हमें यहां कोड की एक अलग पंक्ति की पठनीयता के बीच अंतर करने के लिए सावधान रहना होगा और पूरे कार्यक्रम की पठनीयता। यह दूसरा है जो मायने रखता है। मैं सहमत हूं कि बेसिक की एक पंक्ति होने की संभावना है लिस्प की एक पंक्ति से अधिक पठनीय। लेकिन बेसिक में लिखा गया एक कार्यक्रम है लिस्प में लिखे समान कार्यक्रम की तुलना में अधिक पंक्तियाँ होंगी (विशेषकर एक बार जब आप ग्रीनस्पनलैंड में पार कर जाते हैं)। बेसिक प्रोग्राम को पढ़ने का कुल प्रयास निश्चित रूप से अधिक होगा।

कुल प्रयास = प्रति पंक्ति प्रयास x पंक्तियों की संख्या

मुझे यकीन नहीं है कि पठनीयता सीधे संक्षिप्तता के समानुपाती है जैसा कि मैं हूं कि शक्ति है, लेकिन निश्चित रूप से संक्षिप्तता एक कारक है (गणितीय अर्थ में; ऊपर समीकरण देखें) पठनीयता में। तो यह कहना भी सार्थक नहीं हो सकता है कि एक भाषा का लक्ष्य है पठनीयता, संक्षिप्तता नहीं; यह कहने जैसा हो सकता है कि लक्ष्य पठनीयता था, पठनीयता नहीं।

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

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

किस हद तक?

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

मैं यह सिर्फ बहस को और अधिक सभ्य बनाने के लिए प्रस्तावित नहीं कर रहा हूं। मैं वास्तव में जवाब जानना चाहता हूं। कब, अगर कभी, कोई भाषा बहुत संक्षिप्त होती है अपने भले के लिए?

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

भाषाएँ, कार्यक्रम नहीं

हमें स्पष्ट होना चाहिए कि हम संक्षिप्तता के बारे में बात कर रहे हैं भाषाओं की, व्यक्तिगत कार्यक्रमों की नहीं। निश्चित रूप से व्यक्तिगत कार्यक्रमों को बहुत घनीभूत रूप से लिखा जा सकता है।

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

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

तो उस बारे में कोई बहस नहीं है-- कम से कम, मेरी तरफ से नहीं। व्यक्तिगत कार्यक्रम निश्चित रूप से अपने भले के लिए बहुत संक्षिप्त हो सकते हैं। प्रश्न यह है कि क्या एक भाषा हो सकती है? क्या एक भाषा प्रोग्रामर को लिखने के लिए मजबूर कर सकती है कोड जो समग्र पठनीयता की कीमत पर छोटा (तत्वों में) है?

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

(rec zero 1 * 1-)

आप एक पुनरावर्ती परिभाषा भी लिख सकते हैं:

(rfn fact (x) (if (zero x) 1 (* x (fact (1- x)))))

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

(स्मरण: मैं जो खोज रहा हूं वह ऐसे कार्यक्रम हैं जो बहुत घने हैं "तत्वों" के मीट्रिक के अनुसार ऊपर स्केच किया गया है, न कि केवल ऐसे कार्यक्रम जो हैं छोटा क्योंकि सीमांकक को छोड़ दिया जा सकता है और हर चीज का एक वर्ण नाम है।)