ภาษาโปรแกรม Zig ได้จุดประกายการอย่างดุเดือดในชุมชนนักพัฒนาซอฟต์แวร์ หลังจากมีการวิเคราะห์อย่างละเอียดเกี่ยวกับการเลือกใช้การออกแบบ syntax ในขณะที่นักพัฒนาบางคนชื่นชมความสม่ำเสมอและความสามารถในการอ่านได้ของภาษานี้ แต่บางคนกลับพบว่าการตัดสินใจออกแบบบางอย่างเป็นที่ถกเถียงและยากต่อการใช้งาน
Multiline String Syntax แบ่งความคิดเห็น
แนวทางของ Zig ในการจัดการ multiline strings กลายเป็นหนึ่งในหัวข้อที่ถกเถียงกันมากที่สุดในการอภิปราย ภาษานี้ใช้ syntax ที่เป็นเอกลักษณ์ซึ่งแต่ละบรรทัดของ multiline string จะต้องมี \\ นำหน้า ทำให้สามารถจัดย่อหน้าได้อย่างเหมาะสมโดยไม่ให้ช่องว่างด้านหน้ากลายเป็นส่วนหนึ่งของเนื้อหา string การออกแบบนี้แก้ปัญหาทั่วไปในภาษาอื่นๆ ที่ multiline strings มักจะดูไม่เหมาะสมใน source code หรือมีช่องว่างที่ไม่ต้องการ
อย่างไรก็ตาม นักพัฒนาหลายคนพบว่า syntax นี้ดูแปลกตาในการมองครั้งแรก การใช้ backslash prefix ซ้ำๆ อาจทำให้โค้ดดูยุ่งเหยิง โดยเฉพาะเมื่อเปรียบเทียบกับแนวทางแบบดั้งเดิมอย่าง triple-quoted strings ใน Python หรือ raw strings ในภาษาอื่นๆ แม้จะมีการต่อต้านในตอนแรก แต่นักพัฒนาบางคนรายงานว่า syntax นี้เริ่มถูกใจเมื่อใช้งานไปเรื่อยๆ โดยเฉพาะเมื่อทำงานกับ embedded code หรือการจัดรูปแบบข้อความที่ซับซ้อน
การเปรียบเทียบไวยากรณ์ Zig กับภาษาอื่นๆ
| คุณสมบัติ | Zig | Rust | Go | Kotlin |
|---|---|---|---|---|
| การประกาศตัวแปร | const x: i32 = 1 |
let x: i32 = 1 |
var x int = 1 |
val x: Int = 1 |
| การประกาศฟังก์ชัน | fn add(x: i32) i32 |
fn add(x: i32) -> i32 |
func add(x int) int |
fun add(x: Int): Int |
| สตริงหลายบรรทัด | \\line1\n\\line2 |
r"line1\nline2" |
`line1\nline2` |
"""line1\nline2""" |
| Struct Literals | .{ .x = 1, .y = 2 } |
Point { x: 1, y: 2 } |
Point{x: 1, y: 2} |
Point(x = 1, y = 2) |
| คำสำคัญ | const, var, fn |
let, mut, fn |
var, const, func |
val, var, fun |
ความสมดุลระหว่าง Type Inference และ Explicit Syntax
ชุมชนแบ่งออกเป็นสองฝ่ายเรื่องแนวทางของ Zig ในการสร้างความสมดุลระหว่าง explicit syntax กับ type inference ภาษานี้ต้องการ explicit type annotations ในหลายกรณีที่ภาษาสมัยใหม่อื่นๆ จะ infer types โดยอัตโนมัติ ตัวอย่างเช่น การเขียน const i = 1 โดยไม่มี type annotation จะไม่ทำงานในหลายบริบท ทำให้นักพัฒนาต้องเขียน const i: i32 = 1 แทน
ปรัชญาการออกแบบนี้ขยายไปถึง struct initialization ที่ Zig ใช้ syntax .{} ที่โดดเด่นสำหรับ type-inferred literals แม้ว่าสิ่งนี้จะช่วยให้การ initialization โครงสร้างแบบซ้อนกันสะอาดกว่าเมื่อเปรียบเทียบกับภาษาอย่าง Rust แต่นักพัฒนาบางคนพบว่า dot prefix ไม่จำเป็นและรบกวนสายตา
ความขัดแย้งเรื่อง Function Declaration Syntax
Function syntax ของ Zig ได้รับการวิพากษ์วิจารณ์ว่าอาจจำกัดฟีเจอร์ภาษาในอนาคต ภาษานี้ใช้ fn name(params) return_type แทนรูปแบบ fn name(params): return_type ที่ใช้กันทั่วไป การเลือกนี้ทำให้นักพัฒนาบางคนโต้แย้งว่าทำให้การเพิ่ม lambda functions ยากขึ้น เนื่องจาก syntax ไม่สามารถรองรับ arrow-style function expressions ได้อย่างง่ายดาย
การถกเถียงนี้สะท้อนความตึงเครียดที่กว้างขึ้นระหว่างปรัชญาการออกแบบภาษาโปรแกรมที่แตกต่างกัน - ว่าควรจะให้ความสำคัญกับความเรียบง่ายของ parser ความสม่ำเสมอทางภาพ หรือความสามารถในการขยายในอนาคต
ประเด็นถกเถียงเกี่ยวกับไวยากรณ์ของ Zig ที่สำคัญ
- Multiline Strings: การใช้
\\นำหน้าในแต่ละบรรทัด เทียบกับ triple quotes แบบดั้งเดิม - Type Inference: การอนุมานประเภทข้อมูลอัตโนมัติที่จำกัด ต้องระบุประเภทข้อมูลอย่างชัดเจน
- Function Syntax:
fn name() typeเทียบกับfn name(): type - Struct Literals: ไวยากรณ์
.{}ที่มีจุดนำหน้า - Integer Literals: ระบบประเภทข้อมูลนามธรรมที่ต้องการการแปลงประเภทอย่างชัดเจน
- No Lambdas: มีเพียง function pointers เท่านั้น ไม่มีไวยากรณ์ closure
- Boolean Operators: ใช้คำสำคัญ
and/orแทน&&/||
การแลกเปลี่ยนระหว่าง Performance และ Tooling
นอกเหนือจากความชอบ syntax ล้วนๆ แล้ว การอภิปรายยังเผยให้เห็นความกังวลที่ลึกซึ้งกว่าเกี่ยวกับการแลกเปลี่ยนในการออกแบบภาษา นักพัฒนาบางคนกังวลว่าการเลือก syntax บางอย่าง โดยเฉพาะเรื่อง type inference และ compile-time evaluation อาจทำให้การสนับสนุน IDE และ language tooling ยากต่อการใช้งานอย่างมีประสิทธิภาพ
ภาษาที่เป็นศัตรูกับ LSP/intellisense
คนอื่นๆ โต้แย้งว่าความกังวลเหล่านี้เกินจริง โดยชี้ให้เห็นว่า compiler สามารถทำ type inference แบบเดียวกับที่เครื่องมือพัฒนาต้องการได้
ฉันทามติของชุมชนเรื่องจุดแข็ง
แม้จะมีความขัดแย้ง แต่ก็มีความเห็นพ้องต้องกันอย่างกว้างขวางในหลายแง่มุมของการออกแบบ Zig นักพัฒนาส่วนใหญ่ชื่นชมความสม่ำเสมอของภาษาในการปฏิบัติต่อทุกอย่างเป็น expressions การกำจัด hidden control flow และแนวทางที่ตรงไปตรงมาในการจัดการหน่วยความจำ ฟีเจอร์ compile-time ของภาษาและปรัชญาในการทำให้ allocation ชัดเจนก็ได้รับการยกย่องอย่างแพร่หลาย
ลักษณะที่ร้อนแรงของการอภิปรายเหล่านี้สะท้อนให้เห็นการลงทุนอย่างลึกซึ้งของชุมชนโปรแกรมเมอร์ในการออกแบบภาษา แม้ว่าความชอบ syntax จะยังคงเป็นเรื่องส่วนตัวอย่างมาก แต่การถกเถียงเรื่อง Zig ก็เน้นย้ำคำถามสำคัญเกี่ยวกับวิธีที่ภาษาโปรแกรมควรสร้างความสมดุลระหว่างความสามารถในการอ่าน ความสม่ำเสมอ และความง่ายในการใช้งาน
อ้างอิง: Zig's Lovely Syntax