Eh, sadece Muad Dib geleceği görebilir (O da görmek istemezdi).

Bir script dili öğrenmek herkesin işine yarar. Hatta bildiğiniz bir script dili olması, arada sırada onla oynamak sadece entellektüel bir eğlence olmaktan öte gün gelir faydalı olur.
Ruby öğrenmekle, farklı dillerden aldığı güzel özellikler sayesinde pek çok temel kavramla tanışmış olursunuz. Bu sayede ileride başka dilleri öğrenmeniz kolaylaşır. Benzeri olan diller (php, perl, python) daha çok kendilerine özgü diller olmalarından ötürü bu eğitsel avantajı Ruby kadar taşımazlar.

"... Bu sevilme faktörü çok önemli programcıların kalbini kazanmış olması ve web programlamaya uygunluğu ona de facto standart olma yolunu açacaktır diye tahmin ediyorum."

Tabii eklemem lazım Ruby, php gibi dillerin tersine genel amaçlı bir dil. Web programlama kesinlikle uygun olduğu tek alan değil. Zaten mevcut kütüphane desteğine bir göz atılırsa bu açıkça ortaya çıkıyor.

"Ruby'nin yaratıcısı Matz için 21. yüzyılın Larry Wall'u diyebilir miyiz?"
Uhm, Larry Wall daha ölmedi :)
Ayrıca ikisinin yaklaşımları da farklı, Matz baştan beri kafasında bir belirli yaklaşım taşıyor, hedeflediği belirli kriterler var. Örneğin Ruby'i tasarlarken öğrenme eğrisinin düz olmasını yani programcının önüne öğrenirken engeller çıkarmamasını istediğini söylüyor.

"kesinlikle her ne yapilacaksa Linux/BSD cercevesinde yapilmalidir, vs. gibi bir arguman dogru degildir."
Ben bunu kast etmemiştim. Tek kültürlülüğe en başta ben karşıyım alternatif teknolojilerin yaşam hakkı çok önemli. Benim yaklaşımım Linux çekirdeği ile bu kadar çok yenilik mümkünken kimsenin tekerleği yeniden keşfemekle uğraşmayacağı ve var olanı değiştirmeyi tercih edeceğiydi. Önümüzde örnekler mevcut mesela FUSE örneği. Geçmişte mikrokernelin avantajlarına örnek olarak verilen bir uygulama işte Linux ile de yapılabiliyor. Tabii çok daha radikal fikirler olacak ve umarım ilerde ciddi atılımlara neden olacaktır ancak kısa vadede bunların şu anki ortamı sil baştan değiştirmesi pek olası görünmüyor bana çünkü Linux bugün her yerde ve hemen her maksatla kullanılıyor (Süper biligisayar, gömülü, real time, virtualization, güvenlik açısında geliştirilmiş, masaüstü, server, cluster, NUMA, vd.). Esnekliğini ve pratik gereksinimlerin hemen hemen tümünü karşıladığı denenmiş ve biliniyor.
Donanım konusunda zaten itiraz gelmedi ama yine de biraz daha açayım. Lisp makinelerinin devri geçti derken tamamen ekonomik koşullardan bahsediyorum. Bildiğim kadarı ile o yıllarda bile ki o zamanlar bilgisayar satmak demek işletim sisteminden ek donanımlarına kadar dizayn etmenizi ve ürününüzü farklılaştırmanızı mümkün kılan yıllardı, Lisp makineleri pek fazla satmamışlar. PC donanımı günümüzde çok geniş bir alanı hegamonyasına aldı. Server, masaüstü derken iş istasyonlarının da yerine geçti.
Son olarak Ruby'nin de facto yani zorlama olmadan kendiliğinden standart olmasını beklediğimi söylemiştim. Buna inanmamın sebebi kısa zamanda diğer örneklerin yapamadığını yapabilmiş olması, web programlama konusunda iddiası (ki bu sayede yayılacaktır) ve yeni başlayandan uzmanına kadar, Java kullandan Perl kullanana kadar hemen her kesimin kullanınca "sevdiği" bir dil olması. Bu sevilme faktörü çok önemli programcıların kalbini kazanmış olması ve web programlamaya uygunluğu ona de facto standart olma yolunu açacaktır diye tahmin ediyorum.

Tam aklımdan geçenleri dile getirmişsiniz. Linux çekirdeği sınıflandırmaya göre monolitik bir çekirdek olmasına karşın öyle ilginç yeniliklerin uygulama haline geldi ki. Örneğin daha geçen gün FUSE yani user level'da dosya sistemi mount etme özelliği ile ilgili bir sunum gördüm. Sunumda "mikrokernel gibi" gibi bir tanımlama vardı. Bu aşamadan sonra Hurd ve başka alternatif teknolojiler elbette çıkacak ve güzel olacak ama Linux çekirdeği üzerinde her türlü melez ve evrimsel gelişme ve ilerleme de olacaktır. Kısacası Linux klasik anlamda bir Unix çekirdeği değil artık ne de GNU/Linux platformu klasik bir Unix. Linux'un gelecekte gittikçe özel amaçlara daha da uygun hale geleceği belki çatallanacağı ve farklı kollardan yoluna devam edeceği aşikar.
Ruby konusunda ise şu saatte ayrıntıya girmek istemiyorum ama pek çok güzel özelliği çekinmeden bünyesinde birleştirmiş camia olarak da yeniliklere açık ve ilerici bir dil ayrıca önyargıları yenip deneyen pek çok kişiden oldukça olumlu yorumlar geliyor. Tabii ben Ruby geleceğin "tek ve birick" dili olacak demiyorum sadece önemli bir konuma geleceğine inanıyorum.

Güzel ve ilginç bir yazı. Devamının gelmesini dilerim :-)
Günümüzde ve gelecekte ne yenilik olacaksa (GNU/)Linux ve *BSD platformlarında olacağını sanıyorum. Bunca gelişmeden sonra tekerleği yeniden keşfetmek hem zahmetli hem de anlamsız olur. AMD 64'den sonra Intel ve AMD mimarisinin de daha uzun süre burada olacağı belli oldu. Artık Lisp makinesi gibi donanımların vakti geçti. Ama yazılım açısından ders alınacak çok şey var hala...
Ruby konusunda ise çok olumlu şeyler düşünüyorum. Ruby elbette bir son nokta değil ama yazılım dünyasına çok şeyler kazandıracak bir özgür yazılım değeri. Gelecek yıllarda Ruby'nin de facto standart olacağını sanıyorum. Yeni dil öğreneceklerin dikkatine...

1.1 Alpha sanıyorum çıkmış bulunuyor herkese hayırlı olsun. Pardus ekibinin tebrik ediyorum bu fantastik sürüm için.

Bu arada Sn. Çağlar Onur'un blog girdisini gördüm gezegende, bir cümle dikkatimi çekti:
"... halen bilgisi olmadan fikri olan Qt lisansı/GNOME kütüphanesi diyen sazanları ...". Kendisi blog girdilerinden tanıdığımız kadarı ile içindeki "ergen"i yaşatmayı başarmış ender yetişkinlerden. MFÖ'den "Peki Peki Anladık" şarkısını yolluyorum bu nazik sözlerine karşılık olarak.

Gtk'nın dağıtılması yeterli değil çünkü tarihsel sebeplerle Gtk+ ve Gnome API'leri birbirine karışmış durumda (fakat bu durum en az 1-2 sene sonra çıkacak olan Gtk+ 3.0 ile düzeltilecek, bakınız Project Ridley) yani saf Gtk+ uygulaması yazmak şu anda pratik değil ve Pardus'ta (şu anda) Gnome libraryleri mevcut değil gördüğüm kadarı ile (yanılıyorsam lütfen düzeltin).
Pardus umut ettiğimiz gibi Türkiye'de yüzde olarak çift haneli kullanım oranlarına ulaşınca içerisinde Gnome librarylerinin bulunması bahsi geçen lisans ücreti gerektirmemesi sebebi ile önem kazanabilir belki (tabii Gtk/Gnome ile sınırlı değiliz wxwidgets da kullanılabilir örneğin). Ancak şu anda bunun için panik yapmaya gerek yok (burdan itibaren genele sesleniyorum). En başta da zaten tam kapasiteleri ile çalışan geliştiricilerle bu konuyu tartışmanın bir anlamı yok, Pardus'ta Gnome desteği olacaksa bu ya yeni geliştiricilerle ya da gönüllülerle mümkün olacaktır. Bu yüzden bu konuya önem veriyorsanız konuyu Pardus'un geliştiricileri ile tartışmak yerine yönetici konumundaki insanlara izah etmeli ve onların bu konuda harekete geçmesini sağlamalısınız. Geliştiriciler zaten canla başla çalışırken onlardan daha fazlasını beklemek yanlış olur. Tabii bir devlet kurumuna derdinizi anlatmak ne kadar kolay olur bilemem ancak başka çare de yok gibi görünüyor.

Fanatik sözcüğünü itham etmek maksadıyla kullanmadım. Kullanmamın sebebi Python'a benzer örneğin Ruby veya biraz daha kısıtlı bir kullanım alanına sahip da olsa Lua gibi diller mevcutken neden sadece Python'dan bahsediyorsunuz? Bu tek tarafalı bakışı eleştirmek için kullandım fanatik kelimesini. Deseniz ki örneğin Lisp zor ama Python/Ruby/Lua kolay, itirazım farklı şekilde olurdu.

İtiraz ettiğiğm ikinci nokta dilin sentaksının aşırı derece ön plana çıkarırılıyor oluşu. Bu yaklaşımı sadece sizde değil dediğim gibi başka Python programcılarında da gördüm. Sentaks ne öğrenmeyi ne kullanmayı bu kadar fazla etkiler. Okunabilirliği asıl etkileyen dilin soyutlama mekanizmalarıdır. Öğrenilebilirliği asıl etkileyen dilin zihinde modellenme kolaylığıdır. Bu iki alanda da Python'un burda adı geçen dillerin çoğundan daha iyi olduğunu düşünmüyorum.

Lisp kullandığınızı fakat öğretemediğinizi ifade ettiniz. Ama hangi Lisp'den bahsetttiğinizi bile yazmamışsınız. Lisp bir dil ailesinin adıdır. Scheme, Common Lisp, Emacs Lisp ve diğerleri gibi bu aileye mensup az ya da çok birbirinden farklı diller var. Ayrıca kötü örnek örnek kabul edilmez; belki sizin öğretme metodunuz yanlıştı? Bazı üniversitelerde programlamaya giriş dersinde Scheme kullanılılıyor; bunun bir anlamı yok mu?

Bu modül konusuna takılmayalım. O liste kabaca hazırlanmış bir listeydi herhangi bir dili hedef almak gibi bir niyetim olmadığı için ayrıntılı bir liste de hazırlamadım. Ama hala standart kütüphanenin güya kolay bir dil için fazla "kirli" olduğunu düşünüyorum. Daha önce de belirttiğim gibi önemli olan özgür yazılım olması. Python ile bir derdim yok sadece yanlış önyargılar oluşmasına neden olacak "propaganda"ya karşı mücadele ediyorum. Ne yazık ki bazı diller bir "dünya hakimiyeti" peşinde koşuyorlar. Python camiasını izlemeye çalışıyorum. Örneğin Rails'e karşı propaganda yapmak gibi çabaları enteresan olduğu kadar yanlış buluyorum. Çünkü Rails "iyi" olduğu için isim yaptı; PR ile değil. Bırakın özgür yazılım başarı için uğraş versin neden yapay ayrımlar yaratmaya çalışıyorsunuz? İşin aslı Rails'in başarısından sonra Python'un bu standart dil olmayacağı iyice belli oldu çünkü pogramlama dünyası web programlama ekseninde dönüyor (açmam gerekirse, zincirleme bir reaksiyondan, kritik kitleden falan bahsediyorum. Elbette herkes web programlama yapmıyor).

Scheme'in #t #f meselesine gelince bu bazı Python fanatiklerinin başka dillere nasıl da kolayca kulp taktıklarına güzel bir örnek olmuş. Python kendi doğrusundan başka doğru tanımıyan ve sonuç olarak rekabet gücü düşmüş bir özgür yazılım programlama ortamı yaratma tehlikesini beraberinde taşıyan bir çeşit uzak durulması gereken tehlike olarak kendini gösteriyor (abartıyorum tabii, fanatizm fanatizmdir, nesneyle doğrudan bir ilgisi yoktur elbette).

> O yuzden dilleri birbirleriyle karşılaştırmak çok saçma.

Kesinlikle aynı fikirdeyim. Karşılaştırma pek anlamlı değil ama belirli bir dil üzerinde konuşmak mümkün tabii.

> Bir dil oluşturulurken "aman millet kolay öğrensin" gibi birşeyin düşünüldüğünü sanmıyorum.

Hayır bunların düşünüldüğü diller var ve olmalıdır. Programlama eylemi farklı kesimler tarafından gerçekleştirilebilen bir şey olmalıdır. Ayrıca kimin için kolay? Programlama bilen biri için mi kolay, yeni başlayan biri için mi kolay? Bunların ayrımı yapılmadan yukardaki gibi bir ifade kullanmak pek manalı değil. Bu yorumlarda genellikle programlama bilmeyen veya yeni başlamış biri açısından bakıldı hep. Bu insanlar için Python kolay dendi ben de hayır Python kendi halinde, benzerlerine kıyasla ortalama bir dil, kolaylık açısından büyük artılar taşımıyor düşüncemi ifade ettim. Derdim herhangi bir dili küçümsemek değil sadece yanlış önyargılar oluşmasını önlemek. Keşke söylendiği gibi hem kolay hem yetenekli olsaydı sonuçta özgür yazılımın başarısı hepimize fayda sağlar.

http://blog.philkern.de/archives/177-First-SoC-status-report-Reportbug-Gnome2-GUI.html
Debian hata raporlama aracını yazan arkadaş Python ve Ruby karşılaştırması yapmış. Sadece blog girdisine değil alttaki yorumuna da bakın lütfen.
Not: Ruby'nin yeni sürümü native thread desteğine sahip olacak.

* 1. Standart kütüphanesinde obsolete olmuş veya birden fazla instance'a sahip....

Yeni başlayanların işini zorlaştıran şeyler bunlar aradığı şeyin nerde olduğunu bilmeyen biri bütün bu kirlilikle mücadele etmek zorunda.

* 2. Tuple tipi nedir? Pythonda bir değişken bir değer değil, bir değerler dizisine....

Tuple'ın dilde bulunmasının nedenin bu olduğunu sanmıyorum. Sanırım sizde Tuple neden var sorusunun yanıtını tam bilmiyorsunuz çünkü açık bir yanıt vermemişsiniz. İşin daha acı yanı Tuple ne için kullanılır anlamıyorsanız kullanmayın demek. Bu şu anlama geliyor Python'u tamamen anlayamazsınız ama bir şekilde Python kullanıyorsanız (zorundaysanız veya öyle istiyorsanız) Python'la iş görebilirsiniz. Kullandığı dili bilmeyen programcılar neslinin oluşmasına neden olmaz umarım bu yaklaşım.

* 3-4. Python dilinin mevcut halinin asıl özelliği bu zaten...

Herneyse 3 ile 4'ü birleştirmişsiniz ama bunların birbirleri ile ilişkisi fazla değil. Daha doğrusu değişkenlerin referans tutması default argüman değerinin bir kez evaluate edilmesini gerektiren bir şey değil kesinlikle. Örneğin Ruby'de böyle değil. Direk Python tutorial'a baktım çok sık kullanılabilecek bir kod örneği vermiş, işte bir diziye bir değer ekle (ya da başka bir işlem önemli değil) dizi parametresi verilmediyse boş dizi kullan. Sonra uyarılar vermiş workaround falan vardı FAQ kısmında eskiden şimdi bakmadım. Sonuçta tamamen dilin o konuda anlamsız dizaynı, eğer ben state saklamak istesem bunu neden default argüman'da yapayım? Nesye uzatmayım dili öğrenirken, kullanırken başına iş açacak potansiyel mayındır bu tip gariplikler.

* 5. Python'un herhangi bir dile benzemesi gerekiyor mu?...

E, çok iyi olur. Çoğu insan birden fazla dil öğrenmek durumunda kalıyor. Benzerlikler öğrenme sürecini oldukça kolaylaştıracaktır.

* 6. Self parametresi, bulunduğunuz nesneyi...

Asıl eleştirim metodlarda ilk parametre olarak self (tabii kafa karıştırmak isterseniz kendim falan da yazabilirsiniz) kullanılmak _zorunda_ olması. Ayrıca yine member erişimlerinde yine aynı sıkıcı kelimeyi kullanmanız lazım hep. Tekrar kötüdür, sıkıcıdır. Hadi görmezden gelelim bunu ne de olsa mükemmel dil yoktur diyoruz.

7. map, lambda gibi şeyleri kullanmak veya kullanmamak size kalmış...

Yine aynı noktaya geldik: anlamıyorsan anlama, dili iyi bilmek zorunda değilsin noktası. Ya yeni başlayan arkadaşın önüne map ve lambda kullanan kod gelirse? Ya da madem python kolaylıklar dili neden lambda'da bu gereksiz sınırlamalar var?

* Gördüğüm kadarıyla, bir bahane bulayımi amanda Python şöyledir diyeyim kaygısıyla yazılmış bir post olmuş maalesef.... mesela bu mevzudan bahsedilmiyor.

Hayır böyle bir derdim yok. Sadece uzun bir listeden o anda aklıma gelenleri yazdım. Uzun zamandır Python'la uğraşma ihtiyacı hissetmiyorum zaten, belki ihtiyacım olsa rehine pisikolojisi içerisinde sevmeye bile başlardım Python'u :) Ancak benden bu kadar siz listeyi daha da uzatabilirsiniz eminim.

* Burada mesele edilen konu, sadelik, yalınlık filan feşmekan değildir. Mesele, hesap makinesi pozisyonundan öteye geçip, algoritma kurmaya başlayacağınız noktada önünüze çıkacak olan meselelerdir. Bu noktada Python gerçekten kolayca baş edilebilecek bir dildir.

Tabii bilmediğiniz şeyleri atlayarak, sevmediğiniz şeyleri görmezden gelerek iş görebilirim diyorsanız buyrun kullanın zaten hiç bir zaman Python çok zor bir dildir demedim ki. Ama çok zor olmaması kolay olduğu anlamına gelmiyor.

* Bu tür, yanlış eleştirileri her dil için yapabilirsiniz. Çünkü yaptığınız şey, o dili diğerlerinden ayıran sistematiği eleştirmek. Bu lsitedeki parametrelerin hiç biri, yeni başlayan bir programcı için ayak bağı olacak, zorluk çıkaracak vs. bir şey değil. Ancak, bir vakit BASIC ile uğraşmış birisine bu liste anlamlı gelir. Ama yeni başlayan gittiği her dilde bu yapıları dile özgü haliyle öğrenecektir zaten eli mahkum.

Eleştirilerim eksik olabilir ama yanlış olduklarını sanmıyorum. Ama son cümleniz gereçekten hoş olmuş. Eli mahkum bir şeyleri öğrenmek zorunda kalmak Python için de geçerli madem biz boşuna tartışmayalım o halde.

Bu arada, Python kolay değil Scheme kolay deyince ister istemez bir Lisp Python kıyaslaması oluyor haklısınız :) Aslında kolay diller listeme Scheme'in girmesinin sebebi Scheme'in minimalistliği, zarifliği; pratik kullanım için tasarlanmamış ancak sonuç olarak zarifliğiyle pratik kullanıma da uygun bir dil ortaya çıkmış. Dili kuralları nispeten az ve öz, kolay öğrenilmesinin sebebi bu. Kolay öğrenilmesinden de öte az miktarda olan bu kurallar bazı konulara uyanmanıza yardımcı oluyor. Ancak işte Scheme belirli bir uç noktayı temsil ediyor yoksa zaten Python veya Ruby zaten Lisp ailesinden dillere pek çok benzerlikler taşıyorlar. Kolaylık konusunda ise Scheme'e ayrı bir yer vermek lazım kanımca...

Yanlış anlaşılmaması için özellikle vurgulamak isterim, ilköğretim öğrencisi için ne Ruby uygundur ne de Python, sanıyorum Scheme'de bayağı sulandırmadan o seviyedeki öğrencilerin öğretimi için kullanmak zordur. Ancak öğretim gibi derin bir konuda fikir öne sürmek yerine sadece, Ruby'yi veya Scheme'i bu seviyede _önermediğimi_ vurgulamak isterim.

Lisp Python kıyaslaması yapmıyorum. Öğrenme eğrisi gibi kavramlarla tartışma yapmaya da niyetim yok. Sadece kolay dil deyince BASIC, Pascal ve (ileri özelliklerini daha sonraya saklamak şartıyla) Scheme anladığımı yok illa Python kategorisinde bir şey seçmem gerekiyorsa da farklı dillere aşinalığı arttırma özelliğiyle, zarif dizaynıyla ve kendi fikrime göre zihinde modellenmesin bu yüzden de öğrenilmesinin ve kullanılmasının kolay olduğunu düşündüğüm Ruby'yi anlarım. Python'un kolay olmadığını, yeni çıkacak Python sürümünde gelecek özellikleri anlamak için ileri CS konularını içeren sitelere bakmak durumunda olmanın neresinin kolaylıkla bağdaştığını anlamadığımı da eklemek isterim.

Burda anlatmaya çalıştığım şey "Python öğrenmesi ve kullanması kolay bir dildir" etiketinin geçmişten kalma günümüzde eski geçerliğlini yitirmiş bir etiket olması. Python'a çok zor veya aşırı karmaşık demiyorum ancak iddia edildiği gibi çok kolay ve yeni başlayanlar için, ilköğretim seviyesi için vb. ideal bir dil olduğuna katılmadığını söylüyorum. Python doksanlarda nasıldı diye merak ediyorsanız webde yeterince bilgi bulabilirsiniz sanıyorum.

Python kolay olduğu ve yeni başlayanlara uygun bir dil olduğu o kadar çok tekrarlanıyo ki insanlar bunu sorgulanamaz bir gerçek gibi kabulleniyorlar. İşin aslı python belki doksanlı yıllarda özellikle de Perl gibi bir dille kıyasla kolaydı. Anak geçen yıllar içerisinde büyüdü ve karmaşıklaştı. Bugün Python'a kolay bir dil diyen ya dili bilmiyordur ya da bilinçli dezenformasyon çabası içindedir. Bunun böyle olduğunu düşünüyorum çünkü tam üç defa python öğrenmeye çalıştım ve tam anlamayadığım noktaların çokluğu nedeniyle bundan vazgeçtim. Hepsini açıklamam olanaksız ama bazı sebepleri sıralamaya çalışayım:

1- Standart kütüphanesine bakalım. Bazı modüllerde açıkça kullanılmaması gerektiği içsel kullanım için olduğu veya eskidği falan yazılı. Sadelikten uzak belki, 3-4 tane dbm türevi için modül var. İçinde aradaığınızı bulmanız için tecrübeli olmanız gerekiyor.
2- Tip karmaşası. Tuple tipi nedir? Biri bunu yeni açıklayan birine açıklasın. Sakın sadece okunabilir dizidir falan demeyin Tuple'ın ne CS terminolojisinde anlamı ne de GvR'nin dile koyma sebebi budur. İşin aslı Tuple tipinin ne amaçla konduğunu gerçekten bilen Python programcısın fazla olduğunu sanmıyorum.
3- Lisp kötülenirken gözden kaçırılan ortaklıklar. Örneğin değişken değerlerinin somut nesnelere referans olması. Bu yüzden assignmentlarda bir veri yapısı kopyalanmak yerine başka bir referansı alnıyor. Bu karmaşık veri yapılarında hatta basit liste işlemlerinde yeni başlayanlara pek çok sürpriz yaratır.
4-Dile özgü geçmişten gelen gariplikler. Örneğin python FAQ'da geçer bir değişkene verdiğiniz default değer her seferinde başta yaratılmak yerine ortak olarak kullanılıyormuş (ya da böyle bir şey). Açıklamasını anlamak bile vakit alıcı ve bunu bilmiyorsanız çok da kolay can yakacak bir şey.
5- Python'un kendine özgülüğü. Python hangi dile benzer? Örneğin Ruby'nin kullanımı Smalltalk'a benziyor ama Perl programcısı da yabancılık çekmeyecektir. Hatta aynı Java diyen insanlar bile gördüm. Sonuçta bunlar öznel yargılar fakat başka dillere aşinalık derecesi Python için bayağı düşük.
6- Gereksiz kullanım zorlukları. Konulması zorunlu self parametresi ve self'in her member erişimde kullanım zorunluluğu. Kolay bir dil için ilginç bir dizayn seçimi.
7- Fonksiyonel programlamayı destekler gibi yapması fakat önünde zorluklar çıkarması. Bir kere map, lambda gibi şeyleri ya doğru düzgün destekleyin ya da tamamen dilden çıkarın ikisinin ortasında durmak yeni başlayanların sadece kafasını karıştırır.
8- Profesyonel yazılımcıların kendileri için gerçekleştirdiği dillerin kolay kullanımlı olmasının imkansızlığı. Bu dilleri geliştiren insanlar belirli birikimleri olan belirli teknikleri bilen eğitimli insanlar. Bu insanlardan yeni başlayanlara dost bir ortam beklemek Python gibi her yeni sürümde özellik eklenen bir dil için saflık olur.

Sonuç olarak evet Python Perl'e ve C'ye göre kolaydır. Ancak bu Python'un kolay olduğu anlamına gelmiyor. Yeterince özelliğe sahip ve geçmişi her dilin karanlık köşeleri ve geçmişten gelen sıkıntıları olur; Python da artık geniş özellikli ve eski bir dil ve bunlar aslında iyi nitelikler (kısacası artık doksanlardaki basit ve sade dil değil). Bana hangi dillerin kolay olduğunu sorarsanız cevabım hala BASIC, Pascal ve (continuation gibi kavramları dışarda bırakmak şartıyla) Scheme olur.

Yazının başlığından pek belli olmuyor ama linki verilen makale sadece Rails'e odaklanıp Ruby dilinin güzelliklerini gözden kaçırmayın diye uyarmak amacıyla yazılmış Ruby'yi tanıtan ve öven bir makale.
Ruby genelde programcılar üzerinde enteresan etkiler yaratıyor. Burada da bir artima.com blogcusu Ruby hakkında konuşup hepsini anlatmazsam kafam patlayacak diye esprili bir şekilde Ruby ile ilgili önemli bulduğu şeyleri listelemiş.

Pardon min + (max - min)/2 olacaktı; bir roket de biz düşürmeyelim ;)

İster istemez (C ile nasıl doğru yazılacağı söylenmediği için sanırım) buraya (C/Lisp karşılaştırması) gelmiş gibi görünüyor konu ancak herkes için faydalı olduğuna katılıyorum. Bu arada, haberde linki verilen blogdaki unsigned'a cast doğru çözüm olmadığı gibi sanıyorum ki portable da değildir.

Hayır çözüm tipi unsigned yapmak değil fakat skoylu doğru tipi söylemiş zaten: size_t

Yapılması gereken iki şey var: 1) size_t isimli standart ve (standart olduğu için haliyle) portable bir tip var. Bu tipin özelliği makinenin hafızasının alabileceği (sanal hafıza dahil) en büyük uzunluğu tutabilmesi. Bu durumda merge sort (sanıyorum ki) sadece hafıza içindeki bir arrayi sıralamak için kullanılacağı için sadece bu tipin seçilmesi gerekirdi.
2) size_t tipinde iki büyük sayının toplanmasının overflow yaratacağı sıradan bir C programcısının zaten bilmesi gereken bir şey olduğundan (max + min)/2 yerine max + (max - min)/2 ifadesinin kullanılması.

Bu algoritma Lisp ile yazılsaydı bu hata olmazdı gibi bir yaklaşım size_t'den bir haber daha doğrusu C bilmeyen insanlar üzerinde belirli bir önyargı oluşturabilir ancak C'yi bilen biri elmayla armutu karşılaştırmanın manasızlığının farkındadır. C'ye middle level language ya da portable assembly yakıştırmaları yapılır bu örnekte de görüldüğü gibi doğruluk payı vardır. Bu durumda C'nin örneğin int tipini Integer sanacak kadar naif insanlar varsa bu dili öğrenmeden önce kullanmamalıdır bu doğrudur. Ayrıca Lisp'in programcıyı bu tip ayrıntılardan kurtararak (yani daha fazla soyutlayarak) işini kolaylaştırdığı da doğrudur ancak C'nin bu yolla çalışmasının bir nedeni vardır. C işletim sistemlerinin yazıldığı bir dildir. Şimdi bir C programcısı çıkıp bana hayır katılmıyorum C ile her şey yazılır derse o da haklıdır. Çünkü GMP isimli bir kütüphane vardır ve bunu kullanarak Lisp'in sağladığını sandığım türden bir soyutlama (bu integer mevzusunda) C ile de sağlanabilir. Hatta ben daha da ileri giderek C++ bana daha güzel soyutlama fırsatları yaratırken gerekli gördüğümde C ile kod yazmama engel olmaz diyerek bir başka karşılaştırma daha yapabilirim ve ben de haklı olurum. Görüldüğü gibi dilleri her fırsatta karşılaştırmaya çalışmak pek anlamlı değildir.

Sonuç olarak: a) elma ile armutu karşılaştırmayalım b) Bu algoritma implementasyonu yanlış yazılmıştır. Kitaptan aynen kopyalayan olmuşsa onlar da yanlış yapmıştır.