Bellek sızıntısı gerçekten nedir?

Bellek sızıntısı, artık işe yaramayan bir bellek bölgesinin serbest bırakılamaması durumudur. Buradaki kritik ayrım, belleğin yalnızca kullanılıyor görünmesi ile gerçekten gerekli olması arasındadır. Bir nesneye hâlâ erişilebiliyorsa çöp toplayıcı onu canlı kabul eder; nesnenin uygulama açısından hiçbir anlam taşımaması bu kararı değiştirmez.

Bir sürecin yaklaşık bellek davranışını şöyle düşünebiliriz:

Burada $M_0$ başlangıç belleği, $A(t)$ ayrılan toplam alan, $F(t)$ ise geri verilen alandır. İş yükü sabitlenmesine rağmen $A(t)-F(t)$ sürekli büyüyorsa ortada yalnızca yoğun kullanım değil, muhtemel bir sızıntı vardır.

Manuel yönetim: Unutma sorumluluğu geliştiricide

C ve C++ gibi dillerde bellek ayırmak ile onu serbest bırakmak geliştiricinin sorumluluğundadır. Aşağıdaki fonksiyon, her çağrıda yeni bir alan oluşturur ancak bu alanı geri vermez:

#include <stdlib.h>

void rapor_uret(void) {
    int *veriler = malloc(1000 * sizeof(int));
    if (veriler == NULL) return;

    veriler[0] = 42;
    // İşlem bitti, fakat free(veriler) çağrılmadı.
}

Fonksiyon sona erdiğinde veriler işaretçisi kaybolur. Ayrılan bölgeye artık erişilemez, dolayısıyla sonradan free çağırmak da mümkün değildir. Çözüm, sahiplik süresini açıkça belirlemektir:

void rapor_uret(void) {
    int *veriler = malloc(1000 * sizeof(int));
    if (veriler == NULL) return;

    veriler[0] = 42;
    // Verilerle yapılan işlemler burada tamamlanır.

    free(veriler);
    veriler = NULL;
}

free, kaynağı sisteme iade eder. İşaretçiyi NULL yapmak ise yanlışlıkla aynı alanı yeniden kullanma riskini azaltır.

Çöp toplayıcı her şeyi çözer mi?

JavaScript, Java ve C# gibi dillerde garbage collector erişilemeyen nesneleri otomatik olarak temizler. Ancak otomasyon, psikolojik bağları koparamaz; gereksiz bir referans korunuyorsa nesne hâlâ erişilebilir sayılır.

const gecmisMesajlar = [];

function mesajiIsle(mesaj) {
  const analiz = {
    hamVeri: mesaj,
    zaman: Date.now(),
    sonuc: mesaj.toUpperCase()
  };

  gecmisMesajlar.push(analiz);
}

gecmisMesajlar sınırsız büyüdüğü için her analiz bellekte kalır. Burada sızıntı, unutulmuş bir free çağrısından değil, tasarımsal olarak bitmeyen saklama davranışından doğar. Sınırlı bir önbellek daha sağlıklıdır:

const SINIR = 100;

gecmisMesajlar.push(analiz);
if (gecmisMesajlar.length > SINIR) {
  gecmisMesajlar.shift();
}

Kodun terapi seansı

Sızıntıları bulmak için Chrome DevTools Heap Snapshot, Valgrind, AddressSanitizer veya VisualVM gibi araçlar kullanılabilir. Tek bir ölçüme bakmak yerine aynı senaryoyu defalarca çalıştırıp bellek eğrisini izlemek gerekir. İşlem bittikten sonra bellek başlangıç seviyesine yaklaşmıyorsa nesnelerin referans zincirleri incelenmelidir.

Sonuçta iyi bellek yönetimi, yalnızca alan boşaltmak değildir; bir kaynağın kim tarafından, ne kadar süreyle ve hangi koşulda tutulacağını bilmektir. İnsan geçmişiyle yüzleşerek, program ise referanslarını keserek hafifler. Bazen en etkili optimizasyon, koda nazikçe şunu söylemektir: Artık bunu bırakabilirsin.

``

Reddedilmek neden öğrenmenin parçasıdır?

Derleyici, kaynak kodu makinenin çalıştırabileceği bir biçime dönüştürmeden önce sözdizimi ve tür kuralları gibi koşulları denetler. Bir koşul sağlanmadığında hata üretir. Bu süreç pedagojik açıdan bir geri bildirim döngüsü oluşturur:

1. Öğrenci bir çözüm tahmini geliştirir.
2. Tahmini kod biçiminde ifade eder.
3. Derleyici bu ifadeyi sınar.
4. Hata mesajı, tahmin ile dilin kuralları arasındaki farkı gösterir.
5. Öğrenci zihinsel modelini günceller.

Bunu basitçe şöyle gösterebiliriz:

Öğrenme açısından önemli olan hata sayısını sıfırlamak değil, her denemeden elde edilen bilgiyi artırmaktır. Kabaca bir öğrenme verimi tanımlarsak:

Aynı değişikliği düşünmeden on kez yapmak düşük; hata mesajını okuyup varsayımı sınamak ise yüksek verimlidir.

Bütün hatalar aynı değildir

İlk üç grupta derleyici doğrudan yardımcı olabilir. Mantık hatalarında ise program geçerli olduğu hâlde yanlış sonuç üretir. Yani “derlendi” demek, “doğru çalışıyor” demek değildir.

Bir hata mesajını laboratuvar notuna çevirmek

Aşağıdaki C++ kodunda bilinçli bir tür uyuşmazlığı vardır:

#include <iostream>
#include <string>

int main() {
    std::string yas = "18";
    int gelecekYas = yas + 1;
    std::cout << gelecekYas;
}

Derleyici, std::string ile int değerlerinin bu şekilde toplanamayacağını söyler. Mesaj ilk bakışta uzun ve ürkütücü olabilir; ancak temel soru basittir: Toplama işleminin iki tarafındaki türler nedir? Metni önce sayıya dönüştürerek sorun çözülür:

int gelecekYas = std::stoi(yas) + 1;

Burada yalnızca bir satır düzeltilmedi. Öğrenci, metin olarak saklanan "18" ile sayısal 18 arasındaki farkı keşfetti. İyi hata analizi, yamadan çok kavram üretir.

Pedagojik olarak daha iyi hata alışkanlıkları

Hata mesajını görür görmez kodu rastgele değiştirmek yerine şu yöntem uygulanabilir:

• Önce mesajdaki ilk hatayı okuyun; sonraki hatalar onun zincirleme sonucu olabilir.
• Dosya ve satır numarasını bulun, fakat problemin bir önceki satırdan kaynaklanabileceğini unutmayın.
• “Derleyici ne bekliyordu, ne buldu?” sorusunu yazılı olarak cevaplayın.
• Aynı hatayı küçük bir örnekte yeniden üretin.
• Çözümden sonra hangi kuralı öğrendiğinizi tek cümleyle kaydedin.

Derleyicinin gerçek sabrı

Derleyici aslında sonsuz sabırlıdır: Aynı programı yüzüncü kez de aynı tarafsızlıkla inceler. Sabrı tükenen genellikle öğrencidir. Bu yüzden amaç, kaç kez reddedildiğimizi saymak değil, her ret ile sorumuzu daha kesin hâle getirmektir. Programlama ustalığı hatasız kod yazmak değil; hata ile karşılaşıldığında paniği yönteme, mesajı bilgiye ve reddedilmeyi yeni bir deneye dönüştürebilmektir.

``

Modül Nedir?

Modül, belirli bir sorumluluğu yerine getiren ve kendi kapsamına sahip JavaScript dosyasıdır. Örneğin kullanıcı işlemleri user.js, matematik yardımcıları math.js, API iletişimi ise api.js içerisinde tutulabilir. Her dosya yalnızca dışarı açmak istediği değerleri export eder; başka dosyalar da bu değerleri import ile kullanır.

Bu yaklaşımın temelinde kapsülleme bulunur. Bir modülün içindeki değişkenler varsayılan olarak diğer modüllerin global alanına sızmaz. Böylece iki farklı dosyada result adında değişken bulunması sorun yaratmaz.

Kod karmaşıklığını kabaca şu şekilde düşünebiliriz: Dosya sayısı $n$ ve her dosyanın ortalama sorumluluk sayısı $s$ olsun. Tek dosyalı yapıda zihinsel yük yaklaşık $n \times s$ iken iyi ayrıştırılmış modüllerde geliştirici çoğunlukla yalnızca ilgili modülün $s$ sorumluluğuna odaklanır. Elbette bu matematiksel bir performans ölçümü değil, modülerliğin bilişsel faydasını anlatan basit bir modeldir.

Named Export ve Default Export

ES Modules iki temel dışa aktarma yöntemi sunar:

Named export kullanan bir matematik modülü oluşturalım:

// math.js
export const PI = 3.14159;

export function circleArea(radius) {
  return PI * radius ** 2;
}

function validateRadius(radius) {
  return radius >= 0;
}

Burada PI ve circleArea dışarı açılmıştır. validateRadius ise modülün özel uygulama detayı olarak kalır. İhtiyacımız olan değerleri başka bir dosyada seçerek alabiliriz:

// app.js
import { circleArea, PI as circlePI } from "./math.js";

console.log(circleArea(5));
console.log(circlePI);

as anahtar kelimesi, içe aktarılan değerin yerel adını değiştirir. Böylece isim çakışmaları kontrollü biçimde çözülür.

Bir modül tek bir ana sınıf veya fonksiyon sunuyorsa default export tercih edilebilir:

// UserService.js
export default class UserService {
  async getUser(id) {
    const response = await fetch(`/api/users/${id}`);
    return response.json();
  }
}

Bu sınıf import UserService from "./UserService.js"; şeklinde alınabilir. Süslü parantez kullanılmaması, default import için önemli bir ayrıntıdır.

Tarayıcıda ve Node.js’te Kullanım

Tarayıcıya bir dosyanın modül olduğunu söylemek için type="module" eklenir:

<script type="module" src="./app.js"></script>

Modül betikleri otomatik olarak strict mode ile çalışır ve varsayılan olarak ertelenir. Node.js tarafında ise package.json dosyasına "type": "module" eklenebilir. Dosya yollarında uzantı kullanmak, ortamlar arası davranışı daha öngörülebilir hâle getirir.

Dinamik Import ve Performans

Her modülü başlangıçta yüklemek zorunda değiliz. import() fonksiyonu bir Promise döndürerek kodun ihtiyaç anında indirilmesini sağlar:

button.addEventListener("click", async () => {
  const { openEditor } = await import("./editor.js");
  openEditor();
});

Bu yöntem özellikle yönetim paneli, grafik editörü veya raporlama ekranı gibi ağır özelliklerde kullanışlıdır. Paketleyiciler ayrıca kullanılmayan named export’ları tree shaking ile üretim paketinden çıkarabilir.

Sağlıklı Bir Modül Yapısı İçin İpuçları

Modülleri dosya boyutuna göre değil, sorumluluğa göre ayırın. Dairesel bağımlılıklardan kaçının; a.js, b.js dosyasını, b.js de tekrar a.js dosyasını içe aktarıyorsa mimariyi gözden geçirin. Ortak davranışları bağımsız bir yardımcı modüle taşımak genellikle çözüm olur.

Sonuç olarak ES Modules yalnızca dosya bölme yöntemi değildir. Açık bağımlılıklar, izole kapsam, yeniden kullanılabilirlik ve daha kolay test edilebilirlik sunan bir tasarım aracıdır. İyi organize edilmiş modüller sayesinde proje büyürken kod tabanı korkutucu bir labirente değil, tabelaları düzgün yerleştirilmiş bir şehre dönüşür.

``

Saf fonksiyon: Karması kolay hesaplama

Saf fonksiyon, aynı girdiye her zaman aynı çıktıyı verir ve fonksiyonun dışındaki dünyayı değiştirmez. Matematiksel olarak bunu şöyle düşünebiliriz:

Eğer $x$ değişmiyorsa $y$ de değişmez. Fonksiyon; dosyaya yazmaz, global değişken güncellemez veya gizlice ağ isteği göndermez. Böylece sonucunu anlamak için evrenin bütün geçmişini bilmemiz gerekmez.

const indirimliFiyat = (fiyat, oran) => fiyat * (1 - oran);

console.log(indirimliFiyat(1000, 0.20)); // Her zaman 800

Bu fonksiyon yalnızca parametrelerine bağlıdır. Test etmek için veritabanı, sahte sunucu ya da dolunay gerekmez. Budist düşüncedeki eylem-sonuç ilişkisine benzetirsek, girdiler koşulları; dönüş değeri ise bu koşullardan doğan sonucu temsil eder.

Buna karşılık aşağıdaki fonksiyon dış duruma bağımlıdır:

let vergiOrani = 0.20;

function toplamFiyat(fiyat) {
  console.log("Fiyat hesaplandı"); // Gözlemlenebilir yan etki
  return fiyat * (1 + vergiOrani);
}

Sonucu anlamak için vergiOrani değişkeninin o andaki değerini bilmeliyiz. Üstelik konsola yazmak da hesaplamanın dışında bir etki üretir. Yan etki mutlaka kötü değildir; programların kullanıcıya ulaşması için ekrana yazması, veri kaydetmesi ve ağla konuşması gerekir. Önemli olan yan etkileri tanımak, sınırlamak ve yönetmektir.

Değişmezlik: Bırakmak mı, kopyalamak mı?

Değişmezlik, bir veri oluşturulduktan sonra onu yerinde değiştirmemektir. Güncelleme gerektiğinde eski değeri bozmak yerine yeni bir değer üretiriz. Bu yaklaşım, “hiçbir şey değişmez” demez. Tam tersine değişimin sürekli olduğunu kabul eder; fakat geçmiş durumun üzerine kontrolsüzce yazmaz.

const sepet = Object.freeze([
  { ad: "Çay", adet: 1 }
]);

const yeniSepet = sepet.map(urun =>
  urun.ad === "Çay" ? { ...urun, adet: urun.adet + 1 } : urun
);

Burada sepet korunur, yeniSepet ise değişimi temsil eder. Böylece zaman içindeki durumları karşılaştırmak, hatayı geri almak ve eşzamanlı işlemleri güvenle yürütmek kolaylaşır.

Bağımlı oluş ve fonksiyon bileşimi

Budist felsefedeki bağımlı oluş düşüncesi, olayların tek başına değil koşullarla ortaya çıktığını vurgular. Fonksiyonel programlamada da büyük bir sonucu küçük dönüşümlerin bileşimi olarak ifade edebiliriz:

const temizle = metin => metin.trim().toLowerCase();
const selamla = ad => `Merhaba, ${ad}!`;
const mesajOlustur = ad => selamla(temizle(ad));

Her adım açık, bağımsız ve sınanabilirdir. Karmaşık davranış, gizli mutasyonlardan değil küçük fonksiyonların düzenli ilişkisinden doğar.

Yan etkisiz hayat mümkün mü?

Tamamen yan etkisiz bir program, kullanıcıdan veri alamaz ve sonuç gösteremez; tamamen etkisiz bir hayat da pek hayat sayılmazdı. Fonksiyonel yaklaşımın hedefi dünyadan kaçmak değil, dünya ile temas edilen sınırları görünür kılmaktır. Hesaplamaları saf merkezde tutup ağ, dosya ve arayüz işlemlerini dış katmanlara taşıyabiliriz.

Sonuçta iyi kod da dengeli bir zihin gibi davranır: Neye bağlı olduğunu bilir, geçmişi gizlice değiştirmez ve ürettiği etkinin sorumluluğunu taşır. Nirvana garanti değil; fakat daha öngörülebilir testler ve daha huzurlu hata ayıklama oldukça gerçekçidir.

``

Dün de “gelecek” bugünkü kadar parlaktı

1950’lerde FORTRAN, makine kodunun zahmetini ortadan kaldırarak bilimsel programlamayı dönüştürdü. 1960’larda COBOL, iş dünyasının ortak dili olma iddiasıyla yükseldi. 1980’lerde nesne yönelimli programlama, karmaşıklığı sınıflar ve nesnelerle kontrol edecekti. 1990’larda Java’nın “bir kez yaz, her yerde çalıştır” sloganı platform bağımsızlığını vaat etti. 2010’larda Go sadeliği, Rust ise bellek güvenliğini merkeze aldı.

Bu dillerin hiçbiri başarısız değildir. Hatta bazıları olağanüstü başarılıdır. Yanlış olan, belirli bir dönemin baskın problemini çözmenin bütün gelecek problemlerini çözmek anlamına geldiğini düşünmektir.

Neden tek bir dil yetmiyor?

Programlama dili tasarımı bir optimizasyon problemidir. Bir dilin sadelik, performans, güvenlik, taşınabilirlik ve ifade gücü gibi hedefleri aynı anda en üst düzeye çıkarması beklenir. Ancak pratikte bu hedefler arasında ödünleşim vardır. Bunu kabaca şöyle gösterebiliriz:

Burada $S$ sadeliği, $P$ performansı, $G$ güvenliği, $T$ taşınabilirliği, $C$ ise öğrenme ve işletme maliyetini temsil eder. $w$ katsayıları projeye göre değişir. Bir oyun motorunda performansın ağırlığı yüksekken finans uygulamasında güvenlik, küçük bir otomasyon betiğinde ise geliştirme hızı daha önemli olabilir. Dolayısıyla evrensel “en iyi dil” yoktur; yalnızca belirli koşullar için uygun diller vardır.

Üstelik her soyutlama bir alt katmana dayanır. Basit görünen bir işlem bile çalışma zamanı, işletim sistemi ve donanımla ilişkilidir:

from concurrent.futures import ThreadPoolExecutor

def hesapla(sayi):
    # İş yükünü temsil eden basit bir hesaplama yapar.
    return sayi * sayi

with ThreadPoolExecutor(max_workers=4) as havuz:
    sonuclar = list(havuz.map(hesapla, range(10)))

print(sonuclar)

Kod kısa ve okunaklıdır; fakat iş parçacığı zamanlaması, işlemci çekirdekleri, Python çalışma zamanı ve görev türü performansı etkiler. Dil ayrıntıları gizler, ancak onları yok etmez. Joel Spolsky’nin meşhur ifadesiyle bütün önemsiz olmayan soyutlamalar bir noktada “sızdırır”.

Döngüsel iyimserliğin motoru

Yeni diller genellikle gerçek bir acıya tepki olarak doğar. Eski araçların sorunları görünür, yeni aracın sorunları ise henüz keşfedilmemiştir. Bu algı farkını şöyle özetleyebiliriz:

Konferanslar, şirket yatırımları ve sosyal medya da bu farkı büyütür. Bir dil yalnızca teknik araç değil; topluluk, kariyer fırsatı ve kimlik hâline gelir. İnsanlar teknolojiyi değerlendirirken bazen sözdizimini değil, umutlarını savunur.

“Nihai dil” ilanlarının kaybolması ilerlemenin başarısız olduğu anlamına gelmez. Aksine her kuşak, önceki kuşağın fikirlerini yeniden işler. Rust sahiplik sistemini yaygınlaştırır, Kotlin null güvenliğini erişilebilir kılar, TypeScript dinamik ekosisteme statik denetim ekler. Kazanan tek bir dil değil, diller arasında taşınan fikirlerdir.

Bu yüzden yeni bir dil tanıtıldığında “Hepsinin yerini alacak mı?” yerine “Hangi ödünleşimi farklı yapıyor?” diye sormak daha sağlıklıdır. Geleceğin nihai dili muhtemelen hiç gelmeyecek; fakat onu ararken geliştirdiğimiz kavramlar yazılımı sürekli daha güvenli, anlaşılır ve üretken hâle getirecektir.

``

Kübit gerçekten aynı anda 0 ve 1 mi?

Bir klasik bitin durumu yalnızca $0$ veya $1$ olabilir. Kübit ise şu biçimde gösterilir:

Buradaki $alpha$ ve $beta$, olasılık genlikleridir ve

Burada önemli bir ayrıntı var: Kuantum durumunun ölçüm öncesindeki evrimi Schrödinger denklemi altında deterministiktir. Yani başlangıç durumu biliniyorsa dalga fonksiyonunun nasıl gelişeceği belirlenebilir. Belirsizlik özellikle ölçüm sonucunda karşımıza çıkar.

Determinizmin çatlayan duvarı

Klasik determinizm, evrenin bir andaki bütün koşulları bilinse geleceğin hesaplanabileceğini savunur. Laplace’ın hayalî “cin”i, her parçacığın konumunu ve hızını bilerek yarını okuyabilirdi. Kuantum mekaniğinde ise Heisenberg belirsizlik ilkesi bu hayali sınırlar:

Bu eşitsizlik yalnızca ölçüm cihazlarımızın kötü olduğunu söylemez. Standart yoruma göre konum ve momentum gibi bazı nicelikler aynı anda sınırsız kesinliğe sahip değildir. Bell deneyleri de sonuçların basit, yerel ve önceden saklanmış değişkenlerle açıklanamayacağını güçlü biçimde göstermiştir.

Yine de kuantum teorisinin bütün yorumları aynı hikâyeyi anlatmaz:

Dolayısıyla “Kuantum fiziği determinizmi kesin olarak öldürdü” cümlesi biraz fazla cesurdur. Daha doğru ifade, klasik ve yerel determinizmin ciddi şekilde yara aldığıdır.

Bir kübitlik yazı tura

Aşağıdaki Qiskit örneği, bir kübiti Hadamard kapısıyla eşit süperpozisyona getirip ölçer:

from qiskit import QuantumCircuit
from qiskit_aer import AerSimulator

circuit = QuantumCircuit(1, 1)
circuit.h(0)          # Kübiti eşit süperpozisyona hazırlar
circuit.measure(0, 0) # Kuantum durumunu klasik bite dönüştürür

simulator = AerSimulator()
result = simulator.run(circuit, shots=1000).result()
print(result.get_counts())

Sonuçlar yaklaşık olarak {'0': 500, '1': 500} dağılımına yaklaşır. Ancak her çalıştırmada tam olarak aynı sayıları görmeyiz. Kod bize kuantum olasılığını gösterir; bilinçli tercih yapan minik bir kübit göstermez.

Rastgelelik özgürlük değildir

Bir kararın önceden belirlenmemiş olması, onun özgürce verildiğini kanıtlamaz. Seçiminiz nöronlardaki kuantum rastgeleliğinden kaynaklanıyorsa bu, kontrolün sizde değil kozmik bir zar atışında olduğu anlamına da gelebilir.

Kuantum hesaplama özgür iradeyi ne kanıtlar ne de çürütür. Fakat evreni kusursuz çalışan klasik bir saat gibi düşünmenin yetersiz olabileceğini gösterir. Belki felsefi kâbus kübitin hem 0 hem 1 olması değil; özgürlüğün yalnızca bu iki seçenekten birini rastgele seçmekten çok daha karmaşık olmasıdır.

``

LocalStorage nasıl çalışır?

LocalStorage, aynı kaynağa ait verilerin tarayıcıda anahtar-değer çiftleri biçiminde tutulmasını sağlar. Buradaki “aynı kaynak”; protokol, alan adı ve port birleşiminin aynı olması demektir. Örneğin https://ornek.com ile http://ornek.com farklı depolama alanlarına sahiptir.

Veriler tarayıcı kapatılsa bile korunur. Ancak LocalStorage yalnızca metin saklayabilir. Bir nesneyi doğrudan kaydetmeye çalışırsak anlamlı içeriği yerine [object Object] sonucuyla karşılaşabiliriz. Bu nedenle nesneler JSON.stringify() ile metne çevrilmeli, okunurken JSON.parse() ile geri dönüştürülmelidir.

const kullanici = {
  ad: "Ada",
  tema: "karanlik",
  bildirimler: true
};

// Nesneyi JSON metnine dönüştürerek saklar.
localStorage.setItem("kullanici", JSON.stringify(kullanici));

// Saklanan metni yeniden JavaScript nesnesine çevirir.
const kayit = localStorage.getItem("kullanici");
const okunanKullanici = kayit ? JSON.parse(kayit) : null;

console.log(okunanKullanici?.tema);

Temel işlemler oldukça sadedir: setItem() veri ekler veya günceller, getItem() okur, removeItem() belirli bir kaydı siler, clear() ise kaynağa ait bütün kayıtları temizler.

Tarayıcıların LocalStorage için genellikle birkaç megabaytlık sınırı bulunur. Yaklaşık kapasite hesabı $K \approx n \times b$ biçiminde düşünülebilir. Burada $n$ karakter sayısını, $b$ ise karakter başına kullanılan ortalama baytı temsil eder. Büyük dosyalar ve görseller bu alana doldurulmamalıdır.

Fetch API ile sunucuya ulaşmak

Fetch API, HTTP isteklerini Promise tabanlı olarak gerçekleştirir. fetch() hemen nihai veriyi değil, gelecekte oluşacak sonucu temsil eden bir Promise döndürür. Bu yapı async/await ile daha okunabilir hâle gelir.

async function kullanicilariGetir() {
  try {
    const yanit = await fetch("https://jsonplaceholder.typicode.com/users");

    if (!yanit.ok) {
      throw new Error(`HTTP hatası: ${yanit.status}`);
    }

    const kullanicilar = await yanit.json();
    localStorage.setItem("kullanicilar", JSON.stringify(kullanicilar));
    return kullanicilar;
  } catch (hata) {
    console.error("Veriler alınamadı:", hata);
    return JSON.parse(localStorage.getItem("kullanicilar") || "[]");
  }
}

Bu örnek önce sunucudan veri almaya çalışır. İstek başarısız olursa daha önce LocalStorage’a kaydedilmiş verileri kullanır. Böylece basit bir önbellek mekanizması elde edilir. Fetch yalnızca ağ hatalarında otomatik olarak reddedilir; 404 veya 500 gibi HTTP cevaplarında response.ok ayrıca kontrol edilmelidir.

await fetch("https://api.example.com/tercihler", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ tema: "karanlik" })
});

Güvenlik ve doğru kullanım

LocalStorage içeriğine sayfadaki JavaScript erişebilir. Bu nedenle parola, kredi kartı bilgisi veya uzun ömürlü erişim anahtarları burada saklanmamalıdır. Bir XSS açığı, kayıtlı verilerin saldırgan tarafından okunmasına yol açabilir. Sunucudan gelen içerik de doğrulanmadan innerHTML ile sayfaya basılmamalıdır.

En sağlıklı yaklaşım; LocalStorage’ı tema, dil ve geçici önbellek gibi düşük riskli bilgiler için kullanmak, önemli verileri sunucuda tutmak ve Fetch isteklerinde hata, zaman aşımı ve yüklenme durumlarını kullanıcıya açıkça göstermektir. Böylece uygulama hem hızlı hem dayanıklı olur; kullanıcı da boş ekrana bakıp internet tanrılarına dua etmek zorunda kalmaz.

Editör değil, öğrenilmiş bir hareket sistemi

Vim’in temel farkı modal olmasıdır. Normal modda tuşlar karakter yazmak yerine komut verir; ekleme modunda ise metin oluşturur. Böylece düzenleme, tek tek düğmelere basmaktan ziyade küçük bir dil konuşmaya dönüşür. Örneğin dw “sonraki kelimeyi sil”, ci" ise “tırnakların içini değiştir” anlamına gelir.

Bu yapı, başlangıçta yüksek bilişsel yük üretir. Zamanla komutlar prosedürel belleğe taşınır ve kullanıcı artık adımları bilinçli biçimde düşünmez. Basitleştirilmiş bir öğrenme modeli şöyle gösterilebilir:

Burada $T(n)$, $n$ tekrar sonrasındaki işlem süresi; $T_0$ başlangıç süresi, $T_{min}$ ulaşılabilecek alt sınır ve $k$ öğrenme hızıdır. Yeterli tekrar sonrasında komut, zihinsel bir problem olmaktan çıkarak parmakların bildiği bir harekete dönüşür.

Alışkanlık döngüsü ve anlık ödül

Psikolojide alışkanlıklar çoğunlukla tetikleyici, davranış ve ödül döngüsüyle açıklanır. Vim’de tetikleyici, düzenlenmesi gereken metindir. Davranış kısa bir komut dizisidir; ödül ise değişikliğin anında ve zarif biçimde gerçekleşmesidir. Özellikle karmaşık bir düzenlemeyi birkaç tuşla tamamlamak küçük ama güçlü bir yeterlilik hissi verir.

Aşağıdaki komut, geçerli satırdaki ilk foo ifadesini bar ile değiştirir:

:s/foo/bar/

Bu yalnızca kısa bir komut değildir. Kullanıcıya “Metni ben kontrol ediyorum” hissi veren hızlı bir geri bildirim mekanizmasıdır. Benzer ödüller tekrarlandıkça araç kullanımı otomatikleşir.

Emek, sahiplik ve batık maliyet

Vim kullanıcıları genellikle kendi yapılandırmalarını yıllar içinde geliştirir. Örneğin şu ayarlar satır numaralarını açar ve aramayı yazarken sonuçları gösterir:

set number
set incsearch
set ignorecase
set smartcase

Bu dosya büyüdükçe editör, fabrikadan çıkmış standart bir araç olmaktan uzaklaşır; kullanıcının tercihlerini taşıyan kişisel bir çalışma ortamına dönüşür. IKEA etkisi, insanların emek verdikleri şeylere daha fazla değer biçtiğini söyler. Batık maliyet yanılgısı da geçmişte harcanan zamanın gelecekteki tercihler üzerinde gereğinden fazla etkili olabileceğini açıklar.

Ancak her bağlılık irrasyonel değildir. Araç değiştirme maliyeti kabaca şöyle düşünülebilir:

Burada $E$ eğitim süresi, $Y$ yeni yapılandırma emeği, $A$ ise geçiş sırasında yaşanan akış kaybıdır. Vim becerisi yüksek biri için bu toplam gerçekten büyük olabilir.

Araçtan kimliğe

“Vim kullanıyorum” ifadesi zamanla “Ben klavye odaklı, sistemleri anlayan ve araçlarını özelleştiren bir programcıyım” mesajına dönüşebilir. Topluluk şakaları, .vimrc paylaşımları ve editör tartışmaları bu kimliği pekiştirir. Sosyal kimlik kuramına göre insanlar ait oldukları gruplardan benlik değerinin bir kısmını elde eder. Vim topluluğu da ortak bir jargon ve ustalık ölçütleri sunar.

Sorun, araç tercihi ahlaki üstünlük yarışına dönüştüğünde başlar. Vim kullanmak disiplinin garantisi olmadığı gibi başka bir editör kullanmak da teknik yetersizlik değildir. Sağlıklı bağlılık, aracın işe hizmet etmesidir; bağımlılık ise işin aracı savunmaya hizmet etmeye başlamasıdır.

Sonuçta bazı programcılar Vim’i bırakamaz çünkü yalnızca bir editörü değil, yıllarca geliştirdikleri hareket hafızasını, kişisel çalışma alanını ve mesleki benliklerinin küçük bir parçasını bırakmaları gerekir. Çıkmak için :q yeterli olabilir; fakat psikolojik olarak çıkış komutu biraz daha uzundur.

``

COBOL neden bu kadar uzun yaşadı?

COBOL, Common Business-Oriented Language ifadesinin kısaltmasıdır. Dil; ticari kayıtların işlenmesi, rapor üretimi ve yüksek hacimli finansal işlemler için tasarlandı. Sözdizimi bugünün dillerine göre uzun görünür, fakat okunabilirliği dönemine göre önemli bir avantajdı.

Basitleştirilmiş bir işlem mantığı şöyle yazılabilir:

IF ACCOUNT-BALANCE >= PAYMENT-AMOUNT
    SUBTRACT PAYMENT-AMOUNT FROM ACCOUNT-BALANCE
    MOVE "APPROVED" TO TRANSACTION-STATUS
ELSE
    MOVE "DECLINED" TO TRANSACTION-STATUS
END-IF.

Bu kod, bakiye yeterliyse ödeme tutarını hesaptan düşer ve işlemi onaylar. Gerçek bankacılık sistemleri elbette çok daha karmaşıktır; eşzamanlı işlemler, günlük kayıtları, güvenlik kontrolleri ve geri alma mekanizmaları içerir. Yine de temel fikir aynıdır: Veriyi doğru, tutarlı ve hızlı biçimde işlemek.

COBOL sistemlerinin önemli bölümü mainframe adı verilen yüksek güvenilirlikli bilgisayarlarda çalışır. Bu makineler saniyede binlerce işlemi yönetebilir ve yıllarca kesintisiz hizmet verebilir. Başka bir deyişle mesele yalnızca eski kod değildir; kod, donanım, veri biçimleri ve operasyon ekipleri birlikte çalışan bir ekosistemdir.

Çalışıyorsa neden değiştirmiyoruz?

Bir bankanın çekirdek sistemini yenilemek, telefon uygulamasını güncellemeye benzemez. Milyonlarca müşterinin bakiyesi, kredi planı, faiz hesabı ve geçmiş işlemi yeni sisteme eksiksiz taşınmalıdır. Küçük bir yuvarlama farkı bile büyük ölçekte ciddi sonuçlar doğurabilir.

Örneğin $N$ hesapta oluşan ortalama hata $e$ ise toplam parasal sapma kabaca

şeklinde düşünülebilir. On milyon hesapta yalnızca $0{,}01$ TL hata oluşması, toplamda $100.000$ TL tutarsızlık demektir. Üstelik finansal sistemlerde sorun sadece para değildir; denetim kayıtları ve hukuki yükümlülükler de korunmalıdır.

Risk basitçe şu bileşenlerle modellenebilir:

Eski sistemlerde arıza olasılığı bakım zorlukları nedeniyle artabilir. Ancak plansız bir dönüşümün etkisi de çok büyük olduğundan bankalar çoğu zaman “kontrollü yaşlandırma” yaklaşımını seçer.

Asıl kırılganlık koddan ibaret değil

COBOL kodunun eski olması otomatik olarak kötü olduğu anlamına gelmez. Asıl tehlike, sistemi anlayan uzmanların emekli olması ve kurumsal bilginin belgelenmemesidir. Bazı kurallar yalnızca kodun içinde saklıdır: otuz yıl önce eklenmiş bir vergi istisnası, artık kimsenin hatırlamadığı bir ürün veya gece yarısı çalışan özel bir mutabakat süreci gibi.

Bu bağımlılık toplumsaldır. Bankalar durduğunda maaşlar yatmaz, kartlar çalışmaz, işletmeler ödeme alamaz ve kamu transferleri aksar. Dolayısıyla COBOL bakımı özel bir şirketin teknik borcu olmaktan çıkarak ekonomik altyapı meselesine dönüşür.

Çözüm: Bir gecede yeniden yazmak değil

En güvenli yaklaşım genellikle kademeli modernizasyondur. Önce test kapsamı artırılır, sistem davranışları belgelenir ve COBOL uygulamasının önüne API katmanları eklenir. Ardından düşük riskli işlevler parça parça yeni platformlara taşınır. Eski ve yeni sistem bir süre paralel çalıştırılarak sonuçları karşılaştırılır.

COBOL bugün bankaları ayakta tutuyor çünkü başarısız değil, aksine fazlasıyla başarılı oldu. Fakat bu başarı sonsuz güvence sağlamıyor. Geleceğin görevi eski kodla alay etmek değil; onun taşıdığı bilgiyi kaybetmeden, toplumu sarsmadan ve dijital ekonominin fişini çekmeden dönüşümü gerçekleştirmektir.

``

Önce Quicksort’u Masaya Yatırmak

Quicksort, böl ve yönet yaklaşımına dayanan bir sıralama algoritmasıdır. Diziden bir pivot seçer; küçük değerleri pivotun soluna, büyük değerleri sağına taşır. Ardından aynı işlemi iki alt grup üzerinde tekrarlar.

Ortalama çalışma süresi şu bağıntıyla modellenebilir:

Fakat pivot sürekli en küçük veya en büyük eleman seçilirse gruplar dengesizleşir:

Yani pivot seçimi, algoritmanın kaderini değiştirir. İşte metaforun kapısı tam burada açılır: Toplumlarda da başarıyı ölçmek için seçilen merkezi kriterler, insanları dengeli biçimde değerlendirebilir veya mevcut eşitsizlikleri derinleştirebilir.

def quicksort(insanlar, olcut):
    if len(insanlar) <= 1:
        return insanlar

    pivot = insanlar[len(insanlar) // 2]
    dusuk = [kisi for kisi in insanlar if olcut(kisi) < olcut(pivot)]
    esit = [kisi for kisi in insanlar if olcut(kisi) == olcut(pivot)]
    yuksek = [kisi for kisi in insanlar if olcut(kisi) > olcut(pivot)]

    return quicksort(dusuk, olcut) + esit + quicksort(yuksek, olcut)

Bu kod, kişileri verilen bir ölçüte göre sıralar. Teknik açıdan masum görünen olcut fonksiyonu gelir, sınav puanı veya üretkenlik olabilir. Fakat ölçüt geçmişteki ayrıcalıkları içeriyorsa algoritma onları sorgulamaz; yalnızca daha düzenli hâle getirir.

Pivot ile Ayrıcalık Arasındaki Benzerlik

Bir işe alım sistemi “başarılı çalışan” profilini mevcut yöneticilere bakarak oluşturursa yöneticiler toplumsal pivot hâline gelir. Onlara benzeyen adaylar uygun, uzak kalanlar riskli sayılabilir. Böylece sistem, geçmiş hiyerarşiyi geleceğin matematiksel standardına dönüştürür.

Hızlı Olmak, Adil Olmak Değildir

Bir algoritmanın doğruluğu ile adaleti aynı şey değildir. Quicksort, tanımlanan karşılaştırma kuralına göre kusursuz sıralama yapabilir; ancak kuralın ahlaki açıdan doğru olup olmadığını bilemez. Benzer şekilde kredi modeli ödememe riskini doğru tahmin ederken belirli mahalleleri dolaylı biçimde cezalandırabilir.

Algoritmik adalette kullanılan ölçütlerden biri demografik eşitliktir:

Bu ifade, farklı grupların olumlu karar alma oranlarının eşit olmasını ister. Fırsat eşitliği ise gerçekten uygun kişiler arasındaki kabul oranlarına odaklanır:

Metaforun Sınırı ve Asıl Ders

İnsanlar sayı değildir; toplum da sıralanmayı bekleyen bir dizi değildir. Bu nedenle Quicksort benzetmesi bir çözüm değil, düşünme aracıdır. Ama güçlü bir uyarı sunar: Pivotu kim seçiyor, karşılaştırma kuralını kim yazıyor ve yanlış tarafta kalanların itiraz hakkı var mı?

Adil sistemler yalnızca daha iyi kodla kurulmaz. Temsilî veri, etki analizi, bağımsız denetim, açıklanabilir kararlar ve insan müdahalesi gerekir. Bazen en adil seçenek, sıralamayı iyileştirmek değil; herkesi tek bir hiyerarşiye sokma fikrini sorgulamaktır. Çünkü toplumsal hayatta mesele yalnızca $O(n\log n)$ hızına ulaşmak değil, hiçbir insanı görünmez bir pivotun gölgesinde bırakmamaktır.