दृश्य प्रोग्रामिंग भाषाओं

Question

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

डेवलपर्स के लिए मुख्यधारा, सामान्य-उद्देश्य वाली दृश्य भाषाएँ क्यों नहीं हैं? विजुअल प्रोग्रामिंग के फायदे और नुकसान क्या हैं?

Comments

आप सही हैं: लोग नेत्रहीन सोचते हैं । लेकिन जटिल कोड की छवियों को एक नज़र में समझ पाना असंभव है, तो फायदा कहाँ है? एक अच्छे प्रोग्रामर के पास अपने सिर में कोड का एक दृश्य मॉडल होता है, चाहे वह स्क्रीन पर कोई भी हो। विज़ुअल लैंग्वेज हैं, imho, ऐसे लोगों के लिए जिन्होंने अभी तक प्रोग्राम के टेक्स्ट के प्रतिनिधित्व से सार नहीं सीखा है। जिसके अनुसार, मेरा मानना है कि शाब्दिक कोड है कि है ताकि इसे आँखों से navigatable बनाने के लिए, देखो अच्छा है, जैसे संरचनाओं और स्पष्ट करने के लिए।

— राफेल

@ राफेल, ठीक है, यह कल्पना करो, क्या होगा अगर मैं आपसे इसकी ब्लू-प्रिंट के बजाय गगनचुंबी इमारत का एक पाठीय विवरण पूछता हूं?

— मोहम्मद अल-तुर्कस्टनी

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

— डेव क्लार्क

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

— राफेल

@ मोहम्मदअल-तुर्कस्टनी मुझे लगता है कि यह बहुत व्यापक है। आपके अंतिम पैराग्राफ में 4 प्रश्न हैं। ये कुछ ज्यादा हो गया।

— औली

Answer 1

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

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

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

जब उपयोगकर्ता ब्लॉक भाषा में अधिक जटिल प्रोग्राम बनाना शुरू करते हैं, तो वे पाते हैं कि टाइपिंग से ब्लॉक को खींचना और छोड़ना धीमा है। क्या आप इसके बजाय "a * x ^ 2 + b * x + c" टाइप करेंगे या इसे ब्लॉक बना सकते हैं?

न्याय इस विषय को (कम से कम मेरे द्वारा) कुछ पैराग्राफ में नहीं दिया जा सकता है, लेकिन कुछ मुख्य कारण हैं:

1. ब्लॉक भाषाएं शुरुआती लोगों के लिए डिज़ाइन की जाती हैं, इसलिए वे डिज़ाइन द्वारा शक्तिशाली नहीं हैं।
2. कुछ जटिल अवधारणाओं को व्यक्त करने का कोई अच्छा दृश्य तरीका नहीं है, जैसे कि टाइप सिस्टम, जो आपको सामान्य-प्रयोजन प्रोग्रामिंग भाषाओं में मिलते हैं।
3. ब्लॉक का उपयोग करना जटिल कार्यक्रमों के लिए अपरिहार्य है।

Comments

क्या आप कह सकते हैं कि दृश्य उपहार उपयोगकर्ता की प्रगति के साथ पैमाने पर नहीं हैं?

— राफेल

अच्छा जवाब। मुझे डिजाइन ट्रेड-ऑफ्स का उल्लेख पसंद है।

— जॉन पर्किवल हैकवर्थ

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

— एपीग्रामग्राम

@ ऐपग्राम: दिलचस्प। लगता है जैसे "नेत्रहीन सीखो, अमूर्तता में महारत हासिल करो"।

— राफेल

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

— गुइलिफ़िक्स एफ़एक्स

Answer 2

डेवलपर्स के लिए मुख्यधारा, सामान्य-उद्देश्य वाली दृश्य भाषाएँ क्यों नहीं हैं? विजुअल प्रोग्रामिंग के फायदे और नुकसान क्या हैं?

दृश्य भाषाओं ने इसे तीन व्यापक श्रेणियों में विभाजित किया:

1. गैर-ऑटोमेशन कार्य करने के लिए उपकरण गैर-प्रोग्रामर। मैक पर ऑटोमेटर सोचो।
2. ऐसे वातावरण सीखना जहाँ बहुत अधिक टाइपिंग करना व्यावहारिक नहीं है, या जहाँ तार्किक प्रवाह दिखाने वाले कार्यक्रम की संरचना महत्वपूर्ण है। स्क्रैच, ऐलिस आदि के बारे में सोचें।
3. संबोधित की जा रही समस्या एक डेटा-फ्लो समस्या है, और समस्या का समाधान अच्छी तरह से स्वयं-निहित बक्से के बीच डेटा प्रवाह द्वारा मॉडल किया गया है जो भौतिक दुनिया की नकल करता है। LabView और Ableton दोनों के दिमाग में आते हैं।

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

जबकि दृश्य प्रोग्रामिंग में कुछ भी गलत नहीं है, यह ऐसा हो सकता है कि यह अधिकांश कार्यों के लिए बस एक अच्छा तरीका नहीं है।

Comments

बस सोचा था कि मैं आपको बता दूंगा कि दूसरे उत्तर के लेखक को लगता है कि आप एक अच्छे व्यक्ति हैं। :-)

— एलेन स्पार्टस

जब एबलटन की चर्चा करते हैं, तो क्या आपका मतलब मैक्स / एमएसपी से है? दो अलग-अलग संगठनों और मैक्स / एमएसपी द्वारा विकसित की गई अलग-अलग परियोजनाएं हैं और साथ ही साथ यह ओपन-सोर्स सिबलिंग प्योरडाटा अधिक जटिल और अभिव्यंजक हैं, जो आपकी बात से 3 आईएमओ के लिए उन्हें श्रेय देता है।

— सॉल

Answer 3

कई दृश्य प्रोग्रामिंग भाषाएं रही हैं, जैसा कि निम्नलिखित दो ग्रंथ सूची दिखाएगी: vlib.org और oregonstate.edu ।

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

सामान्य प्रयोजन प्रोग्रामिंग को देखने के बजाय, दृश्य प्रोग्रामिंग विशेष डोमेन में कॉन्फ़िगरेशन टूल के रूप में सफल होने की संभावना है।

Answer 4

पाठ है दृश्य।

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

गणित पाठ्य है। सभी प्रकार के अंकन हैं, लेकिन अंत में यह मूल रूप से पाठ के लिए नीचे आता है। वे सैकड़ों वर्षों से कर रहे हैं।

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

Comments

अच्छा अवलोकन, लेकिन आपका आखिरी उप-विषय एक साहसिक दावा है। आपको क्यों लगता है कि व्हॉट्सएप और विभिन्न प्रतीकों (और शायद रंगों) की तुलना में अधिक विस्तृत दृश्य तत्व मदद नहीं कर सकते हैं?

— राफेल

@ राफेल, मैं यह नहीं कह रहा हूं कि हम अधिक विस्तृत दृश्य तत्वों का उपयोग नहीं कर सकते, इसीलिए मैंने कहा "हम शायद इसका बेहतर उपयोग कर सकते हैं।" मैं कह रहा हूँ कि यह पाठ को फेंकने से नहीं होगा। सभी "दृश्य" प्रोग्रामिंग भाषाओं को मैंने इस धारणा के साथ शुरू किया है कि पाठ खराब है और इसे खत्म करने की कोशिश करता है और वहां वे पूरी तरह से गलत हैं।

— विंस्टन एवर्ट

Answer 5

[इस उत्तर के पीडीएफ संस्करण के लिए , आंकड़े या चित्र इंटरैक्टिव और गतिशील हैं।]

नेट एलीमेंट्स एंड एनोटेशन्स: ए-पर्पस विजुअल प्रोग्रामिंग लैंग्वेज

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

["उत्तर पेट्री नेट" में एनोटेशन के प्रकार इस उत्तर के पीडीएफ संस्करण में पाए जाते हैं।]

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

लाभ और चुनौतियाँ

एक दृश्य प्रोग्रामिंग भाषा कंप्यूटर प्रोग्रामर को कंप्यूटर प्रोग्राम विकसित करने में मदद कर सकती है (Menzies, 2002)।

मेरे पास कम से कम तीन कारण हैं कि मुझे शुद्ध तत्व और एनोटेशन उपयोगी क्यों लगते हैं (फायदे?)।

Firs कारण। प्रक्रिया तर्क को एक बार में एक तत्व बनाया जा सकता है। इसका मतलब है कि मौजूदा नेट (पेट्री, 1966) में तत्वों को जोड़कर एक नेट को बढ़ाया जा सकता है। उदाहरण के लिए, एक नियंत्रक के एक मॉडल को आंतरिक और बाहरी घटकों में विभाजित किया जा सकता है। आंतरिक घटक प्रणाली को नियंत्रित करता है। बाहरी घटक पर्यावरण से इनपुट स्वीकार करके पर्यावरण के साथ हस्तक्षेप करता है। चित्रा 1 आंतरिक घटक का पेट्री नेट मॉडल है। उचित घटक और संक्रमण (चित्रा 2) जोड़कर आंतरिक घटक के पेट्री नेट मॉडल के लिए बाहरी घटक के पेट्री नेट मॉडल को जोड़ना संभव है।

चित्रा 1 एक नियंत्रक के आंतरिक घटक का एक पेट्री नेट मॉडल (हालोवे, क्रोग और जियुआ, 1997)

चित्र 2 एक नियंत्रक के आंतरिक और बाह्य अवयवों का पेट्री नेट मॉडल (हालॉवे, क्रॉघ और गिउआ, 1997)

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

तीसरा कारण। नेट में कुछ ग्राफिक्स ऑब्जेक्ट्स पर ध्यान केंद्रित करना और संबंधित ग्राफिक्स ऑब्जेक्ट्स के लिए कोड या लॉजिक एनोटेशन लिखना संभव है। चित्र 3 में एक कार्ड गेम के पेट्री नेट मॉडल पर विचार करें। यदि इनपुट P7 4 T4 के लिए तीर किसी स्थान / संक्रमण नेट में इनपुट के लिए एक मानक ग्राफिक्स है और यदि m_7 उस स्थान P7 के लिए निशान है, तो तर्क की घोषणा के लिए इनपुट स्थान के चिह्न को अद्यतन करना m_7 = m_7-1 है। यदि s_9 ^ - इनपुट की स्थिति है तो इनपुट की स्थिति को अपडेट करने के लिए तर्क एनोटेशन s_9 ^ - = ((m_7 <1)? False: true) है।

चित्र 3 एक कार्ड गेम का पेट्री नेट मॉडल

मेरे पास कम से कम तीन कारण हैं कि मैं पेट्री नेट के आवेदन को चुनौतीपूर्ण (नुकसान) क्यों मानता हूं?

यदि बहुत अधिक ग्राफिक्स ऑब्जेक्ट हैं तो नेट बनाना या पढ़ना मुश्किल होगा। ग्राफिक्स का एक सबसेट लेने से कठिनाई को कम किया जा सकता है और एक, दो या तीन ग्राफिक्स प्रतीक (नो, 1973; पेट्री, 1966) का उपयोग करके उनका प्रतिनिधित्व करते हैं। उदाहरण के लिए, अगर चित्र 3 में एक कार्ड गेम के पेट्री नेट मॉडल को आरेख में बहुत अधिक ग्राफिक ऑब्जेक्ट माना जाता है, तो कुछ ग्राफिक्स को संयोजित करना और फिर भी आरेख को कंप्यूटर प्रोग्राम में मैप करने के लिए पर्याप्त जानकारी बनाए रखना संभव है। चित्र 4 पर विचार करें, एक ही खेल का पेट्री नेट मॉडल चित्र 3 में उच्च-स्तरीय ग्राफिक्स (Chionglo, 2016a) के साथ पाया जाता है।

चित्र 4 हाई-लेवल ग्राफिक्स (चिएनलो, 2016 ए) का उपयोग करते हुए एक कार्ड गेम का पेट्री नेट मॉडल

एक अन्य उदाहरण में, चित्र 2 में नियंत्रक के बाहरी घटकों को एक अधिक संक्षिप्त ग्राफिक प्रतिनिधित्व बनाने के लिए जोड़ा जा सकता है जैसा कि चित्र 5 में दिखाया गया है।

चित्रा 5 बाहरी घटकों के लिए उच्च-स्तरीय ग्राफिक्स के साथ एक नियंत्रक का पेट्री नेट मॉडल

अंत में, स्थानों का एक पारस्परिक रूप से अनन्य सेट या संक्रमणों का एक परस्पर अनन्य सेट भी एक उच्च-स्तरीय ग्राफिक्स ऑब्जेक्ट (चियनग्लो, 2015) का उपयोग करके प्रतिनिधित्व किया जा सकता है।

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

तीसरा कारण। एक क्रमबद्ध तरीके से शुद्ध तत्वों के एनोटेशन बनाना आसान है क्योंकि हर एनोटेशन प्रत्यक्ष या अप्रत्यक्ष रूप से एक शुद्ध तत्व से संबंधित है। हालाँकि हर नेट तत्व के ग्राफिक्स के साथ हर एनोटेशन को प्रदर्शित करना एक अच्छा विचार नहीं हो सकता है क्योंकि आरेख में बहुत अधिक जानकारी प्रस्तुत की जा सकती है। उदाहरण के लिए, एक तर्क सर्किट के पेट्री नेट मॉडल के आरेख पर विचार करें जिसमें सभी संपत्ति और तर्क एनोटेशन (चित्र 6) के संदर्भ शामिल हैं। [मूल मॉडल में प्रत्येक आउटपुट की स्थिति के लिए एक परीक्षण की स्थिति शामिल थी (पृष्ठ Pet (के पृष्ठ 31 पर आंकड़ा ३१ (पेट्री, १ ९ ६६)); परीक्षण की स्थिति यहां छोड़ दी गई थी क्योंकि यह दिए गए प्रारंभिक अंकन के लिए मूल मॉडल के बराबर है। इस प्रकार हर आउटपुट में आउटपुट स्थान के निशान की गणना के लिए एक तर्क एनोटेशन होता है।]

चित्र 6 एनोटेशन के साथ एक स्थान / संक्रमण नेट - पेट्री के शोध प्रबंध के अंग्रेजी अनुवाद के 31 पृष्ठ 78 के आधार पर (1966)

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

चित्र 7 ए प्लेस / ट्रांज़िशन नेट - पेट्री के शोध प्रबंध के अंग्रेजी अनुवाद के 31 पृष्ठ 78 के आधार पर (1966)

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

संदर्भ

Chionglo, JF (2016a)। स्टैक ओवरफ्लो में "एक प्रतिक्रिया / रिड्यूक्स फ्लैशकार्ड गेम के लिए एक राज्य प्रवाह कैसे डिज़ाइन करें" का उत्तर दें। Https://www.academia.edu/34059934/A_Reply_to_How_to_design_a_state_flow_for_a_react_redux_flashcard_game_Stack_Overflow पर उपलब्ध है ।

Chionglo, JF (2016b)। पेट्री नेट के दो रूप। Http://www.aespen.ca/AEnswers/CAPDissF31P78-form.pdf पर उपलब्ध है ।

चियनग्लो, जेएफ (2015)। उच्च-स्तरीय ग्राफिक्स का उपयोग करके पेट्री नेट आरेख में शुद्ध तत्व ग्राफिक्स की संख्या को कम करना। Http://www.aespen.ca/AEnswers/WjTpY1429533268 पर उपलब्ध है ।

Chionglo, JF (2014)। कंप्यूटर प्रोग्रामिंग के लिए शुद्ध तत्व और एनोटेशन: पीडीएफ में कम्प्यूटेशन और इंटरैक्शन। पर उपलब्ध है https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF ।

हल्लोवे, ले; क्रोग, बीएच और गिउआ, ए (1997)। नियंत्रित असतत इवेंट सिस्टम [इलेक्ट्रॉनिक संस्करण] के लिए पेट्री नेट विधियों का एक सर्वेक्षण। असतत घटना गतिशील सिस्टम: सिद्धांत और अनुप्रयोग, वॉल्यूम। 7. बोस्टन: क्लूवर एकेडमिक पब्लिशर्स, पीपी। 151 - 190।

मेन्ज़ीस, टी। (2002)। दृश्य प्रोग्रामिंग भाषाओं के लिए मूल्यांकन मुद्दे। एसके चांग (एड) में। सॉफ्टवेयर इंजीनियरिंग और नॉलेज इंजीनियरिंग की हैंडबुक, वॉल्यूम। 2 उभरती हुई प्रौद्योगिकियां। विश्व वैज्ञानिक प्रकाशन सह। Pte। लिमिटेड, पीपी। 93 - 101।

नोए, जेडी और नट, जीजे (1973)। "समानांतर सिस्टम के प्रतिनिधित्व के लिए मैक्रो ई-नेट", कंप्यूटर पर IEEE लेनदेन, वॉल्यूम। सी -22, नंबर 8, अगस्त 1973, पीपी। 718 - 727।

पेट्री, सीए (1973)। नेट थ्योरी की अवधारणा। कंप्यूटर विज्ञान की गणितीय नींव में: प्रोक। संगोष्ठी और समर स्कूल, उच्च टाट्रा, 3 सितम्बर - 8, 1973, पृष्ठ 137 - 146। गणित। Inst। स्लोवाक Acad की। विज्ञान की, 1973।

पेट्री, सीए (1966)। ऑटोमोटा के साथ संचार [ट्रांस। सीएफ ग्रीन, जूनियर]। तकनीकी रिपोर्ट RADC-TR-65-377 (वॉल्यूम I) की अनुपूरक I। ग्रिफिस एयर फोर्स बेस, एनवाई: रोम एयर डेवलपमेंट सेंटर, रिसर्च एंड टेक्नोलॉजी डिवीजन, एयर फोर्स सिस्टम कमांड, ग्रिफिस एयर फोर्स बेस। Http://www.informatik.uni-hamburg.de/TGI/mitarbeiter/profs/petri/doc/Petri-diss-engl.pdf से 31 अगस्त 2011 को लिया गया ।

Answer 6

जॉने पर्किवल हैकवर्थ :

जबकि दृश्य प्रोग्रामिंग में कुछ भी गलत नहीं है, यह ऐसा हो सकता है कि यह अधिकांश कार्यों के लिए बस एक अच्छा तरीका नहीं है।

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

Answer 7

आप प्रोग्रामिंग विदाउट कोडिंग टेक्नोलॉजी (PWCT) देख सकते हैं

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

यहां शुरू करने के लिए एक अच्छी जगह है और खुला स्रोत है ।

Comments

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

— वाइल्डकार्ड

Answer 8

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

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

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

यह मुझे प्रतीत होता है कि दृश्य प्रोग्रामिंग का उपयोग चुनिंदा क्षेत्रों में बढ़ रहा है और अब से यह अधिक सामान्य हो सकता है।

यह मत भूलो कि दृश्य प्रोग्रामिंग दशकों के लिए ईई चिप डिजाइन के लिए अंतर्निहित है जहां यह एक अमूर्त नहीं है और (उप) सिस्टम 2 डी डिजाइनों में बिल्कुल उसी तरह से निर्धारित किए गए हैं।

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

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

एक अन्य प्रमुख / उभरता हुआ क्षेत्र जहां यह कई उपकरणों में व्यापक उपयोग में है, बीपीएम, व्यवसाय प्रक्रिया मॉडलिंग है।

• 1970 के दशक से एक रहस्यमय तरीके से कोडिंग विधि बैंकिंग सॉफ्टवेयर हर जगह (फास्ट कंपनी) वेब डेवलपर्स की पवित्रता को बचा सकता है।

• BPM, व्यवसाय प्रक्रिया मॉडलिंग विकिपीडिया

Answer 9

मैं इस कारण का अनुमान लगाता हूं कि ये समाधान इतने लोकप्रिय क्यों नहीं हैं, क्योंकि ज्यादातर मामलों में वे अप्रबंधनीय हो सकते हैं और गड़बड़ हो सकते हैं।

आज उपलब्ध लगभग सभी दृश्य प्रोग्रामिंग उपकरण बड़े अनुप्रयोगों का हिस्सा हैं और एक विशिष्ट उद्देश्य के लिए उपयोग किया जाता है (उदाहरण: UE4 में ब्लूप्रिंट)।

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

Comments

क्या आपके पास अपने दावे का समर्थन करने के लिए कोई उद्धरण है जो कि ज्यादातर मामलों में दृश्य लंगड़ा गन्दा और असहनीय हो जाता है?

— डेविड रिचरबी

वास्तव में हाँ, मैं उदाहरण के लिए, स्पेगेटी ग्राफ, यहां तक ​​कि मेरे द्वारा बताए गए सॉफ़्टवेयर के साथ, डेवलपर ने उसे / उसके स्वयं को वह समस्या बताई थी (मैं उस ऐप के विकास का बारीकी से पालन कर रहा हूं), मेरी बात का बैकअप लेने के लिए, इसे देखें लिंक ।

— नेटइन्फो

Answer 10

मुझे लगता है कि @ राफेल और अन्य गलत हैं जब वे कहते हैं कि एक कार्यक्रम पाठ है। यह नहीं है। यह बहुत सी बातें हैं। यह कंप्यूटर को बता रहा है कि क्या करना है, या कैसे करना है। (अपरिमेय, घोषणात्मक प्रोग्रामिंग) पाठ संपादन के साथ प्रोग्रामिंग का संघ ऐतिहासिक और प्रतिगामी हठधर्मिता है। जिसे शुरुआती कंप्यूटरों के सीमित पाठ इनपुट / आउटपुट द्वारा बनाया गया था। लोग पाठ पार्सर नहीं हैं!

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

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

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

Comments

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

— डेविड रिचरबी

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

— mzso

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

— मेज़ो

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

— डेविड रिचेर्बी

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

— mzso