सभी लेकिन सबसे तुच्छ कार्यक्रम कीड़े से भरे हुए हैं और इसलिए कुछ भी जो उन्हें हटाने का वादा करता है वह बेहद आकर्षक है। फिलहाल, शुद्धता प्रमाण कोड अत्यंत गूढ़ हैं, इसका मुख्य कारण यह सीखने की कठिनता और अतिरिक्त प्रयास के कारण कार्यक्रम को सही साबित करना है। क्या आपको लगता है कि कोड साबित करना कभी बंद हो जाएगा?
जवाबों:
वास्तव में उस अर्थ में नहीं, लेकिन इस क्षेत्र में शुद्ध कार्यात्मक प्रोग्रामिंग अच्छी है। यदि आप हास्केल का उपयोग करते हैं, तो यह संभावना है कि कोड संकलित होने पर आपका कार्यक्रम सही है। IO को छोड़कर, एक अच्छी प्रकार प्रणाली एक अच्छी मदद है।
इसके अलावा अनुबंध करने के लिए प्रोग्रामिंग सहायक हो सकता है। Microsoft कोड अनुबंध देखें
सभी लेकिन सबसे तुच्छ कार्यक्रम
पूरी तरह से उचित प्रयास के साथ सही होने का प्रमाण नहीं दिया जा सकता है। शुद्धता के किसी भी औपचारिक प्रमाण के लिए, आपको कम से कम एक औपचारिक कल्पना की आवश्यकता होती है, और उस कल्पना को पूर्ण और सही होना चाहिए। यह आम तौर पर कुछ भी नहीं है जो आप आसानी से अधिकांश वास्तविक दुनिया के कार्यक्रमों के लिए बना सकते हैं। उदाहरण के लिए, इस चर्चा साइट के उपयोगकर्ता इंटरफ़ेस जैसी किसी चीज़ के लिए इस तरह की कल्पना लिखने की कोशिश करें, और आप जानते हैं कि मेरा क्या मतलब है।
यहाँ मुझे इस विषय पर एक अच्छा लेख मिला:
http://www.encyclopedia.com/doc/1O11-programcorrectnessproof.html
printf("1")सही है या नहीं (उदाहरण के लिए, क्योंकि आवश्यकता "समान रूप से वितरित यादृच्छिक संख्या 1 से 6 तक प्रिंट करना था") इस तरह के एक स्थिर विश्लेषक द्वारा निर्णय नहीं लिया जा सकता है।
औपचारिक प्रमाणों के साथ समस्या यह है कि यह समस्या को केवल एक कदम पीछे ले जाता है।
यह कहना कि एक कार्यक्रम सही है, यह कहने के बराबर है कि एक कार्यक्रम वह करता है जो उसे करना चाहिए। आप कैसे परिभाषित करते हैं कि कार्यक्रम क्या करना चाहिए? आप इसे निर्दिष्ट करें। और आप कैसे परिभाषित करते हैं कि किनारे के मामलों में कार्यक्रम को क्या करना चाहिए जो कल्पना को कवर नहीं करता है? ठीक है, तो आपको कल्पना को और अधिक विस्तृत करना होगा।
तो चलिए बताते हैं कि आखिरकार आपकी कल्पना पूरे कार्यक्रम के हर पहलू के सही व्यवहार का वर्णन करने के लिए पर्याप्त विस्तृत हो जाती है। अब आपको अपने प्रमाण साधनों को समझने के लिए एक तरीका चाहिए। तो आपको ऐनक को किसी प्रकार की औपचारिक भाषा में अनुवाद करना होगा जिसे प्रूफ टूल समझ सके ... अरे, एक मिनट रुकिए!
औपचारिक सत्यापन एक लंबा रास्ता तय कर चुका है, लेकिन आमतौर पर उद्योग / व्यापक रूप से उपयोग किए गए उपकरण नवीनतम शोध से पीछे हैं। इस दिशा में हाल के कुछ प्रयास इस प्रकार हैं:
कल्पना # http://research.microsoft.com/en-us/projects/specsharp/ यह C # का एक एक्सटेंशन है जो कोड कॉन्ट्रैक्ट्स (पूर्व / पोस्ट की शर्तों और आक्रमणकारियों) का समर्थन करता है और विभिन्न प्रकार के स्थैतिक विश्लेषण करने के लिए इन अनुबंधों का उपयोग कर सकता है ।
इसी तरह की परियोजनाएं अन्य भाषाओं के लिए मौजूद हैं, जैसे जावा के लिए जेएमएल, और एफिल में यह बहुत अधिक अंतर्निहित है।
इससे भी आगे जाने पर, स्लैम और ब्लास्ट जैसी परियोजनाओं का उपयोग न्यूनतम प्रोग्रामर एनोटेशन / हस्तक्षेप के साथ कुछ व्यवहार गुणों को सत्यापित करने के लिए किया जा सकता है, लेकिन फिर भी आधुनिक भाषाओं की पूर्ण व्यापकता (पूर्णांक अतिप्रवाह / सूचक अंकगणित की मॉडलिंग नहीं की जाती है) के साथ व्यवहार नहीं कर सकता है।
मुझे विश्वास है कि हम भविष्य में प्रयोग की जाने वाली इन तकनीकों में से बहुत कुछ देखेंगे। मुख्य बाधा यह है कि प्रोग्राम इनवेरिएंट्स मैनुअल एनोटेशन के बिना अनुमान लगाना मुश्किल है, और प्रोग्रामर आमतौर पर इन एनोटेशन प्रदान करने के लिए तैयार नहीं हैं क्योंकि ऐसा करना बहुत थकाऊ / समय लेने वाला है।
तब तक नहीं जब तक कि व्यापक डेवलपर कार्य के बिना कोड को स्वचालित रूप से साबित करने की एक विधि उत्पन्न न हो।
कुछ औपचारिक तरीकों के उपकरण (जैसे गंभीर एम्बेडेड सी सॉफ़्टवेयर के लिए फ्रामा-सी ) को (सॉर्ट-ऑफ) प्रदान करने, या कम से कम जाँच करने, (दिए गए सॉफ़्टवेयर का प्रमाण) के रूप में देखा जा सकता है। (फ्रामा-सी जाँचें कि एक कार्यक्रम अपने औपचारिक विनिर्देश का पालन करता है, कुछ अर्थों में, और कार्यक्रम में स्पष्ट रूप से एनोटेट का सम्मान करता है)।
कुछ क्षेत्रों में, इस तरह के औपचारिक तरीके संभव हैं, जैसे कि नागरिक विमान में महत्वपूर्ण सॉफ्टवेयर के लिए DO-178C । तो कुछ मामलों में, ऐसे दृष्टिकोण संभव और सहायक हैं।
बेशक, कम बग्गी सॉफ्टवेयर विकसित करना बहुत महंगा है। लेकिन औपचारिक विधि दृष्टिकोण कुछ प्रकार के सॉफ़्टवेयर के लिए समझ में आता है। यदि आप निराशावादी हैं, तो आप सोच सकते हैं कि बग को कोड से उसके औपचारिक विनिर्देश में स्थानांतरित कर दिया गया है (जिसमें कुछ "बग" हो सकते हैं, क्योंकि किसी सॉफ़्टवेयर के इच्छित व्यवहार को औपचारिक बनाना मुश्किल है और त्रुटि प्रवण है)।
मैं इस सवाल पर अड़ गया, और मुझे लगता है कि यह लिंक दिलचस्प हो सकता है:
2003 में कोड के 130K से अधिक लाइनों के साथ एयरबस द्वारा उपयोग किए जाने वाले सिस्टम में RTE की अनुपस्थिति को साबित करना बुरा नहीं लगता है, और मुझे आश्चर्य है कि कोई भी व्यक्ति यह कहेगा कि यह वास्तविक दुनिया नहीं है।
इसके लिए सामान्य कहावत है, "सिद्धांत, सिद्धांत और व्यवहार में समान हैं। व्यवहार में, नहीं।"
एक बहुत ही सरल उदाहरण: टाइपोस।
वास्तव में इकाई परीक्षण के माध्यम से कोड चलाने से ऐसी चीजें लगभग तुरंत मिल जाती हैं, और परीक्षणों का एक सुसंगत सेट किसी भी औपचारिक प्रमाण की आवश्यकता को नकार देगा। सभी उपयोग मामलों - अच्छे, बुरे, त्रुटि और किनारे के मामलों - को यूनिट परीक्षणों में गणना की जानी चाहिए, जो अंत में बेहतर प्रमाण के रूप में कोड किसी भी ऐसे प्रमाण की तुलना में सही है जो कोड से अलग है।
खासकर यदि आवश्यकताएं बदल जाती हैं, या बग को ठीक करने के लिए एल्गोरिथ्म को अपडेट किया जाता है - औपचारिक प्रमाण की तारीख खत्म होने की संभावना अधिक होती है, जैसा कि कोड टिप्पणी अक्सर मिलती है।
मुझे लगता है कि रुकने की समस्या के कारण शुद्धता प्रमाणों पर लगाई गई सीमाएँ मुख्यधारा के प्रमाण बनने में शुद्धता के लिए सबसे बड़ी बाधा हो सकती हैं।
यह पहले से ही सभी द्वारा उपयोग किया जाता है। हर बार जब आप अपनी प्रोग्रामिंग भाषा के प्रकार की जाँच करते हैं, तो आप मूल रूप से अपने प्रोग्राम की शुद्धता का गणित प्रमाण कर रहे होते हैं। यह पहले से ही बहुत अच्छी तरह से काम करता है - इसके लिए आपको केवल हर फ़ंक्शन और डेटा संरचना के लिए सही प्रकार चुनने की आवश्यकता होती है। अधिक सटीक प्रकार, बेहतर जाँच आप प्राप्त करने जा रहे हैं। प्रोग्रामिंग भाषाओं में उपलब्ध मौजूदा प्रकार में पहले से ही लगभग किसी भी संभावित व्यवहार का वर्णन करने के लिए शक्तिशाली पर्याप्त उपकरण हैं। यह हर उपलब्ध भाषा में काम करता है। C ++ और स्थैतिक भाषाएं केवल संकलन-समय में चेक कर रही हैं, जबकि अजगर की तरह अधिक गतिशील भाषाएं प्रोग्राम चलाए जाने पर कर रही हैं। इन सभी भाषाओं में चेक अभी भी मौजूद है। (उदाहरण के लिए, c ++ पहले ही साइड इफेक्ट्स की जाँच उसी तरह से करता है जिस तरह से हैस्केल करता है,
mutableया वे अभी भी परिवर्तनीय हैं const_cast। मैं निश्चित रूप से आपके द्वारा खींचे गए कनेक्शन को देखता हूं, लेकिन दो दृष्टिकोणों का स्वाद मुझे अलग लगता है।