Ghi chép của ông tôi về việc COBOL đã “chết” từ lâu
(wumpus-cave.net)- Bài viết đăng trên tạp chí Technical Support vào tháng 6/1992 đã tuyên bố cái chết của COBOL, nhưng điểm chính là hơn 30 năm sau, ngôn ngữ này vẫn chưa hoàn toàn biến mất
- Những buzzword thời đó như 4GL phần lớn không tồn tại lâu, nhưng COBOL vẫn trụ lại lâu hơn nhiều lựa chọn thay thế ra đời sau
- Bước ngoặt quyết định giúp COBOL tiếp tục vận hành là vấn đề Y2K, và việc ứng phó thực tế đòi hỏi phải đào tạo một thế hệ lập trình viên COBOL mới
- Một ngôn ngữ từng có nền tảng triển khai lớn có thể được duy trì với một đuôi dài khi số người mới học giảm dần, thay vì đột ngột biến mất
- Ông của tác giả qua đời ngày 1/9/2024 ở tuổi 91; bài viết đan xen giữa hồi ức cá nhân và những dự đoán công nghệ cũ
Tuyên bố “COBOL đã chết” đã xuất hiện từ năm 1992
- Ông của tác giả đã đăng một bài viết tuyên bố cái chết của COBOL trên tạp chí Technical Support vào tháng 6/1992
- Bài viết khi đó có nhắc đến các thuật ngữ mang tính thời đại như 4GL, và tác giả bổ sung rằng COBOL đã sống sót lâu hơn khá nhiều mục trong danh sách ví dụ về 4GL trên Wikipedia
- Văn bản gốc vẫn còn trong kho lưu trữ NaSPA: http://www.naspa.net/magazine/1992/t9206003.txt
- Bài viết năm 1992 phân tách ý nghĩa của từ “dead”, và xem COBOL như một thực thể kiểu Zombie: đã chết nhưng chưa biến mất
- Autocoder cũng được giới thiệu như tiền thân của COBOL, và được so sánh như một ví dụ về ngôn ngữ bị xem là đã chết nhưng vẫn có thể còn một số dấu vết
Tuổi thọ dài của COBOL do Y2K tạo ra
- Một yếu tố lớn khiến zombie COBOL tiếp tục vận động là vấn đề Y2K
- Khi đó nó được đưa tin rầm rộ, rồi về sau trông như thể chẳng có chuyện gì xảy ra, nhưng thực tế đây là một vấn đề khổng lồ
- Quá trình ứng phó đòi hỏi phải đào tạo một thế hệ lập trình viên COBOL mới
- Quá trình này có thể đã góp phần duy trì COBOL lâu hơn
- Tác giả hiện không còn thường dùng cách gọi dead cho ngôn ngữ lập trình
- Một ngôn ngữ từng có nền tảng triển khai lớn thì khó mà chết hẳn
- Thay vào đó, nó để lại một đuôi dài mờ dần khi các lập trình viên mới không còn học nữa
Một khoảnh khắc trong lịch sử công nghệ nối sang hồi ức cá nhân
- Ông của tác giả qua đời ngày 1/9/2024 ở tuổi 91
- Nguyên nhân tử vong chính thức là viêm phổi
- Bà của tác giả đã qua đời vào tháng 4 cùng năm, và ông đã yêu cầu không điều trị
1 bình luận
Các ý kiến trên Hacker News
Bài viết nhắc đến 4GL, một thuật ngữ đã rất lâu rồi mới nghe lại
COBOL cũng từng hứa hẹn rằng “trông giống như câu văn con người đọc được nên sẽ không còn cần lập trình viên nữa”, điều này khá giống các nền tảng low-code hay mã do LLM tạo ra ngày nay
Vấn đề là người bình thường thường không thể mô tả và chia nhỏ vấn đề đủ chi tiết để đưa ra một giải pháp hoạt động được. Nếu làm được quá trình đó thì rốt cuộc cũng thành lập trình viên, và bài học cốt lõi của COBOL nằm ở chỗ lý do cần lập trình viên không chỉ vì giao diện máy tính hay ngôn ngữ
Nó gần với mục tiêu để người hiểu rõ quy trình công việc có thể chuyển chúng sang COBOL mà không cần học nhiều về cách máy tính hoạt động, tương tự các nhà phân tích hay người phụ trách dữ liệu trò chuyện với cơ sở dữ liệu bằng SQL
COBOL và 4GL chủ yếu nhằm xây dựng ứng dụng nghiệp vụ như lương, ngân hàng, nhân sự, tồn kho, và đặc biệt tập trung vào xử lý batch để giảm các công việc khối lượng lớn lặp đi lặp lại như quyết toán
Đây là sản phẩm của thời kỳ chưa có DBMS chuyên dụng, nên cấu trúc tệp và các động từ liên quan đến tệp rất phát triển, và cũng có những điểm giống SQL ngày nay
Ngay cả khi LLM tạo ra giải pháp như phép màu, trách nhiệm diễn đạt vấn đề một cách súc tích và chính xác chỉ được đẩy lên tầng trên mà thôi
Cuối cùng ta vẫn “lập trình” bằng prompt và rà soát sản phẩm đã được hình thức hóa mà LLM đề xuất, tức là mã. Bản chất của lập trình có thể chuyển thành prompt engineering, nhưng công việc hiểu mã dưới dạng một ngôn ngữ hình thức vẫn còn đó
Bài viết nói 4GL từng là cơn sốt lớn vào đầu thập niên 1990, nhưng tôi nghi ngờ liệu điều đó có đúng cả bên ngoài mainframe hay không. Phong trào 4GL ngay từ đầu đã rất hướng mainframe, và Wikipedia cũng nhắc đến mục tiêu ban đầu là giảm số thẻ đục lỗ cần cho một chương trình
Đến năm 1992 thì Linux đã xuất hiện, Python cũng đang được phát triển, Perl đã trở nên phổ biến và Haskell cũng đã có phiên bản đầu. Tuyến đầu công nghệ đang dịch chuyển từ workstation đắt tiền sang PC tiêu dùng, và tôi cho rằng các nhà thiết kế ngôn ngữ cũng không quá ý thức về khái niệm 4GL ngay cả khi họ tạo ra những thứ về sau có thể xem là 4GL, như dBase, HyperTalk, AppleScript
Tôi đồng ý rằng văn bản giống ngôn ngữ tự nhiên là một ý tưởng tệ cho phần lớn mục đích lập trình, nhưng không nghĩ đó là lý do duy nhất khiến phong trào 4GL thất bại. Hầu hết 4GL thậm chí cũng không giống ngôn ngữ tự nhiên hơn COBOL, vốn là 3GL
Vấn đề lớn hơn là phong trào 4GL đã không định nghĩa đúng thế hệ mới là gì, cái gì là hữu ích. 2GL mang lại bước chuyển cách mạng là dịch từ assembly sang mã máy, 3GL là biên dịch, còn thay đổi có thể định nghĩa được ở 4GL cùng lắm chỉ là “đưa thêm các chức năng vốn nằm trong routine hay thư viện bên ngoài vào trong ngôn ngữ”
Cách tiếp cận này phát huy tốt trong các ngôn ngữ chuyên biệt theo miền, vì thế mới có những 4GL thành công như SQL, R, MATLAB. Ngược lại, tôi cho rằng khái niệm 4GL đa dụng cuối cùng tất yếu sẽ dẫn đến một ngôn ngữ quá cồng kềnh
Ngày nay hầu như không còn ai có thể hoặc cần làm việc đó
Trong ngữ cảnh này, tôi nghĩ đến Scala. Nhìn theo cách bài viết mô tả COBOL, tôi nghĩ Scala về cơ bản cũng gần như đã chết
Vẫn có nhiều doanh nghiệp và dịch vụ có các thành phần cốt lõi viết bằng Scala, nhưng mức độ quan tâm trong các dự án mới đã giảm mạnh
Giai đoạn 2012–2014, có vẻ như trên HN liên tục thấy các bài “Làm X bằng Scala”, còn giờ thì gần như không thấy nữa. Có thể đây là hiện tượng tự nhiên và không tránh khỏi, nhưng vẫn đáng tiếc vì Scala từng có những điểm hay mà các ngôn ngữ chủ lưu khác đến nay vẫn chưa có được
Có cả những dự án khá quan trọng với hệ sinh thái công ty, như hệ thống kiểm thử; những kỹ sư từng xây dựng các hệ thống như vậy trước đây giờ phần lớn đã trở thành quản lý cấp cao
Có người vẫn ủng hộ lựa chọn công nghệ khi đó, nhưng cũng có người cởi mở hơn nếu được cho cơ hội nhìn lại. Nhìn chung, bầu không khí là nếu lúc ấy đã có Kotlin, hoặc Swift đủ dùng cho dịch vụ backend, thì có lẽ họ đã không chọn Scala
https://redmonk.com/sogrady/2024/09/12/language-rankings-6-2...
Cơn sốt ban đầu đã nguội đi, nhưng như vậy cũng ổn. Ngôn ngữ nào cũng có chu kỳ hype, và các dự đoán thường sai. Các ngôn ngữ lập trình chủ lưu giờ khó mà chết như COBOL
Java đã bị nói là sắp chết từ năm 2001, nhưng vẫn sống sót qua bong bóng dot-com, .NET, chữ P trong LAMP, Ruby, JS và Go. Python cũng từng bị nói là sẽ chết khi chuyển sang phiên bản 3, vì mọi người chuyển sang Ruby
Scala là ngôn ngữ lập trình hàm phổ biến nhất thế giới, có công cụ và thư viện tốt, và tôi cho rằng Scala 3 là một bản nâng cấp xuất sắc
Từng cực kỳ lớn và có cảm giác ở đâu cũng có, nhưng giờ đang dần bị đẩy vào các ngách. Giống COBOL, trong thực tế vẫn còn rất nhiều mã Perl ngoài hiện trường
Jack Henry, SiriusXM, Starbucks, dịch vụ streaming của Disney, và Capitol One cũng đã tạo các dự án mới bằng Scala trong mảng dịch vụ, không phải khoa học dữ liệu, từ 5 năm trước đến nay
Tất nhiên còn nhiều đội hơn nữa, nhưng chỉ kể những cái tên nổi tiếng nghĩ ra ngay cũng đã đến mức này, nên khó có thể nói là đã chết
Tuy vậy, có vẻ các việc làm framework xoay quanh Play, Akka và các công việc Spark thuần túy không dùng Airflow đang giảm. Tôi cho rằng đó chỉ là các việc làm framework xuất phát từ hệ sinh thái Scala, còn bản thân Scala trong nhiều trường hợp chỉ là yếu tố thứ yếu
Tôi thích Scala, nhưng nó luôn là ngôn ngữ ở rìa, còn COBOL thì thật sự có mặt ở khắp nơi
Một ngày nào đó, tôi nghĩ mình nên ngồi xuống và trực tiếp thử các ngôn ngữ legacy như Fortran, COBOL, Ada, APL
Độ phổ biến của chúng rõ ràng đã giảm, nhưng chúng vẫn được dùng ở những nơi quan trọng
Đồng thời tôi cũng nghĩ đến lượng mã Java khổng lồ. Dù tốt hay xấu, Java gần như đã chiếm trọn mảng doanh nghiệp; nhưng không rõ 30–40 năm nữa có lý do gì để chỉ còn những người đã nghỉ hưu dùng Java nhằm duy trì các hệ thống ngân hàng cũ hay không
Có lẽ cũng vì đó là các codebase hoặc nền tảng đơn khối khổng lồ. Ngôn ngữ này không bí hiểm hay khó, chỉ là có quá nhiều mã mà cấu trúc không còn nhìn rõ
Tôi nghĩ trong 100 năm tới nó vẫn sẽ chiếm khoảng 0,05% thị trường
Tuy nhiên trong vài năm gần đây, mã mới phần lớn được viết bằng Kotlin
Cá nhân tôi cũng có cảm tình với nó; hồi thập niên 90, công ty tôi đã thực sự dùng nó trên PC. Công việc là tìm cách đưa dữ liệu vào, và cuối cùng tôi đã viết một routine xử lý số dấu phẩy động như vector gồm 1 và 0, thay đổi bit để chuyển từ định dạng Microsoft sang định dạng IEEE
Dĩ nhiên đó là chuyện thời tôi còn đeo củ hành trên thắt lưng
Nếu làm mô phỏng số thuần túy, có lẽ tôi sẽ thích Fortran hơn C++ hay Python. Ngoại trừ NumPy, mà bản thân NumPy rốt cuộc cũng dựa vào Fortran và C++
Ở Carolina Code Conference 2025, họ vẫn đang tìm diễn giả về COBOL
Đặc biệt vì GnuCOBOL gần đây đã được cập nhật, tôi đã muốn đưa một bài nói về COBOL vào chương trình từ lâu
https://gnucobol.sourceforge.io/
https://carolina.codes
“Tôi không biết ngôn ngữ của năm 2000 sẽ trông như thế nào, nhưng tên của nó sẽ là Fortran.” —Tony Hoare
COBOL có thể được xem là còn sống vì nó đã liên tục thay đổi theo từng thời kỳ. COBOL hiện đại khá khác với COBOL thập niên 1950 mà mọi người bản năng nghĩ đến khi nghe cái tên đó
Tương tự như việc Java được gọi bằng cái tên kiểu Algol-94, và vì thế chúng ta nói rằng mình vẫn đang lập trình bằng Algol
MULTIPLY A BY B GIVING C ON SIZE ERROR STOP RUN.nữa<https://dtss.dartmouth.edu/sciencearticle/index.html>
COBOL chưa chết, nhưng khó tiếp cận. Lý do là gần như không có công cụ mã nguồn mở có thể dùng trên Linux
Tại OCamlPro, họ đã khởi động một dự án tên SuperBOL nhằm xây dựng một môi trường mã nguồn mở xoay quanh trình biên dịch mã nguồn mở GnuCOBOL. GnuCOBOL vốn đã trưởng thành và cũng đang được dùng trong doanh nghiệp
Họ đã phát hành một extension VSCode có tích hợp LSP cho COBOL để mang lại trải nghiệm IDE hiện đại, và cũng đang làm các công cụ khác theo nhu cầu của khách hàng
COBOL có thể học trong một hai ngày, và tôi cũng muốn thử làm những công việc COBOL “nhàm chán”, nhưng tôi không có kinh nghiệm mainframe
https://gnucobol.sourceforge.io/
https://cobolworx.com/pages/cobforgcc.html
Như mọi khi, những cuộc thảo luận kiểu này phụ thuộc vào việc định nghĩa “đã chết” và “còn sống” như thế nào
Nếu có thể gọi một công nghệ là đã chết khi không còn có doanh nghiệp mới nào được xây dựng trên nó nữa, thì có thể xem COBOL là đã chết cũng không sai. Điều tương tự cũng đúng với IBM 390x, thường được dùng như một cách nói thay cho COBOL, tức nền tảng Z/OS
Ngược lại, nếu cho rằng còn được dùng trong môi trường vận hành là còn sống, thì COBOL đương nhiên vẫn sống, và còn sống hơn rất nhiều công nghệ trẻ hơn nó
Tuy nhiên không nhất thiết phải coi điều này là ưu điểm của COBOL hay hệ sinh thái mainframe. Các tổ chức có xu hướng bám lấy thứ đã chạy tốt ngay từ đầu, và ở những nơi từng là lực lượng chủ chốt của làn sóng số hóa ban đầu như chính phủ, ngân hàng, hãng hàng không, lựa chọn đầu tiên đó thường chỉ là mainframe IBM và phần mềm chạy trên đó mà thôi
Mainframe của chúng tôi xử lý thoải mái 100 triệu giao dịch mỗi giờ. Hơn nữa, phần lớn là đồng bộ, và mỗi giao dịch lại kéo theo nhiều giao dịch SQL
Eventual consistency cũng là một cách, nhưng cực kỳ không hợp với lĩnh vực tài chính, và rất có thể cũng vậy trong quân sự, bảo hiểm, y tế và chăm sóc sức khỏe. Có thể chia công việc thành các partition, nhưng khi vượt qua ranh giới shard thì sẽ phát sinh vấn đề nhất quán
COBOL vẫn chưa chết, nhưng đang chậm rãi đi theo hướng đó. Tôi không biết ngân hàng nào lại không tích cực làm việc để rời khỏi mainframe. Dù vậy, các dự báo tôi thấy đều nói mainframe và COBOL sẽ còn tồn tại ít nhất đến năm 2050
Tức là trong 26 năm tới vẫn sẽ còn viết mã COBOL. Lập trình viên COBOL đang có nhu cầu cao và đãi ngộ cũng khá tốt, nên ngay cả nếu bắt đầu sự nghiệp lập trình viên COBOL từ bây giờ, bạn vẫn có thể lấp đầy gần như cả đời làm việc
Rào cản gia nhập luôn cực kỳ cao, và khách hàng chính khi đó cũng là các công ty bảo hiểm lâu đời, ngân hàng, chính phủ và những nơi tương tự. Việc các công ty mới có thể làm điện toán chỉ thực sự khả thi hơn kể từ sau minicomputer
Theo nghĩa đó thì không có gì thay đổi nhiều, và nếu xét đến thị trường mục tiêu của sản phẩm, tôi cho rằng việc “doanh nghiệp mới có dùng hay không” không phải là tiêu chí phù hợp để đánh giá một nền tảng còn sống hay đã chết
Một bộ phận kinh doanh mới hoặc một nhóm startup nội bộ, chẳng hạn một danh mục sản phẩm bảo hiểm mới, cũng có thể phải viết một phần bằng COBOL nếu muốn tích hợp với phần còn lại của hệ thống ngân hàng
Ít nhất, ngay cả khi không viết trực tiếp bằng COBOL, họ cũng có thể đưa nó lên hạ tầng thực thi COBOL hiện có, tức Z/OS, vì không có ngân sách để mua rack x86 mới và thuê người quản lý nó
Cloud là mainframe kiểu mới, nhưng là phiên bản tệ hơn. Nó có đủ mọi nhược điểm mà lại không có ưu điểm lớn nhất
Ngày trước, với CICS, bạn có thể tạo ra các dịch vụ rất ổn định và hiệu năng cao, đồng thời gọi dịch vụ khác trong cùng một transaction. Nền tảng sẽ xử lý các việc phức tạp như duy trì tính toàn vẹn dữ liệu
Thử viết AWS Lambda gọi lẫn nhau trong cùng một transaction thì sẽ thấy khác biệt
Và tôi không hiểu vì sao đối tượng so sánh lại là “AWS Lambda gọi lẫn nhau trong cùng một transaction”. Việc triển khai trên mainframe có từng đơn giản như ném một file
.zipchứa code vào một API đã cấp quyền truy cập cho developer không?Một số người hiểu nhầm rồi phê phán rằng tôi chọn hoặc thích COBOL hơn các ngôn ngữ hiện đại, nhưng không phải ý đó. Tôi chỉ đưa ra một quan sát kiểu luật sư của quỷ từ góc nhìn ngoài khuôn khổ mà thôi
Trớ trêu là đã từng có một ngôn ngữ an toàn bộ nhớ, ổn định, dễ đọc và dễ hiểu hơn Rust: COBOL. Nhưng vì chẳng ai muốn dùng nên nó trở thành một ngôn ngữ “chết”, trong khi những hệ thống đã tạo nên thế giới hiện đại lại chạy trên nó
Ví dụ, nếu so sánh mã Rust và COBOL để nhận một số rồi in ra chẵn/lẻ, phía COBOL đọc trực tiếp hơn
Không rõ nó có đạt cùng mức hiệu năng không, có tích hợp với mã native của các ngôn ngữ khác theo cùng cách không, có trình quản lý gói dùng được trên một hệ thống module hỗ trợ composition và tương thích ngược không, hay có thể biểu diễn thuận tiện hình dạng của dữ liệu và lỗi như các kiểu dữ liệu đại số của Rust không
Cũng như COBOL vẫn được dùng vì có lý do, việc các ngôn ngữ mới được tạo ra cũng có lý do chính đáng
Nếu thêm boilerplate thực sự cần thiết để tạo một chương trình COBOL có thể chạy, nó sẽ in “even” với đầu vào
abcvà in “odd” với đầu vào12Việc đặc biệt bắt bẻ cú pháp Rust cũng khá lạ. Như phần lớn ngôn ngữ ngày nay, Rust về cơ bản cũng là cú pháp họ C, chỉ pha thêm một chút yếu tố OCaml. Bỏ qua cú pháp, Rust và COBOL có mục tiêu rất khác nhau, nên “cứ dùng COBOL là được” không làm mất đi lý do tồn tại của Rust
https://www.ibm.com/docs/en/cobol-zos/6.2?topic=statement-ex...
Có xuất hiện các đoạn mã như
ALLOCATE, thiết lập địa chỉ con trỏ,FREEDòng tweet này hay một cách kỳ lạ
https://x.com/grauhut/status/1000017084435312642
Dịch ra thì nội dung là: “Tôi phát hiện COBOL ở khách hàng. Không sao. Đó là mainframe. Không có gì đặc biệt. Chú thích cuối cùng là từ năm 1985. Người viết là mẹ tôi”