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.
--
Emre Sevinç
eMBA Yazılım Geliştirme
İstanbul Bilgi Üniversitesi
_______________________________________________
cs-lisp mailing list
[email protected]
http://church.cs.bilgi.edu.tr/lcg
http://cs.bilgi.edu.tr/mailman/listinfo/cs-lisp
