Dil Üstadları ile Araç Ustaları: IDE Ayrımı

0
FZ
Geliştirici dünyası iki kampa ayrılmıştır. Bir kampta dil üstadları vardır, bu yazılımcılar yüksek seviyeli programlamadan -- birinci-sınıf fonksiyonlar, aşamalı programlama, AOP, MOP, kendi kendini sorgulama -- bahsederler. Araç ustaları ise tümleşik geliştirme ve hata ayıklama araçlarında ustadırlar, kod tamamlama, "refactoring", vs. Dil üstadları Emacs ya da VIM kullanır, bu tür editörler yeni dilleri denemek için daha uygundur. Araç ustaları ise Visual Studio, Eclipse, IntelliJ gibi IDE'leri kullanırlar.

Laszlo ve Groovy gibi yeni diller ya da AOP (Aspect Oriented Programming) gibi dil uzantıları genellikle öncelikli olarak metin-editörü tabanlı yazılım geliştirme ortamlarında ortaya çıkarlar ve ancak ondan bir süre sonra IDE dünyası bu tür desteklere kavuşur. Eğer dil ya da uzantı gerçekten başarılı ise araçlar da bunu desteklemeye başlar. Bu ayrımın tek sebebi araç geliştirmenin dil geliştirmekten zor olması değildir. Asıl mesele bir dile hakim olmak ile bir araç setine hakim olmanın çok farklı iki mantalite olmasıdır, belli bir ölçüye dek bunlar birbirlerini dışlayan alternatiflerdir. Acaba neden? İşte sebepleri...

Oliver Steele'nin The IDE Divide başlıklı makalesini tüm yazılım geliştiricilerin okumasında fayda var. (Not: Şöyle sağlam bir FM üyesi çıksa da bahsi geçen makaleyi Türk diline kazandırsa... hani yani küçük bir olasılık olsa da, belki diyorum, belki biri üstlenir, FM'ye bir katkıda bulunur...)

Görüşler

0
malkocoglu_2
Harika bir yazi!!! Tam da bu konu hakkinda birseyler yazmayi dusunurken hazir pismis bulmak ne guzel! Tesekkurler FZ.

Benim goruslerim tabii ki "once dil" tarafini destekliyor. Ama dilin ne oldugunu iyiiiiice bir genisletmek istiyorum.

Mesela, Java dilinin icinde, Hibernate kalicilik araci, JMS, EJB, vs.. gibi araclarin arayuzleri de birer DILDIRLER. Yani her ek kutuphane bir dildir. Mesela Hibernate icin belli XML dosyalari (konfigurasyon amacli) belli yerlere, belli sozdizim kurallarina gore yazilip konmaktadir, ve sonucta bu bir dilin tanimidir. Once xx() cagir, sonra yy() cagir, vs.. Aynen turkce dilinin kurallari gibi, edat, zamir, fiil, vs..vs.. Hepsinin yerleri var.

Yani, "dillerin icinde yeni diller" surekli dogmaktadir.

Once dil diyen arkadaslar, bu yeni dillere bakacak, temizlik acisindan tartacak, Occam Usturasi desturuna uymayanlari *iktir edecektir. Ote yandan tool bazli arkadaslarin trene gec atlamasi cok muhtemeldir. Teknolojilerin ve onlarin alt teknolojilerinin ne kadar hizli gelistigini ve hatta öldügünü dusunursek, once dil diyen arkadaslar icin bu esneklik bir avantajdir.

Bir de:: Cok teknoloji ustasi olmayan, tool bazli arkadaslar trene atlayinca, sadece tool'un yaptiklarina hapis oluyorlar. HICBIR TOOL, TUM SECENEKLERI GOZONUNE ALAMAZ. Yoksa, Microsoft su anda kurumsal yazilimlarda (servis tarafi) kral olurdu. Degil. Herseyi "kolaylastirmaya" ugrasmiyorlar mi?

Bir de:: (Daha kotusu), tool bazli arkadaslarin bir teknolojiyi "tool destegi var diye" secmesidir. Sirf bu yuzden simdi coktan gebermis olan Entity Bean teknolojisini secmis olanlari gordum. 4 senedir "dilinin sade olmamasi sebebiyle" bu teknolojinin kullanilmamasini girebildigim her net kanalinda soylemeye ugrasiyorum. Fakat IDE'ler bir sekilde alttaki garabeti gizlemisler, teknolojinin dogal olumune erismesini engellemislerdir.

Temiz dil, temiz kod gonderme (deployment) demektir. Daha rahat hata bulma (troubleshooting) demektir. Oyle ya da boyle, %1 sartlarda ortaya cikan o kimsenin dusunmemis oldugu sart ile alakali hatayi ayiklamaya ugrasirken, temiz bir dile bakmanin rahatligini daha iyi anlasilacaktir.

Gorsel arac yazmak zor istir (servis tarafcilar tarafindan pek de sevilmez); teknoloji ureten once dil uretecektir. O yuzden "ikinci elden" bilgili bir araci kullanmak yerine, birinci elden esnek dili kullanmayi tercih ederim.

Tabii yanlis anlasilmasin; Emacs'te Java destegi mukemmel. Ustelik bazi yapacagim hareketleri kimsenin IDE'sini yapamaz, her yerde gezinen sahsim icin bunlar cok onemli. Teknik lider her platformada gezinir. FTP basinda beklesen teknik liderler, azicik betikleme bilse (rsync, ssh, scp), deployment isleri rahatlardi. "Deployment plug-in isteruk!". Bekleyin.

Ama tabii, boyle araclar da olacak. Sadece o araci kullanlar ayptiklarini birincil, ve daha abartilisi kral zannetmesin. Baslangic, orta seviyedeki programcilardan olusan bir takimim olsa, araci kullanin derim. Ama yeni teknolojiyi, gittigim her yerde once dil diyen arkadaslar getirmistir. Liderlik baglaminda projemizde Eclipse... Eclipse sayiklayan arkadasin plug-inleri yeni platforma gecince "calismadi", ve JBoss sitesinden "ornek kodlara" dayanarak gecisi ben yaptim. Kullanilan eski teknolojiyi rafa kaldirik, plug-in var diye kullaniyorlardi. CVS plug-inleri var ama, nasil binary dosya ekleyeceklerini bilmiyorlar. Bu da tum gelistirme ortamini etkiliyor. cvswrapper dosyasina gireceksin YAVVRUUUMMM... :) Bu kadar Akdenizlilik yapayim bari.. :) Bu konu hakkinda bayagi gerilmistim. :)


0
bm
Bu tip tezatlar konusulurken 'yahu keske herkes anlasa' yaklasimi bilgisayarcilarin alanin ticarilesmesine ragmen hala fevkalade paylasimci, ve toplum bilincine sahip insanlar olduklarini gosteriyor. Ticari menfaat aslinda "bunun en iyisi arac kullanmaktir, en bi modern sahane", "ben visual *ok kullaniyorum sen hala visual kakada mi kasiyorsun?" diyenlere hic ses cikartmamakta. Bilginin fazla maddi sermaye gerektirmeden paraya donebildigi bir alan bu aslinda, hal boyle olunca insanlarin bilgilerine sermaye muamelesi yapip susmalari beklenir. En azindan bana simdi oyle geldi. Yanlis mi dusunuyorum?
0
ttk
visual *ok'un, visual kaka'nın bir sonraki versiyonu olduğu hemen de belli oluyor, bunun ismi daha kısa. Hemen ısmarlamak lazım :)
0
malkocoglu_2
Şu da var: Sirket XYZ icinde standartlasmanin sizin istemediginiz yone kaymasi, ve tepeden "bu arac kullanilacak" diye destur inmesi. Ya da, sirket bazinda degil ama, takim bazinda bazi araclara dogru tesvik edilmesi. Her yerde ayni (uniform) gelistirme aracinin kullanilmamasi nereden bakarsaniz biraz uyumsuzluk yaratir. Mesela IDE'ciler 'derleme betigini' merkez almiyorlar; TIK TIK TIK ile secip bir yerlerden kutuphane gorsel olarak "ekliyorlar'. Bu durum yeni gelen programcinin aninda kodu alip derlemesini gecilktiriyor, ayrica, zaten otomatik derleme (automated build) icin gereken betiklerin yazilmamis olmasina sebebiyet veriyor.

Diger durum, daha once belirttigim gibi, bir teknik liderin yanlis araca guvenip, projeyi geciktirmesi, gerekeksiz heyecan/kayip zamana sebebiyet vermesi. Herkes araclar konusunda ilimli olamiyor. Bazilari muptela seviyesinde bu araclarin tiklama ile yapmadigini yapmamakta israrci (gavurcada 'drinking xyz on coolaid' denir buna). Ultra gorsel araclari kullanan sIkI adamlar var, evet, fakat bu adamlar isin dil tarafinda da zaten cok rahat. O yuzden kelege gelmiyorlar. Yani pur IDE'cilerin dil saygisi/bilgisi kazanmasi sart.

Görüş belirtmek için giriş yapın...

İlgili Yazılar

HTML, JavaScript ve PHP ile E-Posta Takibi

FZ

Düşünün ki eski bir dostunuza ya da eski sevgilinize e-posta atıyorsunuz ama onun bu iletiyi okuyup okumadığından emin olamıyorsunuz! :)

Ne yapacaksınız? Oturup merak içinde bekleyecek misiniz? Tabii ki hayır! ;)

Peki ne yapmalı?

Önce derdimize çare olacak bir sistem taslağı çizmeli tabii ki...

Değerli FM üyelerinden Gökhan "Crematorium" Olgun´un "gönderdiğiniz e-postanın okunup okunmadığını kolayca takip etme" amaçlı makalesinin devamını bu adreste okuyabilirsiniz.

O´Reilly´den 2003´ün En İyi Makaleleri, İpuçları ve Kitapları

FZ

Bilgi işlem dünyasının efsanevi yayıncısı O´Reilly ziyaretçi istatistikleri ve okur görüşlerine dayanarak Top 10 makalelerini, ipuçlarını, kitaplarını, vs. seçti. Python, Mac OS X, RegExp, PHP, Mozilla, Python, RSS, Flash MX, Extreme Programming, Java, mplayer, vs. gibi konularda sene boyunca en çok ilgi görmüş, bilgilendirici, vizyon açıcı makalelerin listesini ONLamp Best of 2003 ve O´Reilly Best of 2003 adreslerinde bulabilirsiniz.

Bu arada FM editörlerinden sundance arkadaşımızın mplayer ile ilgili makalesinin ONLamp Top 10 listesinde ikinci sırayı işgal ettiğine dikkat çekmek isterim. Gönül isterdi ki, dünya çapında network adminleri arasında infial yaratan Netcat and Reverse Telnet makalesi de listeye girsin ;-) Ama olsun, o bizim gönüllerimizde alması gereken yeri çoktan aldı :)

Emacs ile Oracle Sql*Plus ve sql-mode

zekzekus

İş yerinde yoğun olarak Oracle veritabanı ile çalışıyorum. Sorun tespit etmek için sorgular yazıyorum, PL/SQL ifadeleri çalıştırıyorum. Bu işlemleri en rahat yaptığım araç Oracle tarafından sağlanan Sql*Plus. Rahat dediğime bakmayın sade ve son derece hafif olan bu istemcinin insanı deli eden “özellikleri” var. En basitinden yazdığınız uzun bir SQL cümlesinin başında küçük bir hata yaptıysanız, imleci geri götüremiyorsunuz (henüz enter tuşuna basmamış olsanız da). Daha önce yazdığınız komutları listeleyen ve çabuk bir şekilde kullanmanıza olanak veren bir tarihçe (history) özelliği de yok. Emacs editörü (editör demek bir nevi haksızlık oluyor artık) her zaman olduğu gibi bu konuda da devreye giriyor.

Emacs ve sql-mode ile ilgili bilgi veren yazının devamı burada...

RSS Dosyası Yapısı

ctengiz

RSS aslında sitelerin içeriklerini başlıklar şeklinde sunmak için kullanılan bir teknoji ve temeli de bir XML dosyası. Açılımı Rich Site Summary veya Really Simple Syndication. İlk olarak 1999 Netscape tarafından ortaya çıkarılan bu teknoloji daha sonra çeşitli gruplar tarafından geliştirildi. Tarihçe ve versiyonlar ile daha detaylı bilgi için yazının sonundaki kaynaklara başvurulabilir.

Smalltalk ile Yazılım Geliştirme: Squeak

FZ

Özet: Bu belge, Squeak bütünleşik geliştirme ortamını kullanarak Smalltalk programlama dili ile yazılım geliştirme süreçlerine giriş niteliğinde kaynak sağlaması amacı ile yazılmıştır.

Zekeriya "zekus" Koç'un yazısının devamını burada okuyabilirsiniz.