Kotlin Programlama Dili Hakkında Bir Kaç Düşünce

Yakında zamanda sırf Kotlin kullanarak bir Android projesini bitirdim ve düşüncelerimi genel olarak paylaşmak istedim Kotlin ile alakalı. Bu arada YouTube kanalımda ki Profesyonel Kotlin Dersleri eğitim serime bakmayı unutmayın.

Image for post
Image for post

Uzun yıllar C# kullanmış birisi olarak fazlasıyla yavaş gelişen Java’ya nazarla, modern yapıları çok daha önce kullanma şansım oldu. Örneğin lambda expression, delegate, first-class citizen functions, expression-bodied functions and properties, vs. bir dili zenginleştiren ve daha hızlı kod yazmayı kolaylaştıran özellikler. Aynı zamanda, doğru yerde kullandıklarında kodun okunmasını da kolaylaştırıyor bu yapılar. Java ile olan muhabbetim ise daha önceki şirkette Java ile yazılan ürüne yardım etmem için gönderilmem ile başladı. Daha önce kendi çapımda kullanıyor olmama rağmen, profesyonel manada kullanmam çokta eskilere dayanmıyor, tabi eğer 4–5 sene öncesi eski zaman olarak görülmüyorsa. Onun dışında ise Android içinde çok kullandım Javayı. Bu kadar bir girişten sonra asıl gelmek istediğim konuya geleyim: Kotlin.

Eski dillerin ve bu dillerin kullandığı framework’un yenilerine göre en büyük artısı, yıllarca kullanılmasından dolayı kurumsal seviyede benim gibi yazılımcılara daha çok güven vermesi. Hem documentation hem de community olarak daha zengin oluyorlar. Sorunların çoğuna cevaplar bulunmuş oluyor. Ama bir sorun var ki o da, C# gibi hızlı gelişen dillerde, maalesef her yeni gelen özellik, bir çözümün birden fazla yöntemi olmasına neden oluyor. Mesela, property tanımlamak isterseniz, aynı işi yapan 3–4 farklı syntax ile karşılaşabilirsiniz. Syntax’ı yalın hale getirme çabaları, zamanla dil içerisinde ezberlenmesi gereken bir sürü tanımın girmesine neden oluyor. Bir de zamanla bazı şeyler değiştirmek daha zor oluyor. Mesela, bir sınıfın aksi söylenmediği sürece ilk başta sealed yada final olması gerektiği gibi. Yazılımcılar olarak bizden sonra geleceklere kodumuzun kendisinin nasıl kullanılması gerektiğini kolay ve anlaşılır biçimde göstermesi lazım. Bundan dolayı kod içinde genişletilebilmesine izin verdiğimiz yerlerin bilinçli bir şekilde yazılması gerektiği gibi. Uzun yıllar kurumsal projeler yazıyorsanız, demek istediğimi anlamış olmalısınız.

Kotlin işte bu noktalarda farklılıklar gösteriyor. Birincisi JVM üzerinde çalışmak sayesinde, yıllarca her türlü darbeye göğüs germiş ve milyarlarca cihaz üzerinde çalışan bir sisteme yaslamış oluyor kendisini. Aynı zamanda, yazılımcıya yaptığı şeyleri daha bilinçli yapması için bazı zorluklar çıkarıyor gibi duruyor. Bunlar aslında yazılımcının bir yönden hayatını kurtarmak için eklemiş özellikler. Örneğin, değişken ve property’lere null değerinin otomatik olarak atanamıyor olması. Dolayısıyla, bir tipi null atanabilir olduğunu açık bir şekilde tanımlamak zorundasınız. Tabi, acemi bir yazılımcı bunları es geçecek ve uğraşmak istemediğinden dolayı herşeyi nullable olarak tanımlayacaktır. Eğer bu gibi insanlar ile çalışıyorsanız, nerede hata yaptığınızı düşünmek size kalmış. Bunların dışında, gereksiz bazı tekrarlardan kaçınmışlar. Mesela, property kullanmak her zaman daha mantıklı ve karlı iken, neden field ile uğraşmak isteyesiniz? Bir de Javaya kıyasla syntax olarak property’leri kullanmak daha kolay. setXXX() ya da getXXX() gibi methodları tanımlamak ile zaman israfından kaçınmışlar. Çoğu zaman bu methodlar sadece backing field değişkenlerinde ki değerleri döndürmek için işe yarıyordu. Hiç bir business değeri olmayan bu gereksiz tekrarlardan kurtulmak için IntelliJ gibi programlama ortamlarının sunduğu bazı kolaylıkları kullanıyorduk. Ama kodun üretimin zamanı daha kısa olmuş olsa bile, kodu okurken gereksiz bir ton şey görmek zorunda kalıyordunuz. Şu aşağıda ki kodun farkına bir bakar mısınız Allah aşkına:

Java ile olan 7 satır, Kotlin ile olan ise sadece bir satır. Yaptıkları iş ise aynı. Bir de ‘data class’ olayı var ki, yazılımcıya ettiği yardımdan dolayı, güzel günler çok yakın çığlıklarına sebep olabiliyor. Aslında bu Kotlin dilinin etkilendiği faktörüde gösteriyor: Yazılımcılar. Zamanla gelişen rekabet ve müşterilerin daha çok şey istemesi, yazılımcıların daha hızlı ürün geliştirme ihtiyacına neden oldu. Dolayısıyla, anlaşılır şekilde ne kadar az kod, o kadar çok kod başına iş değeri üretilmesi demek. Yukarıda ki farklılık basit dursa da, hem bu şekilde onlarca basitleştirilmiş özellik olması, hem de bunu kurumsal projelerde milyonlarca satır üzerinde yapıyor olmanız, işin boyutunu gözler önüne seriyor. Bu kısa kodların yapacağı değişimi kestiremiyorsanız, kurumsal projelerde özellikle de legacy yazılımlar ile çalışmamış olmanızdandır. O yazılımlar ki, bir yerine dokumanız, alakası olduğu aklınızın ucundan bile geçmeyen başka yerlerine bozulmasına neden olur. Çok değil, daha yeni böyle bir sorun ile uğraşmak zorunda kaldım iş yerinde.

Sonuç

Kotlin herşeyin çözümü değil. Kötü bir yazılımcı kendini geliştirmediği müddetçe her aracı kötü kullanmaya devam edecek. Ama araçların bu süreçte ki yardımlarını göz ardı etmek saçmalık. Onun için Kotlin’in sunacağı çok şey var. Yakın zamanda bir Android uygulaması yazdım Kotlin ile. Karşıma çıkan kod çok daha temiz oldu. Hem de çok zevk aldım Kotlin ile çalışırken. Öyleki, Kotlin ile alakalı eğitim videoları çekmeye başladım. Ama Kotlin’e karşı aynı duyguları yıllarca besler miyim bilmiyorum. Zaman ve Kotlin’in gelişimi göstercek bu sorunun cevabını. Şimdilik kalın sağlıcakla.

Written by

Senior Manager in Software Engineering. Former Technical Lead. Author of the book: Hands-on with Go http://amzn.to/2QYFoaV YT: http://youtube.com/c/tarikguney

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store