Tập 11: Người viết ra C đã làm gì?

Muốn tạo ra một ngôn ngữ mới, trước hết phải đủ khiêm tốn để hiểu vì sao những ngôn ngữ cũ vẫn kiên cường tồn tại.

Sau khi đặt tên DUY và viết xuống lời hứa source -> compiler -> binary, tôi có một cảm giác rất dễ gây nghiện: cảm giác mình đang bắt đầu một điều hoàn toàn mới, một kỷ nguyên chưa ai chạm tới.

Thực ra, không có gì hoàn toàn mới cả.

Mỗi ý tưởng tôi thấy đẹp đều đã thấp thoáng xuất hiện ở đâu đó trong lịch sử điện toán. Quyền sở hữu (Ownership) có gốc rễ từ Rust. Phân vùng bộ nhớ (Region) kế thừa từ Cyclone và nhiều thế hệ nghiên cứu học thuật trước đó. Hệ thống hiệu ứng (Effects) chịu ảnh hưởng từ Koka, Eff và cả một dòng chảy tư duy hàm dài lâu. LLVM đã biến backend của trình biên dịch thành một hạ tầng dùng chung cho nhân loại. CompCert chứng minh rằng compiler hoàn toàn có thể được kiểm chứng bằng toán học. seL4 cho thấy một nhân hệ điều hành thực tế cũng có thể đi rất xa trên con đường formal verification.

Nhận ra điều ấy không làm DUY nhỏ bé đi. Nó chỉ đặt DUY về đúng kích thước thực tế của mình. Và khi đứng ở đúng kích thước thực tế, tôi bắt đầu học hỏi được nhiều điều hơn.



Tôi từng hình dung việc tạo một ngôn ngữ lập trình giống như việc ngồi trước một trang giấy trắng, thiết kế ra một bộ cú pháp thật đẹp rồi cặm cụi viết compiler cho nó. Câu chuyện của ngôn ngữ C khiến cách nghĩ ấy trông thật ngây thơ.

Dennis Ritchie không tạo ra C trong một phòng thí nghiệm tách biệt hoàn toàn khỏi đời sống. C ra đời cùng những năm tháng đầu tiên của Unix, trong một môi trường máy tính chật chội đến mức mỗi quyết định thiết kế đều phải trả giá bằng byte bộ nhớ, thời gian CPU và công sức cổng nạp hệ thống. Theo chính các ghi chép lịch sử của Ritchie, C hình thành trong giai đoạn 1969-1973, với thời kỳ sáng tạo mạnh mẽ nhất vào năm 1972. C không sinh ra để chiến thắng một cuộc thi thiết kế cú pháp. Nó sinh ra để giải quyết một công việc cực kỳ cụ thể: làm ngôn ngữ triển khai thực tế cho một hệ điều hành đang lớn lên từng ngày.

Điều làm tôi khâm phục nhất không phải là bất kỳ một từ khóa hay toán tử nào. Đó là cách C gắn chặt số phận của ngôn ngữ với một hệ thống thực tế. Unix tạo áp lực buộc C phải hữu dụng từng giờ. C ngược lại giúp Unix thoát khỏi sự lệ thuộc nặng nề vào một loại máy tính cụ thể. Hai thực thể này kéo nhau cùng trưởng thành qua các mùa sprint.

Bất kỳ ai từng làm sản phẩm đủ lâu đều hiểu rõ giá trị của áp lực thực tế này. Khi không có người dùng và không có hệ thống thật chạy bên dưới, ta rất dễ sa vào việc say mê các trường hợp biên hiếm gặp, các trừu tượng tinh xảo và các cuộc tranh luận cú pháp đẹp mắt kéo dài vô tận qua ba cuộc họp. Một chương trình thực tế thì thô lỗ hơn nhiều. Nó chỉ hỏi: có đọc được file không, có quản lý được tiến trình không, có chạy ổn định trên cấu hình máy kia không, và vì sao lại crash lúc hai giờ sáng?

C trả lời xuất sắc những câu hỏi ấy. Nó đưa ra một mô hình nhỏ gọn, gần sát máy, đủ linh hoạt để người viết hệ điều hành dễ dàng biểu diễn layout bộ nhớ, địa chỉ, cấu trúc dữ liệu và lời gọi thủ tục mà không bắt buộc phải viết mọi thứ bằng assembly thủ công. Cái giá phải trả là rất nhiều trách nhiệm quản lý bộ nhớ được chuyển sang đôi vai lập trình viên. Nhưng trong hoàn cảnh phần cứng thô sơ khi đó, lựa chọn ấy không hề ngốc nghếch. Nó là một thỏa hiệp sáng suốt bậc nhất.

Đọc lịch sử C, tôi thấy mình bớt đi cái khao khát ngạo mạn muốn “sửa sai cho tiền nhân”. Thế hệ đi trước không thiếu thông minh; họ chỉ thiếu những thứ mà chúng ta đang may mắn có hôm nay: tài nguyên phần cứng dư dả hơn, nhiều thập kỷ nghiên cứu học thuật về hệ thống kiểu, hạ tầng backend compiler hiện đại, hàng núi mã nguồn mở và các trợ lý AI thông thái. Nếu sở hữu tất cả lợi thế ấy mà ta chỉ tạo ra được một bộ dấu ngoặc mới, lỗi hoàn toàn nằm ở chúng ta.

Bài học đầu tiên cho DUY vì thế không phải là đi bắt chước cú pháp của C. Bài học đúng đắn là gắn ngôn ngữ mới với một nhu cầu thực tế. DUY cần những chương trình chạy thật, một compiler thật và cuối cùng là các môi trường thử nghiệm đủ khắc nghiệt. Chúng sẽ không cho phép thiết kế của DUY lẩn trốn trong những slide trình diễn đẹp đẽ.

Ritchie và các đồng nghiệp đã không chỉ viết ra một ngôn ngữ lập trình. Họ tạo ra một vòng phản hồi khép kín (feedback loop) giữa ngôn ngữ và hệ thống. DUY cũng cần một vòng phản hồi thực tế như thế để sinh tồn.


Bình luận (0)

Đang tải bình luận...