स्रोत कोड का दो-स्तरीय संगठन। अनिवार्य रूप से या व्यर्थ?

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

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

बेशक, विषय बहुत गंभीर है। कई पहलू और दिशाएं हैं जहां आप आगे बढ़ सकते हैं। इस मामले में, मैं केवल एक ही बात पर विचार करना चाहता हूं।

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

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

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

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

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

5. निम्नलिखित, अब पूरी तरह से अकल्पनीय डिजाइन, जैसे



या तालिका के रूप में फ़ंक्शन के मापदंडों का वर्णन, और पेड़ के रूप में वर्ग के तत्व।

6. स्रोत कोड में सीधे स्थानीयकरण। उदाहरण के लिए, हम एक ही स्ट्रिंग स्थिरांक पर कई मान सेट कर सकते हैं। संपादक में, यह कुछ इस तरह दिखेगा:

const संदेश = "नमस्ते दुनिया!";

को छोड़कर, इसके बगल में कुछ आइकन हो सकते हैं, जब आप उस पर क्लिक करते हैं तो आप किसी भी भाषा में पाठ को देख / सही कर सकते हैं।

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