RSS

Design Patterns: Tasarım Şablonları ve Programlama Dillerinin Kötü Yönleri

01 Jan

Türkçe Lisp programlama e-posta listesi cs-lisp’e Eylül ayında yazan Volkan Yazıcı programlama dünyasının sıcak konularından biri olan tasarım şablonlarına yani ‘design patterns’ konusuna değinmişti:

Merhaba,

comp.lang.lisp listesinde “This may be a nonsensical question, but I was wondering if it is idiomatic to apply common design patterns to lisp applications.” kaşıntısı ile başlayan bir tartışmalar dizisi oldukça ilgimi çekti — şüphesiz ki bunda bu dönem almaya başladığım Aspect-Oriented Software Development dersinin de etkisi olmuştur — ve sizin ile oradan çok ufak bir mesajı paylaşmak istedim.

Tasarım Şablonları, nam-ı diğer Design Patterns mevzusu epey bir süredir sıcak konular arasında. Bu gibi durumlarda sık sık karşılaştığımız gibi konu basit bir teknik konu olmaktan çıkıp pek çok yanlış anlamayı, çok çeşitli felsefi bakış açılarını, alakasız yerlere dallanıp budaklanmayı, düpedüz mantıksal hataları, politik ve ekonomik savaşları bünyesinde barındırmaya başlıyor.

Bu aralar büyük bir zevk ve aydınlanma ile okuduğum CTMCP (Concepts, Techniques, and Models of Computer Programming) kitabından uzunca bir alıntıyı buraya aktarmak istiyorum vurguları kendim yaparak (kitap Lisp, Prolog, Haskell, Erlang ve E gibi dillerdeki pek çok değerli şeyi bünyesinde barındıran Oz programlama dilini kullanarak çeşitli programlama konularına çok güzel şekilde değiniyor):

“Given a class that de?nes a leaf of the tree, the Composite pattern returns a class that de?nes the tree. When put in this way, this sounds much like higher-order programming: we would like to de?ne a function that accepts a class and returns another class. Most programming languages, such as C++ and Java, do not allow de?ning this function, however. There are two reasons for this. First, most languages do not consider classes as ?rst-class values. Second, the function de?nes a new superclass of the input class. Most languages allow de?ning new subclasses but not new superclasses. Yet despite these limitations we would still like to use the Composite pattern in our programs.

The usual solution to this dilemma is to consider design patterns as primarily a way to organize one’s thoughts, without necessarily being supported by the programming language. A pattern might exist only in the mind of the programmer. Design patterns can then be used in languages like C++ or Java, even if they cannot be implemented as abstractions in those languages. This can be made easier by using a source code preprocessor. The programmer can then program directly with design patterns, and the preprocessor generates the source code for the target language.”

Volkan’ın mesajından alıntılar ile devam edelim:

Özellikle Rainer Joswig’in ve Pascal J. Bourguignon’ın mesajlarını herkesin okumasını tavsiye ediyorum.

Biraz fanatikliği kaçacağının farkında olmama rağmen, ufak bir Pascal J. Bourguignon alıntısı ile mesajımı sonlandırıyorum.

    ,-------------------------------------------------------,
    |                                                       |
    |                                                       |
    |                MACRO === DESIGN PATTERN               |
    |                                                       |
    |                                                       |
    `-------------------------------------------------------'


Ben burada bir fanatiklik oldugunu düşünmüyorum, daha doğrusu eger bir fanatiklik var ise bu ne bugüne özgü ne de Lispçilere has (dolayısı ile fanatiklik değil gibi. Sanki.).

comp.lang.lisp’te design patterns araması yaparsak 12-13 yıl önce dahi “yahu bu design patterns denen şey bizi gereksiz kastırıyor olmasın, C++ dünyasina has olup da baska dünyalarda cok gereksiz kaliyor olmasin?” şeklinde kıllanma durumlari oldugunu görmek mümkün (misal bkz. Bruce S. Tobin’in 1995 tarihli mesajı).

Konunun Lispçilere has olmadığını da akıllı bir Perl geliştiricisi olan Mark Jason Dominus’un (*)
Design patterns of 1972‘ ve ‘Ralph Johnson on design patterns’ başlıklı blog girdilerinden görebiliyoruz. Yahut Jeremy Jones’un MJD’nin yazısına işaret eden ‘Design Patterns are Signs of Weakness in Programming Languages‘ başlıklı yazısından.

Bu arada MJD’nin satır aralarında biraz ürkerek de olsa Lisp’e ve CLOS’a (Common Lisp Object System) göndermede bulunduğuna dikkat çekelim (antik Yunan filozoflarının yahut orta çağdaki çok akıllı adamların dini konularda uluorta ve özgürce konuşmak konusundaki haklı çekingenliklerine benzetilebilir mi bu, ne de olsa işin ucunda büyük cemaatler, cemaatlerin yatırım yaptığı teknolojiler, bunun üzerine inşa edilmiş bir eğitim öğretim sektörü, kitap basma ve satma işi, vs. var, az insan ekmek yemiyor).

*: MJD, Higher Order Perl kitabını yazabilecek kadar akıllı biri (kitap beleş olmuş, free as in free beer: http://hop.perl.plover.com/#free), bu onu ortalama yani vasat bir Perl programcısından yahut sys. admin. tarzı işlerde Perl kullanan bir bilgisayarcıdan çok daha akıllı yapıyor. Bununla birlikte onbinlerce Perl ve PHP programcısının ne kadar vasat olduğu gerçeğini de bir kez daha vurgulamış oluyor. Ki bu da yine MJD’nin “bu tasarım kalıplarını dilin bir parçası haline getirip görünmez ve çok kolay şekilde kullanılabilir kılmazsak vay halimize” olarak özetlenebilecek tezini destekliyor. IQ’su yüksek olan ve azınlıktaki düşünürler zahmet edip de ortalama IQ’daki programcıların ağzına kaşıkla beslemezlerse pek çok şeyi, bir endüstri olarak bilgi işlem sektörü çok akıllıca ve hızlıca ilerlemiyor. Bu durumda da marifet tam olarak o kaşıkla ağza besleme işini yapabilmek ve Whitehead’in (Principia Mathematica’yı yazabilecek kadar akıllı biri, yani demek ki ortalama bir Lisp, Perl yahut PHP programcısından çok daha akıllı) “Civilization advances by extending the number of important operations which we can perform without thinking about them.” lafına uygun hareket etmek olsa gerek. Tabii Whitehead milyon dolarların ve abuk sabuk duygusal reklam kampanyalarının döndüğü milyar dolarlık bilgi işlem sektöründe çalışmadığı için o tür lafları çok kolay sarf edebilme lüksüne sahipti, o ayrı.

Advertisements
 
 

4 responses to “Design Patterns: Tasarım Şablonları ve Programlama Dillerinin Kötü Yönleri

  1. osman

    January 1, 2009 at 22:17

    “Bununla birlikte onbinlerce Perl ve PHP programcısının ne kadar vasat olduğu gerçeğini de bir kez daha vurgulamış oluyor…”
    Burayı neden anlayamıyorum? 🙂

     
  2. Emre Sevinc

    January 1, 2009 at 22:23

    Perl ve PHP cemaatleri bünyelerinde pek çok akıllı programcı barındırsalardı, 15-20 yıldır var olan bu diller ile “higher order programming” tabir ettiğimiz önemli tekniklerin nasıl uygulanabileceğine dair HOP gibi kitaplar çok daha önce yazılır ve yayımlanır, sayıları daha çok olurdu.

     
  3. hakan

    January 3, 2009 at 17:22

    Lisp ile sizin fazlamesaideki yazılarınızla tanışmıştım, gerçi kod yazmadım ama practical common lisp’i üstün körü okumuşluğum var. Hayran olmamak elde değildi. Tabi sonra sicp’i de üstünkörü okudum ve çoğunu anlamadan geçtim ama şimdiye kadar hayatımda gördüğüm en tuhaf kitaptı, en derin meseleleri nasıl bir yalınlıkla anlatıyor, benim üstün tuttuğum c – c++’la uğraşsam birkaç kat fazla kod yazmamın gerekeceği ve sonunda karmaşıklığıyla başa çıkamadığım için arapsaçına dönecek programları nasıl da dünyanın en kolay işiymiş gibi ortaya koyuyor, hayranlık vericiydi doğrusu. Yani bir aydınlanma yaşadım ve yolculuk devam ediyor.

    Başkalarını da haberdar edebilmek adına blogumda bir iki yazı yazdım ama sonra pişman oldum çünkü yeterli bilgim olmadığına inanıyorum, okuyacak olana zarar verme ihtimali de var, bu ne saçma iş deyip tamamen de soğuyabilir okuyan biri.(Gerçi günde bir iki kişi giriyor, o da teknik olmayan saçma yazılarıma googledan gelenler, yani çok az kişiye zararı dokunabilir, o yüzden silmeye de kıyamadım)

    Bunu şunun için anlattım, ustaların tavsiyelerini benim gibi çıraklar kulak ardı etmiyor, binlerce kişiden biri bile bir aydınlanma yaşasa bu büyük bir gelişmedir(deniz yıldızlarını kurtaran çocuk hikayesi aklıma geldi böyle deyince)

    Ekonomik, sosyal, politik belki biraz da teknik problemler var bilgi işlem sektöründe. Çoğu programcı ekmek kazanmak için çalışmak zorunda ve onları çalıştıran ve gücü elinde tutanlar herkesi belli programlama dillerine, platformlara, karlarını arttırmak icin gerekli ucuz işgücünün devamlı surette ellerinin altında olmasına ve yeni rakip patronların çoğalmamasına dikkat ediyorlar. Programcılar monoton çalışmaktan, patrona laf anlatmaktan, öğrenmeye, kendini geliştirmeye vakit bulamıyor ki. İngilizceyi bir türlü öğretemeyen bir ülkede yaşadığımızı ve okumanın düşünmenin teşvik edilmediğini nerdeyse yasaklandığından falan bahsetmiyorum bile. Siz anladınız zaten ne demek istediğimi, daha fazla tereciye tere satmayayım 🙂

     
  4. Emre Sevinc

    January 3, 2009 at 19:25

    Aynı konuda sürüp gitmekte olan bir başka tartışma şurada takip edilebilir: http://www.fazlamesai.net/?a=article&sid=5173

     

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: