दृश्य प्रोग्रामिंग - यह एक बुरा विचार क्यों है

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

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

1990 के दशक में, तथाकथित CASE टूल का उपयोग करके कॉर्पोरेट वातावरण में विज़ुअल प्रोग्रामिंग शुरू करने के लिए एक बहुत ही लोकप्रिय आंदोलन था, जहाँ प्रशिक्षित सॉफ्टवेयर डेवलपर्स को आकर्षित करने की आवश्यकता के बिना UML और उत्पन्न [उनके कोड] का उपयोग करके कॉर्पोरेट सिस्टम को परिभाषित किया जा सकता था। यह "राउंड ट्रिपिंग" अवधारणा के कारण है, जहां सिस्टम को नेत्रहीन रूप से मॉडल किया जा सकता है, परिणामी मॉडल से प्रोग्राम कोड उत्पन्न किया जाएगा, और किसी भी कोड परिवर्तन को वापस मॉडल पर लौटाया जा सकता है। काश, ऐसे उपकरण कभी भी अपने मिशन को पूरा करने में सक्षम नहीं होते, और अधिकांश प्रयोग [उनके कार्यान्वयन पर] वर्तमान में बड़े पैमाने पर छोड़ दिए गए हैं।



इस प्रकार, दृश्य प्रोग्रामिंग ने कुछ बहुत सीमित क्षेत्रों को छोड़कर लोकप्रियता हासिल नहीं की है। यह स्थिति काफी हद तक प्रोग्रामिंग के बारे में गलत धारणाओं के कारण है:

• पाठ प्रोग्रामिंग भाषाएं भ्रमित करती हैं कि अनिवार्य रूप से एक सरल प्रक्रिया क्या है।
• अमूर्त और विघटित ( डिकम्पलिंग, कनेक्टिविटी को कम करना ) प्रोग्रामिंग में एक छोटी परिधीय भूमिका निभाते हैं।
• प्रोग्रामिंग की सहायता के लिए डिज़ाइन किए गए उपकरण महत्वपूर्ण नहीं हैं।

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

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

अधिकांश दृश्य प्रोग्रामिंग भाषाओं का समाधान "ब्लॉक" को और अधिक जटिल बनाना है ताकि प्रत्येक दृश्य तत्व पाठ कोड के एक बड़े ब्लॉक के बराबर हो। वर्कफ़्लो के दृश्य उपकरण एक तत्काल ठोकर हैं।

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

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

दृश्य "कोड" और पाठ कोड ( वैचारिक और तकनीकी कठिनाइयों का एक सेट ) के बीच एक बाधा बेमेल है, और प्रोग्रामर को उन दोनों के बीच इंटरफ़ेस को नेविगेट करना पड़ता है, अक्सर मूल कार्य को हल करने की तुलना में ग्राफिकल प्रोग्रामिंग टूल को बेहतर बनाने पर अधिक प्रयास खर्च करते हैं [प्रोग्राम लिखने का]।



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

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

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



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

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

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

अद्यतन

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


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

लेखक के बारे में:
नोट्स, विचारों को ज़ोर से, सादे दृष्टि में सीखना, गलतफहमी, गलतियाँ, अनकही राय। मैं एक प्रचारक माइक हैडलो हूं। मैं इंग्लैंड के दक्षिणी तट पर ब्राइटन के पास रहता हूं।

---

अनुवाद EDISON सॉफ्टवेयर, एक पेशेवर सॉफ्टवेयर विकास और परीक्षण कंपनी द्वारा समर्थित था।