यह किया जा सकता है (2003)

 (multicians.org)
1 पॉइंट द्वारा GN⁺ 2024-02-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Honeywell Cambridge के Multics फाइल सिस्टम को नए सिरे से तैयार करने की प्रक्रिया में André Bensoussan ने मुख्य subsystem, VTOC manager, की जिम्मेदारी ली और design से लेकर testing तक किया
  • इस module को file description जानकारी को disk और memory के बीच ले जाना था, साथ ही buffer pool और disk space भी manage करना था, इसलिए यह असल में छोटे virtual memory manager जैसा था
  • André ने terminal के सामने सीधे coding करने के बजाय pencil से diagrams और code को refine किया, और state information को समेटते हुए भी symmetric design बनाने की कोशिश की
  • final manuscript input करने के बाद पहले compile में आई समस्याएं सिर्फ 3 typos थीं, और system में bind करके चलाने पर भी यह पहली कोशिश में सफल रहा
  • बाद में मिला bug सिर्फ एक था, जो Tom Van Vleck द्वारा error handling procedure के call order को गलत बताने से पैदा हुआ था, इसलिए program की अपनी completeness बहुत ऊंची थी

Multics VTOC manager पर काम

  • André Bensoussan ने Tom Van Vleck के साथ Honeywell Cambridge में Multics operating system पर काम किया
  • file system में बड़े बदलाव के लिए VTOC manager नाम का subsystem चाहिए था
    • file description जानकारी को disk और memory के बीच move करना
    • shared memory buffer pool manage करना
    • file information के लिए disk space manage करना
  • इन roles की वजह से VTOC manager को छोटे virtual memory manager की तरह काम करना पड़ता था
  • André ने इस module का design, implementation और testing संभाला

pencil से पूरा किया गया program

  • André पहले desk पर बैठकर कई diagrams बनाते थे
    • वे ऐसा रूप चाहते थे जो सारी state information समेटे और साथ ही देखने में अच्छा और symmetric हो
    • schedule की वजह से code लिखने में देरी को लेकर आसपास के लोग चिंतित होने लगे थे
  • coding भी terminal पर नहीं, बल्कि pencil से की गई
    • typing में मदद लेने से मना किया
    • कुछ हिस्से फिर से लिखे, नकल करके उतारे, मिटाए और सुधारकर final manuscript बनाया
  • final pencil manuscript को terminal में पूरा input करने के बाद पहला compile fail हुआ, लेकिन 3 typos ठीक करने के बाद compile सफल हो गया
  • system में bind करके चलाने पर यह पहली कोशिश में काम करने लगा, और बाद में VTOC manager लगातार perfectly काम करता रहा
  • मिला हुआ इकलौता bug इस वजह से था कि André ने error handling procedure के call order के बारे में पूछा था और Tom Van Vleck ने check किए बिना अंदाजा लगाकर बता दिया
    • पहली बार उस error path पर जाने पर crash हुआ
    • इसके अलावा program में कोई समस्या नहीं थी

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-02-13
Hacker News की राय

  • मुझे लगता है कि वह ऐसा मुख्य रूप से इसलिए कर पाए क्योंकि requirements बहुत स्पष्ट रूप से define किए गए थे
    आज software के buggy और slow होने की बड़ी वजह यह है कि असल में क्या बनाया जा रहा है, यह किसी को पता नहीं होता, या पता भी हो तो “agile” की वजह से वह लगातार बदलता रहता है
    developer को स्पष्ट API और अच्छी तरह define किए गए criteria दे दें, तो ज़्यादातर लोग बहुत अच्छी तरह चलने वाला code लिखते हैं

    • सुनने में कड़वी सच्चाई यह है कि वह इसलिए कर पाए क्योंकि वे खुद domain expert थे
      requirements का मतलब list और tickets को Kanban board पर सजाना नहीं, बल्कि जिस चीज़ को बनाना है उसके domain को सच में सीखना है
      जिस क्षेत्र को आप समझते नहीं, उसमें भी कुछ बनाया जा सकता है, लेकिन outcome अक्सर कचरा बनने की संभावना रखता है; और अगर उस कचरे को लिखने की प्रक्रिया को domain problem और संभावित solutions सीखने के draft के रूप में लिया जाए, तो ठीक है
      quality के लिए कोई shortcut नहीं होता
      अगर आप stakeholder हैं, तो application बनाने वाले व्यक्ति तक आपकी पहुंच होनी चाहिए, और आपको यह verify करना चाहिए कि वे domain समझते हैं। यह उन्हें लगातार परेशान किए बिना भी किया जा सकता है
      buzzwords उछालने वाले bluffers से सावधान रहना चाहिए
      अगर आप designer और programmer हैं, तो यह सुनिश्चित करना चाहिए कि stakeholders और domain experts सक्रिय और engaged हैं। वरना requirements और understanding निकालना दांत खींचने जितना मुश्किल हो जाता है
      कुछ stakeholders problem solve करना चाहते ही नहीं हो सकते, या वे पूरी तरह अलग दिशा चाहते थे, या political वजहों से खफा हो सकते हैं। आलसी या उदासीन stakeholder जितना project को डुबोता है, उतना शायद ही कुछ और
    • पूरी तरह सहमत। समस्या आम तौर पर यह होती है कि project planning बहुत खराब तरीके से की जाती है
      stakeholders को खुद नहीं पता होता कि वे क्या चाहते हैं, फिर भी वे random तरीके से extra features या बड़े changes मांगते हैं
      इस tool से जो काम नहीं होने चाहिए, उन्हें भी जबरन कराने की वजह से ढेरों exception handling की ज़रूरत पड़ती है
      designers अक्सर ऐसा design बना देते हैं जो needed features, existing system behavior, और stakeholders की demands से टकराता है, और system के अलग-अलग हिस्से बनाने वाली teams ठीक से communication किए बिना silos में बनाती हैं
      खराब तरीके से design किया गया “agile” process संदिग्ध point estimation के आधार पर हर चीज़ को एक तय अवधि में ठूंसने की कोशिश करता है
      आखिर में ये समस्याएं system को intended तरीके से काम न करने देतीं या उसे bugs का ढेर बना देती हैं
      अगर ऐसा environment बनाया जाए जहां requirements स्पष्ट हों और बदलें नहीं, project members अच्छी तरह communicate करें और process पर पूरा control हो, तो चीज़ें ठीक चलती हैं। मूल लेख का मामला भी ऐसा ही दिखता है
    • इसके ऊपर हज़ारों special cases जुड़ जाते हैं, और कई बार उन्हें करना अनिवार्य होता है, भले ही उन्हें code में implement करने का कोई खास मतलब न हो
      मैं ज़्यादातर large companies में काम करता हूं, और आने वाले काम का 90–99% average case होता है
      लेकिन अनगिनत unicorn जैसे special cases होते हैं जो तीन साल में एक बार होते हैं, वह भी तब जब lunar eclipse और solar eclipse साथ हो रहे हों और जंगल में witches मंत्र पढ़ रही हों
      ऐसे cases को manual तरीके से handle करने के बजाय code में implement करना पड़ता है, इसलिए bugs आते हैं और review व maintenance के लिए code बहुत बढ़ जाता है
      maintenance की बात शुरू भी न करें। वह दर्दनाक हिस्सा है
    • अगर आपको लगता है कि “agile” की वजह से requirements बदलती हैं, तो समझ नहीं आता क्या कहूं
      requirements हमेशा बदलती हैं। यह प्रकृति की शक्ति जैसा है, और ऐसा कोई world नहीं है जहां सबको शुरू से पता हो कि क्या बनाना है, पूरी तरह specified API मिल जाए और फिर cave में जाकर सिर्फ implementation करनी हो
      reality कभी ऐसे काम नहीं करती, और अगर आपको ऐसी conditions चाहिए, तो software engineering आपके लिए सही पेशा नहीं है
    • मैं साधारण और boring desktop software बना रहा हूं, और सभी नहीं तो ज़्यादातर bugs उन edge cases से आते हैं जहां users “बेवकूफी” वाली चीज़ें करते हैं, यानी बिल्कुल unexpected behavior करते हैं
      अगर users न हों, तो मेरा software perfect होता ;)

  • मैंने Soviet Union से defect करके आए एक व्यक्ति के साथ काम किया था। उनका कहना था कि Soviet programmers इतने अच्छे इसलिए थे क्योंकि computers तक access बहुत सीमित था
    अगर आपको pencil और paper से programming करनी पड़े, तो आप चाहेंगे कि program पहली run में ही काम करे
    संयोग से, हम Honeywell में काम कर रहे थे

    • एक और interpretation भी संभव है। शायद केवल वही बहुत committed लोग आगे भी काम करते रहे जो paper पर काम करने और limited computer access वाले environment को झेलने के लिए तैयार थे
      तो क्या यह अच्छी education method थी, या कम motivated लोगों को छांटने वाला अच्छा filter?
    • इसकी गवाही मैं दे सकता हूं। university instructor ने programming assignment दिया और solution समझाते हुए paper पर solution की outline लिखना शुरू किया
      school में class के दौरान computers use नहीं कर सकते थे, इसलिए paper पर programming और यहां तक कि debugging करने की आदत थी
      घर पहुंचकर मैंने इसे type किया और run किया, और सोचा कि क्या पहले पढ़े गए Multics anecdote को recreate कर पाऊंगा
      पहला compile fail हुआ, लेकिन एक variable name ठीक करने के बाद यह perfect काम करने लगा
    • मैंने उन computers पर सीखा जहां cards और printouts ही input/output system थे
      कुछ सालों तक मुझे याद है कि edit→compile→print loop में terminal की तुलना में listing output कहीं बेहतर था। क्योंकि code को efficiently देखना, navigate करना और modify करना मुश्किल था
      बेहतर visual editors, बड़े terminals, और तेज compile व execution आने के बाद आखिरकार सुधार हुआ
      analogy के तौर पर यह early firearms जैसा है। गीला gunpowder, unstable flintlock ignition, और barrel में सब कुछ ठूंसने की जरूरत के कारण longbow से transition का दौर inefficient था
    • high school में COBOL सीखते समय ज्यादातर काम pen और paper से किया था। school lab में हर student के लिए पर्याप्त PCs नहीं थे, इसलिए एक computer 3–4 लोगों को share करना पड़ता था
    • तो फिर वे उन privileged लोगों में से रहे होंगे जिन्हें pencil और paper तक access था

  • इस लेख के पिछले HN thread में André के साथ काम कर चुके jrd259 account का अच्छा comment है: https://news.ycombinator.com/item?id=18415231
    यह चौड़ी desk और notifications से मुक्त private workspace की अहमियत से जुड़ा है

  • मेरी ज़िंदगी में दो बार कागज़ पर programming करने की याद आती है
    पहली बार तब था जब मैं करीब 10–12 साल का था। मैं अपने दादा-दादी के घर गया था, जहाँ न computer था न smartphone, लेकिन एक mechanical typewriter था जिसमें switch से काला और लाल रंग बदलकर टाइप किया जा सकता था
    उस समय मेरा मुख्य शौक Turbo Pascal था, इसलिए मैंने typewriter पर एक Pascal program लिखा, जिसे बाद में घर लौटकर PC में डालकर run करना था
    दादा-दादी के घर मैं एक हफ्ते रहा, इसलिए सोचने, हाथ से debugging करने और गलत हिस्सों को फिर से type करने के लिए काफी समय था
    दूसरी बात मेरी बनाई हुई esoteric programming language Ziim(https://esolangs.org/wiki/Ziim) और उस page के binary addition function से जुड़ी है
    वह function बहुत बड़ा और complex था, और उसमें bug था। interpreter में run करके मुझे पता था कि bug है, लेकिन समस्या कहाँ है और उसे कैसे ठीक करना है, यह नहीं पता था
    तभी मुझे लगभग 6 घंटे की लंबी bus यात्रा करनी पड़ी, और यह debugging के लिए perfect मौका था
    मैंने Ziim addition function को pencil से graph paper पर उतारा और bus में उसे step-by-step हाथ से execute किया। मैं bug ढूँढकर ठीक कर पाया, और function की layout पूरी तरह फिर से करनी पड़ी
    इससे शायद यह सबक मिलता है कि आसान तरीके से काम करने की अपनी क्षमता को जानबूझकर सीमित करना कभी-कभी अच्छी तरह सोचे-समझे code तक पहुँचा सकता है
    फिर भी मैं आम तौर पर ऐसा नहीं करता। मैं झटपट snippet लिखकर iterate करता हूँ, या debugger में line-by-line चलाने लगता हूँ। शायद इस पर फिर से सोचना चाहिए

    • आम तौर पर हम ज़्यादातर सोच दिमाग में ही करते हैं, इसलिए कभी-कभी कागज़ और pen से गहराई से सोचते समय सिर्फ महत्वपूर्ण बातें लिखने और बाकी को दिमाग में बनाए रखने की अनुशासन और सावधानी पैदा होती है
      लेकिन अगर हर काम कागज़ पर किया जाए, तो अंत में वह computer पर सीधे करने से बहुत अलग नहीं रह जाता। आप सब कुछ लिखने लगते हैं, और वह abstraction और सावधानी खो देते हैं

  • जब मैंने शुरुआत की थी, वह “बड़े computers” वाले दौर का आखिरी समय था
    पुराने समय में “programmer” अक्सर data entry clerk जैसा होता था, और कई बार महिलाएँ होती थीं
    software लिखने वाले लोग cigarette के धुएँ से भरे offices में कागज़ पर programs लिख रहे होते थे
    computing time महँगा और दुर्लभ था। run करते समय bug आ जाए, तो उसे ठीक करने का मौका तब तक नहीं मिलता था जब तक फिर से data entry time और CPU execution time न मिल जाए
    इसलिए दो बार नापो, एक बार काटो वाला approach बढ़ावा पाता था
    उस समय का ज़्यादातर software, आज जिन चीज़ों को हम सामान्य मानते हैं, उनकी तुलना में काफी सरल था, इसलिए ऐसा करना आसान था। साथ ही software का input/output बेहद सीमित था, UI शब्द तक नहीं था, और peripheral device जोड़ना बड़ा काम था
    आजकल software लिखते समय अक्सर “दीवार पर फेंको और देखो क्या चिपकता है” जैसा तरीका अपनाया जाता है। आधा-अधूरा code लिखकर IDE में debug करना ज़्यादा आसान है
    मेरा software development काफ़ी iterative है, और मैंने यहाँ इसके बारे में लिखा है: https://littlegreenviper.com/miscellany/evolutionary-design-...

    • बात बिल्कुल यही है। हम पुराने दिनों को याद करके अफसोस करते हैं जब code लिखने से पहले software के बारे में बहुत सोचना पड़ता था, लेकिन सच यह है कि आज वैसा ही programmer iterative development से वही program शायद आधे समय में बना सकता था
      मुझे याद है कि university assignment में एक छोटा operating system kernel लिखना था
      मुझे C भी ठीक से नहीं आती थी और kernel क्या करता है, यह भी theory से आगे नहीं मालूम था, लेकिन task management के लिए C code की कुछ सौ lines लिखनी थीं
      मुझे लगा कि अगर यह program नहीं चला तो parallel code होने की वजह से debug करने का लगभग कोई तरीका नहीं होगा, और bugs अज्ञात race conditions के रूप में सामने आएँगे
      मैंने पूरे system के बारे में reasoning की, और कई दिनों तक छोटे-छोटे independent functions पर बहुत सोचकर उन्हें लिखा
      फिर compile करके run किया, और स्वाभाविक “semicolon missing” compile error ठीक करने के बाद यह पहले run में ही काम कर गया

  • जब भी कोई प्रभावशाली उपलब्धि post होती है, comments ज़्यादातर उसमें कमी निकालते हैं। अब बस भी करें

    • modern developers निराश हैं। वे अब कोई महत्वपूर्ण या अर्थपूर्ण काम नहीं करते
      वे किसी नए operating system के लिए virtual memory manager design करने वाले लोग नहीं, बल्कि बच्चों और बुज़ुर्गों को ads दिखाने के लिए SQL queries को HTML में बदलने वाली machine के छोटे gears भर हैं
      cynic और bitter होना स्वाभाविक है
    • जब भी कोई counterargument डालता है, लोग उसमें कमी निकालते हैं। बस करें?
      असल में ऐसा नहीं करना चाहिए। discussion का मतलब ही यही होना चाहिए
      कुछ हद तक यह सही है, लेकिन इसे सकारात्मक दिशा में मोड़ने वाला बेहतर सवाल यह है: आज के company environment में हम वैसी ही उपलब्धि संभव होने की स्थिति तक कैसे पहुँच सकते हैं?
    • मैं इस attitude को समझता हूँ, लेकिन जब मैंने यह post करने के 5 घंटे बाद वापस देखा, तो top comments सभी काफी positive थे और कमी निकालने वाले नहीं थे
      ऐसी प्रतिक्रिया देखने पर आम तौर पर यही होता है। user moderation वाली छन्नी को बेहतर comments ऊपर लाने में बस थोड़ा समय लगता है
    • लेकिन आप समझ नहीं रहे। मुझे एक बार chart.js 3 को chart.js 4 से replace करना पड़ा था, और documentation में सभी changes cover नहीं थे
      अगर इस व्यक्ति ने मेरी जैसी challenge का सामना किया होता, तो वह वहीं ढह जाता

  • उस समय software बहुत छोटा होता था
    आजकल toy program से थोड़ा भी बड़ा होते ही ज़्यादातर project megabyte scale के हो जाते हैं, और उन्हें एक single file में “लिखते चले जाना” संभव नहीं है

    • code खुद देखकर देखें: https://multicians.org/vtoc_man.html
      यह आज ज्यादातर लोग जिस पर काम करते हैं, उससे बड़ा और ज़्यादा जटिल है। आज का बहुत-सा काम CRUD/REST जैसी चीज़ों को जोड़ने वाला बढ़ा-चढ़ाकर बनाया गया glue code ही है
      यह पूरे project की code lines से छोटा हो सकता है, लेकिन लोग जिस unit से निपटते हैं उससे बड़ा है। ऊपर से यह भी पूरे operating system code का सिर्फ़ एक हिस्सा है
      यह “file description information manage करने वाले manager” का पूरा हिस्सा है। इसे file information को disk और memory के बीच ले जाना था, shared memory buffer pool manage करना था, और उस information के लिए disk space भी manage करनी थी
      आज के ज़्यादातर programmers से कहकर देखें कि वे अपनी चुनी हुई language में आज ही वही requirements और semantics वाली चीज़ लिखें
      ज़्यादातर लोग उसे कल्पना करने के स्तर पर ही रास्ता भटक जाएंगे। कागज़ पर लिखकर type करना और चलाना तो और भी कठिन है
    • उल्टा, reference examples लगभग थे ही नहीं। उनके operating system intro course में virtual memory lecture नहीं था। इन लोगों ने operating system design में नए रास्ते बनाए
    • माफ़ कीजिए, लेकिन हममें से ज़्यादातर लोग जिस business software पर काम करते हैं, वह file system के major component को scratch से लिखने से ज़्यादा impressive नहीं है
    • यह जानकर हैरानी हुई कि पिछले एक महीने में electronics notes में लिखे natural-language notes पहले ही 0.25 megabyte, लगभग 37,000 words के Markdown हो चुके हैं
      उसका एक छोटा हिस्सा electronic component URLs है, लेकिन करीब 90% सिर्फ़ English text है। और 10% दूसरे लोगों के लेखों, webpages, manufacturer application notes, किताबों आदि से quotes हैं
      यह single file है, और शायद इस साल के बाकी समय तक ही नहीं, आगे भी single file ही रहेगा। इसी गति से चला तो 12 megabyte हो जाएगा। यह बिल्कुल असंभव नहीं है
      रुचि हो तो git clone http://canonical.org/~kragen/sw/leatherdrink.git कर सकते हैं
      अभी avr toolchain commit किया हुआ है, इसलिए यह लगभग 200 megabyte है, और इसमें photos, videos, schematics जैसी चीज़ें भी हैं
      programming language होती तो monthly byte growth कम होती, लेकिन शायद पाँच गुना तक का फर्क हो सकता है

  • André Bensoussan ने जो code लिखा था, वह यहाँ है: https://multicians.org/vtoc_man.html

    • “उन्होंने यह कैसे किया होगा?” का जवाब साफ़ है। आधुनिक मानकों से देखें तो यह कोई बहुत जटिल काम नहीं था
    • मैंने PL/1 बहुत ज़्यादा नहीं देखा है, लेकिन control flow को छोड़ दें तो syntax हैरान करने वाली हद तक साफ़-सुथरा लगता है

  • काम शुरू करने के लिए desk पर बैठकर वह टालता आ रहा काम खत्म करने ही वाला था कि जाहिर है, मन भटक गया और reddit या HN पर news देखने की इच्छा हुई
    HN खोला तो पहला title यही था
    “कर सकते हो”
    motivation मिली
    P.S.: हाँ, article भी पढ़ा :)

  • “André ने pencil के अलावा किसी tool के बिना यह कैसे किया होगा?”
    14 साल की उम्र में जब मैं high school गया, programming class में ज़्यादातर code कागज़ पर लिखा जाता था
    मैं एक गरीब देश का गरीब बच्चा था, और घर में PC होना तो दूर, school computer lab के कुछ “computers” भी उस समय इस्तेमाल हो रही programming language Turbo Pascal चला नहीं पाते थे; वे ZX Spectrum clones थे