scala

• öğrenmek niyetine girenler için gelsin :
  
  fonksiyonel programlama
  1.) herşeyden önce fonksiyonel programlama ne demektir öğrenmeli
  wiki
  2.) eric meijer - fonksiyonel programlama video eğitim serisi
  functional programming fundamentals
  
  scala
  1.) scala tutorials web sitesiyle codeschool gibi adım adım öğrenmeye başlayabilirsiniz.
  scalakata scala tutorials
  
  2.) martin odersky nin coursera eğitimi - functional programming principles in scala - bence en iyisidir.
  functional programming principles in scala - derslere ulaşmak istiyorsanız warez sitelere göz atabilirsiniz.
  
  > sbt
  > console
  > println("liste zamanla güncellenecektir !")
  > ctrl + d
  
  bye.
• ideal hedef kitlesi "scala'nın type system'ı çok karışık ya" diyenler de değil. insanların yeni bişeyi anlamaları için en azından biraz çaba göstermeleri beklenir. meraklısı için öğrenmek de çok zor değil zaten.
  
  tesadüf bu ya, yaratıcısı martin odersky zamanında yale'ın haskell grubunda da çalışmıştı. implicit'ler gibi kimi özelliklerinde haskell etkisi barizdir. (bakınız "poor man's type classes") dizaynını en çok etkileyen bir başka unsur ise ml'in module sistemi (özellikle functor'lar). martin odersky bir programlama dilleri profesörü, teorik bilgisayar bilimci. haliyle eserinin olabildiğince iyi olması için elbette ki en sofistike teorik araçları kullanacak.
  
  yeni collection library'si "generics of a higher order kind" çalışmalarıyla geldi. okunmazlık getirmediği gibi diğer oo dillere göre çok daha jenerik kod yazmayı sağlıyor bu özellik. nasıl haskell kodu yazmak için, monad kullanmak için kategori kuramı bilmeniz gerekmiyorsa, bundan faydalanmak için de type theory sihirbazı olmanıza gerek yok. bakınız:
  
  misal java'da list class'ını implemente ederken list<t> diye listenin elemanlarını parametre olarak bırakabiliyoruz. böylece tekrar tekrar elemanları farklı type'lar olan list classları yazmaya gerek kalmıyor. güzel mi? süper. sorun ne? ee type constructor'ı (bu örnekte list) parametre yapamıyoruz ama değil mi? jeneriklerde higher order kind desteği onu sağlıyor işte. bu bize ne kazandırıyor? basit bi örnek için bu olmadan iterable ve list class'ları nasıl implemente edilir bakınız:
  
  trait iterable[t]{
  def filter(p: t => boolean) : iterable[t]
  def remove(p: t => boolean) : iterable[t] = filter(x => !p(x))
  }
  
  trait list[t] extends iterable[t]{
  def filter(p: t => boolean): list[t]
  override def remove(p: t => boolean) : list[t] = filter
  }
  
  bakınız list'te bariz code duplication var. higher order kind desteği sayesinde yenisi nasıl oluyor:
  
  trait iterable[t, container[x]]
  def filter(p: t => boolean) : container[t]
  def remove(p: t => boolean) : container[t] = filter (x => !p(x))
  }
  
  trait list[t] extends iterable[t, list]
  
  evet bu kadar. bu sadece ufak bi örnek. daha fazlası için yeni library dizaynını anlattıkları okuması epey kolay şu makaleye bakabilirsiniz: http://lampwww.epfl.ch/…ersky/papers/fsttcs2009.pdf
  
  bu örneği de içeren teorisi için: http://www.cs.kuleuven.be/…es/genericshk/tcpoly.pdf
  
  generics of a higher order kind makalesi en önemli oop konferansı oopsla'da yayınlandı. continuation işleri de en önemli fp konferansı icfp'de. bilim adamının işi araştırma yapmak ve bu araştırmalarını makale olarak yayınlamaktır. odersky de kendi araştırmalarında kendi dili scala'yı kullanıyor. bu da yeni bilimsel bulguların doğrudan dile girmesine sebep olup scala'yı daha da ileri götürüyor. onun için ide'yle uğraşmıyorlar da bunlarla uğraşıyorlar. bunların bilimsel değeri var çünkü. ide'ninse yok. yine de o gibi işleri de tamamen boşlamıyorlar. ide'yle uğraşan programcıları var işte artık. ayrıca "derin konular", "zealot" bulunup implemente edilmiyor. mesele onları dilde implemente etme meselesi değil "derin mevzu"nun kendisini bulma meselesi. bilim bu. şimdiye kadar olmayan bişey bulunuyor da dile ekleniyor. ondan programcının değil bilim adamının işi. konsepti bulduktan sonra herkes implemente eder. adamlar programlamayı pek çok yönden iyileştirecek konseptler bulmaya çalışıyorlar. işleri bu.
  
  elbette ki scala'nın yaygın olarak kullanılması isteniyor. (ki twitter başta epey de kullanılmaya başlandı zaten.) jvm üzerinde çalışmasının tek nedeni de o. bu seçim beraberinde belli bazı tavizler de getirdi, ve fakat bu tavizler kötü programcılar anlayamaz diye daha jenerik kod yazmayı sağlayacak dil özelliklerinin eklenmemesini içermiyor. bir özellik dili daha iyiye götürecekse eklenir, iyi programcının da yeniliklere açık olması beklenir.
• öğrenmeye değer ama deneysel olarak...
  biraz daha kapsamlı yazdım:
  [buradan https://medium.com/…kodcusu-f58e7c780b0b#.69poa7qxn]
• epfl'den martin odersky'nin marifeti. hem object oriented programming hem de functional programming mahfillerinde sevilen sayılan bi isim olan odersky'nin iki komünite arasında sıkışıp kalmaktan sıkılıp ikisini kaynaştırma çabasıdır. malumunuz, philip wadler'ın adına "expression problem" dediği, functional programming'le object oriented programming arasındaki dualiteye işaret eden eski bi problem var. problem şu ki object oriented programming'de subclassing yöntemi ile class'lara yeni case'ler eklemek mümkün iken, class'a yeni bir metod eklemek kodu yeniden compile etmeden mümkün değil; functional programming'de ise data type'lar üzerine yeni fnksiyonlar eklemek mümkünken, kodu yeniden compile etmeden data type'a yeni case'ler eklemek mümkün değil. (eklendiği vakit o zamana kadar yazılmış kodu da bozar ve compile etmeden önce eski kodu düzeltmek gerekir.) scala işte bu dualitenin üzerine gidip iki paradigmanın güçlü oldukları taraflarını birleştirerek zayıf yönlerini ortadan kaldırmayı amaçlıyor. bu kaynaşma öyle "hadi bu ikisini birleştirelim" tarzı basit bi kaynaşma değil. üstüne çok düşünülmüş ve sonunda gayet tutarlı bi programlama dili ortaya çıkmış. hiçbir şey eğreti durmuyor. simon peyton jones da scala'yı "expression problem'a belki de şimdiye dek sunulan en iyi çözüm" diyerek kutsadı.
  
  martin odersky aynı zamanda wadler, bracha ve iki sun çalışanıyla beraber java generics'i de dizayn eden şahıs. java 1.5 compiler'ı da onun da elinden çıkma. bir not olarak zamanında niklaus wirth'in doktora öğrencisi olduğunu da ekleyeyim. daha o zamandan compiler yazma mevzularında aşmıştır.
• ide desteğinin olması zaten başlı başına olay. ocaml'ın haskell'ın var mı? yok. nihayetinde scala tamamen bir üniversitede^* bir araştırma grubu tarafından geliştirilen bi dil. cillop gibi ide yazmanınsa akademik bir karşılığı yok. profesörden bunu yapması beklenemez. işi araştırma yapmak olan doktora öğrencisinden de. araştırma grubunun bütçesinden bi programcı tutup ide işlerini ona havale edebilirler ama orda da profesörün önüne çıkan bütçesini nasıl kullanacağına yönelik çeşitli kısıtlamalar işi yokuşa sürüyor. mevcut eclipse plug-in'i zamanında scala grubunda çalışan bi post-doc tarafından yazılmıştı. incremental compilation gibi alanlarda iyi de iş çıkarmıştı. şimdilerde sırf eclipse plug-iniyle uğraşsın diye parayla bi programcı tuttular. bug bulduğunuzda yapılacak en iyi şey bunu bildirmek olur. düzeltirler.
• adı scalable olmasından geliyor.
  jvm üzerinde de çalışabilen hayranlıkla takip ettiğim (bkz: functional programming) mantığı dillerinden.
  hele bir (bkz: pattern matching) diye bir olayı var, bir de (bkz: with) syntaxı ... java programcısını kendisine aşık eder.
  groovyi yazan herif ki groovy şu an en çok üzerine uygulama yazılan jvm dili*(java hariç) , ben groovyi yazmadan scala'nın
  dökümantasyonunu okusaydım groovyi yazmazdım dedirtmiştir.
  
  twitter bütün alt yapısını ruby den scala ya çeviriyor.adamlar scalanın performansına vurulmuş.
• deneysel olarak yazılıp eğlenilebilen fonksiyonel bir dil. fonksiyonel programlamaya gerçekten çok ihtiyacınız olan bir proje yazmıyorsanız böyle maceralara girmenin manası yok.
  çalıştığım şirket böyle bir maceraya girdi, biz de kasıp duruyoruz ama deyip değmeyeceği konusunda şüphelerim var.
  
  martin amca'nın bakın ne kadar da sintaktikşugır yaptık dediği her saçmalık, java'da yapılamayacağından değil, yapıldığında işleri karıştıracağından yapılmamıştır, bunu bilmek lazım.
• latince, 'merdiven' anlamindaki kelime. turkcedeki 'iskele' kelimesi de bu kelimeden gelir.
• parsers, domain specific languages, message passing interface, pattern matching vb. icin kullanmayacaksaniz ogrenme egrisinin yokusunda kaybolmaniz muhtemel.
• gereginden fazla ozellik neden iyi degildir iyice gorulebilecek programlama dili. her durum icin ne lazimsa tamamen kendi dunyasinda gelen libi alip kullanmaniz gerekir. biri c den farksiz gelir, biri bildigin javadir, biri haskell gibi ama daha berbat syntaxlisidir, bazilarida boyle arada mutant gibi sey seklinde olur. gununu nasil karmasik kodu sanat gibi yazarim diye gecirmiosaniz, amaciniz sadece zor dili kullanmak degil isi bitirmekse hic tavsiye etmem. twitter, netflix falan da kullaniyor goygoyu da tamamen sinir bozucu.