Bài giảng nổi tiếng The Humble Programmer trong lễ trao giải Turing Award năm 1972 của Edsger Dijkstra tiếp tục khơi dậy những cuộc thảo luận sôi nổi trong cộng đồng nhà phát triển, với nhiều người nhận thấy những cảnh báo của ông về độ phức tạp trong lập trình có sự liên quan đáng ngạc nhiên đến những thách thức phát triển phần mềm ngày nay. Những quan sát của nhà khoa học máy tính huyền thoại này về độ phức tạp phần cứng, thiết kế ngôn ngữ và kỷ luật nghề nghiệp dường như đã dự đoán được nhiều khó khăn mà các lập trình viên hiện đại phải đối mặt hàng ngày.
Độ phức tạp phần cứng tạo ra những vấn đề mới thay vì giải quyết những vấn đề cũ
Quan sát của Dijkstra rằng ngành công nghiệp điện tử không hề giải quyết được một vấn đề nào, nó chỉ tạo ra chúng, có tiếng vang mạnh mẽ với các nhà phát triển ngày nay. Cộng đồng chỉ ra các hệ thống phân cấp bộ nhớ hiện đại như một ví dụ hoàn hảo - trong khi chúng ta hiện có bộ nhớ đệm L1 cực kỳ nhanh chạy ở tốc độ nano giây, chúng ta cũng phải đối phó với bộ nhớ lưu trữ lạnh có thể mất cả ngày để truy cập. Khoảng cách độ trễ cực lớn này khiến việc tối ưu hóa trở nên quan trọng hơn bao giờ hết.
Cuộc cách mạng đa lõi đã thêm một lớp phức tạp khác mà Dijkstra không thể dự đoán hoàn toàn. Các nhà phát triển hiện đại phải liên tục suy nghĩ về tranh chấp luồng và vị trí bộ nhớ để đạt được hiệu suất tốt. Một số nhà phát triển ủng hộ việc luôn ghi nhớ nhiệt độ trung bình của bộ nhớ đệm L1, lập luận rằng nếu bạn có thể giữ tập dữ liệu làm việc của mình ấm trong bộ nhớ đệm L1, hầu hết các mối quan tâm về hiệu suất khác sẽ trở thành thứ yếu.
Phạm Vi Độ Trễ Của Hệ Thống Phân Cấp Bộ Nhớ (Hệ Thống Hiện Đại)
- Bộ nhớ đệm L1: Thời gian truy cập tính bằng nano giây
- Lưu trữ lạnh/Băng từ: Thời gian truy cập lên đến 24 giờ
- Khoảng chênh lệch độ trễ cực đại: 6+ bậc độ lớn
Thiết kế ngôn ngữ lập trình vẫn vật lộn với độ phức tạp baroque
Lời chỉ trích của Dijkstra về các ngôn ngữ lập trình quá phức tạp như PL/I, mà ông so sánh với việc lái máy bay có 700 nút, công tắc và tay cầm, tìm thấy những mục tiêu mới trong bối cảnh phát triển ngày nay. Các cuộc thảo luận cộng đồng tiết lộ những thất vọng tương tự với các ngôn ngữ hiện đại tiếp tục thêm các tính năng thay vì tập trung vào sự đơn giản và rõ ràng.
Cuộc tranh luận mở rộng đến các ngôn ngữ phổ biến như Java và C++, với các nhà phát triển lưu ý cách những ngôn ngữ này tiếp tục tích lũy các tính năng và công cụ mới, tạo ra những gì một số người gọi là quái vật baroque. Điều này phản ánh mối quan tâm của Dijkstra về các ngôn ngữ ưu tiên tính đầy đủ tính năng hơn khả năng quản lý trí tuệ.
Các Ngôn Ngữ Lập Trình Được Đề Cập Trong Bối Cảnh Lịch Sử
- FORTRAN : Bị chỉ trích là phương tiện tư duy lỗi thời (1972)
- LISP : "Cách thông minh nhất để sử dụng sai máy tính"
- ALGOL 60 : Được khen ngợi vì định nghĩa độc lập với việc triển khai
- PL/I : Bị chỉ trích là "quái vật baroque" quá phức tạp
Phương pháp hình thức và phát triển dựa trên chứng minh có ý nghĩa mới
Một trong những ý tưởng tiến bộ nhất của Dijkstra là yêu cầu các lập trình viên chứng minh rằng các vòng lặp của họ kết thúc và duy trì các bất biến thích hợp. Trong khi điều này có vẻ không thực tế vào năm 1972, các công cụ hiện đại như Coq và Dafny hiện giờ làm cho việc xác minh hình thức như vậy trở nên khả thi ở cấp độ trình biên dịch.
Cộng đồng thấy tiềm năng cho sự hồi sinh của các phương pháp hình thức, đặc biệt với sự hỗ trợ của AI làm giảm đáng kể chi phí hình thức hóa và chứng minh. Một số nhà phát triển tin rằng chất lượng mã có thể chứng minh có thể trở thành yếu tố phân biệt chính khi mã được tạo bởi AI trở nên phổ biến hơn, làm cho các chương trình được xác minh hình thức nổi bật trong biển phần mềm được tạo tự động.
Các Công Cụ Xác Minh Hình Thức Hiện Đại
- Coq : Thực thi các chứng minh kết thúc vòng lặp
- Dafny : Kiểm tra bất biến ở cấp độ trình biên dịch
- Cả hai đều hy sinh tính đầy đủ Turing để đạt được tính đúng đắn có thể chứng minh
Cuộc đấu tranh vĩnh cửu giữa các thủ thuật thông minh và mã rõ ràng
Dijkstra cảnh báo chống lại các lập trình viên có tư duy giải đố và rất thích các thủ thuật thông minh, thay vào đó ủng hộ mã rõ ràng, dễ hiểu. Sự căng thẳng này vẫn tồn tại ngày nay, đặc biệt với các trình biên dịch Just-In-Time (JIT) có thể tối ưu hóa mã phức tạp trong thời gian chạy.
Nhưng họ không thể giải thích tại sao những đồng nghiệp tội nghiệp phải đọc và bảo trì mã không xứng đáng được quan tâm như máy móc!
Trong khi tối ưu hóa JIT cho phép các nhà phát triển viết mã đơn giản hơn mà không hy sinh hiệu suất, một số lập trình viên sử dụng điều này như một cái cớ để viết mã phức tạp không cần thiết, giả định rằng trình biên dịch sẽ sửa chữa những kém hiệu quả của họ.
Kỷ luật nghề nghiệp vẫn quan trọng như bao giờ
Có lẽ đáng chú ý nhất, lời kêu gọi của Dijkstra để lập trình trở thành một nghề có kỷ luật hơn tiếp tục có tiếng vang. Quan sát của ông rằng xã hội đang trở nên không hài lòng với hiệu suất của các lập trình viên và sản phẩm của họ trong những năm 1960 nghe quen thuộc với bất kỳ ai theo dõi các cuộc tranh luận hiện tại về chất lượng và độ tin cậy phần mềm.
Cộng đồng lưu ý rằng bất chấp nhiều thập kỷ tiến bộ, nhiều nhóm vẫn theo đuổi đầu ra nhanh hơn thiết kế sạch, chỉ để đâm vào tường sau này trong quá trình phát triển. Điều này cho thấy thông điệp cơ bản của Dijkstra về nhu cầu kỷ luật trí tuệ trong lập trình vẫn có ý nghĩa ngày nay như 50 năm trước.
Bài giảng của Dijkstra vừa là một tài liệu lịch sử vừa là một bình luận đáng ngạc nhiên về những thách thức mà phát triển phần mềm hiện đại đang đối mặt. Sự nhấn mạnh của ông về khiêm tốn, kỷ luật và tư duy rõ ràng hơn các thủ thuật thông minh tiếp tục cung cấp hướng dẫn có giá trị cho các lập trình viên ngày nay đang điều hướng trong bối cảnh công nghệ ngày càng phức tạp.
Tham khảo: The Humble Programmer