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

मई 2002

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

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

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

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

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

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

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

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

परिकल्पना

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

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

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

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

मेट्रिक्स

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

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

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

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

डिज़ाइन

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

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

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

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

तुलना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

पठनीयता

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

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

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

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

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

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

किस हद तक?

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

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

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

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

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

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

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

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

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

 (rec zero 1 * 1-)

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

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

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

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