Kod nasıl çalışır

Bilgisayar kodunuzun metnini okumaz; peki ne çalıştırır?

Kaydettiğiniz dosya düz metindir; disk açısından bir not dosyasından farkı yoktur. İşlemci o metni okumaz. İşlemcinin çalıştırdığı şey çok basit sayısal komutlardan oluşur: bu sayıyı bellekten al, şununla topla, sonucu oraya koy ve sıfır çıktıysa şu noktaya atla. Buna makine dili denir ve bugün kimse doğrudan onunla çalışmaz.

Yani metniniz ile işlemci arasında her zaman bir çeviri aşaması vardır. Üç halkası vardır ve sırası hiç değişmez: yazdığınız metin, o metni okuyup denetleyen ve çeviren program, ve sonunda çalışan çevrilmiş biçim. Hiçbir dil bu zincirden kaçamaz. Diller yalnızca iki konuda ayrışır: çeviri ne zaman yapılıyor ve sonucu saklanıyor mu.

Çok çabuk işinize yarayacak bir nokta: çeviri aşaması her şeyden önce söz dizimini denetler, yani metniniz o dilin kurallarına uyuyor mu diye bakar. Uymuyorsa iş tam orada durur ve programınızdan tek satır çalışmaz; hatadan önce yazılmış sağlam bir satır bile. Bu sayfanın dördüncü bölümü bunu iki gerçek dosyayla gösteriyor.

Derlenen ve yorumlanan arasındaki fark nedir?

En sade hali şu: yorumlanan bir dilde metin, dil motoruna olduğu gibi verilir ve yukarıdan aşağı çalışır; derlenen bir dilde metin önce başka bir biçime dönüştürülür ve çalışan şey o biçimdir. Mozilla da tam bu terimlerle anlatır: yorumlanan dillerde kod metin biçiminde alınır ve doğrudan ondan işlenir, derlenen diller ise çalıştırılmadan önce başka bir biçime dönüştürülür.

Şimdi rahatsız edici kısım. Bu ayrım artık temiz bir çizgi değil. Mozilla aynı sayfada, modern JavaScript yorumlayıcılarının çoğunun tam zamanında derleme denen bir teknik kullandığını, betik çalışırken kaynağı daha hızlı bir ikili biçime çevirdiğini ekliyor; yine de JavaScript'i yorumlanan sayıyor, çünkü o derleme önceden değil, çalışma anında oluyor.

Bu yüzden derlenen mi yorumlanan mı sorusu yavaş yavaş faydasını yitiriyor. Daha iyi iki soru var: çeviri ne zaman yapılıyor ve sonucu saklanıyor mu, yoksa her seferinde sıfırdan mı kuruluyor? Bu iki yanıt, bir C programının çalışmadan önce neden ayrı bir derleme adımı olduğunu ve modül içe aktaran bir Python betiğinin ikinci seferde neden biraz daha hızlı açıldığını açıklar.

Python, JavaScript ve PHP bu zincirin neresinde?

Aşağıdaki tablo, önceki bölümdeki iki soruyu dört dile uyguluyor. Üçüncü sütun önemli olan, çünkü diller etiketlerinde değil orada ayrışır.

İlk üç satırı yan yana koyun, bir örüntü çıkar: üçü de çalışma anında çevirir ve yalnızca sonucu nereye koyduklarında ayrışır. Python diske, PHP belleğe, JavaScript hiçbir yere. Dördüncü satır, gerçekten farklı olan durumu görün diye bilerek burada: C'de programı derlemezseniz çalıştırılacak hiçbir şey yoktur.

Hemen kullanabileceğiniz pratik bir sonuç: JavaScript, PHP ve Python'da dosyayı değiştirirsiniz ve etkisini bir sonraki sefer görürsünüz. C'de yeniden derlemeniz gerekir. Biri size dosyayı değiştirdiğini ama hiçbir şeyin değişmediğini söylerse, ilk soru dilinin bu tablonun hangi satırında olduğu, ikinci soru ise beşinci bölümün konusudur.

Neden bazen hiçbir satır çalışmaz, bazen programın yarısı çalışır?

İki küçük dosya oluşturun ve her birini ayrı çalıştırın. İlki bad.py, ikinci satırda kapatılmamış bir parantezle:

print("first line")
print("second line"

Gerçek çıktı şu:

  File "bad.py", line 2
    print("second line"
         ^
SyntaxError: '(' was never closed

İkincisi boom.py; söz dizimi doğru ama imkansız bir şey istiyor:

print("first line")
print(1/0)

Ve çıktısı:

first line
Traceback (most recent call last):
  File "boom.py", line 2, in <module>
    print(1/0)
          ~^~
ZeroDivisionError: division by zero

Farka bakın, çünkü bu tek şey hata ayıklamanızın yarısıdır. İlk dosyada first line sözleri hiç yazdırılmadı; oysa birinci satır tamamen doğruydu ve hatadan önce geliyordu. İkincisinde yazdırıldı ve program yolun ortasında düştü. Sebebi birinci bölümdeki zincir: söz dizimi denetimi, herhangi bir çalıştırmadan önce dosyanın tamamı üzerinde yapılır; bu yüzden ikinci satırdaki kapatılmamış bir parantez birinci satırı da beraberinde götürür. Sıfıra bölme ise ona gerçekten ulaşana kadar keşfedilmez, çünkü o ana kadar bölenin sıfır olduğunu kimse bilmez.

Bu iki durumun adı var: söz dizimi hatası ve çalışma zamanı hatası. Pratik değeri şu: dili bilmeseniz bile ikisini yalnızca çıktıya bakarak ayırt edebilirsiniz. Hata mesajından önce bir şey yazdırıldıysa program çalışmaya başlamıştı ve karşınızda bir çalışma zamanı hatası var; hiçbir şey yazdırılmadıysa büyük ihtimalle hiç çalışmamıştır.

Kaydettiğiniz dosya, çalışan şey değildir

Şimdi zincirin ilginç kısmı. Çevirinin sonucu yalnızca bellekte yaşamaz; çoğu zaman bir dahaki sefere yeniden kurulması gerekmesin diye saklanır. Python bunu gözünüzün önünde yapar. İki dosya oluşturun, tools.py ve onu içe aktaran bir main.py, sonra:

python3 main.py
ls __pycache__/

__pycache__ adlı bir klasör belirir ve içinde tam olarak bir dosya vardır: tools.cpython-312.pyc. main.py için hiçbir şey yazılmamıştır. Python'ın kendi belgeleri her iki yarıyı da açıklar: Python her modülün derlenmiş sürümünü __pycache__ dizininde önbelleğe alır ve doğrudan komut satırından yüklenen modülü her zaman yeniden derler, sonucu saklamaz.

PHP aynı işi tek farkla yapar: sonucu diske koymaz, sunucu belleğinde tutar. Bu katmanın adı opcache ve davranışının, yeni başlayanları çıldırtan tek bir ayarı var: diskteki dosyanın değişip değişmediğini ne sıklıkla denetleyeceği. PHP'nin kendi el kitabı ayarı tam bu sözlerle tarif ediyor: betik zaman damgalarının güncellenme denetimi ne sıklıkla yapılsın, saniye cinsinden. Yani dosyayı kaydetmekle kaydın etki etmesi arasında bir boşluk vardır ve bu boşluk bilinçlidir.

Dolayısıyla o bildik cümlenin, dosyayı değiştirdim ama hiçbir şey olmadı, üç yaygın yanıtı vardır ve üçü de bu zincirin içindedir: ya değiştirdiğiniz dosya çalışan dosya değildir, ya eski bir çevrilmiş kopya hala bellektedir, ya da çıktı daha ileride bir önbellek katmanından gelmektedir ve programınıza hiç ulaşmamıştır. Bu sayfanın altındaki kendi işimizden bölümü, o ayarın kendi sunucumuzdaki değerini veriyor.

Program çalışmadığında önce nereye bakarsınız?

Hata mesajını yukarıdan değil aşağıdan okuyun. Son satır hatanın türünü söyler ve ekrandaki en önemli kelime odur; üstündeki satır ise genelde nerede olduğunu söyler. Dördüncü bölümdeki örnekte son satır ZeroDivisionError: division by zero idi ve üstündeki satır patlayan ifadeyi tam olarak gösteriyordu. Yeni başlayanlar genelde yalnızca dosya yollarının yazdığı en üstten başlar, sonra da hatanın anlaşılmaz olduğunu söyler.

Okuduktan sonra katmanı adlandırın. Yalnızca dört tane var. Söz dizimi: hiçbir şey çalışmadı, mesaj herhangi bir çıktıdan önce geldi. Çalışma zamanı: bir şey yazdırıldı, sonra düştü. Ortam: program sağlam ama ihtiyaç duyduğu bir şey kurulu değil, sürümü farklı ya da bulunamıyor. Mantık: hiç hata yok, program sonuna kadar çalışıyor ve yanlış yanıt veriyor.

Tutumumuz şu ve basit: tek bir karakteri değiştirmeden önce katmanın adını yüksek sesle söyleyin. Yeni başlayanların kaybettiği saatlerin çoğu, sorunun bulunmadığı bir katmanda kodu değiştirmekle geçer; kütüphane hiç kurulmamışken gayet sağlam bir fonksiyonu yeniden yazmak gibi. Dördüncü katman hepsinin en kötüsüdür, çünkü hiç hata vermez; onu yakalamanın tek yolu, çalıştırmadan önce çıktının ne olması gerektiğini tahmin edip sonra çıkanla karşılaştırmaktır.