ปัญหาของการทำอิมพลีเมนเทชันทางเลือก (Alternative Implementation Problem)

ปัญหาของอิมพลีเมนเทชันทางเลือก

ผู้เขียนพูดถึงปัญหาของการทำอิมพลีเมนเทชันทางเลือกที่เกิดขึ้นซ้ำ ๆ ในโลกซอฟต์แวร์ โดยประสบการณ์ของผู้เขียนส่วนใหญ่อยู่กับการปรับแต่งภาษาการเขียนโปรแกรมแบบไดนามิกไทป์ให้มีประสิทธิภาพสูงขึ้น

• โปรเจกต์ PyPy ได้พัฒนา JIT compiler ขั้นสูงสำหรับ Python แต่ในความเป็นจริงกลับแทบไม่มีการใช้งาน เนื่องจาก Python เพิ่มฟีเจอร์ใหม่ ๆ อย่างต่อเนื่องและเปลี่ยนแปลงอยู่เสมอ ทำให้ PyPy ตามไม่ทัน
• LuaJIT ได้รับการยกย่องอย่างมาก แต่เมื่อภาษา Lua เพิ่มฟีเจอร์ใหม่อย่างต่อเนื่อง LuaJIT จึงตกตามหลังอยู่หลายเวอร์ชัน
• TruffleRuby JIT มีประสิทธิภาพที่น่าประทับใจที่สุด แต่มีข้อจำกัดด้านความเข้ากันได้ของฟีเจอร์เมื่อเทียบกับ CRuby จึงถูกนำไปใช้งานอย่างจำกัด

บทเรียน: อิมพลีเมนเทชันทางเลือกเป็นทางเลือกที่มีแนวโน้มจะล้มเหลว

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

YJIT: การทำ Ruby JIT compiler ภายใน CRuby

• YJIT ก็เป็น Ruby JIT อีกตัวหนึ่ง แต่เลือกที่จะพัฒนาไว้ภายในตัว CRuby เอง
• ด้วยแนวทางนี้ YJIT จึงสามารถเข้ากันได้กับทุกฟีเจอร์ของ CRuby แบบ 100% ตั้งแต่ต้น
• ปัจจุบันมันได้กลายเป็น JIT อย่างเป็นทางการของ Ruby และถูกนำไปใช้งานที่ Shopify, Discourse, GitHub และที่อื่น ๆ

บทเรียนในมุมมองที่กว้างขึ้น

• ภาษา Crystal ซึ่งคล้ายกับภาษาเดิมแต่ไม่เข้ากันได้ ก็ประสบความสำเร็จได้อย่างจำกัดเช่นกัน
• สิ่งที่ดูคล้ายกับภาษาเดิมแต่ไม่เข้ากันได้จริง มีแต่จะทำให้ผู้คนสับสน
• เมื่อต้องสร้างภาษาโปรแกรมใหม่ ไม่ควรพยายามเป็นเพียงส่วนย่อยของภาษาเดิม แต่ควรเดินในเส้นทางของตัวเอง
• แบบนั้นจึงจะสามารถพัฒนาไปตามจังหวะและทิศทางของตัวเองได้ โดยไม่ต้องผูกติดกับประสิทธิภาพ ฟีเจอร์ หรือไลบรารีของอิมพลีเมนเทชันอื่น

ความเห็นของ GN⁺

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

[GN⁺]

ความคิดเห็นจาก Hacker News

• เมื่อพัฒนาการติดตั้งใช้งานทางเลือกใหม่ หากสถาปัตยกรรมต่างจากเวอร์ชันเดิม สิ่งที่ทำได้ง่ายในเวอร์ชันเดิมอาจยากมากในเวอร์ชันใหม่ ตัวอย่างเช่น หากซอฟต์แวร์ proprietary โหลด/บันทึกเป็นหน่วย section แต่เวอร์ชันใหม่ใช้วิธีโหลดเอกสารทั้งฉบับขึ้นหน่วยความจำ ก็อาจต้องแก้สถาปัตยกรรมทั้งหมดของเวอร์ชันใหม่เพื่อรองรับฟีเจอร์เพิ่มไฟล์แนบ
• การวางตำแหน่งตัวเองเป็นทางเลือกแทน implementation เดิมเป็นโจทย์ที่แพ้ตั้งแต่ต้น โปรเจ็กต์ที่ทำการตลาดว่าเป็น "Python + X" มักแข่งกับเวอร์ชันทางการได้ยาก แต่ถ้าเหมือน MicroPython ที่ออกแบบมาสำหรับ microcontroller โดยไม่ได้แข่งกับ CPython แต่ไปแข่งกับสภาพแวดล้อมการเขียนโปรแกรมบน microcontroller อื่น ๆ ก็มีโอกาสสำเร็จได้
• แม้จะอ้างว่าเข้ากันได้ แต่ในความเป็นจริงมักเข้ากันได้ต่ำแม้แต่กับฟีเจอร์ภาษาเก่า ๆ และนี่ก็เป็นเหตุผลที่ทำให้การติดตั้งใช้งานทางเลือกล้มเหลว ในกรณีของ Ruby และ Python ตัวอย่างคือการรองรับ native C extension ที่ไม่เพียงพอ
• จากประสบการณ์การก่อตั้ง Startup ควรแสดงให้เห็นว่าสถาปัตยกรรมสามารถรองรับฟีเจอร์ระดับองค์กรได้ แทนการไล่ตามฟังก์ชันพื้นฐาน และควรมุ่งเน้นบางอย่างที่แตกต่างอย่างชัดเจน
• นักพัฒนาให้ความสำคัญกับฟีเจอร์ของภาษาและการทำงานร่วมกันมากกว่า JIT การสร้างโปรเจ็กต์คู่ขนานของตัวเองนั้นง่ายกว่าการไปมีส่วนร่วมกับโปรเจ็กต์เดิม แต่ก็ควรถามตัวเองว่าทำไปเพื่อใคร และต้องระวังไม่ให้หลงตัวเอง
• โค้ดแบบ wrapper มักเบี่ยงเบนจากมาตรฐานและมีเอกสารไม่เพียงพอ จึงก่อให้เกิดความลำบาก ควรเพิ่มเฉพาะฟีเจอร์ที่จำเป็นจริง ๆ และใช้ค่าเริ่มต้นให้มากที่สุด
• คล้ายกับปัญหาที่ TiDB เจอจากความเข้ากันได้กับ MySQL ในทางทฤษฎีมันเป็นโปรโตคอลแบบเปิด แต่ในทางปฏิบัติ Chrome เป็นฝ่ายกำหนดทิศทาง
• ไม่มีการกล่าวถึง Kotlin