Vì sao Common Lisp đang trở thành ngôn ngữ lập trình tốt nhất thời đại LLM

Bạn có đồng ý rằng một số ngôn ngữ lập trình tốt hơn những ngôn ngữ khác? Nếu vậy thì ắt phải có một ngôn ngữ tốt nhất. Và theo một bài viết đang gây chú ý trên Hacker News, câu trả lời hiện nay là Common Lisp — đặc biệt trong bối cảnh các mô hình ngôn ngữ lớn (LLM) có thể viết code với tốc độ chóng mặt.

Bài viết lập luận rằng khi LLM đảm nhận phần lớn việc gõ code, điểm nghẽn của quá trình phát triển phần mềm đã dịch chuyển: từ việc viết code sang việc kiểm chứng chương trình có thực sự chạy đúng hay không.

Vòng phản hồi là yếu tố quyết định tốc độ

Trước đây, con người viết code chậm hơn nhiều so với thời gian chờ biên dịch và khởi động chương trình, nên tốc độ vòng phản hồi (feedback loop) không phải vấn đề lớn. Nhưng khi LLM viết code chỉ trong vài giây, thời gian rebuild kéo dài vài phút bỗng trở thành rào cản chính.

Đây là lúc Common Lisp tỏa sáng. Theo tác giả, trong Common Lisp gần như không tồn tại ranh giới rõ ràng giữa read-time, compile-time và runtime — một đặc điểm mà Paul Graham từng phân tích trong bài viết nổi tiếng "What Made Lisp Different".

Common Lisp dựa trên mô hình image-based, nghĩa là chương trình của bạn là một image sống trong bộ nhớ. Phiên bản mới của một hàm sẽ thay thế phiên bản cũ ngay lập tức, không cần khởi động lại bất cứ thứ gì.

Debugger thay vì crash

Ở hầu hết ngôn ngữ khác, một lỗi sẽ khiến chương trình sập. Khi đó LLM phải đọc log crash, sửa đổi rồi chạy lại từ đầu.

Ở Common Lisp, chương trình không sập mà dừng lại và mở debugger với toàn bộ stack cùng mọi biến trong ngữ cảnh. Bạn có thể trỏ LLM vào debugger đó, để nó đưa ra bản sửa và tiếp tục chạy chương trình ngay tại chỗ.

Theo tác giả, đây là ngôn ngữ phổ biến duy nhất hội tụ đủ tất cả những đặc tính này.

Code chính là dữ liệu, và macro là vũ khí

Lisp là viết tắt của "List Processing" — xử lý danh sách. Trong Common Lisp, code được viết dưới dạng danh sách. Ví dụ, (+ 1 2) vừa là một chương trình cộng hai số, vừa là một danh sách gồm ba phần tử: ký hiệu +, số 1 và số 2.

Vì code và dữ liệu dùng chung một cấu trúc, mọi công cụ xử lý dữ liệu đều có thể dùng để xử lý code. Một chương trình có thể nhận một chương trình khác, biến đổi nó — chẳng hạn chuyển (+ 1 2) thành (* 1 2) — rồi thực thi ngay kết quả.

Đó là nền tảng của macro: một hàm nhận code đầu vào và trả về code mới thay thế. Nhờ macro, lập trình viên có thể bổ sung cấu trúc mới vào chính ngôn ngữ, từ đó xây dựng một ngôn ngữ chuyên biệt cho miền bài toán (DSL) trước khi viết chương trình bằng ngôn ngữ đó.

Ý nghĩa với các sản phẩm phần mềm hiện đại

Tác giả cho rằng luận điểm này càng trở nên quan trọng khi các công ty phần mềm hướng tới việc cho phép người dùng tự thay đổi sản phẩm — điều mà LLM khiến trở nên dễ dàng.

Lấy ví dụ một hệ thống ERP. Mỗi doanh nghiệp vận hành một kiểu khác nhau nên gần như ai cũng phải chỉnh sửa ERP. Nhưng nếu ERP được viết bằng chính DSL của nó, người dùng chỉ cần yêu cầu LLM thực hiện thay đổi bằng ngôn ngữ đó. Thay đổi sẽ tự động tuân theo các quan điểm thiết kế nền tảng của sản phẩm, nhờ vậy khớp với sản phẩm thay vì phá vỡ nó.

Tác giả còn cho biết các ứng dụng ông viết bằng Common Lisp thường ngắn hơn 6–7 lần so với phiên bản Python nhờ macro giúp trừu tượng hóa các mẫu lặp lại. Với LLM, ít code hơn nghĩa là ít token hơn — và token chính là thứ bạn phải trả tiền.

Quan trọng hơn, chương trình ngắn hơn giúp nhiều phần code nằm gọn trong cửa sổ ngữ cảnh (context window) của LLM. Khi LLM nắm trọn ý định của toàn bộ chương trình, nó đưa ra quyết định tốt hơn — thay vì sửa một đoạn mà không thấy phần còn lại, vốn là nguồn gốc của nhiều lỗi do AI tạo ra.

Chuẩn ANSI 1994 — một điểm mạnh bất ngờ

Common Lisp là một chuẩn ANSI và chưa từng được cập nhật kể từ năm 1994. Tác giả xem đây là điểm mạnh: nếu người dùng tự thay đổi sản phẩm dựa trên nền tảng này, ngôn ngữ bên dưới sẽ không bao giờ dịch chuyển và mọi thứ họ xây thêm cũng không bị phá vỡ.

Điểm yếu truyền thống của Lisp là hệ sinh thái thư viện nhỏ. Quicklisp, trình quản lý gói chính của Common Lisp, chỉ có vài nghìn dự án, trong khi npm có hàng triệu.

Nhưng theo tác giả, điều đó không còn là vấn đề. Phần lớn chương trình ngày nay phụ thuộc vào hàng triệu dòng code từ các gói liên tục bị xâm phạm (compromise). Với LLM, bạn có thể tự viết phần mình cần hoặc chuyển toàn bộ thư viện sang — và LLM tỏ ra rất giỏi việc port code.

Còn chuyện tuyển dụng thì sao?

Một phản đối hiển nhiên là rất khó tìm kỹ sư biết Common Lisp. Tác giả phản biện rằng điều này không còn quan trọng. Muốn xây dựng công ty thành công, bạn cần tuyển những người giỏi kỹ thuật nhất — những người học nhanh cái mới.

Trong buổi phỏng vấn, chỉ cần yêu cầu ứng viên học Common Lisp. Bạn sẽ thấy họ tiếp thu nhanh đến mức nào, và những người làm tốt chắc chắn sẽ tiếp tục học và trở nên thực sự giỏi.

Góc nhìn cho lập trình viên Việt Nam

Với cộng đồng lập trình Việt Nam — nơi Python, JavaScript và Java vẫn chiếm ưu thế — luận điểm này đáng để suy ngẫm chứ không hẳn để làm theo ngay. Rủi ro khi đặt cược vào Common Lisp vẫn rất thực tế: hệ sinh thái nhỏ, thị trường tuyển dụng gần như không có, và tài liệu tiếng Việt hầu như bằng không.

Tuy nhiên, ý tưởng cốt lõi của bài viết vượt xa một ngôn ngữ cụ thể. Khi AI viết code thay con người, giá trị sẽ dịch chuyển về phía thiết kế ngôn ngữ miền, khả năng quan sát hệ thống đang chạy, và tốc độ vòng phản hồi. Đó là những bài học mà bất kỳ đội ngũ kỹ thuật nào ở Việt Nam cũng có thể áp dụng — dù họ viết bằng Lisp, Python hay TypeScript.

Kết luận của tác giả rất dứt khoát: lần tới khi bạn muốn viết một chương trình, hãy thử Common Lisp.