COBOL’un Uzun Süredir “Ölü” Olduğuna Dair Büyükbabanın Kaydı

 (wumpus-cave.net)
1 puan yazan GN⁺ 2024-10-02 | 1 yorum | WhatsApp'ta paylaş
  • Haziran 1992’de Technical Support dergisinde yayımlanan bir yazı zaten COBOL’un ölümünü ilan etmişti; ancak asıl nokta, aradan 30 yıl geçmesine rağmen bu dilin tamamen ortadan kalkmamış olması
  • O dönemin 4GL gibi moda terimlerinin çoğu uzun ömürlü olmadı, ancak COBOL birçok daha geç ortaya çıkan alternatife göre daha uzun dayanan bir örnek olarak kaldı
  • COBOL’u çalışır halde tutan belirleyici etken Y2K sorunu oldu ve fiilî müdahale için yeni bir COBOL programcı kuşağının eğitilmesi gerekti
  • Bir dönem kurulu tabanı büyük olan diller, bir anda yok olmaktan ziyade yeni öğrenenlerin azalmasıyla birlikte uzun bir kuyruk bırakarak varlığını sürdürebilir
  • Yazarın büyükbabası 1 Eylül 2024’te 91 yaşında hayatını kaybetti; bu yazı, kişisel bir anıyla eski teknoloji öngörülerinin iç içe geçtiği bir metin

1992’de gelen “ölü COBOL” ilanı

  • Yazarın büyükbabası, Haziran 1992’de Technical Support dergisinde COBOL’un ölümünü ilan eden bir yazı yayımladı
  • O dönemki yazıda 4GL gibi dönemin terimleri geçiyor; yazar da Wikipedia’daki 4GL örnek listesindekilerin önemli bir kısmından COBOL’un daha uzun yaşadığını ekliyor
  • Orijinal metin NaSPA arşivinde duruyor: http://www.naspa.net/magazine/1992/t9206003.txt
  • 1992 tarihli yazı, “dead” sözcüğünün anlamını ayırarak COBOL’u ölmüş ama ortadan kaybolmamış, Zombie benzeri bir varlık olarak ele alıyor
    • Autocoder da COBOL’un öncülü olarak tanıtılıyor; ölü bir dil sayılmasına rağmen bazı izler bırakmış olabilecek bir örnek olarak karşılaştırılıyor

Y2K’nin COBOL’a kazandırdığı uzun ömür

  • COBOL zombiğini hareket halinde tutan en büyük etkenlerden biri Y2K sorunu oldu
    • O dönemde haberlerde büyük yer buldu ve sonrasında sanki hiçbir şey olmamış gibi göründü, ama gerçekte devasa bir sorundu
    • Müdahale sürecinde yeni bir COBOL programcı neslinin eğitilmesi gerekti
    • Bu sürecin, COBOL’un daha uzun süre ayakta kalmasına katkıda bulunmuş olabileceği belirtiliyor
  • Yazar artık programlama dilleri için dead ifadesini pek kullanmıyor
    • Bir zamanlar büyük bir kurulu tabana sahip olan dillerin tamamen ölmesi zor
    • Bunun yerine, yeni programcılar tarafından öğrenilmemeye başlayarak giderek silikleşen uzun bir kuyruk bırakıyorlar

Kişisel bir anıya uzanan teknoloji tarihi sahnesi

  • Yazarın büyükbabası 1 Eylül 2024’te 91 yaşında hayatını kaybetti
    • Resmî ölüm nedeni zatürreydi
    • Büyükannesi aynı yılın Nisan ayında vefat etmişti ve büyükbabası tedavi görmek istemediğini belirtmişti

İlgili okumalar

1 yorum

 
GN⁺ 2024-10-02
Hacker News yorumları

  • Yazı 4GL'den bahsediyor; gerçekten çok uzun zamandır duymadığım bir terim
    COBOL da “insanların okuduğu cümlelere benzediği için artık programcılara gerek kalmayacağı” vaadinde bulunmuştu; bu da günümüzün low-code platformlarına ya da LLM tarafından üretilen koda benziyor
    Sorun şu ki sıradan insanlar genelde, çalışan bir çözüm çıkacak kadar problemi yeterince ayrıntılı biçimde açıklayıp parçalara ayıramıyor. Bu süreci yapabildiğinizde sonuçta programcı olmuş oluyorsunuz; COBOL'un temel dersi de programcılara ihtiyaç duyulmasının nedeninin yalnızca bilgisayar arayüzleri ya da diller olmadığı

    • Genel olarak katılıyorum, ama COBOL'un “ortalama insan” kullansın diye değil, derin alan bilgisine sahip kişiler kullansın diye tasarlanmış bir dil olduğunu düşünüyorum
      İş süreçlerini iyi bilen birinin, bilgisayarların nasıl çalıştığını fazla öğrenmeden bunları COBOL'a aktarabilmesini hedeflemeye daha yakındı; veritabanıyla SQL üzerinden konuşan analistler ya da veri sorumlularıyla benzer bir yönü var
      COBOL ve 4GL'in başlıca amacı maaş bordrosu, bankacılık, insan kaynakları, envanter gibi iş uygulamaları kurmaktı; özellikle mutabakat gibi tekrarlayan büyük hacimli işleri azaltan toplu işleme odaklanıyordu
      Özel DBMS'lerin olmadığı dönemin bir ürünü olduğu için dosya organizasyonu ve dosyayla ilgili fiiller çok gelişmişti; bugünün SQL'iyle benzer yanları da var
    • “Pahalı programcılara artık gerek yok” diyen LLM tabanlı yaklaşımlarda da aynı temel sınır olduğunu hissediyorum
      LLM sihirli biçimde çözüm üretse bile, problemi kısa ve doğru ifade etme sorumluluğu yalnızca daha yukarı taşınıyor
      Sonuçta prompt ile “programlama” yapıyor ve LLM'in önerdiği biçimselleştirilmiş çıktı olan kodu gözden geçiriyoruz. Programlamanın niteliği prompt engineering'e dönüşebilir, ama biçimsel bir dil olan kodu anlama işi ortadan kalkmıyor
    • 4GL, genel mantık, basit veri yapıları ve aritmetiğin ötesinde daha fazlasını ele almak için dile doğal dile benzer yapılar daha fazla katmaya çalışan bir akımdı
      Yazıda 1990'ların başında 4GL'in çok popüler olduğu söyleniyor, ama bunun mainframe dışı dünyada da böyle olup olmadığından şüpheliyim. 4GL hareketi baştan itibaren güçlü biçimde mainframe odaklıydı; Vikipedi de ilk hedeflerden biri olarak programlar için gereken delikli kart sayısını azaltmayı anıyor
      1992'ye gelindiğinde Linux zaten çıkmıştı, Python üzerinde çalışma sürüyordu, Perl popülerlik kazanmıştı ve Haskell'in de ilk sürümü ortaya çıkmıştı. Teknolojinin ön cephesi pahalı workstation'lardan tüketici PC'lerine kayıyordu; dil tasarımcılarının dBase, HyperTalk, AppleScript gibi sonradan 4GL sayılabilecek şeyler üretirken bile 4GL kavramını pek önemsemediklerini düşünüyorum
      Doğal dile benzeyen metnin çoğu programlama kullanımı için kötü bir fikir olduğuna katılıyorum, ancak 4GL hareketinin başarısız olmasının tek nedeni bunun olduğunu sanmıyorum. Çoğu 4GL, bir 3GL olan COBOL'dan daha doğal dile benzer de değildi
      Daha büyük sorun, 4GL hareketinin yeni neslin ne olduğunu ve neyin faydalı olduğunu doğru dürüst tanımlayamamasıydı. 2GL assembly'den makine koduna çeviri, 3GL ise derleme gibi devrimsel değişimler getirdi; 4GL'de az çok tanımlanabilir değişim ise “dış rutinlerde ya da kütüphanelerde bulunan işlevleri dilin içine daha fazla koyalım”dan ibaretti
      Bu yaklaşım alan-özel dillerde iyi işledi; bu yüzden SQL, R, MATLAB gibi başarılı 4GL'ler ortaya çıktı. Buna karşılık genel amaçlı 4GL kavramının eninde sonunda aşırı şişkin dillere varmaya mahkûm olduğunu düşünüyorum
    • Çok şey değişiyor gibi görünse de sonunda aynı kalıp tekrarlanıyor
    • “Artık programcılara gerek yok” sözü şaşırtıcı, ama o dönemde programlama doğrudan kâğıt üzerine makine kodu yazıp doğru çalıştırabilme becerisi anlamına geliyorduysa, bir ölçüde doğru bir ifade olmuş olabilir
      Bugün böyle bir şeyi yapabilen ya da yapması gereken neredeyse kimse yok

  • Bu bağlamda akla Scala geliyor. Yazıda COBOL’un tarif ediliş biçimine bakınca Scala’nın da fiilen ölü bir duruma yakın olduğunu düşünüyorum
    Hâlâ Scala ile yazılmış çekirdek bileşenlere sahip çok sayıda şirket ve servis var, ancak yeni projelerdeki ilgi büyük ölçüde sönmüş durumda
    2012-2014 arasında HN’de sürekli “Scala ile X yapmak” yazıları gördüğümü hatırlıyorum; artık neredeyse hiç görünmüyor. Bu doğal ve kaçınılmaz bir durum olabilir, ama Scala’nın diğer ana akım dillerin hâlâ yakalayamadığı iyi yanlara sahip olması açısından üzücü

    • Apple’daki bazı mühendislik ekipleri mevcut sistemleri sürdürürken yeni Scala projeleri de yapıyor
      Test sistemleri gibi şirket ekosistemi için oldukça önemli projeler de var; eskiden bu sistemleri yapan mühendislerin çoğu şu anda üst düzey yönetici oldu
      O dönemdeki teknoloji seçimini hâlâ savunanlar da var, geriye dönüp bakma fırsatı verilince daha açık fikirli davrananlar da. Genel hava, o zaman Kotlin var olsaydı ya da Swift backend servislerinde kullanılabilir durumda olsaydı Scala’yı seçmeyecekleri yönünde
    • Scala hâlâ aktif biçimde yaşıyor
      https://redmonk.com/sogrady/2024/09/12/language-rankings-6-2...
      İlk dönemki aşırı heyecan yatıştı ama sorun değil. Her dilin bir hype döngüsü vardır ve tahminler de çoğu zaman boşa çıkar. Ana akım programlama dillerinin artık COBOL gibi ölmesi zor
      Java’nın 2001’den beri öleceği söyleniyordu ama dot-com balonunu, .NET’i, LAMP’in P’sini, Ruby’yi, JS’i ve Go’yu atlattı. Python için de 3 sürümüne geçiş sırasında insanlar Ruby’ye kayarken ölecek denmişti
      Scala’nın dünyadaki en popüler fonksiyonel programlama dili olduğunu, araçlarının ve kütüphanelerinin iyi olduğunu, Scala 3’ün de harika bir yükseltme olduğunu düşünüyorum
    • Bugünkü Perl’ün COBOL’a daha yakın olduğunu düşünüyorum
      Bir zamanlar inanılmaz büyüktü ve her yerde varmış gibi hissediliyordu, ama şimdi giderek nişe itiliyor. COBOL gibi sahada hâlâ çok sayıda Perl kodu var
    • Writer’da tüm yeni servisleri Scala ile yapıyoruz
      Jack Henry, SiriusXM, Starbucks, Disney streaming servisleri ve Capital One da son 5 yıldan bugüne veri bilimi dışındaki servis tarafında yeni Scala projeleri geliştiriyor
      Elbette daha çok ekip var, ama aklıma hemen gelen tanınmış yerler bile bu kadar olduğuna göre öldüğünü söylemek zor
      Ancak Play ve Akka merkezli framework işleri ile Airflow olmayan saf Spark işleri azalıyor gibi görünüyor. Bunlar Scala ekosisteminden çıkan framework işleri idi; çoğu durumda Scala’nın kendisi ikincil konumdaydı diye düşünüyorum
    • Scala, COBOL gibi ölemez. Çünkü en başta COBOL gibi geniş ölçekte canlı olduğu bir dönem hiç olmadı
      Scala’yı seviyorum ama hep kenar mahalle dili oldu; COBOL ise gerçekten her yerdeydi

  • Bir gün Fortran, COBOL, Ada, APL gibi legacy dilleri oturup bizzat kurcalamam gerektiğini düşünüyorum
    Popülerlikleri kesinlikle düştü ama hâlâ önemli yerlerde kullanılan diller
    Aynı zamanda aklıma muazzam miktardaki Java kodu da geliyor. Java, iyi ya da kötü, kurumsal alanı neredeyse yuttu; 30-40 yıl sonra yalnızca emeklilerin eski banka sistemlerini ayakta tutmak için Java kullandığı bir tabloya dönüşmemesi için bir sebep var mı, merak ediyorum

    • COBOL’un kalmasının sebebinin COBOL’un kendisinden ziyade vendor/platform bağımlılığı olduğunu düşünüyorum
      Devasa tekil codebase’ler ya da platformlar olması da etkili olabilir. Dil anlaşılmaz ve zor değil; sadece yapısı iyi görünmeyen çok fazla kod var
    • Ada, diğer örneklere göre bir mertebe daha modern ve incelikli bir dil
      Önümüzdeki 100 yıl boyunca pazarın yaklaşık %0,05’ini kaplayacak gibi geliyor
    • Fortune 100 şirketlerinden birinin Android uygulamasını geliştiriyorum; birinin bir Java dosyasını değiştirdiği son commit geçen haftaydı
      Ancak son birkaç yılda yeni kodun çoğu Kotlin ile yazılıyor
    • APL, paradigması o kadar farklı ki doğrudan deneyimlemeye değer
      Kişisel olarak da ona bağlılığım var; 90’larda şirkette PC üzerinde gerçekten kullanıyordum. Mesele, veriyi nasıl içeri alacağımızı bulmaktı; sonunda kayan noktalı sayıları 1 ve 0 vektörü gibi ele alıp bitleri değiştirerek Microsoft biçiminden IEEE biçimine dönüştüren bir rutin yazdım
      Tabii bu, kemerime soğan bağladığım zamanlardan bir hikâye
    • Yalnızca saf sayısal hesaplama yapacaksanız Fortran kullanması epey hoş
      Saf sayısal simülasyon yapacak olsam C++ veya Python yerine Fortran’ı tercih ederdim. NumPy hariç tabii; NumPy’nin kendisi de sonuçta Fortran ve C++’a dayanıyor

  • 2025 Carolina Code Conference için hâlâ COBOL konuşmacısı arıyoruz
    Özellikle GnuCOBOL yakın zamanda güncellendiği için bir süredir programa COBOL konuşması koymak istiyordum
    https://gnucobol.sourceforge.io/
    https://carolina.codes

    • www.cobolworx.com. Yaptığımız işten bahsedebileceğimiz yerleri her zaman arıyoruz

  • “2000 yılının dilinin nasıl görüneceğini bilmiyorum ama adının Fortran olacağını biliyorum.” —Tony Hoare
    COBOL her dönemde değişmeye devam ettiği için canlı sayılabilir. Modern COBOL, insanların adını duyunca içgüdüsel olarak aklına gelen 1950’ler COBOL’undan epey farklı
    Bu biraz Java’nın Algol-94 gibi bir adla anılması ve bu yüzden hâlâ Algol ile programlama yaptığımızı söylememize benziyor

    • Artık kimse MULTIPLY A BY B GIVING C ON SIZE ERROR STOP RUN. gibi yazmıyor
    • Kemeny ve Kurtz, daha 1968’de Fortran’ı “modası geçmiş” diye nitelemişti
      <https://dtss.dartmouth.edu/sciencearticle/index.html>
    • Daha doğrusu “2000 yılının dilinin adının ne olacağını bilmiyorum ama Fortran’a benzeyecek” demeye daha yakın olabilir
    • 2000’de neredeyse doğruydu ama artık değil. Dünya yavaş da olsa değişiyor
    • Peki 70’ler, 80’ler ve 90’lardaki mevcut sistemler gerçekten modern COBOL mu kullanıyor?

  • COBOL ölmedi, ama erişmesi zor. Çünkü Linux’ta kullanılabilecek açık kaynak araç neredeyse yok
    OCamlPro’da, GnuCOBOL açık kaynak derleyicisini merkeze alarak bir açık kaynak ortamı oluşturmak için SuperBOL adlı bir proje başlatıldı. GnuCOBOL zaten olgunlaşmış durumda ve şirketlerde de kullanılıyor
    COBOL için LSP içeren bir VSCode eklentisini yayımlayarak modern bir IDE deneyimi sunuyorlar; müşteri taleplerine göre başka araçlar üzerinde de çalışıyorlar

  • Her zamanki gibi bu tür tartışmalar “ölü” ve “yaşıyor”u nasıl tanımladığınıza bağlı
    Bir teknolojinin üzerinde artık yeni iş kurulmuyorsa ona ölü denebiliyorsa, COBOL’a ölü demek pek yanlış olmaz. COBOL’un genelde vekil ifadesi gibi kullanılan IBM 390x, yani Z/OS platformu için de aynı şey geçerli
    Tersine, üretim ortamlarında hâlâ kullanılıyorsa yaşıyor sayarsak COBOL elbette yaşıyor; hatta kendisinden daha genç birçok teknolojiden çok daha canlı
    Ancak bunu COBOL’un ya da mainframe ekosisteminin bir avantajı olarak görmek gerekmez. Kurumlar ilk başta iyi çalışan şeyi bırakmama eğilimindedir; erken dijitalleşmenin başını çeken devlet kurumları, bankalar ve havayolları gibi yerlerde de o ilk tercih çoğunlukla IBM mainframe’leri ve onların üzerindeki yazılımlardı

    • Mainframe’leri ortadan kaldırmanın zor olmasının nedeni, mainframe düzeyinde eşzamanlı I/O işleme kapasitesini kaldırabilecek başka bir platformun fiilen olmaması
      Bizim mainframe’imiz saatte 100 milyon işlemi rahatça işliyor. Üstelik bunların çoğu senkron ve her işlem birden fazla SQL işlemine dönüşüyor
      Nihai tutarlılık da bir yöntem, ama finans alanına hiç uygun değil; askeriye, sigorta, tıp ve sağlıkta da büyük olasılıkla öyle. İşi partition’lara bölebilirsiniz, ama shard sınırlarını geçtiğinizde tutarlılık sorunları ortaya çıkar
      COBOL henüz ölmedi, ama yavaş yavaş o yöne gidiyor. Mainframe’den çıkmak için aktif olarak çalışmayan tek bir banka bile bilmiyorum. Yine de gördüğüm tahminler mainframe ve COBOL’un en az 2050’ye kadar kalacağını söylüyor
      Yani önümüzdeki 26 yıl boyunca COBOL kodu yazılacak demek. COBOL programcılarına talep yüksek ve ücretleri de iyi sayılır; dolayısıyla bugün COBOL programcısı olarak kariyere başlasanız bile neredeyse bir ömürlük çalışma süresini doldurabilirsiniz
    • Yeni işi kelimenin tam anlamıyla startup olarak görürsek, mainframe 60’lar ve 70’lerde de aslında böyle bir pazar değildi
      Giriş engeli her zaman aşırı yüksekti ve o dönemdeki başlıca müşteriler de köklü sigorta şirketleri, bankalar ve devlet kurumlarıydı. Yeni bir şirketin bilişim yapmasının mümkün hâle gelmesi daha çok mini bilgisayarlardan sonra oldu
      Bu anlamda pek bir şey değişmedi; ürünün hedef pazarını düşününce, bir platformun yaşayıp yaşamadığını belirlemek için “yeni işletmeler kullanıyor mu” ölçütünü uygun görmüyorum
    • Bankaların ya da büyük finans kurumlarının temel iş akışlarında COBOL standardını benimsemiş olma ihtimalini göz ardı etmemek gerekir
      Yeni bir iş birimi ya da kurum içi startup ekibi, örneğin yeni bir sigorta ürünü kategorisi bile bankanın geri kalan sistemleriyle entegre olacaksa bazı kısımları COBOL ile yazabilir
      En azından doğrudan COBOL ile yazmasalar bile, yeni bir x86 rack’i ve onu yönetecek insanları alacak bütçe olmadığından mevcut COBOL çalıştırma altyapısının, yani Z/OS’un üzerine koyabilirler
    • COBOL undead’dir

  • Bulut yeni mainframe’dir, ama daha kötü bir sürümü. Dezavantajlarının hepsine sahip, en büyük avantajı ise yok
    Eskiden CICS ile çok kararlı ve yüksek performanslı servisler oluşturabilir, aynı transaction içinde başka servisleri çağırabilirdiniz. Platform, veri bütünlüğünü korumak gibi karmaşık işleri hallederdi
    Aynı transaction içinde birbirini çağıran AWS Lambda’ları bir kez yazmayı deneyin; fark ortaya çıkar

    • “Dezavantajlarının hepsine sahip” derken tek bir tedarikçiye bağımlılık, muazzam sermaye yatırımı ve operasyon maliyeti, ilgili teknolojileri bilen kişilerin ya eğitim almış ya da deneyimli olmak zorunda olması mı kastediliyor?
      Ayrıca karşılaştırma neden “aynı transaction içinde birbirini çağıran AWS Lambda” anlamıyorum. Mainframe’e dağıtım yapmak da geliştiriciye erişim yetkisi verilmiş bir API’ye kod içeren bir .zip atmak kadar basit miydi?

  • Bazıları bunu, modern diller yerine COBOL’u seçtiğim ya da tercih ettiğim şeklinde anlayıp eleştiriyor; kastım bu değil. Yalnızca kutunun dışından bakan şeytanın avukatı tarzı bir gözlem yaptım.
    İronik biçimde, Rust’tan daha kolay okunup anlaşılabilen, bellek güvenli ve kararlı bir dil olarak COBOL zaten vardı. Ama kimse kullanmak istemediği için “ölü” bir dil oldu; buna karşılık modern dünyayı mümkün kılan sistemler onun üzerinde çalışıyor.
    Örnek olarak bir sayı alıp çift mi tek mi olduğunu yazdıran Rust kodu ile COBOL kodunu karşılaştırınca, COBOL tarafı daha doğrudan okunuyor.

    • Tuhaf bir bakış açısı. Eski dillerdeki iyi özelliklerin kaybolup daha sonraki dillerde yeniden keşfedildiği olur; ama COBOL’un gerçekten Rust’ın çözmeye çalıştığı tüm sorunları çözüp çözmediği şüpheli.
      Aynı düzeyde performans verip vermediğini, başka dillerin yerel kodlarıyla aynı şekilde entegre olup olmadığını, bileşimi ve geriye dönük uyumluluğu kolaylaştıran bir modül sistemi üzerinde kullanılabilir bir paket yöneticisi olup olmadığını, Rust’ın cebirsel veri tipleri gibi veri ve hata biçimlerini rahatça ifade edip edemediğini bilmiyorum.
      COBOL’un hâlâ kullanılmasının nedenleri olduğu gibi, yeni dillerin yaratılmasının da iyi nedenleri var.
    • İki programın karşılaştırılabilir olduğunu söylemek biraz muğlak. Çünkü COBOL sürümü hataları ele almıyor, Rust programı ise en azından panic ederek ele alıyor.
      Gerçekte gerekli boilerplate eklenip çalıştırılabilir bir COBOL programı yapıldığında, abc girdisine “even”, 12 girdisine ise “odd” yazdırıyor.
      Rust sözdizimini özellikle sorun etmek de ilginç. Günümüzdeki çoğu dil gibi Rust da genel olarak C ailesi sözdizimine sahip; biraz da OCaml öğeleri karışmış durumda. Sözdiziminden bağımsız olarak Rust ile COBOL’un hedefleri çok farklı olduğu için, “o zaman sadece COBOL kullanalım” demek Rust’ın varlık nedenini ortadan kaldırmıyor.
    • IBM belgelerindeki örnek, COBOL’un bellek güvenli olmayan bir dil olduğunu gösteriyor gibi.
      https://www.ibm.com/docs/en/cobol-zos/6.2?topic=statement-ex...
      ALLOCATE, pointer adresi ayarlama, FREE gibi kodlar geçiyor.
    • Shell script de bellek güvenlidir; ama 100 satırı aşan programları onda yazmamamızın bir nedeni var.
    • Tuhaf bir karşılaştırma. Bilgisayarın yanına yaklaşmasına izin verilebilecek bir geliştirici, Rust’ın uygun olduğu yerde COBOL’u seçmez; tersini de yapmaz.

  • Bu tweet garip biçimde hoşuma gidiyor.
    https://x.com/grauhut/status/1000017084435312642
    Çevirisi kabaca şöyle: “Müşteride COBOL buldum. Sorun değil. Mainframe. Özel bir şey yok. Son yorum 1985 tarihliydi. Yazarı annemdi.”