Sıradışılıkla Kazanmak - Bir Common Lisp Başarı Öyküsü

0
FZ
1990'lı yılların ortasında Lisp ile geliştirdiği e-ticaret sistemini Yahoo şirketine 40.000.000$'a satan Paul Graham'ın Beating The Averages başlıklı makalesini FM üyeleri ile paylaşıyor ve faydalı olmasını, olabildiğince geribesleme üretmesini ümit ediyoruz. Çeviriye önayak olan, sponsorluğu üstlenen değerli FM üyesi bm'ye ve çevirinin ilk halini gerçekleştiren İstanbul Bilgi Üniversitesi, Bilgisayar Bilimleri Bölümü öğrencilerinden Çağıl Uluşahin'e teşekkürlerimizi sunuyoruz. Bu belgenin orjinal adresine buradan erişebilirsiniz.

Sıradışılıkla Kazanmak *

Nisan 2001, rev. Nisan 2003

(Bu makale, 2001 Franz Geliştirici Sempozyumu'ndaki bir sunumdan derlenmiştir. Hala Yahoo! Store olarak kullanımda olan ve şu sıralar 20,000 mağaza ile en popüler elektronik ticaret yazılımı olan Viaweb Store'u, Lisp kullanarak nasıl yazdığımızı anlamaktadır.) [1]

1995 yazında, arkadaşım Robert Morris ile Viaweb isimli bir şirket kurduk. Amacımız, son kullanıcının Internet üzerinden elektronik mağazalar kurmasını sağlayacak bir yazılım geliştirmekti. Bu yazılımı diğerlerinden farklı kılan ise arayüz olarak web sayfalarını kullanarak kendi web sunucularımızda çalışmasıydı.

Bunu ilk düşünen biz değildik belki de ama ilk hayata geçiren biz olduk. Bildiğim kadarıyla Viaweb, web tabanlı ilk uygulamaydı. Bu fikir bize o kadar değişik gelmişti ki şirketin adını Viaweb koymaya karar verdik çünkü yazılımımız "web yoluyla" (via web, ÇN:Latince "via": yolu ile, aracılığıyla) çalışıyordu.

Bu uygulama hakkında alışılmamış olan diğer bir şey ise o zamana kadar üniversiteler ve araştırma laboratuarları dışında pek kullanılmayan Lisp isimli bir programlama diliyle yazılmış olmasıydı. Viaweb, Lisp ile yazılmış, son kullanıcıya yönelik ilk büyük çaplı uygulamalardan biriydi. Rakiplerimizin kullandıkları programlama dillerinden çok daha etkili olduğu için Lisp bize büyük avantajlar getirdi.

Gizli Silah

Eric Raymond "Nasıl Hacker Olunur" isimli yazısında, hacker adaylarına diğer konuların yanında hangi dilleri öğrenmeleri gerektiğini de anlatır. Öğrenme kolaylığı bakımından Python ve Java'yı önerir. Ciddi bir hacker ise, UNIX üzerinde çalışabilmek için C, sistem yönetimi ve CGI komut dosyaları için Perl bilmeli diye devam eder. Son olarak da gerçek bir "hacker"ın Lisp öğrenmesi gerekliliğini şöyle açıklar:

Lisp, sırf size katacağı şeyler ve açacağı geniş ufuklar için bile öğrenmeye değerdir. İleride hiç kullanmayacak olsanız bile size kazandırdığı deneyimler sayesinde hayatınızın geri kalan kısmında daha iyi bir programcı olmanızı sağlayacaktır.

Bunlar, Latince konusunda duyacaklarınızın aynısıdır. Latince öğrenmek size bir iş imkanı sağlamayacaktır ama zekanızı geliştirecek ve sizi istediğiniz herhangi bir dilde iyi bir yazar yapacaktır.

Ancak bu, bir noktadan sonra çok da iyi bir benzetme değil. Latince öğrenmenin sizi bir meslek sahibi yapmayacak olmasının sebebi kimsenin Latince konuşmamasıdır. Latince konuşursanız kimse sizi anlamaz. Bu durumdan farklı olarak Lisp bir bilgisayar dilidir ve bilgisayarlar programcıların istediği her dili konuşabilir.

Öyleyse, Eric Raymond'ın da dediği gibi, Lisp sizin daha iyi bir programcı olmanızı sağlayacaksa neden onu kullanmayasınız ki? Bence mesela bir ressama onu daha iyi bir ressam yapacak bir fırça teklif edilse, bütün resimlerinde o fırçayı kullanmak istemez miydi? Eric Raymond'la dalga geçiyor falan değilim. Tavsiyelerini genel olarak iyi buluyorum. Lisp hakkında söyledikleri ise alışılagelmiş sözler fakat bu kalıplaşmış sözlerde bir çelişki var: Lisp sizin daha iyi bir programcı olmanızı sağlayacak ve buna rağmen siz bu dili kullanmayacaksınız!

Neden olmasın? Programlama dilleri sadece bir araç sonuçta. Lisp gerçekten daha iyi programlar yazmanıza imkan tanıyorsa, bunu neden değerlendirmeyesiniz? Ve eğer böyle değilse Lisp'i kim ne yapsın?

Bu sadece teorik bir soru değil. Yazılım dünyası şiddetli rekabetin olduğu ve tabii tekellesmeye yatkın bir sektördür. Daha iyi ve daha hızlı bir yazılıma sahip olan şirket, diğer tüm koşullar eşit olsa bile, rakiplerini işsiz bırakır. Yolun başındayken bunu şiddetle hissedersiniz, yanlış bir teknoloji seçerseniz rakipleriniz sizi ezer, yok eder.

Viaweb'e başlarken, ikimiz de Lisp konusunda tecrübeliydik ve içgüdülerimize güvenip Lisp ile yola çıkmamak için bir neden göremiyorduk. Diğer herkesin C++ veya Perl kullandığını biliyorduk ve bunun hiçbir şey ifade etmediğini de -- teknolojiyi böyle seçiyorsanız, Windows kullanıyor olurdunuz. Kullanacağınız teknolojiyi belirlerken, herkesin ne yaptığına bakmayıp, hangisinin en iyi olduğunu ölçüt almalısınız.

En azından yolun başındaki şirketler böyle yapmak zorundadır. Büyük bir şirket kendi ayarındaki diğer şirketler gibi hareket edebilir fakat sektörde yeni şirketlerin böyle bir lüksü yoktur. Ne yazık ki bir çok kişi bunun farkına varamıyor.

Büyük bir şirket normalde yılda ortalama %10 civarında bir büyüme gösterir. Yani büyük bir şirket yönetiyorsanız ve her şeyi standart yapıyorsanız ancak denginiz olan şirketler kadar iyi bir performans göstermeyi bekleyebilirsiniz, bu da yılda %10 civarında bir büyümedir.

Aynı şey, yeni kurulan şirketler için de geçerlidir. Eğer her şeyi ortalama bir düzeyde yapıyorsanız, ortalama bir başarıdan fazlasını bekleyemezsiniz. Sorun şu ki ortalama bir başarının üzerine çıkamamak, sektöre yeni adım atan şirketler için batmak anlamına gelir. Bu şirketlerde ayakta kalma oranı %50'dir. Yani siz de onlardan biriyseniz, alışılmışın dışında hareket etseniz iyi olur. Aksi takdirde başınız belada demektir.

1995'te rakiplerimizin bilmediği bir şey biliyorduk. Kendinize ait sunucularda çalışacak bir yazılımı geliştirmek,için istediğiniz dili kullanmakta özgürsünüzdür. Bugün bile, birçok kişi bunu anlayabilmiş değil. Masaüstü yazılımlarda, işletim sistemiyle aynı dili kullanmak gerektiğine dair genel bir önyargı var. Tamam, on yıl önce uygulama geliştirmek demek C dili demekti, ama web tabanlı yazılımlarla birlikte bu anlayış ortadan kalktı. Özellikle de hem dilin hem de işletim sisteminin kaynak kodları elinizdeyse, istediğiniz dili kullanmamanız için hiç bir engel yok ortada.

Ancak bu yeni özgürlüğün avantajlarını olduğu gibi dezavantajlarını da göz önünde bulundurmak gerekiyor. İstediğiniz dili kullanabilme özgürlüğü beraberinde, karar vermeden önce iyice düşünme gerekliliğini getiriyor. Bu değişime ayak uydurmak için herhangi bir girişimde bulunmayan şirketler rakiplerinin değişime duyarlı olmaları durumunun getireceği riski göze almış olur.

Peki seçme hakkınız olsaydı, siz hangi dili seçerdiniz? Biz kendi adımıza Lisp'i tercih ettik, zira bu sektörde hızlı büyümenin ne kadar önemli olduğu açık ve net bir biçimde ortada. Her birimiz sıfırdan başlıyorduk. Yani yeni özellikleri rakiplerinden daha önce uygulamaya koyabilenler büyük avantaj sağlayacaktı. Hızla yazılım geliştirmek için Lisp'in ideal olduğunu biliyorduk. Sunucu tabanlı uygulamalarla da bu avantajımızı ikiye katlayacaktık, çünkü bu uygulamalar sayesinde yazılımı hazır olduğu an yayınlayabilecektik.

Diğer şirketlerin Lisp kullanmak istememesi bizim için çok daha iyiydi. Bu bize teknolojik bir üstünlük sağlıyordu ve en ufak bir rekabet avantajı bile bizim için önemliydi. Viaweb'e başladığımızda hiç bir iş tecrübemiz yoktu. Ne eleman almak hakkında bir şey biliyorduk, ne pazarlama, ne müşteri edinme, ne de para kazanma -- hatta hiçbirimiz o zamana kadar adamakıllı bir işte çalışmamıştı. Tek iyi olduğumuz konu yazılımdı ve bunun da bizi kurtarmasını umuyorduk. Yazılımda elde edebileceğimiz bütün avantajlardan yararlanmalıydık.

Yani Lisp'i kullanmak bir denemeydi diyebiliriz. Planımız şöyleydi: Lisp kullanarak rakiplerimizden çok daha çevik olacak ve yazılımımızda onların yapamayacakları şeyleri yapacaktık. Lisp çok üst düzey bir dil olduğundan, büyük bir geliştirme takımına ihtiyaç duymayacaktık. Böylece maliyetimiz daha düşük olacaktı. Bu koşullarda daha az paraya daha kaliteli bir hizmet verebilecek ve buna rağmen kâr edecektik. Sonunda da bütün müşterileri toplayıp, rakiplerimizi işsiz bırakacaktık. En azından böyle olmasını umuyorduk.

Bu denemenin nasıl sonuçlandığını soracak olursanız, biraz da şaşırtıcı bir şekilde planımız işe yaramıştı. Bir çok rakibimiz oldu ama hiçbirinin yazılım bizimkiyle yarışamadı. WYSIWYG ("What You See Is What You Get") modunda çalışan bir çevrimiçi mağaza editörümüz vardı. Sunucuda çalışmasına rağmen bir masaüstü uygulaması hissi uyandırıyordu. Rakiplerimizin çoğu CGI komut dosyaları kullanıyordu ve her zaman özelliklerimizle onlardan açık ara öndeydik. Bazen bizde olmayan yeni özellikler yayınlıyorlardı. Ama Lisp sayesinde yazılım geliştirme döngümüz o kadar hızlıydı ki onlar yayınladıkları yeni bir özelliğin basın açıklamasını yaptıktan bir iki gün sonra aynı özelliği biz de eklemiş oluyorduk.

Rakiplerimize, gizli bir silahımız olduğu izlenimini vermiş olmalıyız. Aslında vardı, fakat sandıklarından çok daha basit bir şeydi. Bilgi sızdıran bir ajanımız falan yoktu sadece kimsenin ihtimal vermediği bir hızla yazılım geliştirebiliyorduk.

On yaşlarındayken Frederick Forsyth'ın "The Day of the Jackal" (BM bunu Turkcesi vardir) isimli kitabı elime geçmişti. Ana karakter, Fransa cumhurbaşkanını öldürmekle görevlendirilen bir suikastçıydı. Polisi atlatıp cumhurbaskaninin rotası üzerindeki bir binaya girmesi gerekiyordu. Koltuk değnekli yaşlı bir adam kılığına girip polislerin yanlarından geçmişti ve bir kişi bile ondan şüphelenmemişti.

Bizim gizli silahımız da buna benzerdi. Yazılımımızı, parantezlerle dolu, garip sözdizimi olan tuhaf bir yapay zekâ dilinde geliştiriyorduk. Lisp hakkında söylenen bu tür şeyler yıllarca beni çok rahatsız etmişti ama şimdi işimize yarıyordu. İş alanında, rakiplerinizin anlayamadığı teknik bir üstünlükten daha iyi bir şey olamaz. Savaşta olduğu gibi ticarette de akıllıca sürprizler kaba güç kadar hatta bazen daha da değerlidir.

Biraz da utanarak itiraf ediyorum ki Viaweb'de çalışırken Lisp hakkında alenen hiç konuşmadım. Basının önünde Lisp'in adını hiç anmadık. Sitemizde Lisp'i arattırsaydınız tek bulacağınız biyografimdeki iki kitabın isimleriydi. Bu bir tesadüf değildi. Yeni kurulan bir şirket mümkün olduğunca az deşifre olmalıdır. Uygulamamızı hangi dilde yazdığımızı bilmiyor veya umursamıyorlarsa, böyle kalması daha iyiydi.[2]

Teknolojimizden en iyi anlayan müşterilerimizdi. Viaweb'in hangi dilde yazıldığı umurlarında değildi ama gerçekten iyi çalıştığının farkındaydılar. Kelimenin tam anlamıyla birkaç dakika içinde çevrimiçi mağazalar kurmalarına imkan tanıyordu ve bu sayede kullanıcılarımız hızla artıyordu. 1996 yılının sonlarına doğru 70 çevrimiçi mağazamız olmuştu, 1997'nin sonunda 500 ve bundan altı ay sonra Yahoo bünyesine katıldığımızda ise 1070 kullanıcıya ulaşmıştık. Bugün aynı yazılım Yahoo Store olarak sektördeki egemenliğini sürdürüyor. 1999 yılında Yahoo'dan ayrıldığım için şu an tam olarak bilmiyorum ama son duyduğumda 20,000 civarlarında kullanıcıları vardı.

Blub Paradoksu

Peki Lisp'i bu kadar iyi yapan ne? Ve eğer bu kadar mükemmelse neden kimse Lisp kullanmıyor? Bunlar cevap beklenmeyerek sırf bir etki yaratması için sorulmuş sorular değil, tam tersine çok açık ve net cevapları var. Lisp sadece tutkunlarının bildiği, gizemli özellikleri yüzünden değil, mevcut en etkili dil olduğu için bu kadar iyi. Lisp kullananların sayısının fazla olmamasının nedeni ise programlama dillerinin sadece teknolojiler değil, bir o kadar da zihin alışkanlıkları olması. Kabul edersiniz ki alışkanlıktan daha yavaş değişen bir başka şey de yoktur. Elbette bu iki cevap da açıklama gerektiriyor.

Şaşırtıcı bir biçimde herkesin hemfikir olmadığı, hala tartışmalara yol açan bir ifadeyle başlayacağım: Programlama dilleri güçlerine göre sınıflandırılır.

Bir çok kişi, en azından, üst düzey dillerin makine dilinden daha güçlü olduğunu kabul ediyor. Bugün çoğu programcı normal şartlarda kimsenin makine diliyle programlama yapmak istemeyeceği konusunda hemfikir. Bunun yerine üst düzey bir dilde programlama yapıp, onu sizin için makine diline çevirecek bir derleyici kullanmalısınız. Şimdi donanımda bile bu mantık gözetiliyor, 1980lerden beri komut kümeleri bile programcılardan ziyade derleyiciler için dizayn ediliyor.

Herkes bütün programı makine dili kullanarak yazmanın ne kadar yanlış olduğunu bilir. Daha genel fakat daha az bilinen bir prensip ise şudur: Eğer önünüzde birkaç dil seçeneği varsa, diğer tüm özellikleri eşit diller arasında en güçlü olanını seçmemek büyük bir hatadır.[3]

Bu kurala dair bir çok istisna vardır. Belli bir dille yazılmış bir programla çok yakın çalışacak bir diğer program yazıyorsanız, yazacağınız programı da aynı dille yazmak iyi bir fikir olabilir. Eğer basit işlemler yapacak bir program yazıyorsanız, özelikle daha hızlı çalışacağı için daha soyut bir dil kullanabilirsiniz. Kısa ve daha sonra kullanmayacağınız bir program yazıyorsanız da, yapacağınız işe en uygun kütüphanelere sahip dilde yazmanız en iyisi olur. Fakat uygulama yazılımları için genelde mevcut olan en güçlü ve etkili dili kullanmak varken başka bir dil kullanmak, aynı seviyede olmasa da, makine diliyle programlama yapmakla aynı çeşit bir hata olacaktır.

Makine dilinin ne kadar düşük seviyeli bir dil olduğu ortada fakat herkes en azından genel bir kanı olarak bütün üst düzey dillerin eşit olduğunu düşünüyor, ama değiller. Teknik olarak "üst düzey dil" terimi çok belirleyici bir ifade değil. Makine dillerinin bir yanda yüksek seviyeli dillerin diğer tarafta olduğu belirli bir ayrım yok. Diller kendi içlerinde en güçlü olanından başlayarak makine diline kadar uzanan, soyut bir güç sıralamasına konulurlar.[4]

COBOL'u ele alalım, makine diline derlenmesi bakımından yüksek seviyeli bir dildir. Ama hiç kimse COBOL'un Python gibi bir dil ile kıyaslandığında eşit güçte olduğunu iddia edemez. Muhtemelen COBOL güç sıralamasında makine diline Python'dan çok daha yakındır.

Veya Perl 4'ü ele alalım. Perl 5 ile aralarındaki fark, sözcüksel kuşatma ("lexical closure") özellğinin eklenmiş olmasıdır. Çoğu Perl programcısı Perl 5'in Perl 4'ten çok daha güçlü olduğu konusunda fikir birliğindedir. Ama bunu kabul etmek üst düzey bir dilin bir diğerinden daha güçlü olabileceğini kabul etmektir ve bu da bütün üst düzey dillerin eşit olmamasının yanısıra yazılımlarınız için mevcut en güçlü dili kullanmalısınız tezine de örnek teşkil eder.

Ne yazık ki bunu hayata geçirmek o kadar da kolay değildir. Programcılar belli bir yaştan ve belli bir tecrübe edindikten sonra mecbur kalmadıkça alıştıkları dilden başka bir dil kullanmak istemezler. İnsan bir kere hangi dile alışırsa o dilin yeterince iyi olduğunu düşünmeye yatkınlaşır.

Programcılar favori dillerine büyük bir sadakatle bağlıdırlar. Kimsenin duygularını incitmek istemiyorum. Bu yüzden bu bölümü anlatırken Blub isimli hayali bir programlama dili kullanacağım. Blub, dillerin güç sıralamasında ortalarda bir yerlere denk düşüyor. En güçlü dil olamasa da COBOL ya da makine dilinden daha güçlü bir dil.

Ve doğrusunu isterseniz bizim hayali Blub programcımız onların hiçbirini kullanmaz. Elbette makine dilinde de programlama yapmıyor. Bu derleyicilerin işi. COBOL'a gelince, X özelliği (Blub'un özelliklerinden biri) olmadan istediklerinizi nasıl yapabilirsiniz ki?

Blub programcımız dilleri koyduğumuz güçlülük sıralamasında aşağılara baktığında aşağıya baktığının farkında. Blub'dan daha az güçlü olan diller açık bir biçimde daha güçsüz. Çünkü o dillerde alışmış olduğu özelliklerin bir kısmı yok. Bunun yanında hayali Blub programcımız sıralamada diğer yöne yani yukarılara baktığının farkına varamıyor. Gördüğü sadece birkaç tuhaf dil -- muhtemelen bu dilleri Blub ile eşit güçte görüyor. Bütün o müthiş özellikleriyle Blub onun için yeterince iyi çünkü o Blub'da düşünüyor.

Sıralamada Blub'un yukarısında yer alan dillerden birini kullanan bir programcının bakış açısıyla baktığınızda ise Blub aşağılarda kalıyor, Y özelliği bile olmayan Blub'da istediklerinizi nasıl yapabilirsiniz ki?

Bu durumda döngünün içinden sıyrılabilip, diller arasındaki güç farklılıklarını ancak en güçlü dili anlayan/kullanan programcılar görebilir. (Eric Raymond Lisp sizi daha iyi bir programcı yapar derken büyük olasılıkla bunu kastediyordu.) Diğerlerinin görüşlerine güvenemezsiniz. Blub paradoksunda olduğu gibi, onlar, kullandıkları diller düşünce tarzlarını etkilediğinden bu dillerden memnundurlar.

Bunu BASIC kullanarak program yazdığım lise yıllarımdaki tecrübelerimden biliyorum. BASIC özyinelemeyi (recursion) bile desteklemiyordu. Özyineleme kullanmadan program yazmayı düşünmesi bile zor ama o zamanlar bunun eksikliğini hissetmiyordum. BASIC'te düşünüyordum ve bu işte uzmandım!

Eric Raymond'ın önerdiği beş dil güçlülük sıralamasındaki farklı yerlere denk geliyor. Hangisinin daha üste hangisinin ise altlarda olduğu hassas bir konu. Benim söylemek istediğim bence Lisp'in en yukarda olduğu. Bu iddiamı diğer dört dile baktığımda eksik olduğunu gördüğüm özelliklerden bir tanesini anlatarak destekleyeceğim. Yapmak istediklerinizi makrolar olmadan nasıl gerçekleştirebilirsiniz ki? [5]

Bir çok dilde makrolar vardır fakat Lisp makrolarının bir eşi daha yok ve ister inanın ister inanmayın yaptıkları şey parantezlerle yakından alakalı. Lisp'in tasarımcıları bütün o parantezleri sadece değişik olsun diye koymamışlar. Blub programcısına göre Lisp kodları tuhaf görünümlü fakat bu tuhaflığın bir anlamı var. Parantezler diğer diller ile Lisp'in arasındaki temel bir farkın en açık örnekleri.

Lisp kodları, Lisp veri nesnelerinden oluşur. Bu yüzden kaynak dosyalarının karakterler içermesi veya karakter dizilerinin dilin desteklediği veri türlerinden biri olması boşu boşuna değildir. Ayrıştırıcıdan (parser) geçen Lisp kodları istediğiniz gibi kullanabileceğiniz veri yapılarına dönüşmüştür.

Derleyicilerin nasıl çalıştığını anlıyorsanız, bu olup bitenden Lisp'in söz diziminin acayip değil namevcut olduğunu çıkartmışsınızdır. Lıspte, diğer dillerde derleyicinin içinde oluşturulan ayrıştırma ağaçlarını (parse tree) siz doğrudan program diye yazarsınız -- yani programlarınız bu ağaçları kullanabilir. Onları değıştiren programlar da yazabilirsiniz. Lisp'te bu program yazan programlar makro diye adlandırılır.

Program yazan programlar? Ne zaman böyle bir şey yapmak istersiniz ki? COBOL'da düşünürseniz pek sık değil ama Lisp'te düşünürseniz her zaman. Şimdi en uygunu güçlü bir makro örneği vererek ne demek istediğimi anlatmak olurdu. Ama bu da Lisp bilmeyenler için bir şey ifade etmezdi. ANSI Common Lisp[BM kıtaba referans CN)'te konuları elimden geldiğince hızlı geçmeye çalışmama rağmen, makrolara gelmemin 160 sayfa sürdüğünü göz önünde bulundurursak, burada, sözünü ettiğim şeyleri anlamanız için ihtiyacınız olan her şeyi açıklamama imkan yok.

Ancak sizi ikna edecek bir şeyden bahsedebilirim. Viaweb editörünün kaynak kodları %20-%25 makro içeriyordu. Standart Lisp fonksiyonlarına nazaran makroları yazmak çok daha zordur ve gerekmediği yerde makro kullanmak kötü bir üslup olarak kabul edilir. Yani o koddaki her makro, kullanılması gerektiği için yazıldı. Bu da, bu programdaki kodların en az %20-25'inin diğer dillerde kolaylıkla yapamayacağımız şeyler yaptığı anlamına gelir. Öte yandan Blub programcısı benim Lisp'in gizemli güçleri hakkındaki sözlerimden şüphelenebilir ve bu onu meraklandırabilir. Biz bu kodları eğlence olsun diye yazmıyorduk küçük ve yeni yeni kurulan bir şirkettik ve rakiplerimizden bir adım daha ileri bir teknoloji sunabilmek için çok sıkı bir şekilde çalışıyorduk.

Bu noktada şüpheci biri bu ikisi arasında bir bağlantı olup olmadığını merak etmeye başlayabilirdi. Kodlarımızın büyük bir kısmı, diğer dillerde yapılması çok zor şeyler yapıyordu ve ortaya çıkan yazılım da rakip yazılımların yapamadıklarını -- arada bir bağlantı olma ihtimali üzerine gitmenizi tavsiye ederim bunun arkasında yatan görülenden çok daha fazlası olabilir.

Yeni Kurulan Şirketler İçin Aikido

Bu yazıyı yazmaktaki amacım insanların fikirlerini değiştirmek değil. 25 yaş üstü kimsenin bu makaleyi okuduktan sonra gidip Lisp öğrenmesini beklemiyorum. Amacım, daha çok Lisp'le zaten ilgilenen ve ne kadar güçlü bir dil olduğunun farkında olan fakat geniş bir kullanıcı kitlesi olmaması yüzünden endişeleri olan kişileri bu endişelerinden kurtarmak. Rakiplerinizin Lisp kullanmıyor olması, Lisp'in gücünü bir kat daha arttıran bir faktördür ve bu da rekabet ortamında büyük bir avantajdır.

Eğer yeni kurulan bir şirkette Lisp kullanmak istiyorsanız Lisp'in çok yaygın olmaması sizi endişelendirmemeli, hatta böyle kalmasını ümit etmelisiniz. Kullanıcılarını memnun etmek bilgisayar dillerinin doğasında vardır. Donanımlar kişisel alışkanlıklarınızı değiştiremeyeceğiniz sıklıkta ve ayak uyduramayacağınız bir hızla değişir. Örneğin programlama alışkanlıklarımız, mikroişlemcileri on yirmi yıl geriden takip eder. MIT'de 1960'ların başlarından bu yana üst düzey dillerle programlama yapılırken, bir çok şirket 1980'lerin ortalarına kadar makine dilini kullanmaya devam etti. Muhtemelen bir çok kişi de işlemciler, indirgenmiş komut kümesine (RISC) geçip - bir an önce kapatıp eve gitmeye hevesli bir barmen edasıyla- onları kapı dışarı edene kadar makine dilini kullanmaya devam etmiştir.

Teknoloji genellikle hızlı ilerler ama programlama dilleri farklıdır. Onlar sadece teknoloji değil, programcıların düşünce tarzlarını şekillendiren araçlardır. Yarı teknoloji yarı mezhep de diyebiliriz yani. [6] Bundan dolayı yaygın diye adlandırabileceğimiz ve standart programcının kullandığı standart dil bir buzdağının erimesi kadar yavaş değişir. Lisp'in 1960'da ortaya çıkardığı hafıza temizleme (garbage collection), bugün herkes tarafından kabul görmüş durumda. Çalışma esnasında tip belirlemenin (runtime-typing) popülaritesi gün geçtikçe artıyor. 1970'lerin başında Lisp'le gelen sözcüksel kapalılık bugün herkesin takip ettiği bir özellik. 1960'ların ortasında Lisp'in başlattığı makrolarsa hala keşfedilmemiş bölge.

Standart dilin muazzam bir momentuma sahip olduğu açıkça ortada. Bu büyük güce direnmek yerine bir aikido ustası gibi bu gücü kendi lehinize kullanabilirsiniz.

Büyük bir şirkette çalışıyorsanız bu o kadar da kolay olmayabilir. Patronunuz tam da bir yerlerde başka bir dil hakkında etkili bir yazı okumuşken, onu Lisp kullanmanıza izin vermesi için ikna etmeniz zor olabilir. Bunun yanında yeni bir şirkette çalışıyorsanız, başınızda böyle bir patron yoktur ve siz de bizim yaptığımız gibi Blub paradoksunu kendi lehinize çevirebilirsiniz. Yaygın kullanılan ve reklamı yapılan teknolojilere bağlı rakiplerinizin asla yetişemeyeceği bir teknolojiden yararlanabilirsiniz.

Bir gün kendinizi böyle bir şirkette bulursanız, size rakiplerinizi değerlendirmek için işe yarar bir ipucu: Verdikleri iş ilanlarını okuyun. Web sitelerindeki diğer şeyler hiçbir şey ifade etmeyebilir ama iş ilanları ne istedikleri konusunda kesin bir ipucu verir.

Viaweb'de çalıştığım yıllarda bir çok iş ilanı okudum. Hemen hemen her ay yeni bir rakip ortaya çıkıyordu. Çevrimiçi bir demoları olup olmadığına baktıktan sonra ilk işim verdikleri iş ilanlarını okumak oluyordu. Bir kaç yıl sonra hangi şirketleri görmezden gelmemiz, hangisini ciddiye almamız gerektiğini anlayacak hale gelmiştim. İlan ne kadar fazla IT (BM: CN, burada yazar IT ile yarı-hazır diye reklamı yapılan Bilişim Bilimcileri yahut Mühendislerden ziyade bilgi-işlem müdürleri satıcılar vs.'nın alanı kabul edilen "moda" sistemlerin "uzman"larının hakim olduğu alanı kastediyor) bilgisi istiyorsa, firma da o kadar zararsız demekti. En cekinilmeyecek olanlar Oracle tecrübesi isteyenlerdi, bunlardan korkmanıza hiç mi hiç gerek yoktu. Ayrıca Java ve C++ programcıları isteyenler de zararsızdılar. Eğer Perl veya Python programcıları istiyorlarsa korkmaya başlayabilirdiniz, bu en azından teknik departmanında gerçek hackerlar barındıran bir şirketin habercisidir. Eğer Lisp hackerları arayan bir iş ilanı görseydim, gerçekten endişelenirdim.



*: Paul Graham'ın Beating the Averages isimli makalesinin çevirisidir. Makalenin ilk çevirisi Istanbul Bilgi Üniversitesi, Bilgisayar Bilimleri Bölümü öğrencilerinden Çağıl Uluşahin tarafından yapılmıştır. Çeviri Emre Sevinç ve Bülent Murtezaoğlu tarafından düzenlenmiştir. Çeviri sponsoru Bülent Murtezaoğlu'dur.

Notlar

[1] Viaweb başta iki bölümden oluşuyordu. Kişilerin sitelerini oluşturdukları editör Lisp ile yazılmıştı. Sipariş verme işlevselliğini barındıran sipariş sistemi ise C ile. İlk sürüm çoğunlukla Lisp içeriyordu çünkü sipariş sistemi küçüktü. Daha sonra iki modül daha eklendi. Çoğunluğu C'de yazılmış bir imaj üretici ve Perl'de yazılmış bir arka ofis yöneticisi.

2003 Ocak ayında, Yahoo editörün C++ ve Perl'de yazılmış yeni bir versiyonunu yayınladı. Buna rağmen programın Lisp ile yazılmadığını söylemek zor çünkü bütün programı C++'a çevirmek için bir Lisp yorumlayıcı yazmak zorunda kaldılar. Bildiğim kadarıyla sayfa üretici kalıplarının tüm kaynak kodları hala Lisp kodu.

[2] Robert Morris bu konuda, ketum olmaya çalışmadım çünkü rakiplerimiz Lisp kullandığımızı bilse bile nedenini anlayamayacaktı, eğer bu kadar zeki olsalar, çoktan Lisp'te programlama yapıyor olurlardı demişti.

[3] Bütün diller Turing'in "Turing makinası" kavramına indirgenebildiği için aslında eşit güçte oldukları söylenebilir. Osya bu programcılar için bir kıstas değildir çünkü hiç kimse bir Turing makinesi programlamak istemez. Programcıların güç olarak ifade ettiği şey aslında biçimsel olarak tanımlanabilecek bir şey değildir, ama bunu açıklamanın bir yolu şu olabilir: Bir dilde kullandığınız özellikleri diğer dile ancak ilk dil için bir yorumlayıcı yazarak aktarabiliyorsanız bu ilk dil daha güçlüdür. Yani A dili karakter dizilerindeki boşlukları yok edebilen bir operatöre sahip ve B değilse bu A dilini B dilinden daha güçlü yapmaz çünkü bu açığı kapatmak için bir alt program yazabilirsiniz fakat A özyinelemeyi destekliyor ve B desteklemiyorsa bu bir kütüphane fonksiyonu yazarak kapatabileceğiniz bir eksiklik değildir.

[4] Bilenler için not: Programlama dillerinin kesin bir sıralaması yoktur ancak birbirlerine karşı üstünlükleri vardır. Bu sayede ancak kısmi bir sıralama söz konusu olabilir.

[5] Makroları ayrı bir özellik olarak tanımlamak biraz yanıltıcı olur. Pratikte, Lisp'in diğer özellikleriyle birlikte olunca kullanışlı olurlar.

[6] Sonuç olarak, programlama dillerini karşılaştırmak, ya din savaşları kadar taraflı ya da antropolojik çalışmalar kadar tarafsız olur. Huzur isteyen biri bu konudan uzak durmalıdır. Ama özellikle yeni diller tasarlamak istiyorsanız bu üzerinde çalışmaya değer bir

Görüşler

0
Ansugo

Ne yazık ki bunu hayata geçirmek o kadar da kolay değildir. Programcılar belli bir yaştan ve belli bir tecrübe edindikten sonra mecbur kalmadıkça alıştıkları dilden başka bir dil kullanmak istemezler. İnsan bir kere hangi dile alışırsa o dilin yeterince iyi olduğunu düşünmeye yatkınlaşır.


Onermeyi kendime uyguladim ve true dondurgunu gordum. Cok hosuma giden bir paragraf oldu.
0
lifesdkver0_1
Lisp makrolarıyla gerçekleştirilip, diğer dillerde zorlukla gerçekleştirilecek örnek aranıyor[ ki yazı anlamlı olsun ]
0
bm
Kullandiginiz dilde 'for' dongusu olmadigini dusunun. (Ki Common Lisp'te for yok, do, dotimes ve loop vs. kullaniyoruz onun yerine). Bunu fonksyon olarak yazmak pratikte mumkun degil. (teorik olarak mumkun gayet tabi). Ama mesela Common Lisp'e for ekleyebiliyoruz:

(defmacro for ((var start stop) &body body)
(let ((gstop (gensym)))
`(do ((,var ,start (1+ ,var))
(,gstop ,stop))
((> ,var ,gstop))
,@body)))

(Graham'dan bu ustelik)

Deneyelim:
CL-USER> (macroexpand-1 (for (i 10 20) (print i)))

10
11
12
13
14
15
16
17
18
19
20
NIL
NIL

Bakalim nasil calisiyor:

CL-USER> (macroexpand-1 '(for (i 10 20) (print i)))
(DO ((I 10 (1+ I)) (#:G571 20)) ((> I #:G571)) (PRINT I))
T

Bu web/php-nuke ortaminda daha komplike ornek vermek zor. Bu ornekte gozukmeyen su: alisilagelmisin tersine Common Lisp'te macrolari da Common Lisple yaziyoruz. Yani program yazan program yazarken program yazan programin yazildigi dille sonucun yazilmis oldugu dil ayni. Hal boyle olunca yukarida oldugu gibi 'do' macrosununun uzerine bir de 'for' macrosunu gayet kolay oturtabiliyoruz. Bunu gayet tabi 'for' icin degil cozmeye calistigimiz probleme ozgu bir dil gelistirmek icin kullandigimizi dusunun. Yani dili genel amacli degil kendi ozel maksadimiza gore degistirebiliyoruz. Dile for eklemek yerine problem alanimizi ifade etmeyi kolaylastiracak
degisiklikler yapabiliyoruz.
0
bm
Yanlis yapistirmisim. Ilk cikti su olacak:

CL-USER> (for (i 10 20) (print i))

10
11
12
13
14
15
16
17
18
19
20
NIL

Bu web halleri bu isler icin berbat ortamlar. 20 sene evvel usenet'te yapabildigimiz seyleri bile yapamiyoruz malesef (ama resim gosteriyor! ilerleme dedigin boyle olur). Kusura bakmayin.

Macro isleri icin Ingilizce bilenlere iki kaynak vereyim:
Paul Graham'in On Lisp kitabi tamamen macropanlatir ama Common Lisp biliyor olmak lazim tam takip edebilmek icin. Sonuna dogru uc-bes sayfada Cl'de OO sistemi olmasa bunu nasil ekleyebileceginizi bile gosteriyor.

Yine dil bilenler icin karsilastirmali ornekler ve bir tartisma icin usenet "thread"inin ozellikle su mesajla baslayan kisimi [groups-beta.google.com]indan sonrasina bakmalarini tavsiye ediyorum.

0
FZ
Şu tür LOOP yapıları makrolar sayesinde dile kazandırılıyor ve dilin sözdiziminin doğal bir parçası olarak kullanılabiliyor:

LOOP for Black-Belts:

http://www.gigamonkeys.com/book/loop-for-black-belts.html
0
MultiServis
Aslında konu ile ilgili ama Lisp ile ilgisiz bir yorumum olacak. Uzun zaman önce başalttığımız bir e-ticaret mağaza sistemi olan ComArge müteakip adresden ziyaret edilebilir.
http://www.comarge.com [www.comarge.com]

Yazıda bahsedilen Yahoo Store gibi çalışan sistemimiz OsCommerce üzerinde geliştirildi ve tahmin edileceği üzerede birçok özelliği ile etkili çözüm sunmakta. Şimdi bu yazı biraz reklam gibi oldu ama arkadaşlar kusura bakmasın. Bu çalışma tamamen özgür yazılım mantığı ile ve herhangi bir firma desteği olmadan hazırlandı. Bu nedenle de sizden destek bekliyorum. Teşekkürler.

Ferhat Kurt
0
nehuse
Merak ettim deneyeyim dedim

böyle bir şey çıktı

Warning: shipping(../srx/magaza/includes/languages/turkish/modules/shipping/MODULE_SHIPPING_INSTALLED): failed to open stream: No such file or directory in /home/comarge/domains/comarge.com/public_html/srx/magaza/includes/classes/shipping.php on line 37

Warning: shipping(../srx/magaza/includes/languages/turkish/modules/shipping/MODULE_SHIPPING_INSTALLED): failed to open stream: No such file or directory in /home/comarge/domains/comarge.com/public_html/srx/magaza/includes/classes/shipping.php on line 37

Warning: shipping(): Failed opening '../srx/magaza/includes/languages/turkish/modules/shipping/MODULE_SHIPPING_INSTALLED' for inclusion (include_path='.:/usr/local/lib/php') in /home/comarge/domains/comarge.com/public_html/srx/magaza/includes/classes/shipping.php on line 37

Warning: shipping(../srx/magaza/includes/modules/shipping/MODULE_SHIPPING_INSTALLED): failed to open stream: No such file or directory in /home/comarge/domains/comarge.com/public_html/srx/magaza/includes/classes/shipping.php on line 38

Warning: shipping(../srx/magaza/includes/modules/shipping/MODULE_SHIPPING_INSTALLED): failed to open stream: No such file or directory in /home/comarge/domains/comarge.com/public_html/srx/magaza/includes/classes/shipping.php on line 38

Warning: shipping(): Failed opening '../srx/magaza/includes/modules/shipping/MODULE_SHIPPING_INSTALLED' for inclusion (include_path='.:/usr/local/lib/php') in /home/comarge/domains/comarge.com/public_html/srx/magaza/includes/classes/shipping.php on line 38

Fatal error: Cannot instantiate non-existent class: in /home/comarge/domains/comarge.com/public_html/srx/magaza/includes/classes/shipping.php on line 40
0
FZ
Java programcıları da yavaş yavaş "language oriented programming", metaprogramming diyerek konuya giriş yapıyor, ısınma turları atıyorlar, Amerikayi yeniden keşfetmeleri güzel tabii, zararın neresinden dönülse kârdır şeklinde:

http://www.onboard.jetbrains.com/articles/04/10/lop/
0
bm
Bu adam kotu niyetli veya aptal olmadigina gore cahil. Malesef bizim alanimizda bir suru sey bir suru zeki insan tarafindan devamli yeniden icad ediliyor (ama ne derece iyi sekilde bilemiyorum. Greenspun'un 10. kanunu vs. vs.). O yaziyi yazarken sirf Lisp degil Lisp makineleri ve hatta bir dereceye kadar Smalltalk ortamlarindan haberi olmus olsa (ki olmadigi asikar) buyuk ihtimalle 'Next Programming Paradigm' demeyecegi gibi, belki referansi Knuth'a yapacagina Maclisp yahut Interlisp'e yapip "structure editor" dediginin belki o dogmadan cikmis bir kavram (ve isim) oldugunu fark edecekti.

O yaziyi takip eden tartismada bunu ona soylemisler, hala evet C++ macrolari da oyledir gibi sacmaliklar soyluyor. Bu zekadaki insanlara para kazanip bir taraflari elevasyona ugramadan ulasip en azindan belli bir genel kultur vermenin insanlik icin faydali olacagini dusunuyorum -- muazzam kapasite ziyan oluyor cunku. Mesela bu adam bulunmamis acayip seyleri de buluyor olabilirdi.

Bu islerin sosyolojik tarafi cok ilginc olabilir. Butun oyuncular sagken birisi keske ilgilenip ortaya derli toplu birsey cikartsa diyorum.
0
malkocoglu_2
Guzel bir makale. Saniyorum bu teknolojinin secildigi zamanlar, 90 yillari sonlari, cunku web teknolojisinde o zamanlar daha kimin ustte cikacagi belli degildi, ve boyle egzotik secimler daha rahat kabul gorebiliyordu. Mesela, NeXtStep sirketinin (aziz Steve Jobs'in Apple'dan sonra kurdugu sirket) Objective C diliyle calisan, WebObjects adinda bir teknolojisi vardi. Hatta bir sure buyuk bir sukse yapti. Fakat kurumsal yazimlimci danisman sirketlerin bam telini yakalayamadilar. Insanlar belli bir sure sonra C/CGI'dan Java'ya gecti. O zaman icinde oldugum sirkette bu donusumu seyrettim.

Bir diger konu, Common LISP hakkindaki belgelerin hernedense nesnesel programciliktan fazla bahsetmiyor olmasi. Evet evet, fonksiyonel programcilik yapiyoruz, fakat kod duzenlemesi acisindan OO kavramlarinin dil ogretinde on plana getirilmesi iyi olur. CLISP cogunlukla "okulda ogrenilen bir sey" oldugu icin, algoritmik derslerin odevleri, yazilim muhendisligine fazla onem vermiyorlar. Bu normal. Fakat bu cocuk ileride sektorde calisirken bir kurumsal yazilima baslamak istediginde, CLISP'in "yazilim muhendisligi" kavramlarini tasimayan bir dil oldugunu dusunuyor zannediyorum. Halbuki Java, hersey mutlaka bir class icinde olmalidir mecburiyetinden baslayarak, cokyuzluluk, kalitim gibi teknikleri bir sicrama noktasi sagliyor. Belki bu acidan Ruby ve Phyton '"okuldan ise" daha rahat uyarlanabilir bir sey olacak, ve daha genis kurumsal uygulama alani bulacak.

Not: CLISP te yazilim muhendisligi kavramlari yoktur demiyorum, 10 yildir kullandigim GNU Emacs LISP dilinde yazilmistir, ve Stallman "LISP harikadir, tek cetrefil veri yapisi vardir, o da bir listeden ibarettir" der. Tabii ben faniler dunyasindan biri olarak cetrefil veri yapilarimi bir nesne agi (object graph) olarak gormeyi yeglerim, fakat ustadin dediklerini anliyorum. Herkesin anlamasini beklemek ve uygulamaya koymasini ummak, bos olabilir.

0
bm
Kisa kisa cevap vereyim.

Saniyorum bu teknolojinin secildigi zamanlar, 90 yillari sonlari, cunku web teknolojisinde o zamanlar daha kimin ustte cikacagi belli degildi, ve boyle egzotik secimler daha rahat kabul gorebiliyordu.

Dogru, 90lardan bahsediliyor. 98'de sattilar (40 degil 50 mil olacak yanliz). PG'nin soylemek istedigi su: kimin uste cikmis oldugu onemli degil, ("teklnolojiyi oyle secmek makul olsa Windows kullanirdik" vs. vs.).

Bir diger konu, Common LISP hakkindaki belgelerin hernedense nesnesel programciliktan fazla bahsetmiyor olmasi.

Bu alsinda dogru degil. Common Lisp ANSI tarafindan standartlasacak kadar olgunlasan ilk OO dil aslinda. OO ozelliklerine vurgu yapilmamasinin sebebi "OO dunyayi kuratacak" tarzi inanclarin CL kullanicilari arasinda gulunc bulunmasi. Hal boyle olunca devamli OO demiyorlar tabi.

CLOS (Common Lisp Object Syetem) konusunda hem hyperpec [www.lispworks.com] , hem CLtL2 [www.ida.liu.se] yeterince bilgi verecektir. Eger ileri derecede ilghiliyseniz CLOS'un uzerinde yaygin kullanima olan bir meta-object protokolu de var (C++'da bahsedilen template metaprogramming CL macrolarina daha yakin, Meta Object Protokolu [www.lisp.org] CLOS'u isinize uygun olarak degistirmeye yariyor.)

CLOS'un tasarimcilarindan birinin basitce CLOSu anlattigi bir film de var: Daniel G Bobrow: Common LISP Object Standard
[www.archive.org]

Bahsettiginiz "Yazilim Muhendisligi" kavramlari aslinda programcilari degisebilir (birbirlerinin yerine gecebilir) halde tutma metodolojileri bir yerde. O yuzden dillerde muhtelif zorlamalar, insanlari ve dusunceleri kaliplara sokmalar vs. iyi seylermis gibi konusuluyor. Bunun etrafinda bir egitim yan sanayii de olusmus (Gang of 4, C++ tarzi OO'nun bazi aptalliklarinin ismine 'pattern' deyip insanlara belletmece vs.). Bu tekniklerin faziletleri var elbette, ama bilisim alemi aslinda bu derece tek boyutlu degil.

Yaygin kullanim icin %100 haklisiniz tabi. Yarin is bulmak durumunda olan bir cocuk Java ogrenmeyip de ne ogrenecek? Ama tabi Graham'in yazida soylemek istedigi seylerden biri de herkesin yaptigini yaparsaniz herkese olan size de olur. Yeni, ilginc vs. isler yapmak isteyenlerin kalabalikla hareket etmeleri makul olmayabiliyor.

Universite egitimi hakkinda da hak veriyorum. Universiteler meslek okullari olmadiklari icin meslek okulu gibi davranmiyorlar aslinda -- yani mezun oldugunuzun ertesi gunu bir gurubun arasinda oturup makine basina gececek insan yetistirmek universitenin gorevi degil. Burada hata, talebelerin universitelerden bunu bekliyor olmalari ve onlara beklememelerinin soylenmemesi. Bu sirf TR icin degil heryer icin gecerli. Bu derece yeni bir alanda bu cizgilerin tam nerede olduklari da acik degil tabi ve bu yuzden hem beklenti/ogrenim arasinda hem ideal/ogretilen arasinda bosluklar oluyor. Isaret ettiginiz yazilim metodolojisi bu bosluklardan biri bence. Bu konuda iyi bilinen okullarda bir direnc var cunku hocalar saat ucreti $30-40 bile olsa mezununun alt tarafi uretim bandinin onune oturabilmesini saglayacak seyleri belletmeyi 'muhendislik' saymiyorlar.

Stallman "LISP harikadir, tek cetrefil veri yapisi vardir, o da bir listeden ibarettir" der.

RMS kusura bakmasin, halt etmis o konuda. Elisp (Emacs Lisp) nisbeten berbat ve geri bir lisp. Tamamen "dymanic scope" oldugu icin ciddi programlama gereken yerlerde Common Lisp alsikanliklari (lexical closure vs.) kolayca kullanilamiyor. Common Lispte aliatigimiz sayi turu zenginligi bile yok (yakin zamana kadar bignum yoktu mesela. Rational complex vs. hala yok) Tek veri tipi de bir fazilet degil. Program/veri ayriminin belirsizlesmesini sagladigi icin sexp notasyonu iyi bir sey, 'tek' veri tipi liste oldugu icin degil. Common Lisp'te hash table, struct vs. gayet tabi var (genel amacli nesne de var).

Fonksyonel programlama dogmasinin adresi Scheme, Common Lisp degil. CL'de fonksyonel programlama mumkun ama dil bu konuda (Scheme'in yaptigi gibi) bir zorlama yapmiyor.

0
malkocoglu_2
Bahsettigim yazilim muhendisligi kavramlari, 3 ay sonra kendi kodunuza baktiginizda ne olup bittigini anlamaniza yardim edecek seylerin toplami, illa ki baskalarinin o kodu bakmasina yardim edecek seyler olmayabilir.

Bir ufak not daha: Aslinda ben okullarda yazilim muhendisligi ogretilmesinden bahsetmiyordum. Algoritma agirlikli derslerde, nesnesel kavramlari iceren bir dilin bu ozellikleri kullandirilmaya tesvik edilsin, ve ya, bu ozellikleri bastan ZORLAYAN bir dil ile ise baslansin diyordum.

Ayrica, cocuga fazla miktarda kod yazmasini gerektiren bir proje de yararli. Tekrar soyleyeyim, ayri yazilim muhendisligi dersinden bahsetmiyorum. Bizim okulumuzda mesela "Derleyicilere Giris" dersinde prof. direk sunu soylemisti. "Bir derleyiciyi yazmak, onun icerdigi algoritmalar ve dusunce yapisi acisindan ilginc olacak sizin icin, bir onemli yan etki daha, bir derleyici buyuk miktarda kod gerektirdigi icin, sizi yazilim muhendisligi hakkinda dusunmeye zorlayacak". Ve hakikaten oyle oldu. Ilk defa o miktarda kod yaziyordum, ve basimi derde soktugum yerler, aldigim derslerm butun bunlar ileride cok isime yaradi.

0
bm
Bahsettigim yazilim muhendisligi kavramlari, 3 ay sonra kendi kodunuza baktiginizda ne olup bittigini anlamaniza yardim edecek seylerin toplami, illa ki baskalarinin o kodu bakmasina yardim edecek seyler olmayabilir.

Anlasiyoruz esasinda, ben yukarida soylediginizden de ileri gidip [isi bilen bir] baskasinin da anlamasini buna dahil ederim aslinda ama 'yazilim muhendisligi prensipleri sudur, olculeri budur' diye ISO bilmemne, defects/kloc olculeri, CMM vs. seyleri bir de OO uzerine bindirip insanlara ittirmenin manasini gormedigim icin oyle yazdim. Sizin kastettiginizi degil kendi sevmedigimi duyarak cevap verdim yani.

Soylemediginiz baska bir seye cevap bu tabi ama bu kavramlarin malesef (ozellikle Fortune-500/ABD baglaminda) dibi cikmis durumda. Insanlar herhangi bir makul seviyede yaptiklarini anlamadan is gorebilir hale geliyorlar. Bu fena birsey degil, sonunda isleri ac insanlarin ucuza yapabildikleri memleketlere yollanabilir hale getirip herkesin karli cikmasini sagliyor. Ama muhendislik bu degil bence. Olmamali. 15 senede C->C++->Java gecisini yapmis olmamiz ne kadar kisitli ufuklarla ne beyinleri ziyan ettigimizi gosteriyor bence. Belki tip okusa kansere filan care bulacak kapasitedeki insanlari bilgisayar islerine cektigimiz dusunulurse, zararin buyuklugu ortaya cikiyor. Bu kadar beyinle gelinen yer bu mudur? Sene 2004, Windows kullaniriz, Java'yla kod yazariz umut da Unix turevi Linuxdur! Nereden geldik buraya? Xerox D* makineleri + interlisp, Smalltalk, Symbolics vs. Hmpf??? ("Worse is Better" diye bir makale dizisi vardi, onlari da cevirsek mi acaba? "Beating the Averages"a karsilik bulurken cektigimiz sIkIntIdan beteri oldugunu gorup sukretmeyi ogreniriz. Bizi imana dondurur iyi olur).

Algoritma agirlikli derslerde, nesnesel kavramlari iceren bir dilin bu ozellikleri kullandirilmaya tesvik edilsin, ve ya, bu ozellikleri bastan ZORLAYAN bir dil ile ise baslansin diyordum.

Ben buna okudugum haliyle katilmiyorum. Eger algoritma ogrenilecekse pseudo-code'a yakin (C/pascal herneyse) diller makul. Knuth daha da ileri gidip MIX/MMIX gibi assembly dili ayari diller kullaniyor.

Diger bir taraftan da size katiliyorum, kendileri bilfiil gunde 18 saat kod yazmayacak bile olsalar bu konuda ciddi egitim goren insanlarin kod yazmayi vs. yaptiklarinin dikkatle izlendigi buyukce projelerde ogrenmeleri lazim. Bunun yeri ders midir, bitirme projesi midir, yaz okulu mudur onu bilemiyorum. "Eger bunu da bizim ogretmemizi istiyorsaniz burada isiniz yok. Zaten hemen kapabiliyor olmaniz lazim, ugrasin kaparsiniz, biz kapmis kabul ediyoruz sizi ve buna bagli olarak yapacaginiz sey sudur..." seklinde bir tarz da var. Ama o tarz "olen olur kalan saglarin bir kismini da biz okuldan atariz" tarzina donusmeye meyyal bir tarz. 18-19 yasindaki cocuklara ise yatkinliklari ne seviyede olursa olsun yapilacak bir sey degil.
0
FZ
Bir de wikipedia'dan özel CLOS (Common Lisp Object System) alıntısı:

http://en.wikipedia.org/wiki/CLOS

The Common Lisp Object System, a powerful system for object-oriented programming which forms part of Common Lisp.

CLOS differs from most other object-oriented programming environments in the following ways:

* It offers multiple dispatch, or "multimethods".
* Therefore, methods are not considered to live within classes; they are conceptually grouped into generic functions instead.
* CLOS doesn't provide encapsulation; that is considered to be the job of a different part of Common Lisp, the package system.
* Inheritance can cause methods to be combined together in arbitrarily complicated ways at the discretion of the programmer, and not merely overridden by one another.
* CLOS is dynamic, meaning that not only the contents, but also the structure of its objects can be modified at runtime. CLOS supports changing class definitions on-the-fly (even when instances of the class in question already exist) as well as changing the class membership of a given instance through the change-class operator.

CLOS has multiple inheritance and, unofficially, a meta-object protocol.
0
FZ
Çetrefil veri yapılarını bir nesne ağı yani bir tür graf olarak görmek isyeten Common Lisp programcıları şu gibi şeyler yapıyorlar:

http://clim.mikemac.com/images/listener1.jpg

Bu arada ABD'de okullarda Lisp öğretiliyor olabilir ama Türkiye o bakımdan şanssız, henüz bünyesinde ciddi ciddi Lisp ile iş güç yapan bir mühendislik fakültesine, bilgisayar bölümüne rastlamadım ben Türkiye'de. Dolayısı ile insanların pek kıyaslama şansı da olmuyor maalesef. Daha da kötüsü anlı şanlı okullarımızda "Lisp eski ve yavaş bir dildir" (allah allah gerçekten mi, o zaman ben halüsinasyon görüyor olmalıyım :)), "Lisp'te garbage collection gibi kötü bir özellik vardır" (Java'cılar ne der buna acaba? :) gibi iddialar dile getiriliyor hocalar tarafından.

Ben kendi adıma İTÜ Matematik Müh. bölümünde bana Lisp öğretilmediği için üzgünüm, özellikle matematik okuyanlara ilk öğretilecek diller arasında görüyorum Common Lisp'i. Maalesef bu dil ile 28 yaşımda ve okuldan mezun olduktan epey bir süre sonra tanıştım ama zararın neresinden dönülse kârdır diye düşünüyorum. Hem belki FM üyesi ttk ile birlikte Graham'ı utandırırız, malum üstadın "25 yaşından sonra Lisp öğrenip uygulayabilecek insan yoktur" iddiası var ;-) Hatta sırf buna uyuz olup canavar gibi Lisp öğrenmiş ve iş güç yapmaya başlamış adamlarla karşılaştım (hayır Türk değillerdi :)
0
bm
ABD'de ders olarak Common Lisp ogretildigini zannetmiyorum (benim bildigim hicbir yerde yok). Lisp kulturu olan yerler var (MIT vs.) tabi.

O listener demosunu begendiyseniz, Debian'da o resmi cikartan programlar paketli (cmucl veya sbcl ve cl-mcclim). Ama yeni baslayan birine tavsiye etmiyorum. (daha dogrusu tavsiye edilecek durumda mi tartacak durumda degilim su anda, FZ deneyip soyleyebilir tabi.)
0
FZ
Nesneye yönelik programlama ve Common Lisp. Farklı bir "orientation" ve OO programlanın nasıl yapılabileceğini görmek isteyenler için:

Object Reorientation: Generic Functions
http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html

Object Reorientation: Classes
http://www.gigamonkeys.com/book/object-reorientation-classes.html
0
ttk
Merhaba

Bence harika ve isabetli bir seçim olmuş tercüme için bu yazının seçilmesi. Yamuk elbise dikip terzi kıtlığında bunu millete yutturanların kılıksız tercümelerine de hiç benzememiş, ne denilmek istenildiğini insan yazıyı okurken ister istemez anlıyor. Yazıyı seçen ve tercüme edenlerin tümünün ellerine sağlık, tabii kendilerine de.

Geçen senenin sonlarında neler var diye bilgisayar kitaplarını karıştırırken sayın Mustafa Başer'in Python kitabını almış ve seneler sonra ilk defa bir programlama kitabını sonuna kadar okuyup bitirmiştim. Python ile yapılabilenleri görünce o zamana kadar gözüme gayet de yeterli gelen Delphi'nin balonu bir anda sönüverdi içimde. Özellikle de (kafam basmadığından da olabilir) Delphi'de bir türlü söküp anlayamadığım Class'ların Pythonda ne kadar kolay anlaşılır ve kullanılır olduğunu görünce Delphi'yi artık sadece mecburiyetten kullanıyor duruma düşmüştüm netekim.

Lisp'e de az biraz buradaki daha önceki yazıların üzerine bakma fırsatım oldu, Lisp'de bir potansiyel var gibi geldi bana (pata küte - Lisp'severler üzerine saldırıp beş parmaklı fonksiyonlarla elemana girişir :)

Karar verdim Lisp'çi olacam, dutmayın beniii .... Keloğlan gider perde kapanır.
(Bunun adına Water'li feedback mi denir, neyse :)
0
FZ
Hmm, bu makale 12 saatten kısa süre içinde yaklaşık 300 kere okunmuş görünüyor. Mükerrer okumaları, aynı kişilerin yorumlara bakmasını falan elersek herhalde 200-250 farklı kişi okumuştur.

Şimdiye dek sadece 5 farklı kişi yorum yazmış, ikisi zaten yazıyı yayına hazırlayan. Geriye kalan 3 kişiden biri zaten Common Lisp programlama yapmış bir yazılım geliştirme uzmanı. Geriye kalan iki kişiden biri makrolarla ve Lispe'e özgü olanın ne olduğuna dair güzel bir soru sormuş.

Tek bir kişi, bu yazı ve daha önceki yazılar sebebi ile motive olduğunu ve Common Lisp ile ilgileneceğini söylemiş.

Emek yoğun işler olan çeviri ve öğretici, kılavuz belgeler hazırlama işine devam etmeli miyiz? Derim ki, eğer Delphi ile Python'u kıyaslayabilen, burada yayınladığımız bu Lisp makalelerini okuyup heyecanlanabilen en az bir kişi olduğuna göre devam etmeliyiz. Belki bu şekilde Türkiye'deki yazılım heveslileri ve profesyonelleri de bu programlama dilinin değerli fikirleri barındırdığını ve bir grup "egzantrik", "egzotik" "yabancı" tarafından nadiren kullanılan bir dil olmadığını bizzat kendi denemeleri sonucunda görürler.
0
ttk
Merhaba

Umarım bu işi kapasitemi de zorlayarak başarabilirim.
İnsanın en verimli çağının 25-35 yaşları arası olduğunun söylendiğini duyduğumda yaşım 35'i geçmişti :)(
Bakalım elimden ne gelecek şimdiden sonra, ben yine de ümitliyim :)

Bir de, burayı bu kadar kişi okuyor, neden bir ses vermiyorlar ya da kısa da olsa geribildirimle katkıda bulunmuyorlar anlamıyorum. Sadece seyrederek, alıcı olarak bir yere varılmaz, en azından bir şeyler yapmaya uğraşanlara beğeni ve tepkilerini iletseler epey iyi olur diye düşünüyorum.

Hayırlı günler herkese.
0
bm
Valla secme durumunda olsam begendiginizi duymak yerine neresini ve neden begenmediginizi duymayi tercih ederim. Tercumeyi asil yazarin kastettigini carpitmadan tam anlasilir yapmak -- ozellikle teknik kavramlarin karsiligin tam oturmayabildigi Turkce'de -- kolay bir is degil. Neyin nasil kafa karistirdigini bilirsek isimiz cok kolaylasir.

25-35 arasi icin soylenen dogru bile olsa insan kendisini daha iyi tanidigi icin surecleri daha iyi idare edebilir gibi geliyor bana. Esas 15-25 arasi bence hizli ogrenilebilen zaman. (benim yasim 4'le basliyor).

PG'nin 25 ustu icin soyledigine katilmiyorum ben, bu yasla ilgili degil. O yaslara (ozellikle orada okulu uzatmayanlar icin) insanlarin yaptiklari isten gecinmeye baslayip hayat standartlarini muazzam arttirdiklari zaman denk geliyor. Yani hem tarz ve bilgilerinin yanlis olmadigi hayatlarini etkileyen bir sekilde teyid oluyor hem vakitlerinin ustune maliyet etiketi yapistirabilmeye basliyorlar. Direnc yastan ziyade oradan kaynaklaniyor olabilir. Alanina hakim olup genis perspektiften baktigini dusunmeye baslamis cogu insan aslinda resmin kucuk bir kismini gordugunu duymak istemez. (Bunun caresi aslinda tabi bir iki kucuk seye hakikaten cok iyi hakim hale gelip -- yani bildigini bilebilir olup -- tam bilmedigini tam bilmedigini tahmin edebilir hale gelmek.)

Insanlara konularindaki ilk islerinde yahut daha evvel ulasabilirseniz bilgi/tarz transferi hem onlar hem sizin icin cok daha kolay oluyor. Ozellikle kotu aliskanliklar edinilmesine engel olmak icin bu kesinlikle boyle. Kucuk sirket yoneticileri bazen 'aman baska yerde calisip yoldan cikmamis olsun, ben yetistireyim' derler zaten.
0
FZ
Başka programlama dillerinden gelip de Lisp ile tanışan bazı programcıların tepkilerinin yer aldığı bir özet sayfası:

http://alu.cliki.net/RtL%2520Highlight%2520Film
0
FZ
Aklıma gelmişken, zaman zaman öne sürdüğüm bir örnek vardır. Burada tekrarlayayım ve dilin içinde kalarak o dili genişletmek, makrolar, vs. ne demektir biraz daha iyi anlaşılsın.

Malum çağımız bilgisayar çağı ve insanlar daha algoritma, sembolik mantık, veriyapıları mı o da ne filan demeden hoop gidiyorlar SQL'di, PHP idi falan iki üç "manual" okuyup mevzulara giriyorlar, site yapıyorlar. Hay hay yapılsın edilsin, piyasa hareketlensin, güzeldir :) Evrim sürüp gidiyor. Madem SQL bu kadar asgari müşterek o halde ondan örnek verelim:

Bir veri tabanı tablomuz var, içinde de 50 alan (field, column, ya da her ne diyorsanız) var. Tüm alanları kapsayacak şekilde tüm satırları döndürmek istersem ne diyeceğim çoğunuzun malumu:

SELECT * FROM BenimTablom

Gayet güzel. Peki sadece birkaç alan istiyorsam? O da gayet basit değil mi:

SELECT sütun1, sütun2, sütun3 FROM BenimTablom

Bu da güzel. Şimdi şuna gelelim, eğer sadece bir alan hariç ya da iki üç alan hariç geriye kalan tüm alanları istiyorsam? Bir çözüm var mı evet, istemediğim sütunlar haricindeki tüm sütunları açık açık yazmak:

SELECT sütun1, sütun4, sütun5, ..., sütun50 FROM BenimTablom

İyi güzel de, yani neden bilgisayar benim yerime çalışmıyor ki? efsanevi Cowboy Bebop(*) çizgi filminin bir bölümündeki yaşlı ve huysuz uzay gemisi mühendisinin dediği gibi: Makinanın mı seni kullanmasını istiyorsun yoksa sen mi makinayı kullanmak istiyorsun?

SELECT * EXCEPT sütun2, sütun3 FROM BenimTablom

diyebilsem tam da düşüncemi doğal olarak kullandığım dile yansıtmış olmaz mıyım?

DİKKAT! Yukarıda bahsettiğimiz şey SQL söz dizimini genişletmek. Bir tür metaprogramlama. Kullandığınız programlama dilini programlama yani. Hayır, üzgünüm, 21 günde MySQL ve PHP anlatan kitaplarda bu terimleri bulmanız mümkün değil.

SORU: Bu genişletmeyi, bu işlevselliği SQL dışına çıkmadan yani sadece SQL'nin kendisini kullanarak yapabilir misiniz? (T-SQL ya da PL/SQL kullanarak string işlemleri yapan fonksiyon yazmaktan bahsetmiyorum, lütfen buna dikkat!)

SERBEST ÇAĞRIŞIM: C programlama dili ile kendi SQL ayrıştırıcınızı (parser) yazıyorsanız evet bu tür bir söz dizim genişletmesi yapabilirsiniz. Gerçi öyle bir durumda da muhtemelen flex ve bison yani lex ve yacc yazılımlarının GNU muadillerini kullanıyor olursunuz. Bu da C, lex ve yacc gibi üç farklı sözdizimi ve semantik bilgisini başka bir deyişle üç farklı dili kullanmanız anlamına gelir.

SONUÇ: Lisp ve makrolar derken işte yukarıdaki gibi şeylerden bahsediyoruz. Lisp'in dışına çıkmadan, Lisp'in kendisini kullanarak, tıpkı yukarıdaki örneğe benzer şekilde Lisp'i genişletebiliyorsunuz, sözdizimine eklemeler yapıyorsunuz ve sonra bunları kullanırken yabancı bir dil kullandığınız hissiyatına da kapılmıyorsunuz.

Not: Kullandığınız SQL implementasyonunda (yani XYZ şirketinin çıkardığı ve kafasına göre, standartları bi tarafına takmayarak özellikler ekleyerek sunduğu somut veritabanı ortamında) bahsettiğim türde bir sözdiziminin varlığı (eğer varsa yani) bu örneğin açıklayıcılığını ve gücünü değiştirmez ;-)
0
tongucyumruk
hmmm... http://www.gigamonkeys.com/book/ Böyle bir kitap var, ve bu kadar LISP konuşulan bir ortamda daha yeni anılıyor ha? Yakıştıramadım.. cık cık cık...

Yok ama kendimi kontrol etmeliyim... Mor Kitap'ı tüm örneklerini çözerek bitirmeden diğer LISP kitaplarına geçmek yok!
0
bm
SICP'nin anlattigi hikaye ile Seibel'in kitabinin anlattigi hikaye cok farkli. SICP'yi bilgisayarin (bir perspektiften) ruhunu daha iyi anlamak icin okuyabilirsiniz. Seibel'in kitabi -- ismi gibi -- pratik orneklerle Common Lisp'i tanitmak icin. Ikisi ayni zamanda olabilir eger SICP'nin programlama problemlerine ellemiyorsaniz. Elliyorsaniz Scheme/Common Lisp farki kafa karistirabilir. Ayni zamanda okursaniz meta-circular evaluatori yazarken 'suraya bir de defmacro ekleyeyim' gibi fikirler de gelebilir akliniza tabi.
0
FZ
Tavsiyem şudur: Mor Kitabı şimdilik bir rafa kaldır. Practical Lisp kitabından ufaktan çalışmaya başla. Arada keyif için Mor Kitabın videolarını izle ama bm'nin de belirttiği gibi çok fazla odaklanmadan çünkü en az iki deneyimli programcının kafasını epey karıştırdığını biliyorum Scheme / Common Lisp mevzusunun!

Scheme, çok daha minimalist ve "küçük" bir dil. Çok güzel özellikleri var ve çok acayip fikirleri kolayca denemeye falan izin veriyor görebildiğim kadarı ile, öte yandan aynı aileden gelmekle birlikte Common Lisp "büyük" bir dil. Dilin spesikasyonu 1000 sayfayı aşıyor. Vahşi ormanda, azgın piyasa şartlarında, karmaşık uygulamalarda pratik ve şık çözümler üretmek, iş güç yapmak için hazırlanmış bir dil. Scheme spesikasyonu ise 50 sayfa mı ne. Saflığı, sadeliği ve temel fikirlerden yola çıkarak güçlü yapılar kurmayı vurguluyor.

Bu sebeplerden ötürü Mor Kitap'ın tüm örneklerini bitirmeden Lisp'e geçmek yok fikrini değiştirmeni tavsiye edeceğim ve seni ikna etmek için elimden geleni yapacağım.

Bu arada LISP değil Lisp, ya da bizim burada bahsettiğimiz sürümünün ismi ile: Common Lisp.

Not:Practical Lisp kitabı burada ilk kez anılmıyor, meşhur ve baba Lisp programcılarından, efsanelerden Kent Pitman'ın /. röportajının ilk bölümünü buraya çevirip koymuştuk, onun altındaki tartışmalarda da Practical Lisp kitabına göndermede bulunmuştuk diye hatırlıyorum.
0
tongucyumruk
Açıkçası Mor Kitap'ı bitirme derdim Scheme/Lisp mevzusundan öte CS konusunda adam gibi bir temel yapmaya çalışmamdan kaynaklanıyor. Practical Lisp biraz daha Lisp'te şu şöyle, bu böyle yapılır, haydi eyvallah tarzında, standart kitaplarda olduğu gibi geldi.

Henüz CL hakkında çok bir bilgi sahibi olmadığım için fazla bir yorum yapmak istemiyorum fakat açıkçası spesifikasyonu 50 sayfa olan bir dil bana 1000 sayfalık spesifikasyona sahip bir dilden daha çekici göründü.

LISP yazmamın sebebi LISP'in bir kısaltma olması. Ama tabiiki Common Lisp yazarken Lisp diye...
0
FZ
İlk argümanın karşısında ceketimi giyip sonra da düğmelerini ilikler, şapkamı takıp sonra da çıkarırım ;-)

MIT ve Bilgi Üniversitesi gibi üniversitelerde Scheme, programlamaya giriş dersi olarak okutuluyor, o bakımdan haklısın, o videolar da bildiğim kadarı ile HP sponsorluğunda hazırlanmış, kamuya da sunulmuş aynı zamanda HP'deki personelin eğitiminde de kullanılmış.

Neyse, biz bir Common Lisp tutorial yazmaya başlayalım (çok acayip bir sürprizimiz olacak) belki ikna ederiz seni ;-)
0
bm
CS bilgisi icin o yol dogru. Ciddi bir calisma icin suraya [aduni.org] da bakabilirsiniz (bunlarin filmleri de vardi bir ara, simdi bulamadim). Orada sistem kismi biraz zayif (OS ve mimari yok dogru durust) ve en azindan basit bir derleyici dersi olsa daha iyi olur. Network (ozellikle TCP/IP baglaminda) o kadar da derslik birsey degil aslinda ama onu da bilmekte fayda var. Zaman ve azim olursa tek basina (+ net) yapilabilecek isler bunlar aslinda.

Scheme/CL tamamen farkli guruplara hitab ediyorlar. CL hakikaten endustriyel bir dil, ona gore evrim gecirmis. PG'nin ilk _yaygin kullanilan_ uygulamayi biz yaptik demesine bakmayin, senelerdir ciddi islerde kullaniliyor. Mesela AMD islemci kullaniyorsaniz ve hatasiz calisiyorsa bunda Lispin payi var (ACL2 diye bir googlelayin. Son duydugumuza gore 8-li bir Itanyum makine uzerinde 24gig hafiza kullanarak cayir cayir calisiyormus. Debian'da olmasi lazim.).

Scheme, lisp kulturu cok kuvvetli bir yerde (MIT) kucuk ve yeniliklerle dolu (zamaninda lexical scoping, full tail-call elimination, sonra call/cc) ve teorik olarak gereksiz gorulebilecek (speci buyuten) pek ozelligi olmayan bir dil olmasi amaciyla ortaya cikmis. Oyle de devam ediyor. O topluluk o fikirleri seviyor cunku.

Ikisini de kullanirsaniz CL specinin niye 1000 sayfa oldugunu ve bunun niye iyi oldugunu anliyorsunuz aslinda. Bence eksik biraz Meta Object protokolu de girebilirdi o standarda.

Ama derleyicisini kendim yazabileyim icinde bir de genel call/cc olsun performans onemli degil diyorsaniz o zaman Scheme tabi. Bilmekte fayda var, bilmek de cok zor degil (ozellikle Sussman'in SICP ve SICM'de kullandigi kismini.)

Siebel'in kitabini hafife almayin, evet herhangi bir pratik dil gosterme kitabi gibi ama gosterdigi dil herhangi bir dil degil. Ben FZ'yi lisp konusunda o kitap olmadan bu kadar heveslendiremezdim herhalde (degil mi?).
0
FZ
Siebel'in kitabini hafife almayin, evet herhangi bir pratik dil gosterme kitabi gibi ama gosterdigi dil herhangi bir dil degil. Ben FZ'yi lisp konusunda o kitap olmadan bu kadar heveslendiremezdim herhalde (degil mi?).

Şöyle diyeyim genellikle pratik olarak bir programlama dilini gösteren kitapların çoğu önce bir önsöz, tarihçe ile filan başlar, sonra da bakın "Hello World" şöyle yazılıyor, dilin sözdizimi de buna benziyor diye ufaktan mevzuya girer. Seibel ise önce gördüğüm en çarpıcı tarihçe ve argüman seti ile başlıyor sonra da bırakın hello world'ü, gelin bir basit CD veritabanı ve bunu sorgulamak için mini SQL tarzı bir şey yapalım diye fırtına girişi yapıyor. 40-50 satırda mevzuyu hallettikten sonra, hah tamam bunu yaptığımız iyi oldu, birkaç bölüm sonra bir MP3 browser yazacağız, elimizin altında CD veritabanı olsun, bir de shoutcast server yazacağız... neyse şimdi ben size Common Lisp'teki temel fonksiyonlar, yapılar nedir bir bahsedeyim diye devam ediyor.
..

BEA şirketinde WebLogic, vs. bir sürü şeyle uğraşmış kıdemli bir yazılım geliştirici (Java ve bilimum diğer dilleri iyi bilyor, çok güzel kıyaslamalar yapabiliyor) olan Peter Seibel, boş vakitlerinde (yani Common Lisp kitabı yazmadığı ve gelen geribeslemeleri değerlendirmediği zamanlarda) Lisp ile bir genetik programlama yapıp kendine kendine GO öğrenebilen bir program geliştirmeye çalışıyor. Kısaca tehlikeli biri ve sizi Common Lisp indoktrinasyonuna tabi tutabilir, dikkatli olun derim ;-)
0
Nightwalker
Daha önce konusu geçmişti galiba ama yine şu öykü geldi aklıma. http://www.eminari.com/oykuler/spiral.htm
0
skoylu
Ortada duran birisi, blox dilini kullansın. Aşağıya bakınca, BLOY dilini kullananları görürler. Bunlar X olmadan bu işi nasıl yapıyorlar diye böbürlenirler. Bu silsile böyle devam eder gider. LISP kullanan için Makro vay anam vay olmadan olmaz harikalar yaratan birşeydir. Python'un overload mekanizması da python'cuya öyledir.

Bir gün bu grup biraraya gelip didinirlerken, yukarıdan gökgürültüsü gibi bir ses gelir:

Titreyin ve kendinize gelin. Gercek mutluluk buradadır.

Ve herkes C'yi görüp diz çöker..

Olay budur. Adam vay LISP şöyle mükemmel diye ballandırır, ballandırır sonra da Biz o kodun bir bölümünü C ile yazmıştık der. Buyrun yakın buradan..

Güçlü dil istiyorsanız C kullanırsınız. C kullanıcısı için LISP ve PYTHON ile oynamak anlık işlerdir. C Bir ordu gücü verir. Pyhon veya LISP ise ancak bir kuvvet olabilir (DEniz, kara, hava...)..

Budur derim, Python ile COMAR Yazmaya giderim..
0
malkocoglu_2
Bir de, Eiffel adinda bir dil vardi....

Ustad Bertrand Meyer'in yarattigi bu dil, hem pur nesnesel, hem de cok gerekli bazi yazilim muhendisligini rahatlatacak yapilari temelden destekliyordu. Mesela, onsartlar (pre-conditions) , son sartlar (post-conditions), nesne ici degismezleri (class invariants) gibi kavramlar C usulu "assert" gibi degil, dilin nesnesel sisteminde kokten desteklenmekteydi. Orn: class A da sunuyap() adli bir metotta bir onsart tanimladiginiz zaman, ve class B ile A'dan kalitim ile sunuyap() metotunu alir, tekrar kodlarsaniz (redefine), ust sinifin onsartlari, B::sunuyap'ta tanimlanabilecek onsartlar ile VEYA (OR) islecinden gecirilir. Bu bence nesnesel yapilarda muthis bir kontrol kabiliiyeti getirmektedir. Cunku, B sinifi A'nin daha "ozellistirilmis" halidir, ama tabii bunu yaparken A'nin gerceklestirdigi bazi sartlari gozardi etmez, bilahere VEYA ile A'nin onsartlari alinir. Son sartlar VE isleminden gecirilirler, yani guclendirilirler. Bu da bir nesnesel icinde gereklidir, ve dili tasarlayanin bu kavramlari boylesini uydurabilmis olmasi mimari bir sekerlemedir.

Bahsettigim onsart, sonsart ve degismezler dil icinde AYRI sozdizim yapilari ile destekleniyorlardi, yani makro filan degiller. Tabii sonuc ortami (production) icin butun sartlari kapatmaniz mumkundur, test safhasini astiginiz zaman daha hizli islem icin bu yapilabilir. Bu islem derleyicinin bir seceneginden ibarettir.

Bir zaman, fi tarihinde, bu Eiffel dilinin sIkI bir takipcisi idim. Bertrand Meyer ile Boston'da bir seminer'te nihayet tanistigimda, Object Oriented Software Construction adli klasigini soyle imzalamisti "Usenet'teki muthis desteginiz icin tesekkurler".

Dil savaslari cok zevklidir. Zamaninda C++'cilar ile USENET'te alevli fikir alisverislerinde bulunurduk. Fakat ne yazik ki PIYSASA KARARINI VERIYOR. Ben. Eiffel'i ogrenmis olmakla kendimi sansli hissediyorum. VE LISP icinde ayni seyleri soyleyebilirim. Her yerde kullanilmayabilir, fakat icinden ogrenmis oldugum ve icsellestirdigim taraflari ile beni daha iyi bir programci yapmistir zannediyorum.


0
bm
Birisi bir Eiffel yazisi tercume etmis veya yazmis da FM yayinlamis mi?
0
realist
Değerli arkadaşlarım;

Maalesef birinin bunu söylemesi gerekiyor. Lisp kullanmakla 40 milyon dolar kazanmak arasında doğrudan bağlantı yoktur. Araç başka, amaç başkadır.
0
e2e
Kaç gündür bu yazıyı ve yazılan yorumları imrenerek takip ediyorum. CL üzerine yürüyen, ya da öyle görünen bu tartışmadan çok şey aldığımı söylemeliyim.

Fakat benim asıl merak ettiğim, aslında en çok tartışılan konulardan biri olan, "göreve göre dil" konusu. Örneğin, "Bir sistem yöneticisi şu dille ilgilenmeli", "programcılığa yeni başlayan fakat devam ettirmek isteyen şununla başlamalı", "kafayı ağlarla bozmuş biri şu dille mutlaka haşır-neşir olmalı", "hiçbir şeye ilgisi olmasa da, iyi bir bilgisayar kullanıcısı en azından şu dile bir gözatmalı" vb. gibi belirlemeler yapılabilir mi? Sizlerin bu konulardaki önerileri nelerdir?
0
bm
Beklediginiz cevap olmayacak belki ama yapilabilecek en saglam tavsiye en az okuyabilecek kadar Ingilizce ogrenmenin cok faydali oldugu yonunde. CL ile tanismanizin size bir faydasi olduysa (ki bu sirf kullanmak degildir, 'yahu neler varmis, acaba baska nelerden haberim yok' demek de kazanctir) bunun tamamen egrisi dogrusuna denk geldigi icin oldugunu soylemek isterim. Ben memleketimle biraz ilgilendim, FZ'ye denk geldim de tercumeler yapildi. Bu dilin kac yasinda oldugunu dikkate alirsaniz, ufkunuzun biraz acilmasinin boyle kazalara bagli olmasinin ne derece kisitlayini olugunu goreceksiniz.

Verdiginiz listede programlamayla direkt alakali bir tek "programcilik" basligi var.

Sistem yoneticiliginde onemli olan program yazabilmek degil bence. Titiz/supheci olmak, kullanicilara (sekreter de olabilir muhendis de) saygili olmak, kendine gunenecek kadar bilmek ama bu guvenin kosullu olmasini saglayacak kadar yapilan ise saygili olmak, isini kesinlikle OS/firewall/switch vs. saticisindan ogrenmemek vs. tarz ile ilgili seyler.

Ag anlamak icin, yine dilden evvel kavramlara hakim olmak (Stevens'in kitaplari + Tanenbaum'un yahut Stalling'in kitabi + Ilgili RFCler) ve neyin nasil yapilabildigini ne sekilde bozulabilecegini gormek icin gercek hayatta yapilan isleri tam anlayincaya kadar devamli sorgulamak.

Genelde alanimizda insanlarin kendilerine ve sirketlerine (bizim durumumuzda isin icine devlet tekelleri girdigi icin millete) zarar vermelerinin sebebi kendilerini hangi konuda cahil olduklarini anlamaktan aciz hale getirmeleri. Bu buyuk olcude tarz meselesi. Bakin Skoylu yukarida saka yapmis ama onun yazdigini ciddi soyleyecek suruyle gayet zeki fakat mesnetsiz kendine guvenden ufkunu kisitlamis insan var. Bunlardan olmamak lazim.

Yakinda burada yayinlanacak Kent Pitman'in Slashdot roportajinin ikinci bolumunde bir liste bulacaksiniz. Dil ismi vermeyi o yaziya birakayim.


0
e2e
Yanıtınız için teşekkürler... Yalnız bu başlıkta değil, yayınlanan birçok diğer yazı ve yorumlardan da bir şeyler çıkarmamak mümkün değil.

Aslında sistem yöneticileri için, özellikle de GNU/Linux üzerinde çalışanlar için "Perl olmazsa olmaz" gibi birkaç yorum okumuştum farklı yerlerde. Sanırım neden olarak kabuk programlama vs.ye yakınlığı gösteriliyordu. Yine web tasarımı/programlamasıyla uğraşanlar için de benzer öneriler vardı. Sormamın nedeni bu okuduklarımdı. Kendi adıma programcılığa "nereden başlamalı" konusunda epey bir fikir değiştirdim. C, Phyton, Perl vs. derken şimdi de CL. Sanırım en mantıklısı birine karar verip bir an önce başlamak olacak.

Kent Pitman röportajının ikinci bölümünü sabırsızlıkla bekliyorum...
0
skoylu
Bir şeyleri önce ayırmak gerekiyor.

Sistem Yöneticisi: Bu adamın işi sistemi yönetmektir. Yönetebilmesi için sisteme hakim olması gerekir. Bunun da ilk koşulu sistemin çalışma modelini iyi bilmektir. BU adamın script ile vs. olan işleri temel veya ileri seviyede batch processing'den ibaret olacaktır. Bu yüzden de başta BASH olmak üzere el altında bulunabilecek PERL, Python gibi bir scripting dilinden anlaması çok iyi olacaktır.
Bilgi işleme sistemi kullanıcısı: Bu adam kimdir? Mesela bir füze tasarımcısıdır. İşi gereği karmaşık uygulamalar kullanır. Bunları ve varsa bunların VBA, AutoLISP gibi genişletme mekanizmalarını iyi kullanmayı öğrenmelidir. Dahası, Python, LISP vs. gibi hızlı ve etkili sonuç alınabilecek dilleri de ortalamanın üzerinde öğrenmelidir. Çünkü, çoğu durumda uygulamalar ona yetmeyecek program geliştirmek durumunda kalacaktır. Fakat bu program genel olarak özel bir durumu ifade edecektir. Bu yüzdende programcının ihtiyaçlarına sahip değildir.

Sokaktaki adam bilgisayar başına oturmuş: Bu adamın programlama öğrenmesi filan gerekmez. Ama uygulamaların ayarını filan öğrenebilmelidir.

Programcı : İşte bam teli burası. Bu adam yukarıdaki herhangi birinin kullanması için gereken bir uygulamayı yazabilmelidir. Bu adamın gerçekten işi bilir olması lazımdır. Bu yüzden de C ile başlamalı, kendini yıllar alacak bir öğrenme sürecine hazır tutmalıdır. Bir ton şey öğrenmesi gerekecektir.

Maalesef en azından benim çevremde programcı ile bilgi işleme sistemi kullanıcısı aynı kefeye konuyor. Eğer Excel'i, kerneli, Firefox'u, Java dilini bir (+bir kaç) programcı yazıyorsa, kendine programcı diyen birisi de bunları yazabilecek kabiliyete sahip olmalıdır. Bugün, gereksiz yere program yazma eforu en çok takıldığımız durum. Program yazmayı gerektirecek bir sürü şey için hazır uygulamalar yeterli olacaktır.

Buradaki "programcı" haricinde diğerleri bir kaç dala daha ayrılabilir. Ama bizim hedef kitlemiz, programcıdır.

İyi bir programcı, ben "LISP bilirim, Python neymiş" demez. Karşımda oturan arkadaş, "Hımm, python ile mi yazacağız, dur bir bakalım nasıl şeymiş bu Python" diyerek daldı, akşama python ile LeX'ten HTML'e, XML'den LeX'e vs. çeviren bir uygulama yazdı çıktı. Ben python ile oturdum, ilk olarak Reference kitabını aldım. 1 Saat sonra bir dil yazmaya başladım: CSL.

Eğer bir "Programcı" LISP iyidir veya Python daha iyidir kavgası ediyorsa henüz olgunlaşmış değildir. O bunların gerekli ve güzel bir kuvvet olduğunu, harekatın durumuna göre cephenin herhangi bir yerinde herhangi birinin kullanılabileceğini bilir.

Peki ben neden boyuna C Der dururum. C ile işi öğrenirsiniz de ondan. Python veya LISP sizden bir sürü şeyi gizler. Bu iyidir, faydalıdır ama bu temel teknikleri öğrenmeden programcılık yapmak, gerekli analiz ve problemi doğru şekilde algoritmaya dökmek imkanı olmaz. C burnunuzu sürte sürte size bunları öğretir.

İyi ama herkes programcı mı olacak? Hayır. Biraz PERL bilerek günlük hayatta karşılabilecek bir sürü problemi çözersiniz. Bugün nasıl bir seçim sonucunu grafiğe dökmek için programlama değil, oocalc kullanmayı bilmek gerekiyorsa, günlük hayattaki pek çok şey de aynı şekilde mevcut uygulamalar yoluyla halledilebilir. En fazla ihtimalle, "batch processing" için biraz PERL kasılır mesela. Programcı ise işte o PERL'i yazacak olan, oocalc'i yazacak olan adamdır. Onun gerçekten çok şey bilmesi gerekir.

Bu yüzden, eğer "Programcı olacağım" diyorsanız, işe C ile başlayın. Yok niyetiniz günübirlik uygulamalar yazmak, biraz daha poweruser olmak filansa hiç bulaşmayın o tarafa. LISP, Python, BASIC vs. gibi modern diller sizin içindir. BASIC'mi demeyin. Visual BASIC'e bakarsanız, modern bir dilde olan her şeyi bulursunuz, üstelik bir de bir ton sağlam "RAD" toolu. Fakat haddini bilmek icap eder. Eğer iş günübirlik kodları aşıyorsa, yolunuz gene C'den geçecektir.





0
malkocoglu_2
Ise gore dil konusu onemli:

Gecende yazdigiim ve oldukca cok miktarda log ureten bir programin log'larindan bilgi cikartmak icin Perl kullandim. Sistem idarecileri de Unix uzerinde dosyalari rahat isleyebilen bir dil isteyeceklerdir. Metin bazli dosyalari degistirmek ve bircok komut satiri programi birbirine tutkallamak icin Perl cok guzel. Bu ihtiyaclar icin daha egzotik olmak isterseniz Ruby ve Phyton'a bakin derim. Ilerisi icin de bir yatirim olabilir. Perl burada simdilik de-facto bir dil. Bunu derken aklima geldi, Sun Microsystems dinamik diller ailesine isiniyor mu ne? Bir sempozyum duzenlemisler ve ileride dinamik dilleri JVM'lerinde destekleme yolunda bazi ustadlari biraraya getirmisler.

http://www.tbray.org/ongoing/When/200x/2004/12/08/DynamicJava

Bir baslangic olmasi acisindan ve Perl/Parrot, Python, Jython, Groovy dillerinin yaraticilarini ayni odada toplamis olmasi sebebiyle herhalde ilginc bir toplanti olmustur.

Servis tarafi, olceklenebilen, bakimi rahat cok miktarda kod icin simdilik Java.

Digerlerinin de belirttigi gibi, kapagin altinda nelerin dondugunu anlamak istiyorsaniz ve "makinaya yakin" olmak istiyorsaniz, C/C++. Bu dilleri kullanirken diger daha ust seviye dillerin sagladigi kolayliklarin da da daha cok zevkine varacaksiniz. C++'da "akilli referans pointer class'lari" yazmistik zamaninda, ve butun bu eforlar garbage collection destekleyen bir dil ile tamamen gereksiz oluyor. Ozellikle kurumsal yazilimlar icin bu rahatligi gorunce C/C++'a kizacaksiniz. Ama her aracin bir yeri var. Isletim sistemi gelistirmek, ya da cok hizli bir sekilde sayisal islemler (number crunching) yapmak istiyorsaniz, C/C++. Mesela Honda'nin ASIMO adli robotu VxWors uzerinde, "buyuk bir ihtimalle" C/C++ ile yazildi. Hani su gecende bizim baskabanimiz ile tanisan robot. Merdivanlerden inebiliyor, Japon usulu selam veriyor, ve dans da ediyor. Burada LISP'in kullanilmamasi bir anlam ifade etmiyor olabilir, ASIMO'nun iyi yaptigi seyler "gozlemleme ve hareket" ile alakali olan kod parcaciklari olmali.

Geri kalan Unix betiklemesi icin sh, her makinada oldugu icin. Tabii kontrolunuz olan her makinada Perl kurarsaniz, Perl de olur. Fakat ABD'deki bazi sirketlerin sonuc ortaminda ILLA KI ticari urunler isteme gibi bir aliskanliklari var; Mesela is yaptigimiz Putnam Investments, boyle bir ticari urun istiyordu, cunku isler yolunda gitmesi _dava acabilecekleri bir antite" olsun istiyorlarmis. Grrr.





0
sundance
http://cl-cookbook.sourceforge.net/

Bu, meşhur O'Reilly Perl kitabı olan, Perl Cookbook'u model alan bir Lisp kitabı projesi.

Benim hoşuma gitti bir bakmakta fayda var.
0
bm
Edi Wietz yapiyordu o isi. Bir de kitap tazacak ve nete acacak [home.comcast.net]. O dokumani sevdiyseniz kitabini da seversiniz, gozunuz nette olsun!
0
Nightwalker
Lisp FAQ türkçe için: http://www.paulgraham.com/lispfaq1.html
0
Nightwalker
Lisp FAQ türkçe için: http://www.ceviz.net/index.php?case=article&id=345&catid=49
0
bm
Elinize saglik! Bu Graham'in FAQ'i. Daha cok "niye lisp>" nevinden sorulara cevap verdigi icin su anki konusmamiza cok uygun.

Genelde Graham Common Lisp guruhu icinde "Scheme + CL'in defmacrosu yeter" tercihi nedeniyle biraz azinlikta kalir. Zaten bu yondeki fikirlerini kendi gelistirdigi arc diliyle uygulamaya koyacak. Bekliyoruz.

Ihmale ugramis iki tane Common Lisp SSSsi daha var, ama onlar daha cok CL kullanlara yonelik:

comp.lang.lisp FAQi [www.faqs.org]

Christophe Rhodes'in guncelledigi sekli

Ama cliki [www.cliki.net] genelde SSS listelerinden daha faydali olabiliyor.

0
FZ
http://www.paulgraham.com/avg.html adresindeki özgün makalenin altında Türkçe çeviriye bağlantı veren Paul Graham'a teşekkürler.
Görüş belirtmek için giriş yapın...

İlgili Yazılar

2008 Yılında E-Öğrenmeyi Şekillendirecek 9 Trend

FZ

Bill Brandon’ın Learning Solutions e-Magazine’de dün yayınlanan “Nine Trends That Will Shape e-Learning in 2008″ başlıklı makalesi bu sene e-öğrenim dünyasında etkili olacak yeni ve gelişmekte olan eğilimleri ele alıp önemli noktalara dikkat çekiyor [1].

Kitap Eleştirisi: Süper Hesap Uzmanları

FZ

Makine öğrenmesi konusu ile ilgilendiğim için askere gitmeden önce Ian Ayres'in 'Süper Hesap Uzmanları : Sayılarla Düşünmek Neden Zeki Olmanın Yeni Bir Yoludur' kitabını okumuştum. 2008 yılının Mart ayında Türkçesi yayımlanmış kitabın makine öğrenmesi, veri madenciliği ve genel anlamda istatistiğin gücü ile ilgilenen herkesin okuması gereken türden bir kitap olduğuna inanıyorum. Yani işadamları da bilgisayar yazılımcıları da çözmeye çalıştıkları problemleri daha iyi anlamak ve daha akıllıca çözümler geliştirmek için bu kitaptan feyz alabilirler.

Her ne kadar söz konusu kitap (Freakonomics'in yazarlarıdan) Steven D. Levitt gibi yazarların övgüsüne nail olmuşsa da hem içerik hem de çeviri konusunda bazı eleştirileri hak ediyor. Kitabı okurken not ettiğim bazı noktaları aşağıda listeledim:

Yazılımbilim - 1. Bölüm

malkocoglu

Teorik yazılımbilim, günümüzdeki bilgisayarların soyut temelini oluştuyor. Bu alanda isimleri tanıdık gelen Turing, Church gibi kimseler olduğu gibi, diğer alanlardan bilim adamları mevcuttur, mesela Kurt Gödel. Tarihçesi belki de ünlü matematikçi Hilbert'in 1900 yılında bir beyan ettiği "açık problemler"'den 10'cusuna kadar giden yazılımbilim, bir problemin çözülebilirliğini ispat etmek için algoritmanın ne olduğundan başlayarak, bazı algoritmaların çözülemeyeceğini bulmak ile devam etti, ve nihai olarak günümuz donanımının altyapısını hazırlayarak önemli bir alan olarak kendini ispat etti.

Projelerde Hata Takip Düzeni - ITracker

malkocoglu

Yazılım projelerinin test safhasında ortaya çıkan hataları, bir iş akışı altında kontrol etmek programcılara ve idarecilere rahatlık sağlıyor. Şu anda içinde bulunduğumuz projemiz için ITracker adlı J2EE bazlı serbest yazılımı seçtik (projemiz tarafından Türkçeleştirilmiştir). Hata takip için gereken düzeni, ITracker üzerinde anlattığımız bu yazının yararlı olacağını umarız.

Projelerde Hata Takip Düzeni

ITracker

Yapay Zeka Yazıları

malkocoglu

Akıllı tahmin yapabilmek (heuristic), zekanın kullandığı önemli bir özellik. Bilgisayarla aynı özelliği aktarabilmek için, 8'li Bulmaca ortamında arama algoritmalarını sitemizde işliyoruz. Kullanılan dil, Common LISP olacak. Çözüm kodları da sitede paylaşılıyor. Bu kodlar, üniversitede alınan Yapay Zeka dersi için geliştirildi.
Yapay Zeka ile Problem Çözümü
Akıllı Tahmin Yapabilmek (Heuristic) ve Yapay Zeka