Ngôn ngữ lập trình Zig đã khơi dậy những cuộc thảo luận sôi nổi trong cộng đồng lập trình viên sau một phân tích chi tiết về các lựa chọn thiết kế cú pháp của nó. Trong khi một số lập trình viên ca ngợi tính nhất quán và khả năng đọc hiểu của ngôn ngữ này, những người khác lại thấy một số quyết định thiết kế gây tranh cãi và khó làm việc.
Cú pháp chuỗi nhiều dòng chia rẽ ý kiến
Cách tiếp cận của Zig đối với chuỗi nhiều dòng đã trở thành một trong những chủ đề gây tranh cãi nhất trong cuộc thảo luận. Ngôn ngữ này sử dụng một cú pháp độc đáo trong đó mỗi dòng của chuỗi nhiều dòng phải được đặt tiền tố bằng \\, cho phép thụt lề phù hợp mà không làm cho các khoảng trắng đầu dòng trở thành phần của nội dung chuỗi. Thiết kế này giải quyết một vấn đề phổ biến trong các ngôn ngữ khác, nơi mà chuỗi nhiều dòng hoặc trông kỳ lạ trong mã nguồn hoặc bao gồm khoảng trắng không mong muốn.
Tuy nhiên, nhiều lập trình viên thấy cú pháp này khó chịu khi nhìn lần đầu. Các tiền tố dấu gạch chéo ngược lặp đi lặp lại có thể làm cho mã trông lộn xộn, đặc biệt khi so sánh với các cách tiếp cận truyền thống hơn như chuỗi ba dấu ngoặc kép trong Python hoặc chuỗi thô trong các ngôn ngữ khác. Mặc dù có sự phản kháng ban đầu, một số lập trình viên báo cáo rằng cú pháp này dần trở nên quen thuộc khi sử dụng, đặc biệt khi làm việc với mã nhúng hoặc định dạng văn bản phức tạp.
So sánh cú pháp Zig với các ngôn ngữ khác
| Tính năng | Zig | Rust | Go | Kotlin |
|---|---|---|---|---|
| Khai báo biến | const x: i32 = 1 |
let x: i32 = 1 |
var x int = 1 |
val x: Int = 1 |
| Khai báo hàm | fn add(x: i32) i32 |
fn add(x: i32) -> i32 |
func add(x int) int |
fun add(x: Int): Int |
| Chuỗi nhiều dòng | \\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) |
| Từ khóa | const, var, fn |
let, mut, fn |
var, const, func |
val, var, fun |
Cân bằng giữa suy luận kiểu và cú pháp tường minh
Cộng đồng chia rẽ về cách tiếp cận của Zig trong việc cân bằng cú pháp tường minh với suy luận kiểu. Ngôn ngữ này yêu cầu chú thích kiểu tường minh trong nhiều trường hợp mà các ngôn ngữ hiện đại khác sẽ tự động suy luận kiểu. Ví dụ, việc viết const i = 1 mà không có chú thích kiểu không hoạt động trong nhiều ngữ cảnh, buộc lập trình viên phải viết const i: i32 = 1 thay thế.
Triết lý thiết kế này mở rộng đến khởi tạo struct, nơi Zig sử dụng cú pháp đặc biệt .{} cho các literal được suy luận kiểu. Mặc dù điều này cho phép khởi tạo cấu trúc lồng nhau sạch hơn so với các ngôn ngữ như Rust, một số lập trình viên thấy tiền tố dấu chấm là không cần thiết và gây xao nhãng về mặt thị giác.
Tranh cãi về cú pháp khai báo hàm
Cú pháp hàm của Zig đã bị chỉ trích vì có thể hạn chế các tính năng ngôn ngữ trong tương lai. Ngôn ngữ này sử dụng fn name(params) return_type thay vì mẫu fn name(params): return_type phổ biến hơn. Lựa chọn này đã khiến một số lập trình viên lập luận rằng nó làm cho việc thêm hàm lambda trở nên khó khăn hơn, vì cú pháp không dễ dàng phù hợp với các biểu thức hàm kiểu mũi tên.
Cuộc tranh luận phản ánh những căng thẳng sâu sắc hơn giữa các triết lý thiết kế ngôn ngữ lập trình khác nhau - liệu có nên ưu tiên tính đơn giản của trình phân tích cú pháp, tính nhất quán trực quan, hay khả năng mở rộng trong tương lai.
Các Tranh Cãi Cú Pháp Chính Của Zig
- Chuỗi Nhiều Dòng: Tiền tố
\\trên mỗi dòng thay vì dấu ngoặc kép ba truyền thống - Suy Luận Kiểu: Suy luận tự động hạn chế đòi hỏi các kiểu rõ ràng
- Cú Pháp Hàm:
fn name() typeso vớifn name(): type - Struct Literals: Cú pháp
.{}với tiền tố dấu chấm - Integer Literals: Hệ thống kiểu trừu tượng đòi hỏi ép kiểu rõ ràng
- Không Có Lambda: Chỉ có con trỏ hàm, không có cú pháp closure
- Toán Tử Boolean: Sử dụng từ khóa
and/orthay vì&&/||
Đánh đổi hiệu suất và công cụ
Ngoài các sở thích cú pháp thuần túy, cuộc thảo luận tiết lộ những lo ngại sâu sắc hơn về các đánh đổi trong thiết kế ngôn ngữ. Một số lập trình viên lo lắng rằng một số lựa chọn cú pháp nhất định, đặc biệt là xung quanh suy luận kiểu và đánh giá thời gian biên dịch, có thể làm cho hỗ trợ IDE và công cụ ngôn ngữ trở nên khó triển khai hiệu quả hơn.
Một ngôn ngữ thù địch với LSP/intellisense.
Những người khác lập luận rằng những lo ngại này bị thổi phồng, chỉ ra rằng trình biên dịch có thể thực hiện cùng một suy luận kiểu mà các công cụ phát triển sẽ cần.
Sự đồng thuận của cộng đồng về điểm mạnh
Mặc dù có những tranh cãi, có sự đồng thuận rộng rãi về một số khía cạnh của thiết kế Zig. Hầu hết các lập trình viên đánh giá cao tính nhất quán của ngôn ngữ trong việc xử lý mọi thứ như các biểu thức, việc loại bỏ luồng điều khiển ẩn, và cách tiếp cận đơn giản đối với quản lý bộ nhớ. Các tính năng thời gian biên dịch của ngôn ngữ và triết lý làm cho việc phân bổ trở nên tường minh cũng nhận được sự ca ngợi rộng rãi.
Bản chất gay gắt của những cuộc thảo luận này phản ánh sự đầu tư sâu sắc của cộng đồng lập trình vào thiết kế ngôn ngữ. Mặc dù sở thích cú pháp vẫn mang tính chủ quan cao, cuộc tranh luận xung quanh Zig làm nổi bật những câu hỏi quan trọng về cách các ngôn ngữ lập trình nên cân bằng khả năng đọc hiểu, tính nhất quán và dễ triển khai.
Tham khảo: Zig's Lovely Syntax