นักพัฒนาถกเถียงเรื่องชุดภาษาแบบรวมเป็นทางออกสำหรับความท้าทายในการพัฒนาแบบหลายภาษา

ชุมชนการพัฒนาซอฟต์แวร์กำลังอภิปรายอย่างจริงจังเกี่ยวกับแนวคิดของชุดภาษาแบบรวม (unified language sets) ในฐานะทางออกที่เป็นไปได้สำหรับความท้าทายในการทำงานกับหลายภาษาโปรแกรมมิ่งในโปรเจกต์ต่างๆ การอภิปรายนี้มาจากบทความที่เสนอระบบการจัดหมวดหมู่สำหรับภาษาโปรแกรมมิ่งเป็นสี่ระดับที่แตกต่างกันตามโมเดลการทำงานและระบบไทป์ของภาษา พร้อมข้อเสนอสำหรับชุดภาษาแบบรวมที่สร้างขึ้นรอบภาษา Rust

ปัญหาการพัฒนาแบบหลายภาษา

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

แนวทางที่มีอยู่และทางเลือก

ผู้แสดงความคิดเห็นหลายคนได้เน้นย้ำถึงระบบนิเวศที่มีอยู่แล้วซึ่งพยายามแก้ไขปัญหานี้ ระบบนิเวศ Clojure ถูกกล่าวถึงว่ามีภาษาย่อยที่มีประโยชน์มากโดยมีความซ้อนทับกันอย่างกว้างขวางในสภาพแวดล้อมต่างๆ รวมถึง ClojureScript สำหรับเบราว์เซอร์, Clojure สำหรับ JVM, Babashka สำหรับสคริปต์ และ Jank สำหรับการทำงานร่วมกับ C/C++ ในทำนองเดียวกัน Dart ถูกระบุว่าเป็นภาษาที่มี JIT และสามารถเริ่มต้นได้อย่างรวดเร็วและแปลความหมายในทันที ในขณะที่ยังสามารถคอมไพล์ล่วงหน้าเป็นโค้ดเครื่องที่มีประสิทธิภาพเมื่อคุณพร้อมที่จะส่งมอบ ซึ่งเชื่อมโยงระดับ 2 และ 3 ที่เสนอได้อย่างมีประสิทธิภาพ

กรณีต่อต้านการรวมภาษาแบบบังคับ

ไม่ใช่สมาชิกทุกคนในชุมชนที่กระตือรือร้นกับแนวทางภาษาแบบรวม บางคนโต้แย้งว่าภาษาเฉพาะทางให้ประโยชน์สำคัญที่ไม่ควรถูกสละเพื่อความเป็นเอกภาพทางไวยากรณ์:

โดยเฉพาะอย่างยิ่งเมื่อมี LLM ช่วยเหลือ เราไม่ได้รับประโยชน์มากนักจากการทำให้ทุกอย่างมีไวยากรณ์เดียว ภาษาเดียว ฯลฯ โปรเจกต์เช่น Dotnet Blazor/ASP.NET หรือ Python Streamlit/Dash ตามความเห็นของผม ดูเหมือนถูกบังคับและสร้างปัญหามากกว่าคุ้มค่า ข้อเสนอของผู้เขียนที่ว่าทุกอย่างควรเป็น Rust ก็มีปัญหาเดียวกัน มันถูกบังคับมากเกินไป

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

ระดับการจำแนกภาษาโปรแกรมมิ่ง

• ระดับ 4: แปลความหมายทันที (Interpreted) มีการกำหนดชนิดข้อมูลแบบไดนามิก ( JavaScript , Python , PHP )
• ระดับ 3: แปลความหมายทันที (Interpreted) มีการกำหนดชนิดข้อมูลแบบคงที่ ( Hack , Flow , TypeScript , mypy )
• ระดับ 2: คอมไพล์พร้อมการจัดการหน่วยความจำอัตโนมัติ ( Go , Java , C# , Haskell , Objective-C , Swift )
• ระดับ 1: คอมไพล์พร้อมการจัดการหน่วยความจำด้วยตนเอง ( Rust , C , C++ )

ชุดภาษาที่เสนอ

• Rust: ระดับ 1 - ประสิทธิภาพสูงสุดพร้อมการจัดการหน่วยความจำด้วยตนเอง
• RustGC: ลูกผสมระดับ 2/3 - มีการเก็บขยะ (Garbage collected) พร้อมการคอมไพล์สำหรับการใช้งาน
• RustScript: ระดับ 4 - การกำหนดชนิดข้อมูลแบบไดนามิกสำหรับการสร้างต้นแบบอย่างรวดเร็ว

ความเป็นไปได้ทางเทคนิคและทิศทาง

ข้อมูลเชิงลึกทางเทคนิคที่น่าสนใจจากการอภิปรายเกี่ยวข้องกับทิศทางของความเข้ากันได้ของภาษา ผู้แสดงความคิดเห็นคนหนึ่งสังเกตว่าการแปลความหมายภาษาที่มีข้อจำกัดนั้นง่ายกว่าการคอมไพล์ภาษาแบบไดนามิกที่ออกแบบมาสำหรับตัวแปลความหมาย สิ่งนี้บ่งชี้ว่าการเริ่มต้นด้วยภาษาระดับต่ำเช่น Rust และสร้างรุ่นที่มีระดับสูงกว่า (ตามที่เสนอด้วย RustGC และ RustScript) อาจเป็นไปได้มากกว่าการพยายามทำให้ภาษาเช่น JavaScript หรือ Python สามารถคอมไพล์ได้มากขึ้น

ชุมชนยังได้หารือเกี่ยวกับศักยภาพในการเพิ่มการเก็บขยะอัตโนมัติให้กับ Rust โดยผู้แสดงความคิดเห็นคนหนึ่งแสดงการสนับสนุนอย่างมาก ในขณะที่ยอมรับว่าโค้ด RustGC จะไม่สามารถแปลงเป็น Rust แบบดั้งเดิมได้อย่างง่ายดาย แต่การไปในทิศทางตรงกันข้ามควรจะง่าย

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

อ้างอิง: From Languages to Language Sets