प्रोग्रामिंग कोडिङ भन्दा बढी छ

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

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

habrokat पछि, वास्तवमा, सेमिनार को अनुवाद सुरु हुन्छ। पढेर आनन्द लिनुहोस्!

तपाईले जुनसुकै कार्य लिनु हुन्छ, तपाईले सधैं तीन चरणहरू पार गर्न आवश्यक छ:

• तपाईं कुन लक्ष्य हासिल गर्न चाहनुहुन्छ निर्णय गर्नुहोस्;
• तपाईं आफ्नो लक्ष्य कसरी प्राप्त गर्ने निर्णय गर्नुहोस्;
• आफ्नो लक्ष्यमा आउनुहोस्।

यो प्रोग्रामिङमा पनि लागू हुन्छ। जब हामी कोड लेख्छौं, हामीलाई आवश्यक छ:

• कार्यक्रम के गर्ने निर्णय गर्नुहोस्;
• यो आफ्नो कार्य कसरी प्रदर्शन गर्नुपर्छ निर्धारण;
• सम्बन्धित कोड लेख्नुहोस्।

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

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

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

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

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

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

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

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

तर गणितका कार्यहरू प्रोग्रामिङ भाषाहरूमा भएका कार्यहरू जस्तै छैनन्। गणित धेरै सजिलो छ। मसँग जटिल उदाहरणहरूको लागि समय नभएकोले, एउटा साधारणलाई विचार गरौं: C मा एउटा प्रकार्य वा Java मा स्थिर विधि जसले दुई पूर्णांकहरूको सबैभन्दा ठूलो साझा भाजक फर्काउँछ। यस विधिको विनिर्देशमा, हामी लेख्नेछौं: गणना गर्दछ GCD(M,N) तर्कहरूको लागि M и Nकहाँ GCD(M,N) - एक प्रकार्य जसको डोमेन पूर्णांकको जोडीको सेट हो, र फिर्ताको मान सबैभन्दा ठूलो पूर्णांक हो जुन द्वारा विभाजित हुन्छ। M и N। यो मोडेल वास्तविकतासँग कसरी सम्बन्धित छ? मोडेल पूर्णांकहरूमा सञ्चालन हुन्छ, जबकि C वा Java मा हामीसँग 32-bit छ 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? शून्य सबै संख्याहरु द्वारा विभाजित छ, त्यसैले यस मामला मा कुनै ठूलो भाजक छैन। यस अवस्थामा, हामीले पहिलो चरणमा फर्किनु पर्छ र सोध्नु पर्छ: के हामीले वास्तवमा गैर-सकारात्मक संख्याहरूको लागि GCD गणना गर्न आवश्यक छ? यदि यो आवश्यक छैन भने, तपाइँ केवल विनिर्देश परिवर्तन गर्न आवश्यक छ।

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

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

हामीले पहिलो, सम्भावित प्रारम्भिक अवस्थाहरूको सेट निर्धारित गरेर सुरक्षा प्राप्त गर्छौं। र दोस्रो, प्रत्येक राज्यको लागि सबै सम्भावित अर्को राज्यहरूसँग सम्बन्ध। वैज्ञानिकहरू जस्तै काम गरौं र राज्यहरूलाई गणितीय रूपमा परिभाषित गरौं। प्रारम्भिक अवस्थाहरूको सेटलाई सूत्रद्वारा वर्णन गरिएको छ, उदाहरणका लागि, युक्लिड एल्गोरिथ्मको अवस्थामा: (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+। युक्लिड एल्गोरिथ्मको विनिर्देश यस भाषामा यस्तो देखिन्छ:

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

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

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

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

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

तर माथिको उदाहरणमा, प्रयोगकर्ताले सम्भवतः संयोजन र समान चिन्हहरू पङ्क्तिबद्ध गर्न चाहन्थे। त्यसैले सही ढाँचा यो जस्तै देखिन्छ:

अर्को उदाहरण विचार गर्नुहोस्:

यहाँ, यसको विपरित, स्रोतमा बराबर, थप, र गुणन चिन्हहरूको पङ्क्तिबद्धता अनियमित थियो, त्यसैले सरल प्रक्रिया पर्याप्त छ। सामान्यतया, सही ढाँचाको कुनै सटीक गणितीय परिभाषा छैन, किनभने यस अवस्थामा "सही" को अर्थ "प्रयोगकर्ताले के चाहन्छ" भन्ने हो, र यो गणितीय रूपमा निर्धारण गर्न सकिँदैन।

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

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

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

तर यो स्पेसिफिकेशनमा अन्य स्पेसिफिकेशनहरू भन्दा फरक पार्ने सुविधाहरू पनि छन्। अन्य चश्माहरूको 95% उल्लेखनीय रूपमा छोटो र सरल छन्:

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

यो निरन्तर चल्ने कार्यक्रमहरूको बारेमा केही शब्दहरू भन्न लायक छ। नियमको रूपमा, तिनीहरू समानान्तरमा काम गर्छन्, उदाहरणका लागि, अपरेटिङ सिस्टम वा वितरण प्रणालीहरू। धेरै कम मानिसहरूले तिनीहरूलाई मानसिक रूपमा वा कागजमा बुझ्न सक्छन्, र म तिनीहरूमध्ये एक होइन, यद्यपि मैले एक पटक यो गर्न सक्षम थिएँ। त्यसकारण, हामीलाई हाम्रो काम जाँच गर्ने उपकरणहरू चाहिन्छ - उदाहरणका लागि, TLA + वा PlusCal।

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

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

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

विनिर्देश र कोड कसरी लिङ्क गर्ने? गणितीय अवधारणाहरू र तिनीहरूको कार्यान्वयनलाई लिङ्क गर्ने टिप्पणीहरूको मद्दतले। यदि तपाइँ ग्राफहरूसँग काम गर्नुहुन्छ भने, कार्यक्रम स्तरमा तपाइँसँग नोडहरू र लिङ्कहरूको एरेहरू हुनेछन्। त्यसकारण, तपाइँले यी प्रोग्रामिङ संरचनाहरूद्वारा ग्राफ कसरी लागू गरिएको छ भनेर लेख्न आवश्यक छ।

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

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

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

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

तपाइँ TLA + र PlusCal को बारेमा विशेष वेबसाइटमा थप पढ्न सक्नुहुन्छ, तपाइँ त्यहाँ मेरो गृह पृष्ठबाट जान सक्नुहुन्छ लिङ्क। यो सबै मेरो लागि हो, तपाईंको ध्यानको लागि धन्यवाद।

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

स्रोत: www.habr.com