एक प्रोग्रामिंग भाषा के लिए वर्बोसिटी खराब क्यों है? [बन्द है]

Question

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

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

तो, एक वर्बोज़ प्रोग्रामिंग भाषा के लिए संभावित डाउनसाइड क्या हैं?

Comments

क्या आप हाल ही में एपीएल में कोडिंग कर रहे हैं?

— एसके-लॉजिक

धनजी आर प्रसन्ना द्वारा भाषाएँ, शब्दशः, और जावा की जाँच करें

— जेरेमी हीलर

"एक डेवलपर केवल मरने से पहले उनमें एक निश्चित संख्या में कीस्ट्रोक्स होता है"

— CamelBlues

शायद आपको "बहुत से लोग शिकायत कर रहे हैं" से पूछना चाहिए कि उनके कारण क्या हैं।

— एरिक लिपर्ट

@ EricLippert, मेरा मानना ​​है कि P.SE "शिकायतकर्ता" डेवलपर्स की एक बड़ी संख्या को क्वेरी करने के लिए एक आदर्श स्थान है।

— केविन मैककॉर्मिक

Answer 1

लक्ष्य त्वरित समझ है

"Verbose" का अर्थ है "बहुत अधिक शब्दों का उपयोग करता है"। सवाल यह है कि "बहुत अधिक" क्या है।

अच्छा कोड एक नज़र में समझना आसान होना चाहिए। यह आसान है यदि अधिकांश वर्ण सीधे कोड के उद्देश्य को पूरा करते हैं ।

सिग्नल बनाम शोर

यदि कोई भाषा क्रिया है, तो आपका अधिक कोड शोर है। जावा के "हैलो वर्ल्ड" की तुलना करें :

class HelloWorldApp {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

... रूबी के साथ:

print "Hello World!"

शोर से मानसिक ऊर्जा बर्बाद होती है।

स्पष्ट बनाम

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

(car '(1 2 3))   # 3 characters whose meaning must be memorized
# vs
(first '(1 2 3)) # 5 characters whose meaning is obvious

Comments

मैं कहूंगा कि उत्तरार्द्ध सूक्ष्म स्तर पर पठनीयता के बारे में है (जहां हम आमतौर पर अधिक क्रिया संकेतन पसंद करते हैं) जहां पूर्व स्थूल स्तर पर पठनीयता के बारे में है (जहां हम आमतौर पर अधिक संक्षिप्तता पसंद करते हैं)

— जेके।

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

वास्तव में मैक्रो स्केल वर्बोसिटी का एक बेहतर उदाहरण पैटर्न हो सकता है जो एक लापता भाषा सुविधा

— jk के

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

— मैल्कम

सिग्नल बनाम शोर और गुप्त बनाम बनाम स्पष्ट के

— स्पोइक

Answer 2

यह प्रभावित करता है कि आप एक ही नज़र में कितना कोड देख और पार्स कर सकते हैं

x++ बजाय set(x,Integeradd(get(x),1))

ps। यह सिर्फ कोड पढ़ने की बात नहीं है। 40x25 स्क्रीन के दिनों में तब एपीएल प्रकार की भाषाएँ, या पर्ल, कोडोल या फोरट्रान से अधिक उपयोगी थीं, जिस कोड को आप पढ़ सकते थे / पृष्ठ। लेकिन अब यह आपके स्वयं के आंतरिक कैश के बारे में अधिक है - अगर एक बयान में एक ऑपरेटर है तो यह मेरी उम्र बढ़ने के मस्तिष्क के लिए 3 प्रतीकों और 4 फ़ंक्शन कॉल के साथ एक से अधिक पार्स करना आसान है।

Comments

मेरा मानना ​​है कि यह अंतिम कारण है। एक कागज या एक मॉनिटर के एक सीमित स्थान पर पठनीयता।

+1, और पूरी तरह से सहमत हैं, और मैं 13 "लैपटॉप पर कोड करता हूं, लेकिन फिर इस साइट पर उनके लोगो के रूप में 3 मॉनिटर हैं ... कुछ संबंधित होना चाहिए :)

— ZJR

@ZJR - संपादित देखें।

— मार्टिन बेकेट

तो यहाँ क्या setविधि है? क्या यह वास्तव में कुछ सेट करता है (यानी पहला xपैरामीटर) या यह कुछ वापस करता है (यानी xकॉल के बाद असाइनमेंट )? मैं कहूंगा कि क्रिया के उदाहरण में कुछ अजीब दोहराव चल रहा है।

— जेसी सी। स्लीसर

एक बात जो यहां याद आ रही है, वह विचारधाराओं की उपयोगिता है - यह कि शब्द की तुलना में प्रतीक अधिक सार्थक हो सकते हैं। की +तुलना में अधिक सार्थक है plus। =से बेहतर है equals। इस पाठ्यक्रम को बहुत दूर ले जाया जा सकता है (और कई भाषाओं द्वारा किया गया है) लेकिन जब इसे मॉडरेशन में उपयोग किया जाता है, तो यह बहुत शक्तिशाली है।

— mcmcc

Answer 3

यदि भाषा की वाचालता कोड पठनीयता से अलग हो जाती है, तो यह बुरा है।

कुछ भाषाओं में ऐसी क्रिया सिंटेक्स होती है जो कोड के अर्थ को समझने में अधिक समय लेती है (मैं VB.NET बनाम # # के बारे में सोच रहा हूं:

If something Then
End If

if(something)
{}

यह वास्तव में उबलता है कि एक कोडर परिचित और आरामदायक है।

Comments

मैं सी # में ज्यादातर काम करता हूं, लेकिन जब मैं वीबी पढ़ता हूं तो मुझे लगता है कि मैंने इसे पढ़ा जैसे कि यह सी # था। मैं सभी को अनदेखा करता हूं If .. Then .. End Ifऔर केवल वही पढ़ता हूं जो महत्वपूर्ण है।

— एंडी हंट

एंडी के समान। मुझे दोनों समान रूप से पठनीय लगते हैं। मैं यह भी कहना चाहूंगा कि मैं थोड़ा VB के वेरिएंट को पसंद करता हूं (इसके बावजूद कि मैं c # का अधिक उपयोग करता हूं)।

— डेगनेलिस

VB.NET कुछ अन्य बदतर अपराधियों की तुलना में क्रिया नहीं है !

@AndyBursh - बिल्कुल मेरी बात। VB.NET पढ़ते समय आप कोड को समझने और उसके ऊपर कुछ मानसिक अनुवाद करते हैं।

— ओड

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

— एंड्रयू नीली

Answer 4

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

यदि आप हर दिन ऐसा नहीं करते हैं, तो सभी शब्दार्थों को याद रखने की कोशिश करें कि कीवर्ड कहाँ जाते हैं और वे क्या गैर-तुच्छ हैं।

इस तुच्छ उदाहरण में सभी खोजशब्द शोर देखें:

tell application "Finder"
    if folder "Applications" of startup disk exists then
        return count files in folder "Applications" of startup disk
    else
        return 0
    end if
end tell

bashपारंपरिक यूनिक्स उपकरणों के साथ एक ही चीज को दिया जाएगा, लेकिन ज्यादातर OSX उपयोगकर्ताओं के लिए यह गुप्त होगा, इसलिए इसमें एक संतुलन होना चाहिए।

Comments

क्या आप नहीं चाहते return the 0कि आपने कब टाइप किया? AppleScript एकमात्र ऐसी भाषा है जो मुझे पता है कि आपको विरोधियों को दुखी करने की अनुमति देता है ... मेरा मतलब है कि सह-कार्यकर्ता।

— कोकाले

एप्सस्क्रिप्ट आईडीई, स्क्रिप्ट एडिटर, 90 के दशक में, क्रियाओं की एप्सस्क्रिप्ट स्क्रिप्ट के साथ वाचालता का मुकाबला करने में मदद करता था, यह भयावह रूप से स्मार्ट नहीं था, लेकिन फाइंडर की स्क्रिप्टिंग करते समय थोड़े से काम ... लगभग 1998 रिकॉर्डिंग थोड़े टूट गया और फिर कभी तय नहीं हुआ। । (dunno अगर OSX संक्रमण ने तय किया कि, IIRC, नहीं)

— ZJR

AppleScript की बोझिलता का OSX जवाब ऑटोमैटिक है। चलो ड्रैगबल, वर्बोसली-वर्णित, और खराब-समझाया कार्यक्षमता ब्लॉकों के विशाल पुस्तकालय के साथ आसान-प्रकार के पाठ को प्रतिस्थापित करते हैं!

— शराबी

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

— किंडल

Applescript लिखने के लिए बोझिल है, लेकिन मानव समझ के लिए आसान है ... प्रोग्रामर की सीमा के भीतर चालित अनुप्रयोग में समझदार वाक्य रचना के साथ applescript हुक लगाते हैं।

— अरामी

Answer 5

मुझे लगता है कि आपको इस सवाल को सिर पर रखने की जरूरत है और पूछें: कुछ लोगों को लगता है कि ट्रिक कोड अच्छा क्यों है?

मेरा जवाब होगा कि दो बुनियादी कारण हैं:

क्यों बेहतर हो सकता है कारण

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

कारण क्यों बुरा हो सकता है

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

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

Comments

मैं वर्बोज़ के ऑपोसिट के बारे में विचार नहीं करूंगा। Verbose एक नकारात्मक अर्थ का वहन करता है, इसलिए संभवतः एक सकारात्मक अर्थ को ले जाने वाले antonym के लिए बेहतर अनुकूल होगा।

— जोशुआ ड्रेक

terseका एनटोनियम है verbose, terseकेवल उसी नकारात्मक अर्थ को ले जा सकता है (देखें पर्ल)

@JarrodRoberson: मुझे सभी चीजों की शुक्रवार की रात को पांडित्य से नफरत है, लेकिन मैंने कुछ ऑनलाइन थिसॉरस पर ध्यान दिया और उनमें से कोई भी (या इसके विपरीत) के terseएनटोनियम के रूप में नहीं है verbose। / बतख

— स्कॉट मिशेल

@ScottMitchell en.wiktionary.org/wiki/terse#Antonyms

— naught101

Answer 6

@ यदि, मैं सुझाव दूंगा कि वर्बोसिटी मुद्दे को देखने का एक तरीका यह है कि प्रोग्रामिंग हमेशा एक समाधान खोजने और व्यक्त करने की दो अलग शैलियों की कुछ मिश्रण है।

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

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

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

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

तो मैं क्या सुझाऊँगा?

दोनों शैलियों का उपयोग करें, लेकिन इस बात पर ध्यान दें कि आप प्रत्येक शैली का उपयोग क्यों कर रहे हैं।

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

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

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

Answer 7

बहुत से लोगों ने कुछ ऐसा संकेत दिया है जो मुझे लगता है कि शायद स्पष्ट रूप से कहा जाना चाहिए।

Verbosity सूक्ष्म स्तर पर समझ का पक्ष लेती है - यह आम तौर पर एक व्यक्तिगत कथन को पढ़ने और समझने में आसान बनाता है। वर्बोसिटी भी इसे समझने के लिए आवश्यक भाषा के साथ परिचित की डिग्री को कम करने के लिए जाता है (कम से कम कुछ डिग्री के लिए)। सबसे क्रियात्मक भाषाएँ (जैसे, COBOL) पूर्ण गैर-प्रोग्रामर द्वारा भी कम से कम कुछ पठनीय हो सकती हैं।

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

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

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

Answer 8

एक तकनीकी पुस्तक पर जाने के बजाय, मैं स्ट्रीक और व्हाइट द्वारा एलीमेंट ऑफ स्टाइल * पर वापस लौट आया हूं । अंतर्निहित अवधारणा "सटीक रहें" और "आवश्यकता से अधिक न कहें।" बाकी सब कमेंटरी है।

प्रोग्रामिंग के लिए लागू, यह बहुत सटीक होने के बारे में है, लेकिन अनावश्यक फुलाना नहीं है। अतिरिक्त फ़ुल वाक्यविन्यास हो सकता है, लेकिन यह अर्थ को व्यक्त करने के लिए आवश्यकता से अधिक शब्द भी हो सकता है। (बेशक अस्पष्टता की अनुमति देने के लिए बहुत कम नहीं)

• मैं मूल संस्करण का हवाला देता हूं क्योंकि यह सबसे संक्षिप्त है। :-)

Answer 9

दिन के अंत में, कुछ भी जो 'अलग' है, लोगों को हॉवेल के लिए प्रेरित करेगा। मैं सी स्टाइल सिंटैक्स के साथ सहज हूं और इसलिए अन्य भाषाओं के साथ ठीक हूं जो समान सिंटैक्स (सी ++, जावा, सी #) साझा करते हैं। इसलिए मैं इस विशेष शैली का पक्ष लेता हूं।

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

पर्ल एक उदाहरण है जहां आप बहुत संक्षिप्त कोड लिख सकते हैं। निर्विवाद के लिए, एक पर्ल निंजा द्वारा लिखित कोड जादू से कम नहीं है।

COBOL बहुत क्रिया का एक उदाहरण है।

Comments

यह प्रश्न का उत्तर कैसे देता है?

— ChrisF

वर्बोसिटी हर किसी के लिए अलग होती है। यही मेरी टिप्पणी का आशय था। यदि आप C / C ++ कैंप में हैं, तो स्वीकार किए गए वर्बोसिटी की तुलना में भिन्न है यदि आप पर्ल शिविर में हैं।

— नासिर

एक पर्ल निंजा द्वारा लिखित कोड जादू से कम नहीं है? गंभीरता से, मुझे लगता है कि यह एक बुरा सपना है।

— केविन

मैं पर्ल की :) दूर करने

— नासिर

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

— बिलथोर

Answer 10

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

मैंने पाया है कि यह मेरे और सहकर्मी के बीच सही है। वह बहुत सारी टिप्पणियों के साथ कोड लिखती है जिसमें बताया गया है कि कोड की लाइनें क्या हैं, और बहुत सारे सफेद स्थान हैं। यदि मैं इसे पढ़ रहा हूं, तो मुझे लगता है कि मैं केवल एक स्क्रीन पर कोड की कुछ पंक्तियों को इस वजह से फिट कर सकता हूं। यह प्रत्येक व्यक्ति की रेखा को समझना आसान बनाता है, लेकिन पूरे कार्य को टटोलना बहुत कठिन हो जाता है।

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

Comments

टिप्पणियों के खिलाफ कोई नहीं। समस्या जावा, एप्सस्क्रिप्ट, या विज़ुअल बेसिक जैसी भाषाएं हैं, जिनमें बहुत सारे अनावश्यक लेकिन अनिवार्य तत्व हैं।

— मारसिन

@ मारकिन मैं टिप्पणियों के खिलाफ नहीं हूं, लेकिन जब वे इस तरह होते हैं: i++; //this is adding one to var iयह बेमानी है।

— स्पेंसर रथबुन

सवाल हालांकि प्रोग्रामिंग भाषाओं के बारे में है।

— ब्रेंडन लॉन्ग

@BrendanLong हम्म, मैं स्पष्ट नहीं था। मैं वर्बोज़ प्रोग्रामिंग भाषाओं के साथ अनावश्यक टिप्पणियों की बराबरी कर रहा था। एक ही बात कहने के लिए बहुत सारे शब्द, केवल एक वर्बोज़ प्रोग्रामिंग भाषा की आवश्यकता होती है।

— स्पेंसर रथबुन

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

— लेफ्टरेंबाउट

Answer 11

आइंस्टीन ने इसे सही पाया: "चीजों को जितना संभव हो उतना सरल बनाएं, लेकिन सरल नहीं।"

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

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

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

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

सच्चा कौशल जटिल चीजों को सरल तरीके से बनाने में निहित है, सरल चीजों को जटिल तरीके से बनाने में नहीं।

Answer 12

किसी और ने जो कुछ नहीं मारा है वह उस कोड की मात्रा में है जिसे आप एक स्क्रीन में फिट कर सकते हैं। यह कई कारणों से मदद करता है:

• जब आप एक फ़ाइल में कई कार्य कर रहे हैं (या पढ़ रहे हैं) पर आगे और पीछे स्क्रॉल करना कम करें।
• कम क्षैतिज स्क्रॉलिंग (स्टॉप रीडिंग, क्लिक करें और ड्रैग स्क्रॉल बार, पढ़ना बंद करें, क्लिक करें और स्क्रॉलबार खींचें ...)।
• तेजी से स्कैनिंग, क्योंकि आप जो चाहते हैं उसे खोजने के तरीके में कम बेकार सिंटैक्स हो रहा है।

Comments

वास्तव में कितना स्क्रॉल किया जाता है 1920 X 1080 स्क्रीन पर एक पठनीय फ़ॉन्ट आकार के साथ? इन चीजों को नेविगेशन के लिए कीबोर्ड शॉर्टकट भी कहा जाता है।

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

— ब्रेंडन लॉन्ग

क्या आपका आईडीई विभाजन विचारों का समर्थन नहीं करता है?

— 19-26 को

आप दोनों इस बिंदु को याद नहीं कर रहे हैं - क्या मेरी आईडीई स्क्रॉल को कम खराब कर सकती है , यह कभी भी उतना अच्छा नहीं होगा जितना स्क्रॉल (या हॉटकी, या स्प्लिटस्क्रीन) का उपयोग न करना । यह कहने जैसा है कि "ऑन स्क्रीन कीबोर्ड बस ठीक हैं, क्या आपने कभी चीजों पर क्लिक करने के बारे में नहीं सुना है?" जाहिर है मेरे पास है, लेकिन यह असली कीबोर्ड नहीं है।

— ब्रेंडन लांग

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

— कोनराड रुडोल्फ

Answer 13

क्योंकि अधिक कोड का अर्थ है अधिक विकास समय और अधिक बग।

यदि आप कोड की 300 लाइनों के बजाय 100 लाइनों के कोड लिखते हैं। इसका मतलब है कि लगभग 1/3 विकास समय आपको चाहिए और 1/3 संभावित बग जो आपको मिल सकते हैं।

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

Comments

मैं Ada के 300 लाइनों की तुलना में Perl की 100 विशिष्ट लाइनों में कहीं अधिक छिपे हुए कीड़े की उम्मीद करूंगा। - जैसा कि "चूंकि कम कोड लिखने का मतलब है कि मशीन को अधिक चीजें करने की आवश्यकता है और यह दक्षता को कम कर देगा", इस तरह का सहसंबंध हो सकता है लेकिन यह कार्य-कारण नहीं है। यह सिर्फ इतना है कि रूबी, पर्ल और पाइथन जैसी गतिक गतिशील और / या व्याख्या की गई भाषाएं सी या फोरट्रान जैसी अधिक क्रियात्मक स्थिर संकलित भाषाओं की तुलना में धीमी होती हैं। लेकिन ट्रिक संकलित हास्केल, पायथन w / PyPy या C ++ प्रोग्राम वर्बोज़ की तुलना में बहुत तेज़ हो सकते हैं, जैसे बेसिक, ग्रूवी, स्मॉलटाक या यहां तक ​​कि सी # कोड।

— लेफ्टरनबाउट

Answer 14

आमतौर पर, लोग गूढ़ / छंद से अधिक पठनीय / क्रियात्मक भाषाओं का पक्ष लेते हैं। हालांकि, मुझे लगता है कि ज्यादातर लोग "अव्यवस्था" को "अव्यवस्था" के साथ आत्मसात कर लेते हैं, जो कि एक ही बात नहीं है।

उदाहरण के लिए: while(<>){print if($.==2 || $& && !$x++); $.=0 if (/^--+$/)}

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

वर्बोसिटी के दूसरे चरम पर, http://en.wikipedia.org/wiki/Literate_programming है , जिसे मैं एक बहुत ही दिलचस्प अवधारणा मानता हूं।

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

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

Comments

आप [संक्षिप्त अर्थ] ( en.wiktionary.org/wiki/concise ) को दोबारा जांचना चाह सकते हैं , क्योंकि यह लगभग गूढ़ विद्या है। क्या आप शायद जावा में कोड करते हैं?

— जोशुआ ड्रेक

मैं संक्षिप्त भाषाओं में लिखित क्रिया कोड पसंद करता हूं।

— ब्रेंडन लॉन्ग

@ जोशुआ: हाँ, मैंने देखा कि इसकी व्याख्या बहुत अलग तरीकों से की जा सकती है, इसलिए मैंने अपना उत्तर संपादित किया। ... और इससे जावा को क्या लेना-देना?

— डेगनेलिज

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

— dagnelies

@ विरूपनरी का उपयोग करने के लिए मेरा बुरा। Google खोज परिभाषित करता है: संक्षिप्त प्रारंभ: "बहुत सी जानकारी स्पष्ट रूप से देना" जो कि आपका नमूना कोड स्पष्ट रूप से उल्लंघन करता है। हालाँकि मुझे स्पष्ट, संक्षिप्त और संक्षिप्त अब यात्रा टॉगल के मूल निहितार्थ को स्वीकार करना होगा।

— जोशुआ ड्रेक

Answer 15

शब्दशः पाठ की व्यापक मात्रा का उपयोग करने की प्रवृत्ति, और बहुत कम पाठ का उपयोग करने की प्रवृत्ति ...

वर्बोसिटी खराब है क्योंकि:

1. यह टाइपोग्राफिक त्रुटि के लिए अधिक अवसर का परिचय देता है
2. इससे स्क्रीन या पेपर पर कोड पढ़ना, और / या पंचकार्ड पर दर्ज करना कठिन हो जाता है
   1. यह डिबग समय को बढ़ाता है
   2. यह उन्नयन / रखरखाव के लिए कठिन कोड की समझ बनाता है
   3. इससे अनपेक्षित कोड दोहराव हो सकता है
3. यह कुछ हद तक वाक्य रचना त्रुटि की संभावना को बढ़ाता है
4. यह कोडिंग लचीलापन कम कर देता है, उस में, अधिकांश वर्बोज़ भाषाएँ अत्यधिक संरचित होती हैं और एक ही बात कहने के लिए कई तरीके नहीं होते हैं।
5. यह कोडिंग और संकलन समय बढ़ाता है
6. यह अधिक संग्रहण स्थान ले सकता है।

स्पष्टता के लिए क्रियाशीलता का एक निश्चित स्तर आवश्यक है, हालांकि ...

वर्बोसिटी का न्यूनतम स्तर अच्छा है क्योंकि:

1. मनुष्यों के लिए विशुद्ध रूप से प्रतीकात्मक कोड की तुलना में अर्थ मूल्य को पढ़ना और संलग्न करना आसान है
2. चर और फ़ंक्शन नामकरण में, यह डिबग, पोर्ट और कोड बनाए रखना आसान बनाता है
3. आधार स्तरीय भाषा संचालन और जटिल भाषाओं के कीवर्ड में, यह कम गलत संचालन / कीवर्ड असाइनमेंट की ओर जाता है।

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

या C / C ++ पॉइंटर और रेफरेंस ऑपरेटर्स द्वारा &और *BASIC byrefकीवर्ड द्वारा। C / C ++ में, मेरे पास एक चर X हो सकता है, और उस चर के लिए एक पॉइंटर पास हो सकता है, लेकिन मुझे यह याद रखना होगा कि कौन सा पॉइंटर है और जो "पॉइंटर के रूप में पॉइंटर का उपयोग करता है जो इसे इंगित करता है"; बुनियादी तौर पर, मैं फंक्शन कॉल में एक ब्यॉर्फ कीवर्ड के साथ संदर्भ पास करता हूं, जो अधिक स्पष्ट है, लेकिन कम लचीला है:

def fn Foo(x byref as float) foo= (x += x+1)
...
Foo(x)

इस कोड में, x सामग्री झंडे के कारण संशोधित हो जाती है। कुछ जायके कॉल पर byref की अनुमति देते हैं, दूसरों को परिभाषा में, कुछ में।

क्रियात्मकता आकस्मिक प्रोग्रामर के लिए महत्वपूर्ण है ताकि प्रतीकात्मकता का उपयोग करना आसान हो; BASIC या python C / C ++ की तुलना में अधिक मानव पठनीय और अधिक क्रियाशील है, और इस प्रकार यह आकस्मिक प्रोग्रामर के लिए अधिक उपयोगी है; C / C ++ की terseness अधिक अनुभवी प्रोग्रामर के लिए बहुत बेहतर बनाती है, जिन्हें एक स्क्रीन पर अधिक कोड और अधिक जटिल कोड देखने की आवश्यकता होती है, लेकिन उन्हें विभिन्न प्रतीकात्मक संरचना सम्मेलनों को सीखना पड़ता है। सबसे दूर एपीएल है, जो लगभग पूरी तरह से मानव अपठनीय है।

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

पुराने दिनों में

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

कई समाधान मौजूद थे - टोकन मूल रूप से अत्यंत सामान्य थे; अलग-अलग भाषा के कीवर्ड ऊपरी 128 या नियंत्रण वर्ण स्थान में 1 या 2 बाइट शब्द से कम हो गए थे। Tokenization नेतृत्व भी bytecode संकलन (सूचना और जेड मशीन के रूप में)।

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

हालाँकि, अधिक प्रचलित भाषाओं को डिस्क और रेम दोनों के दिए गए हिस्से में अधिक कोड मिला, और इस तरह एक बार में बड़ी मात्रा में संकलन किया गया। ध्यान में रखते हुए: 1970 की शुरुआत में "मिनिकोमप्वाइंट्स" में केवल 64KiB का राम हो सकता था (हनीवेल 800 में 8 बैंकों में से प्रत्येक में 8B के 2048 शब्दों में से प्रत्येक के आधार पर 4 बैंक थे)। APL और इसी तरह की प्रतीकात्मक भाषाएं 1B प्रति निर्देश प्लस और इसके ऑपरेंड्स के करीब पहुंचीं, प्रति इंस्ट्रक्शन प्लस ऑपरेंड्स की तुलना में बहुत बड़ा 3B-10B। (यह पंचकार्डों पर टाइप करने का एक बुरा सपना था, खासकर जब से प्रतीक अनिवार्य रूप से टाइप-बॉल पर एक फ़ॉन्ट थे, और कई कार्डपंचों में चाबी पर प्रतीक नहीं थे ...)

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

Comments

कई मामलों में निष्पक्षता से टाइपोग्राफिक त्रुटियों की संभावना बढ़ जाती है, जो कि केवल गलत व्यवहार करने के बजाय संकलन-समय पर पता लगाया जाता है।

— सुपरकाट

Answer 16

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

Comments

संतुलित ब्रैकेट और अर्धविराम बेमानी हैं, क्योंकि काफी हद तक प्रकार की घोषणाएं हैं।

— मार्सिन

@ मार्सिन: हाँ, लेकिन वे भाषा के लिए एक पार्सर / विश्लेषक लिखना आसान बनाते हैं। मुझे पूरा यकीन है कि इस तरह के वाक्यविन्यास भाषा कार्यान्वयनकर्ता के लाभ के लिए मौजूद हैं, न कि भाषा का उपयोग करने वाले प्रोग्रामर के लिए।

— ccoakley

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

— इंगो

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

— मार्सिन

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

— इंगो

Answer 17

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

Comments

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

— 22

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

— एड्रियनमेक्मिनामिन

Answer 18

मेरा मानना ​​है कि पठनीयता की तुलना में अधिक मौलिक और सैद्धांतिक मुद्दे में निहित प्रश्न का उत्तर है और यह उत्तर ग्रेगरी चैटिन द्वारा स्थापित एल्गोरिथम सूचना सिद्धांत से संबंधित है: http://en.wikipedia.org/wiki/Al एल्गोरिदम_अनुसंधान_अध्याय । कुछ शब्दों में कहा गया है, "एक स्ट्रिंग की सूचना सामग्री उस स्ट्रिंग के सबसे कम संभव स्व-निहित प्रतिनिधित्व की लंबाई के बराबर है", इसका मतलब है कि सबसे छोटा प्रोग्राम (अर्थात् इसकी लेक्सिकोग्राफ़िक लंबाई के संदर्भ में) किसी दिए गए हल को बारीकी से हल करता है समस्या की आंतरिक जटिलता से मेल खाता है जिससे यह एक समाधान देता है और इस प्रकार, यह समस्या की प्रकृति पर अधिक और समस्या के प्रतिनिधित्व पर कम निर्भर करता है।