เซิร์ฟเวอร์ Minecraft ที่เขียนด้วย COBOL

 (github.com/meyfa)
1 คะแนน โดย GN⁺ 2024-12-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • CobolCraft คือ เซิร์ฟเวอร์ Minecraft ที่พัฒนาด้วย COBOL และรองรับ Minecraft 1.21.4 ซึ่งเป็นเวอร์ชันล่าสุด ณ เวลาที่เขียน
  • ตอนนี้ได้พัฒนาแล้วทั้งการสร้างภูมิประเทศแบบไม่สิ้นสุด, การโหลดชังก์แบบไดนามิก, การบันทึกข้อมูลโลกและผู้เล่นลงดิสก์, การนำเข้าโลกเดิม, มัลติเพลเยอร์, การแสดงสถานะเซิร์ฟเวอร์, การทำลาย·วางบล็อก, อินเวนทอรี, การคราฟต์, การเก็บไอเท็ม, แชต, คำสั่ง ฯลฯ
  • บล็อกที่มีหลายสถานะ หลายทิศทาง และหลายรูปแบบการโต้ตอบ ต้องใช้ โค้ดเฉพาะทางจำนวนมาก เพื่อให้ทำงานได้ถูกต้อง และยังมีบล็อกอีกมากที่ยังไม่รองรับ
  • พัฒนาด้วย GnuCOBOL บน Linux x86_64 หรือ arm64 และสามารถดีพลอยด้วย Docker ได้ แต่ยังไม่ได้ทดสอบการรองรับระบบปฏิบัติการอื่นอย่าง Windows
  • มีการดึงข้อมูล JSON จาก datapack พื้นฐานของ Minecraft และไฟล์ .jar ของเซิร์ฟเวอร์·ไคลเอนต์ทางการ เพื่อนำไปใช้สร้างโค้ด COBOL ตอนคอมไพล์และโหลดข้อมูลตอนรันไทม์

ฟีเจอร์ของเซิร์ฟเวอร์ Minecraft ที่ CobolCraft รองรับ

  • CobolCraft เป็น เซิร์ฟเวอร์ Minecraft ที่เขียนด้วย COBOL และรองรับ Minecraft 1.21.4
  • ฟีเจอร์ที่รองรับมีดังนี้
    • การสร้างภูมิประเทศแบบไม่สิ้นสุดและการโหลดชังก์แบบไดนามิก
    • การบันทึกข้อมูลโลกและผู้เล่นลงดิสก์
    • รองรับฟอร์แมตไฟล์ของ Minecraft และการนำเข้าโลกเดิม
    • มัลติเพลเยอร์ที่กำหนดจำนวนผู้เล่นพร้อมกันได้
    • ping/server status เพื่อให้แสดงว่าออนไลน์ในรายการเซิร์ฟเวอร์
    • การทำลายและวางบล็อก พร้อมโค้ด loot table ที่สร้างอัตโนมัติ
    • การโต้ตอบกับบล็อกผ่านการคลิกขวา
    • อินเวนทอรีของผู้เล่น
    • การคราฟต์แบบ 2x2 และ 3x3
    • item entity และการเก็บไอเท็ม
    • แชต
    • คำสั่งในเกมและคำสั่งคอนโซลแบบโต้ตอบ
    • การตั้งค่าที่อิงกับ server.properties
    • whitelist แบบถาวรที่บันทึกใน whitelist.json
    • การชนกันของบล็อก·ผู้เล่นและฟิสิกส์เอนทิตีในระดับพื้นฐานมาก
    • ความเสียหายจากการตก, ความเสียหายจาก void, การตาย, การเกิดใหม่

ขอบเขตและข้อจำกัดของการรองรับบล็อก

  • บล็อกที่มีหลายสถานะ หลายทิศทาง และหลายรูปแบบการโต้ตอบ ต้องใช้ โค้ดเฉพาะทาง จำนวนมากเพื่อให้ทำงานได้ถูกต้อง
  • ยังมีบล็อกอีกมากที่ยังไม่รองรับ
  • บล็อกที่ใช้งานได้มีดังนี้
    • torches
    • slabs
    • stairs
    • rotated pillars เช่น logs
    • buttons ที่ไม่มีการโต้ตอบ
    • doors
    • trapdoors
    • beds
    • signs

สภาพแวดล้อมสำหรับการบิลด์และรัน

  • CobolCraft พัฒนาด้วย GnuCOBOL และมุ่งให้รันบน Linux
    • สถาปัตยกรรมเป้าหมายคือ x86_64 และ arm64
    • ยังไม่ได้ทดสอบการรองรับระบบปฏิบัติการอื่นอย่าง Windows
    • หากใช้ Docker จะสามารถดีพลอยแบบไม่ขึ้นกับแพลตฟอร์มได้
  • สิ่งที่จำเป็นสำหรับการแจกจ่ายบน Linux มีดังนี้
    • GnuCOBOL 3.1.2 ขึ้นไป
    • เพื่อประสิทธิภาพ แนะนำ GnuCOBOL 3.2 ขึ้นไป
    • make
    • gcc, g++
    • zlib
    • curl สำหรับดาวน์โหลดไฟล์ .jar ของเซิร์ฟเวอร์ทางการ
    • Java 21 ขึ้นไป สำหรับดึงข้อมูลจากไฟล์ .jar ของเซิร์ฟเวอร์
  • คำสั่งสำหรับบิลด์และรันมีดังนี้
make --jobs=$(nproc)
make run
  • สามารถใช้อิมเมจจาก Docker Hub หรือบิลด์เองแล้วรันก็ได้
docker pull meyfa/cobolcraft:latest

git clone https://github.com/meyfa/CobolCraft.git cobolcraft && cd cobolcraft
docker build --tag meyfa/cobolcraft .

การตั้งค่าเซิร์ฟเวอร์และการเข้าถึงผ่านเครือข่าย

  • การตั้งค่าเซิร์ฟเวอร์ทำได้โดยแก้ไขไฟล์ server.properties
  • ไฟล์นี้จะถูกสร้างอัตโนมัติเมื่อรันครั้งแรก พร้อมค่าเริ่มต้นของตัวเลือกที่รองรับทั้งหมด
    • server-port: ค่าเริ่มต้น 25565
    • level-name: ค่าเริ่มต้น "world"
    • white-list: ค่าเริ่มต้น false
    • motd: ค่าเริ่มต้น "CobolCraft"
    • max-players: ค่าเริ่มต้น 10, สูงสุด 100
  • โดยค่าเริ่มต้น เซิร์ฟเวอร์จะเข้าถึงได้จากเครื่องตัวเองเท่านั้นผ่าน localhost:25565
  • หากต้องการให้เข้าถึงได้จากภายนอก เช่น เครือข่ายภายใน, VPN, port forwarding, เซิร์ฟเวอร์เช่า ฯลฯ สามารถ bind พอร์ตเป็น 0.0.0.0:25565:25565 ตอนรัน Docker ได้
docker run --rm -it -p 0.0.0.0:25565:25565 meyfa/cobolcraft

เหตุผลที่สร้างเซิร์ฟเวอร์ Minecraft ด้วย COBOL

  • ผู้พัฒนาไม่เคยมีประสบการณ์กับ COBOL มาก่อนเลย แต่เมื่อเห็นข่าวลือและภาพจำเกี่ยวกับ COBOL ก็อยากทำความรู้จักภาษานี้ให้มากขึ้น
  • จึงเลือกวิธีลงมือเขียนบางอย่างจริง ๆ เพราะมองว่าเป็นวิธีที่ดีที่สุดในการเรียนภาษา
  • เนื่องจากโค้ดของ Minecraft มีทั้งความซับซ้อนและขนาดใหญ่ จึงประเมินว่าการเลือกเขียนเซิร์ฟเวอร์ Minecraft ด้วย COBOL เป็นทั้งไอเดียที่ดีและไม่ดีในเวลาเดียวกัน
  • มีหลายอย่างที่ในภาษาอื่นทำได้ง่าย แต่ต้องสร้างขึ้นใหม่ตั้งแต่ต้น
    • การ parse และ encode JSON
    • การจัดการข้อมูลไบนารีหลายประเภท
    • ระบบเครือข่ายมัลติเพลเยอร์แบบเรียลไทม์
    • การย้ายระบบ Minecraft ที่มีลักษณะเชิงวัตถุไปสู่ภาษาขั้นตอน
  • เส้นโค้งการเรียนรู้ที่ชันทำให้ต้องค้นคว้าและทำความเข้าใจ COBOL กับแนวคิดของมันอย่างลึกซึ้ง และผู้พัฒนาระบุว่ากระบวนการนั้นคุ้มค่า
  • สำหรับผู้ที่เพิ่งเริ่มใช้ COBOL แนะนำ GnuCOBOL Programmer's Guide
  • สำหรับการเรียนรู้โปรโตคอลของ Minecraft สามารถดู wiki.vg documentation
  • ในบางกรณี การดูทราฟฟิกของเซิร์ฟเวอร์จริงผ่านเครื่องมืออย่าง Wireguard ก็อาจช่วยให้เข้าใจการไหลของข้อมูลได้

โครงสร้างซอร์สและไบนารีที่รันจริง

  • ซอร์สโค้ด COBOL อยู่หลัก ๆ ในไดเรกทอรี src/
    • src/main.cob คือจุดเริ่มต้น
    • src/server.cob มีโค้ดสำหรับเริ่มเซิร์ฟเวอร์และเกมลอจิก
  • ไดเรกทอรี codegen/ มี ตัวสร้างโค้ด ที่เขียนด้วย COBOL
    • ใช้สร้างซอร์สโค้ดเพิ่มเติมจากข้อมูล JSON เช่น datapack พื้นฐานของ Minecraft
  • ไดเรกทอรี cpp/ มีซอร์ส C++ สำหรับการเชื่อมต่อกับระบบปฏิบัติการที่ทำด้วย COBOL ได้ยาก
    • การจัดการ TCP socket ระดับต่ำ
    • การจับเวลาอย่างแม่นยำ
    • การจัดการ process signal
  • ซอร์ส COBOL และ C++ ทั้งหมดจะถูกคอมไพล์เป็นไบนารีเดียวชื่อ cobolcraft

การดึงข้อมูล Minecraft และการจัดการ JSON

  • แอปพลิเคชันเซิร์ฟเวอร์และไคลเอนต์อย่างเป็นทางการของ Minecraft Java Edition มีข้อมูลจำนวนมากอยู่ภายใน
    • บล็อก, ไอเท็ม, ประเภทเอนทิตี
    • biomes
    • packet protocol ID
    • tags เช่น บล็อกที่ขุดได้ด้วย pickaxe
    • recipes
    • loot tables ที่ระบุว่าเมื่อทำลายบล็อก ภายใต้เงื่อนไขใดจะดรอปไอเท็มอะไร
  • ใน Makefile ของ CobolCraft มี target สำหรับดาวน์โหลดไฟล์ .jar ทางการและดึงข้อมูลออกมาเป็น JSON
  • ข้อมูล JSON ที่ดึงออกมาถูกใช้งานสองแบบ
    • สร้างโค้ด COBOL อัตโนมัติระหว่างคอมไพล์ เช่น loot table ของบล็อก
    • โหลดข้อมูลเข้าหน่วยความจำตอนรันไทม์
  • ทั้งสองงานนี้ใช้ ตัว parse JSON แบบอเนกประสงค์ ที่เขียนด้วย COBOL และผ่าน unit test แล้ว

การทดสอบและการอัปเดต

  • unit test อยู่ในไดเรกทอรี tests/
  • การทดสอบใช้เฟรมเวิร์กทดสอบแบบคัสตอมที่อิงกับ copybook
    • ติดตาม test suite, unit, assertion
    • ให้สรุปผลเมื่อรันเสร็จ
  • คำสั่งสำหรับรันทดสอบคือ make test
  • เป้าหมายหลักของการทดสอบคือการตรวจสอบส่วนที่ดีบักยาก เช่น การ encode และ decode ข้อมูล JSON·ไบนารี
  • มองว่าการทดสอบเกมลอจิกเองไม่ได้สำคัญเท่าไรนัก
  • ขั้นตอนและช่วงการทดสอบในการอัปเดตเซิร์ฟเวอร์ไปยัง Minecraft เวอร์ชันใหม่อยู่ใน Updating.md

ใบอนุญาตและเครื่องหมายการค้า

  • CobolCraft เผยแพร่ภายใต้ MIT License
  • “Minecraft” เป็นเครื่องหมายการค้าของ Mojang Synergies AB
  • CobolCraft ไม่ได้เป็นโครงการที่มีความร่วมมือหรือได้รับการรับรองจาก Mojang

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

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

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

  • มีข่าวลือและตราบาปเกี่ยวกับ COBOL อยู่มาก ถ้าเขียนเล่าว่าได้ข้อสังเกตอะไรจริง ๆ บ้างก็น่าจะดี
    ผมเองก็เคยได้ยินแต่เรื่องแบบนั้น และอยากรู้ว่า มือใหม่ COBOL เจออะไรบ้างระหว่างทำโปรเจกต์แรกที่ค่อนข้างซับซ้อน

    • มีตราบาปเชิงล้อเล่นว่า COBOL สายวัตถุวิสัยมีชื่อเป็นรูปแบบเทอะทะอย่าง ADD ONE TO COBOL YIELDING COBOL
      แต่ถึงอย่างนั้นก็ไม่เคยมีกรณีแบบ FORTRAN สมัยก่อนที่ไม่สนใจช่องว่าง จน DO 10 I=1.10 ไม่ถูกมองเป็น syntax error ของลูป แต่คอมไพล์เงียบ ๆ เป็นคำสั่งกำหนดค่า DO10I = 1.10 ทั้งที่โค้ดที่ตั้งใจคงเป็น DO 10 I=1,10
    • ชอบ insight แบบนี้
      ถ้าสนใจ นี่คือสิ่งที่ได้จากการทำคอมไพเลอร์จาก COBOL ไป C#: https://github.com/otterkit/otterkit-cobol/issues/40
      ตอนนี้มั่นใจแล้วว่า COBOL เป็นแค่แอสเซมเบลอร์ระดับสูง เท่านั้น

  • เจ๋งจริง ๆ
    โปรเจกต์จบมัธยมของผมคือทำ ระบบ COBOL ทั้งชุด เพื่ออัตโนมัติอัตราต่อรองพนันฟุตบอล ตอนนั้นมันเป็นเทคโนโลยีตกยุคไปแล้ว แต่โรงเรียนยังตามยุคไม่ทัน
    มันไม่เข้ากันอย่างเหลือเชื่อ แต่ผมชอบทุกบรรทัด มีอะไรบางอย่างที่น่าพอใจแปลก ๆ ในภาษาที่กระซิบทุกครั้งตอนพิมพ์ว่า “จำบัตรเจาะรูได้ไหม?”

    • การที่ใช้ COBOL ตัวพิมพ์ใหญ่ ในโปรเจกต์มัธยมนี่เข้ากับยุคมาก ๆ น่าจะกลายเป็นความทรงจำมัธยมที่ยอดเยี่ยม หวังว่าชื่อตัวแปรทั้งหมดจะตั้งเป็นชื่อเทพกรีกนะ

  • อาจจะคิดไปเองก็ได้ แต่รู้สึกว่ามักเห็นโปรเจกต์ข้างเคียงเล็ก ๆ แต่น่าประทับใจที่เขียนด้วยภาษาง่าย ๆ ธรรมดา ๆ อย่าง C หรือ COBOL ในกรณีนี้ค่อนข้างบ่อย
    กลับกัน โปรเจกต์ Rust ที่คล้ายกันมักดูเหมือนมีจำนวนบรรทัดโค้ดมากกว่าราว 10 เท่า แต่แทบจะทำงานไม่ได้
    สมมติฐานของผมคือ ภาษาที่เรียบง่าย ทำให้จับไอเดียเป็นพิมพ์เขียวได้เร็ว และทำให้โค้ดเบสที่สกปรกก็ยังรันได้ก่อน ในขณะที่ภาษาสมัยใหม่บังคับให้เราเขียนโค้ดที่อยู่ได้นานกว่า หรือไม่ก็อาจเป็นว่าภาษาสมัยใหม่กำลังทำอะไรบางอย่างผิดอยู่

    • เซิร์ฟเวอร์ Minecraft พูดให้ถูกไม่ใช่โปรเจกต์ข้างเคียงเล็ก ๆ
      มีเซิร์ฟเวอร์ที่พัฒนามา 3–5 ปีแล้วยังไม่เสร็จ และก็มีแบบที่เน้นฟีเจอร์เฉพาะเพื่อโชว์ redstone อย่าง https://github.com/MCHPR/MCHPRS
      เซิร์ฟเวอร์ COBOL นี้ยังไม่ได้ทำ ระบบแสง และการเกิดของม็อบก็พึ่งพามันด้วย จึงเป็นหนึ่งในส่วนที่ยากที่สุด บล็อกบางชนิดก็ยังไม่ได้ทำให้สมบูรณ์ การทำเซิร์ฟเวอร์ Minecraft ให้เสร็จต้องใช้เวลาหลายปี ดังนั้นการทำอะไรให้เร็วไม่ได้แปลว่าเป็นทางที่ดีเสมอไป
    • ผมว่ามันไม่จำเป็นต้องเป็นความเข้าใจผิดนะ
      ผมกำลังทำเกมด้วย Rust อยู่ 2 เกม ถ้าเลือกเอนจินเหมาะ ๆ การทำต้นแบบ gameplay แบบขั้นต่ำสุดค่อนข้างง่าย แต่ยิ่งเพิ่มฟีเจอร์ โค้ดก็ยิ่งพองขึ้นมาก และกระบวนการเปลี่ยนจาก single-player เป็น multi-player ก็เละเทะ ผมยังเสียเวลาไล่ตามกระแสแล้วต้องกลับมาถอดออกด้วย
      Rust เกลียดโครงสร้างกราฟที่วัตถุในเกมเชื่อมโยงกันซับซ้อนมาก ทุกสถานการณ์ที่ event ในเกมหนึ่งตัวนำไปสู่การอัปเดตหลายประเภทจะเกิดแรงเสียดทาน จะเลือกยอมรับแล้วเขียนโค้ดเพิ่มอีกหน่อยก็ได้ หรือจะเลือกหาแนวทางที่เป็นระบบซึ่งต้องเขียนโค้ดมากขึ้นตั้งแต่ต้นแต่ประหยัดเวลาทีหลังก็ได้
      ผมเลือกทางที่สองและลองหลายอย่าง แต่รู้สึกว่าจุดคุ้มทุนอยู่ไกลเกินไปสำหรับโปรเจกต์เล็กที่มีจุดคุ้มทุนเท่ากับ 1
      แม้ในภาษาเดียวกัน ความต่างก็อาจมากกว่าหนึ่งหลักได้ Rust มีเอนจิน 3D ที่ใช้ได้อยู่ 2 ตัว ตัวหนึ่งมีชื่อเสียง มีผู้ร่วมพัฒนาเยอะ และมีสปอนเซอร์ระดับที่ทดแทนเงินเดือน Bay Area ได้ อีกตัวหนึ่งแทบจะทำโดยคนคนเดียว สลับระหว่างใช้เงินเก็บประทังกับทำงานเต็มเวลา
      แต่เอนจินแรกเน้นประชาสัมพันธ์หนัก สัญญาฟีเจอร์หลายอย่างมาหลายปีแต่แสดงให้เห็นได้น้อย ส่วนตัวที่สองนำหน้าทั้งจำนวนฟีเจอร์และคุณภาพการ implement
      สุดท้ายผมมองว่าเป็นความต่างด้าน ทัศนคติ มีคนที่โค้ดเพื่อความสนุก คนที่มีเป้าหมายชัดและโฟกัสกับการทำให้สำเร็จ คนที่ทำเพื่อเงิน และคนที่ถูกดึงดูดด้วยการยอมรับจากสาธารณะ โค้ดเบสสกปรกไม่ได้จำเป็นเสมอไป แต่มีจุดกึ่งกลางที่ productive อยู่ คนที่โฟกัสกับการโชว์มากเท่าไร ก็ยิ่งมีแนวโน้มไล่ตามกระแสและสถาปัตยกรรมฉูดฉาดมากเท่านั้น
    • Rust ค่อนข้างดิ้นรนในการหาทางแจ้งเกิดในวงการพัฒนาเกม
      สมมติฐานหลักของ Rust คือการแลกความเร็วในการพัฒนาและความยืดหยุ่นกับ memory safety แต่ในงานพัฒนาเกม ปรากฏว่า ความเร็วในการพัฒนาและความยืดหยุ่น สำคัญกว่า memory safety มาก
      ถ้าเป็น microkernel ตาม specification เชิงรูปแบบที่วางพิมพ์เขียวละเอียดไว้แล้ว Rust อาจเป็นตัวเลือกที่ยอดเยี่ยม ตรงกันข้าม ถ้าต้องโยนโคลนใส่กำแพงอย่างรวดเร็วเพื่อดูว่า gameplay แบบไหนสนุก Rust ทำให้กระบวนการนั้นยากกว่าแทบทุกภาษา และข้อดีก็ไม่ชัดเจน อย่างมากก็คือชิ้น gameplay ที่เร็วและสกปรกซึ่งใช้เวลาทำนานกว่า มี memory safety มากขึ้นเล็กน้อย
      ผมไม่ใช่คนเดียวที่ลองพัฒนาเกมด้วย Rust แล้วเลิกใช้มันสำหรับงานนั้นอย่างชัดเจน เช่นมี “Leaving Rust gamedev after 3 years” [0] ซึ่งจนถึงตอนนี้เป็นหนึ่งในโพสต์เกี่ยวกับ Rust บน Hacker News ที่มีคนถกกันและกดถูกใจมากที่สุด
      มองกว้าง ๆ แล้วชัดเจนว่า Rust ได้รับความสนใจเกินจริงมากกว่า Cobol มาก ดังนั้นจึงมีตัวอย่างมากมายของนักพัฒนาที่อ่อนไหวต่อกระแสเกินจริง ซึ่งมักเป็นมือใหม่ที่กระตือรือร้น กระโดดเข้าไปทำโอเพนซอร์สหรือโปรเจกต์งานอดิเรกด้วย Rust อย่างกล้าหาญ ในทางกลับกัน การเขียนเซิร์ฟเวอร์ Minecraft ด้วย Cobol ต้องใช้ความพิสดารและความกล้ามากกว่าเล็กน้อย และโดยทั่วไปสิ่งนี้เชื่อมโยงกับประสบการณ์ที่มากกว่า
      [0] https://news.ycombinator.com/item?id=40172033
    • สุดท้ายก็ดูเหมือนความต่างระหว่าง แฮ็กเกอร์ตัวจริง™ ที่ชอบภาษาง่าย ๆ และไม่ว่าให้อะไรก็สร้างจักรวาลทั้งใบออกมาได้ กับ code monkey ที่ไล่ตามกระแสล่าสุด
      อ้างอิงไว้ก่อนว่า ผมจัดตัวเองอยู่ในกลุ่มที่สอง
    • คนที่ทำงานให้เสร็จมักไม่ค่อยใส่ใจคุณภาพโค้ดมากนัก
      ผมเคยอยู่ในสภาพที่พยายามเขียนโค้ดให้อยู่ได้นาน จนถึงจุดหนึ่งกลับทำอะไรไม่เสร็จเลย หลายปีผ่านไปผมหาสมดุลเจอ และได้เรียนรู้ว่าถ้าค่อย ๆ ปรับปรุงโค้ดห่วย ๆ ซ้ำไปเรื่อย ๆ สุดท้ายมันจะกลายเป็นของที่ใช้ได้ และตั้งแต่นั้นมาก็ทำแบบนั้นมาตลอด

  • https://raw.githubusercontent.com/meyfa/CobolCraft/main/src/...
    สำหรับคนที่มีพื้นฐานภาษาเชิงกระบวนคำสั่ง จริง ๆ แล้วไม่ได้เข้าใจยากขนาดนั้น และทำให้นึกถึง เกมเซิร์ฟเวอร์ที่เขียนด้วย VB ที่เคยเห็นเมื่อราว 20 ปีก่อนอยู่บ้าง

  • หลังจากเลิกใช้ COBOL ในปี 1978 ก็ไม่เคยยอมรับเลยว่ารู้จักภาษานี้
    ขออย่าได้เห็นโค้ดนี้เลย ว่าแล้วก็ทำเครื่องหมายกางเขนแล้วไปดื่มกาแฟเข้ม ๆ :-)
    แต่ก็ยังน่าประทับใจที่ทำสิ่งนี้ได้สำเร็จ

  • จะล้อก็ได้ แต่โค้ดอ่านค่อนข้างง่าย
    เทียบกับภาษาสมัยใหม่บางภาษาที่ต้องจ้องดูอยู่นานหลายนาทีเพื่อทำความเข้าใจว่าเกิดอะไรขึ้น

    • ครั้งหนึ่งเคยทำงานที่บริษัท FAANG และเข้าถึงผู้เชี่ยวชาญ C++ ระดับโลกได้ บางคนอยู่ในคณะกรรมการมาตรฐานภาษาระดับนานาชาติด้วย
      เคยถามในรายการภายในเกี่ยวกับ C++ ว่าโค้ดบรรทัดหนึ่งจะทำให้เกิดหน่วยความจำรั่วหรือไม่ ซึ่งเป็นโค้ดที่ใช้ STL template และการแปลงชนิดข้อมูลล้วน ๆ แต่ผู้เชี่ยวชาญกลับ ตกลงกันไม่ได้ ว่าผมทำถูกหรือไม่ บางคนบอกว่าจะรั่ว บางคนมองว่าไม่รั่ว
      เรื่องจริงเล็ก ๆ นี้บอกอะไรได้มากเกี่ยวกับ C++ ส่วน JavaScript ก็เต็มไปด้วยเรื่องแบบนี้เช่นกัน
    • นั่นแหละคือจุดแข็งของ COBOL
      ผมเริ่มเขียนโปรแกรมในปี 1976 เรียน COBOL กับ ICL PLAN ใช้บัตรเจาะรู แล้วหลังจบการฝึกอบรมก็ใช้เทอร์มินัล โปรแกรมเป็น โปรแกรม batch 100%
      มีความเอนเอียงอย่างมากไปทางความอ่านง่าย เพื่อให้ใครก็ตามสามารถอ่านและเข้าใจซอร์สโค้ดได้ อย่างไรก็ตาม ความอ่านง่ายนั้นถูกหักล้างไปบ้างด้วยการที่ต้องอ่านและทำความเข้าใจ core dump ที่สร้างขึ้นเมื่อโปรแกรมล้มเหลว อย่างดีที่สุดก็ไล่ตามความผิดพลาดไปถึงบรรทัดโค้ดที่เจาะจงได้ และด้วยเหตุนี้นิสัยการรันโปรแกรมในหัวจึงฝังติดตัวมา
      แม้เมื่อออกจากหน่วยงานรัฐไปทำงานเขียนโปรแกรมเชิงพาณิชย์ จนถึงต้นยุค 80 ก็ยังคงเป็น COBOL กับโปรแกรม batch อยู่ ผมทำงานซัพพอร์ตกลางคืนอยู่ 3 ปี และตอนนั้นเองที่คุณค่าของ COBOL ปรากฏชัด แม้หยิบ listing กับ core dump ที่ไม่เคยเห็นมาก่อนขึ้นมา ก็มักแก้ได้ค่อนข้างเร็ว แน่นอนว่าต้องมีเงื่อนไขว่ามักเป็นการแก้ไขเชิงยุทธวิธีเสมอ
    • เพราะแบบนั้นเลยชอบ Ada และ VHDL
      อาจจะค่อนข้างยืดยาวบ้าง แต่ก็อ่านง่ายกว่าภาษาที่ “ทันสมัย” กว่ามาก
    • COBOL ถูกออกแบบมาเพื่อให้คนที่ไม่ใช่โปรแกรมเมอร์ก็เขียนและอ่านได้
      อย่างน้อยก็ในทางทฤษฎี
    • MOVE FUNCTION MIN(BLOCK-ENTRY-MINIMUM-STATE-ID(LK-BLOCK), STATE-ID) TO BLOCK-ENTRY-MINIMUM-STATE-ID(LK-BLOCK)

  • ตอนมัธยมเคยเรียน COBOL นิดหน่อยในเมืองเล็ก ๆ แห่งหนึ่งในปากีสถาน
    ก็ไม่ได้แย่ และเคยทำโปรเจกต์เลียนแบบงบการเงิน มันมีจุดแปลก ๆ อยู่บ้าง แต่สำหรับมนุษย์ส่วนใหญ่ หรือก็คือคนที่ไม่ใช่โปรแกรมเมอร์ ภาษาโปรแกรมมิงไหน ๆ ก็คงค่อนข้างประหลาดทั้งนั้น เลยไม่ค่อยเข้าใจตราบาปที่ติดอยู่กับ COBOL
    ช่วงเดียวกันก็เรียน C ด้วย และทางนั้นก็ยังอยู่ต่อมา :-)

  • ได้ยินมาตลอดว่าโปรแกรมเมอร์ Cobol หายากเลยได้เงินเดือนสูง
    สงสัยว่าโปรเจกต์นี้ทำให้มีข้อเสนองานหลั่งไหลเข้ามาหรือเปล่า

    • สิ่งที่หายากไม่ใช่โปรแกรมเมอร์ Cobol แต่คือ คนที่เข้าใจ business logic
      Cobol มักถูกใช้ในการดำเนินงานทางธุรกิจที่ซับซ้อนมาก
    • อย่างที่คนอื่นพูดไว้ สิ่งที่สำคัญกว่าคือความซับซ้อนของ business logic เดิม และความเข้าใจเกี่ยวกับ ระบบเมนเฟรม ที่โค้ดนั้นมักรันอยู่
      ไม่อย่างนั้นก็คงแค่สร้าง cross-compiler ขึ้นมาสักตัวแล้วจบ
    • คนเหล่านั้นมีคุณค่าเพราะระบบที่ซับซ้อนมากและโดยมากไม่มีเอกสาร รวมถึง ความรู้บริบททางธุรกิจ มากกว่าทักษะการเขียนโปรแกรม

  • COBOL ดูเป็นภาษาที่เท่พอสมควรจริง ๆ
    โค้ดก็จัดระเบียบไว้ดีมาก

  • ชอบตรงที่มี unit test