Bjarne Stroustrup şu anda Texas A&M University’de Mühendislik Fakültesi Başkanı ve Bilgisayar Bilimleri Profesörüdür ve aynı zamanda bir AT&T Labs Fellow’dur. Onunla C++’ın tasarımı ve geliştirilmesi, çöp toplama ve başarılı programlama dillerinde sakalın rolü hakkında sohbet ediyoruz.
C++’ın geliştirilmesini ne tetikledi?
Unix çekirdeğinin dağıtık bir sürümünü tasarlamak ve uygulamak için bir araca ihtiyacım vardı. O zamanlar, 1979’da, böyle bir araç yoktu. Bir programın yapısını ifade edebilen, donanımla doğrudan çalışabilen ve ciddi sistem programlaması için yeterince verimli ve yeterince taşınabilir bir şeye ihtiyacım vardı.
C++’ın tasarımı ve evrimi hakkında daha ayrıntılı bilgiyi, ana sayfalarımda (http://www.research.att.com/~bs) bulabileceğiniz HOPL (History of Programming Languages) makalelerimde ve The Design and Evolution of C++ adlı kitabımda bulabilirsiniz.
Çözmeye çalıştığınız belirli bir problem var mıydı?
Aklımda kalan iki problem, dağıtık ya da paylaşımlı bellekli bir sistem için süreçler arası iletişim altyapısını simüle etmekti (hangi işletim sistemi hizmetlerini ayrı işlemciler üzerinde çalıştırabileceğimizi belirlemek için) ve böyle bir sistem için ağ sürücülerini yazma ihtiyacıydı.
Açıkçası —Unix C ile yazıldığı için— yüksek derecede C uyumluluğu da istiyordum. Çok erken bir dönemde, 1980’den itibaren, çeşitli ağ protokollerinin ve trafik yönetimi algoritmalarının simülasyonları için başkaları tarafından da (benim yardımımla) kullanılmaya başlandı.
C++ adı nereden geliyor?
C with Classes (C++’ın atası olan çalışmam) Bell Labs içinde popüler hale gelince, bazı insanlar bu adı fazla uzun buldu ve ona C demeye başladı. Bu da, Dennis Ritchie’nin dilinden bahsetmek istediklerinde neyi kastettiklerini belirtme ihtiyacı doğurdu; bu yüzden “Old C”, “Straight C” gibi ifadeler kullandılar. Birileri bunun Dennis’e saygısızlık olduğunu düşündü (ne Dennis ne de ben öyle hissettik) ve bir gün Bell Labs yönetim kanalları aracılığıyla bana daha iyi bir ad bulmam yönünde bir talep geldi. Bunun sonucunda bir süre C++’tan C84 olarak bahsettik. Bu pek işe yaramadı, ben de etraftan öneriler istedim ve ortaya çıkan listeden C++’ı seçtim. Herkes anlamsal olarak ++C’nin daha da iyi olacağını kabul etti, ancak bunun teknik olmayan kişiler için çok fazla sorun çıkaracağını düşündüm.
Dilin geliştirilmesi sırasında aşmanız gereken özellikle zor ya da sinir bozucu problemler var mıydı?
Bir sürü! Öncelikle, dil için temel tasarım kuralları ne olmalıydı? Dilde neler olmalı, neler dışarıda bırakılmalıydı? Çoğu insan, şimdiye kadar herhangi bir dilde faydalı buldukları her özelliği sağlayan minicik bir dil talep eder. Ne yazık ki bu imkânsızdır. Kısa bir süre şansa ve iyi zevke güvenmenin ardından, C++’taki programların aynı anda hem zarif (nesne yönelimli programlamayı tanıtan Simula67’de olduğu gibi) hem de sistem programlaması için verimli (C’de olduğu gibi) olmasını sağlamayı amaçlayan bir dizi pratik kurala yerleştim. Elbette her program her ikisi birden olamaz ve çoğu da hiçbirisi değildir, ancak amaç (ve hâlâ da amaç budur), yetkin bir programcının hemen hemen her fikri doğrudan ifade edebilmesi ve bunun asgari ek yükle çalıştırılabilmesidir (C sürümüyle karşılaştırıldığında sıfır ek yük).
Sistem programlama topluluğunu tür denetiminin değeri konusunda ikna etmek şaşırtıcı derecede zordu. Fonksiyon argümanlarının bir fonksiyon bildirimine karşı denetlenmesi fikri, pek çok kişi tarafından şiddetle reddedildi — en azından C, bu fikri C with Classes’tan benimseyene kadar.
Günümüzde nesne yönelimli programlama neredeyse her yerde, bu yüzden insanlara, sanal fonksiyonları ekleyip bunların zorlu kullanım senaryoları için yeterince hızlı olduğunu gösterene kadar, faydasına ikna edemediğime inanmak zor geliyor. C++’ın OOP varyantı temelde Simula’nınkidir ve bazı basitleştirmeler ve hızlandırmalar içerir.
C uyumluluğu, hem sorunların hem de güçlü yönlerin başlıca kaynaklarından biri olmuştur (ve olmaya devam etmektedir). C uyumlu olmak sayesinde, C++ programcıları genellikle yeni dillerin ilk sürümlerinde eksik olan bir özellikler bütünlüğüne ve çok büyük miktarda koda doğrudan (ve verimli) erişime sahip oldular — sadece C koduna değil, aynı zamanda Fortran koduna ve daha fazlasına; çünkü C çağrı kuralları basitti ve diğer dillerin desteklediklerine benziyordu. Ne de olsa eskiden şöyle derdim: yeniden kullanım, yeniden kullanım için tasarlanmış yeni bileşenlerin geliştirilmesini beklemektense, zaten var olan bir şeyi kullanmakla başlar. Öte yandan, C’nin birçok sözdizimsel ve anlamsal tuhaflığı vardır ve C evrim geçirirken onunla adım adım ilerlemek kolay olmamıştır.
Orijinal C with Classes ile C++ arasındaki temel farklar nelerdir?
Farkların çoğu uygulama tekniğindeydi. C with Classes bir önişleyici ile uygulanmıştı, oysa C++ gerçek bir derleyici gerektirir (ben de bir tane yazdım). C with Classes programlarını C++’a dönüştürmek kolaydı, ancak diller %100 uyumlu değildi.
Dil açısından bakıldığında, en büyük iyileştirme, klasik nesne yönelimli programlamayı mümkün kılan sanal fonksiyonların sağlanmasıydı. Aşırı yükleme (operatör aşırı yükleme dâhil) de eklendi ve satır içi genişletme için daha iyi destekle birlikte sunuldu. Genel kaynak yönetimi için temel C++ özellikleri olan yapıcılar ve yıkıcıların, C with Classes’ın en erken sürümünde bulunduğunu belirtmekte fayda var. Öte yandan, şablonlar (ve istisnalar) C++’ın biraz daha sonraki bir sürümünde (1989) tanıtıldı; ondan önce, jenerik programlama fikirlerini ifade etmek için ağırlıklı olarak makrolar kullanıyorduk.
Fırsatınız olsaydı C++’ın geliştirilmesinde farklı yaptığınız bir şey olur muydu?
Bu yaygın soru biraz haksız, çünkü elbette o zamanlar C++ ile ilgili neredeyse 30 yıllık deneyimin getirdiği avantajlara sahip değildim ve bugün bildiklerimin çoğu, C++’ın daha önceki sürümleriyle yapılan denemelerin sonucudur.
Ayrıca o zamanlar esasen hiçbir kaynağım yoktu (sadece ben — yarı zamanlı), dolayısıyla eğer büyük bir özgüvenle (ve doğru olarak) sanal fonksiyonların, şablonların (C++0x’in sunduklarına benzer kavramlarla) ve istisnaların C++85’i çok daha iyi bir dil yapacağını söylersem, bu sadece 1980’lerin başında nasıl tasarlanacağını bilmediğim bir şeyi değil, aynı zamanda —mucizevi biçimde mükemmel tasarımı keşfetmiş olsaydım bile— makul bir sürede uygulanamayacak bir şeyi önermiş olurum.
Bence 1985’te C++ 1.0 ile birlikte daha iyi bir standart kütüphane sunmak zar zor mümkün olurdu ve o dönem için yapılabilecek en önemli iyileştirme olurdu. ‘Daha iyi bir kütüphane’ derken, eşzamanlılık desteği için (o zamanlar mevcut ve dağıtımda olan) görev kütüphanesinin biraz geliştirilmiş bir sürümünü ve bir dizi kapsayıcı sınıfı içeren bir temel sınıflar kütüphanesini kastediyorum. Bunların sunulması, geliştirilmiş sürümlerin geliştirilmesini teşvik eder ve kurumsal kütüphaneler yerine standart temel kütüphanelerin kullanılmasına yönelik bir kültür oluştururdu.
Daha sonra, şablonları (C++ tarzı genel programlamanın anahtarıdır) çoklu kalıtımdan önce geliştirirdim (bazı insanların düşündüğü kadar büyük bir özellik değildir) ve istisnalara daha fazla vurgu yapardım. Ancak ‘istisnalar’ konusu yine geriye dönük değerlendirme sorununu gündeme getiriyor. C++’ta şablonların modern kullanımının altında yatan en önemli kavramlardan bazıları biraz daha sonra ortaya çıktı. Örneğin, şablonların güvenli ve sistematik kullanımını tanımlarken güvencelerin kullanımı, C++’ın standartlaştırılması sırasında, özellikle Dave Abrahams tarafından geliştirildi.
C++’ın 1998’de standartlaşması hakkında ne hissettiniz ve standartlaşma sürecine nasıl dahil oldunuz?
Yıllarca (1989–1997) bu standart üzerinde yoğun şekilde çalıştım – tıpkı şimdi onun halef standardı olan C++0x üzerinde çalıştığım gibi. Ana akım bir dilin kavgalı lehçelere bölünmesini engellemek zor ve hayati bir görevdir. C++’ın, geliştirme gücü, ücretsiz kütüphaneler ve pazarlama sağlayacak bir sahibi ya da ‘şeker babası’ yoktur. ISO standart komitesi, C++ topluluğunun büyümesi için vazgeçilmezdi ve bu topluluk, komitede çalışmış (ve hâlen çalışan) çok sayıdaki gönüllüye çok şey borçludur.
C++ ile yazılmış gördüğünüz en ilginç program hangisidir?
Tek bir tane seçemem ve genellikle bir programı ilginç olarak düşünmem. Daha çok, parçalarının bir kısmı C++ ile yazılmış olan bütüncül sistemlere bakarım.
Bu tür sistemler arasında NASA’nın Mars gezginlerinin otonom sürüş alt sistemi, Google arama motoru ve Amadeus’un havayolu rezervasyon sistemi aklıma geliyor. Kodu yalıtılmış olarak ele alırsak, Alexander Stepanov’un STL’sinin (C++ standart kütüphanesinin kapsayıcılar, yineleyiciler ve algoritmalar bölümünün) şimdiye kadar gördüğüm en ilginç, yararlı ve etkili C++ kod parçaları arasında olduğunu düşünüyorum.
Dili, başlangıçta amaçlanmayan bir şekilde kullanıldığını hiç gördünüz mü?
C++’ı genellik için tasarladım. Yani özellikler, benim iyi olduğuna dair görüşlerimi dayatmak yerine, hayal etmemin mümkün olmadığı şeyleri yapabilsin diye bilinçli olarak tasarlandı. Buna ek olarak, C++’ın soyutlama olanakları (örneğin sınıflar ve şablonlar), geleneksel donanım üzerinde kullanıldıklarında en yüksek hızda çalışacak şekilde tasarlandı; böylece insanlar belirli bir uygulama alanı için ihtiyaç duydukları temel soyutlamaları (karmaşık sayılar ve kaynak tanıtıcıları gibi) dilin içinde oluşturabilsinler.
Dolayısıyla evet, C++’ın öngörmediğim pek çok şey için ve tahmin etmediğim pek çok şekilde kullanıldığını görüyorum; ancak genellikle tamamen afallamıyorum. Şaşırmayı bekliyordum, bunun için tasarladım. Örneğin, STL’nin yapısı ve onunla yazılan kodun görünümü beni çok şaşırttı – iyi kapsayıcı kullanımının nasıl göründüğünü bildiğimi sanıyordum. Ancak şablonları, tür bilgisini derleme zamanında koruyup kullanacak şekilde tasarlamıştım ve less-than gibi basit bir fonksiyonun satır içine alınabilmesi ve tek bir makine talimatına derlenebilmesi için çok uğraşmıştım. Bu, ayrı ayrı tanımlanmış kodun verimli yürütülebilir koda örülmesini mümkün kıldı; bu da STL’nin verimliliğinin anahtarıdır. Sanırım en büyük sürpriz, STL’nin yıllar boyunca derlediğim genel amaçlı bir kapsayıcı mimarisi için uzun bir tasarım ölçütleri listesinin bir tanesi hariç hepsiyle örtüşmesiydi; ancak STL kodunun görünümü tamamen beklenmedikti.
Bu yüzden sürprizlerden çoğu zaman memnun olurum, ancak birçok kez de birilerinin C++’ın temellerini öğrenmeye zahmet etmemesi nedeniyle C++’ı uygun olmadığı bir kalıba zorlamaya yönelik girişimler karşısında hayal kırıklığına uğrarım. Elbette bunu yapanlar mantıksız davrandıklarına inanmazlar; aksine, programlamayı bildiklerini ve C++’ta alışkanlıklarını değiştirmelerini ya da yeni numaralar öğrenmelerini gerektirecek yeni ya da farklı bir şey olmadığını düşünürler. Bu şekilde kendinden emin olan insanlar, kodu örneğin C ya da Java için nasıl yapılandırıyorlarsa aynen öyle yapılandırır ve C++ beklediklerini yapmadığında şaşırırlar. Hatta bazıları kızar; oysa birinin C++’ta tür sistemiyle C’ye göre daha dikkatli olması gerektiğini ya da Java’da olduğu gibi C++ için ücretsiz ve standart kütüphaneler sağlayan bir şirket bulunmadığını fark edince neden kızması gerektiğini anlamıyorum. C++’ı iyi kullanmak için tür sistemini kullanmanız ve kütüphaneleri bulmanız ya da geliştirmeniz gerekir. Uygulamaları doğrudan yalın dilin üzerine ya da yalnızca standart kütüphane ile kurmaya çalışmak zaman ve emek israfıdır. Tür sistemiyle (çok sayıda dönüştürme ve makro ile) mücadele etmek beyhudedir.
Çoğu zaman, çok sayıda programcının C++ programcısı olsalar bile şablonları gerçekten hiç kullanmamış olduğu hissine kapılıyorum
Bu konuda haklı olabilirsiniz, ancak en azından birçoğu – bence çoğu – STL (ya da benzer temel kütüphaneler) aracılığıyla şablonları kullanıyor ve şablonlardan kaçınan programcıların sayısının azaldığını düşünüyorum.
Sizce bunun nedeni nedir?
Alışık olduklarından farklı olana duyulan korku, kod şişmesi söylentileri, olası bağlama sorunları ve son derece kötü hata iletileri.
GNU C++ derleyicisinin, üniversite öğrencilerini korkutmamak için daha kısa sözdizimi hata iletileri vermesini hiç dilediniz mi?
Elbette, ancak bu tamamen GCC’nin suçu değil. Temel sorun, C++98’in programcıya bir şablonun argüman türlerine ilişkin gereksinimlerini doğrudan ve basit bir şekilde ifade etme olanağı sunmamasıdır. Bu, dilin bir zayıflığıdır – bir derleyicinin değil – ve ancak bir dil değişikliğiyle tamamen ele alınabilir; bu da C++0x’in bir parçası olacaktır.
Burada, C++0x programcılarının şablon argüman kümelerinin gereksinimlerini kesin olarak belirtmelerine ve bu gereksinimlerin, dildeki diğer tüm tür denetimleri gibi, çağrı noktalarında ve tanım noktalarında (yalıtılmış olarak) denetlenmesine olanak tanıyacak olan kavramlardan (concepts) bahsediyorum. Ayrıntılar için, C++0x üzerine yazdığım makalelerden herhangi birine ya da Doug Gregor ve diğerleri (ben dahil) tarafından OOPSLA’06’da sunulan Concepts: Linguistic Support for Generic Programming in C++ çalışmasına bakabilirsiniz (yayınlar sayfamdan erişilebilir). Deneysel bir uygulama Doug Gregor’un ana sayfalarından indirilebilir (http://www.osl.iu.edu/~dgregor).
Kavramlar evrensel olarak kullanılabilir hâle gelene kadar, kısıt sınıflarını kullanarak denetimi dramatik biçimde iyileştirebiliriz; teknik SSS’ime bakın.
STL, programcıların karmaşıklık garantilerini gerçekten görebildiği birkaç (hatta belki de tek) genel amaçlı kütüphaneden biridir. Sizce bunun nedeni nedir?
STL her zamanki gibi zamanının ilerisindedir. Doğru garantileri sağlamak çok emek ister ve çoğu kütüphane tasarımcısı çabalarını daha görünür özelliklere harcamayı tercih eder. Karmaşıklık garantileri, kaliteyi güvence altına almaya yönelik birçok girişimden yalnızca biridir.
Son birkaç yılda, dağıtık hesaplamanın ortalama programcı için daha erişilebilir hâle geldiğini gördük. Bu C++’ı nasıl etkileyecek?
Bunu söylemek zor, ancak dağıtık programlamayla uğraşmadan önce bir dilin eşzamanlılığı desteklemesi ve geleneksel düz/tekdüze bellek modelinden daha fazlasıyla başa çıkabilmesi gerekir. C++0x tam olarak bunu yapıyor. Bellek modeli, atomik türler ve iş parçacığına yerel depolama, iyi bir iş parçacıkları kütüphanesini desteklemek için gereken temel garantileri sağlar. Genel olarak C++0x, çok çekirdekli sistemlerin temel ve verimli kullanımına olanak tanır.
Bunun üzerine, uygulamalarımızda eşzamanlılıktan kolay ve etkili biçimde yararlanmak için daha üst düzey eşzamanlılık modellerine ihtiyacımız var. Fonksiyon nesneleri (C++98’de mevcuttur) ve lambda’lar (C++0x özelliğidir) gibi dil özellikleri buna yardımcı olacaktır, ancak eşzamanlılığı yalnızca ‘ortak bir adres alanında bir sürü iş parçacığını serbest bırakma’ şeklinde ele alan bakış açısının ötesine geçen destek sağlamamız gerekir; bunu altyapı açısından gerekli, ancak eşzamanlı uygulamaları düzenlemenin mümkün olan en kötü yolu olarak görüyorum.
Her zaman olduğu gibi, C++ yaklaşımı verimli ilkel yapıtaşları ve çok genel (ve verimli) soyutlama mekanizmaları sağlamaktır; bunlar daha sonra kütüphaneler olarak daha üst düzey soyutlamalar inşa etmek için kullanılır.
Elbette C++’ta eşzamanlı programlama yapmak için C++0x’i beklemek zorunda değilsiniz. İnsanlar bunu yıllardır yapıyor ve yeni standardın eşzamanlılıkla ilgili sunduğu şeylerin çoğu şu anda standart öncesi biçimlerde mevcuttur.
Bunun yeni bir genel amaçlı diller kuşağının ortaya çıkmasına yol açtığını görüyor musunuz?
Betik dillerinin birçoğu, bir Web ortamında durumu yönetmeye yönelik olanaklar sunar ve asıl güçleri de budur. Basit metin işleme, yeni C++ düzenli ifade kütüphanesi (şu anda boost.org’dan erişilebilir) gibi kütüphanelerle oldukça kolay biçimde karşılanabilir, ancak hem genel amaçlı hem de dağıtık olan bir dili tasavvur etmek zordur. Bu sorunun kökü, kullanışlı dağıtık programlamanın basitleştirme ve özelleştirmeye dayanmasıdır. Genel amaçlı bir dil, tek bir üst düzey dağıtım modeli sunamaz.
Bununla birlikte, genel amaçlı bir dilin dağıtım için temel olanaklarla genişletilmesine karşı temel bir neden görmüyorum ve C++0x’in tam olarak bunu yapması gerektiğini (başarısız bir şekilde) savundum.
Bence sonunda tüm büyük diller, doğrudan dil desteği, çalışma zamanı desteği veya kütüphanelerin bir birleşimi yoluyla dağıtıma yönelik bir miktar destek sağlayacaktır.
Sizce boost kütüphaneleri gibi kaynaklar C++ için bu işlevselliği/erişilebilirliği sağlayacak mı?
Boost kütüphanelerinin bazıları – özellikle ağ kütüphanesi – iyi bir başlangıçtır. C++0x standart iş parçacıkları boost iş parçacıklarına oldukça benzer. Mümkünse, bir C++ programcısı temel dil özellikleri ve/veya sistem iş parçacıkları üzerine doğrudan inşa etmek yerine mevcut bir kütüphane (veya araç) ile başlamalıdır.
Sizce C++ bilgisayar geliştirmeye nasıl bir kalıcı miras bıraktı?
C++, nesne yönelimli programlamayı ana akıma taşıdı ve aynı şeyi genel programlama için de yapıyor.
En başarılı C++ kodlarından bazılarına, özellikle genel kaynak yönetimiyle ilgili olanlara bakarsanız, yıkıcıların (destructor) tasarımın merkezinde ve vazgeçilmez olduğunu görme eğiliminde olursunuz. Yıkıcının, en önemli bireysel katkı olarak görülmeye başlanacağını düşünüyorum – diğer her şey, bir programlama tarzını ya da programlama tarzlarının birleşimlerini desteklemek için dil özellikleri ve tekniklerin kombinasyonlarına dayanır.
C++’ın mirasına başka bir açıdan bakarsak, daha önce insanların bitler, baytlar, sözcükler ve adresler gibi makine terimleriyle doğrudan programlama yapması gereken uygulama alanlarında soyutlamayı yönetilebilir ve karşılanabilir hâle getirdiğini söyleyebiliriz.
Gelecekte, nesne yönelimli ve genel programlama tarzlarının daha yakın entegrasyonunu ve genellik, zarafet ve verimlilik ideallerinin daha iyi ifade edilmesini hedefliyorum.
C++’ın geleceğini nerede görüyorsunuz?
C++’ın birinci günden beri en büyük güce sahip olduğu alanların çoğunda: kritik bir sistem programlama bileşeni olan uygulamalarda, özellikle altyapı sağlanmasında. Bugün, esasen tüm altyapılar (tüm üst düzey dillerin gerçekleştirimleri dâhil) C++ (ya da C) ile yazılmıştır ve bunun böyle kalmasını bekliyorum. Ayrıca, gömülü sistemler programlaması C++’ın önemli bir kullanım ve büyüme alanıdır; örneğin, yeni nesil ABD savaş uçaklarının yazılımları C++ ile yazılmaktadır.
C++, özellikle kaynak kısıtları altında, aynı anda hem yüksek performansa hem de üst düzey soyutlamalara ihtiyaç duyduğunuzda en fazlasını sunar. İlginçtir ki bu tanım hem bir iPod’a hem de büyük ölçekli bir bilimsel uygulamaya uyar.
Dilin evrimi ve popülerliği sizi herhangi bir şekilde şaşırttı mı?
Al Aho (ünlü ‘Dragon’ kitabından) olası istisna olmak üzere, kimse C++’ın başarısının ölçeğini öngörmedi.
Sanırım 1980’ler boyunca şaşıracak kadar bile boş vaktim yoktu. Daha sonra hesapladım; C++’ın kullanımı her 7,5 ayda bir ikiye katlanıyordu – ve bu, özel bir pazarlama departmanı olmadan, neredeyse hiç insan olmadan ve son derece kısıtlı bir bütçeyle gerçekleşti. Genellik ve verimliliği hedefledim ve herkesin beklentilerinin ötesinde başarılı oldum.
Bu arada, zaman zaman C++’ı hafifçe övdüğüm ve eleştirenlere karşı savunduğum için onun mükemmel olduğunu düşündüğümü varsayan insanlarla karşılaşıyorum. Bu elbette saçma. C++’ın pek çok zayıflığı var – ve onları çoğu kişiden daha iyi biliyorum – ancak tasarım ve gerçekleştirim çalışmasının tüm amacı hiç hata yapmamak değildi (bu, bu ölçekte ve bu kadar katı tasarım kısıtları altında imkânsızdır). Amaç, yetkin ellerde ciddi gerçek dünya sistemleri inşa etmek için etkili olacak bir araç üretmekti. Bu konuda, en çılgın hayallerimin ötesinde başarılı oldu.
Dilin, C’nin kusurlarını miras aldığı ve çok geniş bir özellik kümesine sahip olduğu için şişkin olduğu yönündeki eleştirilere nasıl yanıt veriyorsunuz?
C++, C’nin zayıflıklarını ve güçlü yönlerini miras aldı ve güçlü yönlerden ödün vermeden zayıflıkları telafi etme konusunda makul bir iş çıkardığımızı düşünüyorum. C basit bir dil değildir (ISO standardı 500 sayfadan fazladır) ve çoğu modern dil daha da büyüktür. Elbette C++ (C gibi) oyuncak dillere kıyasla ‘şişkin’dir, ancak diğer modern dillerle karşılaştırıldığında gerçekten o kadar da büyük değildir. Günümüzde ciddi endüstriyel işler için kullanılan tüm dillerin ‘şişkin’ olmasının sağlam pratik nedenleri vardır – kullanıldıkları görevler, fildişi kule tiplerinin hayal gücünün ötesinde büyük ve karmaşıktır.
Modern dillerin rahatsız edici derecede büyük olmasının bir başka nedeni de istikrar ihtiyacıdır. 20 yıl önce yazdığım C++ kodu bugün hâlâ çalışıyor ve 20 yıl sonra da derlenip çalışacağından eminim. Büyük altyapı projeleri inşa eden insanların böyle bir istikrara ihtiyacı vardır. Ancak modern kalmak ve yeni zorluklara yanıt verebilmek için bir dilin büyümesi gerekir (ya dil özelliklerinde ya da temel kütüphanelerde), fakat herhangi bir şeyi kaldırırsanız kodu bozarsınız. Bu nedenle, kullanıcılarını ciddi biçimde önemseyerek geliştirilen diller (C++ ve C gibi) on yıllar boyunca özellik biriktirme eğilimindedir ve şişkin hâle gelir. Alternatif ise, her beş yılda bir kodunuzu yeniden yazmanız gereken güzel dillerdir.
Son olarak, C++ bilinçli olarak ve ilk günden itibaren birden fazla programlama tarzını ve bu programlama tarzlarının etkileşimini desteklemiştir. Tüm uygulamalar ve tüm insanlar için en iyi olan tek bir programlama tarzı olduğuna inanıyorsanız – örneğin nesne yönelimli programlama – o zaman sadeleştirme için bir fırsatınız vardır. Ancak ben, büyük problem sınıfları için en iyi çözümlerin – en okunabilir, bakımı en kolay, en verimli vb. çözümlerin – popüler programlama tarzlarından birden fazlasını gerektirdiğine kesin olarak inanıyorum – örneğin hem nesne yönelimli programlama hem de jenerik programlama – bu nedenle C++’ın boyutu yalnızca tek bir programlama tarzını destekleyerek küçültülemez. Programlama tarzlarının bu şekilde birlikte kullanılması, C++’a bakışımın kilit bir parçasıdır ve gücünün de önemli bir bölümünü oluşturur.
JSF++ kodlama kurallarına bakın – http://www.research.att.com/bs/JSF-AV-rules.pdf – ana sayfalarımda yer alıyor.
Dilin ilk geliştirilmesi ve devam eden kullanımı açısından en çok neyle gurur duyuyorsunuz?
C++’ın dünyayı daha iyi bir yer haline getirmeye yardımcı olmuş bu kadar çok uygulamada kullanılmış olmasından gurur duyuyorum. C++ aracılığıyla, insan genomu projesine, yüksek enerji fiziğine (C++ CERN, Fermilab, SLAC vb. yerlerde kullanılmaktadır), uzay keşfine, rüzgâr enerjisine vb. çok küçük bir katkıda bulundum. Ana sayfalarımda C++ uygulamalarının kısa bir listesini bulabilirsiniz. Dilin iyi amaçlarla kullanıldığını duyduğumda her zaman mutlu olurum.
İkinci olarak, C++’ın genel olarak kod kalitesinin seviyesini yükseltmeye yardımcı olmasından gurur duyuyorum – yalnızca C++’ta değil. Java ve C# gibi daha yeni diller, C++’ın gerçek dünya kullanımı için kabul edilebilir hâle getirdiği tekniklerle kullanılmıştır ve 20 yıl önceki kodlarla karşılaştırıldığında, bugün güvendiğimiz sistemlerin birçoğu inanılmaz derecede güvenilirdir ve makul bir ekonomik düzeyle geliştirilmiştir. Elbette daha iyisini yapabilir ve yapmalıyız, ancak şimdiye kadar kaydettiğimiz ilerlemeyle de belli bir ölçüde gurur duyabiliriz.
Doğrudan kişisel katkı açısından bakıldığında, ilk C++ derleyicisi olan Cfront’u yazabilmiş olmaktan memnuniyet duydum; bu derleyici, 1 MHz’lik bir makinede 1 MB içinde gerçek dünya programlarını derleyebiliyordu. Bu, elbette bugünün ölçütlerine göre inanılmaz derecede küçüktür, ancak erken dönem PC’lerde daha üst düzey programlamayı başlatmak için gereken buydu. Cfront, C with Classes ile yazıldı ve daha sonra (erken dönem) C++’a aktarıldı.
Bilgisayar programlama dillerinin yakın gelecekte hangi yöne gittiğini görüyorsunuz?
‘Özellikle gelecek hakkında tahmin yapmak zordur.’ Açıkçası gerçekten bilmiyorum, ancak daha iyi soyutlama mekanizmalarına, daha iyi tür güvenliğine ve eşzamanlılıktan yararlanmak için daha iyi olanaklara sahip genel amaçlı programlama dilleri göreceğimizi umuyorum. C++’ın da bunlardan biri olmasını bekliyorum.
Ayrıca şişkin kurumsal altyapılar ve diller olacak; çok sayıda özel amaçlı (alana özgü) dil olacak ve bugün bildiğimiz hâlleriyle, temelde değişmeden niş alanlarda varlığını sürdüren diller de olacak. Burada C++0x’in ötesinde C++’ın önemli ölçüde evrim geçireceğini varsaydığıma dikkat edin. C++ topluluğunun, dilin ve standart kitaplığının esasen durağan hâle gelmesine izin vermeyecek kadar büyük ve dinamik olduğunu düşünüyorum.
Yükselmekte olan programcılara herhangi bir tavsiyeniz var mı?
Bilgisayar biliminin temellerini bilin: algoritmalar, makine mimarileri, veri yapıları vb. Teknikleri uygulamadan uygulamaya körü körüne kopyalamayın. Ne yaptığınızı, bunun işe yaradığını ve neden işe yaradığını bilin. Beş yıl sonra sektörün ne olacağını ya da o zaman ne yapıyor olacağınızı bildiğinizi sanmayın; bu yüzden genel ve faydalı becerilerden oluşan bir portföy edinin. Daha iyi, daha ilkelere dayalı kod yazmaya çalışın. Programlamayı daha çok profesyonel bir etkinlik, daha az da düşük seviyeli bir hackleme faaliyeti hâline getirmek için çalışın (programlama aynı zamanda bir zanaattır, ama yalnızca bir zanaat değildir).
Alanındaki klasiklerden ve daha iyi ileri düzey ders kitaplarından öğrenin; kolayca sindirilen nasıl-yapılır kılavuzları ve çevrimiçi dokümantasyonla yetinmeyin – bunlar yüzeyseldir.
Ana sayfanızda ‘Bunu gerçekten söylediniz mi?’ başlıklı bir bölüm var. Buradaki hangi alıntı en çok peşinizi bırakmadı?
Kendimi rahatsız edilmiş hissetmiyorum. Bu alıntıları, insanlar sürekli bana bunları sordukları için yayımladım; bu yüzden onları açıkça ifade etmemin daha iyi olacağını düşündüm. ‘C++ kendinizi ayağınızdan vurmanızı zorlaştırır; ama bunu yaptığınızda tüm bacağı koparır’ sözü bazen C++’a düşmanca bir biçimde alıntılanıyor. Bu sadece olgunlaşmamışlığı gösterir.
Her güçlü araç, yanlış kullanıldığında sorun çıkarabilir ve güçlü bir araçla, daha az güçlü bir araca göre daha dikkatli olmanız gerekir: bir otomobille (kendinize ya da başkalarına) bisikletten daha fazla zarar verebilirsiniz; bir motorlu testereyle, el testerisinden daha fazla zarar verebilirsiniz vb. O alıntıda söylediğim şey diğer modern diller için de geçerlidir; örneğin bir Java programında bellek tükenmesine yol açmak son derece kolaydır. Modern diller güç araçlarıdır. Bu, onlara saygıyla yaklaşmak ve programcıların görevlerine profesyonel bir tutumla yaklaşmaları için bir nedendir. Onlardan kaçınmak için bir neden değildir, çünkü düşük seviyeli alternatifler daha da kötüdür.
Sona yaklaşmışken, çöp toplama hakkında zorunlu bir soru zamanı; bu konuda sürekli soru alıyor gibisiniz. İnsanların dilin bu yönüne bu kadar ilgi duymasının nedeni sizce nedir?
Çünkü kaynak yönetimi son derece önemli bir konudur; çünkü bazı insanlar (yanlış bir şekilde) GC’yi özensiz ve savurgan programlamanın kesin bir işareti olarak görür; ve çünkü bazı insanlar (yine yanlış bir şekilde) GC’yi iyi dilleri daha aşağı dillerden ayıran tek özellik olarak görür. Temel görüşüm, GC’nin çok faydalı bir araç olabileceği, ancak tüm programlar için ne vazgeçilmez ne de uygun olduğudur; dolayısıyla GC, C++’ta isteğe bağlı olarak kullanabileceğiniz bir şey olmalıdır. C++0x bu görüşü yansıtır.
GC’ye bakışım, onu kaynak yönetiminin ilk değil son çare olarak görmem ve sistem tasarımı için birçok araçtan biri olarak değerlendirmem bakımından pek çok kişiden farklıdır; programlamayı basitleştiren temel bir araç olarak değil.
C++’ta bellek yönetiminin nasıl ele alınmasını öneriyorsunuz?
Önerim, belleği yalnızca birçok kaynaktan biri (örneğin iş parçacığı tanıtıcıları, kilitler, dosya tanıtıcıları ve soketler) olarak görmek ve her kaynağı bir sınıfın nesnesi olarak temsil etmektir. Örneğin bellek, bir kapsayıcının öğelerini ya da bir dizgenin karakterlerini tutmak için kullanılabilir; bu nedenle düşük seviyeli veri yapılarıyla (örneğin sıfırla sonlandırılmış dizilere işaretçi dizileri) ve açık bellek yönetimiyle (örneğin new ve delete) uğraşmak yerine vector<string> gibi türleri kullanmalıyız. Burada hem vector hem de string, öğeleri olan kaynakları otomatik olarak yöneten kaynak tanıtıcıları olarak görülebilir.
Mümkün olan her yerde, bu tür kaynak tanıtıcılarının kapsamlı değişkenler olarak kullanılmasını öneririm. Bu durumda, bir programcının yanlış yapabileceği açık bir bellek yönetimi yoktur. Bir nesnenin yaşam süresi kolayca kapsama alınamıyorsa, akıllı işaretçilerin kullanımı (C++0x’te sağlanan uygun olanlar) ya da sahipliğin bir koleksiyonun üyeliği olarak temsil edilmesi gibi başka basit bir şemayı öneririm (bu teknik, katı zaman ve alan gereksinimleri olan gömülü sistemlerde kullanılabilir). Bu tekniklerin erdemleri, her tür kaynağa tekdüze biçimde uygulanmaları ve çeşitli hata işleme yaklaşımlarıyla güzel bir şekilde bütünleşmeleridir.
Yalnızca bu tür yaklaşımlar yönetilemez hâle geldiğinde – örneğin belirli bir kaynak yönetimi ya da hata işleme mimarisi olmayan bir sistemde veya açık tahsis işlemleriyle dolu bir sistemde – GC uygularım. Ne yazık ki bu tür sistemler çok yaygındır; bu yüzden GC’nin genel kaynak yönetimiyle temiz bir şekilde bütünleşmemesine rağmen (sonlandırıcıları aklınızdan bile geçirmeyin) bunu GC lehine çok güçlü bir gerekçe olarak görüyorum. Ayrıca, bir toplayıcı bulduğu çöpü raporlayacak şekilde araçlandırılabiliyorsa, mükemmel bir sızıntı dedektörü hâline gelir.
Kapsamlı kaynak yönetimi ve kapsayıcılar kullandığınızda, nispeten çok az çöp üretilir ve GC çok hızlı hâle gelir. ‘C++ en sevdiğim çöp toplayıcılı dildir, çünkü çok az çöp üretir’ iddiamın arkasında bu tür kaygılar vardır.
İsteğe bağlı olarak etkinleştirilebilen bir çöp toplayıcının C++0x’in bir parçası olmasını ummuştum, ancak yeterince teknik sorun vardı; bu nedenle, sağlandığı takdirde böyle bir toplayıcının dilin geri kalanıyla nasıl bütünleştiğine dair yalnızca ayrıntılı bir belirtimle yetinmek zorunda kaldım. Esasen tüm C++0x özelliklerinde olduğu gibi, deneysel bir gerçekleştirim mevcuttur.
Burada değinmediğim çöp toplamanın birçok yönü vardır; ancak sonuçta bu bir mülakat, ders kitabı değil.
Daha az ciddi bir not olarak, yüz kıllarının programlama dillerinin başarısıyla ilişkili olduğunu düşünüyor musunuz?
Felsefi olarak bakarsak her şeyin bir şekilde birbiriyle ilişkili olduğunu düşünebiliriz, ancak bu durumda söz konusu olan sadece mizah ve zamanın modasıdır. Başarılı dillerin daha önceki bir tasarımcı kuşağı sakalsızdı: Backus (Fortran), Hopper (COBOL) ve McCarthy (Lisp); ayrıca Dahl ve Nygaard (Simula ve nesne yönelimli programlama) da öyleydi.
Benim durumumda, sadece pragmatiğim: daha soğuk iklimlerde yaşarken (Danimarka, İngiltere ve New Jersey) sakal bıraktım; şimdi ise çok sıcak bir yer olan Teksas’ta yaşıyorum ve sakal altında acı çekmemeyi tercih ediyorum. İlginçtir ki, sakalımın ara bir aşamasını göstermek için kullandıkları fotoğraf tam tersini yapıyor. Beni Norveç’i ziyaret ederken ve birkaç günlüğüne soğuk hava tipine geri dönmüşken gösteriyor.
Belki başka ilginç korelasyonlar da vardır? Belki tasarımcı boyu ile dil başarısı arasında bir ilişki vardır? Belki dil başarısı ile Monty Python’a duyulan takdir arasında bir korelasyon vardır? Birileri bunun üzerine biraz araştırma yaparken eğlenebilir.
Son olarak, eklemek istediğiniz başka bir şey var mı?
Evet, fikirlerin ifade edilmesini ve eğitimi dikkate almamız gerektiğini düşünüyorum. Yukarıda bu konulara birkaç kez değindim, ancak insanlara C++’ın ne olması gerektiğini ve nasıl iyi kullanılacağını anlatma sorunları, onu tasarlamak ve gerçekleştirmek kadar zor ve zaman alıcıydı. İyi teknik çalışma yapmak ve sonra bunu insanlara anlatmamak anlamsızdır. Dil özellikleri tek başlarına kısır ve sıkıcıdır; faydalı olabilmeleri için programcıların dil özelliklerinin, nesne yönelimli programlama ve jenerik programlama gibi bir programlama ideali doğrultusunda birlikte nasıl kullanılabileceğini öğrenmeleri gerekir.
Elbette birçok saf teknik makale yazdım, ancak yazılarımın büyük bir kısmı programların soyutlama düzeyini yükseltmeyi, kod kalitesini iyileştirmeyi ve insanlara neyin işe yaradığını ve neden işe yaradığını anlatmayı amaçladı. Programcılardan bir gerekçe sunmadan bir şey yapmalarını istemek, onlara küçük çocuklar gibi davranmaktır – buna gücenmeleri gerekir. The C++ Programming Language, D&E, Teaching Standard C++ as a New Language baskıları ve HOPL makalelerim, C++ için ideallerimi ifade etme ve C++ topluluğunun olgunlaşmasına yardımcı olma girişimlerim arasındadır. Elbette bu yalnızca kısmen başarılı oldu – hâlâ çok fazla kopyala-yapıştır programlama yapılıyor ve kötü C++ kodu eksik değil – ancak üretilen iyi kod miktarı ve kaliteli sistemlerin sayısı beni cesaretlendiriyor.
Son zamanlarda endüstriden akademiye geçtim ve artık eğitim sorunlarını farklı bir açıdan görüyorum. Yazılım geliştiricilerimizin eğitimini iyileştirmemiz gerekiyor. Son üç yılda, birinci sınıf öğrencileri (ilk yıl öğrencileri, çoğu zaman ilk kez programlama yapanlar) için yeni bir ders geliştirdim. Bu bana daha önce hiç yakından tanımadığım bir kitleye hitap etme fırsatı verdi ve bunun sonucu olarak, Ekim ayında yayımlanacak olan, yeni başlayanlara yönelik bir ders kitabı ortaya çıktı: Programming: Principles and Practice Using C++.