Ruby hakkında şöyle dört başı mamur bir tanıtım yazmayı çok zamandır düşünmekteyim , fakat yazının gerektirdiği fazlamesaiyi bir türlü denk düşüremedik. Son yıllarda tanıştığım en zarif açık yazılım ürünlerinden biri olan bu betik dilini madem ki teferruatıyla mercek altına alamıyoruz, şimdilik vur-kaç operasyonlarıyla yetinelim. Ruby`yi denemiş ve beğenmemiş veya denemeden beğenmemiş olabilirsiniz (sizi gidi piton`cular sizi :) fakat bir şeye eminim ki kendisini `programlama dilleri delisi` olarak tanımlayan Ruby`nin geliştiricisi Yukihiro Matsumoto`nun (a.k.a. MATZ) 2002 Ruby konferansında yaptığı şu nefis sunuları çok çok beğeneceksiniz: Sunu 1,
Sunu 2.
Üstadın dediği gibi `Be Minor, Be Cool`
Görüşler
Abicim Ruby`nin deliliğini bilemem, üstadın üstadlığını da çok ciddi şekilde ıskalamışımdır muhtemelen, ama bana kendisi alenen hıyar geldi :)
Benim bildiğim m1a2 bundan çok daha sağlam Ruby sunumu yapar. Öte yandan MATZ amcanın söylediklerinde alenen karşı çıktığım noktalar var.
Mesela bu slide. Ben şahsen böyle bir grafiği olan bir programlama dilini kullanmam -eğer ki programlama yapmamın tek amacı, bir şeyi gerçekleştirmek değilse-. Nasıl yemek yemenin tek amacının hayatta kalmak olmadığı gibi. Görünen odur ki bu programlama dili benim aklımı zorlamamakta, dolayısıyla bir ilerleme katetmeme yardımcı olmamaktadır. Beni geliştirmeyen bir şey ise öldürüyor demektir :p (bkz: ehcszteiN)
Okunabilirlik: Yahu bana artık kusma geldi bu muhabbetten. Her zaman söylenen, Python ve Ruby`nin dili bilmeyenler tarafından da okunabilir olduğu. Banane dili bilmeyenlerin okumasından. Ben iddia ediyorum ki, hemen hemen bütün Perl kodları da haftada üç-dört saat perl ile uğraşan insanlar tarafından okunabilir. Zaten o insanlar okusun, Perl kullanmayan birisi Perl kodunu debug mı edecek ? Tamam OCML gibi çok uç örnekler de var ama bu okunabilirliği bu kadar da abartmayalım. Daha doğrusu, diğer diller hiç okunmuyor diye bu kadar abartmayalım, çünkü okunuyorlar!
Son olarak da Lightness (hafiflik) kavramı üstünde duracağım. Hafiflik, ne victoria çağı zamanında anlaşıldığı gibi berbat, ne Japon konseptlerindeki gibi duru bir şey değil zamanımızda. Hafiflik, bir çok şeyi yapmamak için bir kaçış noktası, gereksiz şeylerle doldurduğumuz beyinlerimiz için, aynı derecede yalan bir uyuşturucu. Bakın çevrenize, herşey lite, tv içeriği lite, kitaplar lite, Internet sayfaları lite, yiyecekler lite, arkadaşlıklar, dostluklar lite. Eeee ? Daha iyi bir hayatımız mı var ? Hasan Bülent Kahraman üstadın bu lite-mania üzerine çok güzel bir yazısı var bir gün onu burda yayınlamak isterim.
Maruzatım budur...
Benim bildiğim m1a2 bundan çok daha sağlam Ruby sunumu yapar. Öte yandan MATZ amcanın söylediklerinde alenen karşı çıktığım noktalar var.
Mesela bu slide. Ben şahsen böyle bir grafiği olan bir programlama dilini kullanmam -eğer ki programlama yapmamın tek amacı, bir şeyi gerçekleştirmek değilse-. Nasıl yemek yemenin tek amacının hayatta kalmak olmadığı gibi. Görünen odur ki bu programlama dili benim aklımı zorlamamakta, dolayısıyla bir ilerleme katetmeme yardımcı olmamaktadır. Beni geliştirmeyen bir şey ise öldürüyor demektir :p (bkz: ehcszteiN)
Okunabilirlik: Yahu bana artık kusma geldi bu muhabbetten. Her zaman söylenen, Python ve Ruby`nin dili bilmeyenler tarafından da okunabilir olduğu. Banane dili bilmeyenlerin okumasından. Ben iddia ediyorum ki, hemen hemen bütün Perl kodları da haftada üç-dört saat perl ile uğraşan insanlar tarafından okunabilir. Zaten o insanlar okusun, Perl kullanmayan birisi Perl kodunu debug mı edecek ? Tamam OCML gibi çok uç örnekler de var ama bu okunabilirliği bu kadar da abartmayalım. Daha doğrusu, diğer diller hiç okunmuyor diye bu kadar abartmayalım, çünkü okunuyorlar!
Son olarak da Lightness (hafiflik) kavramı üstünde duracağım. Hafiflik, ne victoria çağı zamanında anlaşıldığı gibi berbat, ne Japon konseptlerindeki gibi duru bir şey değil zamanımızda. Hafiflik, bir çok şeyi yapmamak için bir kaçış noktası, gereksiz şeylerle doldurduğumuz beyinlerimiz için, aynı derecede yalan bir uyuşturucu. Bakın çevrenize, herşey lite, tv içeriği lite, kitaplar lite, Internet sayfaları lite, yiyecekler lite, arkadaşlıklar, dostluklar lite. Eeee ? Daha iyi bir hayatımız mı var ? Hasan Bülent Kahraman üstadın bu lite-mania üzerine çok güzel bir yazısı var bir gün onu burda yayınlamak isterim.
Maruzatım budur...
Açıkçası özellikle sipariş üzerine program yazılması gibi durumlarda programın tek amacı bir şeyi gerçekleştirmek olabiliyor. Yani, evde fazlamesailerinde geliştirdiğin bir programı istediğin dille yazabilirsin, üzerinde kafa patlatabilirsin daha iyi optimizasyonlar yapmaya çalışarak uykusuz geceler geçirebilirsin. Bunlar kesinlikle insana inanılmaz bir haz verir, doğrudur. Üstelik gelişmenizi de sağlar. Ama belirli bir zamanda yetişmesi gereken bir proje varsa özellikle zamanın sıkışık olduğu durumlarda Ruby, Python vs... gibi diller hayat kurtarabilir. Daha önemlisi kendini geliştirmek için yapıyor olsan da bu tarz bir dil kullanmak benim sık sık yaptığım bir syntax error yüzünden kafayı yemek gibi durumları büyük oranda ortadan kaldırarak algoritmaya daha çok odaklanmanı sağlayabilir. Bir kere algoritmayı geliştirdikten sonra ise istediğin dilde implementasyonu yeniden yapabilirsin. Bu durumda da bu diller bir tür taslak hazırlamak için işe yarayabilir (özellikle Python'un PalmOS altında bile çalıştığı düşünülürse.
İkinci konu okunabilirlik. Okunabilirlikten çok ağzı yanmış ve yanmakta olan bir insan olarak şunu söyleyebilirim. Kodu her zaman onu debug edecek olanlar okumaz. Örneğin GTK ile GUI oluşturmayı öğrenmeye çalışıyorum. Elimde bir sürü Open Source program, örnek kod vs... var. Ama ben fanatik Pascal'cı olarak o C kodlarını okuyana kadar canım çıkıyor. Bu nedenle bence bir dilin okunabilir olması oldukça önemli. Evet tanrı dünyayı C++ ile yaratmış olabilir. Ama bu onu okumamı kesinlikle kolaylaştırmıyor.
İkinci konu okunabilirlik. Okunabilirlikten çok ağzı yanmış ve yanmakta olan bir insan olarak şunu söyleyebilirim. Kodu her zaman onu debug edecek olanlar okumaz. Örneğin GTK ile GUI oluşturmayı öğrenmeye çalışıyorum. Elimde bir sürü Open Source program, örnek kod vs... var. Ama ben fanatik Pascal'cı olarak o C kodlarını okuyana kadar canım çıkıyor. Bu nedenle bence bir dilin okunabilir olması oldukça önemli. Evet tanrı dünyayı C++ ile yaratmış olabilir. Ama bu onu okumamı kesinlikle kolaylaştırmıyor.
Bir onemli nokta daha: Ruby, butun oteki dillerde olan ayni ozelliklerin tekrardan paketlenmesi degil. Yeni bir ozellik, calisabilir kod parcacigini bildirgec (parameter) olarak islemlere yollamak.. LISP'de felan var diyorlardi, simdi Ruby'de de var.
Ayrica, metin minciklamasi (manipulation) cok rahat. O seviyede Perl gibi, eksi berbat syntax.
Ayrica, metin minciklamasi (manipulation) cok rahat. O seviyede Perl gibi, eksi berbat syntax.
Kod ile verinin birbirine denkliği konusunda LISP, Scheme gibi diller son noktayı daha doğrusu ilk noktayı koymuş durumdalar (LISP'in Fortran'dan sonra geliştirilmiş ve dünyanın en eski 2. bilgisayar dili olduğunu hatırlayacak olursak ;-)
LISP'den once COBOL gelmedi mi hocam?
Hatirladigimiz uzere, daha bastan programcilik dunyasi ikiye ayrildi.
Bilgi islem icin COBOL, matematiksel hesaplar icin Fortran. LISP 3. olabilir :) Bir arada Simula'da var tabii, bir cok nesnesel tabanli dillerin babasi sayilir! Simula'yi hic unutmamak lazim, Eiffel ve C++ yaraticilari bol bol tesekkur etmislerdir bu dile.
http://www.bilgidata.com/article.jsp?file=a_nesnesel_tasarim.xml
Hatirladigimiz uzere, daha bastan programcilik dunyasi ikiye ayrildi.
Bilgi islem icin COBOL, matematiksel hesaplar icin Fortran. LISP 3. olabilir :) Bir arada Simula'da var tabii, bir cok nesnesel tabanli dillerin babasi sayilir! Simula'yi hic unutmamak lazim, Eiffel ve C++ yaraticilari bol bol tesekkur etmislerdir bu dile.
http://www.bilgidata.com/article.jsp?file=a_nesnesel_tasarim.xml
Şu COBOL Tarihçesi Sayfasına bakacak olursak COBOL ilk olarak 1959 yılında ortaya konmuş. Sayfada COBOL'un 2. bilgisayar dili olduğu iddia ediliyor.
Hemen ardından LISP Tarihçesi ile ilgili sayfaya baktığımızda ise ilk LISP uygulamalarının McCarthy adlı bilgisayar bilimcisi tarafından 1958 Kasım - 1959 Mayıs tarihleri arasında gerçekleştirildiğini görüyoruz. Dolayısı ile sanki LISP biraz daha erken doğmuş gibi.
Ancak açıkçası ben biraz tereddütte kaldım. Bu yüzden de şu anda kesin bir şey söyleyemeyeceğim. Görülen o ki ikisi de kafa kafaya gidiyor eskilik bakımından.
Hemen ardından LISP Tarihçesi ile ilgili sayfaya baktığımızda ise ilk LISP uygulamalarının McCarthy adlı bilgisayar bilimcisi tarafından 1958 Kasım - 1959 Mayıs tarihleri arasında gerçekleştirildiğini görüyoruz. Dolayısı ile sanki LISP biraz daha erken doğmuş gibi.
Ancak açıkçası ben biraz tereddütte kaldım. Bu yüzden de şu anda kesin bir şey söyleyemeyeceğim. Görülen o ki ikisi de kafa kafaya gidiyor eskilik bakımından.
sundance arkadaşıma katılıyor ve şu alıntıyı sizlerle paylaşmak istiyorum:
'The connection between the language in which we think/program and the problems and solutions we can imagine is very close. For this reason restricting language features with the intent of eliminating programmer errors is at best dangerous.' Bjarne Stroustrup
Yani C++ dilinin yaratıcısı üstad ne demiş bizim dilimize çevirirsek: Düşündüğümüz/programladığımız dil ile ele aldığımız problemler ve bunlara karşılık hayal ettiğimiz çözümler birbirleri ile çok bağlantılıdır. Bundan ötürü, programcı hatasını azaltacağız diye bir dilin özelliklerinde kısıntıya, tasarrufa gitmek en basit şekilde söylemek gerekirse tehlikelidir.
E yani doğru söze ne denir ;-)
'The connection between the language in which we think/program and the problems and solutions we can imagine is very close. For this reason restricting language features with the intent of eliminating programmer errors is at best dangerous.' Bjarne Stroustrup
Yani C++ dilinin yaratıcısı üstad ne demiş bizim dilimize çevirirsek: Düşündüğümüz/programladığımız dil ile ele aldığımız problemler ve bunlara karşılık hayal ettiğimiz çözümler birbirleri ile çok bağlantılıdır. Bundan ötürü, programcı hatasını azaltacağız diye bir dilin özelliklerinde kısıntıya, tasarrufa gitmek en basit şekilde söylemek gerekirse tehlikelidir.
E yani doğru söze ne denir ;-)
Hepinizi MATZ`e şikayet edecem... :)
Sevgili Romalılar, Ulu Sezar... :) `Brain power consumption`ı azaltma yaklaşımını niçin racona ters bulmaktasınız? Slaytlarda kastedilenin dışında bir anlamla, yüksek beygir gücüne sahip bir aracın yakıt tüketimini tasarım `trade-off`ları çerçevesinde azaltmayı niçin istemeyelim? E tabi o aracın tasarım gerekleri içinde öncelik `yüksek beygir gücü` ise `yakıt tüketimi` konusunda yapacaklarımız da sınırlıdır. Fakat Ruby -bu ailenin diğer üyelerinde de olduğu gibi- beygir gücünün dışında faktörlerin ağırlık taşıdığı bir betik dili. Yakıt tüketimini azaltmak önceki örnekte `güzel olurdu` burada `mutlaka olmalı`.
Hafiflik hadisesine gelince, e adam onu da açıklamış... Doğallık demiş, `least surprise`, `tutarlılık` demiş. TV türkçesiyle devam edeyim, kepekli mi buldunuz bu dili? Sizi gidi taş fırın erkekleri sizi... :) Yani sundance`ım, Reha Muhtar topic`li bir başka yorumun altında olsaydı bu `hafiflik` hususunda yazdıklarının altına imzamı gözü kapalı atardım ama buraya uydumu şimdi?
Bu hafiflik konusunda örnek olması için birkaç laf... Mesela dilin `hafif`liğine katkıda bulunması için C++ vb. OOP dillerde varolan çoklu-miras alma özelliği Ruby`de yok, onun yerine `mixins` denilen daha basit bir model var. Ama `perlish` regexp`ler her türlü inceliğiyle destekleniyor. Daha ne istiyonuzzz?
> Beni geliştirmeyen bir şey ise öldürüyor demektir :p (bkz: ehcszteiN)Be hey ölümlü gafil... Zamana niçin kafa tutarsın?
We, mortals, have only limited brain resources. (bkz.)Stroustrup`un argümana gelince... Kendi şartları içinde doğru bulurum. Betik dillerin varlığını hesaba katmadan düz haliyle yorumlandığında Stroustrup`un cümlesi `garbage collector`leri de hedef alacaktır ki gerçek de böyledir, pointer kullanımını kaldırdığınızda ve hatta dili `tipsiz`leştirdiğinizde -performansın yanısıra- bazı önemli olanakları da programcının elinden almış olursunuz. Fakat bu meselede `yorumlanan dil` vs `derlenen dil` ayrımını yapmak durumundayız. (Anketteki bir tartışmaya ithafen `php`nin programlama dili olduğunu da tekrar edeyim :) Zât-ı kanaatimce Stroustrup`un cümlesini RMS`in TCL ile ilgili -biraz insafsızca- yaptığı eleştiriler bağlamında geçen şu cümlesiyle `yorumlanan dillere` adapte etmek daha doğru olur.
The principal lesson of Emacs is that a language for extensions should not be a mere `extension language`. It should be a real programming language, designed for writing and maintaining substantial programs. Because people will want to do that!Beğenirsiniz, beğenmezsiniz o ayrı konu, her dilin potansiyel müşterisine yönelik -sadık takipçileri tarafından çok iyi bilinen slogan/mottolarda spotlaştırılmış- bir dizi tasarım önceliği, felsefesi vardır. Ruby`nin de `principal of least surprise` vb. sloganları mevcut. Fakat bu slaytlarda belirginleşen `less brain power consumption`, `lightweight language` laflarının -en azından Ruby`yi takip etmişliğim kadarıyla- kutsal insan MATZ`in, cemaate yönelik olarak `ulu önderimiz der ki` takdimiyle dillere pelesenk edilmesi amacına matufen kurguladığı kutsal cümleler olmadığını tahmin etmekteyim. Burada şöyle bir arkaplan görmekteyim. Ruby gerçekten yeterince takdir edilmeyen bir dil. Tuhaf bir düşünce gibi algılanabilir ama capon malı Ruby`nin tepki gördüğü bazı çevrelerde (bkz. Bruce Eckel) bir tür anglo-sakson/germen dayanışması koklamaktayım. `Python`s poor bastard` vb. akla ziyan hakaretleri başka türlü tevil etmekte zorlanıyorum. Slaytlarda da bu hissiyatlara -!- yönelik bazı cümleler var. `Be minor, Be cool` böyle meselâ. Sonra bir yerde MATZ`in `Christian mormon` vurgusu vs...
Ruby`yi yeterince kullanmadığım bir başka dille karşılaştıramam ve böyle bir tecrübeye dayanmayan -yani Ruby`yi hiç denemeden yapılmış- eleştirileri de dikkate almam. Bir dilin size hissettirdiklerini ancak ve ancak elinizi kirleterek anlayabilirsiniz. (Tabii bu işi `Hello World`le değil de önceden bir başka dilde çözdüğünüz cevval bir sorunu o dille kodlamanız şartıyla ;) Bir deneyin bakalım yaw...
Aklını zorlamak... Birkaç gündür Scheme ile uğraşıyorum ve 'zorlanmak' ne demektir gayet iyi anlamış durumdayım :)
Komikten de öte, yani bir arkadaşımın 'Ne Scheme dil ulan bu?' dediğini duyar gibi oldum bir an :) Kendisini severim, sayarım o ayrı. Ama ben gene de azimliyim. En son bir Huffman kodlaması örneğinde kalmıştım (bkz. Purple Book) çok hoşuma gitti. Oradan ufaktan devam ediyorum...
Huffman! Cok super, ben de universiteye giderken odev olarak Huffman kodlamasi yapmistim. Ilk yazdigim kod dosyayi sIkIstIrdIktan sonra sonuc dosya buyumustu! Huffman agaci ile bayagi ugrastigimi hatirliyorum.. Basarilar dilerim.
Valla yani elde edeceğim şey olsa olsa seninki ile aynı işi yapan sonuçtur, programdır, budur yani :) Asıl başarı ve takdir Bay Huffman'e aittir diye düşünüyorum, söz konusu 'güzel' algoritmayı geliştirdiği için. Sıkıştırma alanında (elbette ki) 'son nokta' olmamasına rağmen bence bu tip bir konuya giriş açısından ve 'pedagojik' bakımdan güzel bir 'model' teşkil etmekte bu algoritma. Ve Scheme dili ile uygulaması da epey eğlenceli.
Ancak benim aklıma Perl ile Scheme'i birleştirmek gibi abuk sabuk bir fikir de getirdi ;-) Yani girdi metnini Perl ile tarayıp harf frekanslarını oluşturduktan sonra bunu Scheme dilinde yazılmış Huffman ağacı oluşturma fonksiyonuna pas geçerek mesajı kodlamak falan (ne gerek var dediğinizi duyar gibi oluyorum, o kadar da fantazi yapma hakkım olsun gecenin bir vakti ya :-P ) sonra da çıktıyı bir dosyaya yönlendirmek, vs. (Belki de yapmam, belki de gözümü korkutur, belki de parantezler arasında yitip giderim ama olsun yitip gideceksem de Perl ve Scheme'in derinliklerinde yitip gideyim :)
Son olarak alakasız bir konu, bilgidata sitesindeki Rayleigh-Ritz ispatını sunan Burak Bayramlı''ya buradan selamlarımı iletiyorum. Hayır kendisini tanımam etmem ama gecenin bir vakti böyle güzel ve düzgün bir Türkçe ile böyle teknik bir yazının düzgün bir şekilde sunulması ve bunu genellikle teorik bir yaklaşım beklemediğim türden bir bilgisayar sitesinde görmem (bu benim önyargım, bu site ile ilgili değil genel olarak popüler bilgisayar siteleri ile ilgili bir önyargı) beni ziyadesi ile sevindirdi, bir anda kendimi nedense biraz daha iyi hissetmeme yol açtı.
Kısaca budur yani :)
Ancak benim aklıma Perl ile Scheme'i birleştirmek gibi abuk sabuk bir fikir de getirdi ;-) Yani girdi metnini Perl ile tarayıp harf frekanslarını oluşturduktan sonra bunu Scheme dilinde yazılmış Huffman ağacı oluşturma fonksiyonuna pas geçerek mesajı kodlamak falan (ne gerek var dediğinizi duyar gibi oluyorum, o kadar da fantazi yapma hakkım olsun gecenin bir vakti ya :-P ) sonra da çıktıyı bir dosyaya yönlendirmek, vs. (Belki de yapmam, belki de gözümü korkutur, belki de parantezler arasında yitip giderim ama olsun yitip gideceksem de Perl ve Scheme'in derinliklerinde yitip gideyim :)
Son olarak alakasız bir konu, bilgidata sitesindeki Rayleigh-Ritz ispatını sunan Burak Bayramlı''ya buradan selamlarımı iletiyorum. Hayır kendisini tanımam etmem ama gecenin bir vakti böyle güzel ve düzgün bir Türkçe ile böyle teknik bir yazının düzgün bir şekilde sunulması ve bunu genellikle teorik bir yaklaşım beklemediğim türden bir bilgisayar sitesinde görmem (bu benim önyargım, bu site ile ilgili değil genel olarak popüler bilgisayar siteleri ile ilgili bir önyargı) beni ziyadesi ile sevindirdi, bir anda kendimi nedense biraz daha iyi hissetmeme yol açtı.
Kısaca budur yani :)
Bi dakka bi dakka ne dedin sen? Dosya büyüdü mü? Kafam karıştı :-P Yani önce sıkıştırdın da sonra açarken gereğinden çok mu büyüdü? Yoksa sıkıştırayım derken elde ettiğin orjinal dosyadan da büyük bir şey mi oldu? Tanrı bizi sıkıştırma algoritmalarının lanetinden korusun :) Demek ki neymiş, öyle önümüze gelene Huffman uygulamamak gerekiyormuş, hatta algoritma diyebilmeli ki: Hocam hiç kasma beni de kastırma, şimdi yani ben bunu sıkıştırmaya kalksam bu iyice şişecek, bu şekilde bıraksam çok daha iyi olur ama inanmıyorsan hesap kitap yapayım, sıkıştırayım da gör, yani eğer bana güvenmiyorsan... Sen iyisi mi bana daha uygun bir dosya ver, şöyle içinde bol tekrarlar olan falan ;-)
Sahsen Ruby ve RubyUnit kullanarak kod yazdim; ve hakikaten guzel kodlaniyor. Birim testleri unutmazsaniz yanlis sayisi fazla olmuyor, sadece bir noktada uste-bindirme (overloading) oldugunu deleyici bulamadi ve kafasi karisti. Fakat bu ufak bir ornekti diyebilirim, tamir edildikten sonra hersey calisti.
Saygilar,