English· Español· Deutsch· Nederlands· Français· 日本語· ქართული· 繁體中文· 简体中文· Português· Русский· العربية· हिन्दी· Italiano· 한국어· Polski· Svenska· Türkçe· Українська· Tiếng Việt· Bahasa Indonesia

un

guest
1 / ?
back to lessons

निरपेक्ष बाइनरी में प्रोग्रामिंग

पहले प्रोग्रामर निरपेक्ष बाइनरी में लिखते थे: हर निर्देश & हर पता कच्चे बाइनरी अंकों में। एक एकल निर्देश 01100101 00001010 की तरह दिख सकता है — निर्देश कोड & स्मृति पता बाइनरी में।

स्पेगेटी कोड की समस्या

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

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

परिणाम: प्रोग्राम के माध्यम से निष्पादन पथ कथित रूप से यादृच्छिक स्थानों पर कूद गया। हैमिंग ने इसे 'स्पेगेटी का डिब्बा' कहा। कागज पर खींचा गया नियंत्रण प्रवाह पथ बिल्कुल उलझी हुई स्पेगेटी की तरह दिखता था।

पलायन मार्ग

दो तत्काल सुधार: अष्टक संकेतन (बाइनरी अंकों को 3 के समूह में समूहीकृत करें) और षोडश संकेतन (4 के समूह, 9 से परे मानों के लिए A–F का उपयोग करते हुए)। इन्होंने लेखन त्रुटियों को कम किया लेकिन मौलिक पता समस्या को हल नहीं किया।

प्रतीकात्मक असेंबली (उदाहरण के लिए IBM का SAP — प्रतीकात्मक असेंबली प्रोग्राम — और IBM 650 पर SOAP — प्रतीकात्मक अनुकूलन असेंबली प्रोग्राम) ने प्रोग्रामरों को निर्देश नाम (ADD, MOVE) और प्रतीकात्मक पता लेबल बाइनरी के बजाय लिखने की अनुमति दी। असेंबलर इनपुट समय में बाइनरी में अनुवाद किया, स्वचालित रूप से पता असाइनमेंट का प्रबंधन किया।

SOAP ने एक अतिरिक्त अनुकूलन किया: इसने घूमने वाले ड्रम पर निर्देशों को व्यवस्थित किया ताकि अगला निर्देश पढ़ने वाले सिर पर तब पहुंचे जब पिछला पूरा हो गया हो — न्यूनतम विलंबता कोडिंग। SOAP ने यहां तक कि खुद को संकलित किया: प्रोग्राम A को डेटा के रूप में संसाधित किया गया ताकि B का उत्पादन हो, B को A पर चलाया गया ताकि मापा जा सके कि स्व-संकलन में कितना सुधार हुआ।

पार्स ट्री & भाषा पदानुक्रम

पुस्तकालय & पुनर्स्थान योग्य कोड

हैमिंग ने नोट किया कि पुनः प्रयोज्य सॉफ्टवेयर (गणितीय पुस्तकालय) का विचार बहुत जल्दी आया — बैबेज ने इसकी कल्पना की थी। समस्या: एक निरपेक्ष-पता पुस्तकालय के लिए हर दिनचर्या को हर बार उपयोग किए जाने पर समान स्मृति स्थान पर कब्जा करने की आवश्यकता थी। जब कुल पुस्तकालय बहुत बड़ा हो गया, तो प्रोग्राम समान पतों के लिए प्रतिस्पर्धा करते थे।

समाधान: पुनर्स्थान योग्य कोड। असेंबलर निर्देश उत्पन्न करता है जो स्मृति को सापेक्ष रूप से संदर्भित करते हैं — निरपेक्ष पतों के बजाय आधार पते से ऑफ़सेट। एक लिंकर लोड समय पर अंतिम पते को हल करता है।

वॉन नेउमन्न की अप्रकाशित रिपोर्ट (व्यापक रूप से प्रचारित) आवश्यक प्रोग्रामिंग ट्रिक्स का वर्णन करती है। पहली प्रकाशित प्रोग्रामिंग पुस्तक (विल्क्स, व्हीलर & गिल, EDSAC, 1951) ने इन तकनीकों को संहिताबद्ध किया।

समझाएं कि निरपेक्ष-पता पुस्तकालयों ने एक मापनीयता समस्या क्यों बनाई, और पुनर्स्थान योग्य कोड ने इसे कैसे हल किया। निरपेक्ष पतों की कौन सी विशिष्ट संपत्ति टकराव का कारण बनी, और 'पुनर्स्थान योग्य' तकनीकी रूप से क्या मायने रखता है?

भाषा डिजाइन का कांटा

FORTRAN (1957, IBM) & ALGOL (1958, अंतर्राष्ट्रीय समिति) दो डिजाइन दर्शन का प्रतिनिधित्व करते हैं जो मौलिक रूप से भिन्न परिणाम दिए।

FORTRAN

John Backus ने IBM में FORTRAN (FORmula TRANslation) परियोजना का नेतृत्व किया। डिजाइन लक्ष्य: भाषा को वैज्ञानिकों & इंजीनियरों के लिए उपयोग करना आसान बनाएं। FORTRAN ने गणितीय संकेतन स्वीकार किया जो इसके उपयोगकर्ताओं को प्राकृतिक लगा: A = B + C * D बजाय ADD B, C; STORE T; MULTIPLY T, D; STORE A के।

FORTRAN 60+ वर्षों तक जीवित रहा। यह वैज्ञानिक कंप्यूटिंग, तरल गतिविज्ञान, जलवायु मॉडलिंग, & कम्प्यूटेशनल भौतिकी में सक्रिय उपयोग में रहता है। हैमिंग ने इस स्थिरता को सफल डिजाइन के प्रमाण के रूप में नोट किया।

ALGOL

ALGOL (ALGOrithmic Language) को तार्किकविदों & कंप्यूटर वैज्ञानिकों की एक समिति द्वारा गणितीय कठोरता का लक्ष्य रखते हुए डिजाइन किया गया था: एक तार्किक रूप से स्वच्छ, औपचारिक रूप से परिभाषित भाषा। Backus-Naur फॉर्म (BNF) संकेतन व्याकरण का वर्णन करने के लिए ALGOL को निर्दिष्ट करने के लिए आविष्कार किया गया था।

ALGOL व्यावहारिक रूप से विफल रहा। इसके तार्किक सुंदरता & बाद की भाषाओं पर अपार प्रभाव (Pascal, C, & लगभग हर आधुनिक भाषा ALGOL की व्याकरण अवधारणाओं से उतरते हैं), ALGOL कभी व्यापक रूप से तैनात नहीं किया गया। हैमिंग का फैसला: तार्किक रूप से डिजाइन किए गए, मानवीय रूप से अप्रयोज्य।

भाषाओं की पदानुक्रम

हैमिंग ने मशीन कोड से लेकर असेंबली, उच्च-स्तरीय भाषाओं, & अंततः 'समस्या-उन्मुख भाषा' तक प्राकृतिक पदानुक्रम का वर्णन किया जो कैसे चिकित्सकों अपनी समस्या डोमेन के बारे में सोचते हैं। प्रत्येक स्तर मशीन दक्षता की कीमत पर मानव पठनीयता जोड़ता है।

हैमिंग के भाषा डिजाइन के चार मानदंड

हैमिंग ने FORTRAN बनाम ALGOL के पाठ को एक सफल प्रोग्रामिंग भाषा के चार मानदंड में आसवित किया:

1. सीखने में आसान — एक नौसिखिया जल्दी उत्पादक हो सकता है

2. उपयोग में आसान — दिनचर्या के काम को न्यूनतम औपचारिकता की आवश्यकता होती है

3. डीबग में आसान — त्रुटियां सार्थक, स्थानीय योग्य संदेश प्रदान करती हैं

4. उप-दिनचर्याओं का उपयोग करना आसान — पुनः उपयोग & अमूर्तता के लिए नायक प्रयास की आवश्यकता नहीं है

उन्होंने एक संरचनात्मक अवलोकन जोड़ा: मानव भाषा लगभग 60% अतिरेक ले जाती है; लिखित भाषा लगभग 40%। कम-अतिरेक भाषाएं (APL की तरह) सुंदर एक-पंक्तियां बनाती हैं जो विशेषज्ञ सुंदर पाते हैं & शुरुआत अपारदर्शी पाते हैं — & जिसमें अपरिवर्तनीय त्रुटियां होती हैं जब एक एकल चरित्र अर्थ बदल देता है।

निहितार्थ: एक भाषा तार्किक सुंदरता के लिए डिजाइन की गई गलत पाठक के लिए अनुकूलित करती है। प्रोग्रामर मानव है; मनुष्यों को त्रुटियों को पकड़ने & इरादे को संवाद करने के लिए अतिरेक की आवश्यकता होती है।

आप जो प्रोग्रामिंग भाषा अच्छी तरह जानते हैं उसे हैमिंग के चार मानदंडों पर लागू करें। प्रत्येक मानदंड को 1–5 (5=उत्कृष्ट) स्कोर करें। फिर पहचानें कि कौन सा मानदंड, अगर मजबूत किया जाए, तो भाषा में सबसे अधिक सुधार करेगा — & समझाएं कि एक विशिष्ट परिवर्तन क्या दिखेगा।

मनोवैज्ञानिक बनाम तार्किक भाषा डिजाइन

हैमिंग ने FORTRAN/ALGOL विपरीत को संस्थागत & मानव गतिविज्ञान के पाठ के रूप में लौटाया, न कि केवल भाषा डिजाइन।

FORTRAN को मनोवैज्ञानिक रूप से डिजाइन किया गया — इसे उपयोग करने वाले मनुष्यों के लिए, विशेष रूप से वैज्ञानिक जो गणितीय संकेतन में सोचते हैं। ALGOL को तार्किक रूप से डिजाइन किया गया — औपचारिक शुद्धता & सैद्धांतिक सुंदरता के लिए।

हैमिंग द्वारा पहचाना गया विरोधाभास: एक तार्किक रूप से सही भाषा जिसका मनुष्य प्रतिरोध करते हैं विफल होती है; एक व्यावहारिक रूप से डिजाइन की गई भाषा जिसे मनुष्य अपनाते हैं सफल होती है, भले ही यह तार्किक रूप से गड़बड़ा हो।

उन्होंने APL को चरम स्थिति के रूप में उद्धृत किया: तार्किक रूप से सुंदर, एक-पंक्ति अभिव्यक्त, अपने स्वयं के विशेष वर्ण सेट के साथ। विशेषज्ञों को यह पसंद था। सामान्य प्रोग्रामरों को इसे अपठनीय मिला। एक एकल चरित्र परिवर्तन एक प्रोग्राम का अर्थ चुप्पी से रूपांतरित कर सकता है। APL का एक छोटा समर्पित समुदाय है & लगभग शून्य मुख्यधारा का उपयोग है।

मानव अतिरेक तर्क: बोली जाने वाली भाषा ~60% अतिरेक (दोहराया संदर्भ, स्पष्ट शब्द, अनुमानित संरचना) है। लिखित भाषा ~40% अतिरेक है। यह अतिरेक त्रुटि पहचान का कार्य करता है — मनुष्य अविश्वसनीय हैं, इसलिए भाषा त्रुटियों को पकड़ने & सुधारने के लिए पर्याप्त दोहराई गई जानकारी के साथ विकसित हुई। एक कम-अतिरेक भाषा इस सुरक्षा नेट को हटाता है।

Compiler पदानुक्रम

हैमिंग ने Compiler/interpreter लेयरिंग का वर्णन किया: एक प्रोग्राम एक उच्च-स्तरीय भाषा में पढ़ सकता है & इसे निचले स्तर के लिए अनुवाद कर सकता है। इन परतों को स्टैक करें — प्रत्येक एक स्तर नीचे अनुवाद करता है। शीर्ष पर: एक डोमेन-विशिष्ट भाषा जो किसी क्षेत्र (जीव विज्ञान, वित्त, भौतिकी) में विशेषज्ञ स्वाभाविक रूप से लिखते हैं। नीचे: मशीन कोड। प्रत्येक संक्रमण एक Compiler या interpreter है।

भाषा जीवन की भविष्यवाणी करना

1993 तक, हैमिंग ने कई भाषाओं को सफल & विफल देखा था। FORTRAN (1957) जीवित रहा। ALGOL (1958) विफल रहा। COBOL (1959) व्यावसायिक कंप्यूटिंग में दशकों तक जीवित रहा। LISP (1958) AI अनुसंधान में जीवित रहा। PL/I (1964) सब कुछ को एकीकृत करने का प्रयास किया & विफल रहा।

हैमिंग के मनोवैज्ञानिक बनाम तार्किक डिजाइन अंतर & उनके चार मानदंडों का उपयोग करके समझाएं कि एक भाषा आप जानते हैं क्यों पनपी & एक विफल रहे (या विफल हो रहे हैं)। आपकी व्याख्या अपनाने या अस्वीकृति को चलाने वाले विशिष्ट मानव कारकों की पहचान करनी चाहिए — केवल तकनीकी गुण नहीं।

आवर्ती पैटर्न

हैमिंग की सॉफ्टवेयर इतिहास अध्याय एक आवर्ती संरचना है:

1. एक दर्दनाक सीमितता मौजूद है (निरपेक्ष पते, बाइनरी संकेतन, गैर-मरम्मत योग्य कोड)

2. कोई व्यक्ति एक अमूर्तता परत का आविष्कार करता है जो सीमितता को छुपाता है

3. अमूर्तता नए स्केल को सक्षम बनाता है, जो नई दर्दनाक सीमितताएं बनाता है

4. दोहराएं

बाइनरी → अष्टक/hex → प्रतीकात्मक असेंबली → FORTRAN → संरचित प्रोग्रामिंग → ऑब्जेक्ट-उन्मुख भाषाएं → डोमेन-विशिष्ट भाषाएं। प्रत्येक परत पूर्ववर्ती की सबसे तीव्र पीड़ा को हल करता है जबकि एक नई समस्याओं का एक नया वर्ग शुरू करता है।

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

इंजीनियरों के लिए उनका सबक: आप हमेशा पिछली अमूर्तता द्वारा उजागर की गई पीड़ा को हल कर रहे हैं। आप जो परत पर हैं उसे समझने के लिए जानना आवश्यक है कि इसके नीचे की परत क्यों मौजूद है।

एक सॉफ्टवेयर अमूर्तता परत की पहचान करें जिसके साथ आप नियमित रूप से काम करते हैं। यह किस दर्दनाक सीमितता को नीचे की परत में छुपाता है? & आपकी वर्तमान परत समस्याओं का कौन सा नया वर्ग शुरू करता है — कौन सी पीड़ा अगली परत को हल करनी होगी?