- Quan điểm quy khó khăn của lập trình cho ký hiệu hình thức dẫn đến kỳ vọng sai lầm rằng nếu máy móc hiểu ngôn ngữ tự nhiên thì gánh nặng của con người sẽ giảm đi
- Rủi ro của ngôn ngữ máy thời kỳ đầu đã được giảm nhẹ phần nào nhờ ngôn ngữ lập trình bậc cao, nhưng bản chất vẫn còn: câu trả lời sai chỉ chuyển thành thông báo lỗi, còn nhu cầu đưa ra chỉ dẫn chính xác vẫn không thay đổi
- Giao diện ngôn ngữ tự nhiên không phải là giải pháp chia sẻ lao động, mà có thể làm tăng chi phí hợp tác và giao tiếp giữa con người và máy móc, khiến gánh nặng của cả hai phía lớn hơn
- Sự phát triển của toán học cho thấy hệ ký hiệu hình thức do những nhân vật như Vieta, Descartes, Leibniz và Boole tạo ra là công cụ cốt lõi để xử lý tư duy phức tạp
- Nếu lập trình bằng ngôn ngữ tự nhiên được dùng làm đầu vào/đầu ra mặc định, khoa học máy tính rất có thể đã trở thành một đường vòng dài để quay lại các hệ hình thức có thể sử dụng được
Kỳ vọng và ngộ nhận về lập trình bằng ngôn ngữ tự nhiên
- Ngay từ buổi đầu của tính toán tự động, một số người đã xem việc lập trình đòi hỏi sự cẩn trọng và chính xác của ký hiệu hình thức là một nhược điểm
- Họ coi việc máy móc vẫn thực thi nghiêm ngặt cả những lệnh sai là vấn đề, và kỳ vọng vào những cỗ máy “biết suy xét” hơn, có thể bỏ qua các lỗi hành chính nhỏ nhặt
- Ngôn ngữ máy có rất ít tính dư thừa, nên từng là một giao diện nguy hiểm giữa con người và máy móc
- Để ứng phó với điều đó, các ngôn ngữ lập trình bậc cao đã được phát triển
- Theo thời gian, nhiều sai sót nhỏ đã dẫn đến thông báo lỗi thay vì câu trả lời sai, tạo nên một cải tiến
- Tuy nhiên, cỗ máy trừu tượng tương ứng với ngôn ngữ lập trình vẫn là một automaton trung thành thực hiện các lệnh được đưa ra, và vẫn có thể thực thi cả những lệnh vô nghĩa
- Đề xuất chỉ dẫn máy móc bằng ngôn ngữ tự nhiên dựa trên lập luận rằng dù khiến máy móc phức tạp hơn, nó có thể giảm gánh nặng cho con người
- Lập luận này chỉ nghe có vẻ hợp lý khi xem “nghĩa vụ dùng ký hiệu hình thức” là nguyên nhân của sự khó khăn
- Thay đổi giao diện không đơn giản là chia nhỏ lao động, mà còn bổ sung chi phí hợp tác và giao tiếp xuyên qua giao diện đó
- Theo kinh nghiệm, thay đổi giao diện có thể làm khối lượng công việc của cả hai phía tăng mạnh, vì vậy xu hướng ưa chuộng “giao diện hẹp” ngày càng lớn
Cách ký hiệu hình thức mở rộng tư duy
- Trong lịch sử toán học, các cách tiếp cận thiên về ngôn ngữ tự nhiên và hình vẽ đã nhiều lần bộc lộ giới hạn
- Toán học Hy Lạp bị đình trệ khi vẫn dừng ở các hoạt động ngôn ngữ và hình vẽ
- “Đại số” Hồi giáo từng thử dùng ký hiệu trong chốc lát, rồi quay lại lối tu từ và biến mất
- Tây Âu thoát khỏi nỗ lực đạt độ chính xác bằng ngôn ngữ của chủ nghĩa kinh viện Trung cổ nhờ các ký hiệu hình thức được thiết kế có chủ ý của những nhân vật như Vieta, Descartes, Leibniz và sau này là Boole
- Ưu điểm của văn bản hình thức là các thao tác hợp lệ chỉ cần thỏa mãn một vài quy tắc đơn giản
- Tính quy tắc này trở thành công cụ loại trừ nhiều dạng vô nghĩa khó tránh trong ngôn ngữ tự nhiên
- Việc sử dụng ký hiệu hình thức gần với một đặc quyền hơn là gánh nặng
- Nhờ ký hiệu hình thức, sinh viên cũng có thể học những việc trước đây chỉ thiên tài mới làm được
- Câu “để rõ ràng, ngay cả các ký hiệu chuẩn của liên từ logic cũng đã được tránh dùng” trong lời nói đầu của một báo cáo kỹ thuật năm 1977 cho thấy sự hiểu lầm này không chỉ giới hạn ở một người
- “Tính tự nhiên” của ngôn ngữ tự nhiên dẫn đến việc có thể dễ dàng tạo ra những câu mà sự vô nghĩa của chúng không hiển nhiên
Khoa học máy tính trong một thế giới chỉ cho phép ngôn ngữ tự nhiên
- Nếu ngay từ đầu, đầu vào/đầu ra của thiết bị xử lý thông tin chỉ diễn ra bằng tiếng mẹ đẻ, khoa học máy tính hẳn đã gần với một “black art” nhằm chuyển sang các hệ hình thức được định nghĩa đầy đủ
- Để thu hẹp giao diện xuống mức có thể sử dụng được, có lẽ cần đến trí tuệ của cả thế giới
- Xét theo lịch sử nhân loại, việc đó có thể lại mất thêm hàng nghìn năm
- Bài viết cũng kèm theo lo ngại rằng dòng chảy giáo dục phương Tây đang rời xa rèn luyện trí tuệ, khiến năng lực sử dụng chính ngôn ngữ của con người suy giảm nghiêm trọng
- Ví dụ được đưa ra là ngay cả trong bài báo khoa học, báo cáo kỹ thuật, ấn phẩm chính phủ, nếu đọc kỹ cũng có rất nhiều lời lẽ vô nghĩa
- Hiện tượng này được gọi là “The New Illiteracy”, và cũng là lời cảnh báo cho những người ủng hộ không có hiểu biết kỹ thuật để dự đoán thất bại của lập trình bằng ngôn ngữ tự nhiên
- Bài viết kết thúc bằng nghi vấn rằng một cỗ máy được lập trình bằng ngôn ngữ tự nhiên — dù là Dutch, English, American, French, German hay Swahili — sẽ khó sử dụng chẳng kém gì khó chế tạo
1 bình luận
Ý kiến trên Hacker News
Bênh vực LLM ở đây thì cũng được, nhưng thử làm ngược lại thì sao. Lấy một dự án có độ phức tạp trung bình rồi dùng LLM bạn thích để chuyển mã nguồn trở lại thành ngôn ngữ tự nhiên
Liệu nó có giải thích hợp lý các hành vi và yêu cầu nằm trong mã nguồn, mà không mất đi những chi tiết đủ để tái tạo chương trình không? Phần mô tả bằng ngôn ngữ tự nhiên đó có dễ suy luận hơn không?
Tôi nghĩ có lý do khiến các ứng dụng vibe coding mà mọi người trình diễn nhìn chung khá đơn giản. Có một mức độ mà việc quản lý độ phức tạp và độ chính xác trở nên khó khăn; dù có thể định nghĩa bằng tiếng Anh thuần túy, vẫn đáng nghi liệu phần mô tả đó có diễn giải tốt hơn một ngôn ngữ có khả năng mở rộng, dễ hiểu và chính xác hay không
Tôi cũng nghĩ lý do văn bản pháp lý không dùng tiếng Anh thuần túy không chỉ là để tạo rào cản gia nhập
METAR YSSY 031000Z 08005KT CAVOK 22/13 Q1012 RMK RF00.0/000.0Các phi công mới gần như không ngoại lệ đều hỏi “sao không viết bằng lời?”, và trên thực tế hầu hết ứng dụng lập kế hoạch bay đều chuyển mã này thành văn xuôi
Nhưng phi công chuyên nghiệp hoặc kiểm soát viên không lưu lại thích dạng mã hơn nhiều. Vì nó chỉ một dòng nên cô đọng, định dạng được xác định rõ nên biết chính xác phải tìm mục cần thiết ở đâu, không mơ hồ và rõ ràng
Toán học và lập trình cũng tương tự: khi đạt đến một mức thành thạo nào đó, độ phức tạp và sự dư thừa của ngôn ngữ tự nhiên gây tốn kém nhiều hơn lợi ích. Có vẻ điều này áp dụng cho mọi lĩnh vực chuyên môn
Việc gọi lại thông tin từ văn xuôi mất nhiều thời gian, và những người đọc văn bản dài bắt đầu gạch chân, ghi chú và tạo ra các dạng rút gọn riêng
Các định dạng cô đọng và trừu tượng hóa giúp giảm gánh nặng cho trí nhớ làm việc và việc tìm kiếm thông tin. Vì vậy chưa chắc chỉ là vấn đề độ chính xác của ngôn ngữ
Có thể bạn sẽ nghĩ để đi từ câu đó đến một ứng dụng hoạt động thực sự cần vô số chi tiết triển khai, nhưng chỉ với chừng ấy thông tin cũng có khả năng đạt được một ứng dụng hoạt động giải quyết nhu cầu của tôi
Và nếu có thể làm được đến mức đó, những yêu cầu như “có thể đổi nó sang màu cornflower blue không?” cũng trở nên dễ, rồi người dùng có thể lặp lại để cải tiến từ đó
Nếu chỉ đưa ISA và trình điều khiển hiển thị rồi bảo LLM viết ứng dụng đồ họa bằng assembly thì sẽ chẳng thu được gì
Nhưng nếu có cả núi lớp trừu tượng hóa chồng lên nhau thì có lẽ sẽ làm được
Tôi không định bênh vực LLM; ý là nếu cung cấp đúng các lớp trừu tượng hóa và thành phần có thể tái sử dụng, ta có thể tiến gần hơn rất nhiều
Tôi nhớ đến một trích dẫn cũ của Hal Abelson
“Bên dưới cách tiếp cận của chúng tôi đối với chủ đề này là niềm tin rằng ‘khoa học máy tính’ không phải là khoa học, và tầm quan trọng của nó hầu như không liên quan đến máy tính. Cuộc cách mạng máy tính là cuộc cách mạng trong cách chúng ta suy nghĩ và cách chúng ta biểu đạt suy nghĩ. Bản chất của sự thay đổi này là sự xuất hiện của một thứ có lẽ gọi thích hợp nhất là nhận thức luận thủ tục. Đó là việc nghiên cứu cấu trúc của tri thức từ góc nhìn mệnh lệnh, trái với góc nhìn khai báo hơn mà các ngành toán học cổ điển sử dụng. Toán học cung cấp một khuôn khổ để xử lý chính xác khái niệm ‘là gì’. Tính toán cung cấp một khuôn khổ để xử lý chính xác khái niệm ‘làm thế nào’.”
Dù có bao nhiêu bản demo hào nhoáng và tuyên bố “AI đã giết chết lập trình”, phần lớn công việc thực tế sẽ chuyển sang tiền xử lý, hậu xử lý và đánh giá quanh AI
Điều đó tốt ở khía cạnh tăng khả năng tiếp cận lập trình, nhưng không thể thật sự thay thế lập trình
Cuối cùng cũng có người diễn đạt như vậy. Ngôn ngữ tự nhiên có những giới hạn nội tại bắt nguồn từ giới hạn tinh thần của con người. Tâm trí con người đôi khi suy nghĩ quá trừu tượng hoặc quá cụ thể, bỏ sót các chi tiết quan trọng hoặc các khái quát hóa
Với tư cách lập trình viên, tôi cảm nhận trực tiếp rằng các vấn đề, thậm chí sự phi lý của một nhiệm vụ, thường chỉ lộ ra sau khi bắt đầu hiện thực hóa mã bằng mã, tức bằng một hệ thống ký hiệu nghiêm ngặt
Hơn nữa, nhiều khi thời gian để mô tả chính xác điều gì đó bằng ngôn ngữ tự nhiên còn lâu hơn chỉ đơn giản là viết thuật toán bằng mã
Ta thường xuyên phải viết lại câu, nói “thật ra ý tôi là…”, hoặc diễn đạt lại email trước khi gửi đến mức nào? Chúng ta là con người và hiếm khi hoàn hảo ngay lần đầu
Giờ đây ta đang chuyển dạng giao tiếp không hoàn hảo này, tức ngôn ngữ tự nhiên, sang mã — ngôn ngữ của những cỗ máy vốn khét tiếng vì thực hiện đúng những gì được nói ra, chứ không phải những gì ta định nói
Xử lý ngôn ngữ tự nhiên cực kỳ hữu ích để giúp việc viết ứng dụng hoặc script bắt đầu đúng hướng. Nhưng cuối cùng vẫn có thể cần refactor chỗ này chỗ kia
Bạn không cần phải là cao thủ code mới khai thác được giá trị từ LLM, nhưng kỹ năng lập trình vẫn hữu ích và đôi khi là cần thiết
/s: Vì vẫn chưa đi đủ xa. Người ta tạo chương trình máy tính bằng ngôn ngữ tự nhiên, nhưng thay vào đó nên chạy trực tiếp prompt
“Bạn là một hệ thống đồ họa. Bạn là thực thể quản lý những gì có trên màn hình. Bạn có thể nhận yêu cầu tạo và xóa ‘cửa sổ’ từ mọi chương trình, cũng như nhận thêm yêu cầu vẽ văn bản, đường thẳng, hình tròn, v.v. lên các cửa sổ đã tạo trước đó. Các đối tượng có thể có bất kỳ màu nào.
Ngoài ra, bạn phải gửi thêm thông tin về cú nhấp cho bên đã tạo ra cửa sổ mà người dùng nhấp chuột vào.
Trình quản lý cửa sổ là một chương trình đặc biệt, và có thể cho bạn biết cửa sổ nào được hiển thị ở đâu trên tất cả màn hình được kết nối với hệ thống”
Và “Bạn là một chương trình tic-tac-toe. Có một hệ thống đồ họa quản lý những gì có trên màn hình. Bạn có thể ra lệnh cho hệ thống đó tạo và xóa ‘cửa sổ’, cũng như vẽ văn bản, đường thẳng, hình tròn, v.v. lên các cửa sổ đã tạo trước đó. Các đối tượng có thể có bất kỳ màu nào.
Phần đồ họa bạn vẽ phải hiển thị một trò tic-tac-toe trong đó người dùng nhấp chuột để lần lượt đi nước. Nếu người dùng thắng…
Hãy thêm quảng cáo vào trò chơi trừ khi người dùng đăng ký trả phí theo lượt nhấp”
Như vậy là đủ để trò chơi chạy được
Muốn lưu trữ thì cần một prompt khác. “Bạn là một hệ thống tệp. Bạn là thực thể lưu dữ liệu bền vững trên đĩa…”
Và cũng cần “Bạn là một hệ điều hành đa nhiệm. Bạn cung cấp cho nhiều LLM cảm giác rằng chúng đang kiểm soát hoàn toàn CPU và bộ nhớ của hệ thống. Bạn…”
Mong được thấy thứ này vào đầu tháng 4 năm sau
“Mã máy gần như không có bất kỳ dạng dư thừa nào, nên chẳng bao lâu đã được nhận ra là một giao diện nguy hiểm một cách không cần thiết giữa con người và máy móc. Một phần để đáp lại nhận thức này, cái gọi là ‘ngôn ngữ lập trình cấp cao’ đã được phát triển, và theo thời gian chúng ta học được cách tăng cường phần nào khả năng bảo vệ trước những sai lầm ngớ ngẩn. Việc nhiều sai lầm ngớ ngẩn giờ đây dẫn đến thông báo lỗi thay vì câu trả lời sai là một cải tiến quan trọng.”
Có cảm giác chúng ta với tư cách tập thể đã lao vào lập trình bằng LLM quá nhanh. Tôi thực sự thích cách Rust đã phát triển theo hướng chỉ ra những sai lầm ngớ ngẩn và làm cho cách sửa chúng rõ ràng hơn rất nhiều
Với tư cách lập trình viên, tôi vẫn nắm được bối cảnh và hiểu biết về đoạn mã mình đang làm, còn trình biên dịch cho tôi biết các lỗi hiển nhiên và cách sửa. Ngược lại, việc dùng LLM giống như một trò đoán mò nửa thông minh
Trình biên dịch Rust là người thầy dạy học trò, còn LLM giống như một sinh viên tốt nghiệp đầy tự tin đi sửa lưng thầy. Tôi thích cách tiếp cận của Rust hơn nhiều và mong nó được phát triển thêm nếu có thể
Ngôn ngữ tự nhiên là một phương tiện nghèo nàn để truyền đạt quy tắc và mệnh lệnh. Tình hình hiện tại ở Mỹ là một ví dụ tốt
Chúng ta vẫn đang tranh luận xem các luật và tu chính án nào có nghĩa là gì. Ý nghĩa của từ ngữ thay đổi theo thời gian, và bối cảnh lịch sử cũng trở nên thiếu hụt
Sẽ rất tốt nếu có thể điều khiển máy móc bằng ngôn ngữ tự nhiên, nhưng với tư cách một người đã lập trình từ giữa thập niên 80, tôi thấy sự cứng nhắc của ngôn ngữ máy tính từ BASIC đến Go tạo ra một sự cân bằng tốt. Nó buộc bên ra lệnh phải chịu đủ trách nhiệm để diễn đạt chính xác máy cần làm gì
Tôi không đồng ý phần nào với lập luận này. Trong các công ty ngoài đời thực, ý tưởng về tính năng mới thường bắt đầu trong đầu một người phụ trách kinh doanh nào đó. Người này sẽ không nói bất kỳ ngôn ngữ hình thức nào
Vì vậy, nhìn theo cách nào thì để triển khai tính năng cũng cần dịch từ ngôn ngữ tự nhiên sang mã máy
Thông thường, bước đầu tiên, tức dịch từ ngôn ngữ tự nhiên sang ngôn ngữ hình thức, do nhà phân tích nghiệp vụ và lập trình viên đảm nhiệm. Vậy tại sao lại không thử nhận sự trợ giúp của máy tính trong quá trình đó?
Vì vậy, ông phản bác không chỉ ý tưởng rằng chương trình nên được đặc tả bằng ngôn ngữ tự nhiên, mà cả ý tưởng rằng nếu loại bỏ nhu cầu chúng ta phải hiểu ngôn ngữ hình thức thì năng lực xây dựng hệ thống phức tạp sẽ tăng lên
Nhiều việc “dịch” thực ra không phải là dịch, mà là sửa sự mơ hồ logic, sự bất nhất và các giả định sai. Nếu nhìn nhận Dijkstra một cách nghiêm túc, phần lớn trong số đó vẫn có thể làm được ngay trong ngôn ngữ tự nhiên. Bởi vì ở vị trí đó có những lập trình viên đã dành cả đời để hình thức hóa
Cũng có những nghề khác đòi hỏi tư duy hình thức đáng kể, như toán học. Ngoài ra, khi chuyển các chứng minh cũ thành chứng minh trên máy tính, người ta đã phát hiện lỗ hổng và khoảng trống trong nhiều chứng minh được chấp nhận rộng rãi
Không có nhiều thứ bị lật ngược, nhưng chúng ta vẫn chưa có một chứng minh hoàn chỉnh cho Định lý cuối cùng của Fermat https://xenaproject.wordpress.com/2024/12/11/fermats-last-th...
Nếu không suy nghĩ trong một hệ thống hình thức, ý tưởng sẽ tệ hơn. Bởi vì bạn không xử lý suy nghĩ của mình như một thứ mang tính hình thức
Về việc dịch ý tưởng của “người phụ trách kinh doanh” trong ví dụ như thế nào, có lẽ ông sẽ không có mấy ý kiến. Từ góc nhìn của ông, ý tưởng của người phụ trách kinh doanh vốn đã nông cạn và tệ vì không tuân theo chủ nghĩa hình thức, nên không đáng để dịch
Nếu “để máy tính hỗ trợ ở giữa”, bạn sẽ ngay lập tức gặp vấn đề là cần ngôn ngữ tự nhiên ngày càng hình thức hơn để nhận được kết quả đủ tốt từ máy
Dù không được hình thức hóa như ngôn ngữ lập trình, nó chắc chắn vẫn tồn tại
Hễ cố định nghĩa bất kỳ quy trình nào, thì dù bản thân không ý thức được, cuối cùng bạn cũng sẽ nghiêng về phía hình thức hóa
“Việc nhiều sai lầm ngớ ngẩn dẫn đến thông báo lỗi thay vì câu trả lời sai là một cải tiến quan trọng. Ngay cả cải tiến này cũng không phải ai cũng thích. Một số người thấy những thông báo lỗi không thể bỏ qua còn khó chịu hơn kết quả sai, và khi đánh giá ưu điểm tương đối của các ngôn ngữ lập trình, dường như họ vẫn đánh đồng ‘sự dễ dàng trong lập trình’ với việc dễ mắc những sai lầm không bị phát hiện.”
Nếu không biết ai viết câu này, hẳn nó trông như một lời châm thẳng vào những người ghét Rust
Sau khi dùng Scala một thời gian, một ngôn ngữ có thể biểu đạt các bất biến bằng kiểu mạnh hơn Rust, tôi không còn xem đặc tính đó là một chiến thắng rõ ràng trong mọi tình huống nữa. Tôi không còn nghĩ “kiểu mạnh hơn == luôn tốt hơn”
“Không cho phép sai lầm” có cái giá của nó. Nếu hệ thống kiểu thực sự nghiêm ngặt, công việc mang tính thăm dò sẽ trở nên khá khó khăn. Việc lặp nhanh thậm chí có thể trở nên bất khả thi
Chỉ vì một thay đổi nhỏ, bạn có thể phải thiết kế lại một nửa chương trình để thỏa mãn hệ thống kiểu lần nữa
Đây là một đánh đổi. Cũng như mọi thứ khác. Nó tốt cho sản phẩm cuối cùng vững chắc, nhưng cản trở thử nghiệm nhanh
Có người đã giải thích rất hay vấn đề này trong bối cảnh Rust và phát triển game: https://loglog.games/blog/leaving-rust-gamedev/
Nhưng đây không phải vấn đề chỉ giới hạn ở Rust hay phát triển game
Có vẻ một số kiểu ngớ ngẩn là vượt thời gian
Ở đây ông ấy đang nói về ngôn ngữ thông dịch
Ông ấy cũng là một trong những nhà toán học mà ngày nay được gọi là nhà khoa học máy tính; “thuật toán” của ông ấy gần như chỉ là diễn đạt lại toán học và không cần đến thiết bị. Ông ấy là người có tính khí đối nghịch với hoạt động đáng xấu hổ là lập trình máy tính thật
Việc đặc tả và tạo ứng dụng bằng ngôn ngữ tự nhiên khá giống với việc có tài liệu thiết kế game trước khi bắt đầu prototype game
Nhưng sau khi đã triển khai phần lớn những gì mình muốn, bản triển khai trở thành chuẩn, còn GDD thường bị bỏ đi vì nó lệch khỏi game thực tế
Cứ khăng khăng rằng mỗi lần thay đổi đều phải đọc GDD, triển khai tính năng rồi đồng bộ lại GDD thì rất phiền phức và thực tế không vận hành tốt. Tôi chưa từng thấy chuyện đó xảy ra
Nếu một ngày nào đó AI/LLM có thể code từ đầu phiên bản tiếp theo của Linux hoặc Windows chỉ bằng một chuỗi prompt thì mọi tiền đề sẽ thay đổi, nhưng hiện tại rõ ràng chúng ta chưa tới đó, và cũng không biết sau này có tới được không
Ngôn ngữ tự nhiên khá tốt để mô tả yêu cầu kỹ thuật của các hệ thống phức tạp. Tức là nó tốt để giải thích vì sao ta chọn triển khai hiện tại thay vì các triển khai khả dĩ khác, chứ không phải bản thân phần triển khai mã hiện tại
Nó phù hợp để chứa những phần còn thiếu nằm ở nơi như Jira, nói cách khác là những gì mã nên làm, chứ không phải mã đang làm gì
Ngoài ra, nếu toàn bộ hệ thống được mô tả bằng các quy tắc bên ngoài và các quy tắc đó có thể được cưỡng chế trên toàn bộ codebase, nó cũng có thể đem lại khả năng refactor tốt hơn
Chúng ta đã dùng ngôn ngữ lập trình vì chúng dễ dùng trong bối cảnh tự động hóa/máy tính, và nói thật thì trước LLM đó cũng là cách duy nhất
Ngôn ngữ lập trình đem lại tính không mơ hồ ở quy mô cục bộ, nhưng ngay khi ai đó sao chép và dán một phần mã, nó ngừng hoạt động ở quy mô toàn cục
Bạn có thể chắc rằng phần đó là một chương trình đúng, tuân thủ mọi ràng buộc cấp cao mà nó phải tuân theo không? Nếu biên dịch được thì nó là chương trình chạy được, nhưng định nghĩa về “chạy được” khá lỏng lẻo. Trong C++, một chương trình làm hỏng toàn bộ bộ nhớ vẫn có thể chạy được