1 पॉइंट द्वारा GN⁺ 2024-02-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Multics ऑपरेटिंग सिस्टम के विकास की कहानी

  • Multics ऑपरेटिंग सिस्टम विकसित करने वाले André Bensoussan ने file system में प्रमुख बदलावों का काम संभाला।
  • VTOC manager एक subsystem था जो disk और memory के बीच file information के स्थानांतरण, shared memory buffer pool के प्रबंधन, और disk पर information space के प्रबंधन का काम करता था।
  • André ने VTOC manager के design, implementation और testing की ज़िम्मेदारी ली, और design के दौरान कई diagrams बनाए।

विकास प्रक्रिया और सफलता

  • project coordinator Tom Van Vleck को schedule को लेकर चिंता थी, लेकिन जैसे ही André ने code लिखना शुरू किया, वे आश्वस्त हो गए।
  • André ने computer terminal के बजाय pencil से code लिखा, typing में मदद भी ठुकरा दी, और सारा काम खुद किया।
  • अंत में pencil से लिखे साफ-सुथरे code को terminal में दर्ज कर compile करने की कोशिश की गई; कुछ typos ठीक करने के बाद वह सफलतापूर्वक compile हो गया।
  • system में integrate करके test करने पर VTOC manager शुरू से ही पूरी तरह सही काम करता रहा।

André की सफलता का राज़

  • André ने केवल pencil को उपकरण बनाकर एक flawless program लिखा।
  • VTOC manager में मिला एकमात्र bug Tom Van Vleck की गलती के कारण था; उन्होंने error handling procedure के call order के बारे में गलत बताया था।
  • André की कार्यशैली को software engineering पर एक लेख के रूप में IEEE Computer के अप्रैल 1994 अंक में पेश किया गया था, और नवंबर 2003 में उसे अपडेट किया गया।

GN⁺ की राय

  • André Bensoussan की Multics ऑपरेटिंग System विकास कहानी दिखाती है कि गहन design और एकाग्रता किस तरह एक बेहतरीन परिणाम दे सकते हैं।
  • जब केवल pencil और paper वाली पारंपरिक पद्धति की तुलना आधुनिक जटिल software development tools से की जाती है, तो यह बुनियादी सिद्धांतों पर टिके रहने वाले approach के महत्व को रेखांकित करती है।
  • यह कहानी software engineering में सावधानीपूर्वक पूर्व-तैयारी और testing के महत्व की याद दिलाने वाला एक अच्छा उदाहरण है, और engineering education के लिए भी महत्वपूर्ण सीख देती है।

1 टिप्पणियां

 
GN⁺ 2024-02-13
Hacker News राय
  • पहले कमेंट का सार:

    • स्पष्ट requirements: सॉफ़्टवेयर में कम bugs होने और उसके तेज़ होने की वजह यह है कि requirements स्पष्ट रूप से परिभाषित होती हैं। आज का सॉफ़्टवेयर इस बात पर अस्पष्ट होता है कि क्या बनाया जाना चाहिए, और "agile" तरीके के कारण लगातार बदलता रहता है। अगर developers को स्पष्ट API और अच्छी तरह परिभाषित मानदंड दिए जाएँ, तो अधिकांश लोग efficient code लिख सकते हैं.
  • दूसरे कमेंट का सार:

    • सोवियत programmers की क्षमता: सोवियत संघ से निकले लोगों के साथ काम करने के अनुभव से, सोवियत programmers के बेहतरीन होने की एक वजह यह थी कि computers तक उनकी पहुँच बहुत सीमित थी। उन्हें कागज़ और पेंसिल से programming करनी पड़ती थी, इसलिए शुरू से ही चीज़ों को सही चलाने की कोशिश होती थी.
  • तीसरे कमेंट का सार:

    • निजी workspace का महत्व: एक पुराने Hacker News thread में jrd259 अकाउंट की टिप्पणी का हवाला देते हुए, बड़े desk और notifications से मुक्त निजी workspace के महत्व पर ज़ोर दिया गया.
  • चौथे कमेंट का सार:

    • कागज़ पर programming का अनुभव: बचपन में दादा के घर पर computer के बिना typewriter से Turbo Pascal प्रोग्राम लिखे गए और बाद में PC पर चलाए गए। साथ ही, अपनी बनाई गई अनोखी programming language Ziim के binary addition function को कागज़ पर उतारकर bugs ढूँढने और ठीक करने का अनुभव साझा किया गया। इस बात पर ज़ोर है कि जब "आसान" तरीकों को सीमित किया जाता है, तो code ज़्यादा सोच-समझकर लिखा जाता है.
  • पाँचवें कमेंट का सार:

    • पुराने समय की programming: "big iron" के अंतिम दौर में programmers, data entry कर्मचारियों से बहुत अलग नहीं थे। प्रोग्राम कागज़ पर लिखे जाते थे, और compute time महँगा और कीमती था। अगर bug आता था, तो अगली CPU run शेड्यूल होने तक उसे ठीक नहीं किया जा सकता था। इससे सावधानीपूर्ण approach को बढ़ावा मिलता था। आज IDE में debugging करते हुए बार-बार दोहराव के साथ software development होता है.
  • छठे कमेंट का सार:

    • André Bensoussan द्वारा लिखा गया code: André Bensoussan द्वारा लिखे गए code का एक link दिया गया.
  • सातवें कमेंट का सार:

    • पुराने software का आकार: उस समय software आज की तुलना में बहुत छोटा होता था, और अधिकांश projects megabyte स्तर के होते थे, लेकिन फिर भी एक ही file में "सहेजने" के लिए बहुत बड़े होते थे.
  • आठवें कमेंट का सार:

    • स्कूल में programming assignment: एक दोस्त के अनुभव के अनुसार, स्कूल में programming assignments कागज़ पर जमा किए जाते थे और एक हफ़्ते बाद परिणाम मिलता था। एक हफ़्ते का "compile time" ऐसा शैक्षिक अनुभव था, जो काम को दोबारा जाँचने के लिए मजबूर करता था.
  • नौवें कमेंट का सार:

    • agile/scrum का अभाव: André ऐसा काम कैसे कर पाए, इस सवाल के जवाब में कहा गया कि तब तक agile/scrum development methodology की कल्पना ही नहीं की गई थी.
  • दसवें कमेंट का सार:

    • कागज़ पर coding का अनुभव: 14 साल की उम्र में हाई स्कूल की programming class में अधिकांश code कागज़ पर लिखा गया। एक गरीब देश के गरीब बच्चे होने के कारण घर पर PC नहीं था, और स्कूल के computer lab में मौजूद ZX Spectrum clones उस Turbo Pascal को नहीं चला सकते थे जिसका इस्तेमाल किया जाता था.