บันทึกของคุณปู่เกี่ยวกับการที่ COBOL “ตาย” มานานแล้ว

 (wumpus-cave.net)
1 คะแนน โดย GN⁺ 2024-10-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • บทความที่ตีพิมพ์ในนิตยสาร Technical Support เดือนมิถุนายน 1992 ได้ประกาศ การตายของ COBOL ไปแล้ว แต่ประเด็นสำคัญคือแม้เวลาจะผ่านไป 30 ปี ภาษานี้ก็ยังไม่ได้หายไปอย่างสิ้นเชิง
  • คำฮิตในยุคนั้นอย่าง 4GL ส่วนใหญ่ไม่อยู่ยืนยาว แต่ COBOL กลับเป็นกรณีที่อยู่รอดได้นานกว่าทางเลือกที่ตามมาทีหลังจำนวนมาก
  • จุดเปลี่ยนสำคัญที่ทำให้ COBOL ยังเดินหน้าต่อได้คือ ปัญหา Y2K และการรับมือจริงก็จำเป็นต้องฝึกโปรแกรมเมอร์ COBOL รุ่นใหม่ขึ้นมา
  • ภาษาที่เคยมีฐานการติดตั้งขนาดใหญ่ อาจไม่หายไปอย่างฉับพลัน แต่คงอยู่ต่อได้ในรูปของ หางยาว ที่มีผู้เรียนใหม่ลดลงเรื่อยๆ
  • คุณปู่ของผู้เขียนเสียชีวิตเมื่อวันที่ 1 กันยายน 2024 ด้วยอายุ 91 ปี และบทความนี้ก็ซ้อนทับทั้งความทรงจำส่วนตัวกับคำทำนายทางเทคโนโลยีในอดีต

คำประกาศว่า “COBOL ตายแล้ว” ที่มีมาตั้งแต่ปี 1992

  • คุณปู่ของผู้เขียนได้ตีพิมพ์บทความในนิตยสาร Technical Support ฉบับเดือนมิถุนายน 1992 เพื่อประกาศการตายของ COBOL
  • ในบทความตอนนั้นมีคำตามยุคสมัยอย่าง 4GL ปรากฏอยู่ และผู้เขียนก็เสริมว่า COBOL อยู่รอดได้นานกว่าหลายรายการในรายชื่อตัวอย่าง 4GL บน Wikipedia
  • ข้อความต้นฉบับยังคงอยู่ในคลัง NaSPA: http://www.naspa.net/magazine/1992/t9206003.txt
  • บทความปี 1992 แยกความหมายของคำว่า “dead” ออกเป็นหลายแบบ และมองว่า COBOL เป็นสิ่งมีชีวิตแบบ Zombie ที่ตายแล้วแต่ยังไม่หายไป
    • Autocoder ก็ถูกยกขึ้นมาในฐานะภาษารุ่นก่อนของ COBOL และเปรียบเทียบว่าเป็นภาษาที่ถือว่าตายแล้ว แต่ยังอาจมีร่องรอยบางส่วนหลงเหลืออยู่

อายุอันยืนยาวของ COBOL ที่ Y2K เป็นผู้สร้าง

  • ปัจจัยสำคัญที่ทำให้ซอมบี้ COBOL ยังเคลื่อนไหวต่อได้คือ ปัญหา Y2K
    • ตอนนั้นเป็นประเด็นใหญ่ในข่าว และภายหลังอาจดูเหมือนไม่มีอะไรเกิดขึ้น แต่จริงๆ แล้วมันเป็นปัญหาใหญ่โตมาก
    • ในกระบวนการรับมือ จำเป็นต้องฝึกโปรแกรมเมอร์ COBOL รุ่นใหม่ขึ้นมา
    • กระบวนการนี้อาจมีส่วนช่วยให้ COBOL อยู่ต่อได้นานขึ้น
  • ทุกวันนี้ผู้เขียนแทบไม่ใช้คำว่า dead กับภาษาโปรแกรมแล้ว
    • ภาษาที่เคยมีฐานติดตั้งขนาดใหญ่ ยากที่จะตายอย่างสมบูรณ์
    • แต่จะทิ้ง หางยาว ไว้แทน โดยมีโปรแกรมเมอร์หน้าใหม่เรียนรู้น้อยลงเรื่อยๆ และค่อยๆ เลือนหายไป

ฉากหนึ่งของประวัติศาสตร์เทคโนโลยีที่ต่อเนื่องสู่ความทรงจำส่วนตัว

  • คุณปู่ของผู้เขียนเสียชีวิตเมื่อวันที่ 1 กันยายน 2024 ด้วยอายุ 91 ปี
    • สาเหตุการเสียชีวิตอย่างเป็นทางการคือปอดบวม
    • คุณย่าเสียชีวิตไปก่อนในเดือนเมษายนปีเดียวกัน และคุณปู่ก็ขอไม่รับการรักษา

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-10-02
ความคิดเห็นจาก Hacker News

  • บทความพูดถึง 4GL ซึ่งเป็นคำที่ไม่ได้ยินมานานมากจริง ๆ
    COBOL ก็เคยให้คำมั่นว่า “ดูเหมือนประโยคที่คนอ่านได้ จึงจะไม่ต้องมีโปรแกรมเมอร์อีกต่อไป” และเรื่องนี้คล้ายกับแพลตฟอร์ม low-code หรือโค้ดที่ LLM สร้างในยุคนี้
    ปัญหาคือคนทั่วไปมักไม่สามารถอธิบายและแตกปัญหาให้ละเอียดพอจนได้วิธีแก้ที่ทำงานได้ หากทำกระบวนการนั้นได้ สุดท้ายก็เท่ากับกลายเป็นโปรแกรมเมอร์อยู่ดี และบทเรียนสำคัญของ COBOL คือเหตุผลที่ต้องมีโปรแกรมเมอร์ไม่ได้มาจากอินเทอร์เฟซคอมพิวเตอร์หรือภาษาเพียงอย่างเดียว

    • โดยรวมเห็นด้วย แต่ผมมองว่า COBOL ไม่ได้ถูกสร้างมาให้ “คนทั่วไป” ใช้ แต่ตั้งใจให้ คนที่มีความรู้เชิงโดเมนลึก ใช้มากกว่า
      มันใกล้เคียงกับการทำให้คนที่รู้กระบวนการธุรกิจดีสามารถถ่ายทอดสิ่งนั้นเป็น COBOL ได้ โดยไม่ต้องเรียนรู้การทำงานของคอมพิวเตอร์มากนัก และมีส่วนคล้ายกับนักวิเคราะห์หรือคนดูแลข้อมูลที่คุยกับฐานข้อมูลผ่าน SQL
      COBOL และ 4GL มีเป้าหมายหลักในการสร้าง แอปพลิเคชันธุรกิจ เช่น เงินเดือน ธนาคาร บุคคล และสินค้าคงคลัง โดยเฉพาะเน้นการประมวลผลแบบแบตช์เพื่อลดงานปริมาณมากที่ทำซ้ำ ๆ อย่างการกระทบยอด
      มันเป็นผลผลิตของยุคที่ยังไม่มี DBMS เฉพาะทาง จึงมีโครงสร้างไฟล์และกริยาที่เกี่ยวกับไฟล์พัฒนาไปมาก และก็มีส่วนที่คล้ายกับ SQL ในปัจจุบันด้วย
    • รู้สึกว่าแนวทางที่ใช้ LLM ซึ่งบอกว่า “ไม่ต้องมีโปรแกรมเมอร์ราคาแพงอีกต่อไป” ก็มี ข้อจำกัดพื้นฐาน แบบเดียวกัน
      ต่อให้ LLM สร้างวิธีแก้ได้ราวกับเวทมนตร์ ความรับผิดชอบในการอธิบายปัญหาให้กระชับและแม่นยำก็แค่ถูกเลื่อนขึ้นไปชั้นบนเท่านั้น
      สุดท้ายเราก็ “เขียนโปรแกรม” ด้วยพรอมป์ต์ และต้องตรวจสอบโค้ดซึ่งเป็นผลลัพธ์แบบเป็นทางการที่ LLM เสนอมา ลักษณะของการเขียนโปรแกรมอาจเปลี่ยนไปเป็น prompt engineering ได้ แต่ภารกิจในการเข้าใจโค้ดซึ่งเป็นภาษาทางการก็ยังคงอยู่
    • 4GL เป็นกระแสที่พยายามใส่ โครงสร้างที่คล้ายภาษาธรรมชาติ เข้าไปในภาษาให้มากขึ้น เพื่อรับมือกับสิ่งที่มากไปกว่าตรรกะทั่วไป โครงสร้างข้อมูลง่าย ๆ และเลขคณิต
      ในบทความบอกว่า 4GL เป็นกระแสฮิตมากในช่วงต้นทศวรรษ 1990 แต่ผมสงสัยว่านอกเมนเฟรมจะเป็นเช่นนั้นจริงหรือไม่ ขบวนการ 4GL มุ่งไปทางเมนเฟรมอย่างชัดเจนมาตั้งแต่แรก และวิกิพีเดียก็กล่าวถึงเป้าหมายแรกเริ่มว่าเป็นการลดจำนวนบัตรเจาะรูที่จำเป็นสำหรับโปรแกรม
      พอถึงปี 1992 Linux ก็ออกมาแล้ว งานพัฒนา Python ก็กำลังดำเนินอยู่ Perl กำลังได้รับความนิยม และ Haskell ก็มีเวอร์ชันแรก ๆ ออกมาแล้ว แนวหน้าของเทคโนโลยีกำลังย้ายจากเวิร์กสเตชันราคาแพงไปสู่พีซีสำหรับผู้บริโภค และผมคิดว่านักออกแบบภาษาก็ไม่ได้ใส่ใจกับแนวคิด 4GL มากนัก แม้ตอนสร้างสิ่งที่ภายหลังอาจมองว่าเป็น 4GL ได้ เช่น dBase, HyperTalk และ AppleScript
      ผมเห็นด้วยว่าข้อความที่ดูเหมือนภาษาธรรมชาติเป็นไอเดียที่ไม่ดีสำหรับการเขียนโปรแกรมส่วนใหญ่ แต่คิดว่านั่นไม่ใช่เหตุผลเดียวที่ขบวนการ 4GL ล้มเหลว 4GL ส่วนใหญ่ก็ไม่ได้คล้ายภาษาธรรมชาติมากกว่า COBOL ซึ่งเป็น 3GL ด้วยซ้ำ
      ปัญหาที่ใหญ่กว่าคือขบวนการ 4GL ไม่สามารถนิยามได้ดีว่ารุ่นใหม่คืออะไร และอะไรที่มีประโยชน์ 2GL นำมาซึ่งการเปลี่ยนแปลงเชิงปฏิวัติจากแอสเซมบลีไปเป็นภาษาเครื่อง ส่วน 3GL คือการคอมไพล์ แต่การเปลี่ยนแปลงที่พอจะนิยามได้ใน 4GL มีแค่ประมาณว่า “เอาฟังก์ชันที่เคยอยู่ในรูทีนภายนอกหรือไลบรารีมาใส่ไว้ในภาษาให้มากขึ้น”
      แนวทางนี้ใช้ได้ดีกับภาษาเฉพาะโดเมน จึงทำให้มี 4GL ที่ประสบความสำเร็จอย่าง SQL, R และ MATLAB ออกมา ในทางกลับกัน ผมมองว่าแนวคิด 4GL แบบใช้งานทั่วไปมีชะตาที่จะกลายเป็นภาษาที่บวมเกินไปในที่สุด
    • แม้จะดูเหมือนมีหลายอย่างเปลี่ยนไป แต่สุดท้าย แพตเทิร์นเดิม ก็เกิดซ้ำ
    • คำว่า “ไม่ต้องมีโปรแกรมเมอร์อีกต่อไป” ฟังดูน่าทึ่ง แต่ถ้าการเขียนโปรแกรมในยุคนั้นหมายถึงความสามารถในการเขียน ภาษาเครื่อง ลงบนกระดาษโดยตรงให้ทำงานถูกต้องได้ ก็อาจถือว่าพูดถูกอยู่บ้าง
      ทุกวันนี้แทบไม่มีใครที่ทำแบบนั้นได้หรือจำเป็นต้องทำแล้ว

  • ในบริบทนี้นึกถึง Scala ขึ้นมา จากวิธีที่บทความบรรยาย COBOL ผมคิดว่า Scala ก็แทบจะอยู่ในสภาพตายไปแล้วเช่นกัน
    ยังมีบริษัทและบริการจำนวนมากที่มีคอมโพเนนต์หลักเขียนด้วย Scala อยู่ แต่ความสนใจในโปรเจกต์ใหม่ ๆ ลดลงไปมาก
    ช่วงปี 2012–2014 เหมือนจะเห็นบทความแนว “ทำ X ด้วย Scala” บน HN อยู่เรื่อย ๆ แต่ตอนนี้แทบไม่เห็นแล้ว อาจเป็นปรากฏการณ์ที่เป็นธรรมชาติและหลีกเลี่ยงไม่ได้ แต่ก็น่าเสียดายตรงที่ Scala มีข้อดีหลายอย่างที่ภาษากระแสหลักอื่น ๆ ยังไม่ดูแลให้ดี

    • ทีมวิศวกรรมบางทีมของ Apple ยังคงดูแลระบบเดิมไปพร้อมกับทำ โปรเจกต์ใหม่ด้วย Scala
      มีโปรเจกต์ที่ค่อนข้างสำคัญต่อระบบนิเวศของบริษัท เช่น ระบบทดสอบ และวิศวกรที่สร้างระบบแบบนี้ในอดีตตอนนี้ส่วนใหญ่กลายเป็นผู้บริหารระดับสูงแล้ว
      บางคนยังคงสนับสนุนการเลือกเทคโนโลยีในตอนนั้น แต่บางคนก็มีท่าทีเปิดกว้างมากขึ้นหากให้โอกาสย้อนมอง โดยรวมแล้วบรรยากาศคือถ้าตอนนั้นมี Kotlin หรือ Swift ใช้งานกับบริการแบ็กเอนด์ได้ดี ก็คงไม่ได้เลือก Scala
    • Scala ยัง มีชีวิตอยู่อย่างคึกคัก
      https://redmonk.com/sogrady/2024/09/12/language-rankings-6-2...
      กระแสช่วงแรกซาลงแล้ว แต่ก็ไม่เป็นไร ทุกภาษามีวัฏจักรกระแสเกินจริง และการคาดการณ์ก็มักพลาด ภาษาโปรแกรมมิงกระแสหลักในตอนนี้ตายยากเหมือน COBOL แล้ว
      Java ถูกบอกว่าจะตายมาตั้งแต่ปี 2001 แต่ก็ผ่านทั้งฟองสบู่ดอตคอม, .NET, ตัว P ใน LAMP, Ruby, JS และ Go มาได้ Python เองก็เคยถูกบอกว่าจะตายตอนเปลี่ยนผ่านไปเวอร์ชัน 3 เพราะคนย้ายไป Ruby
      Scala เป็นภาษาฟังก์ชันนัลโปรแกรมมิงที่ได้รับความนิยมที่สุดในโลก มีเครื่องมือและไลบรารีที่ดี และมองว่า Scala 3 เป็นการอัปเกรดที่ยอดเยี่ยม
    • ผมคิดว่า Perl ในปัจจุบันใกล้เคียงกับ COBOL มากกว่า
      ครั้งหนึ่งเคยใหญ่มากและรู้สึกเหมือนอยู่ทุกที่ แต่ตอนนี้ค่อย ๆ ถูกผลักไปเป็นภาษากลุ่มเฉพาะมากขึ้น เช่นเดียวกับ COBOL ในหน้างานจริงยังมีโค้ด Perl เหลืออยู่มาก
    • ที่ Writer เราสร้างบริการใหม่ทั้งหมดด้วย Scala
      Jack Henry, SiriusXM, Starbucks, บริการสตรีมมิงของ Disney และ Capitol One ก็สร้าง โปรเจกต์ใหม่ด้วย Scala ในส่วนบริการที่ไม่ใช่งานวิทยาศาสตร์ข้อมูลตั้งแต่ 5 ปีที่ผ่านมาไปจนถึงปัจจุบัน
      แน่นอนว่ายังมีทีมอื่นอีกมาก แต่แค่ยกชื่อดัง ๆ ที่นึกออกทันทีก็ประมาณนี้แล้ว จึงมองว่ายากที่จะบอกว่ามันตายแล้ว
      อย่างไรก็ตาม งานเฟรมเวิร์กที่เน้น Play, Akka และงาน Spark แบบเพียว ๆ ที่ไม่ใช่ Airflow ดูเหมือนจะลดลง สิ่งเหล่านี้เป็นเพียงงานเฟรมเวิร์กที่มาจากระบบนิเวศ Scala และในหลายกรณี Scala เองเป็นเรื่องรองเท่านั้น
    • Scala ตายเหมือน COBOL ไม่ได้ เพราะตั้งแต่แรกมันไม่เคยมีชีวิตแพร่หลายแบบ COBOL
      ผมชอบ Scala แต่มันเป็น ภาษาชายขอบ มาโดยตลอด ส่วน COBOL นั้นอยู่แทบทุกที่จริง ๆ

  • สักวันหนึ่งคิดว่าควรนั่งลองจับ ภาษาเลกาซี อย่าง Fortran, COBOL, Ada, APL ด้วยตัวเอง
    ความนิยมลดลงอย่างชัดเจน แต่ยังเป็นภาษาที่ใช้ในที่สำคัญ ๆ อยู่
    ขณะเดียวกันก็นึกถึงโค้ด Java ปริมาณมหาศาลด้วย ไม่ว่าจะดีหรือร้าย Java แทบจะครองพื้นที่องค์กรไปแล้ว แต่สงสัยว่าอีก 30–40 ปีข้างหน้าจะมีเหตุผลอะไรที่ทำให้เหล่าคนเกษียณเท่านั้นยังใช้ Java เพื่อดูแลระบบธนาคารเก่า ๆ อยู่หรือไม่

    • ที่ COBOL ยังเหลืออยู่ ผมมองว่าไม่ใช่เพราะ COBOL เองเท่าไร แต่เป็นเพราะ การผูกติดกับเวนเดอร์และแพลตฟอร์ม
      อีกเหตุผลน่าจะเป็นเรื่องโค้ดเบสหรือแพลตฟอร์มขนาดมหึมาที่เป็นก้อนเดียวด้วย ภาษาเองไม่ได้ลึกลับหรือยากอะไร แค่มีโค้ดจำนวนมากเกินไปที่มองโครงสร้างไม่ค่อยออก
    • Ada เป็น ภาษาที่ทันสมัยและประณีตกว่า ตัวอย่างอื่น ๆ ในระดับห่างกันเป็นหลักสิบเท่า
      คิดว่าน่าจะยังครองตลาดราว 0.05% ไปอีก 100 ปีข้างหน้า
    • ผมพัฒนาแอป Android ของบริษัท Fortune 100 แห่งหนึ่ง และคอมมิตล่าสุดที่มีคนแก้ไฟล์ Java คือสัปดาห์ที่แล้ว
      แต่ในช่วงไม่กี่ปีที่ผ่านมา โค้ดใหม่ส่วนใหญ่เขียนด้วย Kotlin
    • APL เป็นพาราไดม์ที่แตกต่างมาก จึงคุ้มค่าที่จะลองสัมผัสเอง
      โดยส่วนตัวก็ผูกพันกับมันอยู่ เพราะในยุค 90 บริษัทเคยใช้จริงบน PC งานคือหาวิธีใส่ข้อมูลเข้าไป และสุดท้ายก็เขียนรูทีนที่ปฏิบัติกับเลขทศนิยมแบบเวกเตอร์ของ 1 และ 0 แล้วสลับบิตเพื่อแปลงจากรูปแบบของ Microsoft เป็นรูปแบบ IEEE
      แน่นอนว่านั่นเป็นเรื่องสมัยที่ยังเอาหัวหอมมาผูกไว้กับเข็มขัดกันอยู่
    • ถ้าเป็นแค่ การคำนวณเชิงตัวเลข ล้วน ๆ Fortran ใช้งานได้ค่อนข้างดี
      ถ้าทำการจำลองเชิงตัวเลขล้วน ๆ ผมน่าจะชอบ Fortran มากกว่า C++ หรือ Python ยกเว้น NumPy นะ แต่ตัว NumPy เองสุดท้ายก็พึ่ง Fortran และ C++ อยู่ดี

  • ที่งาน 2025 Carolina Code Conference ยังตามหา วิทยากร COBOL อยู่
    โดยเฉพาะเมื่อ GnuCOBOL เพิ่งมีอัปเดตเมื่อไม่นานนี้ จึงอยากใส่เซสชัน COBOL มาสักพักแล้ว
    https://gnucobol.sourceforge.io/
    https://carolina.codes

    • www.cobolworx.com เรามองหาสถานที่พูดคุยเกี่ยวกับงานของเราอยู่เสมอ

  • “ผมไม่รู้ว่าภาษาในปี 2000 จะมีหน้าตาอย่างไร แต่ชื่อของมันจะเป็น Fortran” —Tony Hoare
    COBOL ถือว่ายังมีชีวิตอยู่ได้ เพราะมันเปลี่ยนแปลงไปตามยุคสมัยเสมอ COBOL สมัยใหม่ค่อนข้างต่างจาก COBOL ยุค 1950 ที่คนมักนึกถึงโดยสัญชาตญาณเมื่อได้ยินชื่อนี้
    คล้ายกับถ้า Java ถูกเรียกด้วยชื่ออย่าง Algol-94 แล้วเราจึงบอกว่าเรายังเขียนโปรแกรมด้วย Algol อยู่

    • ตอนนี้ไม่มีใครเขียนแบบ MULTIPLY A BY B GIVING C ON SIZE ERROR STOP RUN. กันแล้ว
    • Kemeny และ Kurtz เรียก Fortran ว่า “ล้าสมัย” ตั้งแต่ปี 1968 แล้ว
      <https://dtss.dartmouth.edu/sciencearticle/index.html>
    • ถ้าพูดให้แม่นยำกว่า อาจใกล้เคียงกับ “ผมไม่รู้ว่าภาษาในปี 2000 จะถูกเรียกว่าอะไร แต่ มันจะมีหน้าตาเหมือน Fortran” มากกว่า
    • ในปี 2000 คำพูดนี้เกือบจะถูก แต่ตอนนี้ไม่ใช่แล้ว โลกเปลี่ยนไป แม้จะช้าก็ตาม
    • แต่ระบบเดิมจากยุค 70, 80, 90 นั้นใช้ COBOL สมัยใหม่ กันจริงหรือ?

  • COBOL ยังไม่ตาย แต่เข้าถึงได้ยาก เพราะแทบไม่มี เครื่องมือโอเพนซอร์ส ที่ใช้บน Linux ได้
    ที่ OCamlPro ได้เริ่มโปรเจกต์ชื่อ SuperBOL เพื่อสร้างสภาพแวดล้อมโอเพนซอร์สรอบคอมไพเลอร์โอเพนซอร์ส GnuCOBOL โดย GnuCOBOL นั้นเติบโตเต็มที่แล้วและมีการใช้งานในองค์กรอยู่แล้ว
    ตอนนี้ได้เผยแพร่ส่วนขยาย VSCode ที่มี LSP สำหรับ COBOL เพื่อมอบประสบการณ์ IDE แบบสมัยใหม่ และกำลังทำเครื่องมืออื่น ๆ ตามความต้องการของลูกค้าด้วย

    • ปัญหาน่าจะใกล้เคียงกับ การเข้าถึงเมนเฟรม มากกว่าการเข้าถึงเครื่องมือ
      COBOL เรียนได้ในหนึ่งหรือสองวัน และผมก็อยากลองทำงาน COBOL ที่ “น่าเบื่อ” ดู แต่ไม่มีประสบการณ์เมนเฟรม
    • มีแบบนี้ด้วย
      https://gnucobol.sourceforge.io/
      https://cobolworx.com/pages/cobforgcc.html

  • เหมือนทุกครั้ง การถกเถียงแบบนี้ขึ้นอยู่กับว่าจะนิยามคำว่า “ตายแล้ว” กับ “ยังมีชีวิตอยู่” อย่างไร
    ถ้าเรียกเทคโนโลยีหนึ่งว่าตายได้เมื่อไม่มีธุรกิจใหม่ ๆ ถูกสร้างขึ้นบนเทคโนโลยีนั้นอีกแล้ว ก็ถือว่า COBOL ตายแล้วได้ไม่ผิดนัก แพลตฟอร์ม IBM 390x หรือก็คือ Z/OS ซึ่งมักถูกใช้เป็นตัวแทนของ COBOL ก็เช่นกัน
    ในทางกลับกัน ถ้ามองว่ายังมีชีวิตอยู่ตราบใดที่ยังถูกใช้ในสภาพแวดล้อมปฏิบัติการจริง COBOL ก็ยังมีชีวิตอยู่แน่นอน และยังมีชีวิตอยู่มากกว่าเทคโนโลยีจำนวนมากที่อายุน้อยกว่ามันด้วยซ้ำ
    แต่ไม่จำเป็นต้องถือว่านี่เป็นข้อดีของ COBOL หรือระบบนิเวศเมนเฟรม องค์กรมักมีแนวโน้มจะยึดสิ่งที่ทำงานได้ดีตั้งแต่แรกไว้ต่อไป และในหน่วยงานที่เป็นแกนหลักของการแปลงเป็นดิจิทัลยุคแรก ๆ อย่างรัฐบาล ธนาคาร และสายการบิน ตัวเลือกแรกนั้นก็มักเป็นเมนเฟรม IBM กับซอฟต์แวร์ที่รันอยู่บนนั้นเท่านั้นเอง

    • เหตุผลที่กำจัดเมนเฟรมได้ยาก คือแทบไม่มีแพลตฟอร์มอื่นที่รองรับ ปริมาณงาน I/O พร้อมกัน ระดับเมนเฟรมได้
      เมนเฟรมของเราประมวลผลทรานแซกชัน 100 ล้านรายการต่อชั่วโมงได้อย่างสบาย ๆ แถมส่วนใหญ่เป็นแบบ synchronous และแต่ละทรานแซกชันยังต่อไปเป็น SQL transaction หลายรายการ
      eventual consistency ก็เป็นวิธีหนึ่ง แต่ไม่เข้ากับภาคการเงินอย่างมาก และก็น่าจะเป็นเช่นนั้นในงานทหาร ประกัน การแพทย์ และสาธารณสุขด้วย การแบ่งงานเป็นพาร์ทิชันก็ทำได้ แต่เมื่อข้ามขอบเขต shard จะเกิดปัญหาเรื่อง consistency
      COBOL ยังไม่ตาย แต่กำลังค่อย ๆ มุ่งหน้าไปทางนั้น ผมไม่รู้จักธนาคารไหนเลยที่ไม่ได้ทำงานอย่างจริงจังเพื่อออกจากเมนเฟรม ถึงอย่างนั้น การคาดการณ์ที่ผมเห็นบอกว่าเมนเฟรมและ COBOL จะยังคงอยู่ไปอย่างน้อยถึงปี 2050
      นั่นหมายความว่าจะยังมีการเขียนโค้ด COBOL ไปอีก 26 ปี โปรแกรมเมอร์ COBOL มีความต้องการสูงและค่าตอบแทนค่อนข้างดี ดังนั้นต่อให้เริ่มอาชีพเป็นโปรแกรมเมอร์ COBOL ตอนนี้ ก็ยังมีช่วงเวลาทำงานได้เกือบตลอดชีวิตการทำงาน
    • ถ้ามองธุรกิจใหม่ตามตัวอักษรว่าเป็นสตาร์ทอัพ เมนเฟรมก็แทบไม่เคยเป็นตลาดแบบนั้นแม้ในยุค 60–70
      อุปสรรคในการเข้าสู่ตลาดสูงสุดขั้วมาโดยตลอด และลูกค้าหลักในตอนนั้นก็เป็นบริษัทประกันเก่าแก่ ธนาคาร และรัฐบาล การที่บริษัทใหม่จะทำคอมพิวติ้งได้จริง ๆ นั้นใกล้กับยุคหลังมินิคอมพิวเตอร์มากกว่า
      ในแง่นั้นจึงไม่ได้เปลี่ยนไปมากนัก และเมื่อคิดถึงตลาดเป้าหมายของผลิตภัณฑ์ ผมมองว่าเกณฑ์ตัดสินว่าแพลตฟอร์มเป็นหรือตายโดยดูว่า “ธุรกิจใหม่ใช้หรือไม่” นั้นไม่เหมาะสม
    • อย่าตัดความเป็นไปได้ที่ธนาคารหรือสถาบันการเงินขนาดใหญ่จะกำหนดให้เวิร์กโฟลว์หลักเป็น มาตรฐาน COBOL
      หน่วยธุรกิจใหม่หรือทีมสตาร์ทอัพภายใน เช่น หมวดหมู่ผลิตภัณฑ์ประกันใหม่ หากต้องผสานเข้ากับระบบส่วนที่เหลือของธนาคาร ก็อาจเขียนบางส่วนด้วย COBOL ได้
      อย่างน้อยที่สุด ต่อให้ไม่ได้เขียนด้วย COBOL โดยตรง ก็อาจนำไปรันบนโครงสร้างพื้นฐานรันไทม์ COBOL เดิม หรือก็คือบน Z/OS เพราะไม่มีงบซื้อแร็ก x86 ใหม่กับคนมาดูแลมัน
    • COBOL คืออันเดด

  • คลาวด์คือเมนเฟรมแบบใหม่ แต่เป็นเวอร์ชันที่แย่กว่า มีข้อเสียครบทุกอย่างแต่ไม่มีข้อดีที่ใหญ่ที่สุด
    เมื่อก่อนเราสามารถสร้างบริการที่เสถียรมากและประสิทธิภาพดีมากด้วย CICS และเรียกบริการอื่นภายในทรานแซกชันเดียวกันได้ แพลตฟอร์มจัดการเรื่องซับซ้อนอย่างการรักษาความถูกต้องสมบูรณ์ของข้อมูลให้
    ลองเขียน AWS Lambda ที่เรียกกันภายในทรานแซกชันเดียวกันดูสักครั้ง แล้วจะเห็นความแตกต่าง

    • ที่ว่า “มีข้อเสียครบทุกอย่าง” หมายถึงการผูกติดกับผู้ขายรายเดียว การลงทุนด้านโครงสร้างพื้นฐานและค่าใช้จ่ายดำเนินงานมหาศาล และสถานการณ์ที่คนที่รู้เทคโนโลยีที่เกี่ยวข้องต้องผ่านการฝึกอบรมหรือเป็นผู้มีประสบการณ์เท่านั้นใช่ไหม?
      แล้วผมก็ไม่เข้าใจว่าทำไมคู่เปรียบเทียบถึงเป็น “AWS Lambda ที่เรียกกันภายในทรานแซกชันเดียวกัน” การ deploy บนเมนเฟรมเคยง่ายเท่ากับการโยน .zip ที่มีโค้ดใส่ API ที่ให้สิทธิ์เข้าถึงแก่นักพัฒนาหรือเปล่า?

  • บางคนตีความว่าผมเลือกหรือชอบ COBOL มากกว่าภาษาสมัยใหม่แล้ววิจารณ์กัน แต่ไม่ได้หมายความแบบนั้น แค่เป็น ข้อสังเกตแบบทนายปีศาจ ที่มองจากนอกกรอบเท่านั้น
    น่าขันที่จริง ๆ แล้วมีภาษาที่ memory-safe และเสถียร ซึ่งอ่านและเข้าใจง่ายกว่า Rust อยู่แล้ว นั่นคือ COBOL แต่เพราะไม่มีใครอยากใช้ มันจึงกลายเป็นภาษา “ตายแล้ว” และระบบที่ทำให้โลกยุคใหม่เป็นไปได้กลับรันอยู่บนภาษานั้น
    ตัวอย่างเช่น ถ้าเทียบโค้ด Rust กับโค้ด COBOL ที่รับตัวเลขแล้วพิมพ์ว่าเป็นเลขคู่หรือเลขคี่ ฝั่ง COBOL อ่านได้ตรงไปตรงมากว่า

    • เป็นมุมมองที่แปลก ฟีเจอร์ดี ๆ ของภาษาเก่าอาจหายไปแล้วถูกค้นพบใหม่ในภาษายุคหลังได้ก็จริง แต่ก็ยังน่าสงสัยว่า COBOL แก้ปัญหาทั้งหมดที่ Rust ตั้งใจจะแก้ได้จริงหรือไม่
      ไม่รู้ว่ามันให้ประสิทธิภาพระดับเดียวกันไหม เชื่อมต่อกับ native code ของภาษาอื่นได้ในรูปแบบเดียวกันหรือเปล่า มีตัวจัดการแพ็กเกจที่ใช้งานได้บนระบบโมดูลที่ช่วยเรื่องการประกอบใช้งานและความเข้ากันได้ย้อนหลังไหม หรือสามารถแสดงรูปแบบของข้อมูลและข้อผิดพลาดได้สะดวกแบบ algebraic data types ของ Rust หรือไม่
      เช่นเดียวกับที่ COBOL ยังถูกใช้อยู่ด้วยเหตุผลบางอย่าง ภาษาใหม่ ๆ ก็ถูกสร้างขึ้นมาด้วยเหตุผลที่ดีเช่นกัน
    • จะบอกว่าสองโปรแกรมนี้เทียบกันได้ก็ยังคลุมเครือ เวอร์ชัน COBOL ไม่จัดการข้อผิดพลาด แต่โปรแกรม Rust อย่างน้อยก็ยังทำให้เกิด panic เพื่อจัดการ
      ถ้าต่อ boilerplate ที่จำเป็นจริง ๆ จนเป็นโปรแกรม COBOL ที่รันได้ เมื่อป้อน abc จะพิมพ์ “even” และเมื่อป้อน 12 จะพิมพ์ “odd”
      การเจาะจงตำหนิไวยากรณ์ของ Rust ก็แปลกเหมือนกัน เช่นเดียวกับภาษาส่วนใหญ่ในปัจจุบัน Rust โดยรวมก็เป็นไวยากรณ์ตระกูล C และผสมองค์ประกอบของ OCaml อยู่เล็กน้อย นอกเหนือจากเรื่องไวยากรณ์ Rust กับ COBOL มีเป้าหมายต่างกันมาก ดังนั้นการบอกว่า “ก็ใช้ COBOL ไปสิ” ไม่ได้ทำให้เหตุผลการมีอยู่ของ Rust หายไป
    • ตัวอย่างในเอกสาร IBM ดูเหมือนจะแสดงว่า COBOL เป็นภาษาที่ไม่ memory-safe
      https://www.ibm.com/docs/en/cobol-zos/6.2?topic=statement-ex...
      มีโค้ดอย่าง ALLOCATE, การตั้งค่าที่อยู่ของ pointer และ FREE ปรากฏอยู่
    • shell script ก็ memory-safe เหมือนกัน แต่ก็มีเหตุผลที่เราไม่เขียนโปรแกรมยาวเกิน 100 บรรทัดด้วยมัน
    • เป็นการเปรียบเทียบที่แปลก ถ้าเป็นนักพัฒนาที่ควรได้รับอนุญาตให้เข้าใกล้คอมพิวเตอร์ได้ ก็คงไม่เลือก COBOL ใน ตำแหน่งที่ Rust เหมาะสม หรือเลือกกลับกัน

  • ชอบทวีตนี้อย่างประหลาด
    https://x.com/grauhut/status/1000017084435312642
    แปลได้ว่า “พบ COBOL ที่ไซต์ลูกค้า ไม่เป็นไร มันเป็นเมนเฟรม ไม่มีอะไรพิเศษ คอมเมนต์สุดท้ายเป็นของปี 1985 ผู้เขียนคือแม่ของเราเอง”