- Lập trình văn chương (Literate Programming), tức kết hợp mã và phần giải thích bằng ngôn ngữ tự nhiên trong cùng một mạch tường thuật, đã không được sử dụng rộng rãi vì gánh nặng phải duy trì song song cả mã lẫn giải thích, nhưng các tác tử lập trình AI có thể loại bỏ phần lao động cốt lõi này
- Với
org-babel của Org Mode trong Emacs, có thể thực hiện lập trình văn chương đa ngôn ngữ, nhưng trong các dự án quy mô lớn, sự phiền toái của quá trình trích xuất mã nguồn (tangling) là một giới hạn
- Nếu yêu cầu tác tử viết runbook dựa trên tệp Org, có thể tạo ra quy trình làm việc trong đó ý định được diễn giải bằng phần mô tả, các khối mã được chạy tương tác và kết quả được lưu lại trong tài liệu
- Vì tác tử tự động xử lý việc đồng bộ hóa giữa mô tả và mã cũng như tangling, công sức phải viết lại phần giải thích mỗi khi mã thay đổi biến mất, đồng thời tận dụng đúng thế mạnh dịch và tóm tắt của LLM
- Trong xu hướng vai trò của kỹ sư chuyển từ viết mã sang đọc mã là trung tâm, tính thực tiễn của một codebase mang tính tường thuật do tác tử duy trì đang nổi lên như câu hỏi then chốt
Khái niệm và giới hạn của lập trình văn chương
- Lập trình văn chương (Literate Programming) là ý tưởng trộn mã với phần giải thích bằng ngôn ngữ tự nhiên, để ngay cả người đọc không có kiến thức nền trước đó cũng có thể đọc codebase như một mạch tường thuật và hiểu cách nó vận hành
- Đây là một khái niệm hấp dẫn, nhưng trên thực tế lại phát sinh gánh nặng phải duy trì hai mạch tường thuật song song là chính mã và phần giải thích, và đây là nguyên nhân căn bản khiến nó bị hạn chế trong việc áp dụng
- Hình thức phổ biến nhất trong thực tế là notebook Jupyter của cộng đồng khoa học dữ liệu, nơi phần giải thích, tính toán và kết quả được hiển thị cùng nhau trong trình duyệt web
Emacs Org Mode và lập trình văn chương
- Org Mode của Emacs hỗ trợ lập trình văn chương đa ngôn ngữ thông qua gói
org-babel, cho phép chạy ngôn ngữ bất kỳ và ghi lại kết quả vào tài liệu
- Tuy vậy, cách làm này vẫn là một mẫu hình ngách chỉ còn trong tay một số ít người dùng nhiệt thành
- Nếu dùng tệp Org làm nguồn chân lý (source of truth) trong các dự án phần mềm quy mô lớn, thì mã nguồn thực chất trở thành đầu ra đã được biên dịch, và sau mỗi lần chỉnh sửa phải trích xuất mã ("tangle") rồi đặt vào đích
- Có thể tự động hóa, nhưng sau khi người dùng hoặc tác tử chỉnh sửa trực tiếp mã nguồn thực tế, rất dễ phát sinh vấn đề bị ghi đè ở lần tangle tiếp theo
Mẫu sử dụng trước thời đại tác tử
- Việc dùng lập trình văn chương để quản lý cấu hình cá nhân đã cho thấy hiệu quả đủ lớn, nên ngay cả trước khi LLM xuất hiện, ý tưởng này vẫn chưa bị từ bỏ
- Một mẫu dùng Org Mode cho kiểm thử thủ công và ghi chép: thay vì dòng lệnh, viết và chạy lệnh trong trình soạn thảo, chỉnh sửa từng bước cho đến khi đúng rồi lưu kết quả ngay tại chỗ
- "Nếu kết hợp việc ghi chép với chạy kiểm thử, thì khi kiểm thử xong, bạn cũng có luôn ghi chú miễn phí"
Quy trình làm việc mới cùng tác tử
- Các tác tử lập trình như Claude, Kimi hiểu cú pháp Org Mode rất tốt, và Org là một ngôn ngữ đánh dấu linh hoạt nên LLM xử lý đặc biệt tốt
- Khối cú pháp đồ sộ của Org Mode là nhược điểm với con người, nhưng không phải vấn đề với mô hình ngôn ngữ
- Khi kiểm thử chức năng, nếu yêu cầu tác tử viết runbook Org, thì:
- Phần mô tả chứa sự phản tư của mô hình về ý định ở từng bước
- Các khối mã sau khi được xem xét có thể chạy tương tác từng khối một hoặc chạy toàn bộ như script
- Kết quả được lưu bên dưới mã giống như notebook Jupyter
- Có thể chỉnh sửa phần mô tả rồi yêu cầu mô hình cập nhật mã, hoặc chỉnh sửa mã rồi để mô hình phản ánh ý nghĩa vào phần giải thích, hoặc để tác tử thay đổi cả hai phía cùng lúc
- Vấn đề phải duy trì hai mạch tường thuật song song biến mất
Lao động cốt lõi mà tác tử loại bỏ
- Nếu giao việc tangling cho tác tử thì bài toán trích xuất mã cũng được giải quyết
- Có thể dùng tệp
AGENTS.md để chỉ thị cho tác tử coi tệp Org là nguồn chân lý, luôn viết phần giải thích và thực hiện tangle trước khi chạy
- Tác tử rất thành thạo mọi việc này, và không bao giờ mệt mỏi với việc viết lại phần giải thích sau khi sửa mã
- Tác tử loại bỏ phần lao động bổ sung mang tính căn bản khiến lập trình văn chương không được dùng rộng rãi, tức là tận dụng đúng năng lực dịch và tóm tắt mà LLM làm tốt nhất
Lợi ích được kỳ vọng
- Có thể xuất (export) codebase sang nhiều định dạng khác nhau để đọc thuận tiện hơn
- Điều này đặc biệt quan trọng nếu vai trò chính của kỹ sư đang chuyển từ viết sang đọc
- Dù chưa có dữ liệu chứng minh, có thể suy đoán rằng chất lượng mã được sinh ra cũng sẽ được cải thiện, vì phần tường thuật giải thích ý định của từng khối mã xuất hiện cùng mã trong ngữ cảnh
- Cho đến nay, cách làm này vẫn chưa được thử trên codebase quy mô lớn và nghiêm túc, mà mới được dùng trong quy trình kiểm thử và tài liệu hóa quy trình thủ công
Giới hạn của Org Mode và các lựa chọn thay thế
- Định dạng Org bị ràng buộc bởi sự tích hợp chặt chẽ với Emacs, đây là một yếu tố hạn chế, và từ lâu đã có niềm tin rằng Org nên thoát ra khỏi Emacs
- Muốn đề xuất Markdown như một lựa chọn thay thế, nhưng Markdown thiếu khả năng chứa siêu dữ liệu
- Khái niệm Properties của Org Mode cho phép thao tác tài liệu bằng Emacs Lisp theo cách lập trình được, và giờ đây LLM còn có thể viết các tính năng tùy biến dành riêng cho tài liệu đó bằng Emacs Lisp trong phần file variables
- Markdown không có tính năng như header arguments của Org Mode để chỉ định chi tiết thực thi khối mã, chẳng hạn chạy ở đâu hay trên máy từ xa nào
- Điều thực sự gây hứng thú không phải là cách triển khai cụ thể của Emacs mà là bản thân ý tưởng này
Câu hỏi cốt lõi
- "Thông qua tác tử, liệu có thể trở nên thực tiễn khi sở hữu một codebase quy mô lớn có thể đọc như một mạch tường thuật, và được duy trì ở trạng thái đồng bộ giữa thay đổi mã và phần giải thích bởi một cỗ máy không biết mệt mỏi hay không?"
2 bình luận
Ý kiến trên Hacker News
Tôi nghĩ cách đơn giản nhất là để chính LLM tự viết chú thích của nó
Làm vậy để khi LLM đọc lại mã sau này, nó sẽ tham chiếu các chú thích do chính mình viết, đóng vai trò như một dạng bộ nhớ dài hạn đúng lúc cần dùng (just-in-time memory)
Có thể yêu cầu nó ghi phần tóm tắt trong
<summary>, lý do và ngữ cảnh trong<remarks>, ràng buộc trong<params>, và giảm thiểu chú thích inlineLàm như vậy thì khi review PR, ta có thể xem trực tiếp quá trình suy nghĩ của LLM trong
<remarks>, nên sẽ dễ phát hiện những chỗ nó hiểu lệch với ý định hơnCuối cùng nó chỉ làm ô nhiễm context của chính nó bằng thông tin vô ích, khiến khả năng hiểu còn kém đi
Hiện tại vẫn còn khá xa so với năng lực đọc hiểu (literacy) ở mức con người
Nhưng chính những chú thích kiểu này lại là chỗ mà LLM vướng khi đọc lại cùng đoạn mã, nên biết đâu đó lại là thông tin có giá trị
Vì thế các chú thích như vậy có vai trò lưu giữ phần ký ức đó
Tôi nghĩ ngôn ngữ lập trình ra đời là vì sự mơ hồ của ngôn ngữ tự nhiên
Vì vậy chú thích mã rồi cũng sẽ mơ hồ, mà lại không được thực thi nên nhanh chóng lỗi thời
LLM mạnh ở dịch mã, nhưng việc chuyển prompt ngôn ngữ tự nhiên thành mã thì tôi vẫn thấy còn khó
Mã tốt phải thể hiện rõ ý đồ, và quá nhiều chú thích đôi khi cũng là dấu hiệu chất lượng mã thấp
Nhưng phần mềm tốt cũng phải bao gồm tài liệu hóa tốt
Lập trình văn chương là kiểu viết lấy phần giải thích làm trung tâm hơn là chi tiết triển khai
Mã định nghĩa hẹp phần “làm như thế nào”, còn ngôn ngữ tự nhiên có thể diễn đạt thiên về “làm cái gì”, nhờ vậy LLM có dư địa đề xuất cách tốt hơn
Cần có thông tin trùng lặp thì mới phát hiện và sửa lỗi được
Chúng chỉ đặt ra các quy tắc để thu hẹp mức độ tự do khi diễn giải
Đôi khi ẩn dụ hay sự mơ hồ lại là cách biểu đạt phù hợp hơn
Nếu đưa ví dụ mã và tài liệu làm template thì sẽ giảm được hallucination
Có nghiên cứu cho thấy chú thích theo phong cách lập trình văn chương giúp con người hiểu mã tốt hơn
Nhóm nghiên cứu Google đã thử nghiệm xem LLM có thể cập nhật kiểu chú thích này không, và liệu nó có giúp con người hiểu hơn không
Kết luận là chú thích cấp khối giải thích ý đồ là hiệu quả nhất
(tham khảo: bài báo arXiv 2024 "Natural Language Outlines for Code")
Một hiện tượng thú vị gần đây là, trước đây mọi người ngại viết README hay tài liệu kiến trúc cho con người
nhưng giờ nếu nói là viết cho LLM thì họ lại tích cực hơn hẳn
Nhưng LLM thì tham khảo tài liệu ở mọi tác vụ, nên động lực tài liệu hóa mạnh hơn rất nhiều
Commit message, hồ sơ kiểu ADR trước đây con người không xem, nhưng LLM thì đọc hết
Rốt cuộc các thói quen đó cũng lại giúp ích cho cả người mới vào nghề
Có những người mải học cách nói chuyện với máy tính mà quên mất cách nói chuyện với con người, nên sau khi tốt nghiệp lại tụt hậu hơn
Vì để mã chạy được thì độ chính xác của tài liệu không phải điều bắt buộc
Nên nhiều khi tôi thấy xem trực tiếp mã còn tốt hơn đọc tài liệu
Tôi cho rằng sự kết hợp giữa lập trình văn chương nhẹ và ngôn ngữ thiên về quy ước rất hợp với thời đại agent
Những ngôn ngữ như Go, có tốc độ biên dịch nhanh và style guide rõ ràng, là lựa chọn tốt
Nếu để agent tham khảo Google Go Style Guide khi viết mã thì kết quả khá ổn
(tham khảo: giai thoại liên quan đến Rob Pike)
Vì LLM là mô hình ngôn ngữ nên rất đáng để đầu tư vào cách viết rõ ràng
Dù chưa cần đến mức lập trình văn chương, thì tên gọi tốt, docstring, type signature, chú thích giải thích “vì sao” vẫn rất quan trọng
Cuối cùng cốt lõi vẫn là xây dựng mẫu hình giao tiếp cho cả con người lẫn LLM
Tài liệu giải thích cấu trúc cấp cao ở mức file, thư mục, dự án là đặc biệt quan trọng
Nhưng các khái niệm như vậy lại trải trên nhiều file, nên chuyện viết ở đâu và đồng bộ tài liệu-mã luôn là vấn đề
Trong 10 năm qua, tôi đã viết gần như toàn bộ mã theo phương pháp lập trình văn chương
Tôi tạo ra nbdev để quản lý mã, tài liệu và test cùng nhau trên nền notebook
Gần đây còn xây dựng một công cụ tên Solveit tích hợp LLM và đang dùng trên toàn công ty
(liên kết Solveit)
Lập trình văn chương cũng hữu ích cho cả những công việc ngoài lập trình
Sẽ tốt hơn nếu có thêm demo ngắn hoặc ảnh chụp màn hình
Ý tưởng dùng LLM để tự động phát hiện sự không khớp giữa chú thích và mã khá thú vị
Tài liệu theo thời gian chắc chắn sẽ lệch khỏi mã, nên nếu tự động phát hiện được chuyện đó thì sẽ rất có giá trị
Có khi còn có thể dựng startup quanh ý tưởng này
Mọi thay đổi bắt đầu bằng PR tài liệu, rồi lập trình viên mới phản ánh chúng vào mã
Khi review thì tài liệu và mã được hiển thị song song để kiểm chứng
Hệ thống cũng được thiết kế để cho phép lần theo ngữ cảnh qua các liên kết giữa các tài liệu
Ví dụ: GitHub gh-aw, Continue.dev
Cấu trúc cặp giữa mã test và mã production hữu ích giống như ghi sổ kép trong kế toán
Test giải thích ý đồ của mã, còn mã thì bổ sung ý nghĩa cho test
Khi review, nếu một bên khó hiểu thì có thể nhìn sang bên còn lại
Điểm trừ là lượng mã tăng lên, nhưng khả năng đọc hiểu được cải thiện xứng đáng với cái giá đó
Gần đây tôi cũng có viết về intent-based coding, và nó chạm đúng vào cuộc thảo luận này
(liên kết blog)
Điều quan trọng là có thể biến đổi codebase sang nhiều dạng dễ đọc khác nhau
Trong tương lai, cả những người không chuyên cũng sẽ đến gần mã hơn, và việc đưa ngôn ngữ tự nhiên vào sẽ giúp ích lớn cho năng suất và việc học của họ
Wikipedia - Lập trình văn chương
> Lập trình văn chương (literate programming) là một phương pháp luận lập trình, nhấn mạnh vào việc tạo ra mã nguồn dễ hiểu với con người hơn là chỉ tạo ra mã có thể được máy tính biên dịch. Nói cách khác, mục tiêu là lập trình theo cách giống như viết tài liệu để con người có thể đọc và hiểu. Vì mục tiêu là “giúp việc đọc chương trình trở nên giống như đọc một tác phẩm văn học”, nên phương pháp này được đặt tên là “lập trình văn chương”.