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

Question

पायथन और जावास्क्रिप्ट में, अर्ध-कॉलोन वैकल्पिक हैं।

PHP में, सरणी-कुंजियों के आसपास के उद्धरण वैकल्पिक ( $_GET[key]बनाम $_GET['key']) हैं, हालांकि यदि आप उन्हें छोड़ देते हैं तो यह पहली बार उस नाम से एक निरंतर की तलाश करेगा। यह ब्लॉक (कोलन, या ब्रेस सीमांकित) के लिए 2 अलग-अलग शैलियों की अनुमति देता है।

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

तुम क्या सोचते हो?

---

ठीक है, मेरी भाषा एक फैंसी टेम्प्लेटिंग भाषा के रूप में इतनी प्रोग्रामिंग भाषा नहीं है। Haml और Django टेम्प्लेट के बीच एक क्रॉस की तरह । मेरा सी # वेब फ्रेमवर्क के साथ उपयोग करने का मतलब है, और यह बहुत ही विस्तार से माना जाता है।

Comments

यह एक पवित्र युद्ध का विषय है।

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

— जॉब

PHP सरणी कुंजियों के उद्धरण वैकल्पिक नहीं हैं। वे PHP2 में थे, लेकिन बाद में तब ऑटो-डिफाइन्ड कॉन्स्टेंट का संस्करण तैयार किया। वे हालांकि बुनियादी स्ट्रिंग प्रक्षेप में अस्वीकृत हैं "..$_GET[raw].."।

— मारियो

@ राल्फ: नियम थोड़े अधिक जटिल हैं। यह लिखना सही है "xx$_GET[raw]xx"- यदि आप घुंघराले ब्रेसिज़ का उपयोग करना शुरू करते हैं, तो कुंजी को "xx{$_GET['raw']}xx"उद्धरण में संलग्न किया जाना चाहिए । यदि घुंघराले ब्रेसिज़ का उपयोग किया जाता है, तो साधारण PHP पार्सर इसकी जांच करता है और कड़ा सिंटैक्स लागू होता है। यह सिर्फ इसके लिए है "$_GET[x]"कि कुंजी को कच्चे स्ट्रिंग के रूप में माना जाता है, और यह भी एक सख्त नियम है, PHP त्रुटि पर पार्स करेगा "$_GET['x']"।

— मारियो

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

— एमपैन

Answer 1

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

उदाहरण के लिए, पर्ल एक बहुत ही ढीली भाषा है, और मैं इसे त्वरित फिक्सअप या नंबर क्रंचिंग स्क्रिप्ट लिखने के लिए बहुत उपयोगी मानता हूं। ठोस मजबूत परियोजनाओं के लिए मैं C # का उपयोग करता हूं।

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

Answer 2

मैं प्रोग्रामिंग भाषा में (स्क्रिप्टिंग भाषा के विपरीत) एकरूपता और मजबूत टाइपिंग की तलाश करता हूं ।

वर्तमान प्रोग्रामिंग भाषाओं में कुछ स्थानों पर अस्पष्ट के बिना अर्धविराम को छोड़ना संभव है (एक {}ब्लॉक में अंतिम अभिव्यक्ति एक है)। यदि एक प्रोग्रामिंग भाषा आपको इन मामलों में पात्रों को छोड़ने की अनुमति देती है, तो एक प्रोग्रामर को अब एक अतिरिक्त समस्या है; सामान्य भाषा के सिंटैक्स के शीर्ष पर उसे अब यह जानना होगा कि किन सिंटैक्स के कुछ हिस्सों को छोड़ने की अनुमति है।

यह अतिरिक्त ज्ञान प्रोग्रामर को कोड लिखने के लिए कोई समस्या नहीं है, लेकिन यह किसी के लिए भी बोझ बन जाता है, जिसे मौजूदा कोड को बाद के समय में व्याख्या करना पड़ता है (थोड़ी देर बाद मूल लेखक सहित)।

आपका PHP उदाहरण एक प्रोग्राम में सूक्ष्म बग के लिए संभावना खोलता है जब keyउसी संदर्भ में निरंतर जोड़ा जाएगा। संकलक के पास यह जानने का कोई तरीका नहीं है कि क्या मतलब नहीं था, इसलिए समस्या केवल संकलन समय के बजाय रनटाइम पर स्पष्ट हो जाती है।

Comments

सहमत हों, आपको विकासशील लोगों के लिए संभावनाओं को सीमित करना चाहिए: अधिक अधिभोगियों => और अधिक सोचने की आवश्यकता है (क्या मुझे इस तरह या इस तरह आगे बढ़ना चाहिए) => वास्तविक काम करने के लिए कम समय

— केमोडा

मैं यह देखने में विफल हूं कि किसी भाषा के वाक्य विन्यास के साथ निहित प्रकार की कास्टिंग की कमी क्या है।

— dan_waterworth

इसके अलावा, जब आप पढ़ते हैं $_GET[key]तो आप कुछ भी नहीं जानते हैं। आप यह जानने के लिए कि क्या keyएक स्थिरांक है या नहीं , पूरी परियोजना को समाप्त कर रहे हैं। इस तरह की चीज़ लिखने में 0.5 सेकंड का समय बचाती है और पढ़ने में 20 सेकंड का समय लगता है।

— मोशे रेवह

यदि आपकी भाषा आपको बिना किसी भेद के विकल्प देती है, तो कोडिंग-शैली - चाहे कोडित हो या न हो - उनमें से किसी एक पर मानकीकरण करने की प्रवृत्ति होती है ...

— Deduplicator

Answer 3

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

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

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

Answer 4

अपनी भाषा को कितना ढीला बनाना चाहिए इसका जवाब टेक्सास के लहजे में कहे गए सवाल के जवाब के बराबर है "आप कितना भाग्यशाली महसूस करते हैं, गुंडा?"

Comments

मुझे नहीं मिला।

— एमपीन

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

— हेनरिक

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

— हेनरिक

आह ... लेकिन यह प्रश्न वास्तव में गतिशील टाइपिंग के बारे में कभी नहीं था :)

— एमपीएन

आह, बहुत सच्चा रपल्ह। मैं बस गतिशील भाषाओं के बारे में अधिक ढीली सोचता हूं क्योंकि वे आमतौर पर अधिक ढीली होती हैं। हालांकि आप सही हैं।

— हेनरिक

Answer 5

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

Comments

+1: मैं पूरी तरह सहमत हूं। मैं देख नहीं क्यों KISS और YAGNI तरह सिद्धांतों भाषा डिजाइन के लिए लागू नहीं करना चाहिए।

— गियोर्जियो

Answer 6

मेरी व्यक्तिगत प्राथमिकता मेरे टाइपो को पकड़ने के लिए सिर्फ पर्याप्त सख्ती की क्षमता के लिए है, लेकिन जितना संभव हो उतना कम बायलरप्लेट के साथ। मैं इस मुद्दे पर http://www.perlmonks.org/?node_id=755790 पर बात करता हूं ।

उसने कहा, आप अपनी भाषा अपने लिए डिज़ाइन कर रहे हैं। आपको इसे वह बनाना चाहिए जो आप चाहते हैं।

Comments

+1: ... मेरे टाइपो को पकड़ने के लिए सिर्फ पर्याप्त सख्ती की क्षमता है, लेकिन जितना संभव हो उतना कम बायलरप्लेट के साथ। - हाँ। क्या आप C # के लिए एंडर्स हेजलबर्ग की योजना से परिचित हैं? वह "सार ओवर समारोह" पर जोर देने के लिए एक जागरूक निर्णय ले रहा है। channel9.msdn.com/Blogs/matthijs/…

— जिम जी।

@ जिम-जी: विचार के लिए धन्यवाद। मैं C # के बारे में बहुत कुछ से परिचित नहीं हूं। मैंने कई सालों से Microsoft की दुनिया में काम नहीं किया है।

— btilly

Answer 7

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

Answer 8

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

ईमानदार होने के लिए मैं भाषाओं का एक समूह देखूंगा कि वे क्या करते हैं और एक जगह खोजने की कोशिश करते हैं कि उनमें से कोई भी हिट न हो!

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

सौभाग्य।

Answer 9

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

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

  शब्दकोश <complexType1, complexType2> आइटम =
    नया शब्दकोश <complexType1, complexType2 ()>;

साथ में

  var आइटम = नया शब्दकोश <complexType1, complexType2 ()>;

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

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

Answer 10

मेरे लिए, पठनीयता सबसे महत्वपूर्ण है।

भाषा के साथ अनुभव करने वाले किसी व्यक्ति को, संदर्भ का गहराई से विश्लेषण किए बिना एक कोड टुकड़ा का अर्थ स्पष्ट होना चाहिए।

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

वाक्यविन्यास के अलावा, भाषा में स्पष्ट रूप से परिभाषित शब्दार्थ होना चाहिए, और शायद यह एक सभ्य वाक्य रचना पर निर्णय लेने से भी कठिन है ...

अच्छे उदाहरण:

• जावा में, "1"एक स्ट्रिंग है, 1एक इंट है, 1.0एक डबल है, और 1Lएक लंबा है। एक नज़र और आप जानते हैं कि यह क्या है।

• जावा में, =असाइनमेंट है। यह आदिम प्रकारों के लिए मान और संदर्भ प्रकारों के लिए संदर्भ प्रदान करता है। यह कभी भी जटिल डेटा या तुलना को कॉपी नहीं करता है।

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

खराब उदाहरण:

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

• जावा में, डॉट .का अधिक उपयोग किया जाता है। यह पैकेज के नाम के भीतर विभाजक, पैकेज और वर्ग के बीच विभाजक, बाहरी और आंतरिक वर्ग के बीच विभाजक, उदाहरण अभिव्यक्ति और विधि के बीच संबंधक, उदाहरण पर लागू किया जा सकता है, और बहुत कुछ है।

• कई भाषाओं में, ifब्लॉक के घुंघराले ब्रेसिज़ वैकल्पिक होते हैं, अगर किसी ने एक और कथन को (वास्तव में मौजूदा नहीं) ब्लॉक में जोड़ा है, तो गलतियाँ हो सकती हैं।

• Infix ऑपरेटरों: कभी-कभी मुझे एक संख्यात्मक अभिव्यक्ति पर रोकना पड़ता है और कठिन लगता है कि इसका क्या मतलब है, चरण-दर-चरण। हम सभी को infix संकेतन में गणित के भाव लिखने की आदत है a * b / c * d + e। अधिकांश समय हम गुणा और भाग के जोड़ और घटाव की पूर्वता को याद करते हैं (लेकिन क्या आपको पता है कि हम विभाजित नहीं कर रहे हैं c*d, लेकिन केवल cऔर फिर गुणा करके विभाजित कर रहे हैं d?)। लेकिन अपने स्वयं के पूर्ववर्ती नियमों और कुछ भाषाओं में ओवरलोडिंग के साथ कई अतिरिक्त इन्फिक्स ऑपरेटर हैं जो ट्रैक रखना मुश्किल है। शायद कोष्ठक के उपयोग को लागू करना एक बेहतर दृष्टिकोण रहा ...

Comments

आपने ज्यादातर अस्पष्टता के बारे में बात की है, लेकिन अस्पष्टता पैदा किए बिना एक ही काम करने के कई तरीके हो सकते हैं। शायद हमारे पास दो गुणा संचालक हो सकते हैं, *और ×। दोनों 5*3और 5 × 3` का मतलब एक ही बात है, और एक अनुभवी प्रोग्रामर को ठीक-ठीक पता है कि उन्हें आसपास के संदर्भ में देखने के बिना क्या मतलब है। हालाँकि, समस्या यह है कि अब एक ही काम करने के दो तरीके हैं और हो सकता है कि कोई उनके बीच पूरे कार्यक्रम के दौरान स्वैप कर दे। मेरा मानना ​​है कि जब मैंने सवाल पूछा तो मैं इस बारे में अधिक चिंतित था।

— एमपीएन

Answer 11

आप प्राकृतिक भाषा के साथ एक सादृश्य पर विचार कर सकते हैं। ईमेल में, आप एक व्याकरण नाजी हैं? या क्या आप कुछ व्याकरणिक त्रुटियों के साथ ठीक हैं, जैसे विभाजित infinatics, लापता संयोजन, या गलत संशोधक। उत्तर व्यक्तिगत पसंद को उबालता है।