Görüşler
Hayatta cok merak edip de asla cevabini ögrenmek istemedigim sorulardan biri hala Java'nin tas devrinden kalma versiyonlarini kullanan kurumlarin neden böyle bir israrda bulunduklari.
"Bozuk degil ise elleme" diye birsey yok muydu?
Ilgi alanim degil ama gunluk hayatta veri islerinin prototiplerin cogu icin python kullaniyorum, memnunum. Her yerde python3 kullanini duyuyorum. Hic ilgimi cekmiyor :) Gicikda olmaya basladim, baska biri kendisine gonderilen python3 kodlariyla ugrastigini anlatti. Niye baska/yeni bir dile baslamamislar ki? PythonCon da python2 nin son raf omrunu aciklardilar bir de. Ondan sonra ne yapacaklar bilmiyorum.
Veri analizi / bilimi baglaminda PyData tayfasi cogunlukla Python3 uyumlu degil mi artik zaten? Ben mi yanlis biliyorum? Son baktigimda hamallik cikarabilecek kisimlar daha ziyade web programlama catilari ile ilgiliydi diye aklimda kalmis. Yani 'enterprise' tarafinda entegrasyon gerektiren durumlar soz konusu yoksa 'saf' veri isleme isleri icin makul olabilir (oteki turlu, evet, hamallik cikarir)
Cok anladigim bir konu degil de, python ile veri analizi enteresan bir durum.
Guzel bir fikrimiz var, kullanicimiza yeni bir vukuf (insight?) saglayabiliyoruz. Fikrin tanitimini yapiyorsun, herkes begeniyor. Hadi bunu uretime gecirelim, milyondan fazla kullanicimiz var, ee birisi bari bu python seylerini baska bi sekillerde yazsinlar felan... :)
Benim kendi fikrim, python u ciddi olmadigi icin seviyorum, ciddi seyleri de python ile yapmiyorum. o yuzden boyle 2 olmaz artik 3 kullanin olaylarini rahatsiz edici buluyorum.
Python'a ciddi degil dedin, uzdun. Sizi bilahare eski HiTNet tayfasindan guzel insan ve ex-FB, ex-Google'ci Burc Arpat'in "Why Python is Awesome When Working With Data at any Scale" sunumuna yonlendiriyorum. (Sonra gene elestiririz, o ayri, duzgun bir tur sistemi olmadigi icin ben de kirginim kendisine.)
Tabi ki "bu yazilim tamam, paketleyip surada calsiamaya birakalim" dedikten sonra degisiklik yapmamayi anlarim fakat acikcasi ayatimda hic bu sekilde kullanilan bir yazilim ile muhatap olma sansim olmadi. Kisisel tecrubem yazilim denen seyin surekli gelistirildigi yönunde. Hal böyle oldugu zaman da surekli gelistirilen bir yazilimin nasil tarih öncesi Java surumlerine cakilip kalabilecegini hayal etmek dahi istemiyorum.
Cesitli uygulama catilarina bagimliliklari, bu catilar servisten kalktiktan cok sonra dahi kullanilmaya devam ettiklerini cok gördum fakat özellikle de Java gibi geriye uyumluluk konusunda asiri hassasiyet gösteren bir platformda bu sasirtici.
Not: Tam gönder tusuna basacakken eski isyerimde yasadigimiz bir entegrasyon probleminden öturu Java 7'den Java 8'e gecerken bizden bagimsiz bir sistemle haberlesmesi gereken özel bir Java 6 sunucusu kurdugumuzu hatirladim. Tuylerim urperdi.
Bazi sistemler ucak gemisi ya da devasa tankerler gibi, bir emir verildikten / karar alindiktan sonra nihai sonucu gormek epey surebiliyor.
Videosunu bulamadim ama mesela Hollanda demiryollarindan birilerini 2012'deki su konusmasi bu konuya dair guzel noktalar iceriyordu diye aklimda kalmis. Yine Hollanda demiryollarindan bir baska ornek, vaka olarak 25.000 satirlik Ant-tabanli insa sistemini Gradle'a nasil yavas yavas gecirdiklerini anlatiyorlar.
Yukarida senin bizzat yasadigin ornek guzel bir nokta. O tuyler urpertici durum x 10 dusun. Milyonlarca €, yuzlerce binlerce calisanin isi, milyonlarca kisinin operasyonel durumu vs soz konusu olunca, bazi seyler buzul hizinda ilerliyor gibi gorunuyor.
Bir de tabii arka tarafini istedigin gibi evirip cevirebildigin 'servis' tarzi yazilimlar ile anahtar teslim cozum olarak sundugun 'urun' tarzi yazilimlar arasindaki farklar var, farkli ekonomik modeller, farkli teknolojik kisitlar vs.
Seviyorum Java dunyasini, cok eglenceli, misal Spark - Hadoop - S3 arakesitinde calisan elemanlardan birinin su yazdiklari: "Add spark-cloud module to pull in object store access" Bir yandan gulumseyerek, diger yandan urpererek okuyorum. Soz konusu olan "enterprise" bir proje de degil.
Bu problemin sadece Java dunyasina özgu oldugunu sanmiyorum. Eger hedefiniz hazir kutuphanelerin yeniden kullanilabildigi bir platform kurmaksa bu problemle eninde sonunda ugrasmaniz gerekiyor. Sonucta sizin uygulamaniz A kutuphanesinin x.y.z versiyonuna bagimliysa ve kullandiginiz bir kutuphane de a.b.c versiyonunu istiyorsa elden pek birsey gelmiyor. Tabi ki bu bagimlilik catismalari baska yollarla cözuebiliyor.
Örnegin npm bunu bagimli oldugunuz her modulun bagimliliklarini kendi icinde cekerek cözuyor fakat bu sefer de ayni kutuphanenin 10 farkli surumunun yuklenmesinden kaynaklanan sisme problemlerine denk gelebiliyorsunuz.
Bu problemin tek ve dogru bir cozumu oldugunu dusunmuyorum. Dilin ve gelistiricilerin ihtiyaclarina göre her platformda farkli cozumler uygulanmasindan yanayim. Java icin konusmak gerekirse: Bugune kadar Maven'in "transitive dependency" konusunun yarattigi basagrilari ile, ona cözum olarak sunulan ClassLoader tabanli cozumlerin sebep oldugu pek cok problem ile mucadele etmem gerekti. Ancak acikcasi bugune kadar bagimliliklarini duzgun yöneten ve gunceli takip eden hicbir uygulamada bu tip sorunlara denk gelmedim (bu sorunlar hic olmadigindan degil, ama bana denk gelmedi). Dahasi genellikle bu tip problemler bilindigi ve Java'nin kullanici tabani da gayet genis oldugu icin siklikla bu problemleri cozmekte kullanabilecegim pek cok aracin varligini kesfettim.
Bu bir iki sene icinde yavas yavas Java 8'e gececek kurumlari dusunuyorum. :)