Vẻ đẹp của những chương trình và ngôn ngữ lập trình tí hon
Từ một trình thông dịch Forth chỉ vỏn vẹn 46 byte cho tới Lisp với bộ thu gom rác gói trong 436 byte, cộng đồng lập trình luôn bị cuốn hút bởi những chương trình tí hon. Bài viết khám phá lý do vì sao mã nguồn nhỏ lại hấp dẫn đến vậy, và vì sao đôi khi sự đơn giản nên được đặt trên cả tính biểu đạt.

Vẻ đẹp của những chương trình và ngôn ngữ lập trình tí hon
Có một sức hút kỳ lạ đến từ những thứ nhỏ bé: một trình thông dịch Forth chỉ 46 byte, một thư viện DOM diffing vỏn vẹn 25 dòng JavaScript, hay một trình thông dịch Lisp nằm gọn trên một trang giấy. Bài viết dưới đây lý giải vì sao những "chương trình tí hon" lại khiến giới lập trình say mê, và chúng có ý nghĩa gì vượt ra ngoài chuyện giải trí.
Sức hút của những chương trình tí hon
Mã nguồn nhỏ thì dễ tiếp cận. Nếu thấy một chương trình dài 200 dòng, tôi sẵn sàng đọc nó hơn nhiều so với một chương trình 2.000 hay 20.000 dòng. Và nếu một đoạn mã chỉ 20 dòng mà làm được việc tưởng chừng cần tới 2.000 dòng, thì độ tò mò của tôi tăng lên gấp bội.
Khi nghiên cứu các thư viện DOM diffing trước khi tạo ra RetroV, tác giả bài viết gốc đã mở mã nguồn của ijk — một thư viện do Luke Jackson viết — và bất ngờ vì nó chỉ vỏn vẹn 25 dòng. Gần đây hơn, một phản hồi cho bài viết về Forth đến từ Philippe Brochard với một "Forth" chỉ 46 byte. Nhỏ đến mức có thể đăng nguyên hexdump lên đây:
50b8 8e00 31d8 e8ff 0017 003c 0575 00ea
5000 3c00 7401 eb02 e8ee 0005 0588 eb47
b8e6 0200 d231 14cd e480 7580 c3f4
Rất ít người hào hứng đọc mã máy thô — nhưng đó chính là điểm mấu chốt: một thứ nhỏ như vậy không còn đáng sợ nữa. Chỉ 46 byte, ai cũng có thể tin rằng nếu bỏ công, mình sẽ hiểu được nó hoạt động ra sao.
Một ví dụ gần như ngược lại vì mã quá dày đặc và khó hiểu, nhưng không thể không nhắc tới: "Incunabulum" của Roger K.W. Hui trong bài An Implementation of J, kể về việc Arthur Whitney viết một trình thông dịch ngôn ngữ mảng trên một trang giấy, trong một buổi chiều. Hui có thể in trọn trình thông dịch vào phụ lục vì nó chỉ là 122 dòng C cực kỳ khó đọc.
J thuộc họ ngôn ngữ mảng cùng với APL. Nếu bạn thích sự ngắn gọn, những câu đố lập trình khó hiểu và tính toán số hiệu năng cao, họ ngôn ngữ này chính là dành cho bạn.
Tái tạo hay chân lý nền tảng?
Ai cũng biết code golf — trò chơi rút gọn mã nguồn của dân lập trình — chỉ để cho vui. Nhưng liệu những nỗ lực này có ích thật không? Tác giả khẳng định: có, và còn hơn thế, chúng có ý nghĩa.
Khi thấy một ray tracer vừa vặn trên một tấm danh thiếp, ta nhận ra ray tracer là thứ có thể nằm gọn trên danh thiếp — đó là một sự thật về độ phức tạp tối thiểu của ray tracer. Khái niệm độ phức tạp Kolmogorov định nghĩa chính là "độ dài của chương trình ngắn nhất (trong một ngôn ngữ lập trình định trước) tạo ra được đối tượng đó".
Nhờ Justine Tunney, ta biết một LISP có bộ thu gom rác chỉ cần 436 byte. Đó là một sự thật về Lisp: khi gạt bỏ mọi thứ khác, phần cốt lõi có thể thu gọn đến mức ấy. Điều này mang lại sự an tâm — nghĩa là khái niệm đó có thể nằm gọn trong đầu ta. Và nhờ Frank Force, ta biết một game 3D chạy trên trình duyệt có thể gói trong 2 Kb JavaScript nén cực mạnh. Trang web của Martin Kleppe cũng đầy những kỳ quan chạy ngay trên trình duyệt.
Điểm mấu chốt: không cần phải nghiền ngẫm từng bánh răng của một chương trình thu nhỏ mới hưởng lợi được từ nó. Bản thu nhỏ chỉ đơn giản chứng minh rằng khái niệm đó vừa một tấm danh thiếp và vừa một bộ não người.
Ngôn ngữ nhỏ
Không chỉ chương trình nhỏ, mà cả ngôn ngữ lập trình nhỏ cũng đáng quan tâm. Nhìn chung, ngôn ngữ càng nhỏ thì càng ít biểu đạt. Một trong những ngôn ngữ nổi tiếng nhất và ít biểu đạt nhất là hợp ngữ (assembly) — cú pháp và khái niệm đơn giản, chủ yếu là chuỗi lệnh gợi nhớ theo một trật tự cứng nhắc.
Trong nhóm ngôn ngữ "bậc cao" có cú pháp tí hon, ba cái tên nổi bật:
- Forth: cấu trúc cú pháp duy nhất là dấu cách. Forth linh hoạt và mạnh mẽ đến mức đáng kinh ngạc.
- Lisp (đặc biệt là Scheme): phần lõi nhỏ, cú pháp đơn giản nhưng sức biểu đạt và độ linh hoạt rất lớn.
- Tcl: mọi thứ đều là chuỗi, cho phép bạn tự xây dựng ngôn ngữ riêng giống như với Forth hay Lisp.
Cả ba chỉ đòi hỏi hiểu vài ý tưởng cốt lõi mà đổi lại trao cho bạn sức mạnh vô hạn. Phần cú pháp lõi của chúng có thể vừa một tấm thẻ ghi chú. Nhưng để dùng hiệu quả, bạn phải thay đổi tư duy rất nhiều nếu quen với các ngôn ngữ mệnh lệnh kiểu Algol "bình thường".
Vậy còn thứ vừa nhỏ vừa đơn giản mà không cần "hiến tế máu"? Lua là ứng viên sáng giá — phần ngôn ngữ lõi của nó chỉ chiếm 27 trang trong sách hướng dẫn. Ngôn ngữ C cũng khá nhỏ và biểu đạt tốt so với kích thước của nó. Zig theo hướng C nhưng thực ra khá lớn. JavaScript có phần lõi khá nhỏ, có lẽ ngang ngửa Lua.
Nhỏ gọn hay biểu đạt: nên nghiêng về đâu?
David Ungar
Trong một bài nói chuyện tuyệt vời của David Ungar mang tên Self and Self: Whys and Wherefores, ông hối tiếc về sai lầm của cơ chế đa kế thừa (multiple inheritance) trong ngôn ngữ Self:
"Tốt hơn nhiều khi làm một hệ thống đơn giản quá mức để người ta phải viết thêm, thậm chí viết hai lần kèm ghi chú 'Xem chỗ này', còn hơn có một hệ thống hành xử kỳ quặc mà không ai hiểu vì sao. Vậy nên, sự đơn giản thắng tính biểu đạt."
Tác giả cho rằng ngôn ngữ nhỏ vẫn có thể khá biểu đạt, nhưng chỉ khi được thiết kế cực kỳ cẩn thận — như Forth, Lisp và Tcl. Một khía cạnh dễ bị bỏ qua khác là thư viện chuẩn: nó cũng chịu cùng bài toán cân bằng giữa kích thước và tính biểu đạt. Học thư viện lập trình hàm Ramda cho JavaScript chẳng khác nào học một ngôn ngữ mới, và không phải ai cũng học hết được. Lời khuyên: một chút Ramda là đủ xa.
Vì sao những thứ nhỏ lại khiến ta thích thú?
Stephanie M. Langin-Hooper, tác giả cuốn Figurines in Hellenistic Babylonia, viết trong bài Tiny Things and Why We Love Them:
"Hành động thu nhỏ một vật có kích thước thật xuống tỉ lệ nhỏ hơn có tác động mạnh mẽ. Vật thể trở nên dễ thương, dễ tiếp cận, mong manh và 'squee' hơn. Nó cũng bất lực hơn, và do đó dễ kiểm soát — mang lại cảm giác an ủi và hoàn toàn không đe dọa nhờ kích thước tí hon."
Đó chính xác là cảm giác khi thấy một đoạn mã nhỏ mà hữu dụng. Quy mô nhỏ giúp những thứ "lớn" trở nên dễ tiếp cận và cho phép "thử nghiệm với rủi ro thấp" — lý do ta thường dựng mô hình thu nhỏ trước khi mở rộng quy mô.
Simon Garfield, tác giả cuốn In Miniature: How Small Things Illuminate the World, viết trên The Guardian:
"Câu trả lời nằm ở khát vọng làm chủ và làm sáng tỏ. Khả năng làm đẹp cuộc sống bằng cách mang lại trật tự và ánh sáng thu nhỏ cho một thế giới vốn hỗn loạn — thế giới mà ta có thể cảm thấy mình chẳng kiểm soát được gì — không thể đánh giá thấp. […] Ở mức đơn giản nhất, bản thu nhỏ cho ta thấy cách nhìn, học và trân trọng nhiều hơn với ít đi."
"Niềm thỏa mãn khi quan sát những thứ nhỏ bé trở thành mong muốn tạo ra những thứ nhỏ bé, và cả hai giai đoạn đều đáp ứng nhu cầu thấu hiểu và trật tự của con người. Chúng ta sống trong một vũ trụ rộng lớn và đầy hiểm họa, và việc kiểm soát chỉ một phần nhỏ thu nhỏ của nó khôi phục lại cảm giác trật tự và giá trị của chúng ta."
Với tác giả, điều này giải thích vì sao những "đêm lập trình hợp ngữ" với quy mô nhỏ, logic có trật tự và tính nhất quán nội tại lại mang đến cảm giác thỏa mãn đến vậy. Khác với Thế giới Thực mênh mông không thể thấu hiểu, một chiếc máy tính chạy offline là nơi tưởng tượng mà ở đó ta có thể tin rằng mình sẽ hiểu được mọi thứ, nếu chịu khó đủ lâu.
Với độc giả Việt Nam
Câu chuyện về những chương trình tí hon không chỉ là chuyện của giới lập trình phương Tây. Với nhiều bạn trẻ Việt Nam đang học lập trình nhúng, vi điều khiển hay tối ưu tài nguyên cho thiết bị IoT giá rẻ, bài học này rất thực tế: một chương trình nhỏ, tối giản thường dễ bảo trì, dễ kiểm thử và phù hợp với phần cứng hạn chế. Việc đọc những mã nguồn ngắn nhưng tinh tế — thay vì những khung làm việc đồ sộ — là cách rèn tư duy rất hiệu quả cho người mới. Và đôi khi, chỉ cần một đoạn mã nhỏ đủ để chứng minh rằng cả một ý tưởng lớn có thể nằm gọn trong lòng bàn tay.
Bài viết liên quan

Công nghệ
Nộp đơn xin việc lẽ ra nên khó hơn. Thật đấy
25 tháng 8, 2026

Công nghệ
Mô hình AI hàng đầu giỏi Vật lý đến đâu? Nghiên cứu mới chỉ ra các bài kiểm tra hiện hành đang đánh giá sai
16 tháng 9, 2026

Công nghệ
Nước Mỹ mất 200.000 việc làm trong lĩnh vực truyền thông, điện ảnh và nghệ thuật: AI chịu trách nhiệm bao nhiêu?
24 tháng 10, 2026