撰稿 | 千山
審校 | 云昭
在編程語言中，COBOL 絕對算得上是“上古神獸”，可以追溯到1959年左右，目前全球仍有眾多大型企業(yè)或政府機構用的是COBOL 編寫的舊軟件。但因為太過古舊，很多新手開發(fā)者甚至聞所未聞。
為了解決COBOL應用程序現(xiàn)代化的問題，IBM最近推出了IBM Z 服務，意在利用 AI 技術將COBOL 代碼轉譯成 Java 語言。
1、骨灰級語言迎來新生機
COBOL這門語言雖然古老，但生命力驚人。根據(jù)2022年的一項調查，生產(chǎn)系統(tǒng)中使用的COBOL代碼超過了8000億行。但問題在于，COBOL 的存在已逾一個甲子，很多編寫應用程序的開發(fā)人員早已退休甚至離世了。
正因為“懂COBOL”的程序員極為稀缺，所以他們的薪水是相當可觀的，甚至連美國政府都曾經(jīng)公開招募COBOL程序員，以便維護那些還在運轉中的眾多關鍵任務應用程序。
無論從可操作性還是效率來說，COBOL在當下都過時了，但正是由于COBOL專家的數(shù)量極少，這也導致“遷移”往往成為一個復雜昂貴的命題。2012年，澳大利亞聯(lián)邦銀行下決心更換了其核心COBOL平臺，這場改造耗時5年，耗資超過7億美元。
在這一背景下，IBM發(fā)布了IBM Z的Code Assistant，它使用代碼生成AI模型將COBOL代碼轉換為Java。
IBM介紹，用于 Z 大型機的 watsonx Code Assistant 旨在幫助開發(fā)人員評估和確定最需要現(xiàn)代化的代碼，使他們能夠更快地更新大型應用程序，專注于關鍵任務。
Omdia 首席分析師 Roy Illsley對此評論道，將代碼遷移到 Java 意味著可以找到更多的程序員來做支持，如果 COBOL 應用程序在Z大型機上的 Linux 系統(tǒng)中運行，那么它們將來可能更容易地從大型機上遷移下來(盡管這并不總是像看起來那么容易）。
據(jù)悉，IBM Z的Code Assistant將于今年第四季度上市，在此之前，IBM 會在今年9月初于拉斯維加斯舉行的TechXchange會議上演示該功能。
2、轉換成Java，代碼高度自然
那么IBM Z服務到底是如何發(fā)揮作用的呢？
IBM研究院首席科學家Ruchir Puri在接受外媒采訪時表示：“IBM建立了一個新的、最先進的生成人工智能代碼模型，將遺留的COBOL程序轉換為企業(yè)Java，生成的代碼具有高度的自然性。”
為幫助企業(yè)重構其大型機應用程序，IBM Z的Code Assistant可以在本地配置中運行，也可以作為托管服務在云中運行，由代碼生成模型CodeNet提供支持。
Puri提到，CodeNet 模型使用1.5萬億個參數(shù)進行訓練，擁有 200 億個參數(shù)，設計了一個大的上下文窗口(32,000個令牌)，以“捕獲更廣泛的上下文”，實現(xiàn)“更有效的COBOL到Java轉換”。
放眼當前市場，將COBOL應用程序轉換為Java語法的自動化工具并不少見。Puri也承認這一點。他進一步指出，Code Assistant采取措施避免犧牲COBOL的功能，同時降低成本并生成易于維護的代碼，這就區(qū)別于市場上的一些同類競品。
因為有些類似的產(chǎn)品主要是針對COBOL 代碼進行靜態(tài)和動態(tài)分析而不是運用AI，究其根本，它們只是將代碼拆分為仍然基于 COBOL 的微服務。
watsonx Code Assistant for Z 生成的 Java 代碼將是面向對象的，但仍會與 IBM 聲稱的 COBOL 應用程序的其余部分以及 CICS、IMS、DB2 和其他 z/OS 運行時等關鍵服務進行互操作。
“IBM為IBM Z構建了代碼助手，以便能夠混合和匹配COBOL和Java服務，”Puri說。“如果系統(tǒng)的‘理解’和‘重構’功能建議應用程序的給定子服務需要保留在COBOL中，那么它將保持這種方式，而其他子服務將轉換為Java。”
但這并不是等于說IBM Z的服務是完美無瑕的。斯坦福大學最近的一項研究發(fā)現(xiàn)，使用類似于它的代碼生成人工智能系統(tǒng)的軟件工程師更有可能在他們開發(fā)的應用程序中造成漏洞。實際上，Puri警告不要在由人類專家審閱代碼之前部署由Code Assistant生成的代碼。
3、轉換成Java的影響：風險與垃圾代碼
“像任何人工智能系統(tǒng)一樣，企業(yè)的COBOL應用程序可能有獨特的使用模式，而IBM Z的Code Assistant可能還沒有掌握這些模式。”“必須用最先進的漏洞掃描儀掃描代碼，以確保代碼的安全性。”Puri如是說道。
事實上，也有開發(fā)人員對AI生成的代碼的不可控性提出了質疑。在Reddit論壇的相關討論中，有網(wǎng)友指出：“在某些時候，我們無法知道人工智能的下一個動作，到底是處于天才還是愚蠢的決策。”
“有些東西我們可以理解和單元測試，但在更大的規(guī)模上，系統(tǒng)非常復雜，有很多細微差別和級別，以至于沒有一個人知道每個設計決策的‘原因’。”
還有人直接提出，“Java真的是這里最好的選擇嗎？”對此，有人表示理解，認為選擇Java是個務實的決定。“Java是選項，因為IBM大型機有一個JVM。因此，從通過 CICS 運行 COBOL 過渡到運行 Java 是相當無縫的。特別是使用 IBM 的 Rational Developer 工具集。”
但也有人提出異議。“最大的問題是Java和COBOL的結構完全不同，因此機械翻譯往往會產(chǎn)生完全的垃圾。認為它是一個好的候選者的唯一原因是因為你也沒有實際編程的經(jīng)驗。所以……很大程度上是一個管理決策。”
不過，開發(fā)者們多數(shù)還是認為，Java擁有強大的企業(yè)影響力，并且已經(jīng)在遺留環(huán)境中采用多年，所以考慮用它進行遷移并不令人驚訝。
IBM對這類爭論應該也有所預料，因此該公司也表示watsonx Code Assistant產(chǎn)品組合將在未來擴展到其他編程語言。
4、COBOL二度出圈，不遠了
撇開風險不談，在IBM看來，像Code Assistant這樣的工具對其未來的發(fā)展至關重要。今天，大約84%的IBM大型機客戶運行COBOL——主要是政府部門和金融業(yè)的客戶。雖然IBM的大型機部門仍然是其整體業(yè)務的很大一部分，但該公司將大型機視為通往廣闊的、有利可圖的混合計算環(huán)境的橋梁。
尤其再這樣一個代碼生成AI工具的時代，許多類Copilot的工具已經(jīng)問世。早前，GitHub Copilot和亞馬遜CodeWhisperer等工具的出現(xiàn)打響了競逐的號角。藍色巨人當然不能示弱。今年5月，IBM在其Watsonx人工智能服務中推出了fm.model.code，該服務為沃森代碼助手提供支持，允許開發(fā)人員在程序(包括紅帽的Ansible Lightspeed)中使用簡單的英語提示生成代碼。
如今IBM Z服務的推出，顯而易見是在AI編碼助手領域針對Z大型機的針對性優(yōu)化。可以想象通過這樣的方式，COBOL的應用前景會更加的擴大，Java技術棧的開發(fā)者也許再也不用看見這個晦澀的老語種避而遠之了。
同時，未來IBM是否將加速產(chǎn)品上市時間并繼續(xù)擴大技能庫，相信不久就會有答案。
參考鏈接：
https://techcrunch.com/2023/08/22/ibm-taps-ai-to-translate-cobol-code-to-java/
https://www.theregister.com/2023/08/22/ibm_says_genai_can_convert/
https://www.reddit.com/r/programming/comments/15z7j1u/ibm_taps_ai_to_translate_cobol_code_to_java/
