अमूर्तता का अगला स्तर क्या है? [बन्द है]


15

चूंकि प्रोग्रामिंग भाषाओं ने शुरू में केवल अनुक्रमिक रूप से निष्पादित कोड की लाइनों का उपयोग किया था, और यह उन कार्यों में शामिल था जो अमूर्त के पहले स्तरों में से एक थे, और फिर वर्गों और वस्तुओं को इसे और भी अधिक सार करने के लिए बनाया गया था; अमूर्तता का अगला स्तर क्या है?

कक्षाओं से भी अधिक सार क्या है या अभी तक कोई है?


17
आपको लगता है कि यह एक रैखिक प्रगति है, एक आदेश के साथ ("X, Z की तुलना में Y अधिक सार है")। क्षमा करें मैं असहमत हूं।

2
यह कहना बहुत अच्छा होगा कि आप अलग क्यों भीख माँगते हैं। ;) (पढ़ें: मुझे दिलचस्पी है!)
20

3
मैं परम "अमूर्त" का प्रस्ताव करता हूं: मैं जो सोचता हूं, वह करो जो मैं टाइप नहीं करता हूं। ;)
इज़काता

1
@ डेलन: एब्स्ट्रेक्शन कुल ऑर्डर नहीं देता है, लेकिन "अधिक सार", "कम अमूर्त" कहना संभव है। उदाहरण के लिए, मर्ज सॉर्ट का एक सामान्य कार्यान्वयन मर्ज सॉर्स के कार्यान्वयन की तुलना में अधिक सार है जो केवल पूर्णांकों के लिए काम करता है।
जियोर्जियो

2
Bros, आप कुछ श्रेणी सिद्धांत सीखते हैं। फिर हम चर्चा कर सकते हैं कि वास्तव में सभ्य पुरुषों की तरह क्या अमूर्तता है।
davidk01

जवाबों:


32

मुझे लगता है कि आपको कंप्यूटिंग के इतिहास के बारे में कुछ गलत धारणाएं हैं।

पहला अमूर्त (1936 में), वास्तव में, अलोंजो चर्च का लैंबडा कैलकुलस था, जो उच्च-क्रम के कार्यों और उसके बाद आने वाली सभी कार्यात्मक भाषाओं की अवधारणा की नींव है। इसने सीधे लिस्प (1959 में बनाई गई दूसरी सबसे पुरानी उच्च स्तरीय प्रोग्रामिंग भाषा) को प्रेरित किया, जिसने बदले में एमएल से हास्केल और क्लोजर तक सब कुछ प्रेरित किया।

दूसरा अमूर्त प्रक्रियात्मक प्रोग्रामिंग था। यह वॉन न्यूमैन कंप्यूटर आर्किटेक्चर से बाहर आया जहां अनुक्रमिक कार्यक्रम लिखे गए थे, एक समय में एक निर्देश। फोरट्रान (सबसे पुरानी उच्च-स्तरीय प्रोग्रामिंग भाषा, 1958) प्रक्रियात्मक प्रतिमान से बाहर आने वाली पहली उच्च-स्तरीय भाषा थी।

तीसरी अमूर्तता वास्तव में घोषणात्मक प्रोग्रामिंग थी, पहले एब्स (1967) द्वारा अनुकरणीय, और फिर बाद में प्रोलॉग (1972)। यह तर्क प्रोग्रामिंग की नींव है, जहां अभिव्यक्तियों का मूल्यांकन निर्देशों की एक श्रृंखला को निष्पादित करने के बजाय, घोषणाओं या नियमों की एक श्रृंखला से किया जाता है।

चौथी मतिहीनता तब ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग थी, जिसने 60 के दशक में लिस्प कार्यक्रमों में अपनी पहली उपस्थिति दर्ज की, लेकिन बाद में 1972 में स्मॉलटाक द्वारा इसकी मिसाल दी गई। (हालांकि इस बात पर कुछ बहस भी हुई है कि क्या स्मॉलटाक का मैसेज-पासिंग स्टाइल है वन ट्रू ऑब्जेक्ट-ओरिएंटेड एब्सट्रैक्ट। मैं इसे छूने वाला नहीं हूं।)

अन्य सभी सार, विशेष रूप से पारंपरिक वॉन न्यूमैन कंप्यूटर वास्तुकला पर, उन चार विषयों पर भिन्नताएं हैं। मुझे यकीन नहीं है कि उन चार से परे एक और अमूर्तता है जो केवल एक बदलाव या उनमें से एक संयोजन नहीं है।

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

हालांकि, क्वांटम कंप्यूटिंग मॉडल है। क्वांटम कंप्यूटिंग में, क्वांटम एल्गोरिदम को मॉडल करने के लिए नए अमूर्त आवश्यक हैं। इस क्षेत्र में एक नवगीत होने के नाते, मैं इस पर टिप्पणी नहीं कर सकता।


4
क्या पहलू उन्मुख प्रोग्रामिंग को अमूर्त का एक और रूप माना जा सकता है?
शिवन ड्रैगन

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग 60 के दशक में लिस्प से बाहर आई थी? [उद्धरण वांछित], बड़ा समय। मैंने जो कुछ भी सुना है वह कहता है कि यह 60 के दशक में सिमुला से निकला था, जो ALGOL का प्रत्यक्ष वंशज था, एक अनिवार्य भाषा जिसका लिस्प के साथ कोई लेना-देना नहीं था। स्मॉलटाक सिमुला द्वारा शुरू की गई अवधारणाओं को लेकर आया और उन्हें अधिक "लिस्पी" महसूस करने के लिए घुमाया।
मैसन व्हीलर 19

3
@MasonWheeler: यह लिस्प 1 और 1.5 मैनुअल में है, और लिस्पर्स को ऑब्जेक्ट-ओरिएंटेड प्रोग्राम, विशेष रूप से पुराने लोगों से बात करने के लिए सुनना आम है। एआई लोग उस समय लिस्प में ऑब्जेक्ट सिस्टम करने पर बड़े थे।
ग्रेफेड 19

2
@ शिवनड्रगन: मैं कहूंगा कि नहीं। यह अतिरिक्त दोहन के साथ एक अन्यथा प्रक्रियात्मक कार्यक्रम को साधने का एक तरीका है। यह वास्तव में मॉडल एल्गोरिदम नहीं है, और न ही यह डेटा संरचनाओं के डिजाइन को प्रभावित करता है।
ग्रेफेड

4
दरअसल, SKI कॉम्बीनेटर कैलकुलस लैम्बडा कैलकुलस और ट्यूरिंग मशीन दोनों से मिलता है।
जॉर्ग डब्ल्यू मित्तग

4

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

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

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

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


1
"बतख टाइपिंग" (कम से कम जैसा कि आप वर्णन करते हैं) वास्तव में उपन्यास नहीं है या गतिशील रूप से टाइप की गई भाषाओं तक सीमित नहीं है; यह "संरचनात्मक उप-टाइपिंग" के रूप में सांख्यिकीय रूप से टाइप की गई भाषाओं में लंबे समय तक रहा है , जो ओकेमेल में सबसे अच्छा देखा गया है।
तिखन जेल्विस

2

एसक्यूएल जैसी डोमेन विशिष्ट भाषाओं को अमूर्तता के उच्च क्रम के रूप में माना जा सकता है। एसक्यूएल एक बहुत ही लक्षित भाषा है जो स्टोरेज जैसे ऑपरेशनों को दूर करती है और सेट सिद्धांत के आधार पर उच्च स्तर के कार्य प्रदान करती है। यह भी विचार करें कि आज कितनी मुख्यधारा की भाषाएँ एक विशिष्ट वास्तुकला को लक्षित नहीं करती हैं, बल्कि एक वर्चुअल मशीन (जैसे कि जेवीएम या .NET सीएलआर)। एक उदाहरण के लिए C # को IL में संकलित किया जाता है, जो कि मूल रनटाइम इंजन द्वारा व्याख्या की जाती है (या अधिक बार JIT'd --Just In Time Compiled-- एक मूल कार्यान्वयन के लिए)।

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

आज कुछ अस्तित्व में हैं जैसे कि JetBrains MPS (जो कि DSLs या भाषा जनरेटर का वर्णन करने के लिए एक टूलकिट है)। माइक्रोसॉफ्ट एक संक्षिप्त धावा था (और बहुत मैं जोड़ सकते हैं का वादा) इस स्थान में साथ यह एम भाषा (एम भाषा तो पूरा उस भाषा एम में परिभाषित किया गया था) था।

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


1

मेरा तर्क है कि मेटा-स्ट्रक्चर, मॉड्यूल, फ्रेमवर्क, प्लेटफॉर्म और सेवाएं कक्षाओं की तुलना में सभी उच्च-स्तरीय फीचर ग्रुपिंग हैं। प्रोग्रामिंग सिस्टम सार का मेरा पदानुक्रम:

  • सेवाएं
  • मंच, समाधान ढेर
  • चौखटे
  • मॉड्यूल, पैकेज
  • मेटा संरचनाएँ: मेटाक्लासेस, उच्च क्रम फ़ंक्शंस, जेनरिक, टेम्प्लेट, लक्षण, पहलू, सज्जाकार
  • ऑब्जेक्ट, कक्षाएं, डेटा प्रकार
  • फ़ंक्शंस, प्रक्रियाएँ, सबरूटीन्स
  • नियंत्रण संरचनाओं
  • कोड की लाइनें

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

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

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

समाधान ढेर या प्लेटफ़ॉर्म आमतौर पर कई समस्याओं को हल करने के लिए एक वातावरण में कई चौखटे, सबसिस्टम या घटकों को जोड़ते हैं।

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

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

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


1

कक्षाओं के बाद अगला अमूर्त मेटा क्लास हैं । यह इत्ना आसान है ;)

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


1
मेटाक्लास भाषा की वंशानुगत पदानुक्रम (ies) की जड़ वस्तुएं हैं। .NET का उद्देश्य है। आप इंटरफेस के रूप में मेटाक्लासेस के बारे में भी सोच सकते हैं; वे विरासत के वास्तविक "मूल" वर्ग से स्वतंत्र रूप से अपने उत्तराधिकारियों के इंटरफ़ेस को परिभाषित करते हैं।
20

1
@KeithS यह नहीं है कि किसी भी संदर्भ में शब्द का क्या अर्थ है, मैंने इसे देखा है - CLOS से UML से C #। एक मेटाक्लास एक वर्ग है जिसका उदाहरण वर्ग हैं - एक कमजोर कार्यान्वयन C # है Typeजो चिंतनशील क्षमता देता है लेकिन उत्परिवर्तन नहीं करता है (आप CLOS में MyTypeकहकर एक नई विधि नहीं जोड़ typeof(MyType).Methods += new Method ( "Foo", (int x)=>x*x )सकते हैं)
पीट किर्कहम

1

मुझे आश्चर्य है कि किसी ने भी श्रेणी सिद्धांत का उल्लेख नहीं किया है।

प्रोग्रामिंग की सबसे मौलिक इकाई फ़ंक्शन है जो प्रकारों पर आधारित है। फ़ंक्शन्स को आमतौर पर f: A -> B के रूप में दर्शाया जाता है, जहाँ A और B टाइप होते हैं। यदि आप इन चीजों को रखते हैं, जिन्हें मैं प्रकार और फ़ंक्शन कह रहा हूं, तो सही तरीके से आपको एक श्रेणी कहा जाता है। आपको इस बिंदु पर रुकना नहीं है।

इन चीजों, श्रेणियों को लें, और अपने आप से पूछें कि उन्हें एक दूसरे से संबंधित करने का सही तरीका क्या होगा। यदि आप इसे सही करते हैं, तो आपको एक फ़नकार नामक कुछ मिलता है जो दो श्रेणियों के बीच जाता है और आमतौर पर एफ: सी -> बी के रूप में चिह्नित किया जाता है। एक बार फिर आपको रोकना नहीं है।

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

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


1

मुझे लगता है कि अभिनेता मॉडल उम्मीदवारों की सूची से गायब है।

यहाँ मैं अभिनेताओं से क्या मतलब है:

  • स्वतंत्र संस्थाएं
  • संदेश प्राप्त करते हैं, और जब संदेश प्राप्त होता है, तो हो सकता है
  • नए अभिनेता बनाएँ,
  • अगले संदेश के लिए कुछ आंतरिक स्थिति को अपडेट करें,
  • और संदेश भेजें

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

संक्षिप्त चर्चा / परिचय: http://youtube.com/watch?v=7erJ1DV_Tlo


आपकी पोस्ट को पढ़ना मुश्किल है (पाठ की दीवार)। क्या आप बेहतर आकार में आईएनजी को संपादित करेंगे ?
gnat

0

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

एक के बाद एक निष्पादित किए गए विशिष्ट निर्देशों से , हम फ़ंक्शन / सबरूटीन्स पर जाते हैं , जो एक ही तत्व में निर्देशों का एक तार्किक समूहीकरण, संक्षिप्त या सार करता है। फिर हमारे पास ऑब्जेक्ट्स या मॉड्यूल हैं , जो एक निश्चित तार्किक इकाई या श्रेणी से संबंधित सबरूटीन्स को एनकैप्सुलेट करते हैं, इसलिए मैं सभी स्ट्रिंग ऑपरेशनों को समूह के तहत Stringया सभी सामान्य गणित संचालन को Mathमॉड्यूल (या स्टैटिक क्लास, जैसे भाषाओं में C #) में वर्गीकृत कर सकता हूं। ।

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

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

फिर, एक अच्छा अंतर है। ज्यादातर मामलों में, आप एक ऐसी वस्तु का उपयोग करेंगे जो एक सेवा के लिए प्रॉक्सी के रूप में कार्य करती है , और दोनों बहुत समान होंगे, लेकिन एक वास्तुकला के रूप में, दोनों अलग हैं।


0

अमूर्तता के नए रूप आप से निम्न-स्तरीय कार्य को छिपाते हैं। नामित प्रक्रियाएँ और फ़ंक्शंस प्रोग्राम पतों को आपसे छिपाते हैं। ऑब्जेक्ट्स डायनामिक मेमोरी मैनेजमेंट और कुछ टाइप-डिपेंडेंट "अगर स्टेटमेंट्स" को छिपाते हैं।

मेरा सुझाव है कि अगले स्तर के व्यावहारिक अमूर्त जो आपसे निम्न स्तर के ड्रगरी को छिपाएंगे, वे कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग हैंHttp://elm-lang.org/ जैसी कुछ चीज़ों में "सिग्नल" देखें, जो कॉलबैक और अपडेट निर्भरता को छिपाते हैं, आपको स्पष्ट रूप से जावास्क्रिप्ट में प्रबंधित करना होगा। एफआरपी अंतर-प्रक्रिया की जटिलता और अंतर-मशीन संचार को छिपा सकता है जो बड़े पैमाने पर इंटरनेट अनुप्रयोगों और उच्च-प्रदर्शन समानता में भी आवश्यक है।

मुझे पूरा यकीन है कि यह वही है जो हम सभी अगले 5 वर्षों में उत्साहित करने वाले हैं।


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

0

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.