Grace Hopper'ın derleyicilerin önünü açarak okunabilir kodu savunuşunu, A-0 ve COBOL'un yazılımın nasıl yazıldığı ve bakımının nasıl yapıldığına etkisini öğrenin.

Çoğumuz kodu okunabilir, yeniden kullanılabilir ve görece taşınabilir bekleyerek yazıyoruz. Değişkenlere isim veriyoruz, kütüphaneleri çağırıyoruz ve programımızın hiç görmediğimiz makinelerde çalışacağını varsayıyoruz. Bu beklenti tesadüfen ortaya çıkmadı. İnsanlarla bilgisayarların işi nasıl paylaştığı konusunda büyük bir değişimin sonucu—ve derleyiciler bunun köprüsü.
Erken programcılar bugün düşündüğümüz anlamda “kod yazmıyor”lardı. Bilgisayarları öyle ayrıntılı ve kırılgan bir düzeyde yönetiyorlardı ki her talimat bir makineyi el yapımı gibi şekillendirmek gibiydi. Önemli soru şu:
Programlama nasıl donanıma özgü bir zanaatten zaman içinde ekiplerin sürdürebileceği insan merkezli bir pratiğe dönüştü?
Grace Hopper bu değişimin merkezindeydi çünkü dönemine göre radikal bir fikir savundu: bilgisayar çeviriyi daha çok yapmalı. İnsanları tek bir makineye uyarlanmış, uzun ve hata yapmaya açık diziler yazmaya zorlamak yerine, Hopper daha insan dostu talimatları bilgisayarın çalıştıracağı düşük seviyeli adımlara çevirebilen erken derleyici çalışmalarının önünü açtı.
Onun çalışması “çeviri”nin bir lüks olmadığını kanıtladı. Bu bir verimlilik sıçramasıydı. Niyetinizi daha açık ifade edebilince:
Derleyicilerden önce programlamanın nasıl göründüğünü, bir derleyicinin gerçekte ne yaptığını (jargona girmeden) ve Hopper'ın A-0 çalışması ile COBOL'un yükselişinin yazılımı okunabilir, standartlaştırılmış dillere nasıl ittiğini anlatacağız. Yol boyunca taşınabilirlik, ekip çalışması, uzun vadeli bakım ve kodun makineler kadar insan tarafından anlaşılır olması varsayımı gibi modern gelişmeyi şekillendiren pratik sonuçları göreceksiniz.
Eğer hiç açık hata mesajlarından, taşınabilir koddan veya talimat gibi okunacak şekilde tasarlanmış bir dilden faydalandıysanız, Hopper'ın inşa ettiği dünyada yaşıyorsunuz demektir.
Grace Hopper programlamayı “kolaylaştırmaya” çalışarak başlamadı. Erken bilgisayarların talep ettiği yerden başladı: makinenin sınırlarıyla. Matematikçi olarak yetişmişti, II. Dünya Savaşı sırasında U.S. Navy'e katıldı ve ilk büyük ölçekli elektromekanik bilgisayarlardan biri olan Harvard Mark I üzerinde çalışmak üzere atandı.
Mark I bir hata sonrası yeniden başlatılabilecek bir dizüstü değildi—oda büyüklüğünde, bir ekip tarafından paylaşılan, dikkatle planlanan ve pahalı bir laboratuvar ekipmanı gibi muamele gören bir kaynaktı.
Derleyicilerden önce programlama daha çok bir kontrol panelini kablolamaya benziyordu. Talimatlar donanımın ihtiyaçlarına tam olarak uymalıydı; genellikle sayısal kodlar veya çok düşük seviyeli işlemler şeklindeydi. Makineye toplama, karşılaştırma veya değer taşıma yaptırmak istiyorsanız bunu makinenin kendi sözlüğüyle—adım adım—ifade ediyordunuz.
Bu işler:
Erken bilgisayarlar nadirdi ve “bilgisayar zamanı” bütçelenen bir kalemdi. Programı rastgele on kez çalıştıramazsınız. Ekipler dikkatle hazırlanır, her şeyi iki kez kontrol eder, sonra işi çalıştırmak için sırayı beklerdi. İsraf edilen her dakika çözülmesi gereken asıl problem için harcanmamış olurdu.
Bu baskı Hopper'ın düşüncesini şekillendirdi: insanlar makinenin dilini konuşmaya makineye göre daha fazla zaman harcıyorsa, darboğaz sadece donanım değil—yöntemdir.
Derleyiciler olmadan programcılar bilgisayara onun “yerel” diliyle konuşuyordu.
Makine kodu işlemcinin doğrudan çalıştırdığı 0 ve 1 akışıdır. Her desen “bu iki sayıyı topla”, “bu değeri taşı”, ya da “başka bir adıma atla” gibi bir şey ifade eder. Kesin—ancak insanlar için okumak, yazmak ve ayıklamak acı verici derecede zordur.
Assembly dili makine koduna takma adlar getirir. Ham bitler yerine LOAD, ADD veya JUMP gibi kısa kelimeler ve bellek adresleri yazarsınız. Bir assembler sonra bu kelimeleri o spesifik makine için tam 0 ve 1'lere çevirir.
Assembly saf makine kodundan daha kolaydır, ama yine de insanları donanım gibi düşünmeye zorlar: registerlar, bellek konumları ve işlemlerin kesin sırası.
Erken bilgisayarlar birbirinin yerine geçemezdi. Farklı makinelerin komut setleri, bellek düzenleri ve sayı gösterimleri farklıydı. Bir işlemci için yazılmış bir program başka birinde çoğu zaman çalışamazdı.
Yazılım bir “tarif” olmaktan çok tek bir kilit için özel yapılmış bir anahtara benziyordu.
Programlar düşük seviyeli adımlardan inşa edildiği için, örneğin yeni bir rapor sütunu eklemek, dosya formatını değiştirmek veya bir hesaplamanın yuvarlamasını ayarlamak tüm programı etkileyebilirdi.
Yeni bir özellik ekstra talimat gerektiriyorsa, bellek adreslerini yeniden düzenlemeniz, atlama hedeflerini güncellemeniz ve eski düzeni varsayan her yeri tekrar kontrol etmeniz gerekebilirdi. Bilgisayarın zamanı kıymetliydi ama insan zamanı gerçek darboğazdı ve işin esasıyla çok az ilgisi olan ayrıntılarda harcanıyordu.
Erken bilgisayarlar güçlüydü ama acımasızca literal çalışıyorlardı. Sadece donanımın anladığı küçük operasyon kümesiyle ifade edilmiş talimatları takip edebiliyorlardı. Bu, programlamayı genellikle makineye doğrudan yazmak gibi gösteriyordu.
Bir derleyici iş modelini tersine çevirdi: insanlar "makineyi konuşmak" yerine daha insan dostu bir formda talimat yazabilir ve yazılım çeviriyi üstlenebilirdi. Pratikte, bir derleyici program üreten bir programdır.
Derleme, insanların okuyup yazabildiği kodu bilgisayarın çalıştırabileceği makine talimatlarına dönüştürme sürecidir. Bunu bir tarifi bir mutfak robotunun ne yapması gerektiğine çevirme olarak düşünebilirsiniz.
Yüksek düzeyde bir derleyici genellikle:
Sihir, bilgisayarın aniden "İngilizceyi anlaması" değil. Sihir, derleyicinin sıkıcı, hata yapmaya açık dönüştürme işini hızla ve tutarlı şekilde yapmasıdır.
Derleyiciler ve yorumlayıcılar insan dostu kodu çalıştırmaya yardımcı olduğu içingenellikle karıştırılır.
Ayırmanın basit yolu:
Her iki yaklaşım da dışarıdan benzer görünebilir ("kod yazıyorum ve çalışıyor"), ama iş akışı ve performans ödünleri farklıdır. Hopper'ın hikayesi için kilit nokta, derlemenin "kod yazmayı" donanım ayrıntılarından ziyade niyeti ifade etmeye dönüştürmesiydi.
Grace Hopper'ın A-0 sistemi (genellikle 1952'ye tarihlendirilir) en erken "derleyici benzeri" araçlardan biridir—ancak modern derleyicilerin yaptığı gibi tam bir insan-dostu dili makine koduna çevirmiyordu.
Her talimatı elle yazmak yerine, programcı önceden oluşturulmuş rutinlere bir kimlik ile referans veren bir program yazabilirdi. A-0 sonra:
Programcı hâlâ bilgisayardan "İngilizce-benzeri bir dili" anlamasını istemiyordu. Daha ziyade tekrar eden, hata yapmaya açık bir montaj işini otomatikleştirmesini istiyordu: bilinen yapı taşlarını seçmek ve birleştirmek.
A-0 güçlü bir fikre dayanıyordu: alt programlar. Girdi/çıktı, matematiksel işlemler veya veri taşıma gibi işler için zaten test edilmiş bir rutininiz varsa, her seferinde bunu yeniden yazmamalısınız.
Bu günlük işi iki büyük yönden değiştirdi:
A-0'ın daha derin etkisi yalnızca teknik değildi—kültürelydi. Programlamanın, güvenilir bileşenlerden oluşacak şeyi tanımlamak ve araçların mekanik işi yapmasına izin vermek olabileceğini önerdi.
Bu tutum—kütüphaneleri yeniden kullanmak, rutinleri standardize etmek ve çeviriyi otomatikleştirmek—derleyicilerin, standart dillerin ve modern yazılım geliştirme uygulamalarının temelini oluşturdu.
Erken programcılar sadece makinelerle değil, birbirlerinin "gerçek" programlamanın nasıl olması gerektiğine dair varsayımlarıyla da mücadele ettiler. Birçok mühendise göre ciddi iş donanımı andıran, sıkı, sayısal ve açık talimatlardı. Dilde düz İngilizceye benzeyen bir şey şüpheli sayılıyordu.
Grace Hopper, bilgisayarların insanlara hizmet etmesi gerektiğini savundu. İşe yakın ifadeler kullanacak daha okunabilir notasyon için yaptığı itiraz, bir çekirdek inanca meydan okuyordu: verimliliğin insanları makine biçiminde düşünmeye zorlamasını gerektirdiği inancı.
Şüpheciler, İngilizce-benzeri komutların belirsiz olacağını, önemli detayları saklayacağını ve gevşek düşünmeyi teşvik edeceğini düşündüler. Hopper'ın karşı argümanı pratikti: programlamada zamanın çoğu talimat yazmaktan değil—sonradan onları anlamaktan harcanır.
Okunabilir kod programları “kolay” yapmakla ilgili değildir; onları hayatta tutmakla ilgilidir. Kod niyeti iletiyorsa ekipler değişiklikleri daha hızlı gözden geçirebilir, yeni kişileri daha az hata ile işe alıştırabilir ve her kararın arkasındaki sebebi tersine mühendislik yapmadan teşhis edebilir.
Bu yıllar boyunca daha da önem kazanır. Yazılım iş rolleri, departmanlar ve bazen onu inşa eden ilk amaçların ömrünü aşar. İnsan-dostu yapı ve isimlendirme değişiklik maliyetini azaltır; bu maliyet çoğu zaman yazılımda en büyük maliyettir.
Hopper'ın yaklaşımının sınırları vardı. Erken derleyiciler ve araçlar olgun değildi ve daha yüksek seviyeli kod elle ayarlanmış assembly'den daha yavaş veya daha büyük programlar üretebilirdi. Hata ayıklama dolaylı gelebilirdi: hatalar derlenmiş çıktıda kaynak metinde değilmiş gibi görünüyordu.
Yine de uzun vadeli kazanç açıktı: okunabilir kaynak kod, daha fazla kişiyle daha büyük sistemler kurmayı ve ilk sürüm gönderildikten sonra bile bu sistemleri çalışır tutmayı mümkün kıldı.
COBOL (Common Business-Oriented Language), programların işletmeleri yöneten insanlar tarafından okunabilir olmasını sağlama amacına göre inşa edildi, sadece makineyi kablolarla bağlayan mühendisler için değil. Grace Hopper bu fikri güçlü bir şekilde savundu—kod yıllarca yaşayacaksa, ekipler arasında dolaşacaksa ve personel değişikliklerine dayanacaksa okunabilir olmalıydı.
COBOL, bordro, envanter, faturalama gibi iş verisi işleme için tasarlandı: burada verinin "şekli" matematik kadar önemlidir. Bu yüzden COBOL kayıtlar, alanlar ve bir programın ne yaptığını açıkça betimleme üzerinde yoğunlaştı.
Büyük hedeflerden biri açıklıktı. COBOL, birinin programı gözden geçirirken niyeti takip edebilmesi için İngilizce-benzeri bir yapıya yaslandı. Bu programlamayı “kolay” yapmakla ilgili değildi—iş sistemlerinde hataların maliyeti büyük olabileceği için kodun okunaklı ve sürdürülebilir olmasıyla ilgiliydi.
COBOL'un gerçek atılımı sadece sözdizimi değildi. Standartlaştırmaya doğru bir adımdı.
Tek bir üreticinin donanımına veya bir şirketin özel diline bağlı olmak yerine COBOL komiteler ve resmi spesifikasyonlar tarafından şekillendirildi. Bu süreç yavaş ve politik olabilirdi ama birçok satıcının uygulayabileceği ortak bir hedef yarattı.
Pratikte, bu kuruluşların COBOL'a yatırım yapmasını daha güvenli kıldı: eğitim materyalleri daha uzun ömürlü oldu, işe alım kolaylaştı ve kod donanım değişikliğinde hayatta kalma şansını artırdı.
Standartlaşma ayrıca beklentileri değiştirdi. Diller artık sadece makineyle birlikte gelen araçlar değildi; insanlarının talimat yazma biçimi ve derleyicilerin bunları nasıl çevireceğine dair kamuya açık anlaşmalar—kurallar hâline geldi.
COBOL'un güçlü yönleri kolayca açıklanır: açıkça belirtir, veri yapıları merkezi bir rol oynar ve uzun ömürlü iş sistemlerini destekler. Bu uzun ömür tesadüf değil; açıklık ve istikrarı tercih eden tasarım seçimlerinin sonucudur.
Eleştiriler de gerçek. COBOL ayrıntılı ve modern dillere kıyasla katı okunabilirlik sunabilir. Ancak bu ayrıntı genellikle amaçtı: kod işini gösterir, bu da denetim, bakım ve devir teslimlerde yardımcı olur.
COBOL, programlama dillerinin kişisel kestirmeler olmaktan çıkıp standart-odaklı altyapı—paylaşılan, öğretilen ve kalıcı olacak şekilde—davranmaya başladığı bir dönüm noktasını işaret eder.
Erken programlar genellikle belirli bir makineye bağlıydı. Bilgisayarları değiştirince sadece dosyaları taşımak yetmezdi—genellikle programı yeniden yazmanız gerekirdi çünkü talimatlar ve kurallar farklıydı. Bu yazılımları kırılgan ve pahalı kılıyor, yeni donanımın benimsenmesini yavaşlatıyordu.
Derleyiciler güçlü bir ayrımı getirdi: programınızı daha yüksek seviyeli bir dilde yazıyorsunuz ve derleyici bunu hedef bilgisayarın yerel talimatlarına çeviriyor.
Buna taşınabilirlik denir: aynı kaynak kod farklı makineler için derlenebilir—yeter ki her hedef için uygun bir derleyici olsun ve makineye özgü varsayımlardan kaçınılsın. Bir bordro sistemini her yeni bilgisayar için baştan yazmak yerine kuruluşlar mantığı koruyup sadece yeniden derleyebildi.
Bu değişim donanım iyileştirmenin ekonomisini değiştirdi. Üreticiler daha hızlı veya daha yetenekli makineler çıkardığında müşteriler yılların yazılım yatırımını çöpe atmak zorunda kalmadı.
Derleyiciler, kararlı iş ihtiyaçları ile hızla değişen teknoloji arasında bir tür “adaptör katmanı” oldu. İş uygulamasının niyetini koruyarak işlemcileri, bellek modellerini ve çevre birimlerini güncellemek mümkün oldu. Bazı değişiklikler hâlâ güncelleme gerektirdi—özellikle giriş/çıkış tarafında—ama temel fikir artık belirli bir opcode setine bağlı değildi.
Taşınabilirlik, dil standartlaştırıldıkça dramatik şekilde iyileşir. Standart kurallar, bir derleyici için yazılan kodun başka bir derleyicide derlenme olasılığını artırır, satıcı kilitlenmesini azaltır ve yazılımların paylaşılmasını kolaylaştırır.
Bu miras bugün her yerde:
Grace Hopper'ın insan-dostu, geniş kullanılabilir programlama yönündeki itişi yalnızca rahatlıkla ilgili değildi. Yazılımı donanıma özgü talimatlardan değişen donanım nesillerine dayanabilecek taşınabilir bir varlığa dönüştürmeye yardımcı oldu.
Derleyiciler sadece programlamayı hızlandırmadı—yazılım ekiplerinin nasıl organize edildiğini yeniden şekillendirdi. Kod daha yüksek düzeyli terimlerle yazılabildiğinde (iş kurallarına daha yakın), farklı insanlar daha etkili katkıda bulunabildi.
Erken projeler genellikle analistler (sistemin ne yapması gerektiğini tanımlayanlar), programcılar (bunu koda çevirenler) ve operatörler (işleri çalıştıran ve makine zamanını yönetenler) gibi rollere bölünmüştü. Derleyicilerle analistler iş akışlarını daha yapılandırılmış ve tutarlı bir şekilde tanımlayabilirken, programcılar ayrıntılı "elle montaj" işine daha az zaman harcayıp iş mantığını tasarlamaya daha fazla zaman ayırdı.
Sonuç daha temiz bir devir teslim hattı oldu: gereksinimler → okunabilir kaynak kod → derlenmiş program. Bu, büyük projelerin tek bir uzmana bağımlılığını azalttı.
Yazılım artık haftalar değil yıllar yaşıyordu—bakım büyük bir maliyet haline geldi. Düzeltmeler, güncellemeler ve küçük politika değişiklikleri birikti. Okunabilir kaynak kod bu maliyeti sürdürülebilir kıldı: yeni biri niyeti anlamak için binlerce düşük seviye adımı tersine mühendislik yapmak zorunda kalmazdı.
Derleyiciler bunu destekleyerek isimlendirilmiş değişkenler, yeniden kullanılabilir rutinler ve daha net kontrol akışı gibi yapıları teşvik etti. Kod kendini anlattığında bakım arkeolojisine dönüşmez.
Daha net soyutlamalar test ve hata ayıklamayı da geliştirdi. Tek bir yanlış makine talimatını aramak yerine ekipler özellikler üzerine düşünebilir ("iade hesaplaması yanlış") ve sorunu bir modül veya fonksiyona izole edebilir.
Derleyiciler ilk zamanlarda şifreli hatalar üretiyor olsa da, yine de değerli bir disiplini teşvik ettiler: kaynak kodu düzenli tutun, davranışı adım adım doğrulayın ve değişiklikleri anlamın ifadesinin olduğu yerde yapın—donanımın bitsel düzeninde değil.
Derleyiciler insan-dostu talimatları makine-dostu olanlara çevirir. Bu kayma yazılımı daha hızlı yazılabilir ve paylaşılabilir yaptı—ama aynı zamanda bugün hâlâ konuşmalarda karşımıza çıkan birkaç miti yarattı.
Derleyici esasen kodunuzun dil kurallarına uyup uymadığını kontrol eder ve bunu bilgisayarın çalıştırabileceği bir şeye çevirir. Mantığınız yanlışsa, derleyici genellikle yanlış işi yapan geçerli bir program üretir.
Örneğin, bir bordro hesaplaması derlenebilir ama yanlış formül, eksik uç durum veya gözden kaçan bir saat dilimi nedeniyle hâlâ yanlış ödeme yapabilir.
Yüksek seviye diller belirli hata sınıflarını azaltır—örneğin CPU talimatlarını karıştırma veya bellek yönetimini manuel yapma gibi—ama hataları ortadan kaldırmaz. Yine de şunları yapabilirsiniz:
Okunabilir kod büyük bir kazançtır, ancak okunabilirlik doğrulukla aynı şey değildir.
Kod güzel isimlendirilmiş ve düzenli olabilir ama yine de güvensiz (örneğin kullanıcı girdisine güvenmek), yavaş (örneğin bir döngü içinde tekrarlanan veritabanı çağrıları) veya kırılgan olabilir (örneğin gizli bağımlılıklar).
Daha iyi çerçeveleme şu olmalı: okunabilir kod sorunları bulmayı ve düzeltmeyi kolaylaştırır. Sorunların var olmadığını garanti etmez.
Derleyiciler araçtır, bebek bekçisi değil. Güvenilirlik yine insanların çalışma biçiminden gelir:
Grace Hopper okunabilir kod savundu. En iyi uygulama bunu disiplinli yöntemlerle eşleştirip “kolay”ın "umursamaz" olmamasını sağlamaktır.
Hopper'ın temelde yaptığı bahis basitti: işi insanlar anlayacağı terimlerle tanımlayabilirsek, bilgisayar çeviriyi yapsın. Bu fikir neredeyse her modern programlama deneyiminin içinde—Python veya JavaScript yazmaktan endüstriyel derleyici araç zincirleriyle uygulama göndermeye kadar—yerleşti.
Bugün bir “derleyici” nadiren tek bir programdır. Bir boru hattıdır: kodunuzu ayrıştırır, denetler, dönüştürür, optimize eder ve çalıştırılabilir bir şey üretir (makine kodu, bytecode veya optimize edilmiş bir paket). Go, Rust, Swift veya C# yazıyor olun, Hopper'ın öne sürdüğü sözüntüden faydalanıyorsunuz: insan sıkıcılığını azalt, niyeti açık tut ve makinelerin tekrar eden dönüşüm işini yapmasına izin ver.
Bu aynı zamanda modern geliştirmenin hâlâ daha üst düzey arayüzlere doğru ilerlemesinin nedenlerinden biridir; yine de gerçek, dağıtılabilir sistemler üretiyorlar. Örneğin platformlarda Koder.ai'da, sohbet arayüzünde ne istediğinizi tanımlarsınız ve ajan tabanlı bir iş akışı web, backend veya mobil bir uygulama üretecek ve rafine edecek şekilde yardımcı olurken yine dışa aktarılabilir kaynak kod üretir. Çok Hopper-benzeri bir şekilde amaç aynı: sıkıcı çeviri işini niyeti netleştirmeye, gözden geçirilebilir çıktıya ve daha hızlı yinelemeye kaydırmak.
Modern derleyiciler sadece çeviri yapmakla kalmaz—öğretir ve korur.
Hata mesajı tam satırı işaret edip bir düzeltme önerdiğinde, bu programlamayı insan etkinliği olarak görmenin bir mirasıdır.
Optimizasyon sessiz bir kazanımdır: derleyiciler kodu daha hızlı veya daha küçük hâle getirebilir, geliştiricileri her talimatı elle ayarlamaya zorlamadan.
Statik analiz (çoğu zaman derleyicilerle entegre ya da eşlik eden araçlar) müşteriyle buluşmadan önce tür uyuşmazlıklarını, ulaşılamayan kodu veya olası null hatalarını erkenden yakalar.
Bunların hepsi daha hızlı geliştirme döngülerine dönüşür: daha net kod yazarsınız, araçlar sorunları daha erken işaretler ve derlemeler farklı ortamlarda güvenilir çıktılar üretir. "Derleyici" kelimesini hiç söylemeseniz bile bu etkileri, IDE'nizin bir hatayı çizmesi, CI derlemenizin net bir teşhis vermesi veya bir araç zinciri güncellemesinin yayınınızı hızlandırması halinde hissedersiniz.
Bu, Hopper'ın vizyonunun günlük pratiğe yansımasıdır.
Grace Hopper'ın derleyici çalışması sadece bilgisayarları programlamayı kolaylaştırmadı—yazılımın ne olabileceğini değiştirdi. Derleyicilerden önce her gelişme titiz, düşük seviyeli çaba gerektiriyordu. Derleyicilerden sonra insan zamanının daha büyük bir kısmı fikirler, kurallar ve davranış üzerine gidebildi; adım adım çeviriye değil.
İki kayma fark yarattı:
Bu faydalar birbirini güçlendirdi. Kod okunaklıysa, geliştirmesi daha kolaydır. Çeviri otomatikleşince ekipler refaktör yapıp yazılımı ihtiyaç değiştikçe uyarlayabilecek duruma geldi. Bu yüzden derleyiciler tek seferlik bir hile değildi—modern dillerin, araçların ve işbirliğinin temeli oldular.
Derleyici "programlamayı kolaylaştırmak"tan çok programlamayı ölçeklendirmekle ilgilidir. Bir kişinin niyetinin daha uzağa gitmesini sağlar: daha büyük projelere, daha geniş ekiplere, daha uzun zaman dilimlerine ve daha çok makineye.
Yarın ekibinize yeni biri katılsa, onun kodunuzu daha hızlı anlaması için ne küçük bir değişiklik yapabilirsiniz?—daha iyi isimler, daha net yapı veya “neden”i açıklayan kısa bir yorum?
Grace Hopper, erken derleyici benzeri sistemlerin öncülüğünü yaparak programlamayı donanıma özgü talimatlardan insan merkezli kaynak koda dönüştürme yönünde bir değişim başlattı. Onun çalışması, araçların niyeti makine adımlarına çevirebileceğini gösterdi; bu da yazılımın daha hızlı yazılmasını, daha kolay paylaşılmasını ve daha sürdürülebilir olmasını sağladı.
Derleyiciler yokken programlama çoğunlukla makine kodu veya belirli bir bilgisayara özgü çok düşük seviyeli talimatları yazmak demekti. Bu iş elle yapılıyor, kırılgandı ve değişime yavaştı; küçük bir özellik değişikliği bile adreslerde, atlama hedeflerinde ve bellek düzeninde geniş çaplı yeniden yazmalar gerektirebiliyordu.
Makine kodu, CPU'nun doğrudan çalıştırdığı ham bit dizileridir (0 ve 1'ler). Assembly, LOAD veya ADD gibi okunabilir mnemonikler kullanır, ancak yine de belirli bir makinenin komut setine bağlıdır ve sizin kaydetme, adresleme ve işlem sırasını düşünmenizi zorunlu kılar.
Bir derleyici, insanlar tarafından yazılan kaynak kodu bilgisayarın çalıştırabileceği daha düşük seviyeli bir forma (genellikle yürütülebilir bir dosya) çevirir. Ayrıca dil kurallarına karşı kodu kontrol eder ve çıktıyı optimize edebilir; böylece insanlar tekrar eden, hata yapmaya açık çeviri işlerini elle yapmak zorunda kalmazlar.
Genel fark şudur:
Günümüzde birçok sistem her iki yaklaşımı harmanlar, ama iş akışı ve performans açısından bu fark önemlidir.
A-0, programcıların önceden yazılmış rutinlere bir tanımlayıcı ile başvurabildiği bir sistemdi. A-0, bu rutinleri bir katalogda bulup ilgili makine kodu bloklarını çekiyor ve bunları bir bağlanmış yürütülebilir program halinde birleştiriyordu (bugünkü anlamıyla linking gibi). Henüz İngilizce-benzeri bir dili derlemiyordu ama otomasyon ve yeniden kullanım fikrinin işe yaradığını göstermişti.
Alt programları yeniden kullanmak, aynı mantığı sürekli yeniden yazmak yerine denenmiş parçalar üzerine inşa etmeyi sağlar. Bu günlük çalışmayı şu şekilde değiştirir:
COBOL, iş yazılımlarını okunaklı ve zaman içinde kararlı hâle getirmeyi amaçladı; kayıtlar, alanlar ve açık yapılar üzerine vurgu yaptı. Daha da önemlisi standartlaşma: birçok satıcının uygulayabileceği paylaşılan bir spesifikasyon, vendor kilitlenmesini azalttı ve kodun ile becerilerin makineler arasında taşınmasını kolaylaştırdı.
Taşınabilirlik, aynı kaynak kodun farklı makineler için derlenebilmesidir—her hedef için uygun bir derleyici olduğu ve makineye özgü varsayımlardan kaçınıldığı sürece. Bu sayede kuruluşlar donanımı yükseltirken yılların yazılım yatırımlarını çöpe atmak zorunda kalmadı; mantığı koruyup yeniden derlemek yeterli oldu.
Derleyiciler ve yüksek seviyeli diller bazı hata türlerini azaltır ama kusursuzluk sağlamaz. Gerçek hataları azaltmak için pratik yollar şunlardır: