Ken Thompson’un oluşturduğu Unix felsefesi; minimalist, modüler yazılım geliştirme için bir dizi kültürel norm ve felsefi yaklaşımdır. Unix işletim sisteminin önde gelen geliştiricileri deneyimine dayanmaktadır. İlk Unix geliştiricileri, yazılım mühendisliği pratiğine modülerlik ve yeniden kullanılabilirlik kavramlarını getirmede ve bir “yazılım araçları” hareketi oluştururken önemliydi. Zamanla Unix’in (ve onun üzerinde çalışan programların) önde gelen geliştiricileri, yazılım geliştirmek için bir dizi kültürel normlar ve Unix’in teknolojisi kadar önemli ve etkili hâle gelen normları oluşturdu; bu “Unix felsefesi” olarak adlandırılmıştır.

Unix felsefesi; yaratıcıları dışındaki geliştiriciler tarafından kolayca korunabilen ve yeniden tasarlanabilen basit, kısa, açık, modüler ve genişletilebilir kodlar oluşturmayı vurgular. Unix felsefesi, monolitik tasarıma karşıt olarak kompozitliği destekler.

Başlangıç Noktası

UNIX felsefesi, 1978’den Bell Sistem Teknik Dergisi’nde Doug McIlroy tarafından belgelenmiştir:

  1. Her programın iyi bir şey yapmasını sağlayın. Yeni bir iş yapmak için yeni “özellikler” ekleyerek eski programları zorlaştırmak yerine yeniden oluşturun.
  2. Henüz bilinmeyen bir programa giriş yapmak için her programın çıktısını bekleyin. Çıktısını gereksiz bilgilerle karıştırmayın. Sıkı sütunlu veya ikili giriş formatlarından kaçının. Etkileşimli girişte ısrar etmeyin.
  3. İdeal olarak haftalar içerisinde erken denenecek yazılımları hatta işletim sistemlerini tasarlayın ve oluşturun. Sakar kısımları atmak ve yeniden inşa etmek için tereddüt etmeyin.
  4. Araçların kurulumunu yapmak için saptırmak ve bunları bitirdikten sonra bunlardan bazılarını atmak zorunda kalsanız bile bir programlama görevini hafifletmek için vasıfsız yardım için tercih edilen araçları kullanın.

Daha sonra Unix’in Çeyrek Yüzyılı’nda (1994) Peter H. Salus tarafından özetlenmiştir:

  • Bir şeyi yapan programlar yaz ve iyi yap.
  • Birlikte çalışmak için programlar yazın.
  • Metin akışlarını işlemek için programlar yazın çünkü bu evrensel bir arabirimdir.

1974’teki ödüllü Unix yazısında Ritchie ve Thompson aşağıdaki tasarım unsurlarını aktarmaktadır:

  • Program yazmayı, test etmeyi ve çalıştırmayı kolaylaştırın.
  • Toplu işlem yerine interaktif kullanım…
  • Boyut kısıtlamalarından dolayı tasarımın ekonomisi ve zarafeti (“acı çekerek kurtuluş”).
  • Kendi kendini destekleyen sistem: Tüm Unix yazılımı Unix altında korunur.

UNIX’ın bütün felsefesi çevirme dillerden uzak duruyor gibi görünüyor. -Michael Sean Mahoney

Unix Programlama Ortamı (The Unix Programming Environment)

Brian Kernighan ve Rob Pike’nin 1984 tarihli UNIX Programlama Ortamı (The UNIX Programming Environment) kitabında hem Bell Labs’den hem de Unix tasarımının ve Unix felsefesinin kısa bir açıklamasını veriyor:

UNIX sistemi bir dizi yenilikçi program ve teknik sunsa da hiçbir program veya fikir işe yaramamaktadır. Bunun yerine onu etkili kılan bilgisayar kullanma felsefesi olan programlamaya yaklaşımdır. Her ne kadar bu felsefe tek bir cümle içinde yazılmasa da gönüldeki bir sistemin gücünün programların kendileriyle değil, programların ilişkilerinden daha fazla geldiği fikridir. Pek çok UNIX programı, yalıtımda oldukça önemsiz şeyler yapar ancak diğer programlarla birleştirildiğinde genel ve kullanışlı araçlar hâline gelir.

Yazarlar ayrıca bu kitabın hedeflerinin “UNIX programlama felsefesini iletmek” olduğunu yazıyor.

UNIX Ortamında Program Tasarımı (Program Design in the UNIX Environment)

Daha sonra Bell Labs Bilgisayar Bilimi Araştırma Merkezi başkanı ve Unix boru hattının mucidi olan McIlroy, Unix felsefesini şu şekilde özetledi:

Ekim 1984’te Brian Kernighan ve Rob Pike, UNIX Ortamında Program Tasarımı (Program Design in the UNIX Environment) adlı bir makale yayımladı. Bu makalede 4.2BSD ve System V gibi bazı yeni Unix sistemlerinde bulunan program seçeneklerinin ve özelliklerin birikimini eleştirmekte ve her biri bir genel fonksiyonu yerine getiren yazılım araçlarının Unix felsefesini açıklamaktadır:

UNIX işletim sisteminin gücünün çoğu; programların kullanımını kolaylaştıran ve daha önemlisi diğer programlarla birleştirmeyi kolaylaştıran bir program tasarım stilinden geliyor. Bu stile yazılım araçlarının kullanımı denir ve programların programlama ortamına nasıl uyduğuna ve içsel olarak nasıl tasarlandığına göre diğer programlarla nasıl kullanılabileceğine bağlıdır. […] Bu stil, araçların kullanımına dayanıyordu: Programları ayrı ayrı veya birlikte kullanarak monolitik kendi kendine yeterli alt sistemlerle veya özel amaçlı bir kerelik programlarla elle yapmaktan ziyade bir iş yapmak için.

Yazarlar, cat gibi Unix araçlarını diğer sistemlerin kullandığı daha büyük program paketleriyle karşılaştırır.

cat’ın tasarımı çoğu UNIX programının tipik bir örneğidir: Pek çok farklı uygulamada kullanılabilen (orijinal yazar tarafından öngörülmeyen pek çok kişi de dâhil olmak üzere) basit ama genel bir fonksiyon uygular. Diğer komutlar diğer fonksiyonlar için kullanılır. Örneğin, dosyaları yeniden adlandırma, silme veya ne kadar büyük olduklarını söyleme gibi dosya sistemi görevleri için ayrı komutlar vardır. Diğer sistemler bunun yerine tek bir ‘dosya sistemi’ komutuna kendi iç yapısı ve komut dili ile girerler. (CP/M veya RSX-11 gibi işletim sistemlerinde bulunan PIP dosya kopyalama programı bir örnektir.) Bu yaklaşım mutlaka daha kötü veya daha iyi değildir ancak UNIX felsefesine kesinlikle karşıdır.

Unix Programlamada Doug McIlroy

Daha sonra Bell Labs Bilgisayar Bilimi Araştırma Merkezi başkanı ve Unix boru hattının mucidi olan McIlroy, Unix felsefesini şu şekilde özetledi:

Bu Unix felsefesi: Bir şeyi yapan programlar yaz ve iyi yap. Birlikte çalışmak için programlar yazın. Metin akışlarını işlemek için programlar yazın çünkü bu evrensel bir arabirimdir.

Bu ifadelerin ötesinde Unix programında sadeliği ve minimalizmi vurguladı:

“Karmaşık ve güzel karmaşıklıklar” kavramı neredeyse bir tezattır. Unix programcıları birbirleriyle “basit ve güzel” onurlar için birbiriyle bağlantı kurarlar - bu kurallara aykırı olan bir nokta ama açık yapmaya da değer.

Aksine McIlroy modern Linux’u yazılım şişkinliği olarak eleştirdi ve “hayranlık uyandıran hayranlar, Linux iyiliklerini şişmanlık verici bir obezite hâline getirdiklerini” belirtti. Bu; Research Unix’i geliştirirken ve revize ederken Bell Labs’da daha önceki yaklaşımla çelişir:

Her şey küçüktü… Ve büyüklüğünü gördüğümde kalbim Linux için batıyor. […] Manuel bir sayfa olarak kullanılan el kitabı artık küçük bir hacme sahip, binlerce seçeneğiyle. Unix Odası’nda oturup “Ne atabiliriz? Neden bu seçenek var?” derdik. Çoğu zaman temel tasarımda bazı eksiklikler olduğu için - doğru tasarım noktasına gerçekten isabet etmediniz. Bir seçenek eklemek yerine bu seçeneği eklemenizi zorlayan şeyi düşünün.

Bir Şey Yap ve İyi Yap (Do One Thing and Do It Well)

McIlroy tarafından belirtildiği ve genel olarak Unix topluluğunda kabul edildiği gibi Unix programlarının her zaman DOTADIW ya da “Bir Şey Yap ve İyi Yap. (Do One Thing and Do It Well.)” kavramını takip etmesi beklenmektedir. İnternetteki DOTADIW kısaltması için sınırlı kaynaklar var fakat özellikle Linux topluluğunda yeni işletim sistemlerinin geliştirilmesi ve paketlenmesi sırasında uzun bir süre tartışılıyor.

Slackware Linux’un proje lideri Patrick Volkerding, bu tasarım ilkesini systemd mimarisinin eleştirisinde “bir servisteki hizmetleri, soketleri, cihazları, montajları vb. kontrol etmeye çalışmak; UNIX’ın tek bir şeyi yapma ve iyi yapma kavramı karşısında uçuyor.” diye hatırlattı.

Eric Raymond’un 17 Unix Kuralı

2003 yılında yayımlanan Unix Programlama Sanatı (The Art of Unix programming) adlı kitabında Amerikalı bir programcı ve açık kaynak savunucusu olan Eric S. Raymond, Unix felsefesini “Basit, Aptal Tut (Keep it Simple, Stupid)”; KISS İlkesi olarak özetliyor. Bir dizi tasarım kuralları sunuyor:

  • Modüler programlar oluşturun.
  • Okunabilir programlar yaz.
  • Kompozisyon kullanın.
  • Politikadan ayrı mekanizmalar…
  • Basit programlar yaz.
  • Küçük programlar yaz.
  • Şeffaf programlar yaz.
  • Sağlam programlar yaz.
  • Gerekirse verileri programa göre karmaşıklaştırın.
  • Potansiyel kullanıcıların beklenen bilgisini geliştirin.
  • Gereksiz çıktılardan kaçının.
  • Teşhis edilmesi kolay bir şekilde başarısız olan programlar yazın.
  • Makine zamanı boyunca değer geliştirme süresi…
  • Elle kod yazmak yerine kod üreten soyut programlar yazın.
  • Parlatmadan önce prototip yazılımı…
  • Esnek ve açık programlar yazın.
  • Programı ve protokolleri genişletilebilir yapın.

Mike Gancarz: UNIX Felsefesi (The UNIX Philosophy)

1994 yılında Mike Gancarz (X Pencere Sistemi’ni tasarlayan ekibin bir üyesi); Unix’le kendi deneyimini ve Unix’e bağlı diğer alanlardaki diğer programcılarla ve insanlarla tartıştı, 9 önemli ilkede özetleyen UNIX Felsefesi’ni üretmek için özetledi:

  1. Küçük güzeldir.
  2. Her programın iyi bir şey yapmasını sağlayın.
  3. En kısa zamanda bir prototip oluşturun.
  4. Verimlilik üzerinden taşınabilirliği seçin.
  5. Verileri düz metin dosyalarında saklayın.
  6. Yazılım kaldıracını kendi yararınıza kullanın.
  7. Kaldıraç ve taşınabilirliği artırmak için kabuk komut dosyaları kullanın.
  8. Sabit kullanıcı arayüzlerinden kaçının.
  9. Her programı bir filtre yapın.

“Daha Kötüsü Daha İyi”

Richard P. Gabriel; Unix’in önemli bir avantajının hem arayüzün hem de uygulamanın sadeliğinin sistemin diğer özelliklerinden daha önemli olduğu, “daha kötüsü daha iyi” olarak adlandırdığı bir tasarım felsefesini somutlaştırmasıydı - doğruluk, tutarlılık ve bütünlük de dâhil olmak üzere. Gabriel, bazı sonuçların kalitesini sorgulamasına rağmen bu tasarım stilinin önemli evrimsel avantajlara sahip olduğunu savunuyor.

Örneğin; ilk günlerde Unix bir monolitik çekirdeği kullanmıştır (bu, kullanıcı işlemlerinin kullanıcı sistemindeki tüm çekirdek yığınlarını çağırdığı anlamına gelir). Bir işlem, çekirdeğindeki uzun süreli bir G/Ç’de engellenirken bir işleme teslim edilirse, ne yapılmalıdır? G/Ç tamamlandığında, sinyal gecikmeli, uzun bir süre (belki de süresiz) olabilir mi? İşlem çekirdek modda olduğunda, yığın üzerindeki hassas çekirdek verileriyle sinyal işleyicisi yürütülemedi. Çekirdeğin sinyal işleyicisini başarıyla tamamladığını varsayarak daha sonra tekrar çağırmak ve yeniden başlatmak için sistem çağrısı geri alınmalı ve saklanmalı mı?

Örneğin; ilk günlerde Unix bir monolitik çekirdeği kullanmıştır (bu, kullanıcı işlemlerinin kullanıcı sistemindeki tüm çekirdek yığınlarını çağırdığı anlamına gelir). Bir işlem, çekirdeğindeki uzun süreli bir G/Ç’de engellenirken bir işleme teslim edilirse, ne yapılmalıdır? G/Ç tamamlandığında, sinyal gecikmeli, uzun bir süre (belki de süresiz) olabilir mi? İşlem çekirdek modda olduğunda, yığın üzerindeki hassas çekirdek verileriyle sinyal işleyicisi yürütülemedi. Çekirdeğin sinyal işleyicisini başarıyla tamamladığını varsayarak daha sonra tekrar çağırmak ve yeniden başlatmak için sistem çağrısı geri alınmalı ve saklanmalı mı?

Bu durumlarda Ken Thompson ve Dennis Ritchie, mükemmellik üzerinde sadeliği tercih etti. Unix sistemi, zaman zaman hiçbir şey yapmadığını belirten bir hata ile bir sistem çağrısından erken dönecekti—”kesintiye uğramış sistem çağrısı” veya bugünün sistemlerinde 4 numaralı bir hata (EINTR). Tabii ki sinyal işleyicisini aramak için çağrı iptal edildi. Bu sadece read(), write(), open() ve select() gibi bir avuç uzun süredir çalışan sistem çağrısı için olabilir. Artı tarafta bu, G/Ç sistemini tasarlamak ve anlamak için birçok kez daha basit hâle getirdi. Kullanıcı programlarının büyük çoğunluğu hiçbir zaman etkilenmedi çünkü SIGINT dışındaki sinyalleri ele almadılar veya deneyimlemediler ve biri yükseltilmişse hemen ölecekti. Diğer birkaç program için -iş denetimi anahtarına yanıt veren kabuk veya metin editörleri gibi şeyler- bu EINTR hatası ortaya çıkarsa aramayı hemen yeniden denemek için sistem çağrılarına küçük örtüler eklenebilir. Böylece sorun basit bir şekilde çözüldü.

Eleştiri

1981’de yayımlanan “Unix hakkında gerçek: Kullanıcı arayüzü berbat (The truth about Unix: The user interface is horrid)” başlıklı bir makalede Don Norman, Unix tasarım felsefesini kullanıcı arayüzü için endişe eksikliği nedeniyle eleştirdi. Bilişsel bilimdeki arka planından ve şu anki bilişsel mühendislik felsefesinden yola çıkarak son kullanıcıların kişisel bir bilişsel sistem modelini nasıl kavradıklarına ve oluşturduklarına odaklandı ya da Unix söz konusu olduğunda anlayamıyorsanız sonuçta felaket hatalar (örneğin; bir saatlik çalışmayı kaybetmek gibi) çok kolay.

Ayrıca Bakınız

References