Ruby Nesnelerine Kalıcılığı Öğretmek

0
anonim
anonim
15 Mayıs 2005 , 1 dakika okuma süresi
Dünyada en çok sevilen programlama dili olduğu söylenen Ruby ile sunucu taraflı uygulama geliştirmek için elimizde RoR gibi kullanması çok kolay ve işlevsel bir arayüz var.

Peki ya masaüstü uygulamalarımız için Hibernate benzeri kalıcık araçları karşısında Ruby'de alternatif yok mu?

Tabii ki var. Og (Object Graph) ile Ruby nesnelerine nasıl kalıcı olacaklarını öğretmek çok kolay olsa da, bu makale ile daha kolay olacak.
yazilim
12
Linkedin Facebook Twitter Google plus

Görüşler

eof
0
eof
Rails'de kalıcılık aracı olan ActiveRecord'u Rails olmadan da uygulamalarınızda kullabilirsiniz.

How To Use Active Record Outside Rails [wiki.rubyonrails.com]
bm
0
bm
Propaganda firsati varmis, FZcigim guzel bir orta yapmissin dokunmasam olmazdi. Ne zamandir firsat kolluyordum.

Bu tip isler nasil yapilir (CLOS icin Meta-object Protokolu kullanilarak genel 'persistent class' ornegi)

Andreas Paepcke. User-Level Language Crafting - Introducing the CLOS Metaobject Protocol. In Andreas Paepcke, editor, Object-Oriented Programming: The CLOS Perspective. MIT Press, 1993.

http://www-db.stanford.edu/~paepcke/shared-documents/mopintro.ps

(Ozet, biz aletleri verelim de kalicilik yapilan islerden sadece biri olsun). Ruby sevenler, yeni yetme putlara tapmayin, Lisp sizi bekliyor.

(Propaganda oldugunu soylemistim, yarin obur gun ben de Ruby iyi seydir dersem yuzume vurmayin.)
FZ
0
FZ
Hmm, bu kitap Bilgi'nin kitaplığında görünmüyor! (*) Hemen sipariş verelim de Türkiye'deki Common Lisp'e en çok destek veren üniversite kütüphanesi buna devam etsin ;-)

Bu arada gördüğüm kadarı ile propaganda mevsimi açılmış, şahsen bundan hiç rahatsız değilim hatta diyorum ki 2005-2006 döneminde neden çok acayip bir Ruby kitabı yayınlanmasın Türkiye'de ve neden bu kitabın satışları yine Türkçe bir Common Lisp kitabı ile yarışmasın? (İzin koparabilsek ve basacak yayınevi bulsak Practical Common Lisp'e talip olurdum ya neyse... ;-)

* http://library.bilgi.edu.tr/
FZ
0
FZ
Chaitin'in şu lafını çok seviyor ve sık sık hatırlıyorum:

"So why do I love LISP?! Well, the answer is, because it's really set theory, and all mathematicians love set theory!" (*)

"O halde neden LISP'i seviyorum? Cevabı şu, çünkü Lisp küme teorisidir ve bütün matematikçiler küme teorisini sever!"

Benim sorum: Neden ülkemizdeki matematik (ve matematik müh.) bölümlerinde Lisp gösterilmiyor programlama dili olarak? (Mathematica, MatLAB, vs. iyi güzel tamam ama neden Lisp gösterilmiyor!?)

* http://www.cs.auckland.ac.nz/CDMTCS/chaitin/lisp.html

bm
0
bm
Kitabi ben de bilmiyorum. Toplanmis makaleler olsa gerek. Paepcke'nin makalesi iyi, okunmaya deger (verdigim URL'den indirebilirsiniz). Ozellikle AMOP kitabiyla gayet iyi gider. AMOP kitabinin bir kismi da acik:

http://www.lisp.org/mop/index.html

Tercume/kitap isine gelince, malesef bu konuda Apress ile konusmak lazim. Belki zamaninda uyanilsaydi (uyansaydim) Siebel ile anlasilip Turkce haklari aliabilirdi ve Turkcesi tamamen webe acik PDF sekline getirilirdi. Benim tercihim isleri dijital ortamda ve acik tutmak. Yalniz cok da hayiflanmayalim, su ana kadar ilgilenenlerin hepsi Ingilizce biliyor gozukuyorlar, digerleri icin de belki bir sebep olur yabanci dillerini ilerletirler. Tamamen Turkce'ye donmek icin bir iki baska kitabi ve belki en onemlisi Hyeprspec'i[1] cevirmemiz lazim. Bunlardan sonuncusu kotu yapilacagina hic yapilmamasi gereken birsey, iyi yapmak da kadro ve bilgi meselesi (maliyet demiyorum, paradan dolayi tikanmadik hic henuz, unutma). Hevesli insanlar eger devam edip bilgili hale gelirlerse ve arzu ederlerse yapilir.

Propagandist sapkami kaybettim, bir de baska birsey soyleyeyim: Common Lisp 'en iyisi', 'en ileri', 'en birsey' oldugu icin ogrenilmemeli -- bunlar dogru olmayabilir. Ondan ve kulturunden bi-haber olmak, o tarzi bilmemek (ESR'in da dedigi gibi) onemli bir eksiklik oldugu icin ogrenilmeli. Benim derdim herkesi lispci yapmak degil. Hakikaten hevesli ve ciddi arastirmaya yatkin insanlarin sadece hasbelkader dogmus olduklari memlekette bir bilgisayar bilimi gecmisi olmamasi yuzunden derinden pekcok seyi etkileyen bir dilden, ve zamaninda (belki hala) onemli beyinleri etrafina toplamis bir kulturden habersiz kalmamalarini istiyorum. Buna 80lerde 90larda memleketteki imkanlar musait degildi. Simdi musait. (Haa bir de benim kolayima geliyor, o da var!).

[1] http://www.lispworks.com/documentation/HyperSpec/Front/index.htm
veya apt-get install hyperspec
ahmetaa
0
ahmetaa
Ruby iyi guzel hos ama bir haftada 4 tane baslik vermek (ustelik haberler aslinda eski ya da harci alem seyler) biraz kabak tadi vermiyor mu?
FZ
0
FZ
Yaşasın pozitif ayrımcılık! Java'cılar pek hoşlanmıyor bundan galiba? ;-)

Şaka bir yana, bir de şöyle düşünsek: En az bir (ve tahminen daha çok) FM üyesi var ki Ruby'den müthiş etkilenmiş, heyecanlanmış ve buraya yazacak, küçük de olsa haber, yazı, vs. çevirecek kadar motive olmuş; bu heyecana kayıtsız kalmalı mıyız?

En azından dil savaşları tanrı var mı yok mu ya da evrim var mı yok mu tartışmasından daha eğlenceli.
ahmetaa
0
ahmetaa
Eh hedef java olunca biraz sesimi yukselttim (Ruby programcilari nedense JavaBlogs sitesinde bir ara epey cirit atmisti. firtina gibi, esti ve gecti..).
Haklisin FZ, belki biraz hizlica ve dusunmeden yazdim yaziyi.. gozlemim su ki, bilgsayar dilleri ya da teknolojilerin birbirlerine karsi olan ustunlugu ne yazik ki cogu zaman "hello world" turu uygulamalar, satir sayisi, ya da yarim yamalak bir kac fikir ya da uygulama uzerine gosterilmeye calisilir. Oysa isler cogu zaman gorundugunden cok daha karisiktir. Her arac her probleme uymaz, hic bir teknoloji de aslinda sihirli degnek olmaz.. Ornegin, O/R mapping. Her seye deva olmadigi gibi sadece iki tip veri tabanina basit ekleme-guncellemeden ibaret degildir. Ornegin varolan bir banka veri tabanini O/R yapiya donusturme isinin yuz astarindan pahaliya gelebilir. Ya da kullandiginiza arac sizi Oracle ile yari yolda birkabilir.
Arkadasimizin heyecanina saygi duyuyorum.. Ama yarin oburgun biri cikar da bak Python'da da bu var, iste su makale.., aha Java'da IBatis var, daha iyisini yapar diye birbirini yiyebilir ona gore ;)
ttk
0
ttk
Sahi yahu Python da var netekim :)
Hem bir de Lisp öğrenecektim sözde.
Biraz Lisp'i söküp ortalığı karıştırsaydık iyi olacaktı, söz bir gün sökersem bunu yapmaya çalışacağımdır.

Bu arada Python iyidir haaa :)
FZ
0
FZ
Şimdi tabii ki gerçek hayatta (!) işler o kadar basit değil, basit ekle çıkar, güncelle mevzularının ötesinde şeyler var, aynı anda birçok programcının çalıştığı çok büyük, kurumsal projeler var, var da var... doğru ancak şu noktayı atlamayalım, bir işi ne kadar az sayıda satırla, ne kadar az kod yazarak yaparsam benim için o kadar iyi! Vakti zamanında SQL fikri ortaya atıldığında pek çok böyyük bilgisayarcı gülmüş dalga geçmişti, olur mu öyle dil yahu, bilgisayara neyi nasıl yapacağını adım adım anlatman gerekir, bu incelikli bir iştir, var mı öyle bir iki satırda bir sürü tablodan veri tarayıp bunları birleştirmek, vs. Oturacaksın prosedürel ve karmaşık algoritmalar, optimizasyonlar yapacaksın, vs. 2005 yılında baktığımızda ise SQL fikri ile dalga geçen bilgisayarcıların adını bilmiyoruz ama veritabanı sorgulama dendi mi şartlı refleks olarak hemen herkesin SQL diline göndermede bulunduğunu biliyoruz, bu çok önemli bir nokta!

Bu bakımdan ne kadar az yazarak ne kadar çok iş halledebiliyorsak o kadar iyi derim ve piyasanın (!) desteklediği yaklaşımlara alternatif olan şeylere de mutlaka göz atmaya, anlamaya çalışırım. Unutmayalım ki Galileo zamanında da bir çoğunluk vardı ve bugün biz o çoğunluğa bakıp, allah allah neden öyle düşünmüşler ki diyoruz. Şunu da unutmamak lazım, popülarite her şey mi demek? Birileri bir şeylere yatırım yapıyor, yani Microsoft olmasa VB'nin esamesi okunur muydu? Su gibi para akıtılıp desteklenmese sadece camia desteği ile Java bugün bulunduğu noktada olur muydu, vs. vs. Gerçekten de çoğunluğun rasyonel davrandığından ve en iyiyi seçtiğinden emin olabilir miyiz? 1000 şirket bunu seçti o zaman en iyisi, en pratiği bu olmalı cümlesini söylerken biraz dikkatli olmak bize çok mu zarar verir?

Basit, Hello World türü uygulamalara gelince, bakın mesela burada Lisp'ten bahsederken, Common Lisp filan derken hep Practical Common Lisp diye bir kitaptan örnek veriyoruz ki yazarı BEA'da da çalışmış (çalışan?) sağlam bir Java programcısı aynı zamanda. Bu adamın kitabındaki 3. bölüme bakın, giriş örneği olarak verdiği şey Hello World mü yoksa ötesi mi, bunu bir inceleyin:

http://www.gigamonkeys.com/book/

Bu örneği verdim çünkü görüldüğü gibi aksi örnekler de mevcut, herkes öyle HEllo World örneği basitliğinde örnekler vermiyor.
ahmetaa
0
ahmetaa
Bu konuda cok hemfikir degiliz. Oncelikle SQL, SQL cok ust seviye, ve kendi problem uzayi icin olduka iyi bir cozum. Yani ben SQL'e camur atanladan degilim. Ama SQL kodunun test edilebilirligi ya da nesneye yonelimli bir disipline uygulanabilirligi oldukca dusuk. o nedenle bugun yazilim kodu icinde SQL kullanimindan, mumkun olan yerlerde kaciniyorum. Neyse, konu aslinda o degil. asil farkli dusundugum nokta su cumleniz:
"doğru ancak şu noktayı atlamayalım, bir işi ne kadar az sayıda satırla, ne kadar az kod yazarak yaparsam benim için o kadar iyi! "
Kesinlikle katilmiyorum. Bu cumle ancak kisa komut satiri, script turu yazilimlar, tek basina gelistirilen projeler ya da bir kere yazilip bakimi yapilmasi gerekmeyen projeler icin mantikli. Ne yazikki bu saydigim alanlar yazilim pazarinin belki %1'ini olusturur. kodun anlasilirligi, test edilebilirligi ya da genisleyebilirligi her zaman kodun boyutundan once gelir. Ve bu saydiim seyler genellikle kod boyutunu arttirici yan etkilere sahiptir (her zaman degil).
Dillerin populerliginin dilin asil gucunden once degerlendirildigine de katiliyorum, yani bir yerlerde tozlanmis ya da bir elin parmaklari kadar akademisyen tarafindan kullaniln VB ya da Java'dan cok daha yetenekli diller vardir. Ama bu gercekleri degistirmiyor. VB'ye bir sey diyemem ama Java benim icin "yeterince" iyi. Bir teknoloji yeterince iyi ise ve milyarlarca dolarlik bir pazara sahipse, nedne takip etmeyeyim? ben akademisyen de degilim, yani oturup atiyorum Ruby ya da Lisp ile kasmam bana verimlilik acisindan bir sey kazandirmiyor ki? Adam gibi IDE yok, her konuda kutuphane bulamazsin, ya da elindeki kutuphaneler her problemini cozmez.. ne yapayim ayni isi 100 satir degil 50 satirda yazmissa? Getter-Setter yoklugu ya da Casting'in varligi cok mu onemli? Checked Exceptions ya da Operator Overloading yoklugu zararli mi? Hayir bunlarin hepsi zamaninda dusunulmus ve kodun kotuye kullanimini engellemek icin yerine gore kod boyutunda fedakarlik edilerek tasarlanmis. Hem IDE'ler artik bu isleri yillardir otomatik yapiyor, benim icin try-catch blogu yazmak iki tusa basmaktan obaret, 10 tane getter setter metodu olusturmak icin Alt+Insert ve ok tuslarina bir kac kere basmam yeterli. kisa bir projeyi bit Python ya da Ruby programcisi ile ayni hizda, Buyuk bir projeyi ise daha hizli yazilabilecegini iddia ederim. eger yazilan kod adam gibi anlasilir degilse ya da testi yapilmamisa bence kodun kisa olmasi rahmet degil, lanettir..
Lisp konusunda bir sey diyemem. Dilin guclu ve farkli oldugunu biliyorum ama detaylarini bilmiyorum. ama akademik dunya haric kullaniminin az oldugunu biliyorum (ne yazik ki), bu benim icin onemli negatif bir nokta..
bm
0
bm
Hayat kazanma baglaminda dediginiz dogru. Isinizi en rahat nasil yapacaksaniz, yahut secme sanisiniz olmayan parametreler dahilinde isinizi en verimli nasil yapabilecekseniz oyle yapmaniz en akilci yol. Bu bakimdanm analizinize katiliyorum.

Katilmadigim nokta su:

Adam gibi IDE yok, her konuda kutuphane bulamazsin, ya da elindeki kutuphaneler her problemini cozmez.. ne yapayim ayni isi 100 satir degil 50 satirda yazmissa?

Adam gibi IDE konusunu bir tarafa birakalim, 'her konuda kutuphane bulamazsin' ifadesindeki gizli anlami dusunelim. Kutuphane bulunabilen konular insanlarin evvelce dusundugu, cozdugu, uzerinde mutabakat olan ve/veya stadart koyucuyu tatmin eden bir ortak kullanim tarzinin olgunlastigi konular. Alanimiz bunlardan ibaret degil. Mesele 100 satiri 50 satira indirmek degil, yepyeni bir alanda dili probleme uydurma kabiliyetine sahip olmak, kimsenin gitmedigi yerlere el yordamiyla giderken deli gomlegine benzer birsey giymemis olmak. Madalyonun obur yuzundeki dusunce tarzi bu.

Hayir bunlarin hepsi zamaninda dusunulmus ve kodun kotuye kullanimini engellemek icin yerine gore kod boyutunda fedakarlik edilerek tasarlanmis.

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
Görüş belirtmek için giriş yapın...

İlgili Yazılar

Unreal'i Yapan Adam Programlama Dillerinin Geleceğini Anlatıyor
FZ
6 Şubat 2006, 1 dakika okuma süresi

Epic Games'ten Tim Sweeney, SIGPLAN ve SIGACT tarafından 33.sü düzenlenen Programlama Dillerinin İlkeleri Sempozyumunda The next mainstream programming language: a game developer's perspective başlıklı bir konuşma gerçekleştirdi.

Imposter v0.3
butch
4 Nisan 2005, 1 dakika okuma süresi

Gürer Özen tarafından geliştirilen Imposter 0.3 sürümüne ulaştı. OpenOffice.org Impress sunumlarını OpenOffice.org olmaksızın görüntülemeyi sağlayan Imposter'i edinmek için buraya.

Quantum bilgisayarlar için programlama dili...
lalapoo
6 Eylül 2001, 1 dakika okuma süresi

Bilim Teknik ya da herhangi bir bilgisayar dergisinde mutlaka quantum bilgisayarlarla ilgili bir yazı okumuş bir fikir sahibi olmuşuzdur.

Mesela bit kavramı yerine Qubitlerin kullanıldığı,şimdiki bilgisayarlardan 1,000,000,000 kez daha hızlı olacağı, çok daha az enerji harcayacağı ve bunun gibi daha birçok şey.Ama bütün bu bilgiler havada duruyor ve quantum bilgisayar kavramı bizim için soyut olmaktan öteye geçemiyor.Bu yetmezmiş gibi şu sıralarda quantum bilgisayarlar için bir de programlama dili geliştiriliyor.

Quantum Computation Language

typo3okulu.com
anonim
16 Temmuz 2006, 1 dakika okuma süresi

Typo3'yi Türk kullanıcılarına tanıtmak ve kullanmalarına yardımcı olmak amacıyla typo3okulu.com sitesi açıldı.

`Hacker´lar ve Ressamlar
FZ
15 Mayıs 2003, 2 dakika okuma süresi

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

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