ชุมชนของภาษาโปรแกรม Odin กำลังมีส่วนร่วมในการอภิปรายอย่างเข้มข้นเกี่ยวกับปรัชญาการออกแบบภาษา โดยเฉพาะอย่างยิ่งเรื่อง closures และการเข้าถึง Foreign Function Interface (FFI) การสนทนาเหล่านี้เกิดขึ้นหลังจากที่ผู้สร้าง Ginger Bill ได้เผยแพร่บล็อกโพสต์ล่าสุดที่อธิบายว่าทำไม Odin จึงหลีกเลี่ยงฟีเจอร์บางอย่างที่ภาษาสมัยใหม่อื่นๆ นำมาใช้อย่างจงใจ
ปรัชญาการออกแบบภาษา Odin :
- ไม่มี hygienic macros หรือโครงสร้างสำหรับ metaprogramming
- ไม่มี closures เนื่องจากปรัชญาการจัดการหน่วยความจำแบบ manual
- ไม่มี package manager
- ไม่มีโครงสร้าง OOP แบบดั้งเดิม
- มุ่งเน้นไปที่โซลูชันเชิงปฏิบัติมากกว่าฟีเจอร์เชิงทฤษฎี
- เน้นย้ำการ compilation ที่รวดเร็วและความเร็วในการพัฒนา
ความขัดแย้งเรื่อง Closure แบ่งแยกนักพัฒนา
สมาชิกในชุมชนกำลังตั้งคำถามเกี่ยวกับจุดยืนของ Odin ต่อ closures โดยหลายคนชี้ไปที่การใช้งานที่ประสบความสำเร็จในภาษาระบบอื่นๆ การถกเถียงมุ่งเน้นไปที่ว่า closures จำเป็นต้อง automatic memory management จริงหรือไม่ ตามที่เอกสารของ Odin อ้าง นักพัฒนาหลายคนโต้แย้งว่าภาษาอย่าง C++ และ Rust แสดงให้เห็นว่า closures สามารถทำงานได้โดยไม่ต้องมี garbage collection แม้ว่าพวกเขาจะยอมรับข้อแลกเปลี่ยนในเรื่องความซับซ้อนและความปลอดภัย
การอภิปรายเผยให้เห็นความตึงเครียดพื้นฐานระหว่างความเรียบง่ายของภาษากับความคาดหวังของนักพัฒนา ในขณะที่บางคนชื่นชมแนวทางมินิมอลของ Odin คนอื่นๆ รู้สึกถูกจำกัดจากการขาดฟีเจอร์ที่พวกเขาถือว่าจำเป็นสำหรับการเขียนโปรแกรมสมัยใหม่
หมายเหตุ: Closures คือฟังก์ชันที่สามารถจับและใช้ตัวแปรจาก scope รอบข้างได้ แม้หลังจากที่ scope นั้นสิ้นสุดแล้ว
ข้อกังวลของชุมชนและทางเลือกอื่น:
- การสนับสนุน Closure: C++, Rust และ Ada ใช้งาน closures ได้โดยไม่ต้องใช้ garbage collection
- โซลูชัน FFI: LuaJIT เสนอ FFI ที่ง่ายขึ้นผ่านการ copy-paste C headers
- ความเร็วในการพัฒนา: เร็วกว่า Rust สำหรับการพัฒนาเกมแบบวนซ้ำ
- ประสิทธิภาพการคอมไพล์: เวลาคอมไพล์ถึงเรนเดอร์ต่ำกว่าหนึ่งวินาทีสำหรับแอปพลิเคชัน GUI
ความกลัวเรื่อง FFI สร้างอุปสรรคสำหรับผู้ใช้ใหม่
ส่วนสำคัญของการอภิปรายในชุมชนเกี่ยวข้องกับความซับซ้อนของ Foreign Function Interface โดยนักพัฒนาหลายคนแสดงความวิตกกังวลเกี่ยวกับการใช้ FFI เป็นทางแก้ไขสำหรับข้อจำกัดของภาษา ความกลัวนี้ดูเหมือนจะเกิดจากการรับรู้ว่าการรวม FFI นั้นยากและเสี่ยงต่อข้อผิดพลาดโดยธรรมชาติ
อย่างไรก็ตาม นักพัฒนาที่มีประสบการณ์ในเธรดแนะนำว่าการใช้งาน FFI สมัยใหม่ โดยเฉพาะในภาษาอย่าง LuaJIT ทำให้การรวมข้ามภาษาเข้าถึงได้ง่ายกว่าที่เชื่อกันในอดีตมาก การสนทนาเน้นย้ำช่องว่างความรู้ที่อาจป้องกันไม่ให้นักพัฒนาใช้เครื่องมือที่มีอยู่อย่างเต็มประสิทธิภาพ
หมายเหตุ: FFI (Foreign Function Interface) ช่วยให้โปรแกรมที่เขียนด้วยภาษาหนึ่งสามารถเรียกฟังก์ชันที่เขียนด้วยอีกภาษาหนึ่ง โดยทั่วไปคือ C
การแลกเปลี่ยนระหว่างประสิทธิภาพกับความเร็วในการพัฒนา
ชุมชนแสดงความชื่นชมอย่างมากต่อตำแหน่งของ Odin ในภูมิทัศน์การเขียนโปรแกรมระบบ โดยเฉพาะสำหรับการพัฒนาเกม นักพัฒนาชื่นชมความสมดุลระหว่างประสิทธิภาพและความเร็วในการพัฒนา โดยเปรียบเทียบในแง่ดีกับความซับซ้อนของ Rust และฟีเจอร์ความปลอดภัยเพิ่มเติมของ Zig ที่สามารถทำให้รอบการพัฒนาช้าลง
แอป GUI ของผมใช้เวลาจากการคอมไพล์จนถึงการวาดเฟรมไม่ถึงหนึ่งวินาที เจ๋งแค่ไหน?
ความรู้สึกนี้สะท้อนความพึงพอใจในวงกว้างต่อความเร็วในการคอมไพล์ของ Odin และแนวทางที่ตรงไปตรงมาต่อการเขียนโปรแกรมระบบ แม้ในหมู่ผู้ที่อาจต้องการฟีเจอร์ภาษาเพิ่มเติม
บทสรุป
การอภิปรายเผยให้เห็นชุมชนที่กำลังต่อสู้กับปัญหาคลาสสิกของภาษาโปรแกรม คือความร่ำรวยของฟีเจอร์เทียบกับความเรียบง่าย ในขณะที่ผู้สร้าง Odin ยืนหยัดในจุดยืนที่แน่วแน่ต่อต้าน feature creep การถกเถียงทางเทคนิคของชุมชนแสดงให้เห็นทั้งการมีส่วนร่วมอย่างลึกซึ้งกับภาษาและการพิจารณาแนวทางทางเลือกอย่างรอบคอบ ว่าปรัชญามินิมอลของ Odin จะยังคงตอบสนองฐานผู้ใช้ที่เติบโตขึ้นหรือไม่ยังคงเป็นคำถามที่เปิดอยู่ขณะที่ภาษานี้พัฒนาต่อไป
อ้างอิง: If Odin Had Macros