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

मई 2002

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

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

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

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

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

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

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

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

परिकल्पना

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

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

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

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

मेट्रिक्स

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

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

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

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

डिजाइन

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

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

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

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

तुलना

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

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

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

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

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

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

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

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

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

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

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

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

प्रतिबंधात्मकता

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

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

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

पठनीयता

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

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

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

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

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

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

कितनी हद तक?

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

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

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

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

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

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

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

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

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

(rec zero 1 * 1-)

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

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

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

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