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.

``

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.

``

Ö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.

``

Önce Testin Bilimsel Olmayan Bilimi

Bir programlama dilinin “kişiliğini” üç eksende modelleyebiliriz: ne kadar kural koyduğu, belirsizliğe ne kadar izin verdiği ve programcıyı hangi düşünme biçimine yönlendirdiği. Eğlencelik puanımız şöyle olsun:

Burada $T$ tip sisteminin katılığını, $P$ paradigmanın yönlendiriciliğini, $S$ ise sözdizimsel disiplini temsil eder. Yüksek $K$, dili daha planlı ve kuralcı; düşük $K$ ise daha esnek ve doğaçlamacı gösterir. Bu denklem akademik bir ölçüm değil, tasarım tercihlerini konuşmayı kolaylaştıran mizahi bir mercektir.

Python: Stratejik INTJ mi, Uyumlu ENFP mi?

Python ilk bakışta INTJ havası verir: okunabilirlik konusunda güçlü fikirleri vardır, gereksiz karmaşayı sevmez ve “Bunu yapmanın tercihen tek bir açık yolu olmalı” der. Girintiyi sözdiziminin parçası yapması da masasındaki kalemleri cetvelle hizalayan biri gibidir.

Ancak dinamik tip sistemi Python’ın daha esnek tarafını gösterir. Bir değişkenin türü çalışma zamanında belirlenebilir; ördek gibi yürüyor ve vaklıyorsa muhtemelen ördektir. Dolayısıyla Python, plan yapan fakat plan değişince kriz çıkarmayan bir INTJ–ENFP melezi sayılabilir.

def toplam(degerler):
    # Aynı davranışı destekleyen farklı koleksiyonlarla çalışır.
    return sum(degerler)

print(toplam([2, 3, 5]))
print(toplam((2.5, 3.5)))

Bu fonksiyon, parametrenin kesin sınıfını sormaz; yalnızca sum ile uyumlu olmasını bekler. Esneklik üretkenliği artırır, fakat bazı hataları çalışma zamanına bırakabilir.

Haskell: Safkan INTP

Haskell, “Önce problemi matematiksel olarak tanımlayalım” diyen INTP’dir. Saf fonksiyonlar, değişmez veriler ve güçlü statik tip sistemi onun zihinsel laboratuvarıdır. Yan etkiler bile kapıdan ellerini yıkamadan giremez; IO gibi yapılarla açıkça modellenir.

kareler :: [Int] -> [Int]
kareler sayilar = map (\x -> x * x) sayilar

Tip imzası, fonksiyonun tamsayı listesini alıp yine tamsayı listesi ürettiğini önceden bildirir. Fonksiyon dış dünyayı değiştirmez; aynı girdi için daima aynı sonucu verir. Bu özellik şu eşitlikle anlatılabilir:

Diğer Diller Partiye Katılırsa

Benzetmenin Arkasındaki Gerçek Ders

Kişilik etiketleri şaka olsa da temel ayrımlar gerçektir. Statik tipli diller hataların bir bölümünü derleme aşamasında yakalar; dinamik diller ise hızlı deneme ve esnek modelleme sağlar. Saf fonksiyonel yaklaşım durum değişimini sınırlar, nesne yönelimli yaklaşım davranış ile veriyi nesnelerde birleştirir, sistem dilleri de donanım üzerindeki kontrolü öne çıkarır.

Bu nedenle “en iyi kişilik” olmadığı gibi en iyi programlama dili de yoktur. Haskell finansal kuralları güvenle modelleyebilir, Python veri analizi prototipini hızlandırabilir, Rust kritik sistemlerde bellek güvenliği sağlayabilir. Asıl kişilik testi dile değil geliştiriciye yöneliktir: Belirsizlikle flört mü ediyorsun, yoksa derleyicinin sana sürekli “Bunu gerçekten düşündün mü?” demesini mi istiyorsun?

Regex neden bu kadar güçlü?

Teorik olarak düzenli ifadeler, düzenli dilleri tanımlamak için kullanılır. Klasik regex yapıları sonlu durum makineleriyle modellenebilir. Bir metin $n$ karakterden oluşuyorsa ve motor deterministik bir sonlu otomat gibi çalışıyorsa arama maliyeti çoğunlukla yaklaşık olarak

seviyesindedir. Başka bir deyişle motor, metni soldan sağa tarar ve her karakter için sınırlı miktarda iş yapar.

Örneğin basit bir kullanıcı adı kuralı şöyle yazılabilir:

^[a-zA-Z][a-zA-Z0-9_]{2,15}$

Bu ifade, kullanıcı adının harfle başlamasını ve toplam uzunluğunun 3 ile 16 karakter arasında olmasını sağlar. Kısa, güçlü ve elle yazılmış onlarca koşuldan daha özlüdür. Sorun, kurallar çoğaldığında başlar.

Gücün faturası: Bilişsel yük

Regex soldan sağa okunan doğal bir cümle değildir. Nokta, yıldız, soru işareti ve parantez gibi sembollerin her biri bağlama göre farklı davranır. Bu nedenle karakter sayısının az olması, kodun basit olduğu anlamına gelmez.

Örneğin JavaScript’te tarih parçalarını yakalayan ifadeye doğrudan saldırmak yerine parçaları adlandırabiliriz:

const year = "(?<year>\\d{4})";
const month = "(?<month>0[1-9]|1[0-2])";
const day = "(?<day>0[1-9]|[12]\\d|3[01])";

// Parçaları birleştirerek YYYY-MM-DD biçimini kontrol eder.
const datePattern = new RegExp(`^${year}-${month}-${day}$`);
const match = datePattern.exec("2026-07-16");

console.log(match?.groups);

Bu yöntem birkaç satır daha uzundur; fakat okuyucu hangi bölümün neyi temsil ettiğini hemen anlayabilir. Ayrıca adlandırılmış gruplar, $1 ve $2 gibi unutulmaya mahkûm referanslardan daha açıklayıcıdır.

Backtracking: Karanlık tarafın gerçek patronu

Bazı regex motorları eşleşme başarısız olduğunda önceki kararlarına dönerek başka yollar dener. Buna backtracking denir. İç içe nicelik belirteçleri, denenen yolların sayısını dramatik biçimde artırabilir:

^(a+)+$

Bu ifade yalnızca a karakterlerinden oluşan metinlerde masum görünür. Ancak sonuna farklı bir karakter eklenen uzun bir girdi, motoru çok sayıda olasılığı denemeye zorlayabilir. Kötü durumda süre yaklaşık

seviyesine yaklaşabilir. Bu durum yalnızca performans sorunu değildir; saldırganların özel girdilerle uygulamayı yavaşlattığı ReDoS güvenlik açığına dönüşebilir.

Regex ne zaman bırakılmalı?

Regex; e-posta içinden alan adı ayıklamak, log satırlarını süzmek veya sabit biçimleri doğrulamak için harikadır. Fakat iç içe geçmiş HTML, dengeli parantezler ya da bağlama bağlı iş kuralları söz konusuysa uygun bir ayrıştırıcı daha güvenlidir. Bir ifade yorum satırı olmadan açıklanamıyorsa onu parçalara ayırmak, testlerle belgelemek veya tamamen normal koda taşımak gerekir.

Sonuçta regex kötü değildir; yalnızca yoğunlaştırılmış güçtür. İyi kullanıldığında zarif bir neşter, ölçüsüz kullanıldığında ise bakım ekibine bırakılmış sembolik bir mayın tarlasıdır. En iyi regex, sadece çalışan değil, bir sonraki geliştiricinin de korkmadan değiştirebildiği regex’tir.

olarak düşünürsek eski, belgesiz ve kritik bir modülde hem hata olasılığı hem de etkinin büyüklüğü yüksek algılanır. Bilgi eksikliği bu hesabı ölçülebilir olmaktan çıkarır; boşluğu ise söylentiler doldurur.

Kabile Hafızası ve Kutsal Kod

Ekiplerin “kutsal” kabul ettiği kod genellikle geçmişte büyük bir arızayla ilişkilidir. Bir geliştirici satırı değiştirmiş, üretim sistemi çökmüş ve olayın ayrıntıları zamanla unutulmuştur. Geriye yalnızca yasak kalır. Antropolojide buna kültürel aktarım diyebiliriz: Gerekçe kaybolsa bile davranış yaşamaya devam eder.

Bu davranışlar tamamen anlamsız değildir. Çoğu, gerçek bir tehlikenin kaba biçimde kodlanmış hatırasıdır. Sorun, geçici önlemin zamanla açıklanamaz bir dogmaya dönüşmesidir.

Totem Olarak Yorum Satırı

Aşağıdaki yorum birçok kod tabanının mağara duvarı resmidir:

// DOKUNMA: Bu gecikme kaldırılırsa ödeme işlemi bazen iki kez çalışıyor.
await sleep(500);
await processPayment(order);

Buradaki sleep, muhtemelen bir yarış durumunu tesadüfen bastırır. Ancak yorum neden-sonuç ilişkisini açıklamadığı için ekip gecikmeyi koruyan bir ritüel geliştirir. Daha mühendisçe yaklaşım, işlemi benzersiz bir anahtarla idempotent hâle getirmektir:

async function processPayment(order) {
  const key = `payment:${order.id}`;
  if (await paymentExists(key)) return;

  await createPayment({ key, orderId: order.id });
}

Bu sürümde aynı sipariş yeniden işlense bile ikinci ödeme oluşturulmaz. Ritüelin yerine doğrulanabilir bir kural konmuştur.

Şamanlar, Kıdemliler ve Bilgi Tekelleri

Bazı ekiplerde yalnızca bir kişi üretim sunucusunu “sakinleştirmeyi” bilir. Bu kişi modern bir sistem şamanına dönüşür: Hangi servisin önce başlatılacağını, hangi logun kötü alamet sayıldığını ve hangi betiğin yalnızca salı günleri çalıştığını bilir. Bu uzmanlık kısa vadede değerlidir; uzun vadede ise otobüs faktörünü düşürür. Sistemi bilen kişi sayısını $n$ ile gösterirsek, $n=1$ durumu teknik olduğu kadar örgütsel bir risktir.

Sağlıklı ekipler kişiyi küçümsemek yerine bilgisini görünür kılar. Olay sonrası değerlendirmeler suçlama amacıyla değil, efsaneyi kanıta dönüştürmek için yapılmalıdır. Karakterizasyon testleri mevcut davranışı kaydeder; gözlemlenebilirlik araçları gizli bağımlılıkları açığa çıkarır; küçük ve geri alınabilir değişiklikler korkuyu azaltır.

Büyüyü Mühendisliğe Dönüştürmek

“Dokunmayın” uyarısıyla karşılaştığınızda kodu kahramanca silmek de başka bir irrasyonel ritüeldir. Önce geçmiş olayları araştırın, log ve metrik ekleyin, davranışı testlerle sabitleyin ve değişikliği kademeli yayımlayın. Amaç ekip folklorunu yok etmek değil, içindeki teknik sinyali ayıklamaktır.

Sonuçta yazılımcı batıl inançları cehaletten çok belirsizliğin ürünüdür. İyi mühendislik, insanlara “korkmayın” demekle yetinmez; korkunun yerine deney, ölçüm ve geri dönüş planı koyar. Böylece kutsal kod sıradan koda, şaman bilgisi dokümantasyona, gizemli ritüeller de anlaşılır süreçlere dönüşür.