Permalink
Reply
Nisan 2008 de Bjarne Stroustrup ile yapılmış bir röportaj .Yazını Türkçe çevrimi pek iyi değil. İsteyenler buradan (http://msdn.microsoft.com/en-us/magazine/cc500572.aspx) orjinalini okuyabilir.
Bjarne Stroustrup’dan Dillerin Evrimi
Her biri bir anda, mühendislik alanında biranda değişen, çabucak tekrar şekillenen ve ilerleyen bir bölüm oldular. Sanki yazılım geliştiriciliğinde C++ programlama diline giriş yaptıktan sonra bir ilerleme meydana gelmişti. Bu ilerleyiş , C++’tan önceki Simula67 ve Smaltalk’ta gibi nesneye yönelik programlama dillerinin kendi içinde bir gelişim yoktu. Her şeye rağmen C++dili C dilinin üzerine inşa edildi(geliştirildi) (ve C programları gibi derlenebilir) soyutlamaları nesneye yönelik düşünüm sayesinde ana görüşe yerleştirebilme olanağı sağladı.
C++ ‘ın gelişiminde “meta-programcılığı”dan güzel örnekler ve yazılım geliştirme ve dizaynında bulunan tüm güzel işlemler kullanıldı. Bunun nedeni, donanım platformları arasında daha taşınabilir olması ve daha düşük seviyelerde daha etkili olması. C++ etkleyici bir şekilde dünyada, daha hızlı olabilme ve daha az donanım geresinimi açısından bir esas olacak.
C++ dilinin geliştiricisi olan Bjarne Stroustrupile konuşurken gerçekten heyecanlandım. Kendi başlıkları hakkında ve programlama dillerinin endüstrisi hakkında ki görüşlerini öğrendim, ayrıca kendi kişisel okuma listesini öğrendim. Benim blog’uma okuyucular tarafından yazılıp , tavsiye edilen bir çok soruyu sordum. Sorularıyla katkıda bulunan herkese ve tabiî ki Bjarne’ye teşekkür ederim.
Dil Hakkında Düşündükleri:
Howard Dierking: Neden programlama dilleri insanlarla bu kadar alt seviyede bağlanıyorlar? -ki topluluğun dili direniyorken niçin böyle bir alt seviye bağlantısı gerekli?
Bjarne Strustrup: Bunu bir bilgisayar bilimciden çok psikoloğa, sosyoloğa yada ne bilieyim bir economiste sormalısın. Benim düşüncem eğer bir dil biliyorsanız, kendimizi ve kendi fikirlerimizi açmamız, açıklamamız için bizim bir parçamız haline geliyor. Diğer dillerinde taraftarı olmak kişisel bir korkuya neden olabiliyor. Bu noktada çözüm daha çok dili daha iyi bilmek gibi görünüyor. Yazılım alanında tek bir dil bilmekle bu alanda profesyonel olabileceğinize inanmıyorum. Bunun ekonomik nedenleri olabilir örneğin bir programlama dilinin sınırlarını zorlamaya başlayabilirsiniz ama bazı pratik becerileri edinemezsiniz. Şimdi ben X dilini biliyor ve sadece onun hakkında onun araçlarıyla ilgili bilgim varsa ve ben Y dili hakkında bir şey bilmiyor ama konuşuyorsam eğer bu benim geçimimi tehdit eder. Çözüm yine çok dil ve bu dillerin kullanım araçlarını bilmekten geçiyor. Maalesef ki önerilerim bazıları tarafından sadece belli bir süre kullanılırken, bazıları hesaba bile almadan sadece kendi düşünceleriyle yürüttükleri işlerine devam ediyorlar.
HD: Yazılım geliştiriminde IDE nin rolü ne olmalıdır? IDE dili nasıl desteklemelidir?
BS: Ben öyle çok IDE kullanan biri değilim. Benim dilimi IDE ile destekleyen tüm editörleri tebrik ederim ama ben IDE’ler olmadan çalışmak isterim. Eğer gerçekten tümsel olarak kullanılabilen bir IDE sahibi olsaydım farklı düşüncelere sahip olabilirdim. –gerçekten bir yazılım parçası olmuş bir önek için şekil 1 e bakın. Benim isteğim burada portatif kodların rol alması. C++ ile sistemimdeki kaynak dosyanın içinden kaynak kodlarını anlayabilmeği istiyorum. Ben hali hazırda dönüşüm ve kuşak içeren IDE mekanizmalarını sevmiyorum, bu kodları insanın tüketimine uygulanmış, kalıplaştırılmış gibi gösteriyor.
http://img90.imageshack.us/img90/5948/adszdz.jpg (http://img90.imageshack.us/i/adszdz.jpg/)
(Bir Dilde IDE Tasarımı)
HD: BU günlerde dillerin(programlama) genel amaçları hakkında problem duyuyor yada okuyor musunuz? Eğer böyle şeyler varsa çözüm nedir peki ?
BS: Daha basit bir söz dizimi daha güzel olabilir, çoğu kişinin okunabilirlik hakkında konuştukları zaman doğruluk derecesi olan bir dokümanın umdukları karmaşıklıkta ortaya çıkmadığı hakkında etrafta yakındıklarından şüpheleniyorum. Çoğu insan herhangi bir dille yazılmış herhangi bir programa ulaşmayı ve onu anlamayı bekler, online yardım desteğinin sunduğu olanaklar dahilinde tabi ki, aslında tek sorun programın yayınlamasında ki tüm yapıları anlamak ve programın kendi mantığını kapmaktır. Bizim doğal dillere karşı olan bakışımızı ve onları kullanışımızı kıyasla. Mesela Shakespear’in şiirlerini herhangi bir alt yapın olmadan tam anlamıyla anlayabilirmisin? Yada “Beowulf” ( 8. Yüzyıla ait epik bir şiir türü) eski orijinal İngilizcede nasıldı? Beklide biz programlama dillerinden çok şey bekliyoruz. Hiçbir dil tüm alanlarda, tüm gereksinimleri karşılayabilecek kadar sorunsuz ve bir hayli gereksiz karmaşıklığı olmayan bir sistem değildir ama uygulamaları geliştirebilmek amacıyla temelleri bulundururlar. Her dilin özelliği o dilin tanımladığı bir sisteme hitap eder ama biz şimdiki zamanımızda bu karmaşıklığın bedeli olarak bir çok dili ve onların getirdiği bir çok yapıyı öğrenmek zorundayız.
HD: Genel amaçlı programlama dilleri, uygulama geliştirimi sırasında bileşen programlama yada hizmet programlaması, nasıl olmalıdır?
BS: Genel programlama dilleri, genel yada uygulamaya özel kütüphanelerin tarifinin tasarımını desteklemeli, araç tasarımını desteklemeli, farklı uygulamalarla kontak kurabilmeyi desteklemelidir. Bunun için bir dil esnekliğe, anlamlı bir sisteme, güzel ve temel bir performansa ve uzun gelecekte karalılığa ihtiyacı vardır.
HD: Çoklu dispatch sizce iyi bir şeymi?
BS: Evet, basmakalıp nesneye yönelimli programlama dilleri ( Simula, C++,Smalltalk,Java,C# gibi) basit işlemleri hassa bir şekilde tanımlayamıyorlar. Çoklu olanların ise arakesiti bulmalarının iki şekli var, bunların mecburiyet çeşitleri çalışma zamanına kadar bilinemiyor. Böyle bir kodlamanın sonucu umduğumuz gibi bir yürütebilirlik vermiyor. Geçen sene öğrencilerimle birlikte bu konu üzerine araştırdığımız makaleyi yayınladık, sonuç olarak içinde bulunulan durumu yada olayı daha az hafızayla, daha kısa zamanda, daha basit ve daha hızlı bir çalışmayla halledebildiğimizi gördük. Bu konuyu aşağıda ki şekilde (şekil 2) görebilirsiniz. Bu çalışma C++ için çok geç geldi diye düşünüldü. Ayrıca isterseniz makaleyi http://research.att.com/~bs/multimethods.pdf adresinden bulabilirsiniz.
http://img40.imageshack.us/img40/5004/adsz2ld.jpg (http://img40.imageshack.us/i/adsz2ld.jpg/)
(Şekil 2)
HD: C++ ‘ın eşdeğerliliği hakkındaki düşünceleriniz neler? Gelecekte son çıkan biçimleri ekleyerek dilin versiyonunu yenileyecek misiniz?
BS: Aslında hayır, bu alanda C++ ne yapması gerekiyorsa yapıyor. Hiçbir vektörünün, bir vektörüne dönüşmesini gibi bir örnek düşünebiliyor musunuz? Bu korkunç bir şekilde güvenliksiz olurdu ancak vektörü sabittir (ya da siz onun yerine bir ekleyebilirsiniz). Çalışma süresi gerçekten bir sorun teşkil eder seviyeye gelinceye kadar böyle bir şey yapmayı düşünmüyorum.
HD: Bir anahtar dil özelliği ile ilgili mesaj geçimi yapımı hakkında ki düşüncelerin neler? Bir metod lüzumuna karşı çıkan özellikler?
BS: Net olan mesaj geçimlerini seviyorum ama onları çok uzun zaman önce kullandım ve ayrık sistemlerin içeriğinde yer alıyorlar. Gerçekçi olursak, büyük ölçekli işlerde mesaj geçimi için çok ciddi bir çalışma ve araç desteği sağlamamız gerekiyor. Bunun tam anlamıyla tamamlandığını sanmıyorum, tabi yanılıyor da olabilirim. Çoğu hata paylaşım ve kilitleyip devam etmeyle bağdaşıyor eğer ki gerçekten mesajlar ve mesaj kuyrukları üstünde çalışıyorsanız. Bunun için C++ ta standart kütüphaneleri görmeyi seviyorum.
HD: Genel amaçlı dillerde içsel olarak eş uyumlu bir yerde herhangi bir çakışma duyuyor musunuz? Yani sizi takip edenler tarafından herhangi bir hata bildirisi alıyor musunuz?
BS: Şimdi eğer küçük bir kitleye hitap ediyor olsanız onları takip edebielir ve nasıl bir hata yaptığınızı göz önüne alarak daha güzel şeyler ortaya çıkarabilirsiniz (örneğin onlara şu teorik bilgiyi öğrenin diyebilirsiniz.) ama genel amaçlı dillerde böyle bir işlem yapmanız çok zor zaten. Genel amaçlı bir dilin bir parçası olmak bazen çok vahşice gelebilir düşünsenize yazığınız dökümanlar milyonlar tarafından okunuyor, uygulanıyor vs. . C++ özel bir dil değil fakat hassas işte bu konudaki düşüncelerim bunlar.
HD: Mimarideki anlamı çok mu öne çıkardık?
BS: Hayır, en azından benim tanımladığım manasıyla. Ters şekilde anlaşılan çok az bir ön plana çıkarma var, yapıların prensiplerini çok az anlayıp kodlama çok zayıfça bir iş çıkarır. Benim mimari hakkında şüphelendiğim ana konu şu : programcıların iyi kod kodlama ile ilgili belirsiz düşüncelerinin olması. Ne yapmanız gerektiği hakkında yada yapmamanız gerektiği hakkında yeterli bilginiz yok bu yüzden bizim iyi mimari edilmiş sıkı kurallara ihtiyacımız var.
HD: Açık kaynaklı kod birliği size yardım etti mi? Size zarar verdi mi? Yada dizayn da her hangi bir kalite değişikliği yapmadı mı?
BS: Bu gerçekten zor bir soru. Çoğu yerde yardımlarını gördüm(insanlara sunacağımız kodların profesyonellik derecesinde kalitesini ayarlarken), tabi bana zarar verdikleri yerlerde oldu (gerçekten kötü bir şekilde düşündükleri alışkanlıkları ve vaziyetleri) ve daha söyleyemeyeceğim bir çok durum var.Uzun zamanda topluluğun etkisi ne olur tahmin edemem, topluluk daha iyi mi destek verir yoksa daha az mı bunu bilemem çünkü topluluk tahmin edebileceğimden daha kalabalık.
Dil Eğitimleri:
HD: Yakın gelecekte Dinamik Dillere aday olacak bir şey görebiliyor musunuz?
BS: Aslında hayır, insanlar elma ile armut u çok sık kıyaslıyorlar. Genel olarak Statik ve Dinamik diller arasında bir seçimimizin olduğuna inanmıyorum. Fillerin bu iki kalıpla biçimlenebileceğine inanmıyorum : çoğu eğer dinamik değilse, statik olarak sınırlandırılıyor. Bir moda var tabiî ki ama bu konu yani bu moda hakkında bir tahminim yok çoğu gerçek-dünya dillerinin seçimi yönlü olarak bir uygulamanın ihtiyacını karşılayacak, geliştiricinin becerisine yönelik olarak tasarlanıyor. Örneğin ben hiçbir zaman bir RUBY ‘ yi java ile gerçekleştirmedim yada gerçek bir interaktif simülasyonu C++ gibi bir dille yapmadım.
HD: En sonunda void/variant/object ve benzerlerinin tamamen kaldırılması sizce iyi bir şey mi? (aşağıda ki kodlama örneği bunun için iyi bir örnek)
STDMETHODIMP
CoCalc::QueryInterface(REFIID riid, void** ppv)
{
if (riid == IID_IFirst || riid == IID_IUnknown)
ppv = static_cast<IFirst>(this);
else if (riid == IID_ISecond)
*ppv = static_cast(this);
else
{
*ppv = 0;
return E_NOINTERFACE;
}
AddRef();
return S_OK;
}
BS: Tahmin ediyorum ki prensip olarak kapsamlı(geniş) şeylerden kurtulmak iyi bir durum ama reel olarak biz kendi tanımlamak istediğimiz şeyleri tam manasıyla sınıflandırarak daha özel olabilir ve başarabiliriz. Örneğin ben hiçbir zaman her obje için bir şeyler yapabilen bir fonksiyon görmedim; ne üzerinde oynama yapıyorsanız sürekli bir varsayım yapıyorsunuzdur. (saf bir ilerleme fonksiyonu, sayaç örneği için en yakın düşünebileceğim şeydir). C++ dünyasında ki şu anki konsept çalışması (genetik algoritmalarda ki baskılar/gereksinimler) bu konuda bir yardımı olacaktır ama kendimizi genel mekanizmalar olmaksızın böyle bir açıklamayı yapabilecek derecede görmüyorum; “bilmek istemediğim bir şey” gibi beklenmedik bir yaklaşım olabilir.
HD: Gevşek yazılmış dillerin arkada kalması gibi bir eğilim var. Acaba tekrar Macar Rotasyonu üzerine mi düşünmeliyiz?
BS: Öyle bir eğilim olduğunu sanmıyorum. Gittikçe kaybolan dillere uygun düşen görevler artmakta. Diğer yandan bu tür diller hala gelişiyor olabilir (ben böyle düşünüyorum) çünkü geride kalmış kaybolan dillerin kullanımı arttıkça gelişimi de paralel olarak artmakta. Ayrıca kesinlikle Macar Rotasyonunu kullanmayınız, bu çok kötü bir düşüncedir. Yazdığınız programın kaynak kodu programının simüle yazımını değil anlamını yansıtmalıdır. Eğer gerçekten Macar Rotasyonuna ihtiyaç duyuyorsanız emin olun ki uygulamanız için uygun olmayan bir dil kullanıyorsunuz demektir.
HD: 2000 yılında “ C++,yeni milenyum için yeni bir dil” isminde bir sunum yaptınız ve “Wrap” konseptine değindiniz. Bu basit olarak söyleyecek olursak “ aspect- oritnted programming(AOP)” tir. Genel olarak soracak olursak “AOP” ve onun şablonu olan “Wrap” hakkında ne düşünüyornusuz?
BS: “AOP” hakkında tam bir cevap verebilmek için çok fazla zaman harcamadım aslında. Aslında oluşumları seviyorum ( özellikle yayılımcı olmayanlarını) . Ben esasen ekstra-dil ile alakalı olan araçları ve onların standartlaşmamış araç zincirini merak ediyorum. C++ örnek şablonları yayımlıcılık göstermeyen, ilgi çeken ve başarılı oluşumlardır –Örnekler için Standford Üniversitesi Kütüphanesi ne bakın, gömülü sistem programlaması bölümüne. Bunun, katı bir şekil almaya ve hiyerarşik şekilde ön dizayna gerek kalmadan ve zorlanmaksızın olması kombine bir fikir için gerçekten de güçlü bir şekil. Fakat bu durum bazı geliştiriciler için yönetimi zorlarlaştırır ve kavramsal olarak ağırlaştırır. C++0x biçimsellik veya performans olmaksızın bir sürü örnek şablon içerir.
HD: C++’ın kesin söz malum karakteristiğinde istenmeden yapılanan, kötü amaçlı ve önemli potansiyelleri var ( örneğin makrolar ). Bu yapıları yani belirsizlikleri C++’ta yada genel anlamlı modern dillerde nasıl gömeliyiz?
BS: Aslında makroların kötü amaçlı olduğunu “C” dilini kullanmaya başladığımda gördüm ama diğer bu işi yapan tüm insanlar gibi bunların kötü amaçlı oluşunu veya olumsuz yönlerini tam olarak tahmin edemedim. İşte C++ ın neden 10 yıl gibi bir sürede mükemmel derecede geliştiremediğimizin nedenidir yani “C” dilinde ki makroların her yana yayılmasından dolayı. C++ ta objeleri sıfırlanın bir çok yanıltıcı yöntemi var. Umarım C++0x te adreslerin tek şekilli mekanizmalrı olur. Diğer soruda örnek şablonlardan bahsetmiştim. İşte sonraki C++ ın (1985 te yayınlanan) başarısının temel nedeni budur. Uyumluluk sorunları nedeniyle C++ ta adreslenemeyen irili ufaklı hatalar keşfedildi. Örneğin söz diziminin sahipliliği gereksiz bir yanlışlıktı, sadece lineer bir gösterim daha iyi olabilirdi. Benzer biçimde bir çok varsayım yanlıştı; yapılar öntanımlı olarak geri dönüşümlü olmamalıydı. İsimler öntanımlı olarak başka kaynak kodlardan erişilebilir olmamalıydı ve dahası… Bağdatırıcıların kontrol edilememesi sabit bir problem olmamıştır; özel olarak uygulayıcılar birbirine zıt şekillerde sunulması memnuniyet sağlamıştır. Tüm bunlara rağmen olumlu süprizlerde oldu.. En güzel olanı ise çöp toplama işleminin kaynak yönetime olanak sağlayabilmesi ve hata yönetimini kontrol edebilmesidir. Tüm bunlardan sonra çöp toplama fikrinin güzel bir olay olduğunu biliyorum.
HD: Sitenizde ki bir söyleminizde: “Dilin içindeki özelliklerinden çok yaptığınız uygulamanın zerafetine dikkat etmelisiniz” demiştiniz. Bu söylem Alansal Özelleştirilmiş Diller’e (DLS=Domain Specific Languages) yönelik bir hareket mi oluyor?
BS: Evet, aşağı yukarı kesinlikle. Bu alana sıklıkla bir girişim, teşebbüs olmuştur. Bazen yapmak gerek.
HD: Genel olarak DLS hakkında ki düşünceleriniz neler? DLS ve genel amaçlı diller arasında ki ilişki hakkında kafanızda ne canlandırıyorsunuz?
BS: Kaç dilin geliştirilmeye başlandığını, geliştirildiğini ve çok abartılı bir şekilde sunulduğunu ve sonradan beklenmedik bir şekilde anlamını yitirip kaybolduğunu gerçekten merak ediyorum. Bir çok yıl gelişim için uğraşılır tüm bunlar boyunca çok emek harcanır ama birden fark edilir ki geri dönüşü olmayan bir kaybolma yoluna girilmiştir. Bu konu hakkında “Anlamsal Geliştirilmiş Kütüphane Dillerine Mantıksal Bir Bakış” adlı bir makale yazmıştım (http://research.att.com/~bs/SELLrationale.pdf ). Kütüphanelerin kullanılmasını, olasılıkla desteklenen araçlar ve genel destekli diller hakkında eleştiride bulunmuştum.
Bence DLS başvurulacak son nokta olmalı, ilk değil. Eğer mümkünsel genel amaçlı dillere ve onların araç zincirlerine sağlam bir şekilde tutturulmalıdır. DLS bir genel amaçlı programlama diline ihtiyaç duyar( en azından bir sistem programlama dili ) dili ve dilin genel çalışma zamanını tanımlamak için. Eğer DLS genel amaçlı bir dilde sağlam ve bilinçli olarak eşleştirilirse, yeni özellikler kazandırmak ve yeni kütüphaneler eklemek için çok güzel olur. Açıkçası bir profesyonel bir çok dilde usta olmalıdır
HD: C++ dilinde bir çok yapının bilinçli olarak belirsiz yapının değerin farklı donanımlarda çeşitli değerler aldığını ifade ettiniz . Bu belirsiz yapıların işbiliğinden bir ilerleme gördünüz mü?
BS: “ Belirsizlik” yanlış kelime. Tanımlanmamış bir çok şeyden ve tamamlamaktan uzak bir ifade. Ben şundan şüphe ediyorum; eğer tekrar C++’ı karama işinden başlayarak tekrar dizayn etsem hiçbir tanımlanmamış veya tamamlanmamış kısmı kalmazdı fakat bir zaman makinem yok ayrıca milyonlarca kodlanmış satır arasından iyi olmayanlarını toplayıp tekrar değerlendirebilecek durumum yok.
Yöntembilimi ve En İyi Egzersiz:
HD: Bu dili örenmek isteyenlere ne gibi süreçler tavsiye edersiniz?
BS: Anahtar uygulama konseptini tespit edin, yararlı kütüphaneleri tespit edin, uygulama konseptine uygun olacak kütüphaneler oluşturun, fikirleri hemen deneyin, hemen tümleştirin, erkenden ve sık sık test edin, eğitimsel dökümanlar kullanın ve küçük programlardan çok büyük çaplı programlar geliştirin (gerçi bu çok uzun zaman alabilir). Açık olmak gerekirse ben şu an için küçük çaplı projelere odaklanmış durumdayım.
HD: Hiç programlama dilleri veya geliştirme metoduyla ilgili bir kesişim yada ortaklık görüyor musunuz?
BS: Tabiki, kütüphane geliştiriminde özellikle. Gittikçe yüksek seviyeli ihtiyaçlar doğuyor ve bunun sonucu olarak kütüphane dizaynı kaçınılmaz bir şekilde dildeki yerini alıyor. Bu noktayı her ne kadar böyle söylesemde abartmamam gerekli çünkü tüm dillerde bu işlem için tek bir yol izlenilebilir diyemem mesela COBOL, C, JAVA, C++ ve PYTHON için her dilden minimum destekle kazanç ummak gerekir.
HD: Bir yazılım geliştirirken sizin kişisel kurallarınız nelerdir?
BS: Ana konsepte odaklanmak, ara yüzlere odaklanmak, kaynak yönetimine odaklanmak ( hafıza, dosyalar, kilit ve diğerleri… ), hata yönetimine odaklanmak, sınıflar için değişmezlikler ve kaynak edinim sınıflanması (Resource Acquisiton Is Inialization = RAII ), işte bunlar anahtar teknikler.
HD: Atik olduğunuza dair bir çok söylenti var. Sizin için ”atiklik” ne ifade ediyor? C++ atikliği destekliyor mu?
BS: Ben böyle bir kelime kullanmadım. Bu çok muallak bir şey. Evet C++ bunu destekler, o ne demekse…
Geleceğe Bakış:
HD: Nasıl olurda bir dil ileri derecede özelliklerini örneğin örnek şablonlarını, dinamik olaylarını, kendi kendine kod yazımını(tamamlamayı), aynı zamanda yeni girişler için olduğu gibi kalan erişilebilirliğini kendi kendine geliştirebilir?
BS: Bilmiyorum. Bunun genel bir cevabının olduğunu düşünmüyorum. Yeni özellikler dilin içeriğinin daha kullanışlı yardımı için önemlidir fakat istikrar temeldir; C veya C++’ı zorlamaya devam eden tek bir sebep girilen yeni değerin eskiye döndürülmesine neden olur. Bu kolay değil, en azından bunu söylemek ve yeni bir giriş her zaman başarılı olamayabiliyor. Çoğu zaman kullanıcılar tarafından yoksayıldığını duyuyoruz. Bazı ana özellikler C++0x için tasarlanmıştı örneğin tekdüze yükleme, otomatik kelime tamamlama ve örnek şablon kontrolü gibi işlemler daha iyi hizmet verebilmesi açısından eksper kullanıcılara sunulmuştu.
HD: “ÜSTVERİ(MetaData)” yı gelecekte ki programlama dilleri için önemli bir özellik olarak görüyor musunuz?
BS: Hayır, ben kişisel olarak üstveri’nin saçma sapan kullanılışını rahatsız edici buluyorum.
HD: İleride CPU’ların çekirdek sayısının artmasıyla birlikte uyumluluk için temel bir değişim görüyor musunuz? C++0x teki adreslemeye ne kadar uyumluluk sağlanabilir ?
BS: C++0x size temel olanı sunar. Bir makine modeli çok kullanımlılık için uygun olabilir. Düşük seviyede kuyruğa bağlı olanlar kütüphane oluşturumu için bir iş parçacığıdır ve API kütüphanesini kilitler. Daha fazlasını görmek isterim özellikle daha basitini. Yüksek seviyeli olanları iş havuzları, örnekler ve mesaj kuruları baz alınarak uyumluluk sağlattırılır. Bizim ihtiyacımız olan otomatik yada otomatiğe yakın , bir hesaplamayı diğer işlemlerden ayırıp yerini belirleyen yollar bulmamız. Bu alanda bir çok çalıma var özellikle C++ ta ama halen baskın bir model oluşmuş durumda değil. Örneğin Texas A&M üniversitesinin STAPL içeren çalışması ve INTEL in çalışması olan TBB.
HD: GPGPU hakkında ne düşünüyorsunuz? (GPGPU=bakınız http://tr.wikipedia.org/wiki/GPGPU )
HS: Ümit verici ama henüz bu konuda konuşabilecek bir deneyimim olmadı ama açıkçası bunu kullanabilmek için bir özel amaçlı yeteneğe sahip olan bir işlemciye sahip olmak gerekir.
HD: Yüksek performanslı işlem yapmanın çabucak bir şekilde programcılar için şefaflaşacağını öngörüyor musunuz? Dahası bu amaç bir programlama dili için mi? Bir kütüphane için mi? Yoksa bir framework(yapı) için mi olacak?
HS: Sadece bir yere kadar şeffaflık. Uyumluluğun olabileceğini yada tamamen şeffaflığın olabileceğini düşünmüyorum. Başlangıçtakiler için hata yönetimi işlemcilerin kullanılabilirliğine bağlı olarak çok değişik olabilir, paylaşılmış(yada paylaşılmamış) hafıza, ayrılmışlık(yada ayrılmamışlık) ve gecikme süresi. Öngördüğüm kadarıyla şeffaflık yeni bir dil için, yeni dil özellikleri için ve (benim favorim) yeni kütüphaneler için yerini alacak bir amaç. Son bahsettiğimiz mümkün eğer ki altında yatan dil temel ihtiyaçlara bir makine modeli olarak cevap verebilir ve çok düşük seviyede kurala bağlı olmaksızın sabitlenebilirse. C++0x bunu yapacak.
HD: C++0x’in dizaynı nasıl? Ne zaman bitiyor?
BS: En sonunda finale yaklaştık. En azından umarım, oylama bitene kadar hiçbir şey söyleyemem ve adaylar sonlanana kadar her şet gergin ve duygusal olabilir. Bizim şuan ki planımız oylamayı kazanmak ve Haziran da yeni bir standart duyurusu yapmak. Açıkçası bu bir başlık hakkında bir kitap yazabilirdim nasıl bir standart yapabilirsiniz? Yol gösterim prensiplerinin ne olduğu sanılıyordu? Ve kesinlikle bunun içinde ki nedir? Bunu neredeyse yaptım benim HOPL makalemi görün “Gerçek Bir Dünya İçin Dil Geliştirimi : C++ 1996-2006” (http://research.att.com/~bs/hopl-almost-final.pdf adresinden erişebilirsiniz) ama C++0x ilgili bir şey bulamazsınız. Eğer obur bir cezalandırıcıysanız sitemde ki “WG21” e bakın ve tüm ISO C++ Standartlarıyla ilgili makaleleri bulun eğer hiç biri sizi ikna etmediyse bu çok çalışma demek. Genişçe kullanılmış bir programlama dilini geliştirmek zordur özellikle de bir çok katmanı, bir çok aracı , dilleri ve uygulamaları tamamlanmışsa. Benim C++ sayfamda ve başka online ders veren sitelerde azda olsa video bulabilirsiniz bu konu hakkında.
Kitaplar ve Telefonlar:
HD: Son zamanlarda ne okuyorsunuz?
BS: Teknik metaryeller. Hennessy ve Paterson un makine mimarisi üzerine hatırlatıcı dökümanlarına geri döndüm. İnsanların iyi kod yazabilmeleri için makaleler ve dökümanlar biriktiriyorum( bu arada bende öğreniyorum tabi ki ). Bazen umduğumdan daha zor makaleler buluyorum öyleki akademik makalelerin çok özel eğilimleri oluyor ve akademik olmayan makaleler ispattan yoksun yüksek şeylerden bahsediyor(öneriler hoş karşılanıyor). Daha sonra bu dökümanlar elbette C++’ın standartlaştırılması sağlam bir akım olacak. Knuth serisini tekrar okuyorum ama biri 3.cildi çalmış, sanırım beklemem gerekecek. Heyecan için biraz O’Brain’s Aubrey ve Maturin okuyorum. Bilime olan bakışımı yenilemeye çalışıyorum ve Rodger Command ın “Okyanus : İngiliz Deniz Kuvvetlerinin Tarihi 1645-1815” (bu nedenle O’Brain i ziyaret ettim)
HD: “ Her zaman bilgisayarımı kullanmam telefonumu kullanmam kadar kolay olsa, dileğim gerçekleşti çünkü artık telefonumun nasıl kullanıldığını anlayamıyorum” demiştiniz peki bir SmartPhone’nunuz var mı? Bu bir şekilde faha mı kolay oldu?
BS: Ben iyi bir telefon takipçisi değilim. Yüz yüze görüşmeyi tercih ederim bunu yapamadığım zamanlarda ise kelimeleri yazmayı tercih ederim. En iyi telefon bile güzel bir mailin yerini tutamaz. Ben cebime sığması açısından ince bir telefon kullanıyorum ve özelliklerinin hiç birini de kullanmıyorum. Ses kalitesi ve güvenlik için hemen hemen tüm özelliklerini bıraktım. Adaletli olmak gerekirse kullanıcı ara yüzleri bu gün daha iyiye gidiyor.
--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]