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

FZ
1 Ocak 2009 , 6 dakika okuma süresi

Geçen sene Eylül ayında, 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. Acaba neden?

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 (bu arada 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ı.

yazilim

Görüşler

gentoo
yaklaşık 16 yıl önce

Ben şu meşhur GoF'nin yazdığı kitabı incelerken bu durum deseninin (state pattern) ve bununla ilgili Coplien'in Envelope-Letter (Mektup-Zarf) kavramının özellikle grafik programlamada oldukça faydalı olabileceği kanaatine varmıştım. Tam tersine singleton tasarım şablonunun (design pattern) de hani 'bil ama kullanma' türünden işleri bir anda içinden çıkılamaz bir düzeye getiren bir tasarım deseni olduğu kanaatine varmıştım.

Hatta bu tekli tasarım desenini (singleton design pattern) hem cdili haber grubunda hem de oyungeliştirici forumlarında tartışmıştık.

http://tech.groups.yahoo.com/group/cdili/message/7602

http://www.oyungelistirici.net/index.php/forumlar?func=view&id=4146&catid=10&start=20

FZ
yaklaşık 16 yıl önce

Tüm bu tartışmalardan sonra görünen şeylerden biri sanırım şu: insan düşüncesinin gücü soyutlamalardan gelir ve yazılım da bundan payını almalıdır. Yazılımın bundan payını alabilmesi için işe yarar soyutlamaların tespit edilir edilmez ortama içkin hale getirilmesi yani bir nevi görünmez kılınması (dolayısı ile sıradan programcılar tarafından dahi çok kolay kullanılır hale getirilmesi) önemlidir. Bu işi ya yeni diller geliştirerek (C yerine C++), ya çok esnek mekanizmaları olan diller kullanarak (Common Lisp Object System), yahut bazı çatıları aşırı popülerleştirmeye çalışarak (Ruby ile geliştirilmiş Ruby on Rails çatısının MVC yani Model-View-Controller tasarım kalıbını çok doğal ve kolay kullanılır bir şeymiş gibi sunması ve bunun bambaşka platformlar tarafından öyle ya da böyle taklit edilmeye çalışılması) yaparsınız. Ama bunlardan birini yapmamak ve insanları birtakım reçeteleri reçete olarak kullanma aşamasında bırakmak asıl marifet değildir. Asıl marifet reçeteleri reçete olmaktan çıkarıp araçlarımıza içkin özellikler haline getirebilmek, bunları hiç düşünmeden otomatik olarak kullanabilir hale sokmaktır.

auselen
yaklaşık 16 yıl önce

FZ
yaklaşık 16 yıl önce

"Yazılımın bundan payını alabilmesi için işe yarar soyutlamaların tespit edilir edilmez ortama içkin hale getirilmesi yani bir nevi görünmez kılınması"

Bu yapılıyor. Sizin de dediğiniz C->C++ gibi. Tespit edilir edilmez konusu ilginç tabi. Hemen mi yapmalarını isterdiniz? Birileri hemen de yapıyor aslında, sadece kabul edilmesi uzun sürüyor.

Bunun yapılması iyi, kabul edilmesinin uzun sürmesi kötü. Tür olarak henüz yeterince akıllanmadığımızın göstergesi olarak kabul ediyorum bunu (tıpkı toplu katliamları tür olarak yeterince akıllanamadığımızın bir göstergesi olarak kabul ettiğim gibi). C'de sürekli nesneye yönelik reçeteleri uygulamak yerine C++ gibi bir şeyin geliştirilmesi akıllıcadır. C++ gibi bir şeyi sabit kabul edip birtakım reçetelerin sürekli uygulanmasını istemek ona kıyasla o kadar akılcı değildir. Bu bakımdan Mark Jason Dominus'un dediklerine katılıyorum.

Reçete konusu; Tasarım kalıplarının özü, bulunmuş çözümlerin nasıl paylaşılacağı ya da dokümante edileceğidir. MVC, Singleton, Visitor değildir. Onlar tam da tasarım kalıplarına uyacak şekilde tanımlanmış çözümlerdir (yazılmış reçetelerdir).

Dışarıda n tane sorun var iken, sizin elinizde bulunan herhangi bir dilin m özelliği bunları muhakkak çözmeye (n>m) yetmeyecektir (pigeonhole). Yani bazı çözümleri dili değiştirmeden el ile kendiniz uygulamanız gerekecektir.

Tüm vampirleri öldürmeye muktedir bir gümüş kurşun olacaktır ya da hemen şimdi olsun demiyorum. Bu sanki denmiş gibi davranmak tıpkı MJD'ye verilmiş dikkat çekici bir cevapta olduğu gibi bir korkuluğa saldırmak (straw man argument) olacaktır.

Kalıpları uygulamaya gelince, kalıp keşfedip uygulamak fena bir şey değil mutlak anlamda. Bunu paylaşmak da fena değil. Beynimizin çalıştığını ve soyutlama yapabildiğimizi gösterir. Bu kalıpları bir an önce çok daha kolay kullanılır hale getirmek ise beynimizin daha üst düzey soyutlamalar yapabildiğini gösterir, bunda da bir fenalık görmüyorum.

Ayrıca dillere sürekli yeni özellikler eklemek onların kullanıcılar arasında benimsenmesini (herkesin bildiği gibi) zorlaştırır (örneğin java ve yeni katılan özellikleri). Üstelik hangi özelliğin doğru olacağını en iyi zaman belirlediği için bu işlem doğası gereği uzun sürecektir.

Buradaki problem dile yeni özellik katma denen eylemin zorunlu olarak birtakım ulu kişiler, komisyonlar ve uzun cemaat süreçleri, vs. (birini seçin) sonucunda ortaya çıkabilecek ve kitlelerin homurdanmalarına sebep olabilecek ("kahretsin, bu X ve Y özelliği de nereden çıktı, sürekli öğrenmem gereken yeni şeyler çıkarıyorsunuz!") türden bir eylem olarak kabul edilmesi sanırım. Bu olsa olsa kazaen olan bir şeydir, zorunlu bir özellik değildir. Bir dilin içkin yapılarını değiştirmek söz konusu süreçlere tabi olmak zorunda değil.

Dinamik bir dille bir çok sorunu çözebileceğinizi iddia edebilirsiniz ama yemek tarifi gibi program yazmak isteyen insanları bilmiyorum cezbedebilir misiniz? Dışarıda yazılması gereken milyonlarca satır ve bunun için ödenebilecek yeteri kadar para varken, zekasını daha fazla kullanmak istemeyen insanları hor görmek doğru bir davranış değildir. Gerçekten...

Herhalde işin ucunda ölüm kalım meselesi olmadığından gerek köprü ve uçak yapan mühendislere, cerrahlara, vb. entelektüel işçilere uyguladığımız dayattığımız bazı önemli kriterleri yazılım geliştirici dediğimiz entelektüel işçilere dayatmaktan çekiniyoruz. Ortada yeterince bol miktarda para olması o paranın her harcanışının en verimli ve ekonomik harcanış olduğunu göstermez takdir edersiniz ki. Yine Mark Jason Dominus'un yazısına göndermede bulunalım, ortada yeterince bol miktarda C programcısı varken struct ve fonksiyon pointer ile nesneye yönelik programlama reçetesini sürdürmek bunu nesilden nesile aktarmak iyi olmaz mıydı? C++ gibi bir sürü ekstra özellik barındıran bir şey çıkarmak yerine? Yahut 1950lerde ortada pek çok assembly programcısı ve yeterince para verken 'subroutine' denen tasarım reçetisini güzelce kitap haline getirip (o zaman işe yarayan diğer reçetelerle birlikte) bunu sürekli yeni programcılara öğretmenin zararı ne olurdu? Prosedürel diller geliştirmek yerine yani.

Dünya yeterince hızlı dönmüyor ya da biz istediğimiz kadar uzun yaşayamıyoruz. Demek istediğim, istediğiniz akıllıca davranışın dünya da kabul gördüğünü asla göremeyeceksiniz (ya da çok şanslı olacaksınız).

Buna sevdiğim bir yazarın sözü ile bir yorum getirsem nasıl olur?

"Makul insan kendini dünyaya uydurur; makul olmayan insan ise dünyayı kendine uydurmakta ısrar eder. Bu yüzden ilerleme makul olmayan insanın yaptığına bağlıdır." -- George Bernard Shaw.

İstediğim türden akıllıca davranışın en azından bazı örneklerinin en azından bazı durumlarda gerçekleşmiş olduğunu gördüğüm için, Mark Jason Dominus gibi akıllı insanları ve onun yazdıklarını anlayıp doğru yorumlayanları etrafımda görebildiğim için durumun çok vahim olmadığını düşünüyorum. Evrimin bizi milyonlarca yıl sonra getirdiği noktayı her ne kadar çok iç açıcı bulmasam da çıkmadık candan ümit kesilmez gibi bir iyimserliğe sahibi bu yüzden.

Son olarak;

"ç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."

Umarım istediğinizi vermişimdir :)

Kendi adıma düşüncelerinizi paylaştığınız ve tartışmaya katıldığınız için memnunum. Türkçe konuşan dünyada derdimiz bu tür tartışmaların çokluğu değil bilakis genellikle yokluğu.

auselen
yaklaşık 16 yıl önce

C++ gibi bir şeyi sabit kabul edip birtakım reçetelerin sürekli uygulanmasını istemek ona kıyasla o kadar akılcı değildir.

C++'a şablonların (templates) eklendiğini gördük (çok yaşlı olduğumuzun ispatı değil elbette ki), yani C++'ın kendisi de sabit değil. Bir camiası var. Bir yol haritası var. Değişime kapalı değil. Ayrıca doğal seleksiyonun yavaşlığıda sadece böyle icatlara özgü de değil.

Karmaşıklık olarak (complexity, ayrıca iyi bir özellik, bir gelişme olarak algılayalım) bir inceleme yapalım mesela. C dili basitliği ile övünür. C++ ise buna bazı soyutlamalar ekler. Java ya da C# gibi diller C++'a birşeyler ekler ve çıkarır.

Karmaşıklık olarak C'ye 1 değerini verirsek, C++ 2, Java ya da C#'a 4 diyebiliriz herhalde.

Şimdi Java'ya yeni bir özellik ekleyerek karmaşıklığını 5'e çıkaralım. Yaptığımız şey, 1/4 lük bir gelişme :). Bu değişiklik kimsede C'den C++'a geçişteki gibi bir heyecan yaratmaz. Demek istediğim sistemler büyüdükçe, değişiklikleri gerçekleştirmek zor fakat insanları etkilemek daha da zor olabiliyor.

Tüm vampirleri öldürmeye muktedir bir gümüş kurşun olacaktır ya da hemen şimdi olsun demiyorum. Bu sanki denmiş gibi davranmak tıpkı MJD'ye verilmiş dikkat çekici bir cevapta olduğu gibi bir korkuluğa saldırmak (straw man argument) olacaktır.

Tasarım kalıplarının kendisini ya da programlama dillerinin zayıflıklarını yeni birşeymiş gibi göstermek için de bir isim bulmak lazım o zaman. (bu sözüm meclisten dışarı)

"kahretsin, bu X ve Y özelliği de nereden çıktı, sürekli öğrenmem gereken yeni şeyler çıkarıyorsunuz!"

Kullanıcılara (programcılara) hak vermediğim yerler yok değil doğrusu.

Java'nın geldiği noktaya bakalım¹.

static <T extends Object & Comparable<? super T>> T Collections.max(Collection<? extends T> coll)

ortada yeterince bol miktarda C programcısı varken struct ve fonksiyon pointer ile nesneye yönelik programlama reçetesini sürdürmek bunu nesilden nesile aktarmak iyi olmaz mıydı? C++ gibi bir sürü ekstra özellik barındıran bir şey çıkarmak yerine? Yahut 1950lerde ortada pek çok assembly programcısı ve yeterince para verken 'subroutine' denen tasarım reçetisini güzelce kitap haline getirip (o zaman işe yarayan diğer reçetelerle birlikte) bunu sürekli yeni programcılara öğretmenin zararı ne olurdu? Prosedürel diller geliştirmek yerine yani.

Burada uygun (optimum) noktadan bahsedebiliriz. Assembly ile yazmak ekonomik değil. Bu yazılacak kod'un uzunluğunu arttırması ile ilgili bile değil. Programcılar için assembly ile kod yazmak Java ile yazmaktan daha zor. Benim için lisp ile yazmak yine Java ile yazmaktan daha zor ve sanırım çoğunluk tarikatının iyi üyelerinden biriyim. Doğal olarak piyasa şartlarında çoğunluk tarikatının bulunabilir kaynak olarak değeri çok uygundur (optimum). Eminim lisp programcıları daha fazla para isteyeceklerdir :) ya da yeterince lisp programcısı eğitmek için onları eğitecek insanları eğitecek kurumları eğitecek düşünürleri eğitecek... uzaylılar? :)

İstediğim türden akıllıca davranışın en azından bazı örneklerinin en azından bazı durumlarda gerçekleşmiş olduğunu gördüğüm için

Ama akıllı davranış biçimi üzerine konuşmayacağım. Gerçekten olayı genelleştirmekten başka bir işe yaramayacaktır. Dune romanında şöyle bir cümle geçer "We are generalists. You can't draw neat lines around planet-wide problems. Planetology is a cut-and-fit science." ve ben buna inanırım. Bazı büyük problemlerin kesin çözümleri yoktur. Ne zeka ile, ne insan aklı ile.

Türkçe konuşan dünya

Ortak dileğimiz.

¹http://java.sun.com/developer/technicalArticles/Interviews/studentdevs/index.html#horstmann

küçük biri rica: lütfen fazlamesai'nin arayüzünü geliştirin. gerçekten eskidiğini düşünüyorum. kullanması oldukça zor olabiliyor.

FZ
yaklaşık 16 yıl önce

Akıllı davranış biçimi üzerine konuşmayı çok isterim. Çünkü ona inanmıyorum. Zekanın, akıllı davranışların dünyayı ne kurtaracağını ne de daha güzel bir yer yapacağına inanmıyorum. Bu bende programlama dillerinin akılcılığı üzerine bile etki ediyor. Programlama dillerinden beklentilerim benim işimi kolaylaştıracak şekilde gelişmeleri. Zekice olmaları değil (yukarıda ki java örneği).

Şimdilik şu noktalara değinmekle yetineceğim:

- Bir problemin çözümünü problem 'domain'indeki terimlerle olabildiğince kısa ve açık seçik olarak ifade edebilmek epey güzel, güçlü, üst seviyeli yani kısaca akıllıca soyutlama yapabilmenin bir örneğidir (nesneye yönelik tasarımın özündeki fikir tam olarak da bu değil mi?). Bunu yapabilen insanlar yapamayanlardan daha akıllıca iş yaparlar çünkü başkalarının da işini kolaylaştırırlar. Bu tür insanları daha akıllıca ve arzulanır olarak nitelemekte, o tür soyutlamaları hemencecik yapıp günlük pratiğin çok kolay kullanılabilir bir parçası haline getirmeye daha müsait olan araçların daha akıllıca tasarlanmış araçlar olduğuna bir itarazınız var mı, bunda bir beis görüyor musunuz?

- Verdiğiniz Java örneği işlerin ne kadar sarpa sarabileceğinin güzel bir örneği, ben de C#'taki 'delegate' lafından örnek verebilirim ve bir süredir bakmadım ama son zamanlarda sanırım C# programcıları anonim fonksiyonlar ile (3.0?) ile cebelleşiyor bir kısmı homurdanıp duruyordu. Eğer işler bu kadar arap saçına çevrilirse ben de homurdanırım ve haklı olurum herhalde. Marifet ben homurdanmaya başlamadan epey önce herhalde işlerin arap saçına dönmesini, en azından bu denli dönmesini bir nebze engelleyebilecek tasarımları desteklemek olamaz mı mesela? Söz gelimi anonim fonksiyonlar farklı bağlamlarda çok da basit şeyler olarak anlatılabiliyor ve hiç de homurdanmaya yol açmıyorlar (çünkü bunu gören öğrenciler içine girdikleri ekosistemin doğal, basit ve sıradan bir parçası olarak görüyorlar bunu, yepyeni şekilde pazarlanan teknik bir 'mumbo jumbo' olarak değil).

- Kesin çözümler yoktur demişsiniz. Canı gönülden katılıyorum. Java, C# ve C++'ın geldiği o karmaşık hale acaba tam da "kesin ayrımlar koyalım, bazı dünyaları birbirinden ayıralım, bazı yapıları dile eklemek sadece bazı ortamların kontrolünde olsun, işler çığırından çıkmasın, bazı şeyler uzmanlık gerektirir" şeklinde "düzgün çizgiler" çizmeye çalışan ve sonra karmaşıklıkla başa çıkmak için ek çözümler geliştirmeye çalışan düşünürlerin bakış açıları yol açmış olmasın diye düşünüyorum.

- Zekanın dünyayı kurtarıp kurtarmayacağı çok başka bir problem diye düşünüyorum. Burada, en azından özgün FM yazısında ortaya atılan çok daha pratik bir mesele gibi görünüyor bana. Eğer zekaya ve akıllıca davranışa inanmıyor olsa idiniz o zaman neden belli bir framework'ü diğerine, belli bir geliştirme aracını diğerine tercih ediyorsunuz sorusuna ne cevap veriyor oldunuz? Duygusal sebeplerle mi? Logosu daha iyi görünüyor yahut ismi kulağa daha hoş geliyor diye mi? Sırf birini daha çok insan kullanıyor ve onlarla birlikte çalışmanız gerekiyor diye mi? Teknik tercihlerinizi genel geçer ekonomik ve sosyal dalgalanmaların ötesinde biraz daha sağlam kazıklara bağlamaz mısınız, bunu da geçtim biraz daha meta seviyede bir soru sorayım, biraz daha sağlam kazıklara bağlama çabasının mantıksal açıdan saçma bir çaba olduğunu düşünmek için ne gibi argümanlarınız var?

auselen
yaklaşık 16 yıl önce

Akılcılık kavramını sizin ilk yazınızdaki akıl kelimesi üzerine kuruyorum. Tam yedi kez akıl kelimesi o ya da bu şekilde geçiyor. Beni ateşleyipte konuyu bu noktaya taşıyan sanırım bu oldu. Bunun dışında pozitif bilimler ile bir alıp veremediğim yok. :)

Genel olarak öfkem akıllı insanların sorunları çözüş biçimlerinin de akıllıca kabul edilmesi (bunu kabul edenler tabi ki akıllı olmayanlar). 'Akıllı' tanımının muğlaklığından bahsetmiyorum bile. Ortalama zeka/kabiliyet/beceri seviyesinde bulunan biri olarak akıllı insanlar ve onların yarattığı çöplük içinde yaşamaktan oldukça sıkıldığımı da ayrıca belirtmek isterim.

Yapılması gerekenin sorunları akılcılıkla değil kollektif bir şekilde çözmek olduğunu düşünüyorum. Kollektiflikten kastım, bir sorunu çözerken çözümün kitlelerden koparılmadan, çoğunluğun anlayabileceği şekilde ifade edilmesi gerektiği. Ortalama programcıların beceri seviyesinin üzerinde kullanılan teknikler belki istediğimiz mucizeleri yaratacaktır ama bunları programlama dili seviyesinde insanlara çok kolay yutulur lokmalarmış gibi vermeyi düşünmek sonunda önümüze java örneğini getiriyor.

Zevkime uygun programlama kitaplarında hep "kod bilgisayar için değil, programcılar için yazılır" dendiğini okumuşumdur. Okunabilirliği katleden özellikleri bu yüzden lanetliyoruz sanırım (yine java örneği :) ).

Soyutlama, genelleştirme, OOP'un getirdiği özelliklerin hiç birine karşı değilim. Ama bunları sunuş şekli çok önemli. Tasarım kalıplarının yaptığı işi burada destekliyorum (İlk çıkış noktamı biraz daha belirginleştiriyorum).

Programlama dili basit olmalı (Bildiğim kadarıyla dinamik programlama dillerinin övündüğü yanlardan biri de bu). Her desteklenen özelliğin bu basitlikten aldığını kabul etmeniz gerekir.

İlk kez C programlamayla ilgili çalışırken, dilin çok az sayıda anahtar kelime (keyword) içerdiğini ve bununda dilin basitliğinin bir göstergesi olduğunu okumuştum. Ben de bu fikre katılıyorum.

Dağınık aklımı toplamam gerekirse; programlama dilleri dersinde hep sorulan bir soru vardır: "en iyi programlama dili hangisidir?" (Hatta bu bana işe girerken bile sorulmuştur). Doğru cevabı ezberden "en iyi programlama dili o sorun alanına (domain) en uygun olanıdır" diye veririz. Ama bu doğrudur da, web programlama için C kullanmadığımız gibi, sistem programlama içinde php kullanmayız.

Bazı programlama dillerinin bazı özelliklerden yoksun olması daha iyidir. Genel programlama dili (Generic programming language) kavramının varlığını unutmayalım. Bu dillerin basit olması gerektiği sanırım su götürmez bir gerçek ve bu yüzden de bu dillerde çalışan insanların tasarım kalıplarına ihtiyaçları olacaktır. Sizin elinizdeki belirli alanlara yönelik ya da egzotik programlama dilleri bazı özellikleri kendi içlerinde barındırıyor olabilirler fakat bu onların bile içermediği bazı özelliklerin nasıl gerçekleştirileceğinin dokümante edilmesi gerektiğini saklamaz.

Kollektif çalışmak, bireysel akılcılıktan önemlidir.

FZ
yaklaşık 16 yıl önce

Zevkime uygun programlama kitaplarında hep "kod bilgisayar için değil, programcılar için yazılır" dendiğini okumuşumdur. Okunabilirliği katleden özellikleri bu yüzden lanetliyoruz sanırım (yine java örneği :) ).

Alıntıladığınız söz benim de çok sevdiğim bir söz. Ben o lafın bir benzerini ilk olarak "Programs must be written for people to read, and only incidentally for machines to execute." şeklinde görmüştüm, 'Structure and Interpretation of Computer Programs' kitabının önsözünde geçiyordu. Yazanlar ve hitap ettikleri kişiler sizin deyişiniz ile uzaylı mıydı yahut kolektif akıl olsun da, ortalama olarak iş yapıp yaptırabilelim de gerisi sorun değil yaklaşımı ne kadar doğru, bunu bilemiyorum. Akıllı insanların bazı durumda problem çıkarabilen çözüm önerilerine bakıp kişilerin dayandıkları mantıksal prensipleri, teknikleri, akıl yürütmeleri, vs. komple mahkum etmek ne kadar doğru bir tutumdur bilemediğim gibi.

auselen
yaklaşık 16 yıl önce

neo-Luddite mi gözüktüm? :)

birbirimizi daha fazla yanlış anlamadan yeni bir şeyler eklemeyi burada bırakıyorum ama konunun geldiği noktadan oldukça memnunum, eminim bu başlık için yeteri kadar tez/antitez ürettik :)

Son olarak siz muhakkak bilirsiniz ama kaçırmış arkadaşlar için: http://en.wikipedia.org/wiki/Why_the_future_doesn%27t_need_us

gentoo
yaklaşık 16 yıl önce

Karmaşıklık olarak C'ye 1 değerini verirsek, C++ 2, Java ya da C#'a 4 diyebiliriz herhalde.

Ben C++'nin de en az java veya C# kadar karmaşık olduğunu düşünüyorum :)

Java'nın geldiği noktaya bakalım¹.


static <: T extends Object & Comparable<:? super T>> T 

Collections.max(Collection<? extends T> coll)

Bu da C++ kodu. Yeterince karmaşık bence :o


class KelimeArttirici : public iterator <output_iterator_tag, void, void, void, void>

{

    / /

};

auselen
yaklaşık 16 yıl önce

C++'ın hepsinden karışık olduğuna neredeyse eminim aslında (java'ya biraz zaman tanıyın :) ). Değerlendirmeyi konunun gidişhatına göre yaptım. Java ya da C#'ın geliştiricileri zaten C++'ı çok karmaşık buldukları için bir çok özelliği kendi dillerine aktarmamışlardır.

myavuzselim
yaklaşık 16 yıl önce

C++ ornegi java ornegine gore cok cok daha basit. C++ orneginde iterator template'ine 5 tane parametre veriliyor, ve bunun sonucunda ortaya cikan sinif extend ediliyor. Java ornegini anlamakta gucluk cekiyorum. Anladigim kadariyla Collection parametresi alip T tipinde sonuc donduren ve su sinif hiyerarsisine bagli kalan bir fonksiyon tanimlaniyor:

gentoo
yaklaşık 16 yıl önce

Şimdi bir yanlış anlaşılma olmasın. Yukarıda örnek olarak verdiğim program C++'nin tekli tasarım deseni gerçeklemesi değil,sadece girişten gelen her farklı kelimenin kaç kere yazıldığını sayan bir program. Ve C++'nin karmaşık olabileceğini göstermek için yazdım tabi ki daha okunabilir bir şekilde yazılabilirdi. Tamamı da bu şekilde..

#include <iostream> #include <map> #include <string> #include <iterator> using namespace std; typedef map<string, unsigned int> Kelimeler; typedef pair<string, unsigned int> Sayac; class KelimeArttirici : public iterator<output_iterator_tag, void, void, void, void> { Kelimeler & kelimeler_; public: explicit KelimeArttirici(Kelimeler & kelimeler) : kelimeler_(kelimeler){} KelimeArttirici & operator= (const string & kelime) { ++kelimeler_[kelime]; return *this; } KelimeArttirici & operator*() { return *this; } KelimeArttirici & operator++() { return *this; } KelimeArttirici & operator++(int) { return *this; } }; namespace std { ostream & operator<< (ostream & cikis, const Sayac & sayac) { return cikis << sayac.first << '\\t' << sayac.second; } } // namespace std int main () { Kelimeler kelimeler; copy(istream_iterator<string>(cin),istream_iterator<string>(), KelimeArttirici(kelimeler)); copy(kelimeler.begin(), kelimeler.end(), ostream_iterator<Sayac>(cout, "\ ")); }

gentoo
yaklaşık 16 yıl önce

Bende java bilmediğim için java versiyonunu anlamıyorum :) Singleton tasarım deseninin C++ versiyonu da şu şekilde olabilirdi. Ancak bu program da singleton tasarım deseninin eksiklerinden nasibini alarak çoklu işletim (multi threading) kullanan programlarda doğru çalışmayabilir.

//singleton.h #ifndef SINGLETON_H #define SINGLETON_H class Tekli { public: static Tekli* ornek () { if (!pOrnek_) pOrnek_ = new Tekli; return pOrnek_; } int karesiniAl (int sayi) { return sayi * sayi; } private: Tekli () {} // Kod icinde yeni bir tekli nesnesi // olusturulmasini engelle Tekli (const Tekli &); // Kopyalama kurucusu kullanarak yeni bir tekli nesnesi // olusturulmasini engelliyoruz static Tekli * pOrnek_; // Tek ve biricik ornegimiz }; #endif // singleton.cc #include "singleton.h" #include <iostream> Tekli * Tekli::pOrnek_ = 0; using std::cout; int main () { int sayi = Tekli::ornek ()->karesiniAl (9); cout << sayi << '\ '; return 0; }

auselen
yaklaşık 16 yıl önce

c++'in daha karisik oldugunu one surerken verilen ornegi degil de, multiple inheritance gibi ozellikleri dusunmustum.

anonim
yaklaşık 16 yıl önce

Tasarim sablonlarının (orgu, desen vs.) tasarimin anlasilirligini arttirmaya ve iyilestirmeye yonelik oldugunu hatirlarsak onlarin varlikligini C++, C#, Java gibi dillerin eksiklikleri ile ilişkilendirmek açıkcası bana garip geliyor. Yani tamamen yeni bir programlama yaklasimi getiren bir dil gelse de onun icin yeni bir grup tasarim sablonunun uretilmiyecegi anlamina gelmiyor.

Bu nedenle yapilan butun tartismadan koptum acikcasi...

auselen
yaklaşık 16 yıl önce

Peki size birkaç soru...

Tasarım kalıpları programlama dillerine bağımlı mıdır? Bağımlı/bağımsız olmalı mıdır? Programlama diline özgü ise 'idiom'ların biraz gelişmişleri midir? Madem dilin bir eksiğini kapatmaya çalışan bir çözümünüz varsa onu niye dilin içine dahil etmeyesiniz? Yoksa dili basit bırakıp insanların beyinlerine bazı şeyleri koymakta iyi birşey midir?

... üzerine beyin cimnastiği yaptığımız bir sohbet sadece.

fz'in başta dediği gibi "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."

FZ
yaklaşık 16 yıl önce

Yoksa dili basit bırakıp insanların beyinlerine bazı şeyleri koymakta iyi birşey midir?

Düürrrt!!! diye düdüğümü çalıyor, kırmızı bayrağımı kaldırıyor, ofsayt! diye bağırıyorum hemen. Yahut ABD filmleri ile yetişmiş bir neslin aşina olduğu üzere heyecanlı avukat misalı sesleniyorum: "İtiraz ediyorum!"

Dile bir şey eklemek deyince neden aklımıza hep korkunç C++, Java ve C# örnekleri geliyor? Mesele dilde az ya da çok laf olması değil ki, mesele bunların kolay kullanılabilmesi ve analize kolay gelir olması. Mesele aklıma gelen süper bir soyutlamayı kolayca dilin bir parçası haline getirebilecek (dolayısı ile diğer insanların da hemencecik ve rahatlarını kaçırmadan hizmetlerine sunabilecek) mekanizmalara sahip olma meselesi (bu bakımdan belki doğal dil düşünülebilir). Yani başka bir deyişle, C++, Java ve C# kötü örneklerse kötü örnek örnek değildir ve bu işi yapmanın tek yolu da muazzam popüler olmuş o yaklaşımlar değildir denebilir. Hele de mevcut bir çözüme bakıp onun 'optimum' olduğunu iddia etmek konuyu bence teknik analizden çıkarıp 'yahu ne yapalım çok iyi bir çözüm gibi görünmeyebilir ama şimdilik elimizde bu var, piyasada hemen herkes bunu kullanıyor, ne yapalım başka şey dayatacak gücüm yok ki daha iyi önerilerim olsa bile' gibi bir söyleme dönüşür ki bu durumda pragmatik bakış açısını 'doğru olanı, daha iyi olanı bulma'nın üzerine yerleştirdiğimizin farkında olmalıyız en azından diye düşünüyorum.

auselen
yaklaşık 16 yıl önce

mevcut bir çözüme bakıp onun 'optimum' olduğunu iddia etmek konuyu bence teknik analizden çıkarıp 'yahu ne yapalım çok iyi bir çözüm gibi görünmeyebilir ama şimdilik elimizde bu var, piyasada hemen herkes bunu kullanıyor, ne yapalım başka şey dayatacak gücüm yok ki daha iyi önerilerim olsa bile' gibi bir söyleme dönüşür ki bu durumda pragmatik bakış açısını 'doğru olanı, daha iyi olanı bulma'nın üzerine yerleştirdiğimizin farkında olmalıyız en azından sanırım beni iyi bir mühendis yapan şey de tam olarak bu :)

yilmaz
yaklaşık 16 yıl önce

Tasarım kalıplarının bir dilin eksikliğinden ortaya çıkıyor düşüncesi yanlıştır. Tasarım kalıpları probleme dönük ortaya çıkar. Örneğin nesneye yönelik tasarım iş mantığının koda nasıl döküleceği üzerine ortaya çıkmıştır. Singleton ise api tasarımını belli kalıpların içerisine nasıl sokulacağı üzerinden yola çıkılarak hazırlanmıştır. Tasarım kalıplarının çıkış noktası her zaman geliştiriciyi yönlendirmektir. ( Örneğin birine oyun yazacağım diye sorsanız. Size Singleton pattern kullanmanızı önerecektir. Sebepleri arasında performans , prosedurel kod yazmaya izin vermesi , geri dönük uyumluluk sayılabilir. Yada java ile kod geliştirilen bir yerde sizden istenen nesneye yönelik tasarım hakkında bilgi sahibi olmanızdır.) Amaç sizi koda daha çabuk adapte etmektir. Sebep ne olursa olsun tasarım kalıplarının sunduğu şey dilin eksikliğini kapamaktan ziyade kodun okunabilirliğinin artması ve yeniden düzenlenebilmesi için geliştiriciyi yönlendirmektir. Eskiden on kişi bir kod üzerine çalışırken şimdi yüzlercesi çalışıyor ve herkesin aynı dili konuşabilmesi gerekiyor. Fakat zaman içerisinde yüksek seviyeli dilleri piyasaya sunanlar bu işlerin daha kolay yapılabilmesi için tasarım kalıplarını dillerin içerisine dahil etmeye çalıştılar. Son zamanlarda moda olan ise bu dillerin içerisine reflection yapıları kurmaktan öteye geçemedi. Bunun sebebi ise sattıkları dillerinin ömrünü fazladan birkaç sene daha uzatmak.

gentoo
yaklaşık 16 yıl önce

Genel olarak tasarım desenleri ile ilgili görüşlerinize katılmakla beraber sadece singleton ile ilgili görüşlerinize katılmıyorum.

Örneğin birine oyun yazacağım diye sorsanız. Size Singleton pattern kullanmanızı önerecektir. Sebepleri arasında performans , prosedurel kod yazmaya izin vermesi , geri dönük uyumluluk sayılabilir.

Şu anda okuduğum oyun programlama kitabında singleton tasarım deseni yoğun olarak kullanılmış. Ama Andrei Alexandrescu'nun Modern C++ Design ve Scott Meyers'in Item 10 in Effective C++ inceledikten sonra singleton tasarım deseninin aslında bir sorunlar yumağı olduğunu düşünmeye başladım. Konunun daha fazla ayrıntısı için yukarıda daha önce verdiğim iki bağlantıyı inceleyebilirsiniz.

Bu konuda bir kaç bağlantı:
http://steve.yegge.googlepages.com/singleton-considered-stupid
http://accu.org/index.php/journals/1470

Singleton kullanmak yerine sınıfın türünden bağımsız olarak bellek ayırma verme işlemlerini yapan akıllı sınıflar yazmak bence daha mantıklı..

yilmaz
yaklaşık 16 yıl önce

Örnekte hata olmaz. Singleton uygulanması çok zor bi kalıptır. Onu uygulamadan önce kağıt üzerinde tüm planınızı yapmış olmanız gerekir. Yoksa ileride yapacağınız bir değişiklik tüm uygulamanızı sallar. Özelikle c++ gibi memory yönetimini elinize aldığınız durumlarda dikkatli uygulanmalı.

FZ
yaklaşık 16 yıl önce

Sebep ne olursa olsun tasarım kalıplarının sunduğu şey dilin eksikliğini kapamaktan ziyade kodun okunabilirliğinin artması ve yeniden düzenlenebilmesi için geliştiriciyi yönlendirmektir.

Yani C++ gibi bir şey üretmek yerine C dilinde nesneye yönelik tasarım kalıplarını insanlara anlatıp durmak ve bunu kullanabilen programcıları da örnek gösterip herkesin onlar gibi olmasını istemek ve beklemek daha mı iyi olurdu sizce?

Eskiden on kişi bir kod üzerine çalışırken şimdi yüzlercesi çalışıyor ve herkesin aynı dili konuşabilmesi gerekiyor. Fakat zaman içerisinde yüksek seviyeli dilleri piyasaya sunanlar bu işlerin daha kolay yapılabilmesi için tasarım kalıplarını dillerin içerisine dahil etmeye çalıştılar.

Fena mı yaptılar? Bazı fikirleri sürekli detaylı reçeteler halinde yazıp karmaşık şeyler gibi sunmak yerine doğrudan dilin parçası haline getirip basit bir özellik olarak sunmak daha iyi değil mi? Somut bir örnek vereyim, Haskell, Oz, Erlang, ML, SML, F#, Qi, Prolog gibi dillerde 'pattern matching' denen bir özellik vardır. Bu özelliği kullanarak çok önemli veriyapıları olan ağaç, çizge, vb. yapılar üzerinde iş yapan algoritmaları kodlamak çok basit ve 'doğal' görünür. Bu tekniği kullanmaya alışırsanız ve bir süre sonra böyle bir özelliğin olmadığı bir ortamda o tür algoritmaları kodlamaya çalışırsanız kendinizi eliniz kolunuz bağlanmış gibi hissedebilir ve belki "yeter artık!" deyip o sevdiğiniz tekniği uygulamanıza izin verecek bir ek, bir tür preprocessor, parser, vs. yazmaya girişirken bulabilirsiniz kendinizi. Burada mesele şudur: İşlerinizi muazzam kolaylaştırmış olan özelliği, kalıbı dile katmak mı kolay, dile katmadan onu hatırlayarak ona benzer bir şeyler yapmak mı kolay? Bu soruya vereceğiniz mutlak bir cevap olamaz çünkü bazı dillerde bunu dile katmanız daha kolayken bazı dillerde bu eylemi aklınızdan daha geçirmeyeceğiniz durumlar söz konusu olabilir. Önemli olan seçeneklerin farkında olmak diye düşünüyorum.

Son zamanlarda moda olan ise bu dillerin içerisine reflection yapıları kurmaktan öteye geçemedi. Bunun sebebi ise sattıkları dillerinin ömrünü fazladan birkaç sene daha uzatmak.

Burada kafamı karıştıran bir şey var, çalışmakta olan bir programın kendisine dair meta bilgileri çalışma zamanında kurcalayabilmesi, inceleyebilmesi, değiştirebilmesi, vs. olarak da adlandırılabilecek 'reflection' bir moda mı? Yeni mi gündeme geldi? (Acaba C++ ve Java ile son zamanlarda ortaya atılan fikirlerin yepyeni fikirler olduğunu mu düşünüyoruz çok daha önceden başka platformlarda epey uygulamaları olmuş olmakla birlikte?) Hem moda hem kötü bir şey mi, bir pazarlama numarası mı?

auselen
yaklaşık 16 yıl önce

"I invented the term Object-Oriented and I can tell you I did not have C++ in mind."

http://c2.com/cgi/wiki?AlanKayQuotes

FZ
yaklaşık 16 yıl önce

Alıntı için teşekkürler. Bu alıntı ile değerli bilgisayar bilimci ve programcı Alan Kay'in kast ettiklerini bir yana bırakacak olursak sizin alıntılama sebebinizi ve yukarıda yazılanlarla ne şekillerde ilişki kurup nelere dikkat çekmeye çalıştığınızı da belirtirseniz eminim bundan faydalanacak yegâne insan ben olmam.

auselen
yaklaşık 16 yıl önce

C++ gibi bir şey üretmek yerine

demişsiniz. ilk başta alıntılamıştım ama sonradan her söylediğinize cevap vermeye çalışıyormuşum gibi anlamamanızı dilediğim için vazgeçtim.

Alan Kay'in alıntısı ile anlatmak istediğim ise, belki de bazı durumlarda belirli yaklaşımları var olan dillere eklemeyi çok doğru bulmayan 'iyi' bilgisayar bilimciler de mevcut. Yani bu bilimcileri kendi yanımda hissediyorum.

FZ
yaklaşık 16 yıl önce

Alan Kay'in alıntısı ile anlatmak istediğim ise, belki de bazı durumlarda belirli yaklaşımları var olan dillere eklemeyi çok doğru bulmayan 'iyi' bilgisayar bilimciler de mevcut.

Kesinlikle!

Yani bu bilimcileri kendi yanımda hissediyorum.

O zaman akıllı adamların akıllıca, zekice ve kıvrak çözümlerine (Smalltalk'u buna güzel bir örnek kabul ederim kendi adıma) karşı olmadığınız gibi "ne yapalım elimizde bu var, bunu optimum kabul edip, sabit kabul edip elimizden geleni yapmaya çalışalım" diyen türden bir "iyi mühendis" değilsiniz diye düşünüyorum. Yani eğer iyi bir mühendis iseniz o zaman bunun sebebi standart optimizasyon mantalitesi ile sınırlı kalmayıp innovasyona da açık olmanızda yatıyor olmalı. Yanılıyorsam düzeltin.

auselen
yaklaşık 16 yıl önce

duzeltilecek hicbir sey yok. sizin de belirttiginiz gibi, iyi muhendis olmak cok zor birsey.

sanirim bu konulari uzun sure baska basliklar altinda konusmaya devam edecegiz...

yilmaz
yaklaşık 16 yıl önce

Öncelikle şunu belirtmek lazım. C ve C++ aynı kategoride iki dil değildir. Söz konusu olan mevzu yeni bir dilin ortaya çıkması değil var olan dilin evrimidir. C nin içine nesne ekleyelim niyetiyle C++ ortaya çıkmamıştır. İkisi aşağı yukarı aynı şekilde yazılan bambaşka iki dildir.

İkinci verdiğiniz örneğin ise tasarım kalıpları ile ilgisini çözebilmiş değilim. Pattern-Matching bir tasarım kalıbı mıdır? Var olan dilin içerisine başka bir dilin içerdiği bir özelliği eklemek dilin evrimi ile alakalıdır tasarım kalıbıyla değil.

Reflection yeni bir konu değil. Yıllardır var. Fakat c# ve java gibi dillerde CLR yada JVM dinamik olarak nesne üretemiyor. Önceden nesnenin kalıbının oluşturulması gerekiyor. Özellikle EJB yada LINQ gibi yapıları kullanmaya kalktığınız da ortaya çıkan tonla sorunu bu reflection dediğiniz yapılar ile çözebiliyorsunuz. Eğer dinamik olarak nesne yada fonksiyon üretebilirseniz her türlü çözümü siz uygulamanıza daha kolay entegre edebilirsiniz.

auselen
yaklaşık 16 yıl önce

"C ve C++ aynı kategoride iki dil değildir. Söz konusu olan mevzu yeni bir dilin ortaya çıkması değil var olan dilin evrimidir. C nin içine nesne ekleyelim niyetiyle C++ ortaya çıkmamıştır. İkisi aşağı yukarı aynı şekilde yazılan bambaşka iki dildir."

http://en.wikipedia.org/wiki/C++ 'dan alinti ile cevap vereyim.

It was developed by Bjarne Stroustrup in 1979 at Bell Labs as an enhancement to the C programming language and originally named "C with Classes". It was renamed to C++ in 1983.

JVM ile ilgili soylediginiz "dinamik olarak nesne üretemiyor": kendi classloader'inizi yazarak bu isi yapabilirsiniz.

Reflection konusunda tam olarak ne demek istediginizi anlamadigim icin daha fazla yardimci olamayacagim.

yilmaz
yaklaşık 16 yıl önce

Bjarne Stroustrup kendi kitabından alıntı. C++ tasarlarken OO derken bunları kastetmiş. Wikideki bilgi eksiktir. C low-leveldir pasif bir dildir. C++ yüksek seviyeli bir dildir. Bu bile c++ c den türemiştir gibi saçmalık için yeterli bir kanıt olmalı. Bjarne Stroustrup un Why C++ is not just an Object-Oriented Programming Language makalesini okumanızı tavsiye ederim. Makale de derki C++ temel de çok farklı programlama teknikleri baz alınarak tasarlanmıştır. Ama temelde iki şeyden bahsediyor generic programlama ve OO design fakat bu ikisini desteklemeye çalıştığı için C++ taki OO design bozulmuştur.

Nesneye yönelik tasarım çok genel bir kalıptır. Başka bir tasarım kalıbının X dilindeki örneği üzerinden konuşmak lazım. C++,java , c# örneği tek başına doğru değildir. Örnek vermek gerekirse TDD,Prototype ,AOP hangi dilleri etkilemiştir.

Java ile ne yaparsanız yapın dinamik olarak nesne üretemezsiniz. X nesnesine Y özelliğini ekleyemezsiniz. PHP ile yada javascript ile yapabilirsiniz.

gentoo
yaklaşık 16 yıl önce

Bence siz bazı yerleri karıştırıyorsunuz ya da yanlışlıkla bir bölümü yazdınız sanırım.

Öncelikle şunu belirtmek lazım. C ve C++ aynı kategoride iki dil değildir.

Doğru

C nin içine nesne ekleyelim niyetiyle C++ ortaya çıkmamıştır.

Doğru

Söz konusu olan mevzu yeni bir dilin ortaya çıkması değil var olan dilin evrimidir.

Aynı fikirde değilim.. Gene wikipedia'daki Compatibility of C and C++ maddesini inceleyebilirsiniz.

C low-leveldir pasif bir dildir. C++ yüksek seviyeli bir dildir.

Hem C, hem de C++ yüksek seviyeli dillerdir. Bkz. High Level Programming Languages Assembly ya da makine dili gibi diller alt düzey dillerdir.

Bjarne Stroustrup un Why C++ is not just an Object-Oriented Programming Language makalesini okumanızı tavsiye ederim. Makale de derki C++ temel de çok farklı programlama teknikleri baz alınarak tasarlanmıştır.

C++'nin farklı programlama teknikleri kullanarak tasarlandığı doğrudur. Ama bunu örnek verirken C++ hem nesneye yönelik programlamayı hem de genel programlama tekniklerini (generic programming) destekler. Öyleyse C'ye yakındır diye mi örnek verdiniz. Eğer öyleyse C++'de generic programming'in en güçlü örneği Standart Şablon Kütüphanesidir ve bu C'de desteklenmez

Ama temelde iki şeyden bahsediyor generic programlama ve OO design fakat bu ikisini desteklemeye çalıştığı için C++ taki OO design bozulmuştur.

Hayır. C++ zaten tasarlanırken iki yanı keskin bir kılıç gibi hem generic programming hem de object oriented programming destekleyecek şekilde tasarlanmıştır. Biraz önce bahsettiğim gibi C++'nin en güçlü özelliklerinden biri olan Standart Şablon kütüphanesi tamamen generic programming'in bir örneğidir. Sınıf tasarımı konusunda da sanırım Bjarne Stroustroup'un ünlü bir sözü gibi "kibrit kutusuna savaş gemisi yerleştirmeye çalışmazsanız" bir problem yaşamazsınız.

yilmaz
yaklaşık 16 yıl önce

Sanırım bazı bölümlerde anlatmak istediğimi açık yazamamışım yada siz farklı yerlerinden yakalamışsınız. C ve C++ farklı iki dildir. Dolayısıyla aralarında yakınlık olsa da farklıdırlar. C low-level derken orda bir kavramı yanlış kullandım. low-level den kasıt hardware e yakın demek fakat orda prosedurel ve pasif bir dil olmasını vurgulamak istedim.

auselen
yaklaşık 16 yıl önce

Bu bile c++ c den türemiştir gibi saçmalık için yeterli bir kanıt olmalı.

http://www.research.att.com/~bs/bs_faq.html#difference

Yukarıdaki sayfa B. S.'in kendisine ait. Diyor ki;

'C++ is a direct descendant of C that retains almost all of C as a subset.'

Çevireyim sizin için; 'C++ doğrudan C soyundan gelir, C'nin neredeyse tümünü altkümesi olarak barındırır.'

Herhalde başka şeylerden konuşuyoruz. İnsanların niye genel olarak C/C++ dediğini zannediyorsunuz? Niye ikisini genelde aynı anda ağıza alıyorlar?

Elbette farklı diller, yoksa kimse C++'ı C'den ayırmazdı. Ama C++, C ile aynı kategoridedir, çünkü o kategoride neredeyse C'dir. C, C++ ile kendi bulunduğu kategori dışında yarışamaz, çünkü 'sonradan eklenen' özellikleri desteklemez.

C low-leveldir pasif bir dildir.

Bu ne demek? İlk defa pasif programlama dili diye birşey duydum. İnternette aradığımda da karşıma benzer birşey çıkmadı.

Java ile ne yaparsanız yapın dinamik olarak nesne üretemezsiniz. X nesnesine Y özelliğini ekleyemezsiniz. PHP ile yada javascript ile yapabilirsiniz.

Daha önce söylediğiniz bu değildi. Siz JVM dinamik olarak nesne üretemiyor. dediniz. Ben de ona göre cevap verdim. Herkesin bildiği gibi Java dilinde böyle bir özellik direk olarak desteklenmiyor. Ama JVM bunu sizin daha önceden söylediğinizin aksine destekliyor¹.

Bu belki Java ileride bu özelliği destekleyebilir ya da isterseniz bazı kitaplıklarla² bunu yapabilirsiniz demek. Ama aynı zamanda, şu anda Java'da bunu yapabilirsiniz demek. Yani yine de dediğiniz şey doğru değil.

¹ http://www.ibm.com/developerworks/java/library/j-dyn0203.html
² http://www.csg.is.titech.ac.jp/~chiba/javassist/

yilmaz
yaklaşık 16 yıl önce

Peki şunu örnekleyin o zaman. X nesnesine dinamik olarak Y fonksiyonunu ekleyin sonra bunu Z clasınızın herhangi bir yerinden çağırın. Bunu yapamazsınız. Çünkü Z class'ı X nesnesinin içinde Y fonksiyonunun olduğunu bilmez. javaassit byte code manipule eden bir yazılımdır ve class 'ın orjinal tanımının dışına çıkamaz. Bu yeterli bir örnek oldu mu? Dinamik olarak nesne üretebilseydi bu kadar xml configure etmekle yada anotations ile uğraşmazdık.

yilmaz
yaklaşık 16 yıl önce

C ve C++ arasındaki farklar.

http://www.cprogramming.com/tutorial/c-vs-c++.html

yilmaz
yaklaşık 16 yıl önce

Keşke vermiş olduğunuz linkteki paragrafın sonunda verilen "differences between C++98 and C99" bölümüne de bir göz atsaymışsınız.

yilmaz
yaklaşık 16 yıl önce

Vermiş olduğunuz linkin hemen üzerinde de şu var.

In the strict mathematical sense, C isn't a subset of C++. There are programs that are valid C but not valid C++ and even a few ways of writing code that has a different meaning in C and C++.

http://www.research.att.com/~bs/bs_faq.html#C-is-subset

anonim
yaklaşık 16 yıl önce

Tasarim programlama dilinden cok programlama paradigmalarina bagimlidir. Tasarim kaliplari da tasarima yonelik oldugu icin onlari programlama dillinden cok paradigmalar ile iliskilendirmek daha dogru olacaktir. Zaten bakarsak GOF kaliplari klasik cohesion-coupling problemleri ile nesne tabanli bir perspektif uzerinden bogusur ki bu problem yine dilden bagimsiz olarak kurculanan bir husustur.

Model-driven-architechture (MDA) uzerinden gidersek, platform independent model (PIM) cesitli tasarim kaliplari icerebilir. Burdan platform-specific-model'e (PSM) gecerken dil bagimli cevrim gerceklestirilir. Dolayisi ile ortada bir dil yokken, sadece nesne tabanli yaklasim varken siz tasarim kaliplarini kullanmaya baslarsiniz.

Diger bir nokta ise; siz nesne tabanli degil X tabanli bir tasarim yapsaniz, hatta birakin yazilimi bina tasarliyor olsaniz da er yada gec tasarimi daha iyi ve daha anlasilir hala getirmek icin cesitli kaliplar ortaya cikacaktir.
Ha tabi bir gun oyle bir programlama paradigmasi ortaya cikartilir ki tasarim yapmaniza gerek kalmaz, o zaman kaliplara gerek kalmayacagi varsayilabilir (teorik olarak bile mumkun mudur - ayri bir beyin jimnasitigi). O zaman yapilan isin bir muhendislik dali oldugu da bence soylenemez.

auselen
yaklaşık 16 yıl önce

Advanced Topics In Programming Languages: Closures For Java

http://video.google.com/videoplay?docid=4051253555018153503&ei=Yid_SbWZMYqGjQLSmuSeCw&q=closures

FZ
yaklaşık 16 yıl önce

Advanced?

auselen
yaklaşık 16 yıl önce

Bu açıdan düşünmemiştim açıkçası :) ama umarım sohbete kapalı değilsinizdir ya da videoya şöyle bir göz atmışsınızdır.

Çünkü 2:44'te diyor ki; "Gelecek 30 yıl içerisinde insanlar, Closures özelliği olmayan bir programlama dili icat etmeye çalışan kişilere güleceklerdir, tıpkı şimdi özyinelemeli yapıları desteklemeyen programlama dillerini icat etmeye çalışanlara güldükleri gibi" - Mark Jason Dominus. Konuşma içerisinde de bu sözün High Order Perl kitabıyla ilgili verdiği bir mülakatta geçtiğini söylüyor.

Geçenlerde (baya oldu aslında) kendim için küçük bir program yazmaya çalışıyordum. Kontrol düzeneği tam olarak aynı şekilde çalışan fakat farklı işler yapan üç for döngüsü oluşturdum, herbiri bir methodun içerisindeydi. Daha sonra duruma göre bu methodların artabileceğini, bazı durumlarda geriye bazı değerler döndürebileceğini farkettim. O anda Java'nın bana, kontrol yapıları kurmama izin vermediğini farkettim. Daha önce senelerce bu durumu farketmeden/yokluğunu hissetmeden yaşamış olan ben, o anın şaşkınlığıyla ve aydınlanmasıyla hemen "Closures olarak bahsedilen programlama dili özelliğinin" bununla ilgili olduğunu anladım.¹

¹http://ileriseviye.org/blog/?p=1429

FZ
yaklaşık 16 yıl önce

Sohbete her zaman açığım :)

Video linki için tekrar teşekkürler. MJD'ye gelince, sevdiğimiz saydığımız bir isim. Perl söz konusu olunca Perl 6'ya diğer dillerde yıllardır var olan dolayısı ile artık pek de 'advanced' sayılmayan özelliklerin ekleneceğini öğrendiğimde sevinmiştim ('better late than never'). Benzer şeyler Java ve C# için de geçerli. Camianın tüm duygusal tepkilerine rağmen en-bi-advanced-sofistike (!) konseptlerin bu dillere katılması ('sen şimdi direniyorsun ama her şey senin iyiliğin için yavrucuum' (buyrun 'benevolent dictator' tarzı ;-)) daha nice güzelliklere gebe olacaktır (ve bilgisayar bilimcisi olmayıp, doktora almayıp ekmeğini kod yazarak kazanmaya çalışan 'normal' programcılar da o en bi gelişmiş özelliklerden faydalanacaklardır süreç içinde, bazı durumlarda hükümetimizin dediği gibi, acı şurubu içmek lazım :).

Sizin verdiğiniz örnek de güzel. Bu tür örneklerin çoğalmasını dilerim. Bunlar ne kadar çoğalırsa bazı camialardaki psikolojik direnç de azalacaktır diye düşünüyorum (konuyu sıfırsan öğrenen programcılarda zaten o tür önyargısal psikolojik dirençler olmuyor, onlar o çok gelişmiş özellikleri zaten dilin olmazsa olmaz mekanizmaları olarak öğrenip işlerine güçlerine bakıyorlar ve o mekanizmalar olmadan bazı şeyler ne kadar zor olurdu bunu düşünmelerine gerek dahi kalmıyor (hash table denen konsept olmadan program yazmanın nasıl bir şey olacağını asla tahayyül edemeyen sadece-PHP-ile-kodlayan kişiler gibi mesela).

Görüş belirtmek için giriş yapın...

İlgili Yazılar

MySQL GNU/Linux Desteğini Sınırladı

vst
13 Aralık 2006, 1 dakika okuma süresi

Slashdot haberine göre, MySQL yeni destek stratejisi doğrultusunda sadece RedHat ve SuSE Enterprise ürünlerine destek verecek.

Bahsi geçen destek stratejisi önceden "MySQL Network Support Plan" iken, şimdi "MySQL Enterprise Support Plan" ile değiştirilmiş.

Bakalım, bu gelişme PostgreSQL kullanıcılarının sayısını arttıracak mı?

Güncelleme: Bu haber MySQL müşteri temsilcisinin yanlış bilgilendirmesinden kaynaklanıyormuş. hedele'ye bilgilendirdiği için teşekkürler.

Az bilinen bir işletim sistemi: Plan 9

misafir
26 Haziran 2005, 2 dakika okuma süresi

Bell laboratuvarlarının bilgisayar dünyasına katkısı UNIX(TM) ve C dilinden ibaret değil. İlk kez 1993'te dağıtılan ve 2002'de bir özgür yazılım lisansına kavuşan Plan 9 işletim sistemi de bu katkılardan biri.

ÖNEMLİ UYARI : `Bios Logosunu Değiştirelim´ Makalesi Hakkında

crematorium
4 Mart 2003, 1 dakika okuma süresi

Geçenlerde yazdığım ve FZ arkadaşımızın da duyurduğu Bios Logosunu Değiştirelim makalesi hakkında önemli bir uyarı yapmam gerekiyor.

Kendi makinamda Logo'mu zaten değiştirmiştim. Dün gece logodan sıkıldım ve yeniden değiştirmek istedim. Büyük bir hata yaparak daha önceden içine Logo yüklediğim "Bios Binary" dosyamın üzerine tekrardan bir logo attım ve AWDFLASH ile `flash´ladım. Makinayı yeniden başlattığımda maalesef Bios'umun elimde kaldığını farkettim. Şimdi gelelim uyarıya:

`Hacker´lar ve Ressamlar

FZ
15 Mayıs 2003, 2 dakika okuma süresi

LISP hacker´ı Paul Graham, bilgece makaleleri ile yazılım camiasında büyük spekülasyona yol açmaya devam ediyor.

Üniversitenin bilgisayar bilimi bölümünden mezun olduktan sonra bir sanat okuluna gidip ressamlık üzerine eğitim alan ve büyük ressamlar ile büyük `hacker´ların benzer mantalite ile çalıştıklarını iddia eden Graham, Hackers and Painters başlıklı son makalesinde bu benzerliğe değinmenin yanı sıra iş dünyasından ve açık kaynak kodlu programlama paradigmasının sessiz sedasız yol açtığı devrimden dem vuruyor çok detaylı ve eğlenceli bir şekilde.

Windows XP, 2000 ve 2003 kurulumunu katılımsız hale getirmek

pulkas
15 Mart 2006, 1 dakika okuma süresi

Windows kurulumunu hiç bir zaman bu kadar otomatik hale getiremeyeceğiz.

unattended.msfn.org adresinde İngilizce, windocs.org adresinde de Türkçe olarak anlatılanlarla tamamen size özel ve hiçbir kurulum yönergesinin takip edilmek zorunda kalınmadığı otomatik, katılımsız, kurulum cd'si hazırlanabiliyor.