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

मई 2002

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

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

LL1 मेलिंग सूची पर Revenge of the Nerds द्वारा उठाए गए मुद्दों पर चर्चा में, पॉल प्रेस्कॉट ने कुछ ऐसा लिखा जो मेरे मन में रह गया।

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

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

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

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

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

परिकल्पना

मेरी परिकल्पना यह है कि संक्षिप्तता शक्ति है, या इतनी करीब है कि पैथोलॉजिकल उदाहरणों को छोड़कर आप उन्हें समान मान सकते हैं।

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

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

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

मेट्रिक्स

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

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

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

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

डिजाइन

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

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

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

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

तुलना

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

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

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

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

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

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

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

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

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

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

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

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

प्रतिबंध

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

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

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

पठनीयता

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

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

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

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

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

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

किस हद तक?

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

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

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

भाषाएँ, प्रोग्राम नहीं

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

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

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

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

एक कारण यह कल्पना करना कठिन है कि कोई भाषा बहुत संक्षिप्त हो सकती है, यह है कि यदि कुछ अत्यधिक संक्षिप्त तरीका कुछ वाक्यांश करने के लिए होता, तो शायद एक लंबा तरीका भी होता। उदाहरण के लिए, यदि आपको लगता है कि मैक्रोज़ या उच्च-क्रम कार्यों का बहुत अधिक उपयोग करने वाले लिस्प प्रोग्राम बहुत घने थे, तो आप, यदि आप चाहें, तो पास्कल के समरूप कोड लिख सकते हैं। यदि आप Arc में फैक्टोरियल को उच्च-क्रम फ़ंक्शन (rec zero 1 * 1-) को कॉल के रूप में व्यक्त नहीं करना चाहते हैं, तो आप एक पुनरावर्ती परिभाषा भी लिख सकते हैं: (rfn fact (x) (if (zero x) 1 (* x (fact (1- x))))) यद्यपि मैं अपने सिर से उदाहरणों के बारे में नहीं सोच सकता, मैं इस प्रश्न में रुचि रखता हूं कि क्या कोई भाषा बहुत संक्षिप्त हो सकती है। क्या ऐसी भाषाएँ हैं जो आपको कोड को इस तरह से लिखने के लिए मजबूर करती हैं जो विकृत और समझ से बाहर हो? यदि किसी के पास उदाहरण हैं, तो मैं उन्हें देखकर बहुत रुचि लूंगा।

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