08/10/2026 · VietTechies · Biên tập
Đầu thập niên 1970, Dennis Ritchie không ngồi ở Bell Labs với mục tiêu tạo ra một ngôn ngữ “dành cho toàn bộ ngành phần mềm”. Bài toán trước mắt nhỏ hơn nhiều: làm thế nào để xây và phát triển một hệ điều hành mà không khóa mọi ý tưởng quan trọng vào đúng một loại máy.
Câu trả lời dần trở thành C. Người ta thường tóm tắt ảnh hưởng của C bằng hai ý: nó tác động tới vô số ngôn ngữ ra đời sau và Unix được viết lại bằng C. Cả hai đều đúng, nhưng câu chuyện sâu hơn nằm ở tính portable. Một ngôn ngữ systems programming đủ gần phần cứng nhưng không phụ thuộc hoàn toàn vào assembly đã giúp code hệ điều hành có thể đi sang máy khác dễ hơn.
Ritchie về sau mô tả C là sản phẩm của giai đoạn 1969–1973, phát triển song song với Unix. Nó không xuất hiện hoàn chỉnh trong một lần thiết kế. C tiến hóa từ BCPL, B, hạn chế của phần cứng và những nhu cầu rất thực tế của nhóm Bell Labs đang cố tạo một môi trường tính toán tốt hơn.
Sau Multics, Bell Labs bắt đầu lại nhỏ hơn
Bell Labs từng tham gia Multics, một dự án time-sharing đầy tham vọng. Cuối thập niên 1960, phòng thí nghiệm rút khỏi dự án vì chi phí và tiến độ không còn phù hợp với mục tiêu. Ken Thompson cùng một số đồng nghiệp vẫn muốn có một môi trường tương tác mà họ thực sự thích sử dụng.
Họ bắt đầu trên một chiếc PDP-7 dư thừa. Unix đời đầu vì thế được xây trong điều kiện tài nguyên rất hạn chế. Assembly là lựa chọn tự nhiên để kiểm soát máy thật sát, nhưng cái giá phải trả là code bám chặt vào kiến trúc CPU cụ thể.
Khi Unix chuyển sang PDP-11, nhóm có cơ hội nhìn lại bài toán. Một ngôn ngữ cấp cao hơn có thể giúp phát triển hệ thống nhanh hơn, miễn là nó vẫn đủ “gần máy” để viết kernel và những thành phần thấp tầng.
Từ B tới C
Thompson đã tạo B dựa trên ảnh hưởng từ BCPL. B gọn và hữu ích, nhưng phần cứng PDP-11 cùng nhu cầu của Unix đòi hỏi nhiều hơn. Ritchie bổ sung type system và các đặc điểm giúp biểu diễn dữ liệu thực của máy tốt hơn. Đặc biệt trong năm 1972, thiết kế thay đổi nhanh chóng.
C không phải một ngôn ngữ được tạo ra trên giấy để đạt “độ đẹp” lý thuyết. Nó là phản ứng kỹ thuật trước một môi trường cụ thể. C đủ thấp để làm systems programming, nhưng đủ trừu tượng để cùng một source code có thể được compiler cho nhiều loại processor.
Sự cân bằng đó bền đáng kinh ngạc. C cho phép pointer, truy cập memory và biểu diễn dữ liệu sát phần cứng, đồng thời có function, control flow có cấu trúc và một mức abstraction mà compiler có thể dịch sang kiến trúc khác.
Vì sao viết lại Unix bằng C là bước ngoặt?
Một hệ điều hành viết gần như hoàn toàn bằng assembly phải sửa rất nhiều khi chuyển sang kiến trúc mới. Khi phần lớn Unix được biểu diễn bằng C, phần phụ thuộc trực tiếp vào machine nhỏ đi đáng kể.
Điều đó không khiến Unix tự nhiên “chạy ở mọi nơi”. Vẫn cần compiler cho từng nền tảng, phần cứng vẫn khác nhau và một số đoạn vẫn phải viết riêng. Nhưng economics của việc port hệ điều hành thay đổi. Chuyển Unix sang máy khác trở nên khả thi hơn, và điều đó góp phần giúp nó lan qua các trường đại học, phòng nghiên cứu rồi tới hệ thống thương mại.
C và Unix sau đó nuôi lẫn nhau. Unix là workload thật, khắc nghiệt, buộc C phải chứng minh mình. C lại giúp Unix có đường đi sang phần cứng mới.
C nhìn nguy hiểm hôm nay vì nó được sinh ra cho bài toán khác
Developer hiện đại đôi khi gặp C và thấy nó “cho quá nhiều quyền”: memory safety thấp, pointer dễ sai và ít hàng rào bảo vệ. Nhìn từ bối cảnh ban đầu, lựa chọn đó dễ hiểu hơn. Bell Labs đang viết phần mềm hệ thống trên những máy mà memory, performance và độ đơn giản của compiler đều cực kỳ quan trọng.
Họ không tối ưu ngôn ngữ cho beginner, garbage collector hay ứng dụng web public. Họ muốn giảm phụ thuộc vào từng machine nhưng vẫn không che khuất thực tế của machine.
Điều này cũng giải thích vì sao việc sao chép cú pháp C không đồng nghĩa sao chép triết lý của C. Nhiều ngôn ngữ sau dùng dấu ngoặc nhọn và operator tương tự, nhưng lại đưa ra lựa chọn rất khác về type system, memory management và safety.
Từ công cụ nội bộ tới tiêu chuẩn ngành
Khi C lan ra ngoài Bell Labs và Unix, nhiều compiler và dialect khác nhau xuất hiện. Cuốn The C Programming Language của Brian Kernighan và Dennis Ritchie năm 1978 tạo ra một mô tả được dùng rất rộng rãi. Quá trình chuẩn hóa ANSI diễn ra sau đó trong thập niên 1980.
Trình tự này đáng chú ý. C chứng minh giá trị trước trong một hệ điều hành thật và cộng đồng programmer thật; tiêu chuẩn chính thức tới sau khi usage đã lan rộng. Practice định hình language trước, committee ổn định contract sau.
Di sản của Ritchie thực sự là gì?
Dennis Ritchie cùng Ken Thompson nhận ACM Turing Award năm 1983 cho những đóng góp liên quan tới hệ điều hành và Unix. Nhưng ảnh hưởng của C đi xa hơn Unix. Kernel, database, embedded system, compiler và vô số library ngày nay vẫn dựa trên C hoặc những interface được thiết kế theo thế giới C.
Điều đáng nhớ không chỉ là “C ở khắp nơi”. Bài học hay hơn là một abstraction layer được chọn đúng có thể quyết định phần mềm sống qua bao nhiêu thế hệ phần cứng. Code không nên bị trói vào một machine nếu không cần thiết, nhưng cũng không nên tách khỏi thực tế phần cứng tới mức không làm được việc.
Ritchie không đặt mục tiêu làm ngôn ngữ cho mọi máy tính tương lai. Ông góp phần tạo ra một ngôn ngữ giúp một hệ điều hành quan trọng thoát khỏi chiếc máy mà nó sinh ra trên đó. Phần còn lại của ngành đã nhìn thấy giá trị ấy.
Đọc bằng ngôn ngữ khác: English · Español · Deutsch · Français · Português (Brasil) · Tiếng Việt
