Trong thế giới lập trình, rất ít chủ đề có thể tạo ra nhiều cuộc tranh luận sôi nổi như phong cách viết code. Gần đây, cộng đồng công nghệ đang thảo luận sôi nổi về công trình của Arthur Whitney, nhà khoa học máy tính đứng sau các ngôn ngữ lập trình có ảnh hưởng như K và Q, cùng các cơ sở dữ liệu hiệu năng cao bao gồm Kdb+. Cuộc trò chuyện không tập trung vào bản thân các ngôn ngữ của ông, mà là ở phong cách viết code C nổi tiếng là dày đặc và ngắn gọn của ông, có thể gói gọn toàn bộ trình thông dịch chỉ trong vài chục dòng.
Cuộc thảo luận được châm ngòi bởi một phân tích chi tiết về mã C của Whitney được công khai cho một trình thông dịch đơn giản, được viết theo phong cách mà nhiều người mô tả là gần như không thể hiểu nổi. Đoạn mã này minh họa cho cách tiếp cận của Whitney: sử dụng nhiều macro ký tự đơn, khoảng trắng tối thiểu, và toàn bộ hàm được thu gọn thành một dòng duy nhất. Khi các nhà phát triển xem xét phương pháp viết code gây tranh cãi này, họ đang đặt ra những câu hỏi cơ bản về việc điều gì cấu thành nên một mã code tốt và liệu sự ngắn gọn tột độ có phải trả giá quá đắt hay không.
Sức hút của Mật độ và Lập trình Trên Một Màn Hình
Triết lý viết code của Arthur Whitney xoay quanh việc giữ toàn bộ các đơn vị logic hiển thị trên một màn hình. Cách tiếp cận này đã thu hút sự quan tâm đáng kể từ các nhà phát triển, những người đang vật lộn với việc điều hướng các codebase khổng lồ. Cộng đồng công nhận rằng phong cách của Whitney đại diện cho một nỗ lực có chủ đích để quản lý sự phức tạp thông qua sự súc tích cực độ thay vì trải rộng nó ra nhiều tệp và hàm khác nhau.
Mật độ của nó cao gấp nhiều lần so với hầu hết các chương trình C, nhưng đó không phải là trở ngại lớn để hiểu nếu bạn không cố 'đọc lướt' nó; bạn cần đọc nó từng ký tự một từ trên xuống dưới.
Nhiều nhà phát triển thừa nhận rằng một khi bạn đã điều chỉnh theo sự dày đặc, sẽ có một sự tinh tế nhất định trong việc có toàn bộ mã code liên quan hiển thị ngay lập tức. Điều này loại bỏ gánh nặng nhận thức khi phải cuộn qua hàng ngàn dòng để hiểu cách các phần khác nhau của một hệ thống tương tác với nhau. Phong cách này đặc biệt hấp dẫn những người làm việc trên các hệ thống toán học hoặc tài chính phức tạp, nơi việc nhìn thấy bức tranh tổng thể là quan trọng nhất.
Mối lo ngại về Cơn ác mộng Bảo trì
Bất chấp sức hút trí tuệ, các lập trình viên C có kinh nghiệm bày tỏ những lo ngại nghiêm trọng về các hệ quả thực tế của mã code dày đặc như vậy. Việc phụ thuộc nhiều vào macro tiền xử lý C tạo ra thứ mà nhiều người coi là một mớ hỗn độn không thể bảo trì. Khi các macro định nghĩa lại các cấu trúc ngôn ngữ cơ bản và đưa vào các biến ngầm định, họ lập luận, kết quả trở thành một ngôn ngữ dành riêng cho miền mới được xây dựng trên nền tảng C.
Các nhà phát triển kỳ cựu chỉ ra rằng phong cách này vi phạm các nguyên tắc cơ bản của kỹ thuật phần mềm. Việc thiếu tên mô tả, không có chú thích và sự ngắn gọn cực độ khiến mã code gần như không thể hiểu và sửa đổi đối với bất kỳ ai ngoại trừ tác giả ban đầu. Như một bình luận đã nhận xét, cách tiếp cận này giả định rằng bạn sẽ luôn nhớ chính xác những gì mình đã xây dựng — một giả định nguy hiểm trong bất kỳ môi trường phát triển phần mềm chuyên nghiệp nào.
Những thách thức gỡ lỗi đặc biệt khó khăn. Khi mỗi dòng chứa nhiều thao tác và bộ tiền xử lý đã biến đổi C đơn giản thành một thứ hoàn toàn khác, việc xác định và sửa lỗi trở nên khó khăn theo cấp số nhân. Điều này trở nên cực kỳ quan trọng trong các hệ thống tài chính nơi các công nghệ của Whitney được triển khai.
Những Chỉ Trích Phổ Biến Về Phong Cách Lập Trình Của Whitney:
- Phụ thuộc quá nhiều vào macro tiền xử lý C tạo ra một DSL
- Tên biến và hàm chỉ có một ký tự
- Thiếu chú thích và tài liệu hướng dẫn
- Toàn bộ hàm được viết trên một dòng duy nhất
- Tham số ngầm định và phụ thuộc biến không rõ ràng
- Khó khăn trong việc gỡ lỗi và bảo trì
- Các phần mở rộng C không chuẩn hạn chế tính khả chuyển
Ảnh hưởng từ APL hay Sự khác biệt Cá nhân?
Cộng đồng bị chia rẽ về việc liệu phong cách C của Whitney có đại diện cho một sự mở rộng của các nguyên tắc lập trình APL hay đơn giản chỉ là sở thích cá nhân. Một số cho rằng về cơ bản ông ấy đang viết APL bằng cách sử dụng cú pháp C, mang theo bản chất ký hiệu dày đặc của các ngôn ngữ lập trình mảng vào mã triển khai của mình. Những người khác phản bác rằng phong cách ít liên quan đến bản thân APL mà liên quan nhiều hơn đến cách tiếp cận giải quyết vấn đề cá nhân của Whitney.
Điều rõ ràng là phong cách này đã nhất quán một cách đáng chú ý trong nhiều thập kỷ làm việc của Whitney, từ các trình thông dịch J đầu tiên đến các triển khai K hiện tại. Sự nhất quán này cho thấy cách tiếp cận là có chủ đích chứ không phải ngẫu nhiên. Tuy nhiên, như một bình luận đã quan sát, ngay cả trong cộng đồng APL, phong cách C của Whitney cũng được coi là cực đoan chứ không phải là đại diện cho thực hành phổ biến.
Cuộc tranh luận Kỹ thuật và Nghệ thuật
Ở cốt lõi, cuộc thảo luận phản ánh một sự căng thẳng cơ bản trong phát triển phần mềm: mã code nên được coi là một tạo tác kỹ thuật hay là sự biểu đạt cá nhân? Những người ủng hộ cách tiếp cận của Whitney đánh giá cao vẻ đẹp toán học và hiệu quả của mã code dày đặc. Họ xem nó như một thành tựu trí tuệ thể hiện sự hiểu biết sâu sắc về cả miền vấn đề và ngôn ngữ lập trình.
Những người chỉ trích phản bác rằng phát triển phần mềm chuyên nghiệp đòi hỏi sự hợp tác và khả năng bảo trì trên hết. Họ chỉ ra Định luật Kernighan: Gỡ lỗi khó gấp đôi so với viết chương trình ngay từ đầu. Vì vậy, nếu bạn viết nó một cách thông minh nhất có thể, làm thế nào bạn có thể gỡ lỗi nó? Nguyên tắc này gợi ý rằng mã code nên ưu tiên sự rõ ràng hơn là sự khéo léo, đặc biệt là trong các hệ thống sản xuất xử lý giá trị tài chính đáng kể.
Cuộc trò chuyện cũng đề cập đến động lực nhóm và chuyển giao kiến thức. Mã code dày đặc như vậy tạo ra thứ mà một số người gọi là bảo đảm công việc thông qua sự khó hiểu — khiến bản thân không thể thay thế bằng cách viết mã code khó hiểu. Mặc dù điều này có thể mang lại lợi ích cho các lập trình viên cá nhân trong ngắn hạn, nó tạo ra rủi ro đáng kể cho các tổ chức cần duy trì các hệ thống quan trọng trong dài hạn.
Bối cảnh Hiện đại và Hàm ý về AI
Thú vị là, cuộc thảo luận đã trở nên phù hợp mới trong thời đại của các trợ lý mã hóa AI. Một số nhà phát triển lo ngại rằng khi ngày càng nhiều mã code được viết với sự trợ giúp của AI, chúng ta có thể thấy sự gia tăng của mã code khó hiểu, gây khó khăn cho con người trong việc hiểu và sửa đổi. Phong cách Whitney đại diện cho một ví dụ cực đoan về những gì có thể xảy ra khi mã code ưu tiên sự ngắn gọn hơn là giao tiếp.
Những người khác nhìn thấy giá trị tiềm năng trong việc nghiên cứu phong cách này như một ví dụ về cách diễn đạt các ý tưởng phức tạp một cách súc tích. Ngay cả khi hầu hết các nhà phát triển không nên bắt chước cách tiếp cận của Whitney một cách trực tiếp, việc hiểu nó có thể giúp cải thiện cách chúng ta suy nghĩ về tổ chức và trừu tượng hóa mã code trong các phong cách lập trình thông thường hơn.
Các Ngôn ngữ Lập trình và Cơ sở Dữ liệu Chính của Arthur Whitney:
- Ngôn ngữ lập trình A, K, Q: Các ngôn ngữ lập trình mảng được sử dụng rộng rãi trong lĩnh vực tài chính
- Kdb+: Cơ sở dữ liệu hiệu suất cao được xây dựng trên một tập hợp con của K
- Shakti: Phiên bản kế thừa của Kdb+, được thiết kế cho các tập dữ liệu micro-row
- J: Ngôn ngữ lập trình mảng mã nguồn mở (phiên bản triển khai đầu tiên)
Kết luận
Cuộc tranh luận đang diễn ra về phong cách viết code C của Arthur Whitney tiết lộ những câu hỏi sâu sắc hơn về điều gì tạo nên một mã code tốt. Mặc dù hầu hết các nhà phát triển đồng ý rằng cách tiếp cận của ông không phù hợp cho phát triển phần mềm theo nhóm, nhiều người thừa nhận thành tựu trí tuệ mà nó đại diện. Phong cách này chứng minh rằng các chức năng quan trọng có thể được diễn đạt với sự tiết kiệm đáng chú ý, ngay cả khi sự tiết kiệm đó phải trả giá bằng khả năng tiếp cận.
Như một bình luận đã tóm tắt hoàn hảo các ý kiến trái chiều: một số người thấy nó tương đương với việc đọc necronomicon và mắc bệnh điên cuồng vũ trụ, trong khi những người khác đánh giá cao cách phong cách này dường như 'leo thang thang trừu tượng' rất nhanh. Cuối cùng, cuộc thảo luận đóng vai trò như một lời nhắc nhở quý giá rằng phong cách viết code liên quan đến sự đánh đổi giữa tính ngắn gọn, sự rõ ràng và khả năng bảo trì — những sự đánh đổi mà mọi nhóm phát triển phải cân nhắc dựa trên bối cảnh và yêu cầu cụ thể của họ.
Tham khảo: Learning to read Arthur Whitney's C to become Smart