🌊 👩🏿‍🎨 👩🏼‍🔧 पॉल ग्राहम: Brevity = शक्ति 🤟🏽 ☺️ 🆔

आज हैकरन्यूज में हमने 2002 में पॉल ग्राहम के लेख की चर्चा की और हमने इसके अनुवाद को पुनरुत्थान से पुनर्जीवित करने का निर्णय लिया।

"
बीजीय संकेतों द्वारा एक छोटी सी जगह में संपीड़ित अर्थ की मात्रा , एक और परिस्थिति है जो
उन सहूलियतों की सुविधा प्रदान करती है जो हम उनकी सहायता से ले जाने के आदी हैं।"
- चार्ल्स बैबेज (1791-1871) LL1 मेलिंग सूची

में LL1 रिवेंज लेख के चारों ओर एक चर्चा में , पॉल प्रेसकॉड ने एक विचार व्यक्त किया जो मेरे दिमाग में नहीं आता।

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

पहली नज़र में, एक प्रोग्रामिंग भाषा शायद होने का दावा नहीं करना चाहिए। जैसा कि मैंने इसे समझा, संक्षिप्तता (संक्षिप्तता, संक्षिप्तता, कॉम्पैक्टनेस) = ताकत। और यदि ऐसा है, तो एक स्थानापन्न बनाना, हमें मिलता है:

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

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

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

परिकल्पना

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

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

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

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

मेट्रिक्स

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

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

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

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

डिज़ाइन

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

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

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

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

तुलना

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

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

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

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

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

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

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

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

स्वाद

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

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

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

सीमाएं

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

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

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

पठनीयता

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

यहाँ हमें कोड की एक लाइन की पठनीयता और समग्र रूप से कार्यक्रम की पठनीयता की अवधारणाओं से सावधान रहना चाहिए। केवल अंतिम महत्वपूर्ण है। मैं सहमत हूं कि बेसिक पर एक लाइन लिस्प पर एक लाइन की तुलना में सबसे अधिक पठनीय है, लेकिन बीएएसआईसी में लिखे गए प्रोग्राम में लिस्प में लिखे एक ही प्रोग्राम की तुलना में अधिक लाइनें होंगी। बेसिक कार्यक्रम को पढ़ना अधिक प्रयास करेगा।

कुल प्रयास = एक पंक्ति * पंक्तियों की संख्या को पढ़ने का प्रयास

मुझे यकीन नहीं है कि पठनीयता संक्षिप्तता के समानुपाती है, लेकिन निश्चित रूप से संक्षिप्तता पठनीयता का एक कारक है (ऊपर सूत्र देखें)। इसलिए यह कहना मुश्किल है कि भाषा का उद्देश्य पठनीयता है, लेकिन संक्षिप्तता नहीं।

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

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

किस डिग्री में?

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

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

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

भाषाएँ लेकिन कार्यक्रम नहीं

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

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

मुझे यकीन है कि किसी भी भाषा में इस तरह के समझौते संभव हैं (हालांकि मुझे संदेह है कि दांव मजबूत भाषाओं में उठाए गए हैं)। हर प्रोग्रामर ने कभी कोड देखा है जो संदिग्ध प्रोग्रामिंग तकनीकों के कारण बेहद छोटा है।

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

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

(rec zero 1 * 1-)

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

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

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

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

यह पहली बार प्रकाशित हुआ था । ।

स्किलफैक्ट ऑनलाइन कोर्स करके स्किल्स और सैलरी में स्क्रैच या लेवल अप से मांगे गए प्रोफेशन को कैसे प्राप्त करें, इसका विवरण जानें:

पॉल ग्राहम: Brevity = शक्ति