अधिकांश आधुनिक प्रोग्रामिंग भाषाओं में अनुबंध द्वारा डिजाइन के लिए इतना सीमित समर्थन क्यों है?


40

मैंने हाल ही में कॉन्ट्रैक्ट (DbC) द्वारा डिज़ाइन की खोज की और मुझे यह कोड लिखने का एक बेहद दिलचस्प तरीका लगा। अन्य बातों के अलावा, यह पेशकश करने के लिए प्रतीत होता है:

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

तुलना में लागत, बल्कि छोटी लगती है:

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

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

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


आपके प्रोग्राम का परीक्षण करने के लाभ के बिना परीक्षण संचालित प्रोग्रामिंग करने के लिए एक अति जटिल तरीके की तरह लगता है।
दान

3
@, वास्तव में नहीं, मैं इसे अधिक प्रकार के सिस्टम के विस्तार के रूप में सोचता हूं। जैसे कोई फ़ंक्शन केवल पूर्णांक तर्क नहीं लेता है, यह एक पूर्णांक लेता है जो संविदा शून्य से अधिक होने के लिए बाध्य है
Carson63000

4
@ कोड कोड आपके द्वारा किए जाने वाले परीक्षणों की संख्या को काफी कम कर देता है।
री मियाँसाक

24
@ मैं, मैं कहना चाहूंगा कि टीडीडी गरीब-आदमी का अनुबंध है, इसके विपरीत नहीं।
एसके-तर्क

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

जवाबों:


9

संभवतः वे लगभग हर प्रोग्रामिंग भाषा में समर्थित हैं।

आपको जो चाहिए वह "जोर" है।

इन्हें आसानी से "यदि" कथनों के रूप में कोडित किया जाता है:

if (!assertion) then AssertionFailure();

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

इसलिए मेरा तर्क है कि वे व्यापक नहीं हैं क्योंकि प्रोग्रामर उन्हें कोड करने के लिए बहुत आलसी हैं, इसलिए नहीं कि आप ऐसा नहीं कर सकते।

आप एक संकलन समय बूलियन निरंतर "जाँच" को परिभाषित करके और बयानों को थोड़ा संशोधित करके अधिकांश भाषाओं में इसे थोड़ा अधिक कुशल बना सकते हैं:

if (checking & !Assertion) then AssertionFailure();

यदि आपको सिंटैक्स पसंद नहीं है, तो आप विभिन्न भाषा अमूर्त तकनीकों जैसे मैक्रोज़ का सहारा ले सकते हैं।

कुछ आधुनिक भाषाएं आपको इसके लिए अच्छा सिंटैक्स देती हैं, और मुझे लगता है कि आपको "आधुनिक भाषा समर्थन" से मतलब है। यह समर्थन है, लेकिन इसकी बहुत पतली है।

आधुनिक भाषाओं में से अधिकांश जो आपको नहीं देती हैं, वे "टेम्पोरल" दावे हैं (पूर्ववर्ती या निम्न राज्यों में [अस्थायी ऑपरेटर "अंततः"], जिसकी आपको ज़रूरत है अगर आप वास्तव में दिलचस्प अनुबंध लिखना चाहते हैं। यदि कथन मदद नहीं करेगा। हां, आप।


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

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

7
... बस जाँच की गई कि एफिल कैसे काम करता है। "पुराना <exp>" फ़ंक्शन के प्रवेश पर <exp> का मूल्य है, इसलिए यह फ़ंक्शन प्रवेश पर उथली प्रतियां कर रहा है जैसा कि मुझे उम्मीद थी। आप उन्हें भी कर सकते हैं। मैं सहमत हूँ कि संकलक प्री / पोस्ट / पुराने के लिए वाक्यविन्यास को लागू करना हाथ से यह सब करने की तुलना में अधिक सुविधाजनक है, लेकिन बिंदु एक हाथ से यह कर सकता है और यह वास्तव में कठिन नहीं है। हम आलसी प्रोग्रामर वापस आ गए हैं।
इरा बाक्सटर

यदि आप अनुबंध को वास्तविक तर्क से अलग कर सकते हैं तो @IraBaxter No. कोड सरल हो जाता है। साथ ही, यदि कंपाइलर कॉन्ट्रैक्ट और कोड को अलग-अलग बता सकता है, तो यह डुप्लिकेट को बहुत कम कर सकता है । जैसे डी में आप एक इंटरफ़ेस या सुपरक्लास पर एक अनुबंध की घोषणा कर सकते हैं और उनके कार्यों में कोड की परवाह किए बिना, सभी कार्यान्वयन / विस्तारित कक्षाओं में दावे लागू किए जाएंगे। उदाहरण के लिए अजगर या जावा के साथ, आपको पूरी superविधि को लागू करना होगा और संभवत: परिणामों को फेंकना होगा यदि आप केवल अनुलिपि की जाँच के अनुबंध चाहते हैं। यह वास्तव में स्वच्छ एलएसपी अनुरूप कोड को लागू करने में मदद करता है।
Marstato

@marstato: मैं पहले ही सहमत था कि भाषा में समर्थन एक अच्छी बात है।
इरा

15

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

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

मुझे लगता है कि अगर आप आज औसत डेवलपर के पास जाते और पोस्ट-स्थितियों के बारे में बात करते, तो वे उत्साह से सिर हिलाते और कहते "ठीक है, यह यूनिट-परीक्षण जैसा है।" और यदि आप पूर्व स्थितियों के बारे में बात करते हैं, तो वे कहेंगे "ठीक है, यह पैरामीटर सत्यापन की तरह है, जो हम हमेशा नहीं करते हैं, लेकिन, y'know, मुझे लगता है कि यह ठीक है ..." और फिर अगर आप आक्रमणकारियों के बारे में बात करते हैं , वे कहने लगे "जी, कितना उपरि है? हम और कितने कीड़े पकड़ने जा रहे हैं?" आदि।

इसलिए मुझे लगता है कि DbC को व्यापक रूप से अपनाने से पहले अभी भी एक लंबा रास्ता तय करना है।


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

8

मेरा अंतर्ज्ञान मुझे बताता है कि समर्थन की कमी अभ्यास की अस्वीकृति के परिणामस्वरूप होनी चाहिए, ...

असत्य।

यह एक डिजाइन अभ्यास है। इसे कोड (एफिल स्टाइल) या स्पष्ट रूप से कोड (अधिकांश भाषाओं) या इकाई परीक्षणों में स्पष्ट रूप से सन्निहित किया जा सकता है। डिजाइन अभ्यास मौजूद है और अच्छी तरह से काम करता है। भाषा का समर्थन सभी मानचित्र पर है। हालाँकि, यह इकाई परीक्षण ढांचे में कई भाषाओं में मौजूद है।

मुझे आश्चर्य है कि अगर कोई स्पष्ट कर सकता है कि अधिकांश आधुनिक भाषाएं इतना कम समर्थन क्यों देती हैं? क्या DbC त्रुटिपूर्ण या अत्यधिक महंगा है?

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

या यह सिर्फ चरम प्रोग्रामिंग और अन्य तरीकों के कारण अप्रचलित है?

नहीं।

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

अजगर के लिए, जैसा कि आपने उल्लेख किया है, डीबीसी कई स्थानों पर जाता है।

  1. डॉकस्ट्रिंग और डॉकस्ट्रिंग परीक्षा परिणाम।

  2. इनपुट और आउटपुट को मान्य करने के लिए दावे।

  3. यूनिट परीक्षण।

आगे की।

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


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

+1। मुझे लगता है कि आप केवल वही हैं जिसने सबसे महत्वपूर्ण बिंदु को कवर किया है - there are some things which cannot be proven। औपचारिक सत्यापन महान हो सकता है, लेकिन सब कुछ सत्यापित नहीं है! तो यह सुविधा वास्तव में प्रतिबंधित करती है कि प्रोग्रामिंग भाषा वास्तव में क्या कर सकती है!
दीपन मेहता १६'१२ को १२:२०

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

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

6

सिर्फ अनुमान। शायद इस वजह से कि यह इतना लोकप्रिय नहीं है कि इसका हिस्सा एफ़िल द्वारा ट्रेडमार्क "अनुबंध द्वारा डिज़ाइन" है।


3

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

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


> कॉन्ट्रैक्ट्स का द्रव्यमान खुद बग्गी और डिबग के रूप में कठिन हो सकता है, या अधिक-तो, प्रोग्राम कोड की तुलना में अकेले मैंने यह कभी नहीं देखा है।
काइटेन

2

अधिकांश मुख्यधारा की भाषाओं में DbC की विशेषताएं नहीं होने का कारण यह है कि इसे लागू करने वाले के लिए अनुपात का लाभ उठाने की लागत भाषा कार्यान्वयनकर्ता के लिए अधिक है।

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

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

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


2

DbC का अधिक व्यापक रूप से उपयोग किया जाएगा यदि अनुबंधों का संकलन समय पर किया जा सकता है ताकि किसी भी अनुबंध का उल्लंघन करने वाले प्रोग्राम को चलाना संभव न हो।

संकलक समर्थन के बिना, "DbC" केवल "इन्वर्टर / मान्यताओं की जांच करें और उल्लंघन होने पर एक अपवाद फेंकें" के लिए एक अन्य नाम है।


क्या यह समस्या हल करने में नहीं है?
सीसर बॉतिस्ता

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

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

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

1

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

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

शायद यही कारण है कि मुझे लगता है कि एडा ने विमानन प्रोग्रामिंग उद्योग के बाहर कभी नहीं उठाया क्योंकि यह अधिक कोडिंग का काम करता है, हालांकि एडीए भयानक भाषा है और यदि आप एक विश्वसनीय प्रणाली बनाना चाहते हैं, तो यह नौकरी के लिए सबसे अच्छी भाषा है (स्पार्क को छोड़कर) Ada पर आधारित भाषा)।

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

पूर्व / पोस्ट की स्थिति और अपरिवर्तनीय के लिए दावे पूरी तरह कार्यात्मक समर्थन के समान नहीं हैं। यद्यपि यह उनका अनुकरण करने की कोशिश कर सकता है लेकिन उचित समर्थन के साथ एक भाषा / संकलक 'अमूर्त वाक्यविन्यास वृक्ष' का विश्लेषण करता है और तर्क त्रुटियों के लिए जाँच करता है जो कि केवल दावे नहीं कर सकते हैं।

संपादित करें: मैंने एक खोज की और निम्नलिखित संबंधित चर्चा है जो सहायक हो सकती है: https://stackoverflow.com/questions/4065001/are-there-any-provable-real-world-languages-scala


-2

अधिकतर कारण निम्नानुसार हैं:

  1. यह केवल उन भाषाओं में उपलब्ध है जो लोकप्रिय नहीं हैं
  2. यह अनावश्यक है क्योंकि एक ही सामान को मौजूदा प्रोग्रामिंग भाषाओं में किसी के द्वारा अलग तरीके से किया जा सकता है जो वास्तव में इसे करना चाहता है
  3. इसे समझना और उपयोग करना मुश्किल है - इसे ठीक से करने के लिए विशेष ज्ञान की आवश्यकता होती है, इसलिए इसे करने वाले लोगों की संख्या कम है
  4. इसे करने के लिए बड़ी मात्रा में कोड की आवश्यकता होती है - प्रोग्रामर अपने द्वारा लिखे गए पात्रों की मात्रा को कम करना पसंद करते हैं - यदि यह कोड का लंबा टुकड़ा लेता है, तो कुछ इसे गलत होना चाहिए
  5. फायदे नहीं हैं - इसे सार्थक बनाने के लिए सिर्फ पर्याप्त कीड़े नहीं मिल सकते हैं

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

मैं इसके प्रतिस्थापन के रूप में अभिकथन आदि के बारे में नहीं सोच रहा हूँ। मौजूदा भाषाओं में इसे करने का सही तरीका नहीं है। (यानी इसे अभी तक संबोधित नहीं किया गया है)
tp1

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

@ Sk- तर्क: ठीक है, ऐसा लगता है कि आधी दुनिया केवल OO को गलत कर रही है क्योंकि वे सदस्य कार्यों से अग्रेषण कार्यों को डेटा सदस्यों के सदस्य कार्यों में लिखना नहीं चाहते हैं। मेरे अनुभव में यह एक बड़ी समस्या है। यह सीधे वर्ण लिखने की संख्या को कम करने के कारण होता है।
tp1

@ tp1, अगर लोग वास्तव में टाइपिंग को कम से कम करना चाहते हैं, तो वे कभी भी, ओओ को स्पर्श नहीं करेंगे। OOP स्वाभाविक रूप से वाक्पटु है, यहां तक ​​कि स्मॉलटाक जैसे इसके सर्वश्रेष्ठ कार्यान्वयन में भी। मैं यह नहीं कहूंगा कि यह एक बुरी संपत्ति है, वाक्पटुता कभी-कभी मदद करती है।
एसके-लॉजिक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.