Brendan Eich, JavaScript’in geliştiricisi ve Mozilla Corporation’ın Teknoloji Direktörüdür. Eich, JS’nin 1995’te Netscape’teki başlangıcından itibaren gelişimini ayrıntılarıyla anlatır ve devam eden popülerliği ile Web’de istemci tarafı betik dillerinin geleceğinin ne olacağına inandığı konular hakkında yorum yapar.
JavaScript’in geliştirilmesini ne tetikledi?
Erken tarih hakkında blogumda yazdım: http://Weblogs.mozillazine.org/roadmap/archives/2008/04/popularity.html.
4 Nisan 1995’te Netscape’e katıldım; amaç, Scheme programlama dilini ya da ona benzer bir şeyi Netscape’in tarayıcısına yerleştirmekti. Ancak kadro kıtlığı nedeniyle, Web sunucusu ve proxy ürünlerinden sorumlu olan Netscape Server grubuna alındım. Bir ay boyunca yeni nesil HTTP tasarımı üzerinde çalıştım, fakat Mayıs ayına gelindiğinde, katılmak üzere işe alındığım gruba, yani Client (tarayıcı) ekibine geri döndüm ve hemen JavaScript’e dönüşecek olan şeyin prototipini yapmaya başladım.
İtici güç, en azından Marc Andreessen ve benim, Sun’dan Bill Joy ile birlikte, HTML’nin bir ‘betik dili’ne ihtiyaç duyduğu yönündeki inancımızdı; yani amatörler ve yeni başlayanlar tarafından kolayca kullanılabilen, kodun Web sayfası işaretlemesinin bir parçası olarak doğrudan kaynak biçiminde yazılabildiği bir programlama dili. Görüntüler, eklentiler ve Java applet’leri gibi bileşenlerden Web içeriği oluşturan Web tasarımcıları ve yarı zamanlı programcılar için Web’e yönelik bir ‘yapıştırıcı dil’ sağlamayı hedefledik. Java’yı, daha yüksek ücretli programcılar tarafından kullanılan ‘bileşen dili’ olarak görüyorduk; yapıştırıcı programcılar—Web sayfası tasarımcıları—bileşenleri bir araya getirip etkileşimlerini JS kullanarak otomatikleştirecekti.
Bu anlamda JS, Visual Basic’e; Java ise Microsoft’un Windows’ta ve uygulamalarında kullandığı programlama dili ailesinde C++’a benziyordu.
Programlama piramidi boyunca bu iş bölümü, tüm programcıların ‘küçük’ betik dili yerine ‘gerçek’ programlama dilini (Java veya C++) kullanmasını gerektiren alternatiflere kıyasla daha fazla yeniliği teşvik eder.
Peki çözmeye çalıştığınız belirli bir sorun var mıydı?
Web sayfalarının programlanabilir olmaması, onları statik, metin ağırlıklı hâle getiriyordu; en iyi ihtimalle tablolarda ya da sağda solda yüzen görüntüler vardı. Sayfanın öğelerine dokunabilen, özelliklerini değiştirebilen ve olaylara yanıt verebilen JS gibi bir betik diliyle, uygulamalara daha çok benzeyen sayfalardan oluşan çok daha canlı bir Web hayal ediyorduk.
Nitekim, bazı erken benimseyenler, 1995’in sonlarında bile (Netscape 2’nin beta döneminde), çerçeve kümelerinde çerçeveler ve JS kullanarak gelişmiş Web uygulamaları geliştirdiler; bu da Ajax ya da Web 2.0 tarzı geliştirmenin habercisi oldu. Ancak o zamanlar makineler daha yavaştı, JS’nin başlangıçtaki tarayıcı API’leri görece yetersizdi ve sunucularla iletişim kurmanın yolları genellikle tüm Web sayfalarını yeniden yüklemeyi içeriyordu.
JavaScript, Java programlama diliyle esasen ilişkili değilken adını nasıl aldı?
Yukarıda bağlantısı verilen blog yazıma bakın.
JS neden başlangıçta Mocha, ardından LiveScript olarak adlandırıldı?
Mocha, Marc Andreessen’ın kod adıdır; ancak Netscape pazarlama ekibi olası marka çatışmaları gördü ve başka gerekçelerle de bunu tercih etmedi. İsimlendirmede bir ‘live’ temaları vardı (LiveWire, LiveScript vb.). Ancak dönemin Java ivmesi (1995–1996) bunların hepsini bastırdı.
JavaScript, ECMAScript’ten nasıl farklıdır?
ECMA-262 Edition 3, en güncel ECMAScript standardıdır. Edition 1, Netscape’teki çalışmama dayanıyordu; buna Microsoft’un IE’deki tersine mühendisliğiyle geliştirdiği sürüm (JScript olarak adlandırıldı) ve Borland ile birkaç başka şirketin benzerleri eklendi.
- sürüm, 16. Bölümünde pek çok türde genişletmeye açıkça izin verir; dolayısıyla JavaScript, standartta yer alanlardan daha fazlasını ifade eder ve dil, Mozilla’nın SpiderMonkey ve Rhino motorları gibi uygulamalarda standardın önünde evrilmektedir (SpiderMonkey, Firefox’taki JS motorudur).
ECMA standardı yalnızca çekirdek dili kodlar, DOM’u değil; oysa pek çok insan DOM’u ‘JavaScript’ olarak düşünür.
JavaScript ve JScript terimlerinin birbirinin yerine kullanılabileceğine ya da kullanılmasına inanıyor musunuz?
JScript, tarayıcılar arası dokümantasyon ve kitaplarda dili ifade etmek için pek kullanılmaz ya da hiç kullanılmaz. Kitapların başlıklarında, geliştirici belgelerinde ve konferanslarda kullanılan ad JavaScript’tir (kısaca JS). İyi ya da kötü, gerçek adı budur.
Dilin geliştirilmesi sırasında aşmanız gereken özellikle zor ya da can sıkıcı sorunlar var mıydı?
Evet; esas olarak kavramı kanıtlamak için inanılmaz derecede kısa olan geliştirme döngüsü ve bunun ardından dil tasarımının zorunluluktan donması. Mayıs 1995’te, Date sınıfı hariç yerleşik nesneler dâhil olmak üzere yorumlayıcıyı geliştirmek için yaklaşık on gün harcadım (Netscape’ten Ken Smith, Java’nın java.util.Date sınıfını C’ye çevirerek bunu yazmaya yardımcı oldu; bu süreçte farkında olmadan java.util.Date’in Y2K hatalarını da miras aldı!).
1995’in geri kalanını bu motoru Netscape tarayıcısına yerleştirmeye ve daha sonra DOM (Document Object Model) olarak bilinen şeyi geliştirmeye harcadım; özellikle DOM seviye 0: JS’den pencereleri, belgeleri, formları, bağlantıları, görüntüleri vb. kontrol etmeye yönelik API’ler ile olaylara yanıt verme ve zamanlayıcılardan kod çalıştırma.
1996’nın ortalarına kadar Netscape’te tek JS geliştiricisi bendim.
JavaScript ile yazılmış gördüğünüz en ilginç program nedir?
TIBET (http://www.technicalpursuit.com), Smalltalk’u model alan erken dönem, iddialı bir çerçeveydi.
Günümüzde JS tarafında HotRuby3 gibi harika şeyler var—bu, tarayıcıda Ruby bayt kodunu tamamen JS içinde çalıştırır—ayrıca bir Java VM de bulunuyor.
Ayrıca hem yeni hem de diğer gerçekleştirimlerden taşınmış daha fazla oyun görüyoruz: - http://blog.nihilogic.dk/2008/04/super-mario-in-14kb-javascript.html - http://canvex.lazyilluminati.com/83/play.xhtml
Ve John Resig’in Processing görselleştirme dilinin portu zirveyi kapıyor: http://ejohn.org/blog/processingjs.
Peki en kötüsü hangisi?
Tek bir “en kötü” JS programı seçmem mümkün değil. Sadece şunu söyleyebilirim ki eski günlerde JS çoğunlukla açılır pencereler, durum çubuğunda kayan metinler vb. gibi can sıkıcı şeyler için kullanılıyordu. Firefox gibi tarayıcıların bu zararlılar için, makul varsayılanlara sahip kullanıcı denetimleri geliştirmiş olması iyi oldu. Netscape’in bu tür seçeneklere en baştan sahip olması gerekirdi.
Dili, başlangıçta amaçlanmayan bir şekilde kullanıldığını hiç gördünüz mü? Eğer öyleyse, neydi? Ve işe yaradı mı, yaramadı mı?
Yukarıda bahsedilen Java VM (Orto) buna bir örnektir. JS’nin Google Web Toolkit (GWT) gibi ya da (GWT’den önce) HaXe ve benzeri kod üreticileri için bir “hedef” dil olmasını amaçlamamıştım; bunlar farklı bir kaynak dili alıp, “nesne” ya da “hedef” çalıştırılabilir dil olarak JS üretirler.
Kod üretici yaklaşımı, JS’yi sunucu tarafında yazılmış yüksek seviyeli bir kaynak dil ile, tarayıcıda JS’yi gerçekleştiren optimize edilmiş C ya da C++ kodu arasında güvenli bir orta seviye ara dil olarak kullanır. Bu, JS motoru kodundaki farklı performans yollarını zorlar ve potansiyel olarak insan kodlayıcıların çoğu için uygun olmayan özelliklerin ECMA standardına eklenmesi yönünde baskı oluşmasına neden olur.
- http://ejohn.org/blog/ruby-vm-in-javascript
- Orto, bkz. http://ejohn.org/blog/running-java-in-javascript (uyarı: Java VM’nin ne kadarının JS içinde gerçekleştirildiğinden emin değilim—yine de her açıdan etkileyici bir başarı)
Farklı bir kaynak dili kullanan derleyiciler ve çalışma zamanları tarafından yapılan JS kod üretimi, JS performansının yeterince iyi olması ve giderek iyileşmesi anlamında işe yarıyor gibi görünüyor; ayrıca herkes tarayıcıda JS’yi hedefleyerek “erişimi” en üst düzeye çıkarmak istiyor. Ancak JS’nin büyük çoğunluğu elle yazılıyor ve bunun uzun süre böyle kalmasını bekliyorum.
Görünüşe göre birçok siteler arası betikleme (XSS) açığı JavaScript’i içeriyor. Bu konuda ne hissediyorsunuz? Bu sorunların bazılarını çözmek için planlar var mı?
Evet, bunları ele almak için planlarımız var; hem W3C dâhil standart kuruluşları aracılığıyla hem de Web geliştiricilerin ince taneli biçimde dayatabileceği içerik kısıtlamaları yoluyla. Şu belgeye bakın: http://www.gerv.net/security/content-restrictions
ve bu kısıtlamaları gerçekleştirmek için Mozilla hata takip çalışmaları: https://bugzilla.mozilla.org/show_bug.cgi?id=390910.
JavaScript’in bir sonraki sürümünün ne zaman yayımlanmasını bekliyorsunuz? Dâhil edilecek herhangi bir iyileştirme düşünüyor musunuz?
ECMA-262 standardının 3.1 sürümünün 2009 ortalarına kadar tamamlanmasını bekliyorum ve bunun ardından bir yıl içinde uyumlu bir 4. büyük sürümün gelmesini umuyorum. Belirli bir tarihe kadar şartnamelerin hukuken onaylanmasına acele edilmesindense, şartnamenin yeni sürümlerinin birden fazla birlikte çalışabilir prototip gerçekleştirimle kanıtlanmasının daha önemli olduğunu düşünüyorum (ve komitedeki neredeyse herkesin de böyle düşündüğüne inanıyorum). Ancak 3.1 çalışması yakın vadede başarılabilir görünüyor ve uyumlu bir ardıl olarak büyük bir 4. sürümün bir ya da iki yıl içinde başarılabilir olması gerekir.
3.1 çalışmasındaki iyileştirmeler; hata düzeltmelerine, SpiderMonkey gibi motorlarda geliştirilmiş fiili standartlara (ör. getter ve setter’lar) ve diğer tarayıcılarda tersine mühendislikle uygulanmış özelliklere, ayrıca daha yüksek bütünlüğe sahip nesneler ve özellikler tanımlamaya yönelik imkânlara (genişletilemeyen nesneler, üzerine yazılamayan özellikler vb.) odaklanıyor.
3.1’i izleyen uyumlu büyük sürümdeki iyileştirmeler ise 3.1 eklemelerinin üzerine inşa edilir ve kullanılabilirliğe (yeni sözdizimi dâhil), modülerliğe, ek bütünlük özelliklerine ve genel olarak mevcut dilde büyük ölçekli programlama sorunlarına çözümlere odaklanır.
Web 2.0’da JavaScript’in yeri hakkında ne düşünüyorsunuz?
JS’nin Ajax ya da Web 2.0 devrimi için vazgeçilmez olduğu açık. Firefox, Safari ve yeniden canlanan tarayıcı rekabetinin, ayrıca bunların tetiklediği Web standartları faaliyetlerinin de önemli olduğunu söyleyebilirim.
Gerçek programlar tarayıcılarda da çalışır ve JS ile yazılır. Ancak tüm bu ilerlemenin gerçekleşmesi için, Microsoft tarafından yeni milenyumun ilk beş yılı boyunca neredeyse hiç bakımı yapılmayan eski Internet Explorer sürümlerinde (IE 5.5, IE 6) bile JS’nin yeterince yetenekli olması bir ön koşuldu. Yani JS kök nedendi.
Yıllar boyunca JavaScript’e yönelik dile getirilen tüm olumsuz havalar hakkında ne düşünüyorsunuz?
Bu havalar bana şu unsurların bir karışımı gibi görünüyor:
- HTML içine gömülü bir betik dili fikrine yönelik erken itirazlar.
- JS’nin mümkün kıldığı can sıkıcı özelliklerin (ve Firefox gibi tarayıcılar gelene kadar açılır pencereler üzerinde olduğu gibi makul denetimlerin olmamasının) yerinde reddi.
- Tarayıcılar arasındaki DOM uyumsuzluklarının, geliştiricilere acı çektirmesiyle, genelde çok daha uyumlu olan JS gerçekleştirimlerinin (daha az ama sıfır olmayan) sorun çıkarmasının birbirine karıştırılması.
- Ve elbette, bazı insanlar hâlâ dilin JavaScript olarak adlandırılmasının, Java ile bir bağlantı ima eden Netscape pazarlama numarası hakkında olumsuz hissediyor; bu, kasıtlı olarak JS ile Java arasında kafa karışıklığı ekmiş olabilir (kayıtlara geçmesi için: Netscape’te kimsenin böyle bir kafa karışıklığı eklemeyi amaçladığına inanmıyorum).
Bu olumsuz havalar anlaşılabilir. JS, Web ölçeğinde (diğer tüm platformlardan daha geniş), birden çok işletim sisteminde ve birçok rakip tarayıcıda birlikte çalışmak zorunda olan tek programlama dili örneğidir. Tarayıcı eklentileri tarafından desteklenen diğer programlama dilleri tek satıcıdan gelir; bu satıcılar, uygulamayı tek kaynaktan geliştirerek birlikte çalışabilirliği daha iyi denetleyebilir. Bu nedenle JS ve denetlediği DOM, Web geliştiricileri için zorlu bir birlikte çalışabilirlik yolculuğu olmuştur.
Netscape ile Microsoft’un, öfkeli bir yenilik döneminden sonra erken standartlaşmayı zorlayan ve IE tekelinin altında JS ve diğer Web standartlarının çok uzun yıllar ihmal edilmesiyle sonuçlanan bir tarayıcı savaşı vermesi de yardımcı olmadı.
Olumlu tarafta ise birçok geliştirici JS ile programlamayı sevdiğini söylüyor ve 2004’ten, Web 2.0 ya da Ajax programlamanın ortaya çıkışından bu yana gerçek bir rönesans yaşadı.
JavaScript ve diğer istemci tarafı betik dillerinin Web üzerindeki gelecekteki etkisinin ne olacağını düşünüyorsunuz?
JavaScript’in bir süre daha tarayıcılarda varsayılan ve tek zorunlu programlama dili olacağını düşünüyorum.
Ancak diğer diller de desteklenecek; önce bir ya da başka bir tarayıcıda, sonunda tarayıcılar arası standart biçimlerde.
Firefox dâhil Mozilla tarayıcıları isteğe bağlı olarak C-Python entegrasyonunu destekler, ancak bunu kendiniz derlemeniz ve kullanıcılarınızın C-Python çalışma zamanına sahip olduğundan emin olmanız gerekir. Popüler dilleri güvenli, uyumlu ve güncel çalışma zamanı kodunun otomatik indirilmesiyle desteklemek için daha iyi yollar üzerinde çalışıyoruz.
Web standartlarının istemci tarafının programlanabilirliği hak ettiği açıktır; Marc Andreessen ile 1995’te böyle öngörmüştük. Dünyadaki masaüstü ve mobil bilgisayarlar, yararlı işler yapmak için yeterince çevrime ve depolamaya sahiptir (bugün her zamankinden daha fazla); otomasyon yeteneklerini, yalnızca form göndermeye ya da Web sunucularında çalışan gerçek programlara mesaj göndermeye indirgemek zorunda kalmadan.
Gerçek programlar tarayıcılarda da çalışır ve JS ile yazılır.
JS’nin etkisi yalnızca artıyor; çünkü yalnızca tarayıcıda değil, masaüstünde ve iPhone gibi cihazlarda da betikleme standardı hâline geliyor.
SproutCore ve Objective-J/Cappuccino gibi JavaScript çerçevelerinin yakın zamanda yayımlanması hakkında ne düşünüyorsunuz? Bunların Web uygulamalarının geleceği üzerinde nasıl bir etkisi olacağını düşünüyorsunuz?
Apple’ın abartı makinesi, bazı insanların bunlara Ajax’ın ikinci gelişi gibi davranmasına kesinlikle yol açtı. Bana göre bunlar, Google GWT ve Dojo, jQuery, YUI ve Prototype gibi popüler kütüphaneleri de içeren, gelişen JS kütüphaneleri ve çerçeveleri sürekliliğinin bir parçası. Yıllar boyunca, hatta o zaman bile yalnızca Web’in bazı bölümlerinde, tek bir kazananın her şeyi almasını özellikle beklemiyorum. Elbette bazı cihazlarda fiilen seçeneğiniz olmayabilir, ancak Web, ne kadar popüler olursa olsun, tek bir cihazdan daha geniştir.
Masaüstü uygulamalarının yok oluşunu görmemiz muhtemel mi?
Hayır, ancak Web teknolojileri kullanılarak yazılan daha fazla masaüstü uygulaması göreceğinizi düşünüyorum; Web sunucusunda barındırılmasalar bile. Ve elbette Web uygulamaları çoğalmaya devam edecek. JS’nin ve diğer tarayıcı tabanlı Web standartlarının evrimiyle, daha önce yalnızca masaüstü uygulamalarıyla yapılabilen etkileşimleri ve performans marifetlerini gerçekleştirebilen Web uygulamaları göreceğiz. En yeni tarayıcı nesillerinde çevrimdışı destek, canvas 2D ve 3D çizim vb. ile bunu şimdiden görüyoruz.
Flash gibi eklentilerin artan popülerliğinin JavaScript’in popülerliğini nasıl etkileyeceğini düşünüyorsunuz?
Flash, JS’den betiklenebilir olmak ve URL’ler kullanılarak adreslenebilir olmak—yani eklentiler, resimler veya tablolar gibi yerleşik nesneler ya da tamamen JS nesneleri olsun, sayfadaki diğer bileşenlerle birlikte bir bileşen olmak—konusunda iyi bir Ajax vatandaşı olmak için üzerine düşeni yapıyor. Açık Web her şeyi yukarı doğru eşitler ve tek satıcıya kilitlenmeye karşı durur. Bunu, Flash’ın Web 2.0 dünyasında uyumlu çalışacak şekilde nasıl evrildiğinde görebilirsiniz; Microsoft’un Silverlight’ı da modern Web standartları dünyasına iyi entegre olmayı hedefler.
İnsanlar, tüm Web sayfasını ve kullanıcı deneyimini denetleyen, tescilli tek satıcılı eklentilere dönüşten korkuyor; ancak bunun Web’in her yerinde olacağından şüpheliyim.
Birincisi, öncü tarayıcılardaki Web standartları; video, animasyon, yüksek performanslı JS ve benzeri alanlarda Flash ve Silverlight ile rekabet edecek şekilde evriliyor.
İkincisi, hiçbir Web sitesi “gösteriş” uğruna “erişimden” vazgeçmez ve eklentiler, JS gibi tarayıcıda yerel olarak gerçekleştirilmiş Web standartlarına kıyasla her zaman daha az erişime sahiptir. Kullanıcılar eklentilerini her zaman güncellemez ve kullanıcılar tarayıcılara güvenmeye ve onları kullanmaya devam ederken eklentileri reddeder.
JavaScript’in geleceğinin nerede yattığını öngörüyorsunuz?
Elbette tarayıcıda, ama bunun ötesinde de; sunucularda ve uçtan uca bir programlama dili olarak (daha geleneksel masaüstü ya da işletim sistemi betikleme rollerinin yanı sıra).
Hâlâ (bir zamanlar söylediğiniz gibi) “ECMAScript her zaman, bir deri hastalığı gibi kulağa gelen, istenmeyen bir ticari addı” diye düşünüyor musunuz?
Bunu pek düşünmüyorum, ama evet: arzu edilen bir ad değil ve biraz egzama gibi kulağa geliyor.
ECMA-262’nin Ekim 2008’e kadar hazır olmasını hâlâ bekliyor musunuz? Yeni sürümün geriye dönük uyumsuz olmasını bekliyor musunuz?
Eğer ECMA-262’nin 4. Sürümünü kastediyorsanız, hayır: bunu 2008’de beklemiyoruz ve şu anda sorumlu teknik komite (ECMA TC39), hem yakın vadeli (İlkbahar 2009) bir 3.1 ECMAScript sürümü hem de daha kapsamlı (ama çok büyük olmayan) bir takip sürümü için—ki buna 4. sürüm diyoruz—önerileri uyumlu hâle getirmek üzere birlikte çalışıyor.
JS’nin evrimi ve popülerliği sizi herhangi bir şekilde şaşırttı mı?
Popülerliği beni şaşırttı. Uzun süre, can sıkıcı açılır pencereler yüzünden JS’nin sevilmemesine razıydım; ama daha da önemlisi, işlevsel ve prototip tabanlı nesne programlama geleneklerinin alışılmadık birleşimi nedeniyle. Ancak ortaya çıktı ki, programcılar—kimileri programlamaya JS ile başlayanlar, kimileri geçmişin işlevsel ve dinamik OOP dillerinde deneyimli olanlar—bu alışılmadık karışımı gerçekten seviyor.
JavaScript’in ilk geliştirilmesinde ve süregelen kullanımında en çok neyle gurur duyuyorsunuz?
Birinci sınıf fonksiyonlar ile nesne prototiplerinin birleşimi.
Mükemmel olduğunu söylemem; özellikle standartlaştırıldığı hâliyle (hatalar eklendi ve standartlaştırma ile büyütüldü). Ancak acele etmenin yol açtığı aksaklıklar ve kalıntılar bir yana, temel kavramlar bunca yıl sonra hâlâ oldukça iyi bir bütün oluşturuyor.
Bilgisayar programlama dillerinin gelecekte, özellikle önümüzdeki 5 ila 20 yılda, nereye gittiğini görüyorsunuz?
Hepimizin karşı karşıya olduğu ve daha iyi programlama dilleri gerektiren iki büyük sorun var:
- Çok çekirdekli/aşırı paralel bilgisayarlar, masaüstünde şimdiden hayatımızda ve yakında mobil cihazlara da geliyor. Bilgisayar bilimciler, paralel hesaplamayı daha kolay ve daha kullanılabilir hâle getirme konusunda son 15 yıldaki ilerleme eksikliğini telafi etmeye çalışıyor. JS’nin çok çekirdekli dünyayı ele almada oynayacağı bir rol var; Google Gears’ın işçi havuzları gibi nispeten basit uzantılarla başlayarak—tarayıcı JS’sinin mesaj gönderip alarak iletişim kurduğu, paylaşımı olmayan arka plan iş parçacıkları.
- Güvenlik. Bir programlama dili tek başına güvenliği oluşturamaz ya da garanti edemez; çünkü güvenlik, dilin üstündeki ve altındaki tüm soyutlama seviyelerini kapsayan, uçtan uca ya da sistem özellikleri kümesidir. Ancak bir programlama dili, kullanıcılarına güvenli sistemler inşa etmek ve dil içinde ifade edilebilen bu güvenlik özellikleri hakkında olguları kanıtlamak için kesinlikle daha iyi ya da daha kötü araçlar sunabilir.
Yeni yetişen programcılar için herhangi bir tavsiyeniz var mı?
Klasikleri çalışın: Knuth, Wirth, Hoare. Bilgisayar bilimi bir çark gibidir; akademik araştırma odağı açısından her 10–20 yılda bir döner. İlk günlerde keşfedilenlerin çoğu hâlâ geçerlidir. Elbette daha yakın zamanda da harika işler yapılmıştır, ancak görebildiğim kadarıyla öğrenciler yakın dönem çalışmalarına daha fazla maruz kalıyor ve geçmişin devlerine neredeyse hiç maruz kalmıyor.
Eklemek istediğiniz başka bir şey var mı?
Şu an yok, vaktim doldu ve işe geri dönmem gerekiyor!