सारगर्भितता शक्ति है

मई 2002

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

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

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

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

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

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

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

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

परिकल्पना

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

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

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

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

मापदंड

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

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

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

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

डिज़ाइन

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

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

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

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

तुलना

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

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

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

इसलिए किसी भी भाषा की तुलना जहां आपको पूर्व परिभाषित विनिर्देश को पूरा करना होता है, थोड़ा गलत चीज का परीक्षण कर रहा है।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

पठनीयता

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

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

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

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

किस हद तक?

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

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

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

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

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

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

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

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

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

(rec zero 1 * 1-)

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

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

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

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