स्प्रेडशीट "प्रोग्रामिंग" एक प्रकार का डेटाफ्लो प्रोग्रामिंग है।
हमें इसके साथ एक भाषाई समस्या है, हमें इसे "प्रोग्रामिंग" नहीं कहना चाहिए, क्योंकि यह प्रोग्रामिंग कहे जाने की तुलना में बहुत कम है, लेकिन यह प्रोग्राम में डेटा दर्ज करने से अधिक निश्चित है।
डेटाफ्लो प्रोग्रामिंग एक वास्तुकला और अनुशासन है, जहां एप्लिकेशन स्वतंत्र मॉड्यूल का एक नेटवर्क है, वे एक दूसरे को संदेश (डेटा) भेजते हैं। यह मॉडल हर समस्या के लिए लागू नहीं है, केवल उन लोगों के लिए, जहां एक स्रोत डेटा या स्ट्रीम है (या अधिक हैं), जो प्रसंस्करण नेटवर्क को जाता है, और आउटपुट डेटा / स्ट्रीम बनाता है। नीचे देखें लिस्ट
डेटाफ्लो प्रोग्रामिंग के कई प्रकार हैं, आइए देखते हैं कुछ:
- स्प्रेडशीट: इनपुट नंबरों को फ़ार्मुलों द्वारा संसाधित किया जाता है, फिर नंबरों और ग्राफ़ का परिणाम होता है। विशेष विशेषताएं: एक्सक्यूशन टाइम "वन-शॉट" है, जब इनपुट वैल्यू (घटक) बदलता है, तो प्रोसेसिंग ग्राफ का अप्रोच भाग पुन: चलता है और आउटपुट उत्पन्न करता है।
- यूनिक्स पाइप: खोल कई कार्यक्रमों को लॉन्च करता है, और स्टडआउट-> स्टडिन को जोड़ता है। विशेष विशेषताएं: केवल पाइप-स्टाइल लिंकिंग की अनुमति है, ग्राफ एक एकल कतार है।
- सिंक्रोनाइज़्ड एक्ज़ीक्यूशन: एक क्लॉक होती है, जो किसी फ्रिक्वेंसी में फ्रेम या सैंपल की प्रोसेसिंग को ट्रिगर करती है। हर घटक एक बार एक चक्र चक्र चलाता है। वीडियो और ऑडियो प्रोसेसिंग सिस्टम उदाहरण हैं, वे एक निर्दिष्ट फ्रेम / नमूना दर पर काम करते हैं।
- अतुल्यकालिक निष्पादन: ग्राफ तब तक निष्क्रिय रहता है, जब तक कोई बाहरी घटना नहीं होती है। फिर यह घटना को संसाधित करता है, कुछ आउटपुट (या नहीं) उत्पन्न करता है, और निष्क्रिय स्थिति में जाता है।
अपने प्रश्न पर वापस जाएं: मुझे लगता है कि हां, एक स्टैंडअलोन ऐप के रूप में डेटाफ्लो एप्लिकेशन को प्रकाशित करना अच्छा है। मैं पहले ही बना चुका हूं। दो बार ।
मुझे और मेरे एक दोस्त ने होम ऑटोमेशन के लिए एक प्रोटोटाइप डीएफ सिस्टम बनाया है। हमारे पास कोई ग्राफ़ संपादक नहीं है, इसलिए ऐप उपयोगकर्ता द्वारा संपादन योग्य नहीं है, कुछ मापदंडों को एक कॉन्फ़िगर फ़ाइल में संग्रहीत किया जाता है, लेकिन कुछ और नहीं। हमारे पास एक DF स्क्रिप्ट भाषा है, जो C ++ कोड (घटक निर्माण और संदेश परिभाषाओं की एक सूची) के लिए "संकलित" है, जो एक मूल निष्पादन योग्य के लिए संकलित हो जाती है। मॉड्यूल सी ++ कक्षाएं (अन्य वर्ग हैं, बस हमारे सिस्टम के बारे में कुछ जानकारी प्राप्त करने के लिए: संदेश, डिस्पैसर, कंपोनेंट (सार), पोर्ट (सार), कंज्यूमरपोर्ट, प्रोड्यूसरपोर्ट)।
इसके अलावा, हम एक DF प्रणाली प्रदान करने के फायदे से चकित थे : हमने 2 मिनट के भीतर सीरियल स्निफ़र ऐप बनाया है, या हमने एक साइट पर एक परीक्षण कार्यक्रम बनाया है , जो एक-एक करके लैंप को झपकाता है (कोई प्रलेखन नहीं थे) हार्डवेयर आईडी पर)। हमने केवल मनोरंजन के लिए मिडी और हर्षपेड घटक बनाए हैं, मैंने इसके साथ एक हल्का अंग भी बनाया है (देखें http://homeaut.com/under_construction )!
मैं स्प्रेडशीट के मामले में केवल एक ही कठिनाई देख सकता हूं: जैसा कि प्रत्येक संख्या और सूत्र (संभावित रूप से: प्रत्येक सेल) एक घटक है, आपका ग्राफ अंतिम नहीं है। जब आप अपने साधारण योग () ऐप में एक पंक्ति जोड़ते हैं, तो इसका मतलब है कि डेटाफ्लो ग्राफ बदल गया है। तो, आपको रन-टाइम में ग्राफ को "रीप्रोग्रामिंग" करना होगा, या हमें इसे "मेटाप्रोग्रामिंग" कहना चाहिए। एक्सेल में, एक मैक्रो काम करेगा, लेकिन फिर हमने डेटाफ्लो की शुद्धता को ढीला कर दिया।
मेरे पास एक बहुत-बुरा-बुरा-नहीं-सही समाधान है। मैंने एक स्प्रेडशीट बनाई है, PHP बैकएंड के साथ एक AJAX ऐप। ऊर्ध्वाधर अक्ष समय (दिन) है, लाइनें घटक हैं। घटक होते हैं, जैसे इनपुट (लाइन को उपयोगकर्ता द्वारा संपादित किया जा सकता है), ऊर्ध्वाधर औसत, क्षैतिज औसत / योग, और कुछ डोमेन-विशिष्ट सांख्यिकीय गणना। इसके साथ केवल एक समस्या है: यह "एक आयामी" है। जब तक मुझे सिर्फ योग और एवीजी चाहिए और जो भी हो, मैं नई लाइनें जोड़ सकता हूं, और घटक बना सकता हूं, जो सामान की गणना करता है। लेकिन एक मजबूत बाधा है: कॉलम हमेशा दिन होते हैं (मैंने सप्ताह और महीने को "दृश्य" बनाया है, जो दैनिक डेटा को योग / एवीजी के रूप में प्रदर्शित करता है, लेकिन यह अभी भी एक आयामी है)। मैं इसे नहीं दिखा सकता, यह सहयोगी है और इसे 7/24 चलाने के लिए PHP बैकएंड कार्य की आवश्यकता है, यह मेरे होस्ट प्रदाता द्वारा समर्थित नहीं है।
तो, मेरा मॉडल (जिसे सबसे अच्छा वर्णित किया जा सकता है: "दिन क्षैतिज रूप से") अन्य प्रकार की समस्याओं को संभालने में सक्षम नहीं है।
मेरे पास एक विचार है, इस समस्या को कैसे हल करें: टैब ।
जब आप एक्सेल में फंस जाते हैं, और दूसरी तालिका बनानी होती है, तो आप उसी टैब पर एक अलग क्षेत्र का उपयोग कर सकते हैं, या किसी अन्य टैब को खोल सकते हैं। इसके अलावा, टैब के बीच संदर्भ असहज है, मैं पहली विधि पसंद करता हूं। मुझे लगता है, टैब को एक ही स्क्रीन पर प्रदर्शित किया जाना चाहिए, जैसे गैर-अतिव्यापी विंडोज़।
प्रत्येक तालिका की अपनी बढ़ती हुई धुरी होनी चाहिए: ऊर्ध्वाधर, क्षैतिज या स्थिर। वर्टिकल ग्रोइंग टेबल में लाइन कंपोनेंट्स होते हैं (जैसे मेरा डे-आधारित स्प्रेडशीट), जहां सभी कॉलम में "समान" फॉर्मूला होता है, क्षैतिज घटकों में कॉलम कंपोनेंट होते हैं, फिक्स्ड-साइज टेबल किसी भी स्प्रेडशीट की तरह होते हैं।
इसलिए, जब उपयोगकर्ता एक नई लाइन / कॉलम जोड़ता है, तो नई लाइन / कॉलम में एक ही सूत्र होगा।
इसके अलावा, स्प्रैडशीट में, मुझे इस बात से नफरत है, कि मुझे 1000 बार, यदि मेरे पास 1000 रेखाएँ हैं, तो मुझे एक ही फॉर्मूला कॉपी करने की ज़रूरत है। यह बग्स का स्रोत है (कुछ लाइनों में पुराने संस्करण को सूत्र में रखते हुए), मेमोरी की बर्बादी (उसी फॉर्मूले को 1000x स्टोर करना)।
शायद मैं गलत हूं, और इस मॉडल में अवधारणा कीड़े हैं, लेकिन मुझे आशा है कि यह एक अच्छा विचार-उत्तेजक था।