standart kutuphanenin bu sekil calismasina (yani tum dosyanin once bellege yuklenmesi) sasirdim dogrusu. een basit kutuhaneler bile byte-buffer ve stream uzerinden calisirken hele.. atlanilan bir nokta mi var acaba?

bence genel dilbilgisi yapisina pek uymuyor. Soru eki diyoruz ama aslinda bu ek ayri yazim kurali nedeniyle kok oluyor, tam kok de diyemiyoruz cunku olusumu kendinden onceki kelimeye gore degisiyor. Eger pasa pasa bitisik yazilsaydi soru koku gibi bir tuhaflikla ugrasmazdik.. diger turk dillerinde ayri yazilmadigini saniyorum, detayli bilgisi olan varsa duzeltebilir. Turkce uzmani degilim, ama neden ayri yazildigina dair iki teorim var, 1- bu ek onceden "imek" fiiline ekleniyormus ama sonradan kaybolmus ama ayri yazilmaya devam edilmis... (tipki isme ya da fiillere eklenen imek ekleri gibi, kalem imis -> kalemmis, ama bu durumda ayri yazim artik cok ender kullaniliyor). 2- soylenis sirasinda vurgu soru eki uzerinde oldugundan ayri soyleniyormus hissi verdigi icin ayrilmis..

Soru ekinin ayri yazilmasini Turkiye Turkcesinin zayifliklarindan birisi olarak goruyorum.. keske soru ekleri bitisik yazilasydi.

belki. ama Google'nin satin aldigi bir urunun ikincil oneme sahip bir ozelligini haber yapmak ta cok onemli olmasa gerek. Ruby heveslisi arkadaslar'i elbetteki anlamak gerek ama bu kadar heyecana gerek yok ;)

Sadece bir duzeltme, Ruby scriot desteginin Google ile pek iliskisi yok, bu sirket Google tarafindan yakin zamanda satin alindi o kadar.

Ben de yukarıdaki ifadeye gülüp geçerim çünkü o ifade çok daha temel bir meselenin ıskalanmasıdır. Kaynak kod uzunluğundan çok daha önemli bir nokta var. Problem alanının terimleri ile düşünmek. Nesne modelleme yapan pek çok deneyimli ekibin aslında farklı alışkanlıkarı buna dayattıkları ve zorlandıkları haller çok şaşırtıcı değil. Alanın terimleri ile modelleme yapma ve bunu uygulamaya geçirme mantalitesine bazı diller ve teknolojiler en baştan daha açık durumdalar. Bazıları ise hem ondan hem bundan, biraz ondan biraz bundan, taviz alma, taviz verme yaklaşımı dayatıyorlar ve buna "gerçekçilik" diyorlar. Bilgisayar gibi düşünmekten uzaklaşıp insanlarla iletişim kurmak için düşünmeye alıştığımızda bu alışkanlıklara uygun diller işleri zorlaştırmak şöyle dursun kolaylaştıracaklardır. İşte böyle bir durum söz konusu olduğunda kullandığınız dilin dile içkin özellikleri ne kadar esnekliğe müsaade ediyorsa işleri o kadar kestirmeden halletmek ve kodun alan ile uyumunu yüksek tutmak sağlamak mümkün olur. Aksi takdirde kod üretici yazılımlar, XML filan derken en baştan hiç oluşmayabilecek şeylere girişiyor duruma düşüyoruz. Ve sonuç itibari ile bunlar kütüphaneler eklenerek halledilebilecek şeyler değil, dilin tasarımı ile ilgili. Ya da sizin o tasarıma ne kadar müdahale edebildiğiniz ile.

demissiniz. Bu konuda tam olarak ayni goruste degiliz. Domain spesific languages kavrami, yani konuya gore dil kurallarinin esneyebilmesi ya da mikro diller uretmek uzun suredir uzerinde konusulan bir sey. Bu konuda ki yaklasimlar saniyorum ayrildigimiz nokta. ilk yaklasimda dilin yazim kurallari genislemeye uygun bir yapidadir (lisp?) ya da her yeni surumde cuvalla yeni kod kelimesi-kural eklenir dile (C# - SQL sorgulama gibi) ve bu kurallar kodun icinde kutuphane seklinde degil dogrudan dil ozelligi seklinde yer alir, ya dil kurallari disarida tanimlanip kullanimi asil gelistirme dilinden soyutlanir ya da donusum gerceklestirilir. bu sekilde asil dil basitligini korur. ( HQL-SQL donusumu gibi.. Hibernate donusum icin antlr kullaniyor. antlr gibi ). sonucta hangisi daha iyi oldugu kisiel secime kalir gibi, ben acikcasi dillerin basitligini koruyup kutuphaneler ile genisletilmesi taraftariyim.

NHibernte'in kotu bir kutuphane oldugunu ifade etmedim yazimda, tahmin ettiginiz dogru, kutuphane kullaniminda genel olarak yapilmis yanlislar vardi, sonucta onlari duzelttik. Ozellikle lazy-loading ve kalici nesnlerin (persistent) web session'una koyulmasinda cok dikkatli olunmasi gerekiyor. Biz java projelerinde buyuk abisi Hibernate3'u kullaniyoruz ve genel olarak memnunuz. NHibernate'in bir kac eksi noktasi halen Hibernte2.1 kutuphanesinin ozelliklerini icermesi. Yani biraz geriden takip ediyor. Dokumantasyonu Hibernte ile kiyaslayinca yetersiz. Yazilim isleme sirasinda uretilen Exceptions ne yazik ki bazen cok yardimci olmuyor ve ot yolduabiliyor. nulllable tipler; .Net2 ile geldiginden o konudaki destek ancak ucuncu parti yazilimlar ile olabiliyor (projede .net1.1 kullaniliyor). Javada o sorun zaten yok. Ayrica .Net aleminde ne yazik ki Java daki kadar kabul gormedi henuz. NHiberntate'i gercek projede kullanan kisi sayisi bir elin parmaklari kadardir saniyoruz (sirketeki proje sanirim ilklerden). Elestirileri ben hakli bulmuyorum ama ne yazik ki genel olarak microsoft'un onaylamadigi bir yoldan gidis genellikle ender gorulen bir sey. Cogu kisi de NHibernate'in C# 3.0 ile devreden cikacagini da dusunuyor . Hibernate ise Java dunyasinda epey bir sarsintiya yol acti ve JEE5-EJB3 'un olusmasindaki en buyuk etkenlerden birisi olarak gorunuyor (Ki hibernate-annotations projesi EJB3 gerceklemesidir.). EJB3 Java5 ile calistigindan haliyle annotations ve genrics gibi ozelliklerin nimetlerinden sonuna kadar faydalaniyor. Hibernate'in kullanimini da zaten koru korune savunmuyorum. projeden projeye cok farkediyor. Eger cok az tablo mevcutsa dogrudan SQL'e girisilebilir, ya da eger amaciniz client tarafinda yazilim gelistirmekse hic iliskisel veri tabani ile kasmayip farkli bir tat-doku kullanmak en akillicasi olur. Ya da karisik kebap cozumler de olabilir, ki OpenAccess'in yaptigi da bundan pek farkli degil. .Net icin ticari pek cok ORM uygulamasi da zaten mevcut.

Oncelikle gelismis notepad yorumum VS 2003 icin gecerli. VS 2005 icin cok fazla kullanmadigim icin yorum yapmam guc olabilir, ama kullandigim kadari ile halen benim kullandigm IntelliJ IDEA ile ayni kulvarda olmadiklarini rahatca iddia edebilirim . Bugun cikan Eclipse 3.2' de sanirim IDEA'nin java ozellikleri ile basabas gibi ama xml, html, javscript konularinda biraz almasi gereken yol var henuz. Bu konuda bir noktayi aydinlatmakta yarar var, genellikle IDE kiyaslamasini kod yazimi - proje gelistirme- refactoring konusunda yapiyorum. Yoksa VS 2005'in WEB-GUI ozellikleri konusunda kiyaslama yapacak kadar bilgim yok. IDEA konusunda ise ben soylemeyeyim, siz bakin isterseniz.. Eclipse ise surada

bir kac hiperaktif yalniz kovboy programci haric kimesinin Boo gibi .Net dillerine dillerinin yuzune bakmasini beklemiyorum. Bu Ruby icinde kismen gecerli. Microsoft aleminde .Net = VBasic ve C#, web=ASP.net tir. Bu konuda soylenebilecek sey cok aslinda, ama ben gercek calisma ortamimizdan ornek vereyim. Orta-Buyuk capli yazilim gelistirme sirketlerinde bu tip "aykiri" ya da arkasinda fazla destegi olmayan programlama dilleri ve platformlarin yasama sansi hic yoktur. Bu da gayet normal, cunku elinizdeki insan kaynagi bu tip marjinal gecislere uygun degildir. Eger Java ile baslamissaniz buyuk ihtimal Java ile gidersiniz. .Net -Vb icin de ayni seyler gecerli. Ne yazikki bir dilin bir isi iki satir daha az komutla yapmasi gibi bir ustunluge sadece gulunur gecilir.
Eger kastettiginiz yalniz programcilar ya da kucuk yazilim gelistirme gruplari ise, evet bunlar belki yeni dillere ya da araclari daha kolaylikla deneyebilir, fakat benim tecrubem sizinkinin tam tersi acikcasi, .Net aleminde kimsenin baska teknolojileri denemeye tenezzul edecegini sanmiyorum.
gelistiricilerin cogu da zaten cok merakli degiller, soyle bir ornek veryim, is yerindeki .Net kullanilan (dayatma :P) bir projede Hibernate tecrubemiz oldugundan NHibernate kullanilmaya karar verildi.Ben acikcasi hem gelistiricilerin bu isi kiviramayacagindan hem de NHIbernate Hibernate gibi olgunlasmadigindan biraz burun kivirdim ama sesimi cikarmadim. Sonucta projeye dahil degildim ve soz hakkim yoktu. Tamam iyi guzel baslandi, oncelikle NHibernate o zamanlar daha 1.0 surumune yeni ulastigindan gelistiricileri epey bir surundurdu. iki ay sonra epey bir seyler ortaya cikmaya basladiktan sonra ana gelistirici isten ayrildi, diger iki gelistiriciden birisi de baska projeye yavasca kaydirildi ve iki tane yeni gelistirici projeye girdi. Bu yeni gleistiriciler zaten az bucuk oturmus yapiyi bozmadan ve hic anlamaya calismadan isin arayuz ve is mantigi konusunda calistilar. Kabul testlerine gelindiginde ise kabus gerceklesti. Uygulama iki-uc kullanici ile calistirilinca cokuyordu. Dahasi veri tabani sunucusu ve uygulama sunucusu resmen surunuyordu. uc kisi veri girisi yapmaya kalkisinca 4-5 dakikalik gecikmeler yasaniyordu. Tabi Hibernate adami olarak bilindigimden kabak .Net'in N'sinden anlamayan bana patladi. Uc dort gunluk geceli gunduzlu calisma sonunda lazy-loading , open session in view yapilarini adam gibi oturtumakla gecirdik. Kod icinde kabus denilecek yerler vardi ama fazla dokunmadan asil problemli yerleri cozduk. Sonucta oldu, ama acikcasi bezgin gelistiricilerin kullanilan araclar konusundaki bilgisizligi ve hevessizligi gercekten beni biktirdi. Bu arada IntelliJ IDEA-Eclipse ile kiyaslayinca Visual Studio'nun gelismis bir Notepad gibi oldugunu da gozlemlemis oldum.
sirketteki Java gelistiricileri bu konuda nispeten daha arastirici ve farkli araclari kullanma konusunda cesurlar. isletim sistemi konusunda zaten bir secenek yapmaya gerek yok. Ama onlar da yeni dilleri deneme konusunda biraz hevessizler (Bende dahil). Bunun ana nedenlerinden bazilarii Java aleminde hemen her konuda acik kodlu kutuphanelerin ve secenegin bol olmasi ayrica IDE konusunda diger dillerin yanina bile yaklasamamasi ve cogu yeni dilin Java'nin Tip guvenligi ozelliklerini sunmamasi sayilabilir. Tembellik, vurdumduymalzik da diger faktorler :).
bir arac ya da dili kullanmaya baslamak cok dikkatli alinmasi gereken bir karar. projenin gelisiminde karsilasilabilecek lojistik sorunlari onceden kestirmeden "cool" faktorune kanip atilmak bence yanlis.. neyse cok gevezelik edip pek az sey soyledim.. herkse selamlar.

Lisp kullanmayacagiz, kusura bakmayin :P

anladigim kadariyla bu yontemin farkliligi islemin anlasilir sekilde tek satirda yapilmamasi. Statik Factory metoduna parametreleri tasiyan bir nesne gondersek once parametre tasiyan sinifi olusturup daha sonra icindeki ozellikleri belirleyip en sonunda Factory'e gondermek gerekirdi. yani su sekil bir kullanim olurdu:

B b = new B("abc",2);
b.setc(123);
b.setd("asdf");
A = A.newInstace(b);

bu yontemde ise onceki ornekte oldugu gibi
A a = A.B("abc",2).c(123).d("asdf").build();

Gercekten eger bu sIkca uretilen bir sinif ise saniyorum bu yontemin cok hafif bir performans etkisi olabilir. Ama projedeki ornekteki gibi bir defa acilista olusturulan degismez siniflar icin bunun bir onemi yok.

Acikcasi Property listesi yaklasiminin bu yonteme karsi soylediginiz avantajlarini net goremiyorum. Property listesi kavramini belki ben yanlis algiladim. Yani sonucta bu yontemde de public api'yi degistirmeniz gerekmiyor..
son olarak, sunumdaki kodda kucuk bir hata var, Builder sinifinin "static" tanimlanmasi gerekiyordu galiba.. Saygilar.

Bu yapi daha cok degistirilemez siniflar icin dusunulmus saniyorum. Dediginiz gibi aslinda bunun statik sinif factory metoduna (ya da constructor'a) parametreleri tasiyan bir nesne yollayarak ana nesnenin olusturulmasindan pek farki yok. Guzelligi olusturma isleminin farkliligi (parametrelerin arka arkaya ulanmasi ve build() metoduyla ana sinifin uretilmesi). Ortada ana uretilecek sinifin constructorundan ve uretilecek sinifin icindeki bir factory metodundan eser yok.

ozellik erisim metodlarinin "seytani" olarak nitelendirilmesi abartili. ama bu metodlarin gereksiz ya da yanlis kullanimi sakincali. Ornegin pek cok sinifi "immutable" yani degistirilemez yapmanin buyuk faydalari vardir (Thread-safety, guvenlik). Bu durumda sinif degiskenlerini degistirilemez yapip tekil bir constructor ile ilklendirilmesine izin verip sinif parametrelerine sadece "okuma" erisimi - o da gerekiyorsa- (getter) vermeniz gerekir. Yani gelistiricinin hemen sinifa sarilip aman hemen get-set metodlairi ureteyim su IDE ile demesi yanlis.

Fakat bazi durumlarda (ornegin ORM uygulamarinda) bu genellikle onerilen bir sey oldugundan genellile bur metodlar yazilir, ya da ozellikler "public" ya da package-visible tanimlanabilir..

setter kullaniminin sIkca yapildigi bir yer bazen siniflarin olusturulmasinin dis veri erisimine bagli olmasi. zemberek projesinde acikcasi o konuda biraz muzdaripiz. Ornegin harflerin ya da eklerin cesitli ozellikleri bir dis dosyadan okunuyor. Ve yeni bir ek olusturulacaginda "set" medodlari kullaniliyor. Bu, caisma aninda bu degistirilemez olmasi gereken nesnelerin degistirilmeye acik olmasina neden oluyor. Birisi alakasiz bir yerde 'a' harfini sessiz harfe donusturebilir yani. Bunu engellemek icin cok parametreli constructor kullanilabilir ancak bu da oldukca rahatsiz edici ya da mumkun olmayabilioyor. 10 parametreli bir constructor dusunun. Gecenlerde okudugum Joshua Bloch'un "Effective Java reloaded" sunumunda bu durumda kullanilmasi onerilen "Builder" Patterni onerilmis. Basitce su sekilde, sinifin icine bir adet "Builder" ic sinifi koyuluyor. Bu nesne icinde gercekten set metodlari var ve bu medodlar gene olusmakta olan Builder nesne referansini donduruyor. Bu sekilde cok parametreli bir sinifi su sekilde olusturabiliyorsunuz:

NutritionFacts twoLiterDietCoke = new NutritionFacts.Builder("Diet Coke", 240, 8).sodium(1).calori(0).build();

Yani setter ya da cirkin constructor olmadan gayet zarif bicimde sinifimizi turetebiliyoruz. Bu yapiyi, eger uyarsa zemberek icindeki degismez siniflara uyarlayacagim. sunumu suradan indirebilirsiniz, icinde ilginc baska konular mevcut.. Effective Java Reloaded

IDE refactor ozellikleri inanilmaz guclu olsa bile ne yazik ki property tip donusumu konusunda oldukca yetersizler halen. Sanirim bunun nedenlerinden birisi otomatik olarak int->long donusmunu kestirmenin her zaman kolay olmamasi. Ya da otomatik donusum sonrasinda sistemde derleme hatalarinin olusmasi kacinilmaz olabilir (down-up casting nedeniyle..) Genede yazarin o konuyu abarttigi konusunda katiliyorum.

Usta programcilik karmasik ya da anlasilmasi zor dil ozelliklerini kullanmak degildir.. Aksine, karmasik dil ozelliklerini kullanmak ozellikle takim calismasi ile yurutulen ve uzun sure bakim gerektiren uygulamalarda son derece sakincalidir.

yazik diyorum, ama acikcasi sasirmadim. Dergi ve gazetelerin yasamasi reklamalara baglidir, gozumden kacmadiysa dergide hic reklam yer almiyor. Eger dergi yazarlari linux camiasinda medet umdularsa bence yanilmislar. Turkiyedeki daha Linux-Acik kod camiasi henuz (bilmiyorum dogru kelimemi ama..) bedavaciliktan profesyonellige gecis sIkintisi cekiyor. Dunya capinda linux agirlikli dergilerini inceleyecek olursaniz reklamlarin %90'inin sunucu ve kismen yazilim gelistirme araclari reklami oldugunu gorebilirisniz. Turkiyede adam gibi Linux sunucu destegi veren kim var acaba? Acikcasi derginin icerigi oldukca yogun ve cok cesitli farkli konulara da yer veriyor, bu sekilde bitmis olmasina uzuldum.

Selamlar. acikcasi bir platformun cekirdek yeteneklerinin donanima ya da isletim sistmeine desgimesi cok istenen bir sey degildir. Bu nedenle Java'nin yaklasimini daha tuttugumu ifade etmeliyim. yani int her zaman 32bit, long64 bittir hesabi. en azindan tasinabilirligi garantilemis oluyor. Bu arada JAva'nin buyuk sistemlerle ilgili bir sorunu oldugu konusunda kafanizda bir soru olusmasin..

acikcasi konunun nirvanadan cok performans-kaynak kullanimi ile iliskisi var. yani ne kadar cok esneklik-guvenlik-soyutlama o kadar performans-kaynak kullanimina negatif etki olarak Python icin de benzeri problemlerin oldugunu saniyorum. daha dogrusu calistiginiz platforma gore farkli sonuclar alabilirsiniz gibi gorunuyor. Python arrays kodunu inceleyin isterseniz, dizi indexleri C int'i.. Python arraymodule.c

"... -pi/4 +pi/4 arasi degerler..."
sinus ve kosinus icin -pi/4 +pi/4 arasi degerler... olacakti.

Gercekten algoritmalar soyut ve matematiksel ifadeler ancak bilgisayar dillerindeki gerceklemeleri haliyle donanim kisitlamalari nedeniyle soyut olamiyor. Bunun bir nedeni de kaynak ve performans kaygilari nedeniyle cogu noktada "pratik" kullanilabilirlik teorik "dogruluk"'un yerini aliyor. Bu problemde oldugu gibi. Diger dilleri bilemiyorum ama zaten Java'da bir diziye atanabilecek eleman sayisi pozitif integer siniri kadar. yani index degeri yanilmiyorsam maximum 2^31-1 kadar olabiliyor eger bu boyle olmasaydi, kanaatimce performastan fedakarlik edilecekti. Zaten range-check ile yeterince dizi performansindan fedakarlik edildiginden ve pratik limitler dusunuldugunde bu tur dizilerin bellekte bulunmasinin soz konusu olmayacagi kestirilerek bu yola gidilmis. Elbette bu tur devasa nesne kumelerini tasimak icin Collections nesneleri (Map, List) zaten kullanilabiliyor .
Benzeri bir sorun Floating point islemlerde karsiniza cikiyor. Mesela java'da C kutuphanelerinden biraz farkli bir yol secilip -pi/4 +pi/4 arasi degerler haricinde daha kesin degerler hesaplanmis, ama performanstan fedakarlik edilmis. bilmiyorum diger dillerde bu yola gidilmismidir.
baglanti

valla 1Gig bellek byte dizisi icin yeter saniyorum bu operasyon icin. Lisp'i kucumsemek icin soylememistim, sadece merak ettim acaba benzeri bir problem olur mu diye. Java'da da Collections siniflari integer ile sinirli degildir (List icin long index, 64 bit), ama bu miktarda bir List olusturmak icin 1GB bellekyetmez saniyorum.

aslinda bir bos vaktinizde lisp icinde bir milyarlik bir dizide binary search yapabilirseniz sevinirim..

tabi sunu da not ediniz, butun bu diller C-C++ kokenli oldugundan bu tur hatalari. hatta daha kotulerini icerisinde her an barindirabilirler ;). Isin sakasi bir yana, acikcasi bu hatadan alinmasi gereken ders hatanin kendisi degil, ki pratikte ortaya cikabilecek bir sey de degil zaten, sadece platform gelistirme ve algortima yazmanin ne kadar dikkat istedigi ve test kriterlerinin gunun kosullarina gore tekrar elden gecirilmesi gerektigi.

Eger yeni bir projede bir milyarlik bir dizide binary search ihtiyaciniz olacaksa dediginiz mantikli, ama var olan bir projede bu hata ortaya cikmis ise (neyseki array index out of bound exception firlatiyor..) sanirim bu uc yoldan birini secmeniz gerekir.. ;) bir de saniyorum bu konudan cikarilmasi gereken ders algoritmalarin ne kadar basit olursa olsun cok detayli sekilde test edilmeleri gerektigi.

Evet gercekten tatsiz gorunen bir hata. bu hatanin sadece 1 milyar ve uzeri boyutlu dizilerde gerceklesmesi bu ana kadar gozden kacmasina neden olmus gorunuyor. Bu boyutlu diziler uzerinde binary search islemine pratik olarak rastlamak pek mumkun olmasa gerek. Burada eger bu sekil bir islem ihtiyaci olan varsa sanirim uc cozum onerilebilir, 1- binary-search islemini elle yazin 2- O projeniz icin IBM ya da BEA ya da baska bir Java kullanin.. 3- Eger cok kritik degilse Mustang'in cikmasini ya da bu hatanin geri 5 surumune atilmasini bekleyin..

eger vaktiniz varsa suradan dinleyebilirsiniz. http://www.javapolis.com/confluence/display/JP05/2006/02/12/Joshua+Bloch+and+Neal+Gafter+interview

google java kullanir. kesin bildigim reklam sisteminin sunucu yani tamamen java. gmail, Blogger ve kismen Gtalkin sunucu tarafinin (buyuk cogunlugunun) Java oldugunu okumustum.