Bilgisayar Mühendisleri Portalı

Microsoft API Savaşını Nasıl Kaybetti

Joel Spolsky,
13 Haziran 2004, Pazar

Bu makalenin orijinali İngilizce olarak How Microsoft Lost the API War (http://www.joelonsoftware.com/articles/APIWar.html) başlığıyla yayımlanmıştır.

Serkan Utku Öztürk tarafından çevrilmiştir

Şu teoriyi bugünlerde sıkça duyuyorsunuz: "Microsoft bitti. Linux masaüstünde bir sıçrama yapıp da web uygulamaları masaüstü uygulamalarının yerini aldığı an, güçlü hanedanlık yerle bir olacak."

Linux'un Microsoft için büyük bir tehdit olduğu konusunda haklılık payı olsa da, Redmond şirketinin ölümü hakkındaki tahminler şimdilik vakitsizdir. Microsoft, bankada inanılmaz miktarda nakit paraya sahiptir ve hala akıl almaz derecede karlıdır. Çökmeleri için çok uzun bir yolları var. Muhtemel bir tehlike içine girmek için on yıl boyunca her türlü yanlışı yapabilirler ama son dakikada bile kendilerini bir buz şirketi olarak baştan yaratabilirler... ve siz bunun farkına varmazsınız bile. Bu yüzden bir kenara fırlatıp atmak için o kadar aceleci davranmayın. 90'lı yılların başında herkes IBM'in tamamen tükendiğini düşünüyordu: mainframeler tarih olmuştu! Daha sonradan, Robert X. Cringely, mainframe devrinin 1 Ocak 2000 tarihinde biteceği tahmininde bulundu. COBOL ile yazılmış tüm uygulamalar çöktüğünde, insanlar kaynak kodları çoktan kaybolmuş bu uygulamaları düzeltmek yerine baştan yazacaklardı.

Peki, tahmin edin ne oldu. Mainframeler hala bizlerle beraber, 1 Ocak 2000'den beri hiçbir şey olmadı ve IBM, ucuz plastik telefonlar (http://www.google.com/froogle?q=ibm+cordless+telephone&btnG=Search+Froogle) da üretebilen deneyimli bir teknoloji danışmanlığı şirketi olarak kendini baştan yarattı. Bu yüzden, bir kaç bilgiden tahmin yürüterek Microsoft'un bittiği teorisini üretmek çok ciddi bir abartıdır.

Bununla birlikte, farkedilmediği için eksik anlaşılan bir hadise var: Microsoft'un stratejik hazinesi, Windows API yitirildi. Neredeyse, Microsoft'un tüm gelirlerinin kaynağını oluşturan, karsız ya da çok az kar eden bir çok ürünün zararını telafi eden, Microsoft'un tekel gücünün ve müthiş karlı Windows ve Office'in temel taşı olan Windows API artık yazılım geliştirenlerin ilgisini çekmiyor. Altın yumurtlayan tavuk ölmediyse de, kimsenin henüz farketmediği ölümcül bir hastalığa sahip.

Bir önceki paragrafımın kendini beğenmişliği için özür dilememe izin verin. Sanırım, Microsft'un stratejik mal varlığı Windows API hakkında durmadan yazı yazan bir bulvar gazetesi köşe yazarı gibi davranmaya başladım. Ne hakkında konuştuğumu anlatmak ve bunları savunmak bir kaç sayfamı alacak. Lütfen, tam olarak ne hakkında konuştuğumu açıklayana kadar, herhangi bir yargıya varmayın. Bu uzun bir makale. Windows API'nin ne olduğunu açıklayacağım, neden Microsoft'un en değerli malvarlığı olduğunu göstereceğim, nasıl yitirildiğini ve uzun vadede yaratacağı tahribatları anlatacağım. Büyük akımlardan bahsettiğim için, hem abartacağım hem de genelleştireceğim.

Yazılımcılar, Yazılımcılar, Yazılımcılar, Yazılımcılar

İşletim sisteminin tanımını hatırlayın? Bilgisayarın kaynaklarını yönetir ve bu sayede uygulamalar çalışır. İnsanlar işletim sistemlerine değil, işletim sisteminin çalıştırabildiği uygulamalara dikkat ederler. Kelime İşlemcileri. Anında Mesajlaşma Programları. Eposta. Paris Hilton resimlerine sahip web siteleri. Tek başına, işletim sistemleri işe yarar değildir. İnsanlar, işe yarar uygulamaları çalıştırmak için işletim sistemlerini alırlar.Ve işte bu yüzden, en işe yarar işletim sistemi en fazla sayıda işe yarar uygulama çalıştırabilendir.

Bunun mantıksal sonucu olarak, eğer işletim sistemi satmak istiyorsanız, yapmanız gereken en önemli şey yazılımcıların sizin işletim sisteminiz için yazılım geliştirmelerini sağlamaktır. Steve Ballmer'ın sahnede zıplayarak (http://www.ntk.net/ballmer/mirrors.html) "Yazılımcılar, yazılımcılar, yazılımcılar, yazılımcılar" diye bağırmasının da sebebi budur. Bu Microsoft için o kadar önemlidir ki, yazılım geliştirme araçlarını Windows'un yanında açık açık vermiyorlarsa eğer, bunun tek sebebi ters bir tepki yaratarak yazılım geliştirme aracı üreticilerine(tabii, hala kaldıysa) giden oksijeni kesmemektir, çünkü kendi platformlarında çalışan değişik yazılım geliştirme araçlarının olması yazılımcılar için son derece caziptir. Fakat, gerçekte ise Microsoft bu araçları bedavaya vermek istemektedir. Empower ISV (http://members.microsoft.com/partner/competency/isvcomp/empower/default.aspx)(Bağımsız Yazılım Üreticilerini Güçlendirme) programlarında, beş adet tam sürüm MSDN Universal(başka bir deyişle Flight Simulator dışındaki tüm Microsoft ürünleri) paketini sadece 375$'a alabilirsiniz. .NET dilleri'nin komut satırı derleyicileri ücretsiz .NET çalışma birimine dahildir... üstelik de bedava olarak. Aynı zamanda, C++ derleyicileri de ücretsizdir (http://msdn.microsoft.com/visualc/vctoolkit2003/). Borland gibi şirketleri tamamen ortadan kaldırmadan, yazılımcıları .NET platformunda yazılım geliştirmeleri için, gereken her konuda teşvik etmektedir.

Apple ve Sun Neden Bilgisayar Satamıyorlar?

Evet, elbette, bu biraz saçma: tabii ki Apple ve Sun bilgisayar satıyorlar, ama şirket ve ev bilgisayarı gibi en karlı iki pazara değil. Apple hala tek haneli pazar paylarında sürünürken, masaüstü bilgisayarlarında Sun olanlar ise sadece Sun'da çalışanlardır.(Lütfen burada geniş eğilimlerden bahsettiğimi anlayın, ve bu yüzden hiç kimse veya benzeri bir şey söylediğimde, aslında demek istediğim "10.000.000 kişiden daha az"dır.)

Neden? Çünkü Apple ve Sun Windows programlarını ya çalıştıramamakta ya da çok da işe yaramayan pahalı bir emulasyon modunda çalıştırmaktadır. Hatırlarsanız, insanlar, üzerinde çalışan uygulamalar için bilgisayar satın alırlar, ve Windows için böyle yazılım sayısı Mac'e göre çok daha fazladır, bundan dolayı Mac kullanıcısı olabilmek daha zordur.

Kenar Çubuğu Bu "API" denen şey nedir?

Eğer bir program, mesela bir kelime işlemcisi, yazarken bir menü göstermek, ya da bir dosyaya yazmak istiyorsanız, her işletim sisteminde farklı olan belirli bir fonksiyon grubunu çağırmak zorundasınızdır. Bu fonksiyonlara API(Uygulama Programlama Arayüzü) denir: Bir işletim sisteminin(ör. Windows) uygulama(ör. kelime işlemci, hesap çizelgesi gibi) geliştirenlere sağladığı bir arayüzdür. Programcıların kullanabileceği, işletim sistemine menü göstertmekten, dosya okutup yaztırtmaya, Sırpça bir tarihin nasıl yazılacağını göstertmek gibi uç durumlardan bir pencerede web sayfası göstertmek gibi karışık olaylara kadar bir çok iş yaptırabileceğiniz binlerce ama binlerce ayrıntılı fonksiyon ve altprogramlardan oluşur. Eğer programınız Windowsa ait API çağırıyorsa, farklı bir API'ye sahip olan Linux'ta çalışmaz. Eğer Linux altında da çalışan bir Windows programınız olsun istiyorsanız, binlerce karmaşık fonksiyona sahip olan Windows APIsini baştan yazmanız (http://www.winehq.com) gerekir: Bu Windows'u yazmak kadar iş gerektirir ki bu Microsoft'un binlerce adam-yılını almıştır. Ve eğer küçük bir hata yaparsanız ya da bir fonksiyonu unutursanız, bu tüm programınızı göçertir.

Ve Windows API'sinin Microsoft için önemli bir mal varlığı olmasının sebebi de budur.

(Biliyorum, biliyorum, şu anda dünyanın Macintosh kullanan %2,3'lük kısmı Maclerini ne kadar sevdiklerini anlatan sert bir mail yazmak için mail programlarını açıyorlar. Tekrar ederim ki, büyük eğilimler hakkında konuşuyorum ve genellemeler yapıyorum, bu yüzden boşuna vaktinizi harcamayın. Mac'inizi sevdiğinizi biliyorum. İhtiyacınız olan herşeyi çalıştırdığını biliyorum. Sizi seviyorum, ama dünyanın sadece %2,3'ünü oluşturuyorsunuz, bu yüzden bu makale size değil.)

Microsoft'taki İki Kuvvet

Microsoft içinde, gayri resmi olarak, Raymond Chen Kampı ve MSDN Magazine Kampı olarak adlandırabileceğimiz iki zıt kuvvet bulunmaktadır.

Raymond Chen, Microsoft'ta Windows ekibinde 1992'den beri çalışan bir yazılımcıdır. The New Old Thing (http://weblogs.asp.net/oldnewthing/) adlı weblogunda, belirli şeylerin, en saçma görünenlerin bile, Windows'ta niçin o şekilde yapıldığını çok iyi sebeplere dayanan ayrıntılı teknik hikayelerle anlatır.

Raymond'un weblogunda okuması en ilginç şeyler, Windows takımının geriyle uyumluluğu deskteklemek için yıllar boyunca verdiği inanılmaz eforları (http://weblogs.asp.net/oldnewthing/archive/2003/10/15/55296.aspx) anlatan hikayelerdir (http://weblogs.asp.net/oldnewthing/archive/2003/12/23/45481.aspx):

Şu senaryoyu müşterinin bakış açısından değerlendirin. X, Y ve Z programlarını satın alıyorsunuz. Daha sonra Windows XP'ye terfi ediyorsunuz. Bilgisayarınız rasgele zamanlarda çöküyor, ve Z programı hiç çalışmıyor. Arkadaşlarınıza "Windows XP'ye terfi etmeyin. Rasgele zamanlarda çöküyor, ve Z programıyla da uyumlu değil." diyorsunuz. Peki, Program X'in çökmeye sebep olduğunu ve program Z'nin de dökümantasyonu yapılmamış windows mesajları kullandığı için çalışmadığını belirlemek için sisteminizde hata ayıklar mısınız? Elbette hayır. Windows XP paketinizi para iadesi için geri getirirsiniz. (X, Y, ve Z'yi bir kaç ay önce almıştınız. 30-gün para iadesi bu ürünler için geçerli değil. Geri döndürebileceğiniz tek şey Windows XP.)

Bunu, ilk olarak popüler SimCity oyunun bir yazılımcısının, bana uygulamada kritik bir hata olduğunu söylediğinde duymuştum: bellekte bir alan, serbest bırakıldıktan hemen sonra kullanılmaya çalışılmış, kabul edilemez büyüklükteki bu hata DOS'ta sorun yaratmazken, Windows'ta bellek başka bir uygulama tarafından kullanılmaya çalışıldığı için işe yaramamış. Windows ekibinde test yapanlar popüler bir çok uygulamayı düzgün çalışmasını sağlarlarken, SimCity devamlı çökmüş. Bunu Windows yazılımcılarına rapor etmişler, program debugger ile açıldığında, hatayı bulmuşlar, ve SimCity'nin çalışıp çalışmadığını kontrol eden, ve eğer çalışıyorsa bellek yöneticisini bellek boşaltılsa bile kullanılabilecek bir modda çalıştırmaya yarayan özel bir kod eklemişler.

Bu alışılmamış bir durum değil. Windows test ekibi çok büyüktür ve en önemli sorumluluklarından biri de, insanlar, ister kötü işler yapan, ister dökümante edilmemiş kod kullanan, isterse Windows n versiyonunda hatalı ama Windows n+1 versiyonunda düzgün çalışan bir fonksiyonun hatalı davranışına güvenen herhangi bir uygulamayı kursalar da , işletim sistemlerini terfi ettirdiklerinde bunların çalışmalarını garanti etmektir. Eğer kayıt(registry) düzenleyicisinin AppCompatibility kısmını kurcalayacak olursanız, hatalı ya da beklenmedik şekilde çalışıp da Windows'un özel muamelede bulunarak çalışmalarını sağladığı programların listesini görürsünüz. Raymond Chen, "Özellikle, insanların işletim sistemi terfileri sırasında, bozulan uygulamaları için Microsoft'u suçlamalarına sinirleniyorum. Eğer herhangi bir uygulama Windows 95 üzerinde çalışmıyorsa, bunu o uygulamaya özgü bir yetersizlik olarak kabul ediyorum. Üçüncü parti uygulamaların Windows 95 üzerinde sorunsuz olarak çalışmalarını sağlamak için, bir çok geceyi hata ayıklayarak uykusuz geçirdim." diye yazar (http://weblogs.asp.net/oldnewthing/archive/2003/10/15/55296.aspx).

Bir çok yazılımcı ve mühendis bu tür çalışmayı onaylamaz. Eğer bir uygulama hatalı çalışıyorsa, ya da dökümante edilmemiş bir koda güveniyorsa, bunların işletim sistemi terfilerinde işe yaramaz hale gelmesi gerektiğini düşünürler. Macintosh işletim sistemindeki yazılımcılar da hep bu kampa dahil olmuştur. Macintosh'un ilk günlerinden beri sadece bir kaç uygulamanın hala çalışır olmasının sebebi budur. Örneğin, bir çok yazılımcı uygulamaları daha hızlı çalışsın diye, işlemcinin kesme özellğini kullanmaları gerekirken, işaretçileri atlama tablosuna(jumper table) kopyalayıp doğrudan çağırıyorlardı. Inside Macintosh, Macintosh'un resmi programlama kitabı, kitabının bir yerlerinde "bunu yapamazsınız" yazan teknik bir not varken, onlar yaptılar, başardılar ve programları daha hızlı çalıştı... ta ki işletim sisteminin yeni sürümü gelip de hiç biri çalışmaz olana kadar. Eğer bu programı yapan şirket artık piyasadan çekilmişse(bir çoğu çekildi), en iyisi bir bardak soğuk su için.

Tam tersine, 1983'te ilk çıkan IBM PC'leri için yazdığım DOS uygulamaları, Microsoft'taki Raymond Chen Kampı sayesinde hala sorunsuz bir şekilde çalışıyor. Elbette, bunun sadece Raymond Chen sayesinde olmadığını biliyorum: Bu, tüm çekirdek Windows API ekibinin işi. Fakat, Raymond bunu mükemmel web sitesi The Old New Thing (http://weblogs.asp.net/oldnewthing/) ile herkesle paylaştığı için bu adlandırmayı yaptım.

Bu, kamplardan biriydi. Diğeri ise benim, yazılım geliştiricileri dergisinin, yazılımınızda Microsoft ürünleri kullanarak kendinizi ayağınızdan vurmanın değişik yönlerini anlattığı gaza getirici makalelerinden sonra, MSDN Magazine kampı olarak adlandırdığım kamp. MSDN Magazine Kampı her zaman sizi yeni ve karmaşık harici teknolojileri kullanmaya ikna etmek için uğraşır: COM+, MSMQ, MSDE, Microsoft Ofis, Internet Explorer ve bileşenleri, MSXML, DirectX (son sürümü, lütfen), Windows Media Player, ve Sharepoint!... kimsenin sahip olmadığı SharePoint; müşteriye ürünü gönderip de doğru dürüst çalışmayacak, ve her biri büyük baş ağrılarına yol açacak gerçek bir harici bağımlılık silsilesi. Bunun teknik ismi DLL Cehennemidir. Burda çalışıyordu: neden orda çalışmasın?

Raymond Chen Kampı, bir kere yazıp her yerde çalıştırmayı kolaylaştırarak, yazılım geliştirenlerin işini kolaylaştırmaya inanır. (elbette, herhangi bir Windows üzerinde) MSDN Magazine Kampı, yazılımcıların işini, yararlanabilecekleri gerçek anlamda çok etkili kodları ellerine vererek kolaylaştırmaya inanır, tabi eğer gerçekten inanılmaz derecede karışık olan yükleme ve kurulum bedelini ödemeye, uzun bir öğrenme eğrisini ayrıca tekrar etmiyorum, hazırsanız. Raymon Chen kampında her şey birleştirme üzerinedir. Lütfen, işleri daha da zorlaştırmayalım, hali hazırda çalışır olanları çalışır halde bırakalım. MSDN Magazine kampı ise kimsenin kontrol altında tutamadığı yeni devasal teknoloji parçalarını karıştırmaya devam etsin.

Bu sorun neden önemli. İşte sebebi.

Microsoft Geriyle Uyumluluk Felsefesini Yitirdi

Microsoft içinde, MSDN Magazine kampı savaşı kazandı.

İlk büyük galibiyet Visual Basic.NET'i VB 6.0 ile uyumlu yapılmayarak kazanıldı. Bir Microsoft ürününü alıp da terfi ettirdiğinizde, eski verilerinizin (örneğin VB6'da yazdığınız kodlar) sessiz ve kusursuz bir şekilde aktarımının gerçekleştirilemediği ilk canlı örnek olarak hafızalarda yerini aldı. İlk defa Microsoft, ürünün bir önceki sürümünde yapılmış olan işlere saygı göstermedi.

Microsoft içinde, kubbe düşecek gibi görünmüyor. VB6 yazılımcıları silahlarıyla ayaklandı, ama buna rağmen sayıları her geçen gün azalmakta, çünkü bir çoğu kurumlar için çalışan ve hızla web ortamına geçmekte olan yazılımcılar. Uzun vadeli hasar gizli kaldı.

Koltuklarının altındaki bu zaferle birlikte MSDN Magazine kampı, kontrolü ele geçirdi. Birden, bir şeyleri değiştirmek için ortam uygun hale geldi. IIS 6.0, bazı eski uygulamaları çalışmaz hale getiren yeni bir kanal modeliyle geldi. Windows 2003 kullanan bazı müşterilerimizin FogBugz'ı çalıştırmakta sorun yaşadıklarını keşfettiğimde şok oldum. Ondan sonra, .NET 1.1 NET 1.0 ile tam uyumlu değildi. Ve nihayet sır perdesi de ortadan kalktı, bundan cesaret alan İşletim Sistemi ekibi de Windows API'ye yeni özellikler eklemek yerine, komple değiştirme kararı aldı. Bize anlatıldığına göre, Win32 yerine WinFX (http://www.gartner.com/DisplayDocument?doc_cd=118261)'e, yeni nesil Windows APIsi, hazırlanmaya başlamalıymışız. Herşeyiyle farklı. Yönetilen kod ile .NET tabanlı. XAML. Avalon. Evet, Win32'ye göre çok üstün olduğunu kabul ediyorum. Ama bir terfi değil: geçmişle ipleri koparma.

Windows geliştirmenin karmaşıklığından asla memnun olmamış yazılımcılar, Windows platformunu toptan terkettiler ve şimdi web için yazılım yapıyorlar. Paul Graham, internet patlamasının ilk zamanlarında Yahoo! Stores'u yaratan kişi, sivri bir dille durumu özetliyor (http://www.paulgraham.com/road.html): "Şu zamanda, yeni başlayanlar'ın web tabanlı program yazması için bir çok sebep var, çünkü masaüstü için yazılım geliştirmek artık daha az zevk vermekte. Eğer masaüstü uygulama geliştirecekseniz bunu Microsoft'un kurallarına göre yapmanız lazım, onların API'lerini kullanıp, onların arızalı işletim sistemlerinde çalışmalısınız. Ve eğer yeni başlamış bir teknolojiyle kod yazmaya çalışıyorsanız, tek yaptığınız şey Microsoft adına pazar araştırması yapmaktır."

Microsoft, çok sayıda yazılımcısıyla yeterince büyük ve karını arttırmaya mecbur, işte bu yüzden birden her şeyi baştan icat etmenin o kadar da büyük bir proje olmadığına karar verdi. Eski Microsoft, Raymond Chen'in Microsoft'u, Avalon gibi yeni grafik sistemlerini bir DLL serisi olarak yazardı ve hem tüm Windows sürümlerinde çalışır hem de istenilen her uygulamayla birleştirilebilirdi. Bunun yapılamaması için teknik bir sebep yok. Fakat Microsoft, size LongHorn satın almanız için bir sebep sunuyor ve aslında denemeye çalıştıkları da DOS'tan Windows'a geçişte yaşanan değişikliğin bir benzerini gerçekleştirmek. Sorun ise Windows XP'den LongHorn'a geçiş, Windows'tan DOS'a olan geçiş kadar büyük değil. Büyük ihtimalle, Windows için yeni bilgisayarlar ve uygulamalar almak zorunda kalan insanlar, bu sefer bunu yapmayacaklar. Kimbilir belki de yapacaklar, en azından Microsoft'un buna ihtiyacı var, ama şu ana kadar gördüklerim beni pek ikna etmiş değil. Bir çok iddiaya göre Microsoft yanlış yaptı. Mesela (http://weblog.infoworld.com/udell/2004/06/02.html#a1012), WinFS'in tanıtımı, dosya sisteminizi ilişkisel veritabanı(relational database) olarak kullanarak arama yapmanızı sağlayacak şeklindeydi, burda gözden kaçan ise bir aramayı çalışır hale getirmek, çalışır bir arama sistemiyle mümkündür. Bir sorgu dili kullanarak arama yapabileyim diye bana her dosyaya değişim verisi (metadata) ekletmek zorunda bırakmayın. Bana bir iyilik yapın ve girdiğim metni kahrolası hard diskte full-text indeks ya da 1973'ten beri kullanılmakta olan teknolojilerle bir an önce arayın.

Gün Otomatik İletimin Günü

Beni yanlış anlamayın... .NET'in harika bir yazılım geliştirme platformu olduğunu düşünüyorum ve XAML ile Avalon da eski tarz Windows grafik arayüzü yazmaya göre olağanüstü bir gelişme. .NET'in en büyük getirisi ise otomatik bellek yönetimine sahip olmasıdır.

90'lı yıllarda bir çoğumuz büyük mücadelenin prosedürel dillerle nesne tabanlı diller arasında olacağı fikrindeydi ve nesne tabanlı dillerin programlama üretkenliğine büyük ivme kazandıracağını düşünüyorduk. Benim de fikrim bu yöndeydi. Bazıları hala böyle düşünüyor. Görünen o ki yanıldık. Nesne tabanlı programlama çok kullanışlı, ama üretkenliğe umut edilen ivmeyi kazandıran o değil. Gerçek anlamda, üretkenlikteki farkedilir sıçrama bellek yönetimini otomatik olarak yapan dilleri kullanmamızla başladı. Bu referans sayma(reference counting) ya da çöp toplama(garbage collection) ile olabilir; Java, Lisp, Visual Basic(1.0 dahil), Smalltalk, ya da herhangi bir script diliyle olabilir. Eğer kullandığınız programlama dilinde, bellek kullanıp da işiniz bittiğinde bunu nasıl serbest bırakacağınızı düşünmenize gerek kalmıyorsa, bellek yönetimli bir dil kullanıyorsunuz demektir, ve bellek yönetimini harici olarak yapmanız gereken dillere göre çok daha verimli olursunuz. Kullandıkları dilin ne kadar üretken olduğuyla övünen birini duyarsanız, büyük ihtimalle üretkenliklerine en fazla katkıda bulunan, yanlış atıfta bulunsalar bile, otomatik bellek yönetimidir.

Kenar Çubuğu
Otomatik bellek yönetimi sizi neden daha üretken yapar? 1) Çünkü, f(g(x))'i g'nin geri dönüş değeri nasıl serbest bırakılacak diye kaygılanmadan yazabilirsiniz, ki bunun anlamı kompleks veri tipleri döndüren ya da bunları dönüştüren fonksiyonları daha üst seviyeli soyutlamayla kullanabilmektir. 2) Çünkü, zamanınızı bellek boşaltmak ya da bellek kayıplarını kontrol etmek için kod yazmakta kaybetmezsiniz. 3) Çünkü, fonksiyonunuzda her şeyin düzgün bir şekilde temizlenmesini sağlamak için çıkış noktaları ayarlamak zorunda kalmazsınız.

Yarış arabası müptelaları bana sitem yüklü epostalar yollayacak olsalar da, tecrübelerime dayanarak söylüyorum; otomatik vitesin düz vitesten aşağı kaldığı tek yer normal sürüş modudur. Yazılım geliştirmede de benzer olarak: hemen hemen her koşulda otomatik bellek yönetimi harici bellek yönetimine göre kat kat daha iyidir ve çok daha fazla üretkenlik sağlar.

Windows'un ilk yıllarında masaüstü uygulamaları geliştirdiyseniz eğer, Microsoft'un bunun için iki değişik önerisi vardı: doğrudan Windows API kullanıp, belleği de kendiniz yöneterek C ile yazmak, ya da Visual Basic kullanarak belleğinizin yönetilmesini sağlamak. Şahsen son 13 yıldan beri en çok bu iki yazılım geliştirme ortamını kullanıyorum, ikisinin de içini dışını biliyorum, ve tecrübeme göre Visual Basic açık ara daha verimli. Sık sık aynı kodu Windows API kullanarak hem C++'ta, hem de Visual Basic'te yazarım, ve C++ üç ya da dört kat daha fazla emek gerektirir. Neden? Bellek yönetimi. Bunu görmenin en iyi yolu, dizgi döndüren bir Windows API fonksiyonunun dökümantasyonuna göz atmaktır. Konuya biraz daha eğilip, dizgi için kimin yer ayırması gerektiği, ne kadar yer ayrılması gerektiği konusunda ne kadar çok tartışma olduğunu görün. Genellikle, fonksiyonu iki kere çağırmanız gerekir - ilk çağırmada, 0 bayt ayırdığınızı belirtirsiniz, daha sonra "yeteri kadar bellek ayrılmadı" mesajıyla işleminiz başarısız olur ve fonksiyon bu yolla ne kadar bellek ayırmanız gerektiğini söyler. Bu, dizgi listesi ya da değişken-uzunluklu yapı döndüren bir fonksiyon çağırmadığınız şanslı bir durumdur. Her koşulda, dosya açıp, içine bir dizgi yazıp, sonra da kapamak Windows API kullanarak bir sayfa kod gerektirir. Visual Basic'te buna benzer bir işlem üç satır kodla olur.

Öyleyse, elinizde programlama ile ilgili iki dünya var. Bellek yönetimli dünyanın, olmayanına göre üstün özelliklere sahip olduğu öyle ya da böyle herkes tarafından kabul edilmiş durumda. Visual Basic, içinde "Basic"(temel) kelimesinin geçmesine, fanatik programcıların uzak durmasına rağmen, nesne tabanlı bir çok özelliğe sahip, tüm zamanların en iyi satan programlama diliydi (ve büyük ihtimalle öyle kalacak), ve yazılımcılar Windows yazılımları geliştirmede onu C ve C++'a tercih ettiler. VB'nin sorunu ise dağıtım esnasında, modem ile yüklenmesi büyük sorunlara yol açan, VB Çalıştırma Birimine ihtiyaç duymasıydı. Ve bir de, daha kötüsü, diğer yazılımcıların sizin uygulamayı Visual Basic ile yaptığınızı (yazık!) farketmeleriydi.

Hepsini Yönetecek Tek Çalışma Birimi

Ve geldik .NET'e. Bu büyük proje, tüm karışıklığı herkes için toptan temizlemeyi amaçlayan birleştirici bir projeydi. Bellek yönetimine sahip olacaktı, elbette. Visual Basic yine olacak , ama yanına aslında Visual Basic ruhuna sahip ama C'ye benzer sözdizimi olan, kıvırcık parantezlere ve noktalı virgüllü yeni bir dil de eklenecekti. Ve en güzeli de, Visual Basic/C karması bu yeni dilin adı Visual C# olacaktı, böylece kimseye "Basic" programcısı demek zorunda kalmayacaktınız. Kuyruklu ve kancalı o korkunç Windows fonksiyonları, ne tür bir dizgi döndürdüğünü anlamanın imkansız olduğu< semantikler kalkacak, yerine sadece bir çeşit dizgisi olan nesne tabanlı yeni bir arayüz gelecekti. Hepsini yönetecek tek bir çalışma birimi. Harikaydı. Ve teknik olarak hayata geçirildi. .NET, belleğinizi yöneten, işletim sistemine zengin, eksiksiz ve tutarlı bir arayüz sağlayan ve basit operasyonlar için zengin, tam anlamıyla eksiksiz ve şık bir nesne kütüphanesi içeren harika bir programlama ortamıdır.

Ve şu ana kadar, insanlar hala gerçek anlamda .NET'i kullanmıyorlar.

Elbette, bazıları kullanıyor.

Fakat, tamamiyle baştan aşağı yeniden tasarlanmış, içinde bir değil, iki değil, tam üç tane(yoksa dört mü?) dil bulunan, Visual Basic ve Windows API programlamanın tüm düzensizliğini temizleyip birleştirecek bir programlama ortamını tasarlama fikri, kavga eden iki çocuğu ayırmak için ikisine birden "kapayın çenenizi!" diye bağırmaya benziyor. Bu sadece televizyonda işe yarar. Gerçek hayatta, gürültülü bir şekilde tartışan iki kişiye "kapayın çenenizi!"diye bağırırsanız, gürültüyü üç taraflı olarak arttırmış olursunuz.

(Aklıma gelmişken belirteyim, az kişi tarafından bilinen ama politik kutuplaşmanın yaşandığı blog besleme formatlarından haberdarsanız, burada da aynı durumu görebilirsiniz. RSS yetersiz tanımlamalar, bir çok politik kavga, farklı farklı sürümler yüzünden parçalara bölündü, bütün bunları temizlemek için yaratılan Atom adlı bir başka format; bir sürü RSS formatı artı bir tane Atom formatı, yetersiz tanımlamalar, ve bir çok politik kavgayla sonuçlandı. Ne zaman zıtlaşan iki kuvveti birleştirmek için üçüncü bir format önerseniz, bu birbirlerine zıt üç kuvvetin ortaya çıkmasına neden oluyor. Hiç bir şey birleştiremeyip, hiç bir şey onarmamış oluyorsunuz.)

Yani şu an, .NET'in birleştirmesi ve basitleştirmesi yerine, herkesin hangi yazılım geliştirme stratejisini kullanmaya karar vermeye çalıştığı, ve mevcut uygulamalarını .NET'e geçirmeye güçlerinin yetip yetmeyeceğini tarttığı, 6 farklı belaya sahibiz.

Microsoft'un pazarlamada verdiği mesaj ne kadar tutarlı olursa olsun(sadece .NET kullanın - bize güvenin), müşterilerinin bir çoğu hala C, C++, Visual Basic 6.0, klasik ASP ve bir kez daha tekrar etmeye gerek duymadığım diğer şirketlere ait yazılım geliştirme araçlarını kullanıyorlar. .NET kullananlar da ASP.NET kullanıyorlar, o da Windows sunucu üzerinde çalışan ama Windows istemci gerektirmeyen web uygulamaları geliştirmek için. Web hakkında konuşurken bu konu hakkında daha fazla duracağım.

Bekleyin, Dahası var!

Microsoft'ta dingili yerinden fırlamış o kadar çok yazılımcı var ki, bunlara tüm Windows API'yi baştan icat etmek yetmiyor: iki kere icat etmeleri lazım. Geçen yılın PDC'sinde sıradaki işletim sistemlerinin, kod adı Longhorn, diğer şeylerin yanında günümüz modern bilgisayarların hızlı görüntü bağdaştırıcılarının, ve gerçek zamanlı 3D çeviricilerinin gücünden faydalanan Avalon kod adlı, tamamıyla yeni bir kullanıcı arayüzüyle geleceğini ilan ettiler. Ve eğer Microsoft'un resmi olarak en son ve en harika Windows programlama ortamıyla, WinForms, Windows GUI geliştiriyorsanız, Longhorn ve Avalon'u desteklemek için iki sene içinde her şeye baştan başlamak zorunda kalacaksınız. WinFormsun neden ölü doğduğunu açıklıyor. Umarım bunun üzerinde çok fazla yatırım yapmamışsınızdır. John Udell, üzerinde "Windows Forms ile Avalon arasında nasıl seçim yapacağım?" yazan Microsoft etiketli bir slayt bulur ve sorar (http://weblog.infoworld.com/udell/2004/06/09.html#a1019) "Neden Windows Forms ve Avalon arasında seçim yapmak zorunda olayım ki?". Güzel bir soru, ama asla tatmin edici bir cevap alamayacak.

Windows API'ye sahipsiniz, VB'niz var, farklı dil destekleriyle .NET'iniz de oldu, ama bunlara çok bağlanmayın, çünkü sadece Microsoft'un en yeni işletim sistemlerinde çalışacak ve bu yüzden çok uzuuuuun süre kimsede olmayacak Avalon'u yapmaktayız. Şahsen, derinlemesine .NET öğrenecek zamanım olmadı ve Fog Creek'in klasik ASP ve VB'de yazılmış iki ürününü .NET'e taşımadık, çünkü yatırımımızın geri dönüşü olmayacak. Hem de hiç. Anladığım kadarıyla, bu sadece bir Ateş et ve Saldır (http://www.joelonsoftware.com/articles/fog0000000339.html) taktiği: Microsoft, benim hata takip programıma, içerik yönetim programıma yeni özellikler eklemeyi bırakmamı, bunun yerine bir kaç ayımı yeni programlama ortamına geçiş için harcamamı istiyor, öyle bir şey ki bundan hiç bir müşterimin kazancı olmayacak, bu yüzden bize ek satış sağlamayacak, tamamen boşa gidecek bir kaç ay. Bu tabii Microsoft için harika bir şey, çünkü onların da içerik yönetim programı, hata takip programı var, arı gibi günün çiçeğini yakalamak için önce bir kaç boş tur atacağım, sonra da Avalon sürümünü yapmak için bir-iki yılımı da harcayacağım, onlar da bu süre zarfında rekabetçi ürünlerine yeni özellikler ekleyecekler. Ayneeeen.

Microsoft'ta bir sürü süper kişi yazılım geliştirme araçları yaptı diye sadece, günlük işi olan hiç bir yazılımcı Redmond'dan gelen her yeni yazılım geliştirme aracını denemek için zaman ayıramaz.

Yıl 1990 değil

Microsoft 1980 ve 1990 yılları boyunca büyüdü, kişisel bilgisayarlardaki büyüme o kadar hızlıydı ki her sene mevcut olan toplam bilgisayardan daha fazlası satılıyordu. Bunun anlamı, yaptığınız program, sadece yeni bilgisayarlarda çalışsa bile bir ya da iki sene içinde kimsenin sizin ürününüze geçmesine gerek kalmadan tüm dünyayı kontrolü altına alabilirdi. Word ve Excel'in WordPerfect ve Lotus'un yerini almasının sebeplerinden biri de buydu: Microsoft, sıradaki büyük donanım terfisini bekledi, ve firmaların yeni satın alımlarında onlara Windows, Word ve Excel'i sattı.(bazı durumlar için ilk satın alımlarında) İşte, bir çok sebepten ötürü kurulu bir düzeni N ürününden N + 1 ürününe geçirmeyi nasıl becereceğini öğrenmeye hiç ihtiyacı olmadı. İnsanlar yeni bilgisayar aldıklarında, yeni bilgisayarlarına en son çıkan Microsoft ürünlerini almaktan memnundular, ama nispeten çok daha az kişi terfiye olumlu bakıyordu. PC Endustrisi hızla büyüdüğünden bu önemli değildi, ama şimdi dünya bilgisayara doymuş durumda, ve Microsoft birden son ürünlere geçişin daha uzun zaman alacağını farketti. Windows 98'in hayatını sonlandırmayı denediklerinde, bir çok insanın hala bunu kullandığı ortaya çıktı ve gıcırdayan yaşlı büyükanneye bir kaç yıl daha bakmaya söz verdiler (http://www.windows-help.net/microsoft/98-lifecycle.html).

Herkes 1998'den beri kullandığı bilgisayarı kullanmaya devam ederse, yeni bir API yaratıp insanları kendine bağlamak isteyen .NET, Longhorn ve Avalon gibi Cesur Yeni Stratejiler, maalesef pek işe yaramayacakmış gibi görünüyor. Umulduğu gibi Longhorn 2006 yılında piyasaya çıkarsa, ki zerre kadar inancım yok, yeteri kadar insan tarafından yazılım geliştirmeye değer bulunması bir kaç yılı alacak. Yazılımcılar, yazılımcılar, yazılımcılar, yazılımcılar, Microsoft'un nasıl yazılım geliştirmemiz gerektiği konusundaki çoğul kişilik bozukluğu taşıyan önerilerini dinlemiyorlar.

Web'e Buyrun

Web'den bahsetmeden buraya kadar nasıl gelebildiğimi bilmiyorum. Her yazılımcının yeni bir yazılımı planlarken yapması gereken bir seçim vardır: web'de çalışan bir uygulama inşa etmek ya da PClerde çalışan bir "zengin istemci"(rich client) uygulaması geliştirmek. Temel getiri ve götürüleri açıktır: Web uygulamalarının yüklenmesi kolayken, zengin istemciler daha hızlı tepki zamanlarıyla çok daha ilgi çekici kullanıcı arayüzlerine izin vermektedir.

Web Uygulamalarının yüklenmeleri daha kolaydır çünkü herhangi bir kurulum gerektirmezler. Bir web uygulamasını yüklemek demek adres çubuğuna URLsini yazmak demektir. Bugün, Google'in yeni e-posta uygulamasını Alt+D, gmail, Ctrl+Enter yazarak kurdum. Uyuşmazlık ve mevcut diğer uygulamalarla problemleri çok çok azdır. Ürününüzü kullanan her kullanıcı aynı sürümü kullanır ve bu yüzden asla eski sürümlere destek vermek zorunda kalmazsınız. İstediğiniz herhangi bir programlama ortamını kullanabilirsiniz, çünkü sadece uygulamanızı ayağa kaldırıp kendi sunucunuzda çalıştırmanız yeterlidir. Uygulamanız otomatikman gezegendeki hemen hemen her bilgisayarda erişilebilir hale gelir. Müşterilerinizin bilgisi de otomatikman gezegendeki hemen hemen her bilgisayarda erişilebilir hale gelir.

Fakat kullanıcı arayüzünün pürüzsüzlüğü konusunda ödenmesi gereken bir bedel vardır. İşte size, web uygulamalarında yeteri kadar iyi yapamayacağınız şeylere bir kaç örnek:

1. Hızlı bir çizim programı yaratmak
2. Dalgalı kırmızı altçizgiler çizebilen gerçek zamanlı imla denetimcisi yapmak
3. Kullanıcıları, tarayıcının kapama kutusuna basarlarsa çalışmalarını kaybedecekleri uyarısında bulunmak
4. Fare gerektirmeyen, klavyeden yönlendirilen bir arayüz yaratmak
5. Internete bağlı değilken de insanların çalışmasına imkan sağlamak

Bunların hepsi de büyük sorunlar değil. Bir kısmı zeki Javascript yazılımcıları tarafından kısa sürede çözülecek. İki yeni web uygulaması, Gmail (https://gmail.google.com) ve Oddpost (http://www.oddpost.com), her ikisi de eposta uygulaması, gerçekten tatmin edici iş çıkartarak sorunların bir kısmını dolaylı ya da komple çözümlerle aştılar. Ve kullanıcılar, web arayüzünün yavaşlığına ya da kullanıcı arayüzündeki ufak tefek pürüzlere aldırıyorlarmış gibi durmuyor. Bazı sebeplerden dolayı zengin istemcilerin ne kadar zengin olduğu konusunda ikna etmeye uğraşsam da, tanıdığım hemen hemen tüm kişiler, web tabanlı epostalardan memnunlar.

Web arayüzleri şu anda %80 randımanlıdır ve yeni tarayıcılara gerek duymadan bu rakamı muhtemelen %95'lere kadar çekebiliriz. Bu, bir çok insan ve tercihini yapılan her yeni önemli uygulamanın web uygulaması olmasına kullanmış yazılımcılar için Yeteri Kadar İyidir.

Diğer bir deyişle, Microsoft API artık o kadar da önemli değil. Web uygulamaları Windows gerektirmez.

Microsoft bu olanları farketmedi değil. Elbette farkettiler, ve suçlamalar netleştiğinde, frenlere asıldılar. HTA (http://msdn.microsoft.com/workshop/author/hta/overview/htaoverview.asp) ve DHTML gibi geleceği parlak teknolojiler, üretim bantlarından indirildi. Internet Explorer ekibi ortadan kalkmış gibi; bir kaç yıldan beri tamamıyle kayıplar. Microsoft'un DHTML'in olduğundan daha iyi hale getirilmesine izin verme olasılığı yok: bu işin özü, zengin istemci, için çok tehlikeli. Bugünlerde Microsoft'ta çok duyulan bir tekerleme ise: "Microsoft, şirketi, zengin istemciler üzerine oynuyor." Bunu Longhorn ile ilgili sunumların her sayfasında görebilirsiniz. Avalon takımından Joe Beda şöyle diyor (http://channel9.msdn.com/ShowPost.aspx?PostID=948): "Genel anlamda, Longhorn ve Avalon, Microsoft'un yerdeki kazıklarıdır, diyebilirim ki, masaüstündeki güce inanıyoruz, ve oturduğunuz yerden iyi şeyler yapmaya yine devam edeceksiniz. Masaüstüne yatırım yapıyoruz, bunun iyi bir yer olduğunu düşünüyoruz ve umarım bir heyecan dalgası yaratırız..."

Asıl sorun şu: artık çok geç.

Bu Konuda Kendi Adıma Biraz Üzgünüm

Gerçekten bu konuda kendi adıma biraz Üzgünüm. Bana göre Web önemli ama Web tabanlı uygulamalar yavaş çalışan, tutarsız kullanıcı arayüzüyleriyle günlük kullanılabilirliğin çok gerisindeler. Zengin istemci uygulamalarımı seviyorum ve hergün kullandığım bu uygulamaların, Visual Studio, CityDesk, Outlook, Corel PhotoPaint, QuickBooks, yerine web sürümlerini kullanırsam keçileri kaçırırım. Ama yazılımcıların ileride bize verecekleri bu. Artık kimse (yine 10.000.000 kişiden az demek istiyorum) Windows API için yazılım geliştirmek istemiyor. Yatırımcılar, Microsoft'un rekabetinden çekindikleri için Windows uygulamalarına yatırım yapmıyorlar. Ve çoğu insan da zayıf Web arayüzlerine benim taktığım kadar takmıyor.

Ve işte kanıtı: Farkettim ki(işe alımcı bir arkadaşa da doğrulattım) New York'ta C++ ve COM bilen Windows API programcıları yılda 130.000$ kazanırken, Java, PHP, Perl, ve hatta ASP.NET bilen Web programcıları yılda 80.000$ civarında kazanıyorlar. Bu muazzam bir fark ve Microsoft Danışmanlık Hizmetleri'nden bazı arkadaşlarla konuştuğumda, Microsoft'un tüm bir yazılımcı kuşağını kaybettiğini kabul ettiler. COM tecrübesi olan bir kişiyi işe almak 130.000$ tutuyor, çünkü neredeyse 8 yıldan beri COM programlama ile ilgilenen kalmadı. Bu yüzden gerçekten kıdemli bir kişiyi bulmanız gerekir, ki böyleleri genellikle yönetim kademesindedirler, onları programcı olarak ikna etmeniz için sadece Don Box'in anlayabileceği, ama onun bile bakmaya dayanamayacağı (http://news.com.com/2100-1046_3-5148148.html) bir çok ıvır zıvırla uğraşmanız gerekir.

Bunu söylemekten nefret ediyorum ama, büyük bir yazılımcı kitlesi webe taşındı ve geri dönmeyi reddediyorlar. Bir çok .NET yazılımcısı ASP.NET yazılımcısı ve Microsoft'un web sunucusu için yazılım geliştiriyorlar. ASP.NET harika; on yıldan beri web geliştirme işindeyim ve mevcut herşeyin bir nesil ötesinde. Ama bu bir sunucu teknolojisi ve istemci istediği masaüstünü kullanabilir. Ve Mono (http://www.go-mono.com) kullanarak Linux üzerinde de gayet iyi çalışıyor.

Bu işaretlerin hiçbiri Microsoft ve API'nin gücü sayesinde alıştığı kazançlar için sevindirici değil. Yeni API HTML, ve yazılım geliştirme pazarındaki yeni şampiyonlar HTML'i iyi şakıyanlar olacak.