Có những dự án bắt đầu bằng một bản thiết kế hoàn hảo trên giấy. DUY bắt đầu bằng một sự khó chịu dai dẳng.
Tôi đã chứng kiến thế giới phần cứng tiến về phía trước với một tốc độ gần như bất lịch sự. CPU nhiều nhân hơn, dung lượng bộ nhớ lớn hơn, các trình biên dịch thông minh hơn, và AI đã ngồi ngay cạnh lập trình viên như một cộng sự không biết mệt mỏi. Thế nhưng ở tầng sâu nhất của phần mềm hệ thống, chúng ta vẫn đang lặng lẽ trả những món nợ đã ký từ nửa thế kỷ trước.
Điều đó không có nghĩa thế hệ tiền nhân đã sai. Ngược lại, họ giỏi đến mức các quyết định của họ đã sống lâu hơn cả những cỗ máy mà chúng được tạo ra để phục vụ ban đầu. Nhưng một thỏa hiệp vĩ đại trong hoàn cảnh cũ không tự động trở thành giải pháp tối ưu cho mọi hoàn cảnh mới.
DUY sinh ra trong khe hở ấy: giữa lòng biết ơn lịch sử và quyền được đặt lại những câu hỏi nền tảng.
Câu hỏi đầu tiên của tôi rất đơn giản, theo kiểu đơn giản thường khiến một lập trình viên phải đánh đổi vài năm cuộc đời chỉ để đi tìm câu trả lời:
Tại sao phần cứng đã mạnh mẽ đến mức này, mà việc viết phần mềm hệ thống vẫn là một hành trình đầy rủi ro, rối rắm và dễ sai sót đến thế?
Một chiếc máy tính hiện đại có thể thực hiện hàng tỷ phép tính mỗi giây. Nó dự đoán rẽ nhánh, tự động đổi thứ tự lệnh thực thi, quản lý nhiều tầng cache phức tạp và chạy hàng chục luồng song song. Nhưng một lập trình viên vẫn có thể làm hỏng cả hệ thống chỉ vì giữ một con trỏ lâu hơn đối tượng mà nó trỏ tới. Cỗ máy rất thông minh, nhưng hợp đồng an toàn giữa con người và cỗ máy thì đôi lúc vẫn giống một tờ giấy viết tay để quên trong ngăn kéo.
Khi bắt đầu DUY, tôi không muốn lãng phí thời gian vào việc chọn dấu ngoặc, từ khóa hay màu sắc logo. Những việc ấy tuy vui nhưng giống như đi chọn rèm cửa khi nền móng nhà còn chưa đổ bê tông. Vấn đề thật sự không nằm ở cú pháp bề ngoài, nó nằm ở những câu hỏi cốt lõi mà trình biên dịch có đủ dũng cảm để hỏi và chứng minh trước khi chương trình được chạy:
- Dữ liệu này thuộc về ai?
- Hàm này có cấp phát bộ nhớ động không?
- Lời gọi này có thực hiện I/O hay làm thay đổi trạng thái toàn cục không?
- Tham chiếu mượn này còn hợp lệ đến lúc nào?
- Đoạn mã nguy hiểm nằm chính xác ở đâu và có biển báo không?
Tôi gọi đó là câu hỏi điên rồ vì lịch sử ngôn ngữ lập trình không thiếu những nghĩa địa được lát bằng ý tưởng đẹp. Làm một bộ phân tích cú pháp (parser) nhỏ thì dễ. Làm một ngôn ngữ mà người khác tin tưởng để đặt dữ liệu, dịch vụ hay thiết bị của họ vào đó là một câu chuyện hoàn toàn khác.
Nhưng một câu hỏi lớn không bắt ta phải có ngay câu trả lời khổng lồ. Nó chỉ bắt ta chọn một thí nghiệm đủ nhỏ để không thể trốn sau lời hứa.
Và để chọn được thí nghiệm ấy, tôi phải quay lại nơi phần lớn câu chuyện bắt đầu: Assembly và C.
Bình luận (0)
Đang tải bình luận...