Định luật Wirth, hay vì sao phần mềm ngày càng chậm

Năm 1995, Niklaus Wirth — cha đẻ của Pascal — viết một bài báo cáu kỉnh có tên A Plea for Lean Software. Quan sát của ông sau này được gọi là định luật Wirth: phần mềm chậm đi nhanh hơn phần cứng nhanh lên.

Ba mươi năm sau, định luật ấy vẫn đúng một cách đáng xấu hổ. Chiếc máy tính tôi đang dùng mạnh hơn máy thời Wirth hàng nghìn lần, nhưng mở một ứng dụng chat viết bằng Electron vẫn mất vài giây, và một trang tin tức vẫn tải chục megabyte JavaScript chỉ để hiển thị chữ.

Đây không phải tai nạn — đây là lựa chọn

Sẽ dễ dàng nếu đổ lỗi cho lập trình viên lười. Nhưng sự thật thú vị hơn: phần mềm chậm là kết quả của những đánh đổi hợp lý ở từng bước.

Mỗi lớp trừu tượng — framework, thư viện, container ảo hoá, trình duyệt nhúng — đều mua một thứ rất đắt bằng một thứ rất rẻ: mua thời gian phát triển bằng chu kỳ CPU. Và trong ba mươi năm qua, chu kỳ CPU liên tục rẻ đi còn giờ công kỹ sư liên tục đắt lên. Electron tồn tại không phải vì ai đó thích tốn RAM, mà vì viết một lần chạy ba hệ điều hành là lời đề nghị không thể từ chối với một startup mười người.

Nói cách khác: định luật Wirth không mô tả sự suy đồi kỹ thuật. Nó mô tả một thị trường đang định giá lại — và tốc độ phần mềm là thứ bị định giá thấp.

Cái giá không hiện trên hoá đơn

Vấn đề là chi phí ấy không biến mất; nó được chuyển cho người khác. Mỗi giây chờ đợi nhân với hàng triệu người dùng là hàng nghìn giờ người bị đốt mỗi ngày. Pin điện thoại cạn nhanh hơn, máy cũ bị đào thải sớm hơn, và những người dùng ở nơi mạng chậm, máy yếu — thường là những người ít tiền nhất — trả giá đắt nhất cho quyết định "cứ dùng framework cho nhanh" của một team ở nơi ai cũng cầm máy đời mới.

Hiệu năng, hoá ra, cũng là một vấn đề công bằng.

Sống thế nào với định luật Wirth

Tôi không nghĩ lời giải là "quay về viết assembly". Trừu tượng hoá là thành tựu, không phải tội lỗi. Nhưng có vài nguyên tắc tôi cố giữ:

1. Đo trước khi tin. Cảm giác "chỗ này chậm" của lập trình viên sai thường xuyên đến mức buồn cười. Profiler rẻ hơn phỏng đoán.
2. Phân biệt trừu tượng trả phí một lần và trả phí mỗi lần. Một build tool chậm thì khó chịu; một vòng lặp render chậm thì người dùng trả tiền mãi mãi.
3. Coi tốc độ là tính năng. Không phải tối ưu sau cùng, mà là yêu cầu ghi trong spec, có ngân sách (performance budget) như mọi tính năng khác.

Wirth kết thúc bài báo năm 1995 bằng lời kêu gọi về "phần mềm tinh gọn" như một giá trị đạo đức nghề nghiệp. Ba mươi năm sau, có lẽ nên nói nhẹ hơn: tinh gọn không cần là đạo đức. Chỉ cần nhớ rằng mỗi lớp trừu tượng là một món nợ — và người trả nợ thường không phải người vay.