Catatan sang kakek tentang COBOL yang sudah lama “mati”
(wumpus-cave.net)- Tulisan yang dimuat di majalah Technical Support edisi Juni 1992 sebenarnya sudah menyatakan kematian COBOL, tetapi poin utamanya adalah bahwa bahkan setelah 30 tahun berlalu, bahasa itu belum benar-benar lenyap
- Kata-kata tren saat itu seperti 4GL kebanyakan tidak bertahan lama, tetapi COBOL menjadi contoh yang mampu bertahan lebih lama daripada banyak alternatif yang muncul belakangan
- Pemicu penentu yang membuat COBOL terus berjalan adalah masalah Y2K, dan penanganan nyatanya memang memerlukan pelatihan generasi baru programmer COBOL
- Bahasa yang pernah memiliki basis terpasang besar bisa tetap bertahan dengan meninggalkan ekor panjang berupa berkurangnya pembelajar baru, alih-alih tiba-tiba menghilang
- Kakek penulis meninggal pada 1 September 2024 dalam usia 91 tahun, dan tulisan ini memadukan kenangan pribadi dengan prediksi teknologi lama
Pernyataan “COBOL mati” yang sudah muncul pada 1992
- Kakek penulis menerbitkan tulisan di majalah Technical Support edisi Juni 1992 yang menyatakan kematian COBOL
- Dalam tulisan saat itu muncul istilah zamannya seperti 4GL, dan penulis menambahkan bahwa COBOL bertahan lebih lama daripada cukup banyak contoh 4GL dalam daftar contoh Wikipedia
- Teks asli masih tersimpan di arsip NaSPA: http://www.naspa.net/magazine/1992/t9206003.txt
- Tulisan tahun 1992 itu membedakan makna kata “dead”, dan memperlakukan COBOL sebagai sesuatu seperti zombie: sudah mati tetapi belum hilang
- Autocoder juga diperkenalkan sebagai pendahulu COBOL, dan dibandingkan sebagai contoh bahasa yang dianggap mati tetapi mungkin masih menyisakan jejak
Umur panjang COBOL yang dibentuk oleh Y2K
- Faktor besar yang membuat zombie COBOL terus bergerak adalah masalah Y2K
- Saat itu isu ini banyak diberitakan dan setelahnya tampak seolah tidak terjadi apa-apa, tetapi kenyataannya ini memang masalah besar
- Dalam proses penanganannya, generasi baru programmer COBOL harus dilatih
- Proses ini mungkin ikut berkontribusi membuat COBOL bertahan lebih lama
- Penulis kini jarang menggunakan istilah dead untuk bahasa pemrograman
- Bahasa yang pernah memiliki basis terpasang besar sulit untuk benar-benar mati
- Sebaliknya, bahasa itu meninggalkan ekor panjang dan perlahan memudar ketika programmer baru tidak lagi mempelajarinya
Sepenggal sejarah teknologi yang berlanjut menjadi kenangan pribadi
- Kakek penulis meninggal pada 1 September 2024 dalam usia 91 tahun
- Penyebab resmi kematiannya adalah pneumonia
- Nenek meninggal pada April tahun itu, dan sang kakek meminta agar tidak menerima perawatan
1 komentar
Komentar Hacker News
Tulisan ini menyebut 4GL, istilah yang benar-benar sudah lama sekali tidak saya dengar
COBOL juga pernah menjanjikan bahwa karena “tampak seperti kalimat yang dapat dibaca manusia, programmer tidak akan diperlukan lagi,” dan ini mirip dengan platform low-code atau kode yang dihasilkan LLM saat ini
Masalahnya, orang biasa biasanya tidak mampu menjelaskan dan memecah masalah dengan cukup rinci hingga menghasilkan solusi yang berfungsi. Jika seseorang mampu melakukan proses itu, pada akhirnya ia sudah menjadi programmer, dan pelajaran inti dari COBOL adalah bahwa alasan programmer dibutuhkan bukan semata-mata karena antarmuka komputer atau bahasa pemrogramannya
Arahnya lebih kepada memungkinkan orang yang memahami proses bisnis dengan baik untuk menuliskannya ke COBOL tanpa harus banyak mempelajari cara kerja komputer, mirip dengan analis atau penanggung jawab data yang berbicara dengan basis data melalui SQL
Tujuan utama COBOL dan 4GL adalah membangun aplikasi bisnis seperti penggajian, perbankan, SDM, dan inventori, dengan fokus khusus pada pemrosesan batch yang mengurangi pekerjaan massal berulang seperti rekonsiliasi
Karena lahir pada masa belum ada DBMS khusus, organisasi file dan verba terkait file sangat berkembang, dan ada bagian yang juga mirip dengan SQL masa kini
Sekalipun LLM secara ajaib menghasilkan solusi, tanggung jawab untuk mengungkapkan masalah secara ringkas dan tepat hanya bergeser ke atas
Pada akhirnya kita “memprogram” lewat prompt dan meninjau kode sebagai artefak terformalkan yang diusulkan LLM. Sifat pemrograman mungkin berubah menjadi prompt engineering, tetapi pekerjaan memahami kode sebagai bahasa formal tetap ada
Artikel itu mengatakan bahwa 4GL sangat populer pada awal 1990-an, tetapi saya ragu apakah itu juga berlaku di luar mainframe. Gerakan 4GL sejak awal sangat berorientasi mainframe, dan Wikipedia pun menyebut salah satu tujuan awalnya adalah mengurangi jumlah punch card yang diperlukan untuk program
Pada 1992, Linux sudah muncul, pekerjaan pada Python sedang berlangsung, Perl sudah mulai populer, dan Haskell juga sudah memiliki versi awal. Garis depan teknologi sedang bergeser dari workstation mahal ke PC konsumen, dan menurut saya para perancang bahasa tidak terlalu memikirkan konsep 4GL bahkan ketika membuat sesuatu yang pada akhirnya bisa dipandang sebagai 4GL, seperti dBase, HyperTalk, dan AppleScript
Saya setuju bahwa teks yang mirip bahasa alami adalah ide buruk untuk sebagian besar penggunaan pemrograman, tetapi menurut saya bukan hanya itu alasan gerakan 4GL gagal. Kebanyakan 4GL bahkan tidak lebih mirip bahasa alami daripada COBOL, yang merupakan 3GL
Masalah yang lebih besar adalah gerakan 4GL tidak berhasil mendefinisikan dengan benar apa itu generasi baru dan apa yang berguna. 2GL membawa perubahan revolusioner berupa penerjemahan dari assembly ke bahasa mesin, 3GL membawa kompilasi, tetapi perubahan yang masih bisa didefinisikan pada 4GL paling-paling hanya “mari masukkan lebih banyak fungsi yang sebelumnya ada di rutin eksternal atau library ke dalam bahasa”
Pendekatan ini berhasil pada bahasa khusus domain, sehingga muncullah 4GL yang sukses seperti SQL, R, dan MATLAB. Sebaliknya, menurut saya konsep 4GL serbaguna pada akhirnya memang ditakdirkan berujung pada bahasa yang terlalu membengkak
Saat ini hampir tidak ada orang yang bisa atau perlu melakukan hal seperti itu
Dalam konteks ini, yang terlintas adalah Scala. Kalau melihat cara tulisan itu menggambarkan COBOL, menurut saya Scala juga secara praktis sudah mendekati keadaan mati
Masih ada banyak perusahaan dan layanan yang memiliki komponen inti yang ditulis dengan Scala, tetapi minat untuk proyek baru sudah sangat meredup
Pada 2012–2014, rasanya saya terus melihat artikel “melakukan X dengan Scala” di HN, tetapi sekarang hampir tidak terlihat lagi. Ini mungkin fenomena yang wajar dan tak terhindarkan, tetapi tetap disayangkan karena Scala punya kelebihan-kelebihan bagus yang sampai sekarang belum dimiliki bahasa arus utama lain
Ada juga proyek yang cukup penting bagi ekosistem perusahaan, seperti sistem pengujian, dan para engineer yang dulu membuat sistem semacam ini sekarang kebanyakan sudah menjadi manajer senior
Ada yang masih mendukung pilihan teknologi saat itu, tetapi ada juga yang lebih terbuka jika diberi kesempatan untuk meninjau kembali. Secara umum, suasananya adalah bahwa jika saat itu Kotlin sudah ada, atau Swift cukup layak dipakai untuk layanan backend, mereka kemungkinan tidak akan memilih Scala
https://redmonk.com/sogrady/2024/09/12/language-rankings-6-2...
Hype awalnya memang sudah reda, tetapi tidak apa-apa. Semua bahasa punya siklus hype, dan prediksi biasanya meleset. Bahasa pemrograman arus utama sekarang sulit mati seperti COBOL
Java sudah disebut akan mati sejak 2001, tetapi berhasil melewati gelembung dot-com, .NET, P dalam LAMP, Ruby, JS, dan Go. Python juga pernah disebut akan mati saat transisi ke versi 3 karena orang-orang pindah ke Ruby
Scala adalah bahasa pemrograman fungsional paling populer di dunia, tool dan library-nya bagus, dan menurut saya Scala 3 adalah upgrade yang sangat baik
Dulu sangat besar dan terasa ada di mana-mana, tetapi sekarang makin terdorong menjadi niche. Seperti COBOL, masih banyak kode Perl yang tersisa di lapangan nyata
Jack Henry, SiriusXM, Starbucks, layanan streaming Disney, dan Capitol One juga dari lima tahun terakhir hingga sekarang membuat proyek baru Scala di area layanan, bukan data science
Tentu ada lebih banyak tim, tetapi kalau hanya menyebut nama-nama terkenal yang langsung terpikir saja sudah sebanyak ini, jadi sulit menyebutnya mati
Namun pekerjaan framework yang berpusat pada Play dan Akka, serta pekerjaan Spark murni yang bukan Airflow, tampaknya memang berkurang. Menurut saya itu sering kali hanyalah pekerjaan framework yang lahir dari ekosistem Scala, sementara Scala sendiri hanya bersifat sekunder
Saya suka Scala, tetapi ia selalu merupakan bahasa pinggiran, sedangkan COBOL benar-benar ada di mana-mana
Suatu hari nanti saya merasa harus duduk dan mencoba langsung bahasa-bahasa legacy seperti Fortran, COBOL, Ada, dan APL
Popularitasnya jelas menurun, tetapi bahasa-bahasa itu masih dipakai di tempat-tempat penting
Pada saat yang sama, saya juga teringat pada jumlah kode Java yang sangat besar. Baik atau buruk, Java hampir melahap ranah enterprise, dan saya bertanya-tanya apakah 30–40 tahun lagi hanya para pensiunan yang akan memakai Java untuk memelihara sistem perbankan lama
Mungkin juga karena sifatnya sebagai codebase atau platform tunggal yang sangat besar. Bahasanya bukan sesuatu yang muskil dan sulit, hanya saja ada terlalu banyak kode yang strukturnya tidak terlihat jelas
Saya rasa selama 100 tahun ke depan ia akan tetap menguasai sekitar 0,05% pasar
Namun dalam beberapa tahun terakhir, sebagian besar kode baru ditulis dengan Kotlin
Secara pribadi saya juga punya keterikatan dengannya; pada 1990-an saya benar-benar memakainya di PC di perusahaan. Tugasnya adalah mencari cara memasukkan data, dan akhirnya saya menulis rutin yang memperlakukan angka floating-point seperti vektor 1 dan 0, lalu mengubah bit untuk mengonversinya dari format Microsoft ke format IEEE
Tentu saja, itu cerita dari masa ketika saya masih mengikat bawang di ikat pinggang
Jika melakukan simulasi numerik murni, saya mungkin akan lebih memilih Fortran daripada C++ atau Python. Kecuali NumPy, tetapi NumPy sendiri pada akhirnya juga bergantung pada Fortran dan C++
Di Carolina Code Conference 2025, mereka masih mencari pembicara COBOL
Terutama karena GnuCOBOL baru-baru ini diperbarui, saya sudah cukup lama ingin memasukkan sesi COBOL
https://gnucobol.sourceforge.io/
https://carolina.codes
“Saya tidak tahu seperti apa rupa bahasa pada tahun 2000, tetapi namanya akan Fortran.” —Tony Hoare
COBOL bisa dianggap hidup karena terus berubah dari zaman ke zaman. COBOL modern cukup berbeda dari COBOL tahun 1950-an yang secara naluriah dibayangkan orang ketika mendengar namanya
Mirip seperti jika Java disebut dengan nama seperti Algol-94, lalu karena itu kita mengatakan bahwa kita masih memprogram dengan Algol
MULTIPLY A BY B GIVING C ON SIZE ERROR STOP RUN.<https://dtss.dartmouth.edu/sciencearticle/index.html>
COBOL belum mati, tetapi sulit diakses. Sebab hampir tidak ada alat open source yang bisa dipakai di Linux
Di OCamlPro, mereka memulai proyek bernama SuperBOL untuk membangun lingkungan open source dengan berpusat pada compiler open source GnuCOBOL. GnuCOBOL sudah matang dan juga digunakan di perusahaan
Mereka sudah merilis ekstensi VSCode yang menyertakan LSP untuk COBOL, sehingga menyediakan pengalaman IDE modern, dan sedang mengerjakan alat-alat lain sesuai kebutuhan pelanggan
COBOL bisa dipelajari dalam satu-dua hari dan saya ingin mencoba pekerjaan COBOL yang “membosankan”, tetapi saya tidak punya pengalaman mainframe
https://gnucobol.sourceforge.io/
https://cobolworx.com/pages/cobforgcc.html
Seperti biasa, diskusi semacam ini bergantung pada bagaimana mendefinisikan “mati” dan “hidup”
Jika sebuah teknologi bisa disebut mati ketika bisnis baru tidak lagi dibangun di atasnya, maka COBOL bisa dianggap mati. Hal yang sama berlaku untuk IBM 390x, yaitu platform Z/OS, yang biasanya dipakai seperti representasi pengganti COBOL
Sebaliknya, jika dianggap hidup selama masih dipakai di lingkungan operasional, maka COBOL tentu saja hidup, bahkan jauh lebih hidup daripada banyak teknologi yang lebih muda darinya
Namun tidak perlu menganggap ini sebagai keunggulan COBOL atau ekosistem mainframe. Organisasi cenderung terus berpegang pada sesuatu yang pertama kali bekerja dengan baik, dan di tempat-tempat seperti pemerintah, bank, dan maskapai penerbangan yang menjadi pelaku utama digitalisasi awal, pilihan pertama itu kebetulan biasanya mainframe IBM beserta perangkat lunak di atasnya
Mainframe kami dengan mudah memproses 100 juta transaksi per jam. Selain itu, sebagian besar bersifat sinkron, dan setiap transaksi berlanjut menjadi beberapa transaksi SQL
Eventual consistency memang salah satu cara, tetapi sangat tidak cocok untuk bidang keuangan, dan kemungkinan besar juga untuk militer, asuransi, medis, dan kesehatan. Pekerjaan juga bisa dibagi ke dalam partisi, tetapi muncul masalah konsistensi saat melintasi batas shard
COBOL belum mati, tetapi perlahan menuju ke sana. Saya tidak tahu ada bank yang tidak secara aktif berupaya keluar dari mainframe. Meski begitu, perkiraan yang saya lihat mengatakan mainframe dan COBOL akan tetap ada setidaknya sampai 2050
Artinya, kode COBOL akan dipakai selama 26 tahun ke depan. Programmer COBOL banyak dicari dan bayarannya cenderung bagus, jadi sekalipun memulai karier sebagai programmer COBOL sekarang, masa kerja yang hampir seumur hidup masih bisa terpenuhi
Hambatan masuknya selalu sangat tinggi, dan pelanggan utamanya saat itu pun adalah perusahaan asuransi lama, bank, pemerintah, dan sejenisnya. Baru setelah minicomputer, kira-kira, perusahaan baru bisa menjalankan komputasi
Dalam pengertian itu, tidak banyak yang berubah, dan mengingat target pasar produknya, saya rasa “apakah dipakai bisnis baru” bukan kriteria yang tepat untuk menilai hidup-matinya sebuah platform
Unit bisnis baru atau tim startup internal, misalnya kategori produk asuransi baru, juga bisa menulis sebagian dengan COBOL jika harus terintegrasi dengan sistem bank lainnya
Paling tidak, meskipun tidak ditulis langsung dalam COBOL, mereka bisa saja menaruhnya di infrastruktur eksekusi COBOL yang sudah ada, yaitu di atas Z/OS, karena tidak ada anggaran untuk membeli rack x86 baru beserta orang yang akan mengelolanya
Cloud adalah mainframe baru, tetapi versi yang lebih buruk. Ia memiliki semua kekurangannya, tetapi tidak memiliki keunggulan terbesarnya
Dulu, dengan CICS, kita bisa membuat layanan yang sangat stabil dan berkinerja tinggi, serta memanggil layanan lain dalam transaksi yang sama. Platform menangani pekerjaan rumit seperti menjaga integritas data
Cobalah sekali menulis AWS Lambda yang saling memanggil dalam transaksi yang sama, maka perbedaannya akan terlihat
Dan saya tidak mengerti mengapa pembandingnya adalah “AWS Lambda yang saling memanggil dalam transaksi yang sama”. Apakah deployment mainframe juga sesederhana melempar
.zipberisi kode ke API yang memberikan hak akses kepada developer?Sebagian orang menafsirkan ini seolah-olah saya memilih atau lebih menyukai COBOL dibanding bahasa modern lalu mengkritiknya, tetapi bukan itu maksudnya. Saya hanya melakukan pengamatan ala devil’s advocate dari luar kotak
Ironisnya, bahasa yang memory-safe, stabil, dan lebih mudah dibaca serta dipahami daripada Rust sebenarnya sudah ada dalam bentuk COBOL. Namun karena tidak ada yang ingin memakainya, ia menjadi bahasa yang “mati”, sementara sistem-sistem yang memungkinkan dunia modern justru berjalan di atasnya
Sebagai contoh, jika membandingkan kode Rust dan COBOL yang menerima input angka lalu mencetak genap atau ganjil, versi COBOL terbaca lebih langsung
Tidak jelas apakah performanya setara, apakah bisa berinteroperasi dengan kode native dari bahasa lain dengan cara yang sama, apakah memiliki manajer paket yang layak di atas sistem modul yang membantu komposisi dan kompatibilitas mundur, atau apakah bisa mengekspresikan bentuk data dan error dengan nyaman seperti tipe data aljabar di Rust
Sebagaimana ada alasan COBOL masih digunakan, ada juga alasan bagus mengapa bahasa-bahasa baru dibuat
Jika membuat program COBOL yang bisa dijalankan dengan menambahkan boilerplate yang benar-benar diperlukan, input
abcakan mencetak “even” dan input12akan mencetak “odd”Menjadikan sintaks Rust sebagai masalah khusus juga cukup aneh. Seperti kebanyakan bahasa masa kini, Rust pada dasarnya memakai sintaks keluarga C dengan sedikit unsur OCaml. Terlepas dari sintaks, Rust dan COBOL punya tujuan yang sangat berbeda, jadi alasan keberadaan Rust tidak hilang hanya dengan mengatakan “pakai COBOL saja”
https://www.ibm.com/docs/en/cobol-zos/6.2?topic=statement-ex...
Ada kode seperti
ALLOCATE, pengaturan alamat pointer, danFREETweet ini terasa menarik dengan cara yang aneh
https://x.com/grauhut/status/1000017084435312642
Jika diterjemahkan, isinya kira-kira: “Saya menemukan COBOL di klien. Tidak apa-apa. Ini mainframe. Tidak ada yang istimewa. Komentar terakhir berasal dari tahun 1985. Penulisnya adalah ibu saya”