Merhaba,
Nacizane bir yorum da ben yapayım; veritabanı içerisinde başka hiç bir
çaremin kalmadığı durumlar haricinde asla mantık içeren bir kod
bulunmasına izin vermiyorum. Tabi ki yazılım gibi bir alanda genelleme
yapmak çok yanlış, eminim buna mecbur kalınan bir çok notka da vardır.
Özellikle çok büyük miktarda veri söz konusu olduğu zaman firmadaki
oracle üstadı arkadaşlara işi devredip, onların çözüme müdahale etmesine
izin veriyorum. Ama %99 oranında çok katmanlı kurumsal yazılımlar
geliştirilen bir firmada çalışan birisi olarak, yine çok büyük yüzde ile
db seviyesinde bu tarz teknolojileri kullanmamaktan yanayız. Nedenlerine
uzun uzun girmek istemiyorum, bambaşka bir tartışma konusu; ama temel
olarak java ve db bağımsızlığına yaptığımız yatırımın bize iş modeli ve
dolayısı ile stratejik avantaj olarak çok ciddi geri dönüşleri var. Yani
DB den bağımsız olmak zorunda olan multi milyon dolarlık bir yatırım söz
konusu, ve ben bazı durumlarda işi ne kadar kolaylaştırsa da bahsi geçen
türde çözümleri kullanamam.
Ha tam bu tarz bir şeye ne zaman ihtiyacım oldu? Bir oracle forms
uygulamasının web servislerini çağırması gerektiğinde, web servisi de
yapı olarak ssl falan kullanan bir parça karmaşık bir şey olduğu için
oracle db içindeki jvm ile web servisi çağıran bir java programcığı
yazdım. Tabi orada da bir sürü sorun çıktı , ama sonuç olarak kişisel
olarak çok faydalı bir deneyim olabileceğine katılsam da, oldukça
uçlarda bir proje olur diye düşünmekeyim. Tabi gezegen geniş; mutlaka
kullanacak birisi de çıkar, ama harcanacak eforu bir iki katman yukarı
çekerek daha geniş kitlelere hitap eden, ve kullanılması daha yaygın
olacak bir proje tercih edilebilir. O da paradan puldan ziyade,
kullanıcı kitleri oluşan bir proje kolay kolay ölmez şeklinde bir
düşünceden dolayı
İyi çalışmalar
Şeref Arıkan
Emre Sevinç wrote:
Volkan YAZICI wrote:
Merhaba,
Aranızda daha önceden PostgreSQL kullanmış olanlar varsa, bunlar
PostgreSQL tarafından bir çok prosedürel dilin desteklendiğini
hatırlyacaktır. PL/pgSQL, PL/perl, PL/python, PL/ruby, PL/php, PL/R,
PL/tcl, PL/sh, PL/java, ... Bu liste böyle uzayıp gider. Sizin de
tahmin edeceğiniz gibi ben bu listeye bir de PL/scheme (ya da PL/lisp)
eklemek istiyorum. Bu noktada kolları sıvamadan önce bir kamuoyu
yoklaması ve araştırmasının yararlı olabileceğini düşündüm.
[1] Durduk yere zaten var olan onlarca prosedürel dil arasına bir tane
daha eklemenin ve bunun bakımı ile uğraşmanın hiçbir anlamı yok. Bu
noktada eğer bir şey eklenecekse bunun öyle ya da böyle daha önceden
kapatılmayan bi boşluğu dolduruyor olması gerek.
Bence, Lisp programlama dili tarafından sunulan fonksiyonel
programlama ve rekürsif işlem kolaylığının, esnekliğinin, veri
işlemede çok başarılı bir şekilde kullanılabilir. Konu hakkında
sizin fikirleriniz nelerdir? Sizce gerçekten Lisp sözdizimi
yukarıda bahsi geçen prosedürel dillere ile kıyaslandığında veri
işlemede bunca çabaya değebilecek bir artı sağlar mı? Böyle bir
özelliği "Evet ben kullanırım!", "Şunu şunu yapan adamlar kesin
kullanır." diyebilecek olanımız var mı?
Veritabani isleri ile yogun olarak ugrasiyorum ama MS teknolojileri
ile. Yillardir MS SQL Server
kullaniyorum. MS SQL Server'da PostgreSQL'e benzer bir durum olusmaya
basladi. Simdiye
dek sadece T-SQL denen bir dil ile stored procedure yazilabilirken
artik yavas yavas C#
dili ile yazma destegi de geliyor.
Kendi durumumu düsünüyorum, mesela C# ile stored procedure yazmak
ister miydim,
bu ne avantaj saglardi?
Birincisi homojenlik: Uygulamami C# ile yaziyorum. Uygulamamin
kullanacagi veritabani
kodunu da C# ile yazmaya baslarsam zirt pirt farkli mantaliteler ve
sözdizimleri
arasinda gidip gelmem gerekmez.
Ikincisi: Framework, yani .NET ve C# ile gelen binlerce "class
library". String islemlerinden
tutun XML konusuna ve baska pek cok seye dair her zaman elimin altinda
olan
islevselligin artik veritabaninin icinde de ayni sekilde kullaniliyor
olmasi güzel bir nokta olur.
Ucüncüsü: Nesneye yönelik programlama mantalitesini ve algoritmik
karmasikligi
yine daha alisik oldugum bir dille ifade edebilme gücü.
Simdi bu baglamda Lisp'i ve hic kullanmamis biri olarak PostgreSQL'i
düsünmeye calisiyorum.
Hangi uygulamalarda kullanilacak ne tür prosedürlerde Lisp'in ifade
gücüne
ihtiyac duyulacak?
Stored procedure icinde Lisp tarzi makro tanimlayip kullanmak güzel
olur muydu,
bence olurdu. Daha fazlasi yapilabilir mi? Evet, mesela konu dil ifade
gücü
vermekse Haskell ve OCaml dillerindeki bazi güclü dil yapilarini Lisp
tarzinda
sunan Qi gibi bir dilin de özelliklerini barindiran karma bir
veritabani programlama
dili bazi durumlarda isleri muazzam bir esneklikte halletmeye imkan
verebilirdi.
Yine ayni noktaya takiliyoruz: Bu muazzam güce su anda PostgreSQL
kullananlarin
kacta kaci ihtiyac duyar. Diyelim ki bir kismi duyar pekiyi zaten
tasarlamis olduklari
bir sistemi oturup bu yeni dili kullanarak yazarlar mi? Maliyeti yüksek.
[2] Yukarıda bahsettiğim programlama dillerine baktığınızda, hepsi tek
bir noktadan kontrol ediliyor. (Onlarca değil, - ana olarak - tek
bir Perl ya da Python yorumlayıcısı var.) Bu da ilgili prosedürel
dilin geliştiricilerine büyük bir kolaylık sağlıyor. Sadece o
implementasyon için gerekli kodları yazıyorlar. Ama aynı şeyi Scheme
ya da Common Lisp için diyemiyoruz. Bu noktada tavsiye olarak hangi
yorumlayıcının kullanılmasını tavsiye edersiniz?
[Bir de unutmadan, prosedürel veri işlemede yapılan iş normal bir
programda olduğu kadar karmaşık değildir.
Sanirim yukarida kast edilen yani "prosedürel" derken, "stored
procedure" mi kast ediliyor?
Eger öyle ise benim daha önce yazdiklarim akla geliyor. O kadar
karmasik bir sey degilse
o zaman basa cikilmasi gereken bir karmasiklik yok. Eger bu yoksa,
neyi cözmeye
calisiyoruz sorusu tekrar gündeme gelir.
Bu önemli cünkü gelistirilen seyin kullanimini etkiler. Eger pek cok
veritabani
gelistiricisi bunu kullanmazsa o zaman dogru dürüst geribesleme
gelmez. Yapilabildigi
gösterilmis olur ama o sekilde kalir. "Proof of concept" kabilinden
bir sey olur yani.
Istenen bu mudur? Yoksa daha fazlasi mi?
Bu yüzden Scheme'i seçmek
bana daha mantıklı geliyor. (Bu da ayrıca tartışılabilir. Ama bu
satırdan sonraki yazılanlarda, Scheme'i baz alarak ilerleyeceğim.)]
Yukarida "framework"e deginmistim. Bilmedigim icin sorayim, ben simdi
PostgreSQL stored
procedure'larini Perl ile yazacak olsam, istedigim CPAN modülünü bunun
icinden kullanabiliyor
muyum? Eger öyle ise cok saglam islevsellik zaten elimin altinda
demektir, dilin avantajlarina
ek olarak.
Benzer sey secilecek Lisp icin de söylenebilir. Bu implement
edildiginde o dilin cevresini
olusturan islev kütüphaneleri de bir parcasi olacak mi? Bu durumda
Scheme mi yoksa CL mi?
Birinin avantaji ne zaman dezavantaja dönüsür?
Bu noktada bence öyle bir yorumlayıcı şeçilmeli ki, gelişimi aktif
olarak devam ediyor (ve edecek) olmalı. Ayrıca her şeyden önemlisi,
bir çok sistemde kurulu olarak bulunma olasılığı çok yüksek olmalı.
Bu kriterleri göz önüne aldığımda aklıma Guile'dan başka çözüm
gelmiyor. Sizin düşünceleriniz nelerdir?
Performansi nasil? PostgreSQL icine gömüldügünde diger dillere göre
performansi nasil olur?
Bunu etkileyen faktörler neler olur?
[3] Kimseyi korkutmak istemem ama... Böyle bir iş için taşın altına
elini koyabilecek başkaları da var mı? (Kısmen ileri düzey bir C
bilgisi şart, bunun dışında Lisp/Scheme ya da PostgreSQL biliyor
olmasına bile gerek yok.)
Sanırım V0 hızı için bu kadar soru yeterli.
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.4/399 - Release Date: 7/25/2006
_______________________________________________
cs-lisp mailing list
cs-lisp@cs.bilgi.edu.tr
http://church.cs.bilgi.edu.tr/lcg
http://cs.bilgi.edu.tr/mailman/listinfo/cs-lisp
