प्रोग्रामिंग कोडिंग से कहीं अधिक है

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

जब मैंने वह देखा लेस्ली लामपोर्ट (हाँ, पाठ्यपुस्तकों वाला वही मित्र) रूस आता है और कोई रिपोर्ट नहीं दे रहा है, बल्कि एक प्रश्न-उत्तर सत्र दे रहा है, मैं थोड़ा सावधान था। बस मामले में, लेस्ली एक विश्व-प्रसिद्ध वैज्ञानिक हैं, वितरित कंप्यूटिंग में मौलिक कार्यों के लेखक हैं, और आप उन्हें LaTeX - "Lamport TeX" में ला अक्षरों से भी जानते होंगे। दूसरा चिंताजनक कारक उसकी आवश्यकता है: जो कोई भी आता है उसे (पूरी तरह से नि:शुल्क) उसकी कुछ रिपोर्ट पहले से सुननी होगी, उनके बारे में कम से कम एक प्रश्न पूछना होगा और उसके बाद ही आना होगा। मैंने यह देखने का निर्णय लिया कि लैमपोर्ट वहां क्या प्रसारित कर रहा था - और यह बहुत अच्छा है! यह बिल्कुल वही चीज़ है, ज़ोंबी के इलाज के लिए एक जादुई लिंक-गोली। मैं आपको चेतावनी देता हूं: यह पाठ उन लोगों को गंभीर रूप से परेशान कर सकता है जो सुपर-एजाइल पद्धतियों को पसंद करते हैं और जो अपने द्वारा लिखी गई बातों का परीक्षण करना पसंद नहीं करते हैं।

हब्रोकैट के बाद वास्तव में सेमिनार का अनुवाद शुरू होता है। मन लगाकर पढ़ाई करो!

आप जो भी कार्य हाथ में लेते हैं, आपको हमेशा तीन चरणों से गुजरना पड़ता है:

• तय करें कि आप कौन सा लक्ष्य प्राप्त करना चाहते हैं;
• तय करें कि आप वास्तव में अपना लक्ष्य कैसे प्राप्त करेंगे;
• अपने लक्ष्य तक पहुँचो।

यह बात प्रोग्रामिंग पर भी लागू होती है. जब हम कोड लिखते हैं, तो हमें इसकी आवश्यकता होती है:

• तय करें कि प्रोग्राम को वास्तव में क्या करना चाहिए;
• यह निर्धारित करें कि उसे अपना कार्य कैसे करना चाहिए;
• उचित कोड लिखें.

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

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

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

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

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

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

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

आइए पहले चरण पर करीब से नज़र डालें: प्रोग्राम किस समस्या का समाधान करता है। यहां हम अक्सर एक प्रोग्राम को एक फ़ंक्शन के रूप में मॉडल करते हैं जो कुछ इनपुट लेता है और कुछ आउटपुट देता है। गणित में, किसी फ़ंक्शन को आमतौर पर जोड़ियों के क्रमबद्ध सेट के रूप में वर्णित किया जाता है। उदाहरण के लिए, प्राकृतिक संख्याओं के लिए वर्ग फ़ंक्शन को सेट {<0,0>, <1,1>, <2,4>, <3,9>, …} के रूप में वर्णित किया गया है। ऐसे फ़ंक्शन की परिभाषा का क्षेत्र प्रत्येक जोड़ी के पहले तत्वों का सेट है, यानी प्राकृतिक संख्याएं। किसी फ़ंक्शन को परिभाषित करने के लिए, हमें उसका डोमेन और सूत्र निर्दिष्ट करना होगा।

लेकिन गणित में फ़ंक्शन प्रोग्रामिंग भाषाओं में फ़ंक्शन के समान नहीं हैं। गणित बहुत सरल है. चूँकि मेरे पास जटिल उदाहरणों के लिए समय नहीं है, आइए एक सरल उदाहरण पर विचार करें: C में एक फ़ंक्शन या जावा में एक स्थिर विधि जो दो पूर्णांकों का सबसे बड़ा सामान्य भाजक लौटाती है। इस विधि के विनिर्देशन में हम लिखेंगे: गणना करता है GCD(M,N) तर्क के लिए M и Nजहां GCD(M,N) - एक फ़ंक्शन जिसका डोमेन पूर्णांकों के जोड़े का एक सेट है, और रिटर्न मान सबसे बड़ा पूर्णांक है जिसे विभाजित किया गया है M и N. वास्तविकता की तुलना इस मॉडल से कैसे की जाती है? मॉडल पूर्णांकों के साथ संचालित होता है, और सी या जावा में हमारे पास 32-बिट है int. यह मॉडल हमें यह तय करने की अनुमति देता है कि एल्गोरिदम सही है या नहीं GCD, लेकिन यह अतिप्रवाह त्रुटियों को नहीं रोकेगा। इसके लिए अधिक जटिल मॉडल की आवश्यकता होगी, जिसके लिए समय नहीं है।

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

आइए देखें कि यूक्लिडियन एल्गोरिथम का दूसरा चरण कैसा दिखेगा। हमें हिसाब लगाने की जरूरत है GCD(M, N). हम आरंभ करते हैं M जैसा xऔर N जैसा y, फिर इन चरों में से छोटे को बड़े से तब तक बार-बार घटाएं जब तक वे बराबर न हो जाएं। उदाहरण के लिए, यदि M = 12और N = 18, हम निम्नलिखित व्यवहार का वर्णन कर सकते हैं:

[x = 12, y = 18] → [x = 12, y = 6] → [x = 6, y = 6]

और अगर M = 0 и N = 0? शून्य सभी संख्याओं से विभाज्य है, इसलिए इस मामले में कोई सबसे बड़ा भाजक नहीं है। इस स्थिति में, हमें पहले चरण पर वापस जाना होगा और पूछना होगा: क्या हमें वास्तव में गैर-सकारात्मक संख्याओं के लिए जीसीडी की गणना करने की आवश्यकता है? यदि यह आवश्यक नहीं है, तो आपको केवल विनिर्देश बदलने की आवश्यकता है।

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

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

हम पहले संभावित प्रारंभिक अवस्थाओं का एक सेट निर्दिष्ट करके सुरक्षा प्राप्त करते हैं। और दूसरी बात, प्रत्येक राज्य के लिए सभी संभावित अगले राज्यों के साथ संबंध। आइए वैज्ञानिकों की तरह व्यवहार करें और राज्यों को गणितीय रूप से परिभाषित करें। प्रारंभिक अवस्थाओं का सेट सूत्र द्वारा वर्णित है, उदाहरण के लिए, यूक्लिडियन एल्गोरिथ्म के मामले में: (x = M) ∧ (y = N). कुछ मूल्यों के लिए M и N केवल एक प्रारंभिक अवस्था है. अगली स्थिति के साथ संबंध को एक सूत्र द्वारा वर्णित किया जाता है जिसमें अगली स्थिति के चर को अभाज्य के साथ लिखा जाता है, और वर्तमान स्थिति के चर को अभाज्य के बिना लिखा जाता है। यूक्लिडियन एल्गोरिथ्म के मामले में, हम दो सूत्रों के विच्छेदन से निपटेंगे, जिनमें से एक में x सबसे बड़ा मूल्य है, और दूसरे में - y:

पहले मामले में, y का नया मान y के पिछले मान के बराबर है, और हमें बड़े चर में से छोटे चर को घटाकर x का नया मान प्राप्त होता है। दूसरे मामले में, हम इसके विपरीत करते हैं।

आइए यूक्लिडियन एल्गोरिथम पर वापस लौटें। फिर से मान लीजिये M = 12, N = 18. यह एकल प्रारंभिक अवस्था को परिभाषित करता है, (x = 12) ∧ (y = 18). फिर हम इन मानों को उपरोक्त सूत्र में प्लग करते हैं और प्राप्त करते हैं:

यहाँ एकमात्र संभावित समाधान है: x' = 18 - 12 ∧ y' = 12, और हमें व्यवहार मिलता है: [x = 12, y = 18]. इसी प्रकार, हम अपने व्यवहार की सभी अवस्थाओं का वर्णन कर सकते हैं: [x = 12, y = 18] → [x = 12, y = 6] → [x = 6, y = 6].

अंतिम अवस्था में [x = 6, y = 6] अभिव्यक्ति के दोनों भाग झूठे होंगे, इसलिए इसकी कोई अगली स्थिति नहीं है। तो, हमारे पास दूसरे चरण का पूरा विवरण है - जैसा कि हम देखते हैं, यह इंजीनियरों और वैज्ञानिकों की तरह बिल्कुल सामान्य गणित है, और कंप्यूटर विज्ञान की तरह अजीब नहीं है।

इन दोनों सूत्रों को लौकिक तर्क के एक सूत्र में जोड़ा जा सकता है। यह सुंदर है और समझाने में आसान है, लेकिन अब इसके लिए समय नहीं है। हमें अस्थायी तर्क की आवश्यकता केवल जीवंतता की संपत्ति के लिए हो सकती है; सुरक्षा के लिए इसकी आवश्यकता नहीं है। मुझे अस्थायी तर्क पसंद नहीं है, यह बिल्कुल सामान्य गणित नहीं है, लेकिन जीवंतता के मामले में यह एक आवश्यक बुराई है।

प्रत्येक मान के लिए यूक्लिडियन एल्गोरिथ्म में x и y अद्वितीय मूल्य हैं x' и y', जो अगले राज्य के साथ संबंध को सत्य बनाता है। दूसरे शब्दों में, यूक्लिडियन एल्गोरिथ्म नियतात्मक है। एक गैर-नियतात्मक एल्गोरिथ्म को मॉडल करने के लिए, वर्तमान स्थिति में भविष्य की कई संभावित स्थितियाँ होनी चाहिए, और अप्रकाशित चर के प्रत्येक मान में प्राइमेड चर के कई मान होने चाहिए जैसे कि अगले राज्य से संबंध सत्य हो। ऐसा करना मुश्किल नहीं है, लेकिन मैं अब उदाहरण नहीं दूंगा।

एक कार्यशील उपकरण बनाने के लिए, आपको औपचारिक गणित की आवश्यकता होती है। किसी विशिष्टता को औपचारिक कैसे बनाएं? ऐसा करने के लिए हमें एक औपचारिक भाषा की आवश्यकता होगी, उदा. टीएलए+. इस भाषा में यूक्लिडियन एल्गोरिथम की विशिष्टता इस प्रकार दिखाई देगी:

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

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

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

शायद किसी को आपत्ति होगी कि TLA+ और PlusCal गणित हैं, और गणित केवल बने-बनाए उदाहरणों के साथ काम करता है। व्यवहार में, आपको प्रकारों, प्रक्रियाओं, वस्तुओं आदि के साथ एक वास्तविक भाषा की आवश्यकता होती है। यह गलत है। अमेज़ॅन में काम करने वाले क्रिस न्यूकॉम्ब क्या लिखते हैं: “हमने दस बड़ी परियोजनाओं पर टीएलए+ का उपयोग किया है, और हर मामले में इसके उपयोग से विकास में महत्वपूर्ण अंतर आया है क्योंकि हम खतरनाक बगों को उत्पादन में आने से पहले ही पकड़ने में सक्षम थे, और क्योंकि इससे हमें वह अंतर्दृष्टि और आत्मविश्वास मिला जो हमें आक्रामक बनाने के लिए आवश्यक था। कार्यक्रम की सच्चाई को प्रभावित किए बिना प्रदर्शन अनुकूलन". आप अक्सर सुन सकते हैं कि औपचारिक तरीकों का उपयोग करते समय हमें अप्रभावी कोड मिलता है - व्यवहार में, सब कुछ बिल्कुल विपरीत होता है। इसके अलावा, ऐसी धारणा है कि प्रबंधकों को औपचारिक तरीकों की आवश्यकता के बारे में आश्वस्त नहीं किया जा सकता है, भले ही प्रोग्रामर उनकी उपयोगिता के बारे में आश्वस्त हों। और न्यूकॉम्ब लिखते हैं: "प्रबंधक अब टीएलए+ में विशिष्टताओं को लिखने के लिए हर संभव तरीके से जोर दे रहे हैं, और इसके लिए विशेष रूप से समय आवंटित कर रहे हैं". इसलिए जब प्रबंधक देखते हैं कि TLA+ काम करता है, तो वे इसे अपना लेते हैं। क्रिस न्यूकॉम्ब ने इसे लगभग छह महीने पहले (अक्टूबर 2014) लिखा था, लेकिन अब, जहां तक ​​मुझे पता है, टीएलए+ का उपयोग 14 नहीं, बल्कि 10 परियोजनाओं में किया जाता है। एक अन्य उदाहरण एक्सबॉक्स 360 के डिजाइन से संबंधित है। एक प्रशिक्षु चार्ल्स थैकर के पास आया और मेमोरी सिस्टम के लिए विशिष्टताएँ लिखीं। इस विनिर्देश के लिए धन्यवाद, एक बग पाया गया जिसका अन्यथा पता नहीं चल पाता और चार घंटे के उपयोग के बाद प्रत्येक XBox 360 क्रैश हो जाता। आईबीएम के इंजीनियरों ने पुष्टि की कि उनके परीक्षणों में इस बग का पता नहीं चला होगा।

आप इंटरनेट पर TLA+ के बारे में अधिक पढ़ सकते हैं, लेकिन अब अनौपचारिक विशिष्टताओं के बारे में बात करते हैं। हमें शायद ही कभी ऐसे प्रोग्राम लिखने पड़ते हैं जो न्यूनतम सामान्य भाजक और इसी तरह की गणना करते हैं। अक्सर हम प्रीटी-प्रिंटर टूल जैसे प्रोग्राम लिखते हैं जो मैंने टीएलए+ के लिए लिखा था। सरलतम प्रसंस्करण के बाद, TLA+ कोड इस तरह दिखेगा:

लेकिन उपरोक्त उदाहरण में, उपयोगकर्ता संभवतः संयोजन और समान चिह्नों को संरेखित करना चाहता था। तो सही स्वरूपण इस तरह दिखेगा:

एक अन्य उदाहरण पर विचार करें:

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

ऐसा प्रतीत होता है कि यदि हमारे पास सत्य की परिभाषा नहीं है, तो विशिष्टता बेकार है। लेकिन यह सच नहीं है. सिर्फ इसलिए कि हम नहीं जानते कि किसी प्रोग्राम को क्या करना चाहिए इसका मतलब यह नहीं है कि हमें यह सोचने की ज़रूरत नहीं है कि इसे कैसे काम करना चाहिए - इसके विपरीत, हमें इस पर और भी अधिक प्रयास खर्च करना चाहिए। विशिष्टता यहाँ विशेष रूप से महत्वपूर्ण है. संरचित मुद्रण के लिए इष्टतम कार्यक्रम निर्धारित करना असंभव है, लेकिन इसका मतलब यह नहीं है कि हमें इसे बिल्कुल नहीं करना चाहिए, और चेतना की धारा के रूप में कोड लिखना मामला नहीं है। मैंने परिभाषाओं के साथ छह नियमों का एक विवरण लिखना समाप्त कर दिया टिप्पणियों के रूप में एक जावा फ़ाइल में. यहां एक नियम का उदाहरण दिया गया है: a left-comment token is LeftComment aligned with its covering token. यह नियम, मान लीजिए, गणितीय अंग्रेजी में लिखा गया है: LeftComment aligned, left-comment и covering token - परिभाषाओं के साथ शब्द। गणितज्ञ गणित का वर्णन इस प्रकार करते हैं: वे शब्दों की परिभाषाएँ लिखते हैं और उनके आधार पर नियम बनाते हैं। इस विनिर्देश का लाभ यह है कि कोड की 850 पंक्तियों की तुलना में छह नियमों को समझना और डीबग करना बहुत आसान है। मुझे कहना होगा कि इन नियमों को लिखना आसान नहीं था, इन्हें डीबग करने में काफी समय लगा। मैंने विशेष रूप से इस उद्देश्य के लिए कोड लिखा था जो मुझे बताता था कि किस नियम का उपयोग किया जा रहा था। क्योंकि मैंने कुछ उदाहरणों के साथ इन छह नियमों का परीक्षण किया, मुझे कोड की 850 पंक्तियों को डीबग नहीं करना पड़ा, और बग ढूंढना बहुत आसान था। जावा के पास इसके लिए बेहतरीन उपकरण हैं। यदि मैंने अभी कोड लिखा होता, तो मुझे अधिक समय लगता और फ़ॉर्मेटिंग खराब गुणवत्ता की होती।

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

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

लेकिन इस स्पेसिफिकेशन में ऐसे फीचर्स भी हैं जो इसे बाकी स्पेसिफिकेशन से अलग करते हैं। 95% अन्य विशिष्टताएँ बहुत छोटी और सरल हैं:

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

लगातार चलने वाले कार्यक्रमों के बारे में कुछ शब्द कहना उचित है। आमतौर पर वे समानांतर में काम करते हैं, जैसे ऑपरेटिंग सिस्टम या वितरित सिस्टम। बहुत कम लोग उन्हें अपने मन में या कागज़ पर समझ पाते हैं, और मैं उनमें से नहीं हूँ, हालाँकि मैं एक बार ऐसा करने में सक्षम था। इसलिए, हमें ऐसे टूल की आवश्यकता है जो हमारे काम की जाँच करें - उदाहरण के लिए, TLA+ या PlusCal।

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

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

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

स्पेसिफिकेशन और कोड को कैसे लिंक करें? गणितीय अवधारणाओं और उनके कार्यान्वयन को जोड़ने वाली टिप्पणियों का उपयोग करना। यदि आप ग्राफ़ के साथ काम करते हैं, तो प्रोग्राम स्तर पर आपके पास नोड्स की सारणी और लिंक की सारणी होगी। इसलिए आपको यह लिखना होगा कि इन प्रोग्रामिंग संरचनाओं द्वारा ग्राफ़ को वास्तव में कैसे कार्यान्वित किया जाता है।

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

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

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

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

आप एक विशेष वेबसाइट पर टीएलए+ और प्लसकैल के बारे में अधिक पढ़ सकते हैं, आप मेरे होम पेज से वहां जा सकते हैं по ссылке. मेरे लिए बस इतना ही, आपके ध्यान के लिए धन्यवाद।

कृपया याद रखें कि यह एक अनुवाद है. जब आप टिप्पणियाँ लिखें तो याद रखें कि लेखक उन्हें नहीं पढ़ेगा। यदि आप वास्तव में लेखक के साथ बातचीत करना चाहते हैं, तो वह हाइड्रा 2019 सम्मेलन में होंगे, जो 11-12 जुलाई, 2019 को सेंट पीटर्सबर्ग में आयोजित किया जाएगा। टिकट खरीदे जा सकते हैं आधिकारिक वेबसाइट पर.

स्रोत: www.habr.com