प्रोग्रामिंग में कस्टम डेटा प्रकारों का विकास

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

कस्टम डेटा प्रकार डेटा प्रकार हैं जो उपयोगकर्ता द्वारा भाषा में उपलब्ध होने के आधार पर बनाए जा सकते हैं।

उपयोगकर्ता इस प्रकार के डेटा रखना चाहते हैं।

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

कस्टम डेटा प्रकारों का अभाव

एक बार जब कोई उपयोगकर्ता डेटा प्रकार नहीं थे। किसी तरह मुड़ गया

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

अंतर्निहित डेटा प्रकार

निर्मित प्रकार बहुत सुविधाजनक हैं! जब आप डेवलपर्स द्वारा योजना के अनुसार उनका उपयोग करते हैं ...

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

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

लेकिन उपयोगकर्ता कम हैं - वे अधिक से अधिक उपयोगकर्ता डेटा चाहते हैं।

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

और फिर, फोरट्रान के साथ अल्गोला की एड़ी पर कदम रखते हुए, 1958 में एक और भाषा दिखाई दी, पूरी तरह से भाषा के विपरीत - लिस्प।


लिस्प अकल्पनीय कार्य कर सकते हैं। बस इसके साथ कैसे रहना है?

उन्होंने अभी तक एक और पूरी तरह से नया प्रकार का डेटा, वास्तविक उपयोगकर्ता डेटा प्रकार - फ़ंक्शन (सी-एक्सप्रेशन के रूप में) दिया, जो 21 वीं शताब्दी की शुरुआत से सभी आधुनिक भाषाओं में दृढ़ता से दर्ज करना शुरू कर दिया (मुख्य रूप से बहु-प्रतिमान पायथन और रूबी के लिए धन्यवाद)। यह देखते हुए कि लिस्प आपको मैक्रोज़ के साथ काम करने की अनुमति देता है - प्रोग्रामिंग eval-s (58 वें में) जैसा कुछ - यह आश्चर्य की बात नहीं है कि दुनिया इसके लिए तैयार नहीं थी।
लेकिन क्या अब दुनिया लिस्प के लिए तैयार है? शायद नहीं।
क्यों इंगित करें। लिस्प, किसी भी अन्य कार्यात्मक प्रोग्रामिंग की तरह, उच्च अंतःसंबंधित वस्तुओं के साथ काम करता है, कुछ हद तक एक यांत्रिक घड़ी के जुड़े गियर की याद ताजा करती है। अनिवार्य भाषाओं के विपरीत, गियर में कोई भी wedging पूरे तंत्र को बंद कर देता है। इस वजह से, उपयोगकर्ता डेटा प्रकारों सहित भाषा की आवश्यकताएं बहुत सख्त हैं। जो समस्याएं लिस्प में तुरंत उठती हैं, अनिवार्य भाषाओं में, वे केवल 80 के दशक के अंत तक खराब हो गईं।
लिस्प किसी भी सी-अभिव्यक्ति का निर्माण करना संभव बनाता है। लेकिन यह केवल एक टूलकिट देता है - सी-भाव के साथ काम करने के लिए एक मानक और सरल टूलकिट।
यह पता चला है कि किसी भी उपयोगकर्ता डेटा को लिखने का एक अवसर है, लेकिन आप उनके साथ केवल प्राइमिटिव्स के साथ ही काम कर सकते हैं। लिस्प जैसी भाषाओं के विकास से पता चला है कि अब तक अलिखित सी-एक्सप्रेशन के लिए कोई अच्छा टूलकिट नहीं मिला है।

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

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


कभी-कभी आपको केवल उन विशेषताओं के साथ काम करने की आवश्यकता होती है जो हैं

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

अंतर्निहित डेटा प्रकारों का युग समाप्त हो रहा था।
लेकिन वर्ष 1972 आया, दिखाई दिया ... सी। और डायनासोर के प्रभुत्व का युग (अंतर्निहित डेटा प्रकार) एक और दशक तक जारी रहा, हालांकि कस्टम डेटा प्रकार सूरज के नीचे उनकी जगह लेना शुरू कर दिया।
सी में ही शामिल है।

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


मास्टर कुंजी जैसे गतिशील डेटा प्रकार बदसूरत हैं, लेकिन उनके साथ किस तरह के छिपे हुए कमरे तक नहीं पहुंचा जा सकता है!

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

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

70 के दशक का अंत निकट था, और ये बुनियादी अंतर्निहित डेटा प्रकार वास्तविक उपयोगकर्ता डेटा को रास्ता देते हुए, दिनचर्या के अनुसार, परिधि पर जाने लगे।

हालांकि, वास्तविकता कभी-कभी आश्चर्यजनक आश्चर्य प्रस्तुत करती है।
कौन जानता है कि अच्छे पुराने और लंबे समय से समझे जाने वाले डेटा प्रकारों में कितना अधिक पाया जा सकता है! "


कभी-कभी आपको बस नए को देखने की जरूरत होती है जहां सब कुछ लंबे समय से जाना जाता है। उदाहरण के लिए, एमएंडई की यह छँटाई

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

समूह डेटा प्रकार

कुछ समूह बड़े हैं। मैं उनके साथ जल्दी काम करना चाहता हूं

वास्तव में, समूह डेटा प्रकार एक भाषा का एक बहुत कुछ है, आमतौर पर एक मोनोमोर्फिक समूह। अक्सर ये डेटा प्रकार उपयोगकर्ता-परिभाषित नहीं होते हैं, लेकिन अंतर्निहित होते हैं, लेकिन कभी-कभी वे इतने लचीले होते हैं कि यह पर्याप्त है।
फोरट्रान ने पहले से ही समूह डेटा प्रकारों का समर्थन किया है - ये सरणियाँ हैं, हालांकि वे अब की तुलना में थोड़ा अलग दिखते थे। आधुनिक लोगों के लिए बहुत समान हैं पहले से ही अल्गोल में थे। पास्कल में सेट थे (सेट)
लिस्प में सूचियां (सूची) थीं।
फिर हैश टेबल, संबद्ध सरणियाँ, वैक्टर, ढेर, कतारों, ढेर, पेड़ ...
कुछ एम्बेड किया गया था, कुछ कस्टम डेटा प्रकारों का उपयोग करके नकली या बनाया गया था।
समूह डेटा प्रकारों के आगे विकास के कारण विकास की 2 अलग-अलग शाखाएँ हुईं
1) प्रत्येक समूह डेटा प्रकार के साथ इसकी कार्यक्षमता का उपयोग करने की आवश्यकता सबसे संतोषजनक नहीं थी, मैं उनके साथ उसी तरह काम करना चाहता था। अनिवार्य भाषाओं में इसके लिए मुख्य उपकरण संग्रह और पुनरावृत्त हैं। अधिकतर 2000 के दशक के प्रारंभ में जोड़े गए।
2) 80 के दशक में, डेटा विकास के विकास के साथ, समूह डेटा प्रकारों के साथ काम करने के लिए उपकरणों का विस्तार करने की आवश्यकता छलांग और सीमा से बढ़ी। डेटाबेस दिखाई दिए, और उनके साथ क्वेरी और क्वेरी दोनों भाषाएँ। 80 के दशक के मध्य में, संरचित क्वेरी भाषा (SQL) प्रमुख हो गई। स्ट्रिंग्स के लिए पार्सर की तरह, क्वेरी भाषा ने यह स्पष्ट किया कि समूह डेटा प्रकारों के लिए उपयोग किए जाने वाले टूल को प्राइमर क्वेरी भाषा माना जा सकता है। डेटाबेस, एक नियम के रूप में, भाषा से बाहर ले जाया जाता है, और भाषा में उनके साथ काम करने के लिए केवल विधियां हैं, इसलिए उन्हें पूर्ण रूप से उपयोगकर्ता डेटा प्रकार नहीं माना जा सकता है। हालांकि उनके लचीलेपन के कारण, यह महत्वपूर्ण नहीं है।

वास्तविक उपयोगकर्ता डेटा प्रकार

विभिन्न भाषाओं में अंतर्निहित डेटा प्रकारों के युग में, अत्यधिक विदेशी अंतर्निहित डेटा प्रकारों के लिए समर्थन पाया जा सकता है।
उदाहरण के लिए, C में, इस प्रकार का डेटा एनम था। यह सी से पहले था, पहले पास्कल (1970) द्वारा पेश किया गया था, हालांकि इसे एक स्केलर कहा जाता था।


उंगलियों पर बच्चों को भी समझाने के लिए एक कल्पना क्या आसान है

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

समग्र डेटा प्रकार

प्रविष्टियाँ बहुत विविध हैं। फिर भी सीखेंगे कि उनका उपयोग कैसे किया जाए

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

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

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

वस्तुएं

वस्तुएं सब कुछ कर सकती हैं। खुद को और खुद से ऊपर

ऑब्जेक्ट एक अन्य प्रकार के उपयोगकर्ता डेटा हैं। इसमें रिकॉर्ड की तुलना में काफी अधिक क्षमताएं हैं।
इससे उसे केवल जंगली लोकप्रियता हासिल करने का अवसर मिला।
विडंबना यह है कि सिमुला की तरह, जो सी से कुछ साल पहले बाहर आए थे, जिसमें कोई वस्तु नहीं थी, इसलिए सी ++ से कुछ साल पहले, 1980 में स्मोलटॉक ने प्रतिमान "सभी वस्तुओं" की घोषणा की।
लेकिन स्मॉलटाक बहुत लोकप्रियता हासिल नहीं कर पाया, उसे तब तक इंतजार करना पड़ा जब तक कि सी ++ ठहराव के स्तर तक नहीं पहुंच गया, और उसके बाद ही, 1995 में जावा फिर से "सभी वस्तुओं" प्रतिमान को अपने सिर से ऊपर उठाने में सक्षम था।
वस्तुएं इतनी अच्छी क्यों हैं, क्योंकि वे रिकॉर्ड से बहुत अलग नहीं हैं। वास्तव में - विधियों के अतिरिक्त के साथ समान प्रविष्टियां।
सबसे पहले, वस्तुओं के साथ काम करने के लिए उपकरण संरचना के साथ काम करने के लिए उपकरणों की तुलना में बहुत समृद्ध और मजबूत हैं।
और दूसरी बात, वस्तुओं के साथ काम करने के लिए उपकरण जो अभी तक नहीं बनाए गए हैं ... भी मौजूद नहीं थे।
रोकें, आप पूछते हैं कि "दूसरा" कहां है, अगर वस्तुओं में गैर-निर्मित डेटा प्रकारों के साथ कोई उपकरण नहीं है, और रिकॉर्ड नहीं है। और फिर भी, दूसरी बात! अभिलेखों के लिए, इस टूलकिट की नकल करना आवश्यक था, जबकि वस्तुओं के लिए, आप बस इस टूलकिट को ऑब्जेक्ट के अंदर लागू कर सकते हैं!
और अगर अचानक उपयोगकर्ता डेटा प्रकार को थोड़ा बदलना आवश्यक था, तो वंश के निर्माण के लिए वस्तुओं का एक टूलकिट का उपयोग करना सुविधाजनक था - वंशज बनाने के लिए और इसमें व्यवहार को सही करने के लिए।
वस्तुओं के उछाल और कुल उपयोग से अब ठहराव आ गया है।
वस्तुओं को आगे बढ़ने से क्या रोक रहा है?
जैसा कि हम याद करते हैं, नई वस्तु के टूलकिट का कार्यान्वयन पूरी तरह से प्रोग्रामर के साथ होता है, न कि भाषा के साथ, इसलिए कोड के पुन: उपयोग का स्तर उतना बड़ा नहीं होता जितना कि यह हो सकता है।
समान रूप से महत्वपूर्ण बढ़ती निकटता है। ऑब्जेक्ट खुद ही सब कुछ कर देगा, हालांकि इससे सब कुछ करना लगभग आवश्यक नहीं है। और इसके विपरीत, अपने आप को सब कुछ करने की क्षमता होने के नाते, यह ऑब्जेक्ट दूसरों के लिए कुछ भी नहीं करेगा। हो सकता है, लेकिन ऐसा नहीं हुआ।
भाग में, इंटरफेस और मिक्सिंस (मिश्रण, लक्षण) का परिचय समस्या को हल करने में मदद करता है।
इंटरफेस पहले डेल्फी (1986 में ऑब्जेक्ट पास्कल के रूप में), बाद में जावा और सी # द्वारा पेश किए गए हैं। और यह समझ में आता है - वे वस्तु भाषाओं में नेता थे।
लेकिन जो आश्चर्य की बात है, लिफ़्ट (जायके, सीएलओएस) (सीएलओएस कॉमन लिस्प का हिस्सा है) के लिए वस्तुओं को संलग्न करने की कोशिश करते समय उपप्रकार / लक्षण दिखाई दिए, बाद में विभिन्न भाषाओं में जोड़ा गया।
हालांकि, इंटरफेस और अशुद्धियों के रूप में भी ऐसे अमूर्त मददगार हमेशा मदद नहीं करते हैं, उदाहरण के लिए, "अंतिम" (अंतिम) लेबल वाली एक पुरानी वस्तु के लिए। आंशिक रूप से, हाइब्रिडाइजेशन समस्या को 1980 के दशक के मध्य में प्रोटोटाइप इनहेरिटेंस (स्वयं की भाषा (उसी स्मॉलटॉक की एक बोली) द्वारा खोजी गई) के आधार पर हल किया जा सकता है और एक दशक बाद मुख्य रूप से जावा स्क्रिप्ट के लिए लोकप्रियता प्राप्त हुई है, लेकिन इस पद्धति में वर्ग की विरासत के बारे में कमियां हैं।
दिलचस्प मेटाक्लासेस के लिए समर्थन है, जो 1980 में स्मॉलटाक में शामिल किए गए थे और अब कुछ भाषाओं द्वारा समर्थित हैं, उदाहरण के लिए, पायथन। मेटाक्लासेस कक्षाओं के साथ वस्तुओं के रूप में काम करते हैं (ऐसा पुनरावर्ती दृष्टिकोण)। यह वस्तुओं के साथ वस्तुओं के रूप में काम करने के लिए उपकरणों में बहुत सुधार करता है।
अब पहली जगह में एक नई वस्तु का निर्माण नहीं है, लेकिन डिजाइन पैटर्न (पैटर्न) का उपयोग करके सिस्टम डिजाइन के लिए एक सक्षम दृष्टिकोण।
आगे क्या होगा? सवाल बयानबाजी का है।
क्या वस्तुओं, संरचनाओं के रूप में ऐसे शक्तिशाली उपयोगकर्ता डेटा प्रकार के विकल्प हैं? हाँ, और वस्तुओं से भी बेहतर! यह समझना बेहतर है कि भविष्य में ऑब्जेक्ट कैसे विकसित हो सकते हैं।

एक विकल्प के लिए खोजें

क्राइस्ट और कृष्ण एक साथ। इम्पीरियल और फंक्शनलिटी एक साथ हो सकती है।

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

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

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

बीजगणितीय डेटा प्रकार

एटीडी इतना सुंदर है कि मैं इसे एक फ्रेम में सम्मिलित करना चाहता हूं और इसे लटका देना चाहता हूं। और कभी-कभी, वहां छोड़ दें और इसे फिर से न

छूएं वाह, यह कैसे खतरनाक लगता है!
मानक एमएल ने पहली बार 1990 बीजीय डेटा प्रकार (एटीडी) पेश किया।
बीजगणितीय डेटा प्रकार सबसे शक्तिशाली उपयोगकर्ता डेटा प्रकारों में से एक है। वे गणितज्ञ हिंडले और मिलनर द्वारा लैम्ब्डा कैलकुलस में पाए गए थे।
ADT "सभी में एक है" - एकात्मक डेटा प्रकार (प्रकार नल), एन्यूमरेशन (टाइप एनम, बूल), संरक्षित आधार प्रकार (जैसे लिंक के विपरीत संसाधन), स्विच प्रकार (सी - यूनियन में कुछ) सूची-जैसी संरचनाएँ, वृक्ष संरचनाएँ, फ़ंक्शंस, टुपल्स, रिकॉर्ड्स, ऑब्जेक्ट-जैसी संरचनाएँ (लेकिन ऑब्जेक्ट नहीं)। और इस सब का कोई संयोजन।
यह वस्तुओं की तुलना में बहुत बेहतर है! कम से कम विभिन्न प्रकार के कस्टम डेटा बनाने के दृष्टिकोण से - हां, बेहतर, निश्चित रूप से।
केवल अन्य दृष्टिकोण से, यह डेटा दोनों मानक एमएल में और बाद में ओकामला बहुत, बहुत दुर्लभ है।
एडीटी के साथ एडीटी के साथ काम करने के लिए उपकरण रिकॉर्ड के साथ काम करने से बहुत अधिक नहीं हैं, और वस्तुओं के साथ बहुत कम हैं।
दूसरे, डेटा प्रकारों के साथ काम करने के लिए कोई उपकरण नहीं हैं जो अभी तक नहीं बने हैं। और, वस्तुओं के विपरीत, समोप्सी टूलकिट को छिपाने के लिए कहीं नहीं है। केवल नकल करते हैं।
कमल, मानक एमएल के वंशज के रूप में, दो बार बिना सोचे-समझे, वस्तुओं को खुद से जोड़ दिया और ओकामेल (1996 तक) बन गए। और समानांतर में, ओकामल ने एक वैकल्पिक, अधिक कार्यात्मक समाधान विकसित करना शुरू किया, जहां उपयोगकर्ता डेटा के साथ काम करने के लिए उपकरणों के कार्यान्वयन को छिपाने के लिए - पैरामीट्रिक मॉड्यूल में। और, 15 वर्षों में, ओकामल ने वस्तुओं के लिए एक योग्य कार्यात्मक प्रतिस्थापन का निर्माण किया। अभी भी एक दिलचस्प दृष्टिकोण है - जैसा कि हम याद करते हैं, अलिखित एडीटी डेटा के लिए उपकरणों की कमी की समस्या से छुटकारा पाने के लिए पैरामीट्रिक मॉड्यूल-फ़ंक्शंस पेश किए गए थे, केवल पैरामीट्रिक मॉड्यूल स्वयं अब एडीटी से लगभग अलग नहीं हैं, जिसका अर्थ है कि अब कोई उपकरण नहीं है नहीं लिखा है ... मॉड्यूल। प्रत्यक्ष पुनरावृत्ति!
और इन 15 वर्षों में, ओकामल ने गैर-निर्मित डेटा प्रकारों के लिए उपकरणों की कमी की समस्या को हल करने के लिए एक और विकल्प पाया है, उन्होंने उन्हें कहा कि - विकल्प (संस्करण)। यह एक अलग डेटा प्रकार है, एडीटी नहीं, हालांकि यह समान दिखता है। यह एक स्विचिंग डेटा प्रकार है, उसी समय इसे किसी भी अनुपात में साझा किया जा सकता है, जिसमें मिश्रण (ATData को अनुपात में साझा नहीं किया जा सकता है, न ही इसे मिलाया जा सकता है)। यह अच्छा है कि आप आनुपातिक रूप से साझा कर सकते हैं (आप इसे केवल इंटरफेस या विशेषता का उपयोग करके वस्तुओं के साथ प्राप्त कर सकते हैं, और पूरी तरह से भी नहीं), यह अक्सर मिश्रण करने के लिए आकर्षक है (आप ऑब्जेक्ट के साथ ऐसा नहीं करते हैं), यह किसी भी अनुपात में खराब है। अभी भी काम करना बाकी है। यह डेटा प्रकार अविकसित है। सरल विकास पथों में से, टूलकिट सेट के वेरिएंट के साथ काम करने के लिए एक लिथो स्कार टूलकिट जोड़ें।

बीजीय डेटा प्रकार प्रकार वर्गों के साथ रखा

टाइप क्लास के साथ ADT एक जैसे दिखते हैं, लेकिन बहुत ज्यादा सक्षम होते हैं।

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

यह निश्चित रूप से वस्तुओं में एम्बेडेड की तुलना में उपयोगकर्ता डेटा प्रकारों की संभावनाओं के संदर्भ में बहुत अधिक है।

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

निष्कर्ष

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