Neden Arc Özellikle Nesne Yönelimli Değil?

0
FZ
Paul Graham'ın Why Arc Isn't Especially Object-Oriented makalesi yazılım dünyasında bazı çok tekrarlanan ve düşünmeden kabul edegeldiğimiz kalıpları sorgulamamız için kısa ve etkili makalelerden biri.

Daha önce Common Lisp ile Internet Programlamaya Giriş Kılavuzu makalesi ile tanıdığımız İstanbul Bilgi Üniversitesi, Bilgisayar Bilimleri bölümü öğrencilerinden Haldun Bayhantopçu'nun çevirisi ile bu makaleyi FM'de de yayınlıyoruz. Çevirinin daha güzel bir hale gelmesinde emeği geçen Türkiye Lisp Çalışma Grubu üyelerine teşekkürler.

Neden Arc Özellikle Nesne Yönelimli Değil?

Şimdilerde bir çeşit nesne yönelimli programlama çılgınlığı yaşanıyor ama tanıdığım bazı çok zeki programcılar, bu çılgınlıktan en az heyecan duyanlar.

Nesne yönelimli programlamanın bazı durumlarda yararlı olduğunu düşünüyorum. Ancak yazdığınız her programda da kullanmanıza gerek yok. Bir dilde yeni veri tipleri yaratabilmelisiniz ancak yazdığınız her programı yeni veri tipleri tanımlarıyla ifade etmek zorunda da kalmamalısınız.

Bence insanların nesne yönelimli programlamayı sevmelerinin beş nedeni var, ve bunlardan üç buçuk tanesi kötü:
  1. Nesne yönelimli programlama, metinsel kuşatmalara [1] veya makrolara sahip olmayan statik tipli bir dil kullanıyorsanız, heyecan vericidir. Bir dereceye kadar bu gibi kısıtlamaları aşmanıza yarar. (Bakınız: Greenspun'un Onuncu Kuralı.)
  2. Nesne yönelimli programlama büyük firmalarda yaygındır, çünkü onların program yazma yöntemine uyar. Büyük firmalarda, yazılım orta seviye programcılardan oluşan büyük (ve genellikle sıkça eleman değiştiren) ekipler tarafından yazılır. Nesne yönelimli programlama bu programcıların herhangi birisinin çok fazla zararlı bir iş yapmasını engelleyen bir disiplin sağlar. Bunun bedeli yazılan kodun protokoller ve tekrarlamalarla dolu olmasıdır. Bu bedel büyük firmalar için çok ağır değildir, çünkü yazdıkları yazılım da muhtemelen ağzına kadar protokollerle ve tekrarlamalarla dolu olacaktır.
  3. Nesne yönelimli programlama çok fazla iş yapılmış gibi gösterir. Eski günlerde, yazdığı 5-10 satır koddan önce 20 satır düzgünce şekillendirilmiş yorum yazan bir programcı tipi vardı. Nesne yönelimli programlama bu tipte programcılar için bulunmaz nimettir: bütün bu yapıyı doğrudan kaynak kodun içine koymalarını sağlar. Bir Lisp hackerının listeye bir sembol koyarak hallettiği iş, bir dolu sınıf ve metod dosyası halini alır. Bu yüzden, kendinizi ya da bir başkasını, çok çalıştığınıza ikna etmek için güzel bir yoldur.
  4. Eğer bir dilin kendisi nesne yönelimli bir programsa, kullanıcılar tarafından genişletilebilir. Yani, belki. Ya da belki nesne yönelimli programlamanın alt kavramlarını sunarsanız daha iyi olur. Örneğin fonksiyon yüklemesi (overloading) esasında sınıflara bağlı bir kavram değildir. İleride göreceğiz.
  5. Nesne yönelimli soyutlamalar, belirli tipteki programlardaki kavramlarla çok güzel eşleşir. Örnek olarak simülasyon ve CAD sistemlerini verebiliriz.
Kişisel olarak nesne yönelimli soyutlamalara hiç ihtiyaç duymadım. Common Lisp inanılmaz derecede güçlü bir nesne sistemine sahip ve ben onu bir kez bile kullanmadım. Diğer güçsüz dillerde nesne yönelimli teknikleri kullanmamı gerektirecek bir sürü iş yaptım (ör: tamamen kuşatmalardan oluşan harman tabloları [2]), ancak hiç bir zaman CLOS [3] kullanmak zorunda kalmadım.

Belki ben aptalım, ya da sadece sınırlı bir alanda çalıştım. Bir dili birisinin kişisel deneyimlerine dayanarak tasarlamak tehlikelidir. Ancak hiçbir zaman gereksinim duymayacağınız şeyleri sadece iyi fikirler olduğu düşünüldüğü için bir dile koymak, bence daha tehlikelidir.

Paul Graham.

[1] ÇN: Lexical closure. (Bkz. The Idiot's Guide to Special Variables and Lexical Closures
[2] ÇN: Hashtable.
[3] ÇN: Common Lisp Object System.

Görüşler

0
tongucyumruk
Bu güzel çeviri için, fakat özellikle de The idiot's guide linki için çok teşekkürler... Ben yine de Lafzi Muhasara'yı kullanmayı öneriyorum...
0
hb
Bu linki ben degil FZ eklemis yaziya. Bu vesileyle ben de tesekkurlerimi sunarim.
0
innaw
Okudugum en kotu P.Graham yazisi bu olsa gerek. Yazdigi $eylere katilmadigimdan degil, yalnizca savini iyi destekleyemedigini du$undugum icin.
0
FZ
Graham yine az ve öz yazmış. Dedikleri tartışılabilir öte yandan son 5-6 yıldır mesela J2EE ile damardan uğraşan insanların, proje yöneticilerinin de söylediği şeyler benzer değil mi, hani şu "ortalama programcı alırız, kolayca bir başkası ile değiştirebiliriz ve bazı şeylerin yapılması evet uzun sürer ama zaten kurumsal ölçekte bunu baştan kabul ederiz" şeklinde bahsedilmiyor mu? Ortalama programcı alıyor ve onu bir Lego parçası gibi bir işe monte ediyorsunuz, yerine kolayca başka biri geçebilir.

Neden ortalama programcı sayısı fazla?

Normal dağılım böyle bir şey değil mi zaten? Öte yandan Erik Naggum'un dediği gibi, elinizdeki teknoloji zırt pırt yani 3-4 yılda bir değişecekse zaten çok iyi öğrenip çok çok uzman olmakla niye uğraşasınız mevcut ekonomik/IT düzeninde. Bu bakış açısını pek çok insan benimsemiyor mu?

Yine Naggum'un dediği gibi mevcut IT ortamı "acemiyi ödüllendirirken uzmanı cezalandırıyor" değil mi yukarıdaki ve başka benzer sebeplerden ötürü? (Lütfen uzman adam her yerde süper iş bulur şeklinde cevap vermeyin buna, kast edilen biraz daha faklı bir şey).
0
innaw
Konu OOP'den uzaklaşmıyor mu acaba?

İş hayatındaki abuklukların suçlusu OOP mi? Bence değil.

Makaleye dönecek olursak, mesela Graham OOP'deki kod tekrarlarından bahsetmiş. Bu tamamen programcının hatasıdır, "OOP'in ne demek olduğunu iyi bilmiyor demek ki" diye düşünürüm. Ya da platform örneğin J2EE ise "projenin başındakiler OOD üzerinde çok iyi iş çıkaramamışlar, belki de doğru teknolojileri seçmemişlerdir" derim. OOP/OOD "her şey bir nesne"dirin ötesinde bir olay. Tıpkı J2EE gibi; insanı vezir de eder, rezil de.

Makalede belirtilen nedenlerden 3.'sü gerçekten çok komik. Lütfen bir daha okuyun. Burada da tamamen bireysel bir olaydan bahsedilmiş, "Nesne yönelimli programlama çok fazla iş yapılmış gibi gösterir. [..] ...kendinizi ya da bir başkasını, çok çalıştığınıza ikna etmek için güzel bir yoldur." Şahsen ben hiç bir zaman böyle hissetmedim. Bu şekilde düşünen OO programcıları olabilir. Bu onların sorunu, OOP'in değil. OO paradigması ile bunun ne ilgisi var?

Erik Naggum'dan verdiğiniz örnekleri biraz daha açmanızı rica ederim.
0
FZ
Konu aslında hep aynı konu. Ortada bir "şey" var ve bunun "her şeye" uygulanmasının gerekmediğini söyleyen, karmaşık yazılımlar geliştirmiş bir adam var. O şey bazı bakımlardan faydalı. Her zaman, her şey için faydalı gibi gösterilmeye çalışılması tabii bu tür alerjik tepkilere yol açıyor. Öte yandan tek bir OOP sistemi de yok mesela Graham CLOS'tan bahsederken Java, C++, vb. dillerin Smalltalk tarzı "message passing" tarzı OO'sundan değil "generic function"lara dayanan OO ve görülen o ki bu güçlü sistem de kullanılmadan pek çok şeyi acı çekmeden yapmak mümkün oluyor Graham'a göre. Benzer bir şey mesela UML ile ilgili Boeing'de çalışan kıdemli bir yazılım projeji yöneticisi tarafından söylenmişti ACM'nin bir yayınında ( burada da tartışmıştık). Yani Graham köyün delisi değil. Bazı bakımlardan şikayetçi olan başka deneyimli uzmanlar da var.

Naggum'a göndermede bulunmam ise daha ziyade "kolayca öğrenilen... ve unutulan sistemler" ile alakalı idi. OO bağlamına oturtmak gerekirse, hiçbir şey OO'nun suçu değil. Kavramların suçu olmaz zaten, insanların sorumluluğu olur. Pek çok genç insan da genellikle piyasadaki "guru"ların ve "şirket"lerin yönlendirmesi ile hareket ediyor, "büyük"lerinden nasıl görüyorlarsa öyle yapıyorlar. Naggum'un derdini anlamayı gerçekten isterseniz buyrun kendi sözlerinden okuyun.
0
yilmaz
"ortalama programcı alırız, kolayca bir başkası ile değiştirebiliriz ve bazı şeylerin yapılması evet uzun sürer ama zaten kurumsal ölçekte bunu baştan kabul ederiz"
bahsedilen söz kendi yazılımını kendi geliştiren yani yazılımın birincil kullanıcısı kendileri olan kurumlar için doğrudur. Ama bu diğer diller içinde aynıdır. Kurum C de kullanıyorsa bu söz yine doğrudur. Ama başka bir kurumun ihtiyacını gidermeye çalışıyorsanız o zaman, zaman problem olur. o zaman da daha sağlam bilgi birikimine sahip insanlara ihtiyacımız olur. Nesneye yönelik programlamada amaç parcaları tek tek yazmak sonra tekrar birleştirmek. Bu aşamada problem doğarsa problem olan nesne değiştirilir uygulamanın bütünlüğü bozulmaz. Buda bir ihtiyaçtan dolayı doğmuştur.
Görüş belirtmek için giriş yapın...

İlgili Yazılar

Bağlı Listeler, C, Lisp, Scheme...

FZ

Bağlı listeler programcıların kullanabilecekleri soyutlama araçları arasında önemli yer işgal ederler. Bu veri yapılarını kullanarak veri işleme süreçlerini kolayca yönetmek mümkündür.

Jonathan Bartlett, IBM developerWorks sitesindeki Techniques for using linked lists in C and -- smarter still -- Scheme makalesinde bağlı listelere dair önce C programlama örnekleri vermekte ve daha sonra liste yapısını dilin doğal parçası olarak ele alan Lisp benzeri Scheme dilinde benzer işlerin nasıl daha kolayca ve soyut seviyede yapılabileceğini göstermektedir.

Ruhan İkeda ile Müzik ve Lisp Üstüne

FZ

Bir sonraki Lisp toplantısının konuşmacısı Bilgi Üniversitesi'nde Müzik ve Linux dersini veren Ruhan İkeda.

Ruhan İkeda, gerçekleştirdiği müzik araştırmalarından ve bunlarla bağlantılı olarak kullandığı Common Lisp tabanlı araçlardan bahsedecek.

Düzeltme: Etkinlik 14 Ekim'de değil, 14 Kasım'da gerçekleşecek.

Meta-programlama sanatı

tongucyumruk

IBM DeveloperWorks'te yayınlanan makalesinde Jonathan Barnett meta-programlama ve makro işleme konularını incelemiş. Yazının içinde CPP ve M4 gibi çeşitli makro dillerinden örnekler ve son olarakta Scheme ile yazılmış makrolardan bahsediliyor. Özellikle diğer dillerdeki makrolar ile Lisp ailesindeki dillerin makroları arasındaki farkı anlayabilmek için okunması gereken bir makale.

Fonksiyonel Geometri, Lisp, Escher, Postscript: Sanat ve Bilgisayarlar

FZ

Daha önce FM'de bir Mars programlama projesi yarışması bağlamında adı geçen Frank Buss bu sefer de gündemimizi Peter Henderson'ın makalelerinden uyarladığı ve Common Lisp kullanarak gerçekleştirdiği bir fonksiyonel geometri uygulaması ile meşgul ediyor. Fonksiyonel programlamanın grafik uygulamalarını kullanarak anlaşılması bakımından çarpıcı bir örnek. Program çıktısını Postscript olarak üretiyor.

Söz konusu grafik yapılar pek çok matematikçinin ve diğer bilim insanlarının da hayranlığını kazanan Hollandalı meşhur sanatçı M. C. Escher'in yapıtlarından esinlenerek hazırlanmış.

Diyelim Ki Elimizde Nesneye Yönelimli Bir Dil Yok - Alice Nesneler Diyarında

FZ

Elinizdeki programlama dilinde nesneye yönelimli (OO - Object Oriented) programlama imkanı olmasa idi ne yapardınız? İki seçenekten biri gelirdi aklınıza herhalde:
  1. OO desteği veren bir dil kullanmaya başlamak.
  2. Elinizdeki dile OO desteği katmak için uğraşmak.
Bu kısa yazıda Peter Norvig'in PAIP (Paradigms of Artificial Intelligence Programming Case Studies in Common Lisp) kitabının 13. bölümündeki birkaç kısa örnekten yola çıkarak "eğer Common Lisp dilinde CLOS (Common Lisp Object System) gibi bir şey olmasaydı bunu nasıl gerçekleştirebilirdik?" sorusunun cevabının ilk bölümüne göz atacağız.