Delphi Neden Eski Bir Teknoloji Haline Geldi?

Delphi'yi artık günlük işlerimde kullanmıyorum. Arada yeni bir sürümü çıktığında, eski bir bileşenin adı karşıma düştüğünde veya yıllar önce yazılmış bir Delphi uygulamasına dokunmam gerektiğinde dönüp bakıyorum. Bugün ona yalnızca sözdizimi veya IDE üzerinden bakmıyorum; bir zamanlar çok hızlı çözebildiği problemlerin ne kadarının hâlâ yazılım dünyasının merkezinde kaldığı daha belirleyici geliyor.

Bugün sıfırdan başlayacağım ciddi bir projede Delphi'yi tercih etmem. Bunu Delphi ile yeni bir proje yapılamadığı için söylemiyorum. Windows uygulaması geliştirilir, veri tabanına bağlanılır, HTTP servisi yazılır, Android ve iOS hedeflenir, Linux için kod derlenir, thread kullanılır. Bunların hemen hepsi teknik olarak mümkündür.

Artık bir programlama dilini yalnızca "bunu yapabiliyor mu?" sorusuyla değerlendirmiyorum. C ve C++ ile de çok geniş bir problem kümesi çözülebilir; aynı şey Java, C#, Python veya başka birçok dil için geçerlidir. Fark, çözümün çevresinde ne kadar yük taşımak gerektiğinde ortaya çıkar. Benim açımdan Delphi'yi eski yapan da büyük ölçüde budur.

"Eski" derken çalışmayan veya geliştirilmesi bırakılmış bir üründen söz etmiyorum. RAD Studio hâlâ güncelleniyor, yeni işletim sistemi sürümleri ve mobil hedefler ekleniyor. Eski olan daha çok dilin ve geliştirme ortamının ağırlık merkezi. Delphi'nin en doğal olduğu dünya hâlâ form, bileşen, olay, veri kümesi ve masaüstü uygulaması çevresinde şekilleniyor; yazılım endüstrisinin büyük bölümü ise uzun zaman önce web, servisler, dağıtık sistemler, Linux, container, açık kaynak paket ekosistemleri ve mobil platformların kendi doğal araç zincirlerine doğru kaydı.

Yeni projede neden aklıma gelmiyor?

Yeni bir servis yazarken Java veya C# dünyasında hangi HTTP katmanını, hangi bağımlılık yönetimini, hangi test aracını veya hangi telemetry sistemini kullanacağımı düşünürken dilin çevresinde hazır bir dünya buluyorum. Python tarafında veri, bilimsel hesaplama ve yapay zekâ için benzer bir durum var. C ve C++'ta işletim sistemi, donanım, gömülü yazılım veya performans sınırına yaklaştığımda karşıma onlarca yıllık açık kaynak altyapı çıkıyor.

Delphi'de aynı sorular daha erken aşamada "bunun Delphi karşılığı var mı?" biçimine dönüşebiliyor. Bu fark ilk bakışta küçük görünse de yıllarca yaşayan bir projede büyüyor. Bir yazılımın maliyeti yalnızca ilk sürümün kaç günde yazıldığı değildir; beş yıl sonra yeni bir kimlik doğrulama yöntemi eklenecek, üçüncü taraf SDK değişecek, işletim sistemi güncellenecek, bir bağımlılık güvenlik açığı nedeniyle değiştirilecek, CI sistemi başka ortama taşınacak ve projeye yeni mühendis girecek.

Delphi'nin güçlü olduğu dönemde bunların önemli bir kısmının karşılığı farklıydı. Bir Windows bilgisayarı, ilişkisel veri tabanı ve masaüstü kullanıcı arayüzü çoğu kurumsal uygulamanın önemli bölümünü oluşturabiliyordu. Delphi tam bu aralıkta çok iyiydi; bir TQuery, TDataSource ve TDBGrid ile saatler içinde çalışan bir iş ekranı çıkarmak mümkündü. C++ ile aynı dönemde aynı arayüzü hazırlamanın zahmeti düşünüldüğünde bunun ne kadar etkileyici olduğu daha iyi anlaşılıyordu.

Sorun, bu avantajın zaman içinde mimariye dönüşmesiydi. Hızlı geliştirmenin kendisi sorun değildi; hızlı geliştirilen yapının yıllarca büyümeye devam etmesi asıl yükü oluşturuyordu.

Formun uygulamaya dönüştüğü yer

Eski Delphi koduna döndüğümde en çok yabancılaştığım şey Pascal sözdizimi değil. Object Pascal hâlâ okunabilir. Beni daha fazla rahatsız eden, yıllarca çok doğal kabul ettiğimiz bazı bağımlılıklar.

Bir forma query bırakmak kolaydı, DataSource bağlamak kolaydı ve bir butonun OnClick olayında iş kuralını çalıştırmak son derece doğaldı. Başka bir formun global değişkenine ulaşmak da aynı ölçüde kolaydı.

MainForm.Edit1.Text := Value;
DataModule1.Query1.Open;

Kod kısa, fakat bağımlılık kısa değil. Bu iki satırın arkasında UI yaşam döngüsü, global nesneler, veri tabanı bağlantısı, form oluşturma sırası ve uygulama durumu bulunabiliyor. Küçük programda büyük mesele olmayan bu yapı, yüz binlerce satırlık uygulamada bir metodun neye bağımlı olduğunu imzasından anlayamamaya dönüşebiliyor.

Delphi bunun dışında mimari kurmayı engellemiyor. Arayüzler kullanılabilir, katmanlar ayrılabilir, dependency injection yapılabilir; Spring4D gibi projeler de yıllardır bunun için var. Fakat bir platformu değerlendirirken yalnızca neye izin verdiğine değil, hangi yolu doğal hale getirdiğine bakıyorum. Delphi'nin klasik yolu çok hızlıdır ve aynı hızla sıkı bağlı kod da üretebilir.

DataSet hâlâ iyi bir fikir; her yerde olması değil

Delphi'nin veri tabanı bileşenlerini kötü bulmuyorum. Tam tersine, masaüstü veri uygulaması geliştiren biri için bu modelin neden yıllarca sevildiğini anlamak zor değil.

Database
   |
DataSet
   |
DataSource
   |
DBGrid

Birkaç nesne ile verinin ekranda düzenlenebilir hale gelmesi hâlâ etkileyici. Fakat büyük sistemlerde zamanla başka bir sınır istiyorum:

Database
   |
Persistence
   |
Domain
   |
Application
   |
API / UI

İlk yapı daha çabuk sonuç verir; ikincisi veri tabanı durumunun kullanıcı arayüzüne kadar sızmasını azaltır. Delphi'nin eski projelerinde gördüğüm sorunların önemli bölümü dilin kendisinden değil, bir zamanlar çok üretken olan ilk modelin büyüdükçe bıraktığı izlerden geliyor.

Bellek yönetimi

Daha önce Delphi ile çalışırken şu kalıp son derece normaldi:

Obj := TObject.Create;
try
  Obj.Execute;
finally
  Obj.Free;
end;

Bu model hâlâ anlaşılır ve yaşam süresi açık biçimde deterministiktir. Fakat başka dillerde uzun süre çalıştıktan sonra Create/Free çiftini sürekli takip etmek, uygulamanın çözmeye çalıştığı probleme ait olmayan bir sorumluluk gibi görünmeye başlıyor.

GC kullanmayan her dili eski saymak mümkün değil; Rust tam tersini gösterdi. Buradaki fark garbage collector'ın bulunup bulunmaması değil, ownership sorumluluğunun ne kadarının derleyici tarafından izlenebildiği. Rust nesnenin sahipliğini derleyicinin anlayabileceği bir probleme dönüştürmeye çalışırken Delphi'de doğru yaşam süresini kurma sorumluluğunun önemli bölümü hâlâ geliştiricide.

Leak, yanlış ownership, dangling reference ve nil erişimleri yıllardır bilinen hata sınıfları. Modern bir dilde beni ilgilendiren şey bunların yazılabilir olup olmamasından çok, ne kadarının derleme sırasında reddedilebildiği. Delphi'de TObject referansının nil olması olağan bir runtime gerçeğiyken Kotlin'de T ile T? ayrımı, Rust'ta Option<T> ve C#'ın nullable reference analizi aynı problemin daha fazla kısmını type system tarafına itiyor.

Thread var; mesele thread oluşturmak değil

Delphi'de çok iş parçacıklı programlama yeni bir şey değil. TThread yıllardır var, daha sonra Parallel Programming Library ve TTask geldi. Bu nedenle Delphi'nin concurrency desteklemediğini söylemek doğru olmaz.

Benim için fark, concurrency'nin platformun genel programlama modeline ne kadar yayıldığında ortaya çıkıyor. Java tarafında ExecutorService, ForkJoinPool, CompletableFuture, concurrent collection'lar ve son yıllarda virtual thread'ler aynı ekosistemin parçaları. C# tarafında Task ve async/await programlama modelinin içine yerleşmiş durumda; Go concurrency'yi dil karakterinin bir parçası yaptı, Rust ise bazı concurrency hatalarını type system ile ilişkilendiriyor.

Delphi ile bunların karşılıkları kurulabilir. Fakat özellikle I/O ağırlıklı sunucu kodunda dil, runtime ve kütüphanelerin ortak bir async model çevresinde gelişmiş olması fark yaratıyor. async/await benim için yalnızca rahat bir sözdizimi değil; cancellation, hata yayılımı, scheduler, socket I/O, debugger ve framework davranışlarının aynı modele göre şekillenmesi demek.

Native kod tek başına eskisi kadar şey ifade etmiyor

Delphi hakkında sık duyulan savunmalardan biri native executable üretmesi. Bu doğru ve hâlâ değerli, fakat artık ayırt edici değil. C ve C++ zaten bu dünyada; Rust ve Go native binary üretiyor, Swift native çalışıyor, .NET tarafında AOT seçenekleri gelişti.

JVM ve CLR ise JIT, profiling, garbage collection ve runtime optimizasyonu alanında yıllarca başka bir yönde ilerledi. Bir uygulamanın hızlı olup olmadığını dil adından çıkaramıyorum; algoritma, bellek erişimi, allocation davranışı, I/O, cache locality, locking ve kullanılan kütüphaneler çoğu zaman daha belirleyici.

Native olmak hâlâ avantaj olabilir, fakat modern olmakla aynı şey değil. Delphi'nin bugün açıklamak zorunda olduğu konu compiler'ın binary üretip üretmediğinden çok, bu binary'nin çevresinde hangi geliştirme ve işletim ekosisteminin bulunduğu.

Web dünyası Delphi'yi beklemedi

Delphi ile web servisi yazmak mümkün. WebBroker eski zamandan beri var; bugün DelphiMVCFramework gibi çok daha modern açık kaynak seçenekler de bulunuyor. JWT, middleware, ORM, WebSocket veya Redis gibi ihtiyaçların Delphi tarafında karşılıklarını bulmak mümkün.

Fakat önemli olan bu özelliklerin tek tek bulunması değil. Java dünyasında Spring'in, .NET tarafında ASP.NET Core'un, Python'da Django ve FastAPI'nin, JavaScript tarafında Node ekosisteminin oluştuğu yıllarda Delphi benzer bir çekim merkezi oluşturamadı.

Bir framework yazmak mümkün, fakat ekosistem yalnızca framework yazılarak oluşmuyor. Binlerce bağımsız geliştiricinin, şirketin, kütüphanenin, dokümantasyonun, sorunun, cevabın ve gerçek üretim kullanımının zaman içinde birikmesi gerekiyor. Delphi bu birikimi masaüstünde yaptı; web tarafında aynı ağırlığı kuramadı.

Mobil destek var, mobil ekosistem aynı ölçekte değil

FireMonkey ilk çıktığında ilgimi çekmişti. Tek kod tabanıyla birden fazla platform fikri doğal olarak cazipti ve bugün Delphi ile hâlâ Android ve iOS uygulamaları geliştirilebiliyor.

Fakat Delphi'nin mobil platformları teknik olarak desteklemesi ile mobil yazılım dünyasının Delphi'yi yaygın biçimde tercih etmesi aynı şey değil. Android'in doğal geliştirme ekosistemi Kotlin/Java tarafında, iOS'unki Swift tarafında gelişti; Flutter ayrı bir ekosistem kurdu, React Native ise JavaScript dünyasının büyüklüğünü arkasına aldı.

Bir platform API değiştirdiğinde, yeni bir SDK çıktığında veya servis sağlayıcısı örnek kod yayımladığında önce hangi teknolojilerin desteklendiğine bakmak yeterli oluyor. Kotlin, Swift, JavaScript, Java, C#, Python veya C++ örneğini bulmak olağan; Delphi örneği daha seyrek. Binding veya wrapper yazılabilir, native API çağrılabilir, fakat yapılabiliyor olması bunun düşük maliyetli olduğu anlamına gelmiyor.

Linux desteği ile Linux dünyasının parçası olmak farklı şeyler

Delphi bugün Linux hedefli kod üretebiliyor. Bu teknik olarak önemli bir ilerleme, fakat Linux'ta yıllarca çalıştıktan sonra platform desteğine yalnızca derleyicinin executable üretmesi olarak bakmak zor geliyor.

Linux tarafındaki doğal geliştirme ortamı shell araçları, package manager'lar, container image'ları, standart build sistemleri, açık kaynak servisler, dağıtık sistem araçları, profiler'lar ve gözlemleme altyapılarıyla birlikte geliyor. Go, Java, C/C++, Rust, Python ve artık .NET bu dünyanın içinde günlük olarak karşıma çıkıyor.

Delphi Linux'a çıktı, fakat Linux ekosisteminin ağırlık merkezi Delphi çevresine kaymadı. Bu da yine target desteği ile ekosistem aidiyetinin aynı şey olmadığını gösteriyor.

Paket yöneticisi sayılardan daha fazlasıdır

Delphi'nin bugün GetIt'i var. Bir zamanlar component indirip installer çalıştırdığımız, package'ı IDE'ye eklediğimiz ve Library Path düzenlediğimiz dönemden daha iyi bir yerde.

Fakat Maven Central, NuGet, npm veya PyPI kullandıktan sonra aynı kategorideymiş gibi davranmak zor. Büyük paket depolarının ölçeği bugün milyonlarla ifade ediliyor. Bu depolar aynı şeyi birebir saymadığı için bunları doğrudan dil pazar payı karşılaştırması olarak okumuyorum; yine de Delphi'nin paket ve bileşen ekosisteminin bu merkezî depolarla aynı ölçekte olmadığı açık.

Bugün bir Java projesini başka makineye aldığımda Maven veya Gradle bağımlılıkları indiriyor. .NET tarafında NuGet aynı işi yapıyor; Python ve JavaScript ekosistemlerinde de benzer beklenti var. Eski Delphi projelerinde ise gerçek bağımlılık tanımı kaynak kodunun yanında kurulu component'lerde, DCU/BPL sürümlerinde ve IDE yollarında saklanabiliyordu.

Eski bir projeyi açıp Unit X not found mesajını görmek yalnızca eksik bir dosyanın haberi değildi. Bazen o projenin yıllar önceki geliştirici bilgisayarının bir bölümünü yeniden inşa etmek gerektiği anlamına geliyordu. Bu tür ortam bağımlılıkları yeni projede özellikle kaçınmak istediğim şeyler arasında.

GitHub'a bakınca

Arada Delphi'de neler olduğuna bakarken GitHub'a da bakıyorum. DelphiMVCFramework, Spring4D ve başka iyi projeler var; üretim kalitesi yüksek işler de çıkıyor.

Buna rağmen genel açık kaynak hareketliliği içinde Delphi'nin kapladığı yer küçük. GitHub'ın 2025 Octoverse verisinde ilk sıralarda TypeScript, Python, JavaScript, Java, C#, PHP, C++, Shell, HCL ve Go bulunuyor; Delphi ilk 10'da değil. Bu tek başına bir dilin kalitesini ölçmez ve her eski dili GitHub trendiyle değerlendirmek doğru olmaz.

Yeni proje seçimi açısından yine de önemli bir sinyal. GitHub yalnızca kaynak kod deposu değil; issue geçmişi, örnek kullanım, CI dosyaları, gerçek hatalar, pull request'ler, entegrasyon örnekleri ve geliştiricilerin birbirinden öğrendiği büyük bir teknik hafıza. Delphi bu hafızada Java, C#, Python, JavaScript veya C++ ile aynı hacimde değil.

Bu fark yapay zekâ araçlarında daha görünür oluyor

Birkaç yıl önce küçük topluluğun temel dezavantajı Stack Overflow'da daha az cevap veya Google'da daha az örnek bulmaktı. Şimdi aynı eksiklik başka yerde yeniden karşıma çıkıyor.

Kod üreten modeller, retrieval sistemleri ve IDE içindeki yapay zekâ araçları açık dokümantasyon, kaynak kod, issue, örnek ve teknik tartışma bolluğundan yararlanıyor. Yaygın bir Java kütüphanesiyle ilgili modelin karşılaşmış olabileceği açık örnek sayısıyla, yalnız birkaç Delphi projesinde kullanılan ticari bir VCL component'ine ilişkin veri aynı değil.

Bu, yapay zekânın Delphi kodu yazamadığı anlamına gelmiyor. Sorun daha çok uzun kuyruğa gidildikçe ortaya çıkıyor: az kullanılan component sürümleri, eski compiler davranışları, DFM ayrıntıları ve vendor'a özgü API'lerde kaynak azaldıkça modelin dayanabileceği doğrulanabilir örnekler de azalıyor.

Büyük açık kaynak ekosistemi artık yalnız insanların daha kolay soru sormasını sağlamıyor; makine tarafından kullanılabilen teknik hafızayı da büyütüyor. Bu nedenle küçük ekosistemlerin dezavantajı bugün eskisine göre daha görünür.

Üniversitedeki programlama dilleri dersi

Üniversitede programlama dilleri dersinde Robert W. Sebesta'nın Concepts of Programming Languages kitabını kullanmıştık. Delphi geçmişim olduğu için kitapta dillerin nasıl sınıflandırıldığına bakarken ister istemez Delphi'yi de arıyordum.

Hatırladığım şey Delphi'nin bu tartışmanın merkezinde olmadığı. 2018'de yayımlanan 12. baskının güncelliği korumak için Swift ve Python üzerine yeni içerik eklemesi de bunu daha anlamlı hale getiriyor. Kitabın ana bölümleri dil evrimi, type system, nesne yönelimli programlama, concurrency, functional ve logic programming gibi kavramlar üzerinden ilerliyor; Delphi bu çağdaş karşılaştırmanın belirgin örneklerinden biri değil.

Tek bir ders kitabının kimi seçtiği elbette teknoloji endüstrisini belirlemez. Fakat yıllar sonra Stanford ve MIT gibi üniversitelerin açık derslerine baktığımda da benzer bir görüntü görüyorum. Stanford'un güncel Programming Languages dersi Haskell ve Rust üzerinden type system, algebraic data type, concurrency, metaprogramming ve semantics tartışıyor; MIT'nin açık programlama materyallerinde Python temel giriş dili olarak öne çıkarken Julia, MATLAB, Java ve C/C++ gibi diller için de dersler bulunuyor.

Delphi'yi burada sık görmemek beni şaşırtmıyor. Bir dilin akademik değeri yalnız üniversitede ders olarak okutulmasıyla ölçülmez, fakat yeni programcıların nerede yetiştiğini anlamaya çalışırken bu sinyal önemsiz değil. Pascal bir dönem eğitim dili olarak çok güçlüydü; Delphi ise Pascal'ın eğitimdeki tarihsel konumunu modern endüstri ekosistemine aynı ölçüde taşıyamadı.

Lisans meselesi

Delphi'yi yıllar sonra yeniden kurmayı düşündüğümde beni hâlâ eski dünyaya bağlayan şeylerden biri lisans modeli. Community Edition var ve bu olumlu; öğrenci, hobi geliştiricisi veya çok küçük ölçekte başlayan biri ücretsiz kullanabiliyor.

Buna karşılık resmi koşullarda yıllık 5.000 dolar gelir sınırı bulunuyor ve ekip büyüdüğünde ticari sürüme geçmek gerekiyor. Community Edition bir yıllık lisans dönemine sahip; remote database erişimi ve Linux server deployment gibi bazı özellikler de daha yüksek ürün katmanlarına bağlı.

Bunların her biri ticari açıdan açıklanabilir tercihler. Benim açımdan soru, OpenJDK, .NET SDK, GCC, Clang, Go, Rust ve Python gibi araç zincirleri yanımdayken yeni bir projeye daha ilk günden derleyici ve IDE lisans politikasını neden mimari değişken olarak ekleyeyim sorusu.

1990'larda iyi bir IDE ve compiler başlı başına satılabilir büyük bir üründü. 2026'da compiler, runtime, language server, debugger, package infrastructure ve framework'lerin önemli bölümünün açık kaynak olması sıradanlaştı. Delphi'nin lisans modeli çalışıyor olabilir; fakat ait olduğu geliştirme aracı ekonomisi bugünün açık ekosistemlerinden belirgin biçimde farklı.

MEB'in bir milyon öğrenci girişimi

2020'de Milli Eğitim Bakanlığı ile BTG arasında yapılan Delphi protokolü bu yüzden bende tuhaf bir izlenim bırakmıştı. Konu internette bazen "MEB bir milyon Delphi lisansı satın aldı" biçiminde anlatıldı; resmî açıklama bu değil.

Protokol, Delphi'nin 1.600'den fazla mesleki ve teknik okulda yaklaşık bir milyon öğrencinin ücretsiz kullanımına sunulmasını, öğretmen eğitimlerini ve ilgili laboratuvar çalışmalarını kapsıyordu. Bu ayrımı önemli buluyorum; ödeme yapıldığına dair veri olmadan bir milyon lisans satın alındığını söylemek doğru değil.

Ücretsiz olması ise benim temel itirazımı ortadan kaldırmıyor. Bir öğrencinin zamanı, müfredat saati, öğretmenin yeni teknoloji için harcadığı süre, laboratuvar kapasitesi ve kurumsal dikkat ücretsiz değil. Bir milyon öğrenci gibi büyük bir sayı söz konusu olduğunda benim sorum lisans faturası değil, neden Delphi'nin seçildiği.

Programlama mantığı öğretilecekse açık kaynak ve çok daha geniş kullanım alanına sahip alternatifler vardı. Öğrenci iş hayatına hazırlanacaksa yine daha büyük ekosistemler vardı; mobil hedefleniyorsa Android'in ve iOS'un doğal dilleri, web tarafında başka ekosistemler ve veri bilimi ile yapay zekâ tarafında Python'ın yükselişi 2020'de zaten görünür durumdaydı.

Pascal kökeni nedeniyle Delphi'nin öğretici ve okunabilir olması bir avantaj. Fakat bir milyon öğrencinin teknoloji tercihinde yalnız ilk haftaların sözdizimi kolaylığına bakamam. Öğrenci yalnız if, for ve fonksiyon öğrenmiyor; package manager kullanıyor, repository geziyor, başkalarının kodunu okuyor, üçüncü taraf kütüphane ekliyor, hata arıyor, CI öğreniyor, farklı işletim sistemleri görüyor ve zamanla bir topluluğun parçası oluyor.

Delphi'nin eğitimdeki garip yeri

Pascal'ın bilgisayar bilimi eğitiminde tarihsel bir yeri var. Niklaus Wirth'ün Pascal'ı yapılandırılmış programlamayı öğretmek için tasarladığı dönem ile Delphi'nin RAD ürünü olarak geliştiği dönem aynı şey değil.

Bazen Delphi'nin eğitim için uygun olduğu savunulurken bu iki tarih birbirine karışıyor. Pascal'ın eğitim için iyi tasarlanmış olması, ticari Delphi toolchain'inin milyon ölçeğinde öğrenci için bugün en iyi eğitim yatırımı olduğunu kendiliğinden göstermiyor.

Öğretmek için kullanılan dilin mutlaka iş piyasasının en popüler dili olması gerektiğini de düşünmüyorum. Scheme, Haskell veya OCaml gibi diller belirli programlama kavramlarını öğretirken ticari pazar payından bağımsız çok değerli olabilir.

Fark amaçta ortaya çıkıyor. Bu diller çoğu zaman bir kavramı görünür kılmak için seçiliyor; Delphi'nin eğitim savunması ise daha çok kolay GUI geliştirme, Object Pascal'ın okunabilirliği ve RAD verimliliğine dayanıyor. Bunlar kötü özellikler değil, fakat programlama dilleri dersinde type system, semantics, functional programming, concurrency veya memory safety gibi kavramları tartışacaksam bugün Delphi benim ilk örneğim olmaz.

Vendor ve ürün tarihi

Delphi'nin tarihinde Borland, CodeGear, Embarcadero ve daha sonra Idera çatısı var. Burada bazen "Delphi dört kez satıldı" gibi fazla basitleştirilmiş bir anlatı kullanılıyor; CodeGear Borland'ın geliştirici araçları için oluşturduğu birimdi, daha sonra Embarcadero tarafından satın alındı ve Embarcadero da Idera bünyesine geçti.

Benim için isimlerin sayısından çok bu geçmişin bıraktığı mühendislik sonucu önemli. On veya yirmi yıl yaşayacak bir kurumsal sistemde compiler, IDE, framework ve önemli üçüncü taraf bileşenler aynı ticari ekosisteme bağlıysa üreticinin yol haritası mimarinin bir parçası oluyor.

Kapalı kaynak veya ticari ürün kullanmaya karşı değilim. Yıllardır ticari veri tabanları, işletim sistemleri, donanımlar ve araçlarla çalışıyorum; fakat bağımlılığın fiyatını ayrıca hesaplamak gerekiyor.

Delphi projesi bazen yalnız Delphi kaynak koduna değil, belirli RAD Studio sürümüne, belirli component setine, belirli BPL/DCU sürümüne ve geliştirici makinesinin ayarlarına bağlanabiliyor. Eski projelerde bunun ne anlama geldiğini gördüğüm için yeni projede aynı borcu isteyerek oluşturmak istemiyorum.

FireMonkey neden fikrimi değiştirmedi?

FireMonkey Delphi'nin masaüstü Windows sınırından çıkmak için attığı önemli adımlardan biriydi. Teknik olarak küçümsemiyorum; tek framework ile Windows, macOS, Android ve iOS hedeflemek zor bir problem.

Fakat teknoloji seçiminde sonuca bakıyorum. FireMonkey çıktıktan yıllar sonra mobil uygulama dünyasında Delphi hâlâ istisna; cross-platform uygulamalarda Flutter, React Native ve başka ekosistemler çok daha görünür.

Bu bana bir platformun target listesi ile pazar kabulünün aynı şey olmadığını hatırlatıyor. Compiler'ın bir platform için binary üretmesi birinci aşama; o platformdaki geliştiricilerin, SDK üreticilerinin, kütüphane yazarlarının, şirketlerin ve yeni mezunların o teknoloji çevresinde toplanması ikinci aşama.

Delphi ilkini başardı. İkincisini ise aynı ölçekte başaramadı.

Eski Delphi uygulamasını yine de hemen değiştirmem

Bütün bunlara rağmen çalışan büyük bir Delphi uygulamasını yalnızca "eski" diye yeniden yazmayı doğru bulmuyorum. Bu, yeni projede Delphi seçmemekle çelişmiyor.

Yirmi yıllık bir uygulamada kod yalnız algoritmalardan oluşmuyor. Bug'ların çözümleri, veri tabanındaki gariplikler, müşterinin yıllar içinde istediği davranışlar, unutulmuş edge case'ler ve artık kimsenin dokümante etmediği iş kuralları kaynak kodun içinde kalıyor.

Eski bir formun yüzlerce satırlık event koduna bakıp kötü mimari demek kolay. Onu sıfırdan yazdıktan sonra on beş yıl boyunca çözülmüş hataların yarısını tekrar keşfetmek daha pahalı olabilir.

Bu nedenle mevcut Delphi sisteminde önce sınır çizerim. Stabil çalışan çekirdeği yerinde bırakırım; yeni entegrasyonları, web katmanını, mobil istemciyi, raporlamayı, aramayı veya yoğun işlem gerektiren yeni bileşenleri gerektiğinde başka teknolojilerde ayırırım. Eski bölüm gerçekten küçüldüğünde değiştirmeye değip değmediğine yeniden bakarım.

Delphi'nin bugün en güçlü gerekçesi

Delphi için bugün duyduğum en ikna edici gerekçe çoğu zaman "Bu sistem zaten Delphi" oluyor. Bu aslında güçlü bir gerekçe.

Ekip dili biliyorsa, uygulama yıllardır çalışıyorsa, büyük VCL yatırımı varsa, Windows masaüstü hedefleniyorsa ve kullanıcıların ihtiyacını karşılıyorsa sırf başka bir dil daha popüler diye sistemi yeniden yazmak anlamsız olabilir. Fakat yeni projede bu gerekçelerin hiçbiri yok; orada Delphi diğer seçeneklerle sıfırdan yarışıyor.

Benim için yarışın sonucu uzun zamandır benzer. Yeni Windows masaüstü uygulamasında bile önce C#/.NET ve diğer seçeneklere bakarım. Backend için Java/.NET/Go gibi ekosistemler daha doğal geliyor; sistem seviyesinde C/C++ veya Rust, veri ve yapay zekâ tarafında Python, mobilde platformun doğal araçları veya yaygın cross-platform çözümler daha anlamlı.

Delphi ancak gereksinimin kendisi Delphi'nin güçlü tarafına çok özel biçimde oturuyorsa yeniden masaya geliyor. Bu, geçmişte Delphi kullanmış biri için biraz garip bir durum; IDE'yi açtığımda Object Inspector, form designer, unit yapısı, begin/end ve property/event modeli hâlâ tanıdık geliyor.

Sonra IDE'yi kapatıp bugün kullandığım sistemlere dönüyorum. Aradaki fark syntax değil; dünya değişmiş. Delphi de değişmiş, fakat dünyanın değiştiği yönde aynı ağırlığı kuramamış. Bence Delphi'yi eski yapan da tam olarak bu: çalışmaya devam etmesi değil, yeni bir problem geldiğinde artık akla ilk gelen araçlardan biri olmaması.

Kaynaklar

• Robert W. Sebesta, Concepts of Programming Languages, 12th Edition, Pearson, 2018: https://www.pearson.com/en-us/subject-catalog/p/concepts-of-programming-languages/P200000003361/9780134997186
• GitHub, Octoverse 2025 – Top Programming Languages: https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/
• Sonatype, State of the Software Supply Chain 2026 – Software Infrastructure Growth: https://www.sonatype.com/state-of-the-software-supply-chain/2026/software-infrastructure-growth
• Stanford University, CS 242 – Programming Languages: https://explorecourses.stanford.edu/search?q=CS242
• MIT OpenCourseWare, Introductory Programming: https://ocw.mit.edu/collections/introductory-programming/
• MIT OpenCourseWare, Language Specific Programming Courses: https://ocw.mit.edu/course-lists/language-specific-programming-courses/
• Embarcadero, Delphi Community Edition FAQ: https://www.embarcadero.com/products/delphi/starter/faq
• Embarcadero, Reasons to Upgrade Delphi: https://www.embarcadero.com/products/delphi/starter/top-upgrade-reasons
• Embarcadero RAD Studio Platform Status: https://docwiki.embarcadero.com/PlatformStatus/en/Main_Page
• DelphiMVCFramework: https://github.com/danieleteti/delphimvcframework
• Spring4D: https://github.com/spring4d/spring4d
• T.C. Millî Eğitim Bakanlığı, 1 Milyon Meslek Lisesi Öğrencisine Yazılım Eğitimi: https://www.meb.gov.tr/1-milyon-meslek-lisesi-ogrencisine-yazilim-egitimi/haber/20138/tr