Swift Programlama Öğrenmek: Prime Time için Hazır mı?

Apple'ın iOS uygulamaları yazmak için yeni bir programlama dili olan Swift'i geçtiğimiz Haziran ayında piyasaya sürmesi, iOS geliştirici topluluğunda büyük bir heyecan ve heyecan yarattı.

Piyasaya sürülmesinden bu yana, birçok iOS geliştiricisi, Objective-C'den Swift'e geçiş yapılıp yapılmadığı, nasıl ve ne zaman yapılacağı sorusuyla mücadele ediyor. Bu sorunun cevabı elbette her takım ve her proje için farklı olacaktır.

Swift'in birçok avantajını kapsayan okuyabileceğiniz çok sayıda makale var. Bu nedenle, aynı noktaları yeniden ele almak yerine, bu makalede Swift ile uygulama geliştirmeyi öğrenmeden önce göz önünde bulundurmak isteyebileceğiniz bazı endişelere odaklanacağız.

Ama önce saati biraz geriye alalım…

Swift'den Önce: Objective-C kullanacaksınız ve beğeneceksiniz…

Yıl 2010'du. iPhone henüz 3 yaşında değildi ve iPhone için yerel uygulamalar yazma yeteneği sadece yaklaşık 2 yıldır vardı. O yılın 8 Nisan'ında Apple, iPhone işletim sisteminin sürümünü duyurdu. iPhone işletim sistemi (bu, adını iOS olarak değiştirmeden önceydi), çoklu görev, hızlı uygulama değiştirme ve arka plan hizmetleri gibi göz alıcı yeni özellikleri içeriyordu. Anlaşılacağı gibi, iPhone geliştiricileri yeni SDK'yı ele geçirmek ve tüm bu heyecan verici yeni özelliklerle oynamaya başlamak için sabırsızlanıyorlardı.

Ancak iPhone OS 4 SDK'sı beklenmedik bir bomba etkisi yarattı. Bu bomba yazılımda yoktu, kullanım sözleşmesinde vardı. iPhone OS 4 SDK ile, Geliştirici Sözleşmesinin 3.3.1 Bölümü, aşağıdaki sorunlu dili içerecek şekilde güncellendi:

Uygulamalar orijinal olarak Objective-C, C, C++ ile yazılmalıdır… ve yalnızca C, C++ ve Objective-C ile yazılmış kodlar derlenebilir ve Documented API'lere doğrudan bağlanabilir.
– iPhone OS 4 SDK Geliştirici Sözleşmesinin 3.3.1 Bölümü

Söylemeye gerek yok, bu yeni kısıtlama birçok geliştiriciyi şaşırttı. Steve Jobs tarafından sağlanan değişikliğin resmi nedeni, yakın zamanda duyurulan Flash CS5 gibi platformlar arası araçların kullanımını engellemekti. Jobs, “platform ile geliştirici arasındaki ara katmanların nihayetinde [sic] standart altı uygulamalar ürettiğini” söyledi. Ancak Apple'ın bu “ara katmanlarla” mücadele yaklaşımının, iPhone uygulamaları yazmak için hangi programlama dillerinin kullanılabileceğini kısıtlamak olduğu gerçeği, Apple'ın düşüncesi hakkında bir şeyi daha ortaya çıkardı: Objective-C herkes için yeterince iyi olmalı.

Objective-C, Tiobe Index'in “Yılın Programlama Dili” ödülünü iki yıl üst üste kazandığı için, bu iddiaya katılmak affedilebilir. Ancak gerçek şu ki, Objective-C'nin popülaritesi, büyüyen uygulama ekosisteminin bir işleviydi, tersi değil. 2010'da bile, birçok kişi Objective-C'den memnun değildi ve sonuç olarak, iPhone uygulamalarını diğer programlama dillerinde yazmanın alternatif yolları şimdiden ortaya çıkıyordu.

Sonunda, genel olarak geliştirici topluluğunun baskısı altında Apple, yalnızca beş ay sonra SDK Geliştirici Sözleşmesinin 3.3.1 Bölümünde yapılan bu değişiklikleri iptal etti. Yine de mesaj açıktı: iPhone için uygulamalar yazmak istiyorsanız, muhtemelen Objective-C kullanıyor olmalısınız.

… ya da belki değil. Yeni iOS dili Swift'i girin.

Bu olaydan 4 yıl sonra, Apple'ın geliştiricileri yeni dili Swift ile tanıştırdığı Haziran 2014'e kadar hızlı ileri sar. 4 yıl önceki mesaj Apple'ın Objective-C'den tamamen memnun olduğuysa, Swift'in tanıtımının gönderdiği mesaj Apple'ın nihayet gerçeği kabul etmeye hazır olduğuydu. Objective-C, mobil uygulamalar yazmak için mutlaka en iyi dil olmayabilir.

Swift'in Objective-C'den daha “modern” bir dil olduğu hakkında çok şey söylendi. Swift programlama dilini nasıl öğreneceğinizle ilgileniyorsanız, Objective-C'den Swift'e geçiş kılavuzuna göz atmak isteyebilirsiniz.

Bununla birlikte, dikkat etmeniz gereken şey, Objective-C ve Swift dilleri arasında iki önemli fark olduğudur:

1. Swift, C dilinin katı bir üst kümesi değildir .
2. Swift, dinamik olarak değil , statik olarak yazılır.

C'nin katı bir üst kümesi olmamak, Swift'in aksi halde izin verilmeyecek sözdizimi yapılarını kullanmakta özgür olduğu anlamına gelir. Bu, örneğin özel operatörlerin Swift'de uygulanmasını mümkün kılar.

Statik olarak yazılmış olmak, Swift'in Haskell gibi dillerin öncülük ettiği yazı sistemlerindeki son gelişmelerin çoğundan yararlanabileceği anlamına gelir.

Halka açıklanmadan önce 4 yıldır geliştiriliyor olmasına rağmen, Swift hala genç bir programlama dilidir, bu nedenle bir takım uyarılarla birlikte gelir.

Objective-C ile uyumluluk

iOS, OS X ile ortak bir mirası paylaşır ve bu da geçmişini ilk olarak 1989'da piyasaya sürülen NeXTSTEP işletim sisteminden alır. NeXTSTEP orijinal olarak büyük ölçüde Objective-C'de yazılmıştır ve OS X ve iOS'taki çekirdek kitaplıkların çoğu köklerinin izini sürer. bu orijinal uygulamalara dönüş yolu. (Bu arada, NSString gibi çekirdek sınıflarda bulunan her yerde bulunan “NS” önekinin geldiği yer burasıdır.) Swift teorik olarak bu çekirdek kütüphanelerin yokluğunda var olabilirken, gerçek şu ki, yakın gelecekte yazabileceğiniz herhangi bir Swift programı Objective-C ile arayüz oluşturmak zorunda kalacak.

Swift'in arkasındaki geliştiriciler, var olan Objective-C kitaplıklarıyla etkileşimi olabildiğince acısız hale getirerek harika bir iş çıkardılar. Bu, sürecin tamamen ağrısız olduğu anlamına gelmez. Apple, Objective-C kodunu Swift'den nasıl çağıracağınızı ve bunun tersini açıklayan yararlı bir kılavuz sağladı, ancak dikkat edilmesi gereken bazı önemli empedans uyumsuzlukları var.

Belki de en belirgin uyumsuzluk başlık dosyalarıyla ilgilidir. Objective-C, C kökleri nedeniyle hala işlevlerin çağrılmadan önce bildirilmesini gerektirir. Bir kitaplığa çağrı yapıldığında, bu bildirimler kitaplığın başlık dosyalarında bulunacaktır. Ancak Swift, başlık dosyalarını kullanmaz. Yani, Objective-C'den Swift kodunu çağırmak istiyorsanız, önce bir “köprüleme başlığı” oluşturmanız gerekecek. Kavramsal olarak bu o kadar karmaşık görünmese de, pratikte aslında oldukça görev olabilir.

Swift ve Objective-C arasındaki arabirimin bir başka komplikasyonu, tür sistemlerindeki doğal farklılıklardan kaynaklanmaktadır. Swift, diğer modern dillerden bir ipucu alarak, nil kavramını ortadan kaldırdı. Onun yerine Swift'in isteğe bağlı türleri var. Örneğin, bir dosyayı yalnızca zaten varsa açan bir yöntemin dönüş türü File? (sadece File yerine) Swift'de. Swift derleyicisi, türlerin isteğe bağlı olduğu tüm yerleri izleyerek, korkunç “Boş İşaretçi Hatası” ile karşılaşmayı etkili bir şekilde imkansız hale getirebilir. Tabii bu, Objective-C'yi aramadığınız sürece. Objective-C, nil döndürmeme konusunda böyle bir garanti vermediğinden, Swift, Objective-C kodu çağrılırken kullanılan, Implicitly Unwrapped Options adlı özel bir tür kategorisine sahiptir. Bu türler, varlık kontrolü için gerekli tüm ek masraflarla birlikte Swift dilinde isteğe bağlı olarak ele alınabilir. Alternatif olarak, isteğe bağlı olmayan herhangi bir türle aynı şekilde kullanılabilirler, ancak Objective-C nil döndürürse bir çalışma zamanı hatası alırsınız, bu nedenle Swift'in derleme zamanı güvenlik garantilerinden bazılarını kaybedersiniz.

Son olarak, Swift ve Objective-C arasında programlama yaparken göz önünde bulundurulması gereken biraz daha incelikli bir uyumsuzluk, bu iki dilde nesnelerin ve sınıfların gizli olarak nasıl oluşturulduğuyla ilgilidir. Objective-C, dinamik yapısı nedeniyle nesneler üzerindeki yöntemleri çağırmak için dinamik göndermeyi kullanır ( objc_msgSend aracılığıyla). Swift kesinlikle dinamik göndermeyi kullanabilir , ancak statik olarak yazıldığından, her yöntem için işlev işaretçilerini depolamak için bir vtable kullanma seçeneğine de sahiptir. Swift'in kullandığı bu iki mekanizmadan hangisi birkaç faktöre bağlıdır. Düzlem Eski Swift Nesneleri, sınıf veya sınıf içindeki yöntemler @objc Swift özniteliği kullanılarak açıklama yapılmadıkça vtable mekanizmasını kullanır. Objective-C sınıflarından miras alan Swift sınıfları, miras alınan yöntemler için dinamik göndermeyi kullanır, ancak alt sınıf tarafından tanıtılan yeni yöntemler için kullanılmaz (yine de, dinamik gönderme kullanımını @objc özniteliği ile zorlayabilirsiniz). Ne olursa olsun, Swift kodu her zaman Swift sınıflarıyla çalışabilecektir, ancak Objective-C kodu yalnızca düzgün açıklamalı Swift nesnelerini ve yöntemlerini kullanabilir.

Objective-C'den daha mı hızlı?

Apple lansmanını tanıttığında Swift'in özellikle vurgulanan faydalarından biri hızıydı. Apple'ın Objective-C'den daha yüksek seviyeli bir dile geçme konusundaki isteksizliğinin nedenlerinden birinin, esasen C'nin bir uzantısı olan Objective-C'nin çok daha hızlı, daha verimli programlar oluşturabilmesi olduğunu düşündüğünüzde, bu anlaşılabilir bir durumdur. Python veya Ruby gibi bir şeyden daha. Buna rağmen, mutlak performans söz konusu olduğunda Objective-C bir roket gemisi değildir ve bunun çoğu dinamik yazmaya atfedilebilir. Dolayısıyla Swift'in statik bir tip sistemi benimsemesiyle, Swift'in en az Objective-C'den daha hızlı veya daha hızlı olması beklenir.

Tabii ki, deyim yerindeyse, "Üç tür yalan vardır: yalanlar, kahrolası yalanlar ve ölçütler." (Ya da onun gibi bir şey…) Elbette, Swift dilinin daha hızlı çalışmasının sayısız nedeni var. Ne yazık ki, Swift'in bellek yönetimi için Apple'ın ARC (Otomatik Referans Sayma) tekniğini kullanma şekli bazen Swift'in derleyicisinin, özellikle daha düşük optimizasyon ayarlarıyla (geliştirme sırasında kullanabilecekleriniz gibi) önemli ölçüde daha yavaş programlar üretmesine neden oluyor gibi görünüyor. İyi haber şu ki, Swift'deki iyileştirmeler bu sorunu sürekli olarak ele alıyor gibi görünüyor ve bu nedenle yakın gelecekte Swift'in yürütülebilir dosyaları en az Objective-C'den daha hızlı veya daha hızlı üretmesi muhtemel.

Yine de Swift'in hızıyla ilgili başka bir uyarı var. Swift'in tüm amacı, geliştiricilerin Objective-C'de yazacakları kodun aynısını yazmayacak olmalarıdır. Bu performans için ne anlama geliyor? Bu, kesinlikle Swift ve Objective-C arasındaki performansı karşılaştırmanın basit kıyaslamaların ortaya çıkarabileceğinden daha fazla dahil olduğu anlamına gelir. Ayrıca, oluşturulan yürütülebilir dosyaların mutlak çalışma zamanı performansını karşılaştırmanın hikayenin yalnızca yarısını anlattığı anlamına gelir.

Herkes hızlı programlar ister, ancak çoğu zaman geliştirme hızı - daha fazla değilse - önemlidir. Daha anlamlı, daha az kod satırında daha çok iş başarabilen bir dil, bu konuda çok büyük fayda sağlayabilir. Öte yandan, düzenleme-derleme-çalıştır-hata ayıklama döngüsünün bir programcının gününün çoğunu kapladığı derlenmiş bir dilde çalışırken, yavaş bir derleyici üretkenliğe gerçekten zarar verebilir. Kanıtlar esasen anekdot niteliğinde olsa da, Swift derleyicisinin şu anda can sıkıcı olacak kadar yavaş olduğu görülüyor, özellikle de Swift'in gelişmiş tip sistemini çalıştıran kodlarla çalışırken. Bir grup, derleme hızının, Objective-C'ye geçişi motive edecek kadar sorunlu olduğunu bile buldu.

derleyici

Swift derleyicisinden bahsetmişken, yeni Swift diline geçiş yapmayı düşünürken daha da fazla uyarının kaynağıdır. Derleme hızının yanı sıra, Swift, Apple'da onunla çalışan küçük geliştiriciler kadrosundan çıkıp kitlelere salındığı için, derleyici stres altında çatlaklar göstermeye başladı. Swift derleyicisinin çökmesine neden olacak kod örneklerini toplamaya adanmış bütün bir GitHub deposu bile var.

Bir de Swift derleyicisinin nasıl değişeceği sorusu var. GitHub'daki başka bir proje, topluluktan Swift için ne gibi değişikliklerin olabileceğine dair spekülasyon ve analizler toplamaktır. Örneğin, özel operatörler bir ayrıştırıcıya önemli ölçüde yük bindirebilir. Başlangıçta, Swift'deki özel operatörler soru işareti (?) karakterini kullanamadı. Bu, en son Swift sürümünde düzeltilmiş olsa da, geçerli bir özel operatör olarak kabul edilebilecek şeylerde daha da fazla esneklik için büyüyen Swift geliştiricileri topluluğundan talepler gelmeye devam ediyor.

Bir dil için ayrıştırıcının akışta olduğunu her duyduğunuzda, sizi duraklatmalıdır. Bir dilin ayrıştırıcısı, bir programlama dilinin kalbi ve ruhudur. Herhangi bir dil semantiği, koda anlam vermek için uygulanmadan önce, başlangıçta geçerli kodun ne olduğunu ve neyin geçerli olmadığını belirleyen ayrıştırıcıdır. Öyleyse, Apple'ın Swift için bir miktar çalışma zamanı uyumluluğu sağlama sözü vermesi cesaret verici. Yine de bu, Swift kodunun her yeni Xcode ve/veya iOS sürümü için yeniden derlenmeden çalışacağını garanti etmez. Ayrıca Swift'in gelecekteki sürümleriyle uyumlu kalmak için Swift kodunuzun bölümlerini yeniden yazmanıza gerek kalmayacağını da garanti etmez. Ancak yine de, Apple'ın bu süreci olabildiğince acısız hale getirme taahhüdü, en azından küçük bir teselli.

Toplum

Şimdiye kadar yaratılmış en kötü programlama dillerinden bazıları (isimsiz kalacaklar), sağduyu, yalnızca kendi topluluklarının gücüyle başarısız teknolojinin çöp kutusuna atılması gerektiğini söyledikten çok sonra, desteklendi. Aynı zamanda, bir topluluğun eksikliği nedeniyle tutunamayan gerçekten güzel programlama dillerinin koleksiyonu sayılamayacak kadar çoktur. Güçlü topluluklar öğreticiler üretir, Stack Overflow ile ilgili soruları yanıtlar, çevrimiçi olarak veya konferanslarda hikayeler, ipuçları ve püf noktaları paylaşarak takılır ve birbirleriyle faydalı kitaplıklar yazıp paylaşır. Bir proje için hangi dili kullanacağınızı seçerken topluluk kesinlikle dikkate alınması gereken bir şeydir.

Ne yazık ki, iOS/Objective-C topluluğu, samimi ve konuksever olma konusunda en iyi itibara sahip değil. Bu yavaş yavaş değişiyor ve açık kaynak, Objective-C geliştirmede giderek daha önemli bir rol oynuyor. Yine de, bu erken aşamada Swift topluluğunun gelecekte nasıl görüneceğini söylemek zor. Çoğunlukla, yalnızca resmi Apple API'leri ve kendi özel kod koleksiyonları dışında çalışan bağımsız geliştiricilerden mi oluşacak? Yoksa ipuçlarını, püf noktalarını ve faydalı kitaplıkları paylaşan canlı bir grup topluluğu mu olacak?

Topluluğun rolünün bir başka yönü, Swift'in geliştiricilerinin kendilerinin rolüdür. Programlamadaki genel eğilim, tescilli programlama dillerinden ve platformlarından açık kaynaklı çözümlere geçmek olmuştur. Açık Kaynak geliştirme, özellikle programlama dilleri ve çalışma zamanları düzeyinde gerçek bir avantaj olabilir. Swift geliştiricileri, amaçlarının Swift dilini ve çalışma zamanını tamamen açık kaynak yapmak olduğunu defalarca belirtmiş olsa da, bu henüz gerçekleşmedi, bu yüzden dikkatli olunması gerekiyor.

Bununla birlikte, Swift'in arkasındaki geliştiriciler, uzun süredir devam eden LLVM projesinin arkasındaki aynı geliştiricilerden bazılarıdır. LLVM, Urbana-Champaign'deki Illinois Üniversitesi'nden bir proje olarak açıktan hayata başladığından beri mükemmel bir benzetme değildir. Ancak ana geliştiriciler, çoğu Apple için çalışmaya geçtikten sonra bile çok açık ve toplulukla etkileşimde kaldılar. Swift dilinin (çoğunlukla) açıkta geliştirilmeye devam etmesini beklemek tamamen mantıklı, ancak topluluktan gelen yamaların ve özellik önerilerinin dile gelip gelmeyeceğini göreceğiz.

Swift Öğrenmeli miyim?

Elbette burada "herkese uyan tek bir beden" yanıtı yok. Her zaman olduğu gibi, iş için doğru aracı seçmek, söz konusu projenin tüm detayları hakkında derin bilgi sahibi olmayı gerektirir. Elbette, bu noktada Objective-C, iOS geliştirme için “güvenli” seçim olmaya devam ediyor, ancak Swift kesinlikle dikkate alınmaya değer.

Yine de Swift'in iOS geliştirmeye getirdiği en önemli değişiklik, birçok geliştiricinin ilk kez kendilerine şu soruyu sorması: "Hangi dili kullanmalıyım?" Apple, Objective-C ve iOS platformunun geçmişi göz önüne alındığında, özellikle seçimin ikili olmadığı düşünüldüğünde, bu değişiklik tek başına oldukça heyecan verici. Apple tercihlerini açıkça belirtmiş olsa da, iOS geliştirici topluluğunun tamamı yıllardır bu soruya daha da olası cevaplar sağlamak için yoğun bir şekilde çalışıyor.