''C/C++ Öğrenmeli Miyim Acaba?'' Sorusuna Bir Yanıt

0
GenesisCOX
Az önce Öğrenme Psikolojisi baslikli yaziyi okuyunca; C ve Sistem Programcıları Derneğinin kurucusu ve şu an başkanlık görevini yürüten Kaan Aslan'ın 2002 yılında anet haber grubuna verdiği yanıtlardan birini burada paylasmak gerektiğini düşündüm.
"C ögrenmeli miyim?", "C'ye baslasam mi acaba?" gibi sorulara genel bir yanit verebilmek için bu yaziyi ayri bir thread olarak atiyorum....

Programcilari bir dogru üzerinde bir noktaya yerlestirecek olalim. Bana göre bir uçta "ürüne odaklanmis programcilar" dedigim kesim, diger uçta ise "olaya odaklanmis programcilar" dedigim kesim bulunuyor.

Ürüne odaklanmis programcilar için programlama dili ya da gelistirme ortami tamamen bir araçtir. Ortada bir proje vardir. Ya da kafada bir fikir vardir.

Amaç bu projeyi ya da fikri gelistirerek ürün haline getirmektir. Bunu saglayacak en kolay araç en iyi araçtir. Bu tür programcilar olaylarin nasil gelistigini pek merak etmezler. Merak etseler de bu meraklarini kolaylikla bastirabilirler. Örnegin, onlar için klavyenin nasil çalistiginin, görüntünün ekranda nasil olustugunun, isletim sisteminin programi nasil yüklediginin, dosyalarin diskte nasil tutuldugunun hiç önemli yoktur. Önemli olan ürünün kendisidir. Bu tür programcilar kolay kullanilabilen, hizli ögrenilebilen, gelistirme sürecinde kendilerini sonuna kadar destekleyebilecek, yüz üstü birakmayacak programama dillerini ve araçlarinitercih ederler. Ürün gelistirecek düzeye çabuk gelirler. Iyileri çok güzel projeler çikartir. Kötüleri kullanici ile gelistirici olma arasinda gidip gelirler...

Halbuki olaya odaklanmis programcilar üründen çok olaylarin nasil gelistigi üzerinde kafa yorarlar. Olaylarin hep nasil gerçeklestigini merak ederler.

Bu meraklarini bastiramazlar. Onlar için ürünün gelistirilmesi ikinci plandadir. Olaylarin nasil gerçeklestigini bilmeden bir sey yapmak istemezler. Bu tür programcilar örnegin gelismis araçlari kullanmak istemezler. Yüksek seviyeli kütüphanelerden nefret ederler. Her seyi kendileri yapmak isterler. Her zaman daha ayrintiya inerler. Bazen durum amacindan sapar, obsesif bir hal alir. Standart ezberlemeye kadar gider...

Olaya odaklanmis programcilarlarin sirket patronlariyla ve ürüne odaklanmis programcilarla arasi pek iyi degildir. Patronlarla iyi degildir, çünkü patronlar için amaç ürünün kendisidir. Programcinin olayin ayrintilarini anlama güdüsü yüzünden ürünü gelistirmekte geri kaldigini farkederler. Ürüne odaklanmis programcilarla arasi iyi degildir, çünkü kendilerinin bu kadar ayrintisiyla bildigi konularin hiç bir ayrintiyi bilmeden ve neredeyse daha ise yarar bir biçimde çarçabuk olusturulmasi onlari içten içten sinirlendirmektedir. Neyse ki derinlemesine bilgi gerektiren konular söz konusu oldugunda bu tür programcilar devreye girerek küçük ama önemli kodlarla kendilerini kurtarirlar. Yaptiklarini çok az kisi yapabildiginden saygi da görürler. Olaya odaklanmis programcilar asagi seviyeli dillerle islerini görürler. Bu tür programcilarin is görür noktaya gelmeleri uzun zaman alir. Ürüne odaklanmis programcilarla olaya odaklanmis programcilarin ögrenme ve konuyu ele alma sistematigi ve süreci tamamen farklidir.

Ürüne odaklanmis programci ve olaya odaklanmis programci olmak çogu kez kisinin bilinçli bir seçimiyle olmaz. Bu olusumun kisilikle, geçmis deneyimlerle, tutumlarla ilgisi vardir. Ürüne odaklanmis bir programci zorla olaya odaklandirilamayacagi gibi tersi de söz konusu degildir. Zorlamalar iyi sonuç da vermemektedir.

Ürüne odaklanmis ve olaya odaklamis programcilar iki uç noktayi temsil ediyorlar. Kisiler bu dogru üzerinde çesitli yerlerde olabilirler. Ben iki gruptan da çok kisi tanidim. Örnegin, ürüne odaklanmis bir arkadasima ne zaman "Ya bunu gerçekten merak etmiyor musun?" diye sorsam bana hep söyle yanit verirdi. "Yoo neden merak edeyim ki?" Ya da örnegin, tipik bir olaya odaklanmis programci olan ögrencimiz is yerinde yüksek seviyeli bir araçla çalismak zorunda birakildiginda patronuna "kusura bakmayin bünyem kaldirmiyor" demisti.

Eger siz bu yazidan sonra kendinizi ürüne odaklanmis tarafa daha yakin görüyorsaniz o zaman C/C++ size göre degil! Yok eger kendinizi olaya odaklanmis tarafa yakin buluyorsaniz o zaman C/C++ iste tam size göre. Ama unutmayin ürün ortaya koymak için uzun bir yoldan geçeceksiniz...

Programcilarin çok büyük çogunlugu programcilik yasamlari boyunca en az bir kez C/ C++'i ögrenmeye çalismislardir. Fakat hala iyi C/C++ programcilarinin sayisi çok azdir.

Görüşler

0
darkhunter
0
darkhunter
0
darkhunter
0
darkhunter
vazgeçtim Nuke den kurtulunca yazarım artık :)
0
skoylu
Tamamına katılırım. Ama gözden kaçan, daha doğrusu konunun dışında kaldığı için sanırım bahsedilmeyen bir kaç husus mevcut.

Bugün ürün odaklı çözümler artık uygulamaların customization yetenekleri kapsamında halledilebilir durumdalar. Dahası bu tür bileşenler artık altyapı, kütüphane vs. olmaktan çıkıp basbayağı bir ürün haline geldiler. Ürün bazında pek çok işlevi kodlama gerekmeden yapabilmek imkan dahiline girdi. Bu çerçeveden bakacak olursak, buradaki ürün odaklı geliştiricilerin piyasada tutunabilme imkanları günden güne azalarak yokolup gidecek. Sanırım orta vadede, 5-6 yıl sonra bu tür uygulama geliştirenlere ihtiyaç kalmayacak. Bu tür programcılık şoförlük gibi bir şey olacak. Adam aslen fatura kesen adam olacak, ama bu tür uygulama yapabiliyor olacak. Elbette alacağı ücret, işyerindeki konumu vs. ona göre düşük olacak. Bu tür mesleklere en iyi örnek şoförlük olacaktır. DEvri zamanında şoför olmak ciddi bir meslekmiş. Oysa bugün şoför olmak bir anlam ifade etmiyor. Fakat olaya odaklı şoförler, tır, otobüs vs. şoförleri bu işi gerçekten profesyonel olarak ifşa edebiliyor. Bunun ardındaki gerçek ise, bu şoförlerin işin olayına vakıf olmaları. Kamyonun freni patlayınca yokuş aşağıya, nereye yatıracaklarını bilmeleri. Dağın başında prizdirek burcu dağılınca şanzımanı söküp yenisini takabilmeleri vs.

Bilgisayar dünyasının hızlı ilerlemesi ile beraber, ürüne odaklı programlama da hızla ölüyor. Sistemlerin kabiliyetleri ile birlikte basitlikleri artıyor. Bir süre sonra çok optimize uygulamalar dışında uygulama yazılması gerekmeyecek. Bu noktada da ancak olayı bilen programcılar iş bulabilecek. Bu yüzden programcılığı ciddi anlamda düşünen herkese C/C++ ve kaputun altını öğrenmeyi tavsiye ediyorum.
0
ec18672
Peki urun odakli programcilar hangi dilleri yada aracları kullaniyorlar?Mutlaka bircok dil ve arac vardir ama, en cok kullanilanlar hangileri? dusuk seviyeliler hangileri( 1-2 ornek)?

Kullanilacak proramlarma dilini belirlemek, urun odaklilikla olay odaklilik arasindaki ayirimi yapmaya yeter mi?

Dusuk seviyeli bir dil bilip, programci olay odakli olabilirmi?
0
skoylu
Böyle bir ayrım yapmak, ürün odaklı/olay odaklı diye bir ayrım yapmak çok çok zor.

Bazı durumlarda C/C++ ile bir ürün geliştirmek Java, VB vs. den daha hızlı olabilir. Olası uygulama alanlarını gözönğne alıp, bu iş en verimli olarak nasıl yapılır dediğimizde, taşınabilirlik vs. gibi hususları da eklediğimizde bir noktada çok kullanışlı olabilen bir dilin, bir başka noktada zorlandığını görebiliriz. Bu da herhangi bir dil için atıyorum %10 iş için idealken, diğer %90 için başkaları daha ideal konumuna getiriyor.

Bir diğer husus ise şöyle, artık diller arasında uçurumlar yok. Uçurum daha ziyade C/C++ ile diğerleri arasında var. C/C++ çok güçlü, esnek, hedefe yönelik ve kesin olarak her şeyi destekleyen tek dil. Diğerleri arasında birbirine göre herhangi bir bariz üstünlük söz konusu değil. Fakat, her dilin kendine göre bir yoğurt yiyişi var. Siz LISP'teki bir olaya vaooov mükemmel diyebilirsiniz, ama bu olay farklı bir yaklaşımla Python veya Java içinde gerçekleştirilebiliyor. Sonuçlar, harcanan zaman vs. anlamlı bir fark sunmuyor.

Sonuçta güncel diller içinde C/C++ doğrudan sisteme sızma kabiliyeti sunan tek dil. Bu da alt düzey işlerin nasıl döndüğüne dair bilgi edinmeyi kolaylaştırıyor. Ama mesela gidip X11 op'larını doğrudan servere basmak dönen dolapları çok iyi anlamak için faydalı diye uygulamaları böyle yazmak anlamsız. XLib veya daha iyisi QT, WxWindows vs. kullanır, o hammallıktan kurtulursunuz. Sonuçta belki C#, Java, Python vs. 5 saatte yapacağınız işi C ile 4 saatte yapabilirsiniz. Fakat üst seviyeli dillerin RAD sistemlerine yatkınlığını düşündüğümüzde, sisteme sızmayan bir uygulama gerekiyorsa C/C++ ile uğraşmak daha çok zaman kaybı olabilecektir.

C/C++ nin avantajı insanın analiz ve sentez kabiliyetlerini geliştirmesidir. İyi bir C programcısı herhangi bir zamanda iyi bir C# programcısından daha etkili şekilde C# (veya Java, Python vs.) kodu yazabilir. Çünkü programlama pratiğinde asıl sorun satır yazmak değil, ne yazacağını bilmektir. C kullanıcısına bunu çok iyi öğretir, burnunu sürte sürte..

Kısaca, herhangi bir dil olay veya ürün odaklı kullanılabilir. Ama kaputun altına bakmak için C ve C++ son derece faydalı aletlerdir. Diğerleri bu noktada size hiç yardımcı olmaz. Bu yüzden işe C ile başlamak her zaman diğerlerinden önde başlamak anlamına gelir. C ile 2 yılda iyi bir programcı olabilirsiniz. Ama diğerleri ile bu süre misli ile katlanıverir.
0
bm
Sonuçta güncel diller içinde C/C++ doğrudan sisteme sızma kabiliyeti sunan tek dil. Bu da alt düzey işlerin nasıl döndüğüne dair bilgi edinmeyi kolaylaştırıyor. Ama mesela gidip X11 op'larını doğrudan servere basmak dönen dolapları çok iyi anlamak için faydalı diye uygulamaları böyle yazmak anlamsız.

Gayet tabii, bunlari okurken buranin kiraathane oldugunu unutmamak lazim. Yukarida X11 sunucsu ile ile dogrudan konusmanin yolu sadece C'dir gibi bir mana da var. Xlib'den dahi gecmeden bunu yapan bir de CLX var. Bazi seyler dil ozelliginden cok kutuphane vs.'ye bakiyor. Lispciler oturup ihityac hissettikleri icin CLX'i yazmislar zamaninda, bunu herhangi bir genel amacli dil icin de yapmak mumkun tabii ama xlib ve/veya daha ust seviye kutuphanelere linklemek varken insanlar bunu yapmiyorlar. Makul degil.

Belki soru su: hangi dilin ne oldugunu ne olmadigi konusunda Skoylu bilgisindeki (olumlu anlamda soyluyorum) insanlarin agizlarindan yari-yanlis tarafa cekilebilecek seyler ciktiginda bunu farkedecek teknik olgunluga varmakta C ogrenmek yardimci olur mu? Olur. Ogrenmesi zor bir dil de degil C bence. Kucuk, basit ve eger makineyi biraz anliyorsaniz ne yaptigini az bucuk cikartabileceginiz bir dil. Makineyi o seviyede anlamiyorsaniz C ogrenmek anlamaniza yardimci olur mu, onu tam kestiremiyorum. Bu arada C/C++ niye ayni dil ve tarzmis gibi yapilir onu da bilmiyorum. En iyisi daha uzun yazip konunun ustune altina koyayim bunu, bu CLX/Lisp reklami yazisi belki dogru yer degil uzatmak icin.
0
skoylu
Belki soru su: hangi dilin ne oldugunu ne olmadigi konusunda Skoylu bilgisindeki (olumlu anlamda soyluyorum) insanlarin agizlarindan yari-yanlis tarafa cekilebilecek seyler ciktiginda bunu farkedecek teknik olgunluga varmakta C ogrenmek yardimci olur mu?

Bir örnek vereyim. Python da socket nesneleri send ve sendall olarak iki farklı metoda sahiptir. Bunlar arasındaki farkı anlamak Python ile çalışırken son derece güçtür. blocking I/O soketi nasıl olurda verinin tamamını yollamadan geri dönebilir? Bunu bir gün Python kullanırken de anlarsınız ama C ile bu daha kolay anlaşılır. Çünkü, size bir errno döner, EINTR''i görünce bakacağınız yer C düşünülerek yazılmış olur. Ne send, ne sendall her zaman her derde çare değildir. Ama diğer dillerde uğraşırken bu tür sorunlar genelde beklenmedik sorunlardır. Çünkü yüksek seviyeli olmak bu tür sorunları kullanıcıdan uzak tutmak demektir. Ve çoğu zaman siz böyle bir durumun varlığını bile bilmeden yazar gidersiniz. Fakat bir gün gelip blocking I/O yüzünden sistem şişince veya send'leriniz doğru düzgün çalışmayınca, o zaman işin sadece buzdağının su üstündeki kısmı olduğunu farkederler..
0
bm
Dogru diyorsunuz, ayrildigimiz nokta belki benim bunu C bilgisi olarak degil makinenin nasil calistigi bilgisinin biraz yarim yamalak yapilmis Unix usulu sistem arayuzlerinin anlasilmasi ile evlendirilmesi olarak gormem. EINTR'in 'kaput alti' olmak gibi bir ozelligi yok aslinda, sadece 'halinin altina supurulmus' olmak gibi bir ozelligi var (ilgilenenler icin: 'worse is better' [1] serisi yazilarda pc-losering denen problemle alakali). Aslolan sistemlerin genelde nasil calistigi konusundaki bilgidir bence, burada C sadece Unix'in (bazen posix kiliginda) yayginlasmis olmasindan dolayi on planda gibi gozukuyor 'derin' bir ek ozelligi yok.

Biraz makineyi anlayabilecek bilgisi olanin C'yi hizle ogrenebilecegi bence acik (herhalde hemfikiriz). Makine ile ilgili bilgiyi edinmenin C ogrenerek yapilabilebilecegi konsunda ise suphelerim var, o ok geriye dogru gitmiyor olabilir.

[1] http://www.dreamsongs.com/WorseIsBetter.html
0
canerpro
Bkz: www.csystem.org SSS

Eğer ürüne odaklanmış programcılara yakın görüyorsanız o halde VB, C#, Java programlama dilleri, veritabanı işlemlerine, raporlamalara yönelik araçlar üzerinde çalışmanız daha uygun olabilir. Eğer kendinizi olaya odaklanmış guruba yakın görüyorsanız o halde C/C++ programlama dilleri ve genel olarak sistem programlama etkinlikleri size daha uygundur.
C ve C++ programlama dilleri sistem programlama dilleri olmakla birlikte uygulama geliştirmede de yaygın olarak tercih edilmektedir. Kararınızı şimdiki ve gelecekteki durumunuzu düşünerek gerçekçi bir biçimde vermelisiniz.
0
robertosmix
Programcıları bu şekilde iki sınıfa ayırmak bence çok gereksiz.

Hiç kütüphane kullanmadan herşeyi sil baştan geliştirebilen bir programcı, bazı projeler için kompleks geliştirme ortamları ve yüksek seviyeli kütüphaneleri de kullanabilir.

Arka tarafta neler döndüğünü bilmek tabii ki büyük bir avantajdır, ancak birçok süreci handle eden geliştirme ortamları için bu avantajın kullanılmasına gerek kalmayabilir.

Bence C/C++ herkese göre.
0
FZ
Aslında ayrı bir FM başlığı altında bahsetmek istiyordum ama şimdilik buraya not düşeyim, sonra vakit olursa detaylandırırız.

OOP, XP, vs. ile uğraşan camia içinden Martin Fowler'ın [1] ismini duymamış olan pek yoktur herhalde. Üstadın bir süre önce yazdığı makalelerden biri [2] epey ilgi uyandırdı. Makalenin konusu DSL yani "Domain Specific Language" idi, Türkçe söylemek gerekirse Alana Özgü Diller. Belli bir işi yapmak için o alandaki problemleri ifade etmemizi sağlayacak ve dolayısı ile çözüm geliştirmeyi hızlandıracak küçük diller geliştirmek. Yani dil yönelimli (language oriented) programlama. Yani dil tezgahı (language workbench) modeliyle çalışmak.

Fowler, DSL mevzusunu biraz açıkladıktan sonra DSL tarzı geliştirme araçlarına, dillerine örnek olarak UNIX dünyası geleneğini gösteriyor, lex, yacc, awk gibi başarılı örnekleri veriyordu.

Martin Fowler, hemen ardından, DSL tarzı programlamanın kendini en güçlü şekilde gösterdiği dil olarak Lisp'ten bahsediyor ama bunun üzerinde pek durmuyordu. Ortaya koyduğu problemi çözmek için örnek olarak kullandığı dil C# diliydi.

Greenspun'ın Onuncu Programlama Yasasından [3, 4, 5] haberdar olan ve Common Lisp dünyasının meşhur isimlerinden Rainer Joswig, Fowler'ın makalesini okumuş ancak etkilenmek bir yana, ciddi eleştiriler getirmişti [6]: "Fowler, Lisp'ten bahsetmekle birlikte bir Lisp örneği vermemiş. C# ya da Java ile XML kullanmak zorunda olan geliştiriciler için o kadar çok üzülüyorum ki. Gördüğüm kod örnekleri beni bir türlü etkilemiyor. Kodların okunabilirliği düşük, yazması acı verici uzunlukta, geliştirme şekli etkileşimli değil, bir araya getirmeye çalıştıkları diller birbirlerine uymuyor. (Sourceforge'daki online kaynak kod arşivini bir utanç listesi olarak görebilirsiniz). Ne yazık ki günümüzde çoğu 'araştırmacı' ve yazılım geliştirici tek satır Lisp okumaktan veya anlamaktan aciz".

Joswig, bu eleştirilerinden sonra Fowler'ın ortaya koyduğu problem için basit bir Lisp çözümü sunuyor [6]. Kaynak kodu ve örnek uygulamayı sunmakla kalmıyor aynı zamanda bir Lisp programcısının çalışma şeklini göstermek için bir de video hazırlıyor. İlgili sayfadan çekilebilecek video için başka yansılar da mevcut [7, 8, 9].

Kullandığı Lisp geliştirme ortamı olan LispWorks'ün fena olmadığını belirten Joswig, MacIvory isimli Lisp Machine'de en az iki kat daha hızlı geliştirme yapabileceğini ve daha karmaşık projeler için Lisp Machine [10] türü makinaların 5 kat verimlilik artışı getirebileceğini iddia ediyor.

1- http://en.wikipedia.org/wiki/Martin_Fowler

2- http://martinfowler.com/articles/languageWorkbench.html

3- http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule

4- http://philip.greenspun.com/research/

5- 10. Yasa : "Yeterince karmaşık bir C ya da Fortran programı bünyesinde gelişigüzel, resmen tanımlanmamış, hatalı ve yarım olarak uygulanmış bir Common Lisp barındırır."

6- http://lispm.dyndns.org/news?ID=NEWS-2005-07-08-1

7- http://www.paoloamoroso.it/log/050713.html

8 -http://bc.tech.coop/blog/050711.html

9- http://planet.lisp.org/

10- http://en.wikipedia.org/wiki/Lisp_machine
0
skoylu
10. Yasa : "Yeterince karmaşık bir C ya da Fortran programı bünyesinde gelişigüzel, resmen tanımlanmamış, hatalı ve yarım olarak uygulanmış bir Common Lisp barındırır."

Zaten sorunda burada. Ben bakınca, %50 uygulanmış bir Python, X bakınca C#, Y bakınca Java görüyor. Bir LISP programcısı için her şeyin LISP gibi görünmesi gayet doğal. LISP'çilerin genel yaklaşımı gördüğüm kadarıyla her şeyi çivi olarak görüp LISP'i bir çekic olarak kullanmak.

LISP gayet iyidir. Fakat bu LISP'i bir gümüş mermi yapmaya yetmez. Herşeyin başında,

Ne yazık ki günümüzde çoğu 'araştırmacı' ve yazılım geliştirici tek satır Lisp okumaktan veya anlamaktan aciz

Zaten sorunun taa kendisi bu. LISP okumayı öğrenmek zaten kendi başına ayrı bir problem:

(defmacro defmapping (name mapping &body fields)
`(progn
(defclass ,name ()
,(loop for (nil nil slot) in fields
collect slot))
(defmethod find-mapping-class-name ((mapping (eql ',(intern mapping))))
',name)
(defmethod parse-line-for-class (line (class-name (eql ',name)))
(let ((object (make-instance class-name)))
(loop for (start end slot) in ',fields
do (setf (slot-value object slot)
(subseq line start (1+ end))))
object))))


Bu karışık, zor, şu bu demek değil. Bundaki sorun yazımın çok kriptik olmasında, bir virgül, kesme vs. çok kritik anlamlar ifade ediyor. Bu makineye daha yakın bir anlatım. Oysa insanlar insana daha yakın bir anlatım bekliyor.

Bir LISP kullanıcısı da şuna kriptik diyecektir:

func(a = ((unsigned char*)ptr)[2] ? *((int *)data): 0);

Ama bana LISP acayip korkunç gelirken bu C satırının sadeleştirilmemiş hali bile korkunç gelmiyor. Kısaca, herkes bildiğini daha güzel okuyor.

LISP'çilerin nedendir bilmem böyle bir takıntısı var. LISP mükemmeldir, her şeye yeter, sadece o olsa başka hiç bir şey gerekmez. Ama bu millet neden kafa kırmak adına C ile uğraşır, anlamak istemezler. Yada niye Python/Java gerilerden gelmesine rağmen öne geçmiştir?

Dil, sadece matematik ifade güzelliğiyle kritik arzetmiyor. Yazması acı verici uzunlukta derken, X satır sonra içice 100. paranteze gelince hiç acı hissetmiyor olmalılar. Maalesef, hayatta pek çok uygulama böyle, "Bir fonksiyon iki sayfadan uzunsa bir yanlış vardır", "Tablar o kadar fazla olup ekranın yanından çıkmaya başlamışsa bir sorun vardır", gibi kaideler çok doğru ama günlük hayatta maalesef bunlar bir şekilde gerekiyor. Dahası programlara bakım yapmak gerekiyor vs.

Eğer LISP taa bu kadar üstünse, neden Graham efendi, oturup kendine bir OfficeSuite yazıp, MS Office'in tahtını da kapmadı? 40 Milyon değil 40 Milyarlık adam oluverirdi. İddia, biz LISP kullanarak accayip rekabet avantajı sağladık. Eğer o kadar accayiiip olsaydı, MS'nin en ağır geliştirme ortamı olan C/C++ ile yaptığı işi LISP le yapıp kısa yoldan köşeyi dönemez miydi? Yada MS dangalak, hala herşeyini C/C++ ile yapıyor, LISP'te zaten Redmond'un kapısından girmeyen bir şey, ne bilsinler, oturup C# diye diller icat ediyorlar..

LISP kötü değildir. Her dil ne kadar kötüyse, o kadar kötüdür. Her dil ne kadar iyiyse o kadar iyidir. Elbette burada COBOL'u saymak gerekir mi? Gerekir elbet, şu gün itibarıyla COBOL ile yazılan uygulama sayısı LISP'le yazılandan daha fazladır sanıyorum. Millet LISP'ten uzak durup COBOL gibi bir ucubeye daha çok prim veriyorsa bunun bir sebei hikmeti olmalı.

0
FZ
Bir LISP programcısı için her şeyin LISP gibi görünmesi gayet doğal. LISP'çilerin genel yaklaşımı gördüğüm kadarıyla her şeyi çivi olarak görüp LISP'i bir çekic olarak kullanmak.

Pardon ama bunu kim iddia ediyor? Neden ben ya da burada Lisp ile ilgilenen insanlar böyle bir şey iddia etmiş gibi yapıyorsunuz?


Bu karışık, zor, şu bu demek değil. Bundaki sorun yazımın çok kriptik olmasında, bir virgül, kesme vs. çok kritik anlamlar ifade ediyor. Bu makineye daha yakın bir anlatım. Oysa insanlar insana daha yakın bir anlatım bekliyor.


Şimdi burada el insaf demek durumundayım. Öncelikle Rainer Joswig'in sitesinde düzgün olarak hizalanmış kodu buraya doğrudan kopyala yapıştır yaptığınız için çok çirkin ve karmaşık duruyor, inşallah insanlar gidip bunun otomatik olarak düzgün formatlanmış haline bakarlar (Emacs ile Lisp geliştirenler için bu zaten doğal durum, kodları hiç sizin buraya yapıştırdığınız gibi görmüyorlar). Göz var nizam var, LOOP dediğimiz şey misal, Lisp içinde mini dil (DSL tarzı) gibi bir şey, özel olarak İngilizce sözdizimine uygun geliştirilmiş, eşanlamlı sözcükler, vs. bile içine yerleştirilmiş okumayı kolaylaştırmak için. Bu mudur insandan uzak olan?

Gelelim ', ` ve , ' sembollerine. Kriptik diye diye dediğiniz bu mudur? Lisp en basit sözdizimlerinden birine sahip. C dilindeki işlemci önceliği tablosunu hatırlamak yeterli olacaktır. Paragrafın başındaki üç sembolün kesin, net, iyi tanımlanmış anlamları vardır ve sürekli aynı anlamda kullanılırlar. Böyle bir argüman komik kalıyor ve "C kullanıyorum ama &, *, ?: operatörleri bana çok kriptik geliyor, keşke daha insani olsaydı" demek gibi.


Bir LISP kullanıcısı da şuna kriptik diyecektir:

func(a = ((unsigned char*)ptr)[2] ? *((int *)data): 0);


Eğer C çalıştı ise biraz, iyi bir kaynaktan yola çıkıp birkaç ay C programlama çalıştı ise neden desin? Yukarıdaki satır korkunç bir satır değil ki.

Benzer şekilde Practical Common Lisp gibi Internet'ten ücretsiz, herkese açık bir kaynaktan birkaç hafta uygulamalı olarak Lisp çalışmış biri yukarıda formatını bozarak (pekala tamam, php-nuke ve HTML bunun baş sorumlusu ne yapalım :) aktardığınız kodu anlamakta güçlük çekmez. Anlamayı kolaylaştıran pek çok araç da mevcuttur, hemen REPL ortamına gidip:

CL-USER> (macroexpand-1 '(defmapping service-call "SVCL"
(04 18 customer-name)
(19 23 customer-id)
(24 27 call-type-code)
(28 35 date-of-call-string)))

yazmak sureti ile o makronun açılımının ne olduğunu inceleyebilir mesela (ve atla deve olmadığını görür).


LISP'çilerin nedendir bilmem böyle bir takıntısı var. LISP mükemmeldir, her şeye yeter, sadece o olsa başka hiç bir şey gerekmez.


Neden önce homojen ve birörnek bir "Lispçi" kitlesi var sayıp sonra söz gelimi benim ya da Lisp ile ilgilenen FM okurlarının söylemediği şeyleri söylemiş gibi yazıyorsunuz?

Common Lisp, pek çok iş için kullanılmış olan güçlü bir dil. İlgilenen insanlar da zaman zaman Common Lisp muhabbeti yapıyorlar burada. Dilin gücünü ve onunla nelerin ne kadar verimli şekilde yapılabileceğini keşfetmeye çalışıyorlar. Nasıl ki Python programcıları Python'dan bahsediyorlarsa, nasıl ki Java programcıları her bir şeyin Java ile programlanabileceğini söylüyorlarsa (yanlış anlamalara yol açacak şekilde), Lisp öğrenmeye çalışan insanlar da bu dil ile neler yapabileceklerini araştırıyorlar (ama her şeyi Lisp ile hallettiklerini söylemiyorlar, en fazla duruma göre bir DSL geliştirir, Lisp içinden onu kullanırız, güzel ve verimli olur, daha az yoruluruz diyorlar).


Ama bu millet neden kafa kırmak adına C ile uğraşır, anlamak istemezler.


"C kullanmayın" gibi bir lafı "mutlak" geçerli olarak kim iddia etti? Bir şeyleri anlamak istemeyen kim?


Yada niye Python/Java gerilerden gelmesine rağmen öne geçmiştir?


Kim insanlara Python ya da Java kullanmayın diyor ki? Bu bir. İkincisi çoğunluğun kullandığı mübahsa benzer argümanla gezegendeki en iyi işletim sistemi MS Windows işletim sistemi ailesi, en çok o kullanılıyor. Var mı böyle bir şey? Bu nasıl bir argümandır?


Dil, sadece matematik ifade güzelliğiyle kritik arzetmiyor.


Bu ne demek şimdi? Böyle bir şeyi iddia eden mi oldu? Matematik nereden çıktı ki? Biz burada DSL yani Domain Specific Language konusunda dair bir makaleden ve alternatif çözümlerden bahsediyorduk.


Yazması acı verici uzunlukta derken, X satır sonra içice 100. paranteze gelince hiç acı hissetmiyor olmalılar.


İç içe 100 parantez? Fantastik bir sayı! Açıkçası bırakın 100'ü ona yakın sayıda parantezi görmedim iç içe. Öte yandan modern bir Lisp geliştirme ortamı kullanıyorsanız (yani 25 yıldır filan) o zaman parantezler dert etmeniz gereken en son şey.


Eğer LISP taa bu kadar üstünse, neden Graham efendi, oturup kendine bir OfficeSuite yazıp, MS Office'in tahtını da kapmadı? 40 Milyon değil 40 Milyarlık adam oluverirdi. İddia, biz LISP kullanarak accayip rekabet avantajı sağladık.


Bu da enteresan ve alakasız bir argüman olmuş. Adam küçücük bir ekiple gitti, bu Internet'te ticaret mevzuları yeni yeni yeşerirken başarılı bir e-ticaret, e-dükkan yazılımı geliştirdi ve bunu da pazarladı. Bir insan kıt kaynaklarla kazanabileceğini düşündüğü bakir bir ticari-teknoloji alanında iş güç yapıp başarılı olmuşsa, sonra gelip "hehe, madem o kadar süper programcısın haydi gidip Microsoft ile en güçlü olduğu ofis süiti alanında rekabet et, baak gördün müüü" demek nasıl bir tartışma yöntemi anlamadım ben.


Yada MS dangalak, hala herşeyini C/C++ ile yapıyor, LISP'te zaten Redmond'un kapısından girmeyen bir şey, ne bilsinler, oturup C# diye diller icat ediyorlar..


Microsoft her zaman dangalak değil. Lisp çoktan Redmond'dan içeri girdi, içeri girmekle kalmadı adamların teknoloji geliştirmelerine de yardımcı oldu. Misal oturup .NET için GC sistemini Common Lisp ile yazdılar (sistem iyice geliştirilip test edildikten sonra da kodu otomatik olarak C'ye dönüştürüp bir stajyere biraz düzenlettiriyor sonra da süper GC var .NET'te mükemmeliz biz diye reklam yapıyor, tabii Lisp'ten bahsedip ortalığı bulandırmanın, kafaları karıştırmanın manası yok, akıllıca programlama yapmak başka bir şey, akıllıca pazarlama yapmak bambaşka bir şey):

http://www.fazlamesai.net/modules.php?name=News&file=article&sid=2716

Öte yandan, yani C# dilinin ne kadar önemli bir pazarlama ve piyasa kapma aracı olduğunu unutmuş gibisiniz. MS, hiç saklamadan J2EE programcılarını hedefliyor, "bakın artık biz de Enterprise level uygulamalar için sağlam araçlar, diller sunuyoruz" demek istiyor Java'cılara ve bunun için de VB tarzı bir dil ile adamların karşısına çıkacak hali yok ya. Tabii ki Java benzeri dil ile çıkacak.


LISP kötü değildir. Her dil ne kadar kötüyse, o kadar kötüdür. Her dil ne kadar iyiyse o kadar iyidir.


Dillerin birbirlerine Turing-denk olduğu argümanının konumuzla ilgisi olduğunu düşünmüyorum. Bu teorik bir mesele. Pratikte farklı kriterlere göre seçim yapıyoruz.


Elbette burada COBOL'u saymak gerekir mi? Gerekir elbet, şu gün itibarıyla COBOL ile yazılan uygulama sayısı LISP'le yazılandan daha fazladır sanıyorum. Millet LISP'ten uzak durup COBOL gibi bir ucubeye daha çok prim veriyorsa bunun bir sebei hikmeti olmalı.


Tartışmada bir COBOL eksikti kafaları karıştırmak için, şimdi tamama erdik :-) Tekrar ve tekrar el insaf demek durumundayım, bu nasıl bir düşünme şekli, "Millet Lisp'ten uzak durup... COBOL..." sanki böyle mütemadiyen programcılar bir araya geliyor ve "hmm, bu projeyi COBOL ile mi yapsak yoksa Lisp ile mi yapsak, evet evet en iyisi COBOL ile yapalım, daha iyi öyle" diyor falan. Yok ki böyle bir şey. Bambaşka ortamlarda çıkmış, bambaşka hedeflerle, bambaşka camialarla ilerlemiş iki farklı dil.

Lisp'in nerelerde kullanıldığını merak edenler için kaynaklar mevcut:

http://www.lispworks.com/products/myths_and_legends.html

http://www.franz.com/success/

Son olarak şunu demek istiyorum: Korkmayın, biz burada Common Lisp ile ilgili makale yayınlıyoruz diye insanlar C öğrenmekten ya da C++ sözdizimi ve semantiği ile saç dökmekten imtina etmezler, çalışmaya devam ederler. Öte yandan burada isteyen Java, isteyen Python, isteyen C# makalesi yayınlar, şöyle güzel bir mevzu var, bakın işimi böyle kolaylaştırdı der, seve seve yayınlarız, sansür uygulamıyoruz ki diğer teknolojilere, bilakis ne kadar çok şey bilirsek vizyonumuz o kadar geniş olur, bilgisayar dünyasının hep tekrarlanan bazı şeylerden ibaret olmadığını görmüş oluruz diyoruz.
0
bm
Common Lisp, pek çok iş için kullanılmış olan güçlü bir dil. İlgilenen insanlar da zaman zaman Common Lisp muhabbeti yapıyorlar burada. Dilin gücünü ve onunla nelerin ne kadar verimli şekilde yapılabileceğini keşfetmeye çalışıyorlar.

Yok tam degil oyle. En azindan benim gayem CL'i arac olarak kullanip buradaki insanlara biraz Win/Linux, PCler, C/C++/Java/C# eksenleri disinda kalan birseyler oldugunu (ve bunlarin ilginc ve/veya harika seyler olabilecegini) hissettirmek. Lisp makinesi filmlerini filan da onun icin reklam ediyorum (ve anladigim kadariyla ise yaradiklari da oluyor). Bu gaye dogrudur yanlistir o ayri, ama boyle bir gaye yoktur sadece aramizda CL konusuyoruz diyemeyecegim.

Belki bu cabanin tepki cekmesinin sebebi boyle bir amac oldugunun hissedilmesi? Yani 'suna bakarsaniz ufkunuz genisleyebilir' dedigimizde otomatik olarak "bi-haberseniz dar ufuklusunuz" demis gibi de oluyoruz?
0
skoylu
FZ, sözüm sana değil zaten. Birisi DSL iyi olur diyor, ötekisi, ne gerek var DSL'e LISP'imiz var diyor. Konu bu açıkca.. DSL olayına bir yere kadar bende taraftarım. Ama DSL, oha tamam işte Python, tüm dertlerin üzerine sifonu çekin diyemem.

Benim derdim LISP ile değil, ama neden acaba LISP her derde deva gibi gösterilmeye çalışılır, mucizevi bir şeymiş gibi sunulur bir türlü anlayamam. LISP benim gözümde diğer tüm diller kadar değerlidir, ama hiç biri gözümde parlayan yıldız filan değildir (COBOL müstesna, o sadece diskte yer kaybı anlamına gelir, uzak durulması gerekir bence..).

Benim LISP kullananlardan öğrenmek istediğim, LISP madem bu kadar uçan bir dil, neden millet kullanmıyor? Bir sebebi olmalı? Millet kullanmıyor derken, çoğunluktan bahsediyorum elbette.

Bir framework vs. oluşturmak için LISP gibi bir ajan kullanmak gayet bilienen bir yaklaşımdır. 3 hafta önce filan bir hafta sonunda 2 bin satırın üzerinde C kodu yazmışım. Ne yapmışım, 100 satır kadar Python yazmış, C kodlarını ona yaptırmışım. Bu Python yerine makulen LISP de olabilirdi.

Bu arada, LISP öğrenmeye değer bir dildir, her zaman portföyde bulunması son derece faydalı olur.. Bunu belirtmeden geçmek istemem.

İyi ile kötü arasında bir değerlendirme değil benim derdim. LISP şu şu şu özellikler sunar, böyle faydalar sağlar, diğeri bu bu bu özellikler sunar, şöyle faydalar sağlar. Genel toplamda çok fazla bir şey farketmez.

Ama bakalım:


C# ya da Java ile XML kullanmak zorunda olan geliştiriciler için o kadar çok üzülüyorum ki. Gördüğüm kod örnekleri beni bir türlü etkilemiyor. Kodların okunabilirliği düşük, yazması acı verici uzunlukta, geliştirme şekli etkileşimli değil, bir araya getirmeye çalıştıkları diller birbirlerine uymuyor. (Sourceforge'daki online kaynak kod arşivini bir utanç listesi olarak görebilirsiniz). Ne yazık ki günümüzde çoğu 'araştırmacı' ve yazılım geliştirici tek satır Lisp okumaktan veya anlamaktan aciz


Şimdi burada LISP kullanmayanlara "Yazık zavallılara" deniyor açıkça. Yani o kadar ki, makalenin tümünü okuduğunuzda da "LISP varken diğerleri abesle iştigaldir" gibi bir anlam çıkıyor. Bunada sessiz kalmak zor geliyor, çünkü gördüğüm kadarıyla LISP ile diğer üst seviyeli diller arasında aman aman diyecek bariz bir fark yok..

Bunu söylemek neden saldırı gibi anlaşılıyor anlamış değilim.
0
bm
Nereden geldi o alinti bilemiyorum ama algilamaniz dogru bence. C#'i MS'in Java'yi isedigi gibi ceviremedigi icin cikarttigini kabul edersek ayni tarza Java'yi tasarlayan guruptan birinin de sahip oldugunu belirteyim. Buraya baska sebeple yazmistim [www.fazlamesai.net]oradan alinti yapiyorum:

Java'dan bahsediyorsaniz, bunu hazirlayanlar ortalama bir C/C++ programcisini en acisiz sekilde (yani korkutmadan) biraz daha modern bir dile nasil gecirip nasil dilimizi populer hale getiririz diye dusunduklerini acik veya kapali soyluyorlar. Steele bir de

And you’re right: we were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren’t you happy?[1]

Filan gibi ifadelerle bir kalabaligi oraya buraya cekistirdiklerini acikca soyluyor. Piyasa sartlari, ve kutuphane vs. sebeplerden dolayi bu tip dilleri tercih etmek gayet makul olsa da, 'nicin oraya buraya goturulenlerden oluyorum da goturenlerden olmuyorum' demek de insanin aklina geliyordur herhalde? Sadece akademik yaklasim degil insanlari alternatifleri ogrenmeye iten demek istiyorum. Yoksa yazdiklariniz calisan bir programicinin is hayatina bakisi acisindan kesinlikle kusur bulunacak seyler degil.
[1]http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg04045.html


Ben anladim simdi sizin neden rahatsiz oldugunuzu. "Smug Lisp Weenie" sayfasi da bundan bahseder: http://c2.com/cgi/wiki?SmugLispWeenie

Dogru diyorsunuz, O tarz ayni tarif ettiginiz gibi, niye oyle oldugu konusunda da fikirler bulacaksiniz orada.

XML/C# baglaminda ise sexp ve lisp bilen birinin 'yani simdi bu dil ve XML usulu 2005 senesinde marifet olarak mi goruluyor? Yazik' demesinin belki bunlarin cok tabii geldigi ve devamli kullanildigi bir arkaplana sahip olmasinin rolu vardir? XML icin McCarthy diyor ki mesela:
This paper, written in 1975, published in 1982 [McC82] in the proceedings of a conference whose title was in German, seems to be worth reviving in 1998, because some of its ideas are new in 1998 (I'm told) and are relevant to the new interest in electronic commerce.

tamami: http://www-formal.stanford.edu/jmc/cbcl2/cbcl2.html
0
FZ

Birisi DSL iyi olur diyor, ötekisi, ne gerek var DSL'e LISP'imiz var diyor. Konu bu açıkca.. DSL olayına bir yere kadar bende taraftarım. Ama DSL, oha tamam işte Python, tüm dertlerin üzerine sifonu çekin diyemem.


Birisi DSL iyi olur bakın C# ve XML, bakın Java ve XML örnekleri, vs. diyor. Beriki, Common Lisp ile DSL geliştirmek C# ve Java'ya kıyasla çok daha kolaydır, Lisp geleneğinde ve kültüründe zaten DSL, dil yönelimli, yani yeni dil geliştirerek programlama yaygındır diyor, gelin Common Lisp ile yapalım bakalım nasıl olacak diyor, bir de üşenmiyor çalışma şeklini gösteren bir video koyuyor.


Benim derdim LISP ile değil, ama neden acaba LISP her derde deva gibi gösterilmeye çalışılır, mucizevi bir şeymiş gibi sunulur bir türlü anlayamam.


Mucizeden bahseden kim, somut bir DSL örneği üzerinden, bakın o mevzu Lisp'te de şu şekilde yapılıyor diye örnek verilmiş.


LISP benim gözümde diğer tüm diller kadar değerlidir, ama hiç biri gözümde parlayan yıldız filan değildir


Lisp, bazı programcıların gözünde parlayan yıldız. Herkesin kendince sebepleri var. Burada anlatmışlar:

http://lisp.tech.coop/RtL%20Highlight%20Film

http://lisp.tech.coop/The%20Road%20to%20Lisp%20Survey


Şimdi burada LISP kullanmayanlara "Yazık zavallılara" deniyor açıkça. Yani o kadar ki, makalenin tümünü okuduğunuzda da "LISP varken diğerleri abesle iştigaldir" gibi bir anlam çıkıyor.


Tam olarak öyle denmiyor. C# ve Java ile ilgili eleştiriler getirilip insanların Lisp'e dair bilgi sahibi olmamaları ve o yüzden bazı şeyleri kaçırmalarından ötürü duyulan üzüntü dile getiriliyor.
0
skoylu
Ama, sanki XML olmadan Java olmaz, C#olmaz gibi bir esinti var. Benim şahsi görüşüm, XML'in bir balondan ibaret olduğudur. Sağlam olup ömürboyu patlamayacak olması onun balon olduğu gerçeğini değiştirmez.

Yani, Java veya C# kullananların XML kullanmaya vs. bulaşıp kendilerine zulm ediyor olması onların sorunu. Bu yüzden gidip Java veya C# yada Python'u zavallı görmek vicdana sığıyor mu?

Herkesin bildiği dili yıldız olarak görmesi gayet doğal. Ama tonla dille uğraşmış biri olarak diyebilirim ki, tek yıldız olsa olsa C ve C++ dır, amma velakin elinize alırsınız, yakar, pişirir. Bunun dışında kalan diller aynı kulvarda farklı performans gösterseler bile başka kulvarlarda öne çıkarlar, terazide hiçbiri diğerine bariz bir üstünlük sağlamaz.

LISP iyidir, ama Python'da iyidir. Benim itirazım, LISP "en" iyidir yaklaşımı. En iyi ancak C olabilir. Ama o da vahşi at gibidir ve böylece en iyi olma sıfatını kaybeder. Bakılır uygulamaya, performans vs.gereklerine oturulur en uygun dil hangisi ile onunla yazılır. Eğer uzmanlık LISP üzerineyse, siz onun çevresini daha efektif kullanmayı biliyorsanız, LISP çoğu zaman sizin için en uygun dil olacaktır. Ama Python içinde, Java içinde (Ruby, Haskel vs. aklınıza geleni koyun) aynı şey söylenebilir. İşin diğer yanında temel programcılık yeteneğine sahip insanların Python, LISP veya Java üzerinde uzmanlık sağlaması için geçecek süre, harcanacak emek vs. pek farklı değildir. Kısacası diller birbirinden üstün değiller. Ama LISP'çiler nedense aksini ima ediyor her tarafta. Bu garibime gidiyor. Nedir LISP'i diğerlerinden üstün yapan? Hiç bir şey göremiyorum da... Bu linkler ne olacak? Adam 1995'te filan C kullanırken LISP ile uğraşmaya başlamış.. İyi ama bizim sektörde 10 yıl, diğer sektörlerin 100 yılı gibi bir şey. Ben 10 yıl önce bunları söylemiyordum. Biraz bugüne bakalım. Kim mi demiş, rasgele karşıma çıkanlar:

Constantine Vetoshev 1999
Kenny Tilton, 1995 or 96
Scott McIntire, 96... 2000
Peter Van Eynde, 96.. 2000, Fortran ve AWK'tan LISP'e..

Liste böyle uzayıp gidiyor. İşin ilginç yanı sanırım diğer diller için böyle "Bizim dilimiz en babasıdır" siteleri yok. Evet, kullandıkları dile şöyle süper filan diyen, fan siteleri vs., tonla mevcut ama hiçbiri işi LISP'çilerin seviyesine getiremiyor. Nedir bu LISP'in kerameti kardeşim, anlamış değilim. Gene aynı sitelerde karşılaştığım makro mucizesi filan gibi şeylerde bana bir anlam ifade etmiyor, çünkü hemen her dilde aynı sonuca aynı şekilde çabuk ulaşmanızı sağlayacak tonla şey var.

Yanlış olan LISP'in gücü değil. Yanlış olan, LISP'in gücünün benzersiz gibi gösterilmek istenmesi. Burada FZ'nin veya diğer arkadaşları özel olarak kastetmiyorum. Bu yaklaşım nerdeyse tüm LISP kullananlarda var. Peki nedir diyorum, doğru düzgün bir cevap yok.

Konu uzmanlaşma konusu. Çok iyi LISP bilin, çok iyi Python bilin, çok iyi Java bilin vs.. Bunun arasında bir fark yok. LISP, Python vs. vs. diyoruz, Web sayfasında client side kodlama yapacaksak bunların hepsi hikaye kalıyor, Javascript gerekiyor mesela. Onu da bilin. Hiç biri diğerinden daha iyi değil. Ama bunların hangisi olursa olsun yaptığınız işin niteliği sizin programlama disiplinine sadakatinize, analiz yeteneğinize, sentez ve uzak görüş kabiliyetinize bağlı. Bu diller programlama sürecinin %10'unu kapsayan şeyler. Geri kalan %90 işte o disiplin içinde kalıyor. Bu yüzden de en iyi dille en kötü dil arasında olası nitelik farkı zaten %10'u aşamıyor. Ama siz, JavaScript ile server yazacağım yada LISP ile ofis süiti yazacağım diyorsanız baştan kaybetmiş olursunuz.

Ah bir LISP makinesi olsaydı.. Eğer alacak müşteri olsaydı, yapacak bir INTEL, AMD vs. bulunurdu. Platform olarak geliştirilen Java bile bu noktada bir şey yapamadı. LISP2in pek şansı olduğunu sanmıyorum. C# için IL kodunu doğrudan çalıştıran makine yapılır sanıyorum, ama LISP için LISP makinesi üreten pek olmaz kanımca..


0
bm
Nedir bu LISP'in kerameti kardeşim, anlamış değilim.

Belki ogrendiginiz zaman anlarsiniz? Yarim asra yakin bir birikim var o dil ve camiada, belki ogrenmenin faydasi MS'in veya Sun'in ortalama programaciyi urkutmeden ittirdigi dilleri ogrenmekten fazla olacaktir?

Bu yaklaşım nerdeyse tüm LISP kullananlarda var. Peki nedir diyorum, doğru düzgün bir cevap yok.

Obur tarafta bunu defmacro icin sordugunuzda aydinlatici ve yanlis anlamanizi duzeltici cevaplar verildi diye hatirliyorum? Mesela:
http://www.fazlamesai.org/forum/viewtopic.php?t=1382&postdays=0&postorder=asc&start=30

Orada anlasilmayan birsey olduysa tekrar sorabilirdiniz. Yahut tamam bu kadarini anladim, su sebepten dolayi hosuma gitmedi diyebilirdiniz. Hala da diyebilirsiniz. Yahut hic buradaki minicik kalabaliga bagimli kalmayin, dogrudan comp.lang.lisp'e sorun. Maksat ogrenmekse, yardimci insan ve kaynak bulmak zor degil.

Lispcilerin o link verdigi sayfada anlatildigi gibi insanlara batan bir tarzi oldugu dogru, ama genelde biraz daha yasca buyuk, belki biraz daha okumus, belki biraz daha fazla pazarlama (ticari veya degil) yalani filan isitmis, daha fazla sistem gormus (ve belki bazen ittirilen 'en bir yeni' sistemlerin alinmasina engel olmus) insanlar oldugumuz icin biraz farkli davraniyor da olabiliriz. Dogru anladiysam burada kimsenin bu tarzi gosterdigini de ima etmiyorsunuz zaten, yabanci sitelerde ve tercumelerde gordugunuz hava caninizi sIkmis. Sorunuzun tek cumlelik cevabi olmadigini dusunuyorum, yine bir yabanciya atifta bulunayim:
LISP' öğrenmek başka bir sebepten dolayı önemlidir - sonunda anladığınız zaman elde edeceğiniz aydınlanma deneyiminden dolayı. Bu deneyim, bir daha hiç LISP kullanmasanız dahi, hayatınızın kalan kısmında çok daha iyi bir programcı olmanızı sağlayacaktır.


Tamami: http://www.belgeler.org/howto/hacker-howto/hacker-howto-basics.html
0
skoylu
:)

LISP bilmediğimi nerden çıkardığınızı anlamış değilim, ama, o topikte de elle tutulur bir şey görünmüyor. Ama çarpıcı bir cümle:

"Bu benim için çığır açıcı kitap. Artık başkalarının Lisp kodunu okuyabiliyor ve anlayabiliyorum. Diğer dillerde 200 satır tutabilen 'Desing Pattern'leri (Tasarım Kalıpları) Lisp'te 3 satırlık deyimlere dönüşebiliyor. Sözdizimsel soyutlama ile bunların bir kısmı da tek satıra indirgenebiliyor."

O diğer başka diller nelerdir, onlarda 200 satır tutabilen bu iş nedir, bu nasıl 3 veya tek satıra dönebilir? İşte buna bir örnek istiyorum. Benim kıt LISP tecrübem böyle bir öngörüde bulunmama yetmiyor. Örnekler verildi orada, bir tür kütüphane çağrısı ile bir OpenGL vertex çağrısı. Bunlarda da öyle herhangi bir vay anasını diyecek bir şey göremedim. Ben mi körüm, bakmasını mı bilmiyorum, anlamış değilim. Bir zahmet bunu bir gösterseniz de hepimiz mutlu olsak?

Bir şey yazıyorduk. LISP'çi arkadaşımız bir aya yakın uğraştı. X satır kod elde etti. Biz daha fonksiyonel olanını bir-iki gün içinde Pythonla yazdık. Üstelik bizim kodumuz satır sayısı olarak çok daha kısa olmuştu. Bu şimdi LISP Python'dan daha şeydir diye mi gösterir?

Hayır, ben 20+ yıldır kod yazıyorum, nereye ne konmasını gerektiğini kestirebiliyorum. Altta neler olduğunu, hangini kullanırsam daha kolay yoldan neticeye ulaşacağımı biliyorum. Diğer arkadaş matematikçi. O belki benim yarım kadar tecrübe sahibi olsa benden daha çabuk vede LISP kullanarak yazabilirdi. Yani olay LISP, Python vs. olayı değil, olay elinizdeki dili nasıl kullandığınız olayı. Konu bundan ibaret. Ve ben o kitapları okuyup baktığımda, bir yerde bu güzel, hoş bir olay derken diğer yerde, burada atıyorum Java olsaydı, C olsaydı, daha güzel, kolay olurdu diyorum. Aynı şey C ile yazarkende, Java ile yazarken de geçerli elbette..
0
FZ
Enteresan bir örnek vermişsiniz, sevindim ve detaylarını öğrenebilirsem daha da sevinirim:


Bir şey yazıyorduk. LISP'çi arkadaşımız bir aya yakın uğraştı. X satır kod elde etti. Biz daha fonksiyonel olanını bir-iki gün içinde Pythonla yazdık. Üstelik bizim kodumuz satır sayısı olarak çok daha kısa olmuştu. Bu şimdi LISP Python'dan daha şeydir diye mi gösterir?


Demişsiniz. Şu aşamada sadece şunu gösterir: Gayet güzel, ortada somut bir şey var demek ki. Şimdi iki seçenek var, süper gizli bir proje yaptınız, devlet sırrı dolayısı ile daha fazla detay veremezsiniz, o zaman bu dediklerinizi tartışmanın çok bir anlamı olmaz. İkinci seçenek, tartışılmasında sakınca olmayan bir şey, o zaman hep birlikte masaya yatıralım. Kendi adıma, meraklı bir insanım ve fazla bilgi göz çıkarmaz diyorum. Ne olduğunu bir öğrenelim ve gerekirse comp.lang.lisp'teki insanlara da bir soralım.

1- Ne yazıyordunuz?

2- Bahsettiğiniz Lispçi arkadaş ne tür bir Lisp geliştirme ortamı kullanıyordu?

3- Bahsettiğiniz Lispçi arkadaş Lisp ile daha önce neler yapmıştı? Hangi kaynaklardan ne kadar Lisp çalışmış? (Bunu soruyorum çünkü daha önceki mesajımda belirttiğim gibi, Common Lisp öğrenmesi vakit alan, büyük bir dil. Yüksek seviyeli demek misal bir Python kadar kolay öğreniliyor demek değil.)

4- O arkadaşın matematikçi olduğunu vurgulamışsınız, yine merak ediyor insan, söz konusu proje ne projesi idi. Matematik ile ilintisi ne idi?

5- Python ile birkaç günde yazdık hem daha az satır tuttu demişsiniz. Gayet güzel, bu durumda tekrar o söz konusu arkadaşın yaptığı işi biraz deşelim, acaba bir kütüphane sıkıntısı mı vardı? Bazı kütüphaneler vardı da kendisi mi bundan habersizdi? Yoksa hakikaten yaptığı iş için bazı şeyleri sıfırdan yazmaya mecbur mu kaldı?

Sorular çoğaltılabilir ama bir post-mortem yani vaka sonrası çalışma yapılacaksa yukarıdaki soruların daha fazlasının cevaplanması doğru dürüst fikir sahibi olmamızı sağlayacaktır. Öteki türlü biri de gider yahu ne uğraşıyorsunuz, sizin mevzunuzu ben Common Lisp ile 5 kat kısa sürede hallettim, 3 kat kısa oldu der ama detay olmadan bu çok bir şey ifade etmez. Madem elinizde detaylarını aktarabileceğiniz, bizzat uğraşmış olduğunuz ve uğraşanların da yaptıklarını gördüğünüz bir proje var masaya yatıralım bakalım nerede ne olmuş, ne tür sıkıntılar gündeme gelmiş. Bu şekilde çok daha sağlıklı fikir edinmiş olmaz mıyız?
0
skoylu
Aslında sorunun cevabını ben kendim verdim. Bu olay LISP vs. Python mevzusu değil. Asıl önemli olan o arkadaş ile bizim aramızdaki sistem hakimiyeti, tecrübesi mevzusu idi.

Problemi kabaca şöyle özetleyebilirim. Bir script çalışacak, diyelim şöyle bir script:

add()
delete()
updatedb()
updatefs()
extractfiles()

gibi belli sayıda fonksiyon olacak. Şimdi bu script bir yerlerden gelecek. Bizde bir dizin hiyerarşisi hazırlayacağız.

/a/b/c/d/e/script

şeklinde. Burada diyelim ki c'deki scriptte bulunan updatefs yöntemi script içinde kullanılacak. Script kendisi bir updatefs() tanımlamazsa, bir üsttekindeki dizindeki scriptten alacak. o da kendi parentinden vs. böyle gidecek. Bunlar baya baya scriptler.

Biz bunu inherit eden metotları herhangi bir dille olabilecek vs. şekilde hazırlamıştık. Eğer bulabilirsem yollamak isterim o kodları.

Ama dediğim gibi sorun LISP'ten daha fazlasını yaptık sorunu değil. Belki benden daha iyi bir C programcısı bizden daha çabuk bunu C ile yapabilirdi (belki dedik, yanlış anlaşılmasın)..

Önemli olan dil değil, Dili nasıl kullandığınız. Benim Türkçeyi kullandığım gibi kullanırsanız derdinizi anlatmanız zor olur bilgisayara. Malum, anlatamama kıtlığım iyi bilinir, 4 saatlik seminerde uyuturum milleti..

Diğer yandan devri zamanında LISP makineleri üretiliyor oluş olması, bunların da mazi olması aslında düşünülmesi gereken bir husus. Gerçi düşünecek bir şey yok, maliyetini kurtaracak olsa bir yapan olur. Belki de vardır, belli mi olur..

0
bm

Problemi kabaca şöyle özetleyebilirim. Bir script çalışacak, diyelim şöyle bir script:

add()
delete()
updatedb()
updatefs()
extractfiles()

gibi belli sayıda fonksiyon olacak. Şimdi bu script bir yerlerden gelecek. Bizde bir dizin hiyerarşisi hazırlayacağız.

/a/b/c/d/e/script

şeklinde. Burada diyelim ki c'deki scriptte bulunan updatefs yöntemi script içinde kullanılacak. Script kendisi bir updatefs() tanımlamazsa, bir üsttekindeki dizindeki scriptten alacak. o da kendi parentinden vs. böyle gidecek. Bunlar baya baya scriptler.


Aslinda bu dizin/script olarak degil de generic-function ve CLOS default dispatch mekanizmasina cuk oturuyor. Yani b a'nin sublcassiyla c de b nin subclassiysa update generic functionini c cinsi birsey ile cagirdiginizda sirasiyla c icin yoksa b icin onun icin de yoksa a icin olan fonksyonlar araniyor. Bu fonksyonlar class'lere ait olmadiklarindan sizin dosya sistemi orneginde oldugu gibi bagimsiz (ve tabii runtime'da dahi degisebilecek) sekilde yaratilabiliyorlar.

Belki son donemde alisilan dillerden farki foksyonlarin kendi baslarina tanimlanabilmeleri ve sizin dizin orneginde hiyerarsiyi agac olmaktan cikartacak linkler olsa dahi CLOS'un fonksyon bulma mekanizmasinin (generic dispatch) tanimli olmaya devam etmesi.

Herneyse, hesap acisindan cuk oturdugu icin belki heveslileri biraz 'nasil yapardim' diye dusunmeye itecek bir iki sey soylemek istedim. Yoksa o problemle direkt alakasi yok.
0
bm
LISP bilmediğimi nerden çıkardığınızı anlamış değilim, ama, o topikte de elle tutulur bir şey görünmüyor.

Semaphore ornegi vermissiniz ben de boyle P/V esleme, yahut begin/end esleme gibi seyleri dile nasil yedirebileceginizi gosteren minicik bir ornege isaret etmisim. [1] Ona gelen cevabiniz bana 'lisp okuyamiyor' dedirtmisti. Biliyor idiyseniz, iyi saklamissiniz (ayrica o zaman rica edeyim beni yalniz birakmayin heveslilere siz de vaktiniz varsa yardim edin lutfen. Yeteri kadar bilen ve tUrkce yazabilen insan yok oralarda herkese yetisecek).

O alinti oradan mi? Ben soylememisimdir ama pattern'dan ekmek yiyen adamlarin bir kismi C++'in eksikliklerinden dolayi pattern uretiyorlar benim de _hissettigim_ kadariyla. Ben OOP teoristi (veya devamli kullanicisi) degilim ama 'ne var bunda' dedigim cok olmustur. Bu konuda bir google linki vereyim meraklilari kendileri takip etsin, benim anlatacak kadar bilgim yok:

http://www.google.com/search?&q=design+patterns+clos+lisp

[1] Gittim baktim, state machine ve semaphore demissiniz, ben de state machine yazmaya usenmisim, semaphore'a oturan cok basit bir ornege link vermisim. Gittim state machine macrosu da buldum size simdi:
http://groups-beta.google.com/group/comp.lang.lisp/browse_frm/thread/82b3fc9cd9e0a0fa/0c13db5451f12451
0
FZ
Google'ın döndürdüğü sonuçlardan (bir dakika yahu Google sonuç döndürüyorsa, o zaman Google'a bir fonksiyon diyebilir miyiz? Dünyanın en büyük fonksiyonu? (defun google (input1 &key so-many-keywords &rest) body* ...) ) :) () (()) ((()))........

Neyse tamam kendime geldim. Ne diyordum, hah şu sayfalar benim çok ilgimi çekti:

Şu anda Google'da çalışan, YZ ve Lisp üstadı Norvig'in pattern ve Lisp mevzusuna dair eğlenceli ve aydınlatıcı bir sunumu (GoF kitabını okumuş olanlara tavsiye edilir):

http://norvig.com/design-patterns/

Visitor ismi ile nam salmış pattern ve Lisp'teki (yahu aslında buna pattern demeye bile gerek yok, biz zaten bunu hep ve kolayca yapıyoruz tarzı) uygulaması:

http://www.cliki.net/Visitor%20Design%20Pattern

Ve bir başka pattern: Iterator, bu da Franz'tan:

http://www.dynamiclearningcenter.com/samples/design-patterns/iterators-in-lisp-notes.html

Sondan bir önce olarak da:

http://www.lisp-p.org/controversy/

Perl'cilerin de bu pattern mevzusuna dair diyecek bir içft sözü varmış:

http://www.perlmonks.org/?node=133399

Güzel oldu, tam da bu aralar GoF kitabını ve başka bir adamın Design Patterns in C# kitabını okurken...
0
bm
Güzel oldu, tam da bu aralar GoF kitabını ve başka bir adamın Design Patterns in C# kitabını okurken...

Onlar bitince Gabriel'in kitabina da bakmak iyi olabilir. Alexander'i anlatmak disinda hayat ve hatiratini da var o kitapta. En azindan bir Smug Lisp Weenie nasil o hale gelmis anlamak bakimindan fena olmaz (Unix'le C'ye virus deyip ustune RMS ile kapisip emacs'i fork etmis bir adam, daha ne olsun):

http://www.dreamsongs.com/NewFiles/PatternsOfSoftware.pdf

0
skoylu
Birincisi, begin-end eşleme mevzusu size aman aman gibi geliyor olabilir, ama bu hiç bir programlama dilinde kritik olmaz. LISP'in yoğurt yediği gibi yenmeyen diller için en başından yaklaşım tamamen farklı olur.

Buradada bir tür SMTP implement etmeye çalışan bir state machine var. ama bu iş o kadarcık olmaz. Bu makinenin socket state'lerini takip eden, recv/send hatalarını takip eden, connection'ları vs. takip eden... Bir sürü parçası eksik. Ne girişte recipient checking, nede mime checking vs. mevcut. Daha hatta, bu bilhassa yük altında mail hub olarak çalışacaksa, blocked I/O ile pek fazla uzağa gidemez. Haa, hani bunun kuyrukları demeye hiç gerek yok sanırım..

Elbet adamın derdi sendmail'e rakip bir şey yapmak değil. Ama asıl önemli olan husus bunun gibi bir karışık makineyi yapmaya çıktığınızda böyle tıonla husus göreceğiniz. Gerçek dünyaya hoş geldiniz. O dünyada yukarıdaki saydığımız şekilde içice geçmiş karmaşık yapılar karşınıza çıkar ve böyle kısaca özetleyemezsiniz iş yapacak kodu. Mesela, tcp/25 için root hakları gerekirken, bu haklarla uzağa gidip ortalığı karıştırmamak adına paketi aldıktan sonra haklarınızı devredersiniz. vs. vs. İşte o zaman yazdığınız kod, LISP veya başkasında hemen hemen aynı olmaya başlar gider. İşte o yüzden de, adam gibi bir SMTP server yazmak için C daha "fine grained" olarak tercih sebebi oluverir. Haa, bunun gibi bir state machine'i Python ile yazsakta çok farklı olacağını sanmıyorum. Eğer illa diyorsanız, oturalım yazalım. Hatta birde java ile yazalım. Bakalım gerçekten o kadar amaney diyecek fark var mı?

Gerçek dünyada işler başkadır. Karşınıza çıkan sorunlar çoğu zaman öyle 50 satır filan tutan kodlar gerektirmez. Binlerce satır sıradan bir iş olur. Asıl o zaman programlama yaptım dediğinize değecek bir iş ortaya çıkar. Kaldı ki, Mathlab veya sıradan bir hesap tablosu (hele birde VBA gibi scripting desteği) 50 satırlık kodun yapacaklarından çok daha fazlasını çok daha seri olarak yapmanızı sağlar.

LISP ile öyle karmaşık işler yapılamaz mı? Yapılır. Tekrar tekrar edeyim. Konu böyle uygulama yazmayı gerektirecek kompleksliğe ulaşınca LISP ile Python, java vs. arasında pek bir fark kalmaz. Satır sayısına vs. baktığınızda %2-3 bir şey değişir.

Ama sorun şu. Kız gitmiş, Programcı sertifikası lamış on yaşında ne yapmış.. Hesap makinesi.. İşte hesap makinesi yapmaksa dert, LISP ile Java veya C arasında korkunç farklar görürsünüz. Ama söz konusu olan bir hesap tablosu yazmaksa diller arasında çok bariz bir uçurum göremezsiniz. Temel özellik seti olarak MS Office kodu ile StarOffice kodu arasında pek bir fark olduğunu sanmıyorum. Ama StarOffice bir tür Java kullanıyor, diğeri sanırım pattern bazlı bir C++ uygulaması. Eğer satır sayılarına erişebilsek, çok fazla fark olmadığını görürüz sanıyorum..

Eee, korkuluk mu gösteriyorum.. Hayır, gerçek dünyada her şey spreadsheet yazmak kadar kompleks değildir. Önce programcıları tekrar bir ikiye ayıralım. Günübirlik bir iş başa düşünce kod yazanlar, birde işi kod yazmak olanlar. Kırk yılda bir yazacağınız hiç bir kod, öyle ciddi manada state machine vs. içermez. Burada duruma göre bazı diller diğerlerine fark atabilir. Ama ciddi bir programlama faaliyetinde işler o kadar basit olmaz. Bir kaç bin satırlık kodlar söz konusudur, bu noktada da diller arasında pek bir ayrım göremezsiniz. Bir noktaya gelirsiniz, LISP'in makrosunu ararsınız, bir başka yere gelir Python'un dictionary'lerini. Bir başka yerde de Java'nın RMI nerde dersiniz. Maalesef bu böyle. en azından benim başıma defaten gelmiş bir şey bu...



0
bm
Birincisi, begin-end eşleme mevzusu size aman aman gibi geliyor olabilir, ama bu hiç bir programlama dilinde kritik olmaz. LISP'in yoğurt yediği gibi yenmeyen diller için en başından yaklaşım tamamen farklı olur.

Pekiyi, o zaman siz bana ogretin. 'Ama semaphore?' diyen birisine ne gosterseydim? Loop macro'yu mu? Ne bekliyordunuz isin icine semaphore'u soktugunuz zaman? Tilsimli senkronizasyon mu?

Kalanina diyecegim birsey yok cunku onlari neye cevaben yazdiginizi anlamadim. Ben size soket programlama bilmezsiniz, unix'de priviledged portlara bind etmek nasil olur anlamazsiniz demedim ki bunlari bildiginizi gosteriyorsunuz bana? Acaba lafini ettiginiz seylerden semaphore icin ornek vermek yerine state-machine icin verseydim ne olurdu onu anlamis oldum sadece (o da size yardimci olmadi). Oturalim yazalim filan isleri icin (yahut 'size aman aman gelir ama' filan tarzi icin) dogru adam degilim ben galiba, yorulmayin. Pesinen ancak ayakkabilarini kuru tutabilen biri oldugumu soyleyeyim bir yaris haline gelmesin bu. Maksat 'bu macrolar da neymis' sorusunun cevabini vermekti sadece.

Bir seye daha degineyim:

LISP ile öyle karmaşık işler yapılamaz mı? Yapılır. Tekrar tekrar edeyim. Konu böyle uygulama yazmayı gerektirecek kompleksliğe ulaşınca LISP ile Python, java vs. arasında pek bir fark kalmaz. Satır sayısına vs. baktığınızda %2-3 bir şey değişir.

Lispli veya lispsiz bu bana dogru gelmiyor. Bunlari duzgun olcmek de cok zor aslinda. Bu sonucu vermis ciddi bir calisma varsa nerededir bilmek isterim tabii.
0
bm
Bu arada aslinda FM'deki ilk Smug Lisp Weenie siz olabilirsiniz. TR'de lispi yayma projesinin basarisini belki de size 'C' yerine "lisp' dedirtmesi ile olculmeli? Nasil hedef ama?
0
skoylu
Birincisi semaphore diyerek geçmemek lazımdır. Programlama da sorunların büyük kısmı race condition'ları çözmekle halledilir. Ben doğrudan semaphore dediğimi hiç sanmıyorum. Ama hangi dili kullanıyor olursanız olun, kaynak paylaşımı ve çakışmaları önlemek birebir ciddi programlama sorunlarının başında gelir.

Ben de gidip soket programlama anlatmadım. Ama sizin state-machine örneğiniz böyle bir örnekti. Bana hiç çatmayın bu hususta. Sanki hiç LISP ve Makro yazmamış biri ile tartışmıyorsunuz, farkında olun. Diğer yandan siz orada çaıkca, LISP ile State-machine örneği veriyorum gibi yazmışsınız..

Sen diyorsun ki bu bana doğru gelmiyor. Merak ediyorsan otur şöyle 30-40 bin satır tutacak birer kod yaz. Öğren bakalım doğru muymuş değil miymiş? Yada aynı şeyleri yapan kodları bul. LISP'te, Python'da Java'da vs. nasıl kod yazılmış bir incele bakalım.
0
bm
Obur iste uzlasamayacagiz, birakalim.

Sen diyorsun ki bu bana doğru gelmiyor.

Bu herhalde Python, Lisp, Java vs. arasinda %2-3 satir sayisi farki ile ilgili? Evet gelmiyor.

Merak ediyorsan otur şöyle 30-40 bin satır tutacak birer kod yaz. Öğren bakalım doğru muymuş değil miymiş? Yada aynı şeyleri yapan kodları bul. LISP'te, Python'da Java'da vs. nasıl kod yazılmış bir incele bakalım.

Bunun yolu o degil. Bu tip seyleri denemenin zorlugu da bir kisinin oturup 30-40k satir program yazmasindaki zorluk degil. Kontrollu ve faktorlere hakim olunan deney yapmanin zorlugu. Ben bunu sorarken derken ciddi bir calismaya dayanarak mi diyorsunuz diye merak ettigim icin sordum. Anladigim kadariyla boyle bir calisma bilmiyorsunuz. Bilen var mi?
0
FZ
Ama, sanki XML olmadan Java olmaz, C#olmaz gibi bir esinti var. Benim şahsi görüşüm, XML'in bir balondan ibaret olduğudur. Sağlam olup ömürboyu patlamayacak olması onun balon olduğu gerçeğini değiştirmez.


XML esintiden ziyade kuvvetli bir fırtına gibi öyle değil mi? En azından son 4-5 yıldır.


Yani, Java veya C# kullananların XML kullanmaya vs. bulaşıp kendilerine zulm ediyor olması onların sorunu. Bu yüzden gidip Java veya C# yada Python'u zavallı görmek vicdana sığıyor mu?


Doğru onların sorunu. Onlardan çok var. Martin Fowler'ın örneğinde de yine XML gündemdeydi. Evet, onların sorunu. O örnekte Java ya da C#'a zavallı denmiyordu, söz konusu işler daha kolay yapılabilecek iken daha zor yapılmasına karşı üzüntü belirtiliyordu okuduğum kadarı ile.


LISP iyidir, ama Python da iyidir.


Bu sitede Python ile ilgili makale yayınlamadık mı? Bunlardan bir tanesi fanatik Lisp ustası Paul Graham'ın Python Paradoksu başlıklı yazısı değil miydi ve o yazıda sinsiden sinsiye Python ile uğraşanları "tehlikeli, hacker adamlar, çok iş çıkartabilirler" şeklinde övmüyor muydu?

Java yokken ortada Python vardı. İyi ki de var, insanlara farklı bir ufuk sunuyor. Zaten Martin Fowler ve çevresinde dönen tartışmada Python ile ilgili hiçbir laf yok ki. Nelerin eleştirildiği belli. Buyursun birisi de yahu yormayın kendinizi Java ile C# ile bakın o iş Python ile şu şekilde çok daha kolay yapılır desin, ona da bakalım, nasıl yapılıyormuş. Ben kendi adıma üşenmedim dün gece Joswig'in videosunu izledim, bir yandan İngilizce anlatıyor, bir yandan adım adım Lisp ile söz konusu problemi nasıl çözdüğünü filan gösteriyor. Gayet de güzel ve eğlenceli idi. Python ile yapılmışı var ise gider ona da bakarız, buna karşı hiçbir laf etmedik ki burada.


Python, LISP veya Java üzerinde uzmanlık sağlaması için geçecek süre, harcanacak emek vs. pek farklı değildir.


Farklıdır. Kendi adıma konuşayım, muhtemelen Python için harcayacağım süre Common Lisp için harcayacağım süreden çok daha kısa olacaktır. Belki bir gün Python da çalışırım ancak şimdilik, kişisel olarak, Common Lisp çalışmayı tercih ediyorum. Kişisel sebepler derken, Lisp çalışmak ve comp.lang.lisp'te takılmak epey eğlendirici ve bilgilendirici, tabii herkes bana katılmak zorunda değil, kendi izlenimlerimi ortaya koyuyorum hepsi bu.

Gene aynı sitelerde karşılaştığım makro mucizesi filan gibi şeylerde bana bir anlam ifade etmiyor, çünkü hemen her dilde aynı sonuca aynı şekilde çabuk ulaşmanızı sağlayacak tonla şey var.


Lisp'teki makrolara mucize demiyoruz. Çok güçlü bir özellik hepsi bu. Dilin içinde kalarak o tür iş güç yapabiliyor olmak, çarpıcı bir özellik. Size bir anlam ifade etmiyor olabilir. Başka dillerdeki (misal Java, C#) "code generation" mevzularına göz attığımda korktum açıkçası, bu ne yahu, bununla mı uğraşacağım, 2005 yılında bana bunlarla mı geliyorsunuz dedim.


Konu uzmanlaşma konusu. Çok iyi LISP bilin, çok iyi Python bilin, çok iyi Java bilin vs.. Bunun arasında bir fark yok.


Enteresandır, bu aralar Lisp öğrenenlere tavsiye ettiğimiz, Internet üzerinden kaynak kodları ile birlikte herkese açık olan Practical Common Lisp kitabının yazarı Peter Seibel aynı zamanda çok iyi bir Java programcısı. WebLogic gibi J2EE konusunda uzman ve dünya çapında iş yapan şirketlerde çalışmışlığı var. Şimdi bu adam gidiyor, ciddi emek harcıyor ve gelin yahu biraz Lisp çalışalım, çok eğlenceli, güçlü ve pek çok işimi Java'ya kıyasla daha kolay ve rahat yapıyorum Lisp'te diyor. Tabii ki herkesin kendi aklı var, benim verdiğim sadece küçük bir örnekti. Kaynaklar herkese açık, insanlar okur ve kendileri karar verir. Biz kaynaklara göndermede bulunup bazen makaleler yayınlıyor ve bazı şeyleri Lisp'te nasıl kolayca yapabileceğimizi anlamaya çalışıyoruz.


LISP, Python vs. vs. diyoruz, Web sayfasında client side kodlama yapacaksak bunların hepsi hikaye kalıyor


DHTML ve JScript gereksizdir, onlar olmadan da etkileşimli web sayfası süper olur diyen deneyimli bir Lisp programcısı ile karşılaşmadım. Ya siz?


Bu diller programlama sürecinin %10'unu kapsayan şeyler. Geri kalan %90 işte o disiplin içinde kalıyor. Bu yüzden de en iyi dille en kötü dil arasında olası nitelik farkı zaten %10'u aşamıyor.


Böyle kesin rakamlar vermek kolay değil. Ama haydi bunu geçtim, bir programla dili öğrenmek hiçbir zaman sadece dilin sözdizimini ve semantiğini öğrenmek demek değil aynı zamanda bir bakış açısı edinmek, bir kültürle yüzleşmek, o kültür içinde bazı şeylerin nasıl yapıldığını, gelenekleri, önemli problemlere getirilmiş önemli çözümleri öğrenmek demek. Bir dil, etrafındaki insanların oluşturduğu ekosistemle birlikte var oluyor. Lisp söz konusu olduğunda ise yaklaşık 50 yıllık bir süreç söz konusu. Bugün Lisp'i ortaya atan adam McCarthy de hala Lisp konferanslarına katılıyor, diğer Lisp programcıları ile sert tartışmalara giriyor, vs. Gençler de var, dinozorlar da var. Ben, kendi adıma, insanların deneyiminden faydalanmaya, daha önce görmediklerimi görmeye çalışıyorum. Bu bana ne kazandırır, bu biraz benim kapasiteme ve zamana bağlı, yavaş yavaş belli eder kendini. Sadece şu kadarını söylememe izin verin, Perl Rahipleri sitesinin süper yaklaşımını ve paylaşım ruhunu bir yana bırakırsak (perlmonks.org), comp.lang.lisp bu bakımdan karşılaştığım en iyi ortamlardan biri, alanındaki programcılar ve bilgisayar bilimciler, bunların ezici çoğunluğu gerçekten deneyimli insanlar ve bu deneyimlerini de çok güzel ve çarpıcı örneklerle aktarma yeteneğine sahipler. Bence, bu bir şans ve böyle olduğu için de sevindim. Orada bu konulara yıllarını adamış zeki ve bilgili insanların ders verircesine bazı konulardan bahsetmesi, yeri geldiğinde C'ydi, C++'ydı, vs. dilleri de harmanlayarak örneklendirmeleri, kıyaslamaları ve kaynaklara göndermede bulunmaları çok değerli bir durum teşkil ediyor.


Ama siz, JavaScript ile server yazacağım yada LISP ile ofis süiti yazacağım diyorsanız baştan kaybetmiş olursunuz.


Önce bir korkuluk üretiyor sonra bu samandan korkuluğa saldırıyorsunuz. Şu eğlenceli browser-içinde-UNIX mevzusunu saymazsak JavaScript ile UNIX yazmak isteyen kim? Bunu iddia eden bir Lisp programcısı ile mi karşılaştınız?


Ah bir LISP makinesi olsaydı...


Vardı, yanılmıyorsam birkaç farklı şirket tarafından 10-15 sene üretildi ve epey kullanıldı o makinalar:

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

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

http://en.wikipedia.org/wiki/Lisp_Machines%2C_Inc.

Bugün PC'lerde ya da Mac'lerde çalışan deneyimli Lispçilerin hala "yahu Lisp Machine süper geliştirme ortamıydı" dediklerine şahit oluyor, videoları filan seyredince şaşırıyor ve takdir ediyoruz.



Eğer alacak müşteri olsaydı, yapacak bir INTEL, AMD vs. bulunurdu. Platform olarak geliştirilen Java bile bu noktada bir şey yapamadı.


Yani piyasa koşullarından bahsediyoruz. Yani başka türlüsü de olabilirdi, mantıki bir zorunluluk yok ortada. Bugün baştacı edilen şeyler 15 sene sonra ortada olmayabilir, bu o baştacı edilen ve gerçekten değerli de olabilen şeylerin işe yaramaz olduğunu göstermez öyle değil mi.


LISP2in pek şansı olduğunu sanmıyorum. C# için IL kodunu doğrudan çalıştıran makine yapılır sanıyorum, ama LISP için LISP makinesi üreten pek olmaz kanımca..


Olur ya da olmaz, bu yukarıda belirttiğim gibi ekonomik koşulların türbülansı ile ilgili, hep birlikte göreceğiz; açıkçası 15 yıl sonra neler olacağını ben tahmin bile edemiyorum. Öte yandan Lisp Makinaları denen mefhumdan haberdar olmak bile bence bir fark yaratıyor. Alternatifsiz olmadığımızı çok değil kısa bir süre öncesine dek insanların bugün çoğu kişinin adını sanını duymadığı platformlarda çok güzel, zevkli ve verimli şekilde çalıştıklarını bilmenin getireceği ufuk genişlemesi bence az buz şey değil.
0
bm
skoylu: Python, LISP veya Java üzerinde uzmanlık sağlaması için geçecek süre, harcanacak emek vs. pek farklı değildir.

fz: Farklıdır. Kendi adıma konuşayım, muhtemelen Python için harcayacağım süre Common Lisp için harcayacağım süreden çok daha kısa olacaktır.


Bence FZ'nin dedigi dogru. Common Lisp'in tasarim ve standartlastirma kriterleri arasinda 'kolay ogrenilsin' 'korkutmasin' 'isi gorsun yeter' on planda degil. Diger dillerde pek gorulmeyen kuvvette macro sistemi, genel amacli condition sistemi, birden fazla deger dondurebilen fonksyon cagirmasi (liste hilesiyle degil, oyle tasarlanmis) var en azindan. Bunun ustune CLOS ve standardin disinda olmasina ragmen kendini belli eden MOP biniyor. Alana giris Scheme ile yapilmis olsa (yani parantez korkusu olmasa) bile kisa zamanda hakim olunabilecek bir dil degil. Dilin tamamini kullanmak gerekmiyor tabii, o ayri.
0
bm
Bu sorulari ben pek anlayamiyorum cunku soylenmeyen kismi var: ogrenirken harcanacak olan zaman para ve enerjinin gidecegi alternatif yer nedir? Bu yazi o bakimdan biraz yardimci olmus. Bir iki sey ekleyeyim:

-- C ile C++'i ayni kalip icinde kullanmak yanlis. C oldukca kucuk ve tarihsel gelisim icinde bir zaman gerek derleyici yazmaninm kolayligi gerek sosyal bakimdan bir cins optimumu yakalamis bir dil. C++ 'statikimsi Cimsi' bir dille OO modasini takip etme yolu haline gelmis ne kus ne deve, ama ikisini de olmaya calisirken biraz sasirmis ve bazen manasiz yere komplikelesmis bir dil. Dil ogrenerek makineye yakin olmayi anlamaksa maksat, C kafi bu is icin. C++ icin iyi bir sebep yoksa (para, kullanilan kutuphanelerden dolayi o ortama bagli olma geregi, okul zorlamasi vs.) iyi ogrenilmemesi bir kayip degil. Ozellikle C++'i dunyanin merkezi kabul eden OO akimi okumaya devam etmeyecek insanlar icin bence biraz da zararli (OO C++ ile baslamis ve o tarzdan ibaretmis gibi anlatan bir takim pattern isleri vs.).

-- Mesela Knuth'un MIX veya MMIX'i ile algoritma filan calismissaniz, yahut makineye yakin olabilmis baska diller biliyorsaniz (Wirth'in dillerinin bazi eklerle makineye yaklasmis halleri mesela, yahut diger Algol turevleri) zaten C'yi biraz daha iyi ogrenerek makineyle ilgili bilgiyi hissetmek gibi bir durumunuz olmaz[1]. Aaa boyleymis bu C demek deyip yurursunuz. Bu bakimdan kastettigi sey dogru olmasina ragmen Skoylu'nun 'kaputun altina bakma yolu C'dir' tarzi cumlelerini duz okumayin bence. Ehven-i ser ve kolay ulasilan bir dil oldugu icin tavsiye ediliyor yoksa muazzam bir ozelligi yok.[2]

-- Hakikaten sistem tarafindan yaklasip ciddi sekilde kaputun altina bakmak gibi bir arzunuz varsa, en azindan mimari, isletim sistemleri, dil tasarimi/derleyiciler ile igili kitaplari okumak ve bir iki proje yapmak bunun dogru yolu bence. Mesela:
http://www.amazon.com/exec/obidos/tg/detail/-/1558603298
http://www.amazon.com/exec/obidos/tg/detail/-/1558604421
(benim tavsiye edecegim OS ve derleyici kitaplari eskidi, tavisyesi olan eklesin). Ciddi calismanin yerine herhangi bir dili ogrenmek kesinlikle gecmez ama ciddi calisirken bazi dilleri ogrenmek ve belki daha onemlisi neyi niye yaptiklarini anlamak mumkun olur. O bakimdan kazanc (yine amaciniza gore) daha fazla olabilir.

-- "Sistemleri cok iyi anlamak' ile cok iyi ve verimli bir programci olmak es anlamli degil. Kismen ortusen taraflari var o kadar. Arabayi yapan muhendis ve yaris soforu ornegi biraz esneterek bu konuya oturtulabilecek bir karsilastirma.


[1] Bunu laf olsun bir de Algol demis olayim diye yazmiyorum. Algolumsu 'pseudocode' ile algoritma anlatan kitaplar var ve onlarda birsey eksik kalmiyor. Debian'a algol'u nereden takarim Windows'da var mi diye soracaksaniz zaten ayni seyden bahsetmiyoruz, ama ':=' yerine '=' yahut ne bileyim (buraya yazamadigim iki buyuktur isareti) yerine shift yazildi diye dil makineden daha uzak olmuyor. Hat gurultusune benzeyen notasyon kaputun iyice altina inmek demek degil. UNIX/Linux furyasi, ve MS'in yakin zamana kadar C++ ittirmesi insanlarin ufkunu cok daraltti. C veya C++'i 20 sene evvel ders dili yapmak dusunulmezken (tam 'gulunc olma' denecek seydi) simdi ogrenciler ve belki bazi hocalar bunlari nirvana gibi goruyorlar. _Teknik_ bir sebebi yok bunun bence.

[2] Hiz diyecek arkadaslarin derleyicinin onlarin gormedigi yerlerde neler yaptigini, mesela hafizaya direkt pointer ile gidilebilmesinin hangi optimizasyonlarin ayagina bastigini dusunmeleri yerinde olur. Fortrancilar biraz daha dikkatlidirler bu konularda. Burada benim asil demek istedigimle alakali birsey var: C bildiniz diye kaputun altina da tamamen hakim olmuyorsunuz, belki baktim zannedip 'orada da silindirik birsey var' dediginiz sey bir supercharger olabiliyor -- malloc'a program linkleyip 'hafizayi _tamamen_ kendim idare ediyorum' demek hatasi gibi. Aslolan tabii ki bilgi, dil degil.
0
skoylu
Birincisi, OOP bir dil uzantısı değildir. OOP bir programlama yakalışımıdır. C ile de gayet iyi OOP temelli kodlar yazabilirsiniz. Çok detaya girmeden şu örneğe bakın:

nesne->metot(parametre)
metot(nesne, parametre)

Örnek kabul ediyorum, çok iyi açıklamıyor durumu. Ama OOP paradigması ile dil arasında doğrudan bir bağ kurmak yanlış.

Bu noktada OOP'un bariz avantajları nedeniyle, bazı diller doğasından OOP'un bir takım özelliklerini desteklerler. Bu nesnelerin derleyici tarafından farkında olunmasını sağlar vede operator overloading gibi kolaylaştırıcı etmenleri size sunar. Fakat, C++ kullanıyor olmanız nesne yönelik uygulama yazdığınız anlamına gelmez. C'de herşey açıktadır, OOP'un ana ilkesi ise veriyi saklamaktır. Bu yüzden derleyici sizin veriyi saklayan mekanizmalar sunar. Ama siz kodunuza hakimseniz, aynı şeyi C ilede gayet makul bir şekilde yaparsınız.

C, C++, LISP, Python, OOP vs. devrimsel olaylar değildir. Bunlar evrimsel olaylardır. İnsanlar bir takım teknikler geliştirir. Bunlar kolaylık sağlar, kalıplaşmış ifadelere döner. Akabinde birisi çıkar bunu bir dile çevirir. En radikal doğuma sahip olan LISP için bile durum böyledir. List Processor. List denen kavram LISP'ten önce vardı. OOP denen kavramda ilk nesneye yöenlik dillerden önce vardı. C++ yazılırken OOP teknikleri zaten oturmuş haldeydi. C++, C'yi OOP olarak kullanırken daha kolaylık sağlamak üzere geliştirildi.

C/C++ dememdeki etmende aynen pratik bir sonuçtur. Elinize alın bir MSDN CD'si. İçinde Windows'un async I/O vs. mekanizmalarını anlatan tüm bilgiler C/C++ için yazılmış olur. Bir CPU'nun veya OS'un manuelinde INT yazıyorsa, bu Python'un veya LISP'in integeri değil doğrudan C'nin INT'idir. Kitap okuyarak pratik yapmak zordur. Ama konu derleyici yazmakvs. ise C derleyicisi yazmak diğerlerinden daha zordur. Dahası, C ile derleyici yazmakta LISP veya Python'la yazmaktan daha zordur. Ama kasarsanız, BASH ile bile derleyici yazarsınız.

Sebepler gayet net. C bilmek size bir şey getirmez. Zaten 50 sayfa tutmaz herhalde C kitapları. Gidin bakın, sanırım kütüphane fonksiyonlarını çıkarırsanız, 50 sayfadan fazlasını bulamazsınız. Önemli olan, elinize bir smartcard alınca, bulacağınız her türlü dökümantasyonun mesela burada PKCS#11 kavramı tamamen C'ye yönelik olacağıdır. C ile bunuları kolayca anlayabilir, deneyebilir, tecrübe edebilirsiniz.

Algoritma bilmekle programlama bilmek arasında çok fark bulunur. Algoritma veri yapısı yönetimi başka bir husus, kaputun altında ne var başka bir husus. Diskten okunan bilginin size nasıl ulaştığı başka bir kavram. Bunu bilmek demek, bu bilginin nerde takılabileceğini, darboğaza gelebileceğini bilmek demektir ve kodu buna dikkat ederek yazabilmenizi sağlar.



0
skoylu
Hiz diyecek arkadaslarin derleyicinin onlarin gormedigi yerlerde neler yaptigini, mesela hafizaya direkt pointer ile gidilebilmesinin hangi optimizasyonlarin ayagina bastigini dusunmeleri yerinde olur.

Derleyici optimizasyonları, minor farklar sunar. Asıl optimizasyon işi kod üzerinde yapılandır. Bazı lamerlerin düşündüğü gibi 3-5 satır kaldırarak yapılmaz.

Basit ve bariz örnek. QSORT yerine iki döngü açıp içice, swap ederek sort yaparsanız, bir sürü satırdan kar edersiniz ama hızınız misliyle azalır. Bir başka örnek:

BOOL compare(a, b, c, d) {
BOOL ret;
ret = a == 1;
ret &= b==2;
ret &= c==3;
ret &= d==4;
return ret;
}

C kodu ama sanırım bariz anlaşılabiliyordur. Bunu şöyle yazsanız:

ret = a == 1 && b==2 && c==3 && d == 4;

Derleyici veya yorumlayıcının uyanıklık edip en azından a != 1 olduğu durumda diğer işleri yapmayıp biraz hız kazandırmasını sağlarsınız. Fakat birebir bu formu kodlarına gömen pek çok adam tanırım. Kimisi aynen böyle yazar, kimisi bunu daha bulanık şekilde yazar.

İşte derleyici optimizasyonu bunun gibi bir şeydir. 32 Bit alignment vs. benzer şekilde işlev görür. Fakat bir C programcısından pointeri doğru dürüst kullanması ve de o tür durumlarda derleyiciyi zorda bırakmaması beklenir.

Zaten sorunda budur. Pek çok insan C'nin ne yaptığını, sistemin ne yaptığını vs. bilmez. Çala kalem kod yazmaya girişir. Böyleleri için C yerine yüksek seviyeli diller her zaman çok daha iyi olacaktır.
0
bm
Derleyici optimizasyonları, minor farklar sunar. Asıl optimizasyon işi kod üzerinde yapılandır.

Bu dogru ama konuyla alakasi yok, asimptotik karmasiklaigi ayni olan kodlarda dilin derleyiciyiye optimizasyonda yardimci olmasi bakimindan 'C hizlidir'in her zaman gecerli olmamasi icin sebeplerin olduguna isaret etmek istemistim.

İşte derleyici optimizasyonu bunun gibi bir şeydir. 32 Bit alignment vs. benzer şekilde işlev görür. Fakat bir C programcısından pointeri doğru dürüst kullanması ve de o tür durumlarda derleyiciyi zorda bırakmaması beklenir.

Hayir, anlatamamisim. Bahsedilen sey alignment veya and'i kisa devre etmek degil temelde farkli. Basit bir ornek olarak aklima hafizaya pointer verilebilen bir dilinin 'aliasing' etkilerinden dolayi derleyicinin analiz yapmasina engel olacagi idi. Yani belki makineye daha yakiniz ama bu sefer derleyici bazi seylere musade etmeyen dillerde yapabildigi isleri yapamaz oluyor kod yavasliyor. (sizin ornegin ilk kisminda b c vd d'nin (ciddiye alinan) 'volatile' olabildigini ama derleyicinin bunu bilemedigini dusunun: bu durumda ikinci ifade zaten semantik olarak farkli oluyor, kisa devre imkani kalkiyor). Dogrudan dilin karakterinden dogan bir yavaslama soz konusu yani. Bu tip seyler yuzunden ciddi hiza ihtiyaci olan bazi alanlarda hala Fortran tercih edilir (C99'da en azindan bu konuda 'restrict' filan var o yollari acmak icin.)

Duzgun bir referans aradim size ama acik/indirilebilir birsey gozukmuyor. Merak ediyorsaniz optimizasyon kitaplari bu tip seyleri anlatirlar.
0
bm
[mark-up'i yanlis yapmisim, bir daha geciyorum. Ozur dilerim bm]

Derleyici optimizasyonları, minor farklar sunar. Asıl optimizasyon işi kod üzerinde yapılandır.

Bu dogru ama konuyla alakasi yok, asimptotik karmasiklaigi ayni olan kodlarda dilin derleyiciyiye optimizasyonda yardimci olmasi bakimindan 'C hizlidir'in her zaman gecerli olmamasi icin sebeplerin olduguna isaret etmek istemistim.

İşte derleyici optimizasyonu bunun gibi bir şeydir. 32 Bit alignment vs. benzer şekilde işlev görür. Fakat bir C programcısından pointeri doğru dürüst kullanması ve de o tür durumlarda derleyiciyi zorda bırakmaması beklenir.

Hayir, anlatamamisim. Bahsedilen sey alignment veya and'i kisa devre etmek degil temelde farkli. Basit bir ornek olarak aklima hafizaya pointer verilebilen bir dilinin 'aliasing' etkilerinden dolayi derleyicinin analiz yapmasina engel olacagi idi. Yani belki makineye daha yakiniz ama bu sefer derleyici bazi seylere musade etmeyen dillerde yapabildigi isleri yapamaz oluyor kod yavasliyor. (sizin ornegin ilk kisminda b c vd d'nin (ciddiye alinan) 'volatile' olabildigini ama derleyicinin bunu bilemedigini dusunun: bu durumda ikinci ifade zaten semantik olarak farkli oluyor, kisa devre imkani kalkiyor). Dogrudan dilin karakterinden dogan bir yavaslama soz konusu yani. Bu tip seyler yuzunden ciddi hiza ihtiyaci olan bazi alanlarda hala Fortran tercih edilir (C99'da en azindan bu konuda 'restrict' filan var o yollari acmak icin.)

Duzgun bir referans aradim size ama acik/indirilebilir birsey gozukmuyor. Merak ediyorsaniz optimizasyon kitaplari bu tip seyleri anlatirlar.
0
skoylu
Konuyu dağıtıp biyerlere doğru götürmeyelim. Bir toparlayalım..

Öncelikle derdimiz şu anda optimizasyon nasıl yapılır sorunu değil. Aynı şekilde semaphore nasıl kullanılır değil. Gene aynen soket nasıl programlanır da değil.

Derdimiz öncelikle LISP ile kod yazmak mutlak olarak, bariz bir şekilde daha mı avantajlıdır konusu.

Bir takım örnekler gösteriliyor. Bende diyorum ki bu örneklere bakınca LISP'in bariz bir üstünlüğü görülmüyor. Diğer yandan gerçek dünya için yazacağınız uygulamalarda başınıza geleceklerden o örneklerin tamamen farklı olduğunu söylüyorum.

Gerçek dünyada, state-machine, race condition, IPC gibi tonla iş önünüzdedir. Siz basitçe bir adres defteri yazarsınız. Basit bir iş. Ama bu bile kendi içinde race conditionlar vs. taşır. İş bunları çözmeye gelince kodlar irileşmeye başlar, sonuçta diller arasındaki öngörülen üstünlükler giderek anlamsız hale gelir. Bu kurala uymayan nerdeyse tek dil C'dir. O her zaman aynı avantaj ve dezavantajlara sahiptir.

Konuyu alıp optimizasyonlar vs. halkalarına çekmenin anlamı yok. C öğrenip 2 yıl oturun, programcı olursunuz demiyoruz. C öğrenip 2 yıl ciddi ve makul yoğunlukta çalışırsanız o zaman gerçek manada programcılık tekniklerini yeterince öğrenmiş olursunuz, diyoruz. Bu tekniklerde LISP veya BASIC kullanmanız halinde dahi her zaman işinizi görecek, daha iyi kod geliştirebileceğiniz tekniklerdir.

Bu bir ayrı husus. Bu aslen topiğin konusu. Tartışmanın konusu ise, LISP kullanıcılarının LISP'i en "en" dil olarak göstermek istemesi. Bence bu yanlış. LISP "en" dil değildir, ama diğerleri de değildir. Hemen hepsi, bilhassa gerçek dünyadaki uygulamaların geliştirilmesi işinde diğerlerinden daha üstün değildir. Öncemli olan dil öğrenmek değil, dili kullanmayı öğrenmektir.

Bunun en iyi örneği, kim nasıl hello world yazar, örneğinde görülebilir. C++ için kabaca:

cout << "hello worldn";

İşe yeni başlayan adam için bu güzel bir örnektir. Ama bu iş bu kadar basit değildir. Gerçek dünyada Hello World böyle yazılmaz. Çünkü kimse iki kelime yazmak için kod yazmaz. Bundaki hataları söyleyeyim ben size basitçe:

* Bu kodda, satır sonunun "n" olduğu farzedilmiş. Oysa bu böyle olmak zorunda değil. Önce gidip satır sonu için ne gerektiğini bulmanız gerekir.
* Paldır küldür stream'a yazmaya başlıyorsunuz, bu da büyük bir hata, önce stream'ın yazmaya hazır olup olmadığını test etmeniz gerekir.
* Diyelim ki bir program çalıştı ve ekran renklerini siyah zemin üzerinde siyah yazı yaptı. Eğer ekrana yazıyorsanız, önce bunun okanbilecek olduğuna emin olmalısınız.
* Toplam 12 bayt yolladınız. Bu mesajın basılacağı yerde 12 bayt yer olduğuna nasıl hükmediyoruz?

Daha bu liste böyle uzar gider. Ve sonuçta, basit görünen hello world yazma işi, gerçek dünyaya çıkınca bir sürü teferruat getirir. Programcı, bu teferruatı önceden görüp ona göre kodunu yazan adamdır. Ve bu noktada maalesef en basit işler bile kolayca binlerce satıra ulaşır. Pek çok yeni başlayan bu yüzden LISP, Python, C# gibi dilleri çok acayip şekilde avantajlı görür. Ama sonuçta yazılan kodun nihai aşamalarında bu üst düzey dillerin avantajlarının yadsınamaz derecede önemli olduğu ama hiç birinin maalesef mucize yaratamadığını tecrübe ederler. Bu süreçte sıklıkla, 15 günde biter denen iş 3 ay sonraya sarkar. Çünkü oratadaki işin teferruatı görülmemektedir. İşte bu yüzden salkım saçak çalışmaya daha kolay uyum gösteren Python gibi diller tercih edilir. Bu diller için prototip dili denmesinin asıl sebebi budur. Çünkü nihai uygulama çoğu zaman hangi dille yazdığınız önemli olmayacak kadar kompleks olacaktır.

İşte yanlış tam buradadır, vede benim hararetle aman LISP böyledir demeyin dememin esprisi budur. LISP'i bu kadar göğe çıkarırsınız (yada pythonu vs. farketmez) yeni başlayan adam buna kanar ve asıl sorunu çabucak atlar. Bir süre sonra da LISP'ten soğutursunuz, çünkü iş çetrefilleşince LISP'in ona verebileceği bir şey olmaz.

0
bm
Öncelikle derdimiz şu anda optimizasyon nasıl yapılır sorunu değil. Aynı şekilde semaphore nasıl kullanılır değil. Gene aynen soket nasıl programlanır da değil.


Ozellikle ayri yere yazmisdim bunu ve bir dipnot yanlis anlasilip siz optimizasyondan bahsedince burada ogrenmeye calisan insanlar yanlis anlamasin diye cevap verdim yazdiginiza. Konu budur. Yahut buydu. (Halbuki akla gelebilecek birseyi eksik kalmasin belki herseyin duz olmadigi konusunda yol gosterici olsun diye koymusum ben o dipnotu.)

Derdimiz öncelikle LISP ile kod yazmak mutlak olarak, bariz bir şekilde daha mı avantajlıdır konusu.


Yanis yere cevap veriyorsunuz o zaman. Ben bu alt konuda boyle birsey demedim ama onemli degil takip eden varsa cikartabilir herhalde. Genelde burada lisp dememinizin ana sebebi 'ogrenmeniz ufkunuzun acilmasina yardimci olur' fikri. Bu konuda Dijkstra'dan ESR'a kadar bizimle ayni fikirde olan ve inanilirligi bizden cok daha fazla olan insanlar var. Hedef kitle de sadece kendisine programci rolu bicmis olanlar degil, bilgisayar bilimiyle ilgilenenler (Quine'lar, Y-combinator filanin soz konusu olmasi biraz da bu yuzden).

Bariz avantaj konusu iki uc dile hakim insanlarin tartabilecegi birsey. Simdi cikip ben hakimim ve evet bariz avantajli demeyecegim, hem dogru olmadigi durumlar var hem insanlar kendileri ogrensinler tartsinlar cok daha iyi. Genelde su ana kadarki (buradaki Turkler baglaminda) tecrubemiz ogrenmenin ufuk genislettigi ve 'iyidir' diye ittirilen dillere supheyle bakmaya yol actigi yonunde.

Bir takım örnekler gösteriliyor. Bende diyorum ki bu örneklere bakınca LISP'in bariz bir üstünlüğü görülmüyor.

Bir tanesinde detaya indiniz onda da bana yazilan lispi okuyamadiginizi zannettiren birsey soylediniz. Biliyormussunuz halbuki, o zaman problem neydi niye anlamaz gibi yaptiniz bilemiyorum. Ama biz (su anda ben ve FZ) burada Skoylu'yu egitmek veya ikna etmek icin fazla mesai yapmiyoruz, yukarki cercevede hevesli insanlari belki biraz ufuk acici seylere yonlendirmeye calisiyoruz. Daha iddiali seyler soyleyenler, mucizelerden bahsedenler burada degil, onlarin oldugu yerlere gidip bu dediklerinizi yazmaniz size ve onlara daha faydali olacaktir herhalde. Yazismalardan anladigim kadariyla sizin ne lispten bahseden kimseden kimseden ogrenecek birseyiniz ne de bizim konuda katki yapmaya niyetiniz var. Mani olmaya calismanizin sebebinin ne oldugunu da ben anlamadim. Mucize filan diyoruz gibi geliyorsa size bir defa daha soyleyeyim: demiyoruz.

Diger yazdiklariniz ne demek, neye cevap ben anlayamadim. Duz okuyunca da kismen yanlis geliyor bana ama nette yanlis duzeltmeye omur yetmez -- okuyanlar kiraathane tavsiyesi olarak alip akil eleginden gecirirler zaten herhalde. Siz de beni aklim ve bilgim yetmedi diye kabul edin.
0
FZ
Dijkstra ve ESR lafı geçmişken birkaç alıntı:

"Lisp öğrenmek başka bir sebepten dolayı önemlidir - sonunda anladığınız zaman elde edeceğiniz aydınlanma deneyiminden dolayı. Bu deneyim, bir daha hiç LISP kullanmasanız dahi, hayatınızın kalan kısmında çok daha iyi bir programcı olmanızı sağlayacaktır. (Emacs metin düzenleyicisi için basit düzenleme modları yazarak ya da varolanları değiştirerek küçük LISP deneyimleri kazanabilirsiniz.)" - ESR [1]

"Tasarlanmış en büyük programlama dili." Alan Kay [2]

"Lisp bir dil değildir, bir inşa malzemesidir." - Alan Kay [2]

"Şaka yollu, Lisp'in 'bir bilgisayarı yanlış kullanmanın en zekice yöntemi' olduğu söylenir. Bu tasvirin aslında bir iltifat olduğuna inanıyorum çünkü özgürlüğün ne demek olduğuna işaret ediyor: O, en zekilerimizden bir kısmına önceden imkansız kabul edilen şeyleri düşünmelerinde yardımcı oldu." - Edsger Dijkstra, CACM, 15:10 [2]

"Bilgisayarın yapabileceklerini yapmayı reddediyorum" - Olin Shivers [2]

"Sadece SQL, Lisp ve Haskell söz konusu olduğunda insanların düşünmeye ayırdıkları zamanın kodlamaya ayırdıkları zamandan daha çok olduğunu gördüm" - Philip Greenspun [2]

"O zamandan beri diğer dillerle de uğraştım: Perl, Java, Python, Standard ML, Caml, Prolog ve Haskell. İtiraf etmek zorundayım: Dönüp dolaşıp gene Lisp'e geliyorum. Tam olarak neden olduğunu anlamıyorum ama öyle yapıyorum ve bu süreçle ilgili bazı şeyler keşfettim." [3]

Son olarak da, APress'ten Dr. Gary Cornell'in "Neden bastık biz bu Practical Common Lisp kitabını" açıklaması:

http://blogs.apress.com/archives/000492.php?author=gary_cornell

1- http://www.belgeler.org/howto/hacker-howto/hacker-howto-basics.html

2- http://www.paulgraham.com/quotes.html

3- http://harold.hotelling.net/old_blog/000957.html
0
FZ
Enteresan bir yaklaşımınız var, sanki Common Lisp pek çok gerçek dünya uygulamasında kullanılmamış gibi.

Öte yandan, hata ele alma meselesinden bahsetmişsiniz:


* Diyelim ki bir program çalıştı ve ekran renklerini siyah zemin üzerinde siyah yazı yaptı. Eğer ekrana yazıyorsanız, önce bunun okanbilecek olduğuna emin olmalısınız.
* Toplam 12 bayt yolladınız. Bu mesajın basılacağı yerde 12 bayt yer olduğuna nasıl hükmediyoruz?


E yani ortada monitör de olmayabilir, klavye de olmayabilir, network kablosu çekilmiş olabilir, vs. vs. Ne ki bu? Belli varsayımlarda bulunur, çıkabilecek hataları düşünür onlar için hata ele alma mekanizmaları kullanırsınız. Öyle bir aktarmışsınız ki sanki C++ kullanmayan biri asla ve kat'a "error handling" konusu ile uğraşmaz, bundan haberdar da değildir, "haha, bu üst seviyeli bir dil, benim yerime tüm hata ele alma işini yapar, oh kafam rahat" dermiş gibi. Konu hata ele alma ise gidersiniz kullandığınız dilin "error handling" mevzularını incelersiniz (Common Lisp error handling'in ötesine geçer, ve "error" denen sınıfı "condition" dediği sınıfın alt sınıfı kabul eder):

http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html

http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html

http://www-2.cs.cmu.edu/Groups/AI/html/cltl/clm/node312.html


Daha bu liste böyle uzar gider. Ve sonuçta, basit görünen hello world yazma işi, gerçek dünyaya çıkınca bir sürü teferruat getirir. Programcı, bu teferruatı önceden görüp ona göre kodunu yazan adamdır. Ve bu noktada maalesef en basit işler bile kolayca binlerce satıra ulaşır. Pek çok yeni başlayan bu yüzden LISP, Python, C# gibi dilleri çok acayip şekilde avantajlı görür


Sanki Java, C#, Common Lisp, Python kitaplarında "error handling" anlatılmıyor gibi yazmışsınız. Benim okuduğum pek çok metinde, atıyorum adam bir veritabanı bağlantısı açacak, basit bir iş, ilk söylediği şey "aman ha bunu bir deneyin (try), belki veritabanına bir bağlantı açamazsınız (catch), açabileceğinizi varsayarak iş yapmayın" filan. Yanılmıyorsam Java'da idi, bağlantı kodunu try catch olmadan yazmanıza izin vermiyordu filan.

Tekrar tekrar vurgulamakta fayda var, şimdi de konu bir program geliştirirken çıkabilecek hatalara ve bunları ele almaya geldi. Başka dillerle uğraşanların hata ele almakla uğraşmadığını nereden çıkarıyorsunuz?


. Ama sonuçta yazılan kodun nihai aşamalarında bu üst düzey dillerin avantajlarının yadsınamaz derecede önemli olduğu ama hiç birinin maalesef mucize yaratamadığını tecrübe ederler.


Mucize yarattığını iddia eden kim? Burada linki verilen hangi kaynak mucize yarattığını söylüyor?


çalışmaya daha kolay uyum gösteren Python gibi diller tercih edilir. Bu diller için prototip dili denmesinin asıl sebebi budur. Çünkü nihai uygulama çoğu zaman hangi dille yazdığınız önemli olmayacak kadar kompleks olacaktır.


Hemen bir potansiyel yanlış anlamayı düzeltelim, Python için bir prototip dili demek uygun olabilir, Common Lisp için ise prototip dili yakışık almaz. Eğer Python bir prototip dili ise, Common Lisp değildir.


İşte yanlış tam buradadır, vede benim hararetle aman LISP böyledir demeyin dememin esprisi budur. LISP'i bu kadar göğe çıkarırsınız (yada pythonu vs. farketmez) yeni başlayan adam buna kanar ve asıl sorunu çabucak atlar.


Pardon, yeni başlayan biri neye kanar ben onu anlamadım. Burada hiç vermedi isek en 50 kere farklı farklı güzel Common Lisp kaynaklarına, kitaplarına referans verdik. E zaten C, C++, Java, C# için kaynak vermeye gerek yok, elinizi sallasanız bu dillerden biri için kitap, kaynak, öğretici, yığınla örnek proje, vs. bulabilirsiniz. Internet hepimizin, kim kimi engelliyor ki, isteyen gider yahu bu adamlar Common Lisp deyip duruyor, neymiş bu, gideyim araştırayım, deneyimli insanlarla bir yazışayım der, isteyen gider C çalışır, büyük projelerin kodlarını inceler, vs.

Neye kanacak insanlar? Lisp'in makro sistemi güçlüdür, dilin içinde kalarak dili şekillendirebilirsiniz, diğerlerinin "makro" dediği şeyi incelediğinizde bunu anlarsınız dendiğine mi kanacaklar? Yani doğru bir şeye? Ya da Lisp ile DSL (Domain Specific Language - Alana Özgü Dil) geliştirmek daha kolay, bakın kıyaslamalı bir örnek dendiğinde buna mı kanmış olacaklar? Yani doğru bir şeye? Lisp'teki DSL mevzusuna en güzel örneklerden biri LOOP isimli döngü yapısı ve aslında mini DSL'sidir, İngilizce grameri modellenerek çok güzel bir şekilde oturtulmuştur dediğimizde buna mı kanacaklar, yani doğru bir şeye mi kanacaklar? Lisp ile gerçek dünya uygulamalarından örnekler verdiğimizde, buna mı kanacaklar?

http://www.franz.com/success/customer_apps/data_mining/itastory.php3

http://www.itasoftware.com/

http://www.franz.com/success/customer_apps/scheduling/nasa.lhtml

http://www.lispworks.com/products/success.html

http://www.xanalys.com/solutions/linkexplorer.html

http://icb.nasa.gov/swy99win.html

http://www.cliki.net/Application


Bir süre sonra da LISP'ten soğutursunuz, çünkü iş çetrefilleşince LISP'in ona verebileceği bir şey olmaz.


Yine enteresandır, o kadar insan var, yıllar geçmiş Common Lisp'ten soğumamışlar, bir sürü proje geliştirmişler filan, herhalde beyinlerinde bir sorun var, Lisp onlara bir şey vermediği halde uğraştıklarına göre deli divane filan olsalar gerek. Ben gidip onlara "gerçeği" söyleyeyim, boşuna uğraşmasınlar, yazık :)
0
skoylu
Neden ısrarla yanlış yanlış taraflara, yanlış yanlış şeylere çektiğinizi anlamakla güçlük çekiyorum. Tamam, anlatma kabiliyetim kötüdür, ama bu kadarda olacağını sanmıyorum.

Birincisi kimseye "error handling" dersi vermek değil niyetim. O basit hello world yazma işi bile ne kadar karışır gider bunu göstermek. Siz tutuyor, efenim error handling yok mu LISP'te vs. diyorsunuz. Ben hiç LISP'te şu yoktur, o yüzden kötüdür vs. dedim mi? Bakın, tekrar söylüyorum. Sorun dil ve mekanizmalar değildir. Uygulamalar o kadar komplekstirler ki, elinizdeki dilin getirileri çoğu zaman ancak devede kulak kadar size yardımcı olur. Bu yüzden bilhassa üst düzey diller arasında bariz bir avantaj/dezavantaj farkı yoktur. Bir daha yazayım mı? Siz error handling tarafına gidiyorsunuz...

Bu işe ilk başladığımda elimizde 38911 byte free alanı olan BASIC vardı. Bir sonraki aşamada ise Z80 assembly ve 1K RAM. Ardından COBOL, RM-COBOL özelde.. Ege üniversitesinde bir hoca bizi çekti Fortran diye, onunla kastık. Devamında IBM VM/SP üzerinde assembler, PL/I, ALgol gibi bir dizi kodla uğraştık. 50 bilinmeyenli denklemleri çözen kodlar yazıp para kazanıyorduk. IBM PC'ler çıktı geldi. Haliyle GW-BASIC ve MASM. Akabinde C geldi önümüze.. Bir kaç ay sonra LISP bulduk, IBM PC için değil, baya baya bir LISP makinesi olmasa da VMS üzerinde çalışan bir şeydi. Bu VMS daha iyi, pek hoş, pek güzel derken UNIX çıktı geldi. Texas Instruments'in bir sistemiydi. Üzerinde doğal olarak C ve Raima'mıydı neydi vardı bir şey.. Daha sayayım isterseniz, Bir çoğunun adını bile duymadığı dillerde kod yazdık. Binlerce satır. Delikli kartlara fortran kodu basıp 3 pass ile derletip çalıştırmanın zevkini de tattık. Eee, ne mi olmuş yani? Yok bu dillerin birbirinden farkı. Çünkü iş bambaşka bir şey. İş başka bir disiplinde yatıyor. Bu disipline vakıf olduğunuzda herhangi bir dille herhangi bir şekilde işinizi yapıyorsunuz. Hiç bir şey göründüğü gibi değil, hayatta hiç bir uygulama 50 satır ile bitivermiyor. Binlerce satır yazınca da yazdığınız kodun hangi dilde olduğunun bir anlam ve önemi kalmıyor.

Ama ne bileyim nereden nasıl anlıyorsunuz. LISP ile ciddi program yazılmaz diyor muşum.. LISP ile error handling... C ile yazabileceğiniz her şeyi LISP ile, Python ile, BASIC ile, PERL ile vs. uzatında uzatın.. Yazabilirsin. Ve inanın ki toplam satır sayısında da ciddi bir artış bile göremezsiniz. Oynasa oynasa %3 - %5 oynar en fazla..

Ama ev ödevi, iki matiris çarpın gelin diyorsanız iş değişir elbet. Fakat iki matrisi çarpmak için MathLab kullanmadığımızın sebebi ayrı bir topik mevzusu olur, o ayrı..

1950'lerde filan, ben görmedim, bilmiyorum, ama atıyorum bir integral hesabı için özel kod yazılırmış. İlk PC-DOS döneminde de gerçekten iki sayıyı toplamak için özel bir program bulmanız gerekiyordu. İşte böyle bir kullanımlık, basit, dar kapsamda durumlardan ibaret olan kodlar yazılırmış. Bu durumda LISP ile Java kavgası acayip anlamlı. Ama artık sistemler ve genel amaçlı uygulamalar o kadar gelişti ki, böyle bir şey için kod yazmak zaten hammallığın önde giden tarafı oluyor. Yazmaya değecek en basit uygulama bile birden binlerce satıra ulaşıyor ve diller arasında ancak, web tabanlı, script tabanlı, derlenebilen, nesne desteği daha iyi gibi ayrımlar yapılabiliyor. Artık dillerin güçleri o kadar olgunlaştı ki, birini diğerinden daha üstün yapacak hiç bir şey yok nerdeyse.

Kapatmadan tekrar yazayım. LISP diğerlerinden daha kötü değildir. Ama daha iyi hiç değildir. Alın birini vurun ötekine.. İş sizde, algortima adaptasyon, sorun analizi, hatayı koklama vs. gibi yeteneklerinizde. Ötesi hikaye. Gidin bunları öğrenmeye ağırlık verin.

0
sekuiche
buradan cikardigim sonuclar sunlar oluyor beyler.ne kadar dogrudur bilmiyorum -ki zaten akil danismak maksatli yaziyorum.

i. python dili baslangic icin iyidir ama sadece baslangic icin(?) kaputun altinda ter dokmek icin C sarttir -veya C++(?)

ii. lisp ve bu duzeydeki diller her ne kadar iyi de olsalar birer fantazidir yani aslolan C'dir(?) - bi yer de okudugum belgede diyordu ki: omrunuz boyunca lisp kullanmayacak olsaniz dahi ogrenin.zira programciya tecrube katar/yardimci olur -.

iii. her is icin ayri programlama dilleri vardir.bazi diller sirf o bazi isler icin tasarlanmistir - mesela awk - (?) ama C her yerde NR1 konumundadir (?)

iv. C ogrenilecek ilk dil olmaya musaittir.urkmeye gerek yoktur.bazi istisnalar ve ozel teknolojiler haricinde C bana tek basina yeterlidir(?)



soyle bir dusundugum zaman kendimi olaya odakli programci grubuna dahil ediyorum.yukaridaki sorularima/celiskilerime vereceginiz cevaplar, programcilik hayatimda bana cok faydali olacaktir.

ufak bir sey daha yazacagim umarim okursunuz:

- ilk olarak python ogrenmeyi dusunuyordum ve tam baslayacaktim ki bu haber/yorumlar biraz kafami karistirdi.C ile baslamak aklima geldi.ama planlarima gore sirasiyla python-java-perl ve sonunda C ogrenecektim.perl'i de ekledim cunku C'den once biraz tecrube olur diye dusunuyordum.sizler ne dusunursunuz acaba?
not: daha onceden html/javascript/php/sql gibi tecrubelerim var.

---

burada kesiyorum.
herkese olayli gunler...
0
freethings
ürüne odaklanınca, C++ Builder :) yada Delphi
0
Soulblighter
C++ Builder bana da çok şey öğretti. Fakat 'sekuiche' arkadaşımız bence şimdilik ürüne yönelikten ziyade, mantığı öğrenmek için bir ortam kullanmalı. Şöyle Borland'ın eski düzenleyicisini kullanıp, 16 bit'in tozunu bir yutmalı :)
0
Soulblighter
Bana kalırsa C ile öğrenmeye başla. C, dışardan karışık görünen ama aslında çok basit bir dil. Bence C'nin en güçlü olduğu yön, programcı adayına, programlama mantığını aşılayabilmesi. C, herkesi mutlu edebilecek bir dil. Çünkü basit programlar yapmak için de kullanılabilir, çok karmaşık programlar yapmak için de. Bu yüzden C'yi öncelikle basit olarak öğren derim ben. Böylece C'yi öğrenmekten ziyade programlama mantığını öğreneceksin ki bu zaten önemli olan.

Daha sonra ne öğrenmeli? Onu üstadların yorumlarına bırakıyorum. :)
0
Ragnor
Bence python-perl-java üçlüsünden sadece birini öğren ve tavsiyem python. Ondan sonrada C'ye geç. Aslında C'ye başlamak için beklemene gerek yok ama önce python ile başlaman daha iyi olur. Bunun nedeni python ile hızlı program geliştirebilmen. Birçok yerde python için prototip hazırlamak için ideal olduğundan bahseder. Python ile başlarsan hızla öğrenir ve hızla program yazabilirsin. Bu sayede daha kısa sürede python bilginden tatmin olur ve c'ye geçersin. C'de program yazmak (anlamlı birşeyler olmak koşulu ile :)) biraz uzun sürmesi nedeniyle kendini tatmin olmuş hissetmen zaman alabiliyor. İkisini öğrendikten sonrada genel işler için python ama detaylı yada alt seviye işler için C kullanırsın.
0
sekuiche
ben dusundum tasindim ve yorumlari da gozonunde tutarak planimi olusturdum: C ogrenmek icin kasicam.

sebepler:

i. ilk dil olarak C ogrenebilirim.
ii. en fazla 2 yilimi harcasam ortaya urun cikarabilecek hale gelebilirim.
iii. ne de olsa yeterli bilgi birikimi/tecrubem var.
iv. eglenceli olacak :)
v. bir zamanlar (unix yayiliyordu ve ilk fanatikleri vardi o zamanlar...) insanlar ilk dil olarak C ogrenebiliyordu.sonucta basarili olanlar var ve benim eksik yonum yok onlardan!
vi. eski yaptigim planima gore cok daha hizli bir sekilde amaclarima ulasabilirim.cunku C'nin verdigi tecrube ile istersem yeni bir dili daha kolaylikla ogrenebilirim!

yolum acik olsun :)

herkese olayli bir hayat diliyorum...
0
skoylu
C kolaydır, ama sizi sizinle başbaşa bırakır. Sizin için hiç bir şey yapmaz. String'ki en çok kullanılan veri tiplerindendir, C'de tanımlı değildir. Ama C size programcılık disiplinini öğretir. Veri türlerinin ne demek olduğunu anlatır vs. vs.

Daha önemlisi C size bilgiye erişmeyi öğretir. En ufak iş için bile düşünmeyi öğretir. Kendi sizin hiç bir hatanızı telafi etmediği için her adımınzda hatalarınızı nasıl kontrol edeceğinizi anlamayı öğretir. Sistemden verinin nasıl geldiğini, gittiğini öğretir.

2 Yıl sonunda derken, önemli olan iki yıl boyunca neler yaptığınız. BU iki yılın 18 ayını KDeveleop veya ne bileyim GLADE ile dialog çizmekle harcarsanız boşa harcamış olursunuz. Önceliğiniz elinizle kodları yazmak olmalı. Bu yüzden mesela bir proxy/server yazmakla işe başlayın, önceliği GUI tabanlı işlere vermeyin..


0
sekuiche
grafikten nefret ediyorum.
0
MC
C bir prosedürel bir programlama dilidir eğer pascal veya benzeri bir programlama dili biliyorsanız C öğrenmek size çok da zor gelmiyecektir. Terside doğru tabi C biliyorsanız pascal öğrenmek zor olmıyacaktır.

Benzer şekilde nesne yönelimli herhangi bir programlama dilini biliyorsanız ( C++, Java ... ) bir diğerini öğrenmek zor olmıyacaktır.

Önemli olan dillerin avantajlarını ve dezavantajlarını mümkün olduğunca bilmek ve projenize uygun dili seçmektir. Unutulmaması gereken programlama dillerinin sadece araç olduğudur. Programcılık içinize işlemişse zaten projenizi geliştirdikçe seçmiş olduğunuz dilde doğal olarak ustalışırsınız.

"Olay odaklı" veya "ürün odaklı" programcı olarak bakmak bana doğru gelmiyor. Uzmanlaştığınız konular olmalı (programlama dili değil, dil ile çözmeye çalıştığınız projede) ve bunları en ufak detayına kadar bilmelisiniz ama doğal olarak her şeyi bilemezsiniz. Bazı konularıda yüksek seviyeli araçlara bırakmalısınız ki uzman olduğunuz konularda çalışmaya çabuk geri dönebilesiniz.
0
skoylu
Uzmanlaştığınız konular olmalı (programlama dili değil, dil ile çözmeye çalıştığınız projede) ve bunları en ufak detayına kadar bilmelisiniz ama doğal olarak her şeyi bilemezsiniz.

Pek katılmıyorum. Aslen hiç bir şeyi bilmemelisiniz. Sadece gerektiğinde nerede bulacağınızı bilmelisiniz. Bulduğunuz bilgileri işlemeyi bilmelisiniz. 20 yıldır C kullanırım, hala printf'i doğru düzgün bilmem, typedef struct ... union... nasıl yazılır bilmem. Gerektiğinde açar bakarım, man vs. herneyse.

Çok bilmek çok yanılmak demektir. Bu yüzden bilhassa programlama sürecinde çok bildiğini düşünmek gaflet olur..

Bazı konularıda yüksek seviyeli araçlara bırakmalısınız ki uzman olduğunuz konularda çalışmaya çabuk geri dönebilesiniz.

Bunada katılmıyorum. Özel bir gerek yoksa herşeyi yüksek seviyeli araçlara, ve mümkün olduğu kadar sistem çağrıları, standart API'lere bırakmalısınız. Kernele kod yazarken bile, ilk tercih bottom-half'leri yapmak olmalıdır. Ama bu sizin o konuları bilmiyor olmanızı mazur göstermez. Konuları gayet iyi bileceksiniz. Daha doğrusu ne nereden gelir, ne olur biter bilmeniz gerekir. Bunun için yapacağınız iş için hangi mekanizmalar gerekli, buralarda neler dönüyor vs. derhal seri bir teftiş yapmanız faydalı olur.

Dün itibarıyla yaşadığımız bir örnek. Bir frontend yazıyoruz. Porta gelenleri GUI'ye çıkarıyor. Bloke olmaması için ASYNC I/O kullandık doğal olarak. SIGIO'yu yakaladık. Ama bazen datanın ezildiğini, uygulamanın tam zamanında cevap veremediğini gördük. Bu durum OOB data I/O yapılmıyorsa başa çokca gelecektir. Eskiden bildiğim şekilde SIGIO yerine SIGRTMIN istedik. Sorun kalmadı. İşte hiç ummadığınız yerde böyle acayip bir durum karşınıza çıkar gelir. Bu Linux'a özgü değildir. Windows'un WASYN çağrıları da benzer bir takım acayiplikler taşır.Normal koşullarda, bu uygulamaya girişmeden önce bu konuları nazara almış olmamız lazımdı.

Herşeyi bilmeniz gerekiyor. Kıvırsanızda bunlardan kaçamazsınız, güdük bir program yazmak istemiyorsanız elbet. Ama herşeyi biliyor olmak demek temelde neyi nerde bulacağınızı biliyor, bulduğunuzu da kullanabiliyor olmanız demek olmalı. Ama herşeyi biliyor olmanız demek, herşeyi siz yazacaksınız anlamına asla gelmez. Hatta, öncelik herşeyi yüksek seviyeli çağrılarla yapmaya verilmeli..
0
inoxes
elindeki projeyi seni daha az yorarak ve verimden kaybettirmeden bitirmeni saglayacak bir arac mevcutsa onu kullanmak bence en mantiklisi. bu durum gore yeri gelir c++ olur yeri gelir java olur yeri gelir delphi olur. benim tarafimda implementasyon ayri programcilik ayri kavramlar. ama c++ kullanmiyorum diye bos adam oluyorsam dahada bir sey demiyorum.
Görüş belirtmek için giriş yapın...

İlgili Yazılar

Vikipedi: Silinmeye aday maddeler ve Fazlamesai.net

butch

Bir sebeple Wikipedia fazlamesai.net maddesine göz atmak istedim az önce. Silindiğini biliyordum ancak birçok kullanıcının katkısıyla oluşturulmuş bu maddeye sistemin derinliklerinde de olsa ulaşabileceğimi umuyordum. Fakat öyle olmadı. Bu vesile ile de iki konuyu tartışmaya açmak istiyorum.

Kablosuz Yaşam

butch

Fazlamesai aşkına!

sundance

Fazlamesai.net ekibi iki gündür Bilgi´de. Çanakkale´den ve Ankara´dan iki fazlamesai üyesi dışında da gelenimiz gidenimiz yok.

Akşama kadar altı saat var, İstanbul´da olup da gelmeyenlere yazıklar olsun, Fazlamesai t-shirtleri var, Linux şapkaları var, dahası biz varız dedik yalan olmuş demek ki :(

Ek: Fazlamesai ekibi beklemede... (Soldan sağa: Butch, Erdoğan(Linux34), Esse, Larweda, FZ, Sundance)

Buffer overflowlar öldü ! Yaşasın Theo ;)

sundance

BSD camiasının asi çocuğu, OpenBSD'nin babası Theo de Raadt CanSecWest güvenlik konvansiyonunda yaptığı açıklama ile Open BSD'nin 1 Mayıs'da çıkacak yeni sürümünde, yaklaşık otuz yıldır işletim sistemlerinin baş belası buffer overflow mevzuunu tamamen çözeceklerini açıkladı. Bu konuda yine de mütevaziliği bırakmayan Theo, tamamen mümkün değil hale getiremeseler bile yeni güvenlik katmanı sayesinde buffer overflowların uygulanmasını imkansıza yakın hale getirdiklerini söylüyor.

Kış Geldi

butch