सी ++ एसटीएल, 1995 के निर्माता के साथ साक्षात्कार। भाग 1

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

एलेक्स, सामान्यीकृत प्रोग्रामिंग में आपकी दीर्घकालिक रुचि के बारे में कुछ बताएं।

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

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

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

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

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

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

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

फिर मुझे C ++ पुस्तकालयों पर C ++ भाषा समूह में बेल लैब में नौकरी की पेशकश की गई। उन्होंने मुझसे पूछा कि क्या मैं C ++ में भी ऐसा कर सकता हूं। बेशक, मैं सी ++ नहीं जानता था, और निश्चित रूप से मैं सहमत था। लेकिन मैं सी ++ में ऐसा नहीं कर सका, क्योंकि 1987 में, C ++ में इस प्रोग्रामिंग शैली के लिए आवश्यक टेम्पलेट नहीं थे। सामान्यीकरण प्राप्त करने के लिए वंशानुक्रम ही एकमात्र तंत्र था, और यह पर्याप्त नहीं था।

अब भी, C ++ में वंशानुक्रम सामान्यीकृत प्रोग्रामिंग के लिए विशेष रूप से मूल्यवान नहीं है। आइए चर्चा करें कि क्यों। कई ने डेटा संरचनाओं और कंटेनर कक्षाओं को लागू करने के लिए विरासत का उपयोग करने की कोशिश की है। जैसा कि हम अब जानते हैं, बहुत कम सफल प्रयास हुए हैं, यदि कोई हो। C ++ की विरासत और इससे जुड़ी प्रोग्रामिंग शैली काफी सीमित है। तो, इसमें एक डिजाइन को लागू करना असंभव है जिसमें समानता के लिए तुलना ऑपरेटर का उपयोग करना जैसी सरल बात शामिल है। यदि आप अपने पदानुक्रम की जड़ के रूप में बेस क्लास X से शुरू करते हैं और इस वर्ग के लिए एक वर्चुअल समानता तुलना ऑपरेटर को परिभाषित करते हैं जो टाइप X का तर्क प्राप्त करता है, तो X से वर्ग Y को विरासत में मिला। समानता तुलना ऑपरेटर का इंटरफ़ेस क्या है? इसमें एक समानता है जो Y की X के साथ तुलना करती है। उदाहरण के रूप में जानवरों का उपयोग करना (ऑब्जेक्ट ओरिएंटेड लोग जानवरों से प्यार करते हैं), एक "स्तनपायी" को परिभाषित करते हैं और एक स्तनपायी से "जिराफ़" प्राप्त करते हैं। फिर सदस्य फ़ंक्शन "मेट" को परिभाषित करें, जिसमें एक जानवर दूसरे के साथ संभोग करता है और जानवर को वापस करता है। फिर आप जानवर से "जिराफ़" लाते हैं और निश्चित रूप से, यह "मेट" फ़ंक्शन होता है, जिसमें जिराफ़ जानवर के साथ संभोग करता है और जानवर को वापस लौटाता है। यह निश्चित रूप से नहीं है कि आप क्या चाहते हैं। जबकि जोड़ी बनाना C ++ प्रोग्रामर के लिए बहुत महत्वपूर्ण नहीं हो सकता है, समानता ऑपरेटर ऐसा है। मुझे एक भी एल्गोरिथ्म का पता नहीं है जो किसी प्रकार की समानता की तुलना का उपयोग नहीं करेगा।

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

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

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

C ++ सफल है, क्योंकि, एक मशीन मॉडल की पेशकश करने की कोशिश करने के बजाय, केवल उसकी नाभि पर चिंतन करने की प्रक्रिया में आविष्कार किया गया, Bjarn ने C से शुरू किया और C को और विकसित करने की कोशिश की, और अधिक सामान्यीकृत प्रोग्रामिंग तकनीक प्रदान की, लेकिन इस मशीन मॉडल के ढांचे के संदर्भ में। मशीन मॉडल सी बहुत सरल है। आपके पास एक मेमोरी है जहां इकाइयां हैं। आपके पास लगातार मेमोरी तत्वों के लिए संकेत हैं। इसे समझना बहुत आसान है। C ++ इस मॉडल को बचाता है, लेकिन मेमोरी में स्थित संस्थाओं को C मशीन की तुलना में अधिक व्यापक बनाता है, क्योंकि C में डेटा प्रकारों का एक सीमित सेट है। अर्थात्, C में ऐसी संरचनाएं हैं जो एक्स्टेंसिबल टाइप सिस्टम की भिन्नता प्रदान करती हैं, लेकिन यह आपको संरचनाओं पर संचालन को परिभाषित करने की अनुमति नहीं देता है। यह टाइप सिस्टम की एक्स्टेंसिबिलिटी को सीमित करता है। C ++ ने C मशीन मॉडल को वास्तव में एक्स्टेंसिबल टाइप सिस्टम के लिए उन्नत किया है।

1988 में, मैं एचपी लैब्स में चला गया, जहां मुझे सामान्य पुस्तकालयों में काम करने के लिए रखा गया था। कई वर्षों तक, मैंने इसके बजाय हार्ड ड्राइव पर काम किया, और यह रोमांचक था, लेकिन अनुसंधान के इस क्षेत्र में पूरी तरह से ऑर्थोगोनल था। मैं 1992 में एक सामान्य पुस्तकालय के विकास में लौट आया, जब मेरी प्रयोगशाला के पूर्व प्रमुख बिल वर्ले ने एक प्रबंधक के रूप में मेरे साथ एल्गोरिदम पर एक परियोजना शुरू की। उस समय तक C ++ में टेम्पलेट थे। मैंने पाया कि Bjarn ने डिजाइनिंग के उत्कृष्ट कार्य किए हैं। कुछ समय पहले मैंने बेल लैब्स में डिज़ाइनिंग टेम्प्लेट्स के बारे में कई चर्चाओं में भाग लिया था, और मैंने बजरन के साथ बहुत दृढ़ता से तर्क दिया कि उन्हें सी + + टेम्प्लेट्स को जितना संभव हो सके एडीए जेनरिकों के करीब बनाना चाहिए। मुझे लगता है कि उन्होंने इतना कठिन तर्क दिया कि उन्होंने विपरीत निर्णय लिया। मुझे लगता है कि C ++ में टेम्पलेट फ़ंक्शंस होने का महत्व है, और न केवल टेम्पलेट कक्षाएं, जैसा कि कई लोग सोचते हैं। मैंने सोचा, हालाँकि, कि टेम्पलेट फ़ंक्शंस को Ada जेनरिक की तरह काम करना चाहिए, अर्थात कि उन्हें स्पष्ट रूप से तत्काल किया जाना चाहिए था। बजरन ने मेरी बात नहीं मानी और एक टेम्प्लेट फंक्शन मैकेनिज्म तैयार किया, जिसमें ओवरलोड मैकेनिज्म का उपयोग करके टेम्प्लेट्स को तुरंत स्पष्ट किया जाता है। यह विशिष्ट तकनीक मेरे काम के लिए महत्वपूर्ण हो गई है, जैसे मैंने पाया कि उसने मुझे बहुत कुछ करने की अनुमति दी जो कि आदा में असंभव थी। मैं बजरन द्वारा विकसित इस विशेष डिजाइन को एक उत्कृष्ट परिणाम के रूप में देखता हूं, और मुझे खुशी है कि उन्होंने मेरी सलाह का पालन नहीं किया।

आपने एसटीएल पर काम कब शुरू किया और इसका मूल उद्देश्य क्या था?

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

( जारी )

( मूल लेख )