COBOL के लंबे समय तक “मृत” बने रहने पर दादा का रिकॉर्ड

 (wumpus-cave.net)
1 पॉइंट द्वारा GN⁺ 2024-10-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • जून 1992 में Technical Support पत्रिका में प्रकाशित लेख ने पहले ही COBOL की मृत्यु की घोषणा कर दी थी, लेकिन मुख्य बात यह है कि 30 साल बाद भी यह भाषा पूरी तरह गायब नहीं हुई
  • उस समय के 4GL जैसे buzzwords में से ज़्यादातर लंबे समय तक नहीं टिके, लेकिन COBOL कई बाद के विकल्पों से ज़्यादा समय तक टिका रहा
  • COBOL को चलते रहने देने वाला निर्णायक मोड़ Y2K समस्या थी, और वास्तविक प्रतिक्रिया में COBOL programmers की एक नई पीढ़ी को train करना पड़ा
  • जिस भाषा का installed base कभी बड़ा रहा हो, वह अचानक गायब होने के बजाय नए learners के घटने के साथ एक long tail छोड़ते हुए बनी रह सकती है
  • लेखक के दादा का 1 सितंबर 2024 को 91 वर्ष की उम्र में निधन हुआ, और यह लेख निजी स्मरणों और पुराने तकनीकी पूर्वानुमानों को साथ-साथ रखता है

1992 में ही आ चुकी “मृत COBOL” की घोषणा

  • लेखक के दादा ने जून 1992 में Technical Support पत्रिका में COBOL की मृत्यु घोषित करने वाला लेख प्रकाशित किया
  • उस लेख में 4GL जैसे उस दौर के शब्द आते हैं, और लेखक जोड़ता है कि Wikipedia की 4GL उदाहरण सूची में मौजूद कई चीज़ों से ज़्यादा लंबे समय तक COBOL जीवित रहा
  • मूल टेक्स्ट NaSPA archive में उपलब्ध है: http://www.naspa.net/magazine/1992/t9206003.txt
  • 1992 का लेख “dead” शब्द के अर्थों को अलग-अलग समझाते हुए COBOL को मृत लेकिन गायब न हुई Zombie जैसी चीज़ के रूप में देखता है
    • Autocoder को भी COBOL के पूर्वज के रूप में पेश किया गया है, और उसकी तुलना ऐसे उदाहरण से की गई है जिसे मृत भाषा माना जाता है लेकिन जिसके कुछ निशान अब भी बचे हो सकते हैं

Y2K ने COBOL को लंबी उम्र दी

  • COBOL zombie को चलते रहने देने वाला बड़ा कारण Y2K समस्या थी
    • उस समय खबरों में इसे बहुत उछाला गया था और बाद में ऐसा लगा जैसे कुछ हुआ ही नहीं, लेकिन असल में यह एक बहुत बड़ा मुद्दा था
    • इससे निपटने की प्रक्रिया में COBOL programmers की नई पीढ़ी को train करना पड़ा
    • इस प्रक्रिया ने COBOL को और लंबे समय तक बनाए रखने में योगदान दिया हो सकता है
  • लेखक अब programming languages के लिए dead शब्द का इस्तेमाल ज़्यादा नहीं करता
    • जिस भाषा का कभी बड़ा installed base रहा हो, उसका पूरी तरह मरना मुश्किल है
    • इसके बजाय, जब नए programmers उसे सीखना बंद कर देते हैं, तो वह धीरे-धीरे धुंधली पड़ती हुई एक long tail छोड़ती है

निजी स्मरण से जुड़ता तकनीकी इतिहास का एक दृश्य

  • लेखक के दादा का 1 सितंबर 2024 को 91 वर्ष की उम्र में निधन हुआ
    • आधिकारिक मृत्यु-कारण pneumonia था
    • दादी का उसी साल अप्रैल में निधन हुआ था, और दादा ने इलाज न लेने का अनुरोध किया था

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

1 टिप्पणियां

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

  • लेख में 4GL का ज़िक्र है, और यह शब्द वाकई बहुत लंबे समय बाद सुनने को मिला
    COBOL ने भी यह वादा किया था कि “यह इंसानों द्वारा पढ़े जाने वाले वाक्यों जैसा दिखता है, इसलिए अब programmers की ज़रूरत नहीं रहेगी”, और यह आज के low-code platforms या LLM-generated code जैसा लगता है
    समस्या यह है कि आम तौर पर लोग किसी काम करने वाले समाधान तक पहुँचने लायक पर्याप्त विस्तार से समस्या को समझा और छोटे हिस्सों में बाँट नहीं पाते। अगर कोई यह प्रक्रिया कर लेता है, तो वह आखिरकार programmer ही बन जाता है, और COBOL का मुख्य सबक यह है कि programmers की ज़रूरत की वजह सिर्फ़ computer interface या language नहीं है

    • मोटे तौर पर सहमत हूँ, लेकिन मेरे हिसाब से COBOL “औसत व्यक्ति” के लिए नहीं बनाया गया था, बल्कि इसे गहरी domain knowledge रखने वाले लोगों के इस्तेमाल के लिए सोचा गया था
      यह ज़्यादा इस दिशा में था कि जो व्यक्ति business processes को अच्छी तरह समझता है, वह computers के काम करने का तरीका बहुत अधिक सीखे बिना उन्हें COBOL में लिख सके; कुछ-कुछ वैसा ही जैसे analysts या data लोग SQL के ज़रिए database से बात करते हैं
      COBOL और 4GL का मुख्य उद्देश्य payroll, banking, HR, inventory जैसे business applications बनाना था, और खासकर settlement जैसे दोहराए जाने वाले बड़े पैमाने के कामों को घटाने वाली batch processing पर फोकस था
      यह उस दौर की उपज था जब dedicated DBMS नहीं थे, इसलिए file organization और files से जुड़े verbs बहुत विकसित थे, और इसमें आज के SQL जैसी कुछ बातें भी दिखती हैं
    • मुझे लगता है कि “महंगे programmers की अब ज़रूरत नहीं” वाले LLM-based approach में भी यही मूलभूत सीमा है
      भले ही LLM जादू की तरह समाधान बना दे, समस्या को संक्षिप्त और सटीक रूप से व्यक्त करने की ज़िम्मेदारी बस ऊपर की ओर चली जाती है
      आखिरकार आप prompt के ज़रिए “programming” करते हैं, और LLM द्वारा सुझाए गए औपचारिक output, यानी code, की समीक्षा करते हैं। Programming का स्वरूप prompt engineering में बदल सकता है, लेकिन code नाम की formal language को समझने का काम बना रहता है
    • 4GL एक ऐसा चलन था जिसमें general logic, simple data structures और arithmetic से आगे की चीज़ों को संभालने के लिए language में natural language जैसी संरचनाएँ और जोड़ने की कोशिश की गई
      लेख कहता है कि 1990 के शुरुआती दशक में 4GL बहुत popular था, लेकिन मुझे शक है कि mainframe के बाहर भी ऐसा था या नहीं। 4GL movement शुरुआत से ही काफ़ी mainframe-oriented था, और Wikipedia भी इसके शुरुआती लक्ष्य के रूप में program के लिए ज़रूरी punched cards की संख्या घटाने का ज़िक्र करता है
      1992 तक Linux आ चुका था, Python पर भी काम चल रहा था, Perl लोकप्रिय हो रहा था और Haskell का शुरुआती version भी आ चुका था। Technology का front महंगे workstations से consumer PCs की ओर जा रहा था, और language designers ने dBase, HyperTalk, AppleScript जैसी चीज़ें बनाते समय—जिन्हें नतीजे के तौर पर 4GL माना जा सकता है—4GL concept को बहुत ज़्यादा ध्यान में रखा हो, ऐसा नहीं लगता
      मैं इस बात से सहमत हूँ कि natural language जैसा text ज़्यादातर programming उपयोगों के लिए खराब idea है, लेकिन मुझे नहीं लगता कि 4GL movement की असफलता की वजह सिर्फ़ यही थी। ज़्यादातर 4GL, 3GL COBOL से भी ज़्यादा natural language जैसे नहीं थे
      बड़ी समस्या यह थी कि 4GL movement ठीक से परिभाषित नहीं कर पाया कि नई generation क्या है और क्या उपयोगी है। 2GL ने assembly से machine code में translation, और 3GL ने compilation जैसा क्रांतिकारी बदलाव लाया, लेकिन 4GL में जो बदलाव कुछ हद तक परिभाषित किया जा सकता था, वह बस इतना था कि “जो capabilities external routines या libraries में थीं, उन्हें language के अंदर और डालें”
      यह approach domain-specific languages में अच्छा चला, इसलिए SQL, R, MATLAB जैसे सफल 4GL निकले। दूसरी ओर, general-purpose 4GL का concept अंततः बहुत ज़्यादा फूली हुई language में बदलना तय था
    • भले ही बहुत कुछ बदलता हुआ दिखे, आखिर में वही pattern दोहराया जाता है
    • “अब programmers की ज़रूरत नहीं” कहना चौंकाता है, लेकिन अगर उस समय programming का मतलब कागज़ पर सीधे machine code लिखकर उसे सही ढंग से चलाने की क्षमता था, तो यह बात कुछ हद तक सही हो सकती थी
      आज ऐसे लोग बहुत कम हैं जो ऐसा कर सकते हैं या जिन्हें ऐसा करना चाहिए

  • इस संदर्भ में Scala याद आता है। लेख में जिस तरह COBOL का वर्णन किया गया है, उसे देखते हुए मुझे लगता है कि Scala भी असल में लगभग मृत अवस्था के करीब है
    अभी भी कई कंपनियों और सेवाओं में Scala से लिखे core components हैं, लेकिन नए projects में इसकी दिलचस्पी काफी कम हो चुकी है
    2012~2014 में HN पर “Scala में X करना” जैसे लेख लगातार दिखते थे, अब लगभग नहीं दिखते। यह स्वाभाविक और टाला न जा सकने वाला बदलाव हो सकता है, लेकिन अफसोस इस बात का है कि Scala में ऐसी अच्छी बातें थीं जिन्हें दूसरी mainstream languages अभी भी ठीक से नहीं अपना पाई हैं

    • Apple की कुछ engineering teams मौजूदा systems को maintain करते हुए भी Scala के नए projects कर रही हैं
      testing systems जैसे कंपनी के ecosystem के लिए काफी अहम projects भी हैं, और पहले ऐसे systems बनाने वाले engineers अब ज्यादातर senior managers बन गए हैं
      कुछ लोग उस समय की tech choice का अब भी समर्थन करते हैं, लेकिन अगर उन्हें पीछे मुड़कर देखने का मौका दिया जाए तो कुछ लोग ज्यादा खुले रुख में दिखते हैं। कुल मिलाकर माहौल यह है कि अगर उस समय Kotlin मौजूद होता या Swift backend services के लिए इस्तेमाल करने लायक होता, तो शायद Scala नहीं चुना जाता
    • Scala अभी भी सक्रिय रूप से जिंदा है
      https://redmonk.com/sogrady/2024/09/12/language-rankings-6-2...
      शुरुआती hype ठंडा पड़ गया है, लेकिन यह ठीक है। हर language का एक hype cycle होता है, और predictions भी ज्यादातर गलत निकलते हैं। mainstream programming languages अब COBOL की तरह आसानी से मरना मुश्किल हैं
      Java को 2001 से मृत घोषित किया जा रहा था, लेकिन उसने dot-com bubble, .NET, LAMP का P, Ruby, JS और Go सब झेल लिए। Python के बारे में भी version 3 transition के समय कहा गया कि लोग Ruby में चले जाएंगे और यह मर जाएगा
      Scala दुनिया की सबसे लोकप्रिय functional programming language है, इसके tools और libraries अच्छे हैं, और मेरी नजर में Scala 3 एक शानदार upgrade है
    • मुझे लगता है कि आज का Perl, COBOL के ज्यादा करीब है
      कभी यह बेहद बड़ा था और हर जगह मौजूद लगता था, लेकिन अब धीरे-धीरे niche में सिमटता जा रहा है। COBOL की तरह, वास्तविक production environments में अब भी काफी Perl code बचा हुआ है
    • Writer में हम सभी नई services Scala में बना रहे हैं
      Jack Henry, SiriusXM, Starbucks, Disney streaming services, Capitol One ने भी पिछले 5 साल से अब तक data science नहीं, बल्कि services वाले हिस्से में Scala के नए projects बनाए हैं
      बेशक और भी बहुत सी teams हैं, लेकिन तुरंत याद आने वाले मशहूर नाम ही इतने हैं कि इसे मृत कहना मुश्किल है
      हालांकि Play, Akka-केंद्रित framework jobs और Airflow नहीं बल्कि pure Spark काम घटते दिखते हैं। मेरी नजर में ये Scala ecosystem से निकली framework jobs थीं, और कई मामलों में Scala खुद secondary था
    • Scala, COBOL की तरह मर नहीं सकता। वजह यह है कि वह शुरू से COBOL की तरह व्यापक रूप से जिंदा कभी था ही नहीं
      मुझे Scala पसंद है, लेकिन यह हमेशा एक हाशिये की language रहा है, जबकि COBOL सचमुच हर जगह था

  • कभी न कभी Fortran, COBOL, Ada, APL जैसी legacy languages को बैठकर खुद आजमाना चाहिए, ऐसा सोचता हूं
    इनकी लोकप्रियता जरूर घटी है, लेकिन ये अब भी अहम जगहों पर इस्तेमाल होती हैं
    साथ ही Java code की विशाल मात्रा भी याद आती है। अच्छा हो या बुरा, Java ने enterprise क्षेत्र को लगभग निगल लिया था, लेकिन सोचता हूं कि 30~40 साल बाद सिर्फ retired लोग पुराने banking systems maintain करने के लिए Java इस्तेमाल करते दिखेंगे, ऐसा होने की कोई खास वजह है क्या

    • COBOL का बचे रहना मुझे COBOL खुद की वजह से कम, और vendor/platform lock-in की वजह से ज्यादा लगता है
      शायद विशाल monolithic codebase या platform होना भी एक कारण है। language कोई बहुत रहस्यमयी या कठिन नहीं है, बस बहुत सारा ऐसा code है जिसकी structure साफ नजर नहीं आती
    • Ada, बाकी उदाहरणों की तुलना में एक order of magnitude ज्यादा modern और refined language है
      लगता है अगले 100 साल तक market का लगभग 0.05% हिस्सा तो इसके पास रहेगा
    • मैं एक Fortune 100 company का Android app develop करता हूं, और किसी ने Java file modify करने वाला आखिरी commit पिछले हफ्ते किया था
      हालांकि पिछले कुछ सालों में नया code ज्यादातर Kotlin में लिखा गया है
    • APL इतना अलग paradigm है कि इसे खुद अनुभव करना worthwhile है
      निजी तौर पर भी इससे लगाव है; 90s में कंपनी में इसे PC पर सचमुच इस्तेमाल किया था। काम यह पता लगाने का था कि data कैसे डाला जाए, और आखिर में floating-point numbers को 1 और 0 के vector की तरह treat करते हुए bits बदलकर Microsoft format से IEEE format में convert करने वाला routine लिखा था
      बेशक, यह उस जमाने की बात है जब मैं बेल्ट में प्याज बांधता था
    • अगर सिर्फ numerical computation करना हो तो Fortran काफी अच्छा इस्तेमाल होता है
      pure numerical simulation करनी हो तो मैं C++ या Python से ज्यादा Fortran पसंद करूंगा। NumPy को छोड़कर, क्योंकि NumPy खुद भी आखिरकार Fortran और C++ पर निर्भर है

  • 2025 Carolina Code Conference में अब भी COBOL speakers की तलाश है
    खासकर GnuCOBOL हाल में update हुआ है, इसलिए मैं कुछ समय से COBOL talk शामिल करना चाहता था
    https://gnucobol.sourceforge.io/
    https://carolina.codes

    • www.cobolworx.com. हम अपने काम के बारे में बात करने की जगह हमेशा खोजते रहते हैं

  • “मुझे नहीं पता कि साल 2000 की language कैसी दिखेगी, लेकिन उसका नाम Fortran होगा।” —Tony Hoare
    COBOL को जिंदा माना जा सकता है, क्योंकि यह हर दौर में बदलता रहा है। modern COBOL, लोगों के नाम सुनते ही सहज रूप से दिमाग में आने वाले 1950s के COBOL से काफी अलग है
    यह कुछ वैसा है जैसे Java को Algol-94 जैसा नाम दिया गया होता, और इसलिए हम कहते कि हम अब भी Algol में programming करते हैं

    • अब कोई भी MULTIPLY A BY B GIVING C ON SIZE ERROR STOP RUN. जैसी शैली में नहीं लिखता
    • Kemeny और Kurtz ने 1968 में ही Fortran को “पुराना” कहा था
      <https://dtss.dartmouth.edu/sciencearticle/index.html>
    • ज्यादा सटीक रूप से शायद यह “मुझे नहीं पता कि साल 2000 की language को क्या कहा जाएगा, लेकिन वह Fortran जैसी दिखेगी” के करीब हो सकता है
    • 2000 में यह लगभग सही बात थी, लेकिन अब नहीं। दुनिया धीरे-धीरे ही सही, बदलती है
    • लेकिन 70s, 80s, 90s के मौजूदा systems क्या सच में modern COBOL इस्तेमाल कर रहे हैं?

  • COBOL मरा नहीं है, लेकिन उस तक पहुँचना मुश्किल है। वजह यह है कि Linux पर इस्तेमाल किए जा सकने वाले open source tools बहुत कम हैं
    OCamlPro ने GnuCOBOL open source compiler को केंद्र में रखकर open source environment बनाने के लिए SuperBOL नाम का एक project शुरू किया है। GnuCOBOL पहले से mature है और कंपनियों में भी इस्तेमाल हो रहा है
    वे पहले ही COBOL के लिए LSP वाला VSCode extension जारी कर चुके हैं, जिससे आधुनिक IDE experience मिलता है, और ग्राहक मांगों के हिसाब से दूसरे tools पर भी काम कर रहे हैं

    • समस्या tools की accessibility से ज्यादा mainframe accessibility से जुड़ी है
      COBOL एक-दो दिन में सीखा जा सकता है और मैं “बोरिंग” COBOL काम आज़माना चाहता हूँ, लेकिन मेरे पास mainframe experience नहीं है
    • ऐसा भी है
      https://gnucobol.sourceforge.io/
      https://cobolworx.com/pages/cobforgcc.html

  • हमेशा की तरह, ऐसी चर्चा इस बात पर निर्भर करती है कि “मरा हुआ” और “ज़िंदा” को कैसे define किया जाता है
    अगर किसी technology पर नए business अब नहीं बनते, तो उसे मरा हुआ कहा जा सकता है—ऐसा मानें तो COBOL को मरा हुआ कहना गलत नहीं होगा। यही बात IBM 390x, यानी Z/OS platform, पर भी लागू होती है, जिसे आम तौर पर COBOL के proxy की तरह इस्तेमाल किया जाता है
    उल्टा, अगर operational environments में अभी भी इस्तेमाल होना ज़िंदा होने की कसौटी है, तो COBOL निश्चित रूप से ज़िंदा है, और अपने से युवा कई technologies से कहीं ज्यादा ज़िंदा है
    हालांकि इसे COBOL या mainframe ecosystem की खूबी मानने की जरूरत नहीं है। Organizations की प्रवृत्ति होती है कि जो चीज़ शुरुआत में अच्छी तरह काम करती है, उसे पकड़े रहें; और शुरुआती digitization के मुख्य खिलाड़ी रहे government, banks, airlines जैसी जगहों पर वह पहली पसंद अक्सर IBM mainframe और उसके ऊपर का software ही था

    • mainframe हटाना मुश्किल होने की वजह यह है कि mainframe-level की concurrent I/O throughput संभालने वाला कोई दूसरा platform असल में नहीं है
      हमारा mainframe प्रति घंटे 10 करोड़ transactions आराम से process करता है। ऊपर से ज्यादातर synchronous हैं, और हर transaction कई SQL transactions में बदलता है
      eventual consistency भी एक तरीका है, लेकिन finance sector के लिए यह बिल्कुल fit नहीं बैठती, और military, insurance, medical और healthcare में भी शायद ऐसा ही है। काम को partitions में बाँटा जा सकता है, लेकिन shard boundaries पार करते समय consistency issues पैदा होते हैं
      COBOL अभी मरा नहीं है, लेकिन धीरे-धीरे उसी दिशा में जा रहा है। मुझे ऐसा कोई bank नहीं पता जो mainframe से बाहर निकलने के लिए actively काम न कर रहा हो। फिर भी, देखे गए estimates कहते हैं कि mainframe और COBOL कम-से-कम 2050 तक बने रहेंगे
      यानी अगले 26 साल तक COBOL code लिखा जाएगा। COBOL programmers की demand भी ऊँची है और pay भी अच्छा है, इसलिए अभी COBOL programmer के तौर पर career शुरू करने पर भी लगभग पूरी working life जितना समय भरा जा सकता है
    • अगर नए business से मतलब सचमुच startup है, तो mainframe 60–70 के दशक में भी असल में उस तरह का market नहीं था
      entry barrier हमेशा बेहद ऊँचा था, और उस समय के मुख्य customers भी पुरानी insurance companies, banks, governments जैसी जगहें थीं। नई companies के लिए computing करना संभव होना minicomputers के बाद के दौर के ज्यादा करीब है
      इस मायने में बहुत कुछ बदला नहीं है, और product के target market को देखते हुए platform के जिंदा या मृत होने की कसौटी के रूप में “क्या नए business इसे इस्तेमाल करते हैं” मुझे उचित नहीं लगता
    • इस संभावना को नज़रअंदाज़ नहीं करना चाहिए कि banks या बड़े financial institutions ने अपने core workflows को COBOL standard बना रखा हो
      कोई नया business unit या internal startup team—मसलन नई insurance product category—भी अगर bank के बाकी systems के साथ integrate करना चाहे, तो उसका कुछ हिस्सा COBOL में लिखा जा सकता है
      कम-से-कम, सीधे COBOL में न लिखें तब भी, नए x86 racks और उन्हें manage करने वाले लोगों के लिए budget न होने के कारण उसे मौजूदा COBOL execution infrastructure, यानी Z/OS, पर चढ़ाया जा सकता है
    • COBOL undead है

  • Cloud नया mainframe है, लेकिन और खराब version। इसमें सारी कमियाँ हैं, पर सबसे बड़ा फायदा नहीं है
    पहले CICS से बेहद stable और high-performance services बनाई जा सकती थीं, और उसी transaction के अंदर दूसरी services को call किया जा सकता था। platform data integrity बनाए रखने जैसे जटिल काम संभाल लेता था
    एक बार उसी transaction के अंदर एक-दूसरे को call करने वाली AWS Lambda लिखकर देखें, फर्क साफ दिख जाएगा

    • “सारी कमियाँ हैं” से क्या मतलब single-vendor lock-in, भारी capital expenditure और operating costs, और ऐसी स्थिति से है जहाँ संबंधित technology जानने वाले लोगों को trained होना या experienced होना ही पड़ता है?
      और मुझे समझ नहीं आता कि तुलना “उसी transaction के अंदर एक-दूसरे को call करने वाली AWS Lambda” से क्यों है। क्या mainframe deployment भी developer को access दिए गए API पर code वाला .zip फेंकने जितना आसान था?

  • कुछ लोग इसे ऐसे समझकर आलोचना कर रहे हैं कि मैं आधुनिक भाषाओं की जगह COBOL चुनता या उसे पसंद करता हूं, लेकिन मेरा मतलब वह नहीं है। मैंने बस दायरे से बाहर जाकर devil's advocate वाली एक observation रखी थी
    विडंबना यह है कि Rust से ज्यादा पढ़ने और समझने में आसान, memory-safe और स्थिर भाषा COBOL के रूप में पहले से मौजूद थी। लेकिन कोई भी उसे इस्तेमाल करना नहीं चाहता, इसलिए वह “मरी हुई” भाषा बन गई, जबकि आधुनिक दौर को संभव बनाने वाले सिस्टम उसी पर चलते हैं
    उदाहरण के तौर पर, कोई संख्या input लेकर even/odd output करने वाले Rust code और COBOL code की तुलना करें, तो COBOL वाला ज्यादा सीधे तौर पर पढ़ा जाता है

    • अजीब नजरिया है। पुरानी भाषाओं के अच्छे features गायब होकर बाद की भाषाओं में फिर से खोजे जाते हैं, ऐसा होता है, लेकिन शक है कि COBOL सच में उन सारी समस्याओं को हल करता है जिन्हें Rust हल करना चाहता है
      क्या यह उसी स्तर की performance देता है, क्या यह दूसरी भाषाओं के native code के साथ उसी तरह interoperate करता है, क्या composition और backward compatibility में मदद करने वाले module system के ऊपर इस्तेमाल लायक package manager है, क्या Rust के algebraic data types की तरह data और errors के आकार को सुविधाजनक ढंग से व्यक्त कर सकता है—पता नहीं
      जैसे COBOL के अब भी इस्तेमाल होने की वजहें हैं, वैसे ही नई भाषाओं के बनाए जाने की भी अच्छी वजहें हैं
    • इन दोनों programs को comparable कहना थोड़ा अस्पष्ट है। COBOL version errors handle नहीं करता, जबकि Rust program कम से कम panic करके तो handle करता है
      असल में जरूरी boilerplate जोड़कर executable COBOL program बनाया जाए, तो abc input पर “even” और 12 input पर “odd” output करता है
      Rust syntax को खास तौर पर मुद्दा बनाना भी अजीब है। आजकल की ज्यादातर भाषाओं की तरह Rust भी broadly C-family syntax है, बस थोड़ा OCaml का असर मिला हुआ है। syntax से अलग, Rust और COBOL के लक्ष्य बहुत अलग हैं, इसलिए “बस COBOL इस्तेमाल कर लो” कहने से Rust के अस्तित्व की वजह खत्म नहीं होती
    • IBM docs का example दिखाता लगता है कि COBOL memory-safe भाषा नहीं है
      https://www.ibm.com/docs/en/cobol-zos/6.2?topic=statement-ex...
      ALLOCATE, pointer address सेट करना, FREE जैसे code दिखाई देते हैं
    • shell script भी memory-safe होती है, लेकिन 100 lines से ज्यादा का program उसमें न लिखने की वजह होती है
    • अजीब तुलना है। कोई developer जिसे computer के पास जाने देना ठीक हो, वह जहां Rust सही choice है वहां COBOL नहीं चुनेगा, और न ही इसका उलटा करेगा

  • यह tweet अजीब तरह से अच्छा लगा
    https://x.com/grauhut/status/1000017084435312642
    अनुवाद करें तो मतलब है: “customer site पर COBOL मिला। ठीक है। mainframe है। कोई खास बात नहीं। आखिरी comment 1985 का था। author मेरी मां थीं।”