Mempelajari Pemrograman Swift: Apakah Sudah Siap untuk Prime Time?

Peluncuran Swift bulan Juni lalu, bahasa pemrograman baru untuk menulis aplikasi iOS, menciptakan banyak gebrakan dan kegembiraan di seluruh komunitas pengembang iOS.

Sejak diluncurkan, banyak pengembang iOS telah berjuang dengan pertanyaan apakah, bagaimana, dan kapan harus beralih dari Objective-C ke Swift. Jawaban atas pertanyaan tersebut tentunya akan berbeda untuk setiap tim dan setiap proyek.

Ada sejumlah artikel yang dapat Anda baca yang mencakup banyak keunggulan Swift. Jadi, alih-alih mengulangi poin yang sama, dalam artikel ini kami akan berfokus pada beberapa masalah yang mungkin ingin Anda pertimbangkan sebelum mempelajari pengembangan aplikasi dengan Swift.

Tapi pertama-tama, mari kita putar waktu sedikit ke belakang…

Sebelum Swift: Anda akan menggunakan Objective-C, dan Anda akan menyukainya…

Saat itu tahun 2010. iPhone belum berusia 3 tahun, dan kemampuan untuk menulis aplikasi asli untuk iPhone baru ada sekitar 2 tahun. Pada tanggal 8 April tahun itu, Apple mengumumkan versi iPhone OS. iPhone OS (sebelum berganti nama menjadi iOS) menyertakan fitur-fitur baru yang menggiurkan seperti multitasking, peralihan aplikasi yang cepat, dan layanan latar belakang. Dapat dimengerti, pengembang iPhone sangat ingin mendapatkan SDK baru dan mulai bermain dengan semua fitur baru yang menarik itu.

Tetapi iPhone OS 4 SDK berisi kejutan yang tidak terduga. Bom ini tidak ada dalam perangkat lunak, itu dalam perjanjian penggunaan. Dengan iPhone OS 4 SDK, Bagian 3.3.1 dari Perjanjian Pengembang telah diperbarui untuk menyertakan bahasa bermasalah berikut:

Aplikasi awalnya harus ditulis dalam Objective-C, C, C++ … dan hanya kode yang ditulis dalam C, C++, dan Objective-C yang dapat dikompilasi dan ditautkan langsung ke Documented APIs.
– Bagian 3.3.1 dari Perjanjian Pengembang SDK iPhone OS 4

Tak perlu dikatakan, pembatasan baru ini mengejutkan banyak pengembang. Alasan resmi untuk perubahan tersebut, yang diberikan oleh Steve Jobs sendiri, adalah untuk mencegah penggunaan alat lintas platform seperti Flash CS5 yang baru-baru ini diumumkan. Jobs dikutip mengatakan bahwa "lapisan perantara antara platform dan pengembang pada akhirnya menghasilkan aplikasi sub-standar [sic]". Tetapi fakta bahwa pendekatan Apple untuk memerangi "lapisan menengah" ini adalah dengan membatasi bahasa pemrograman apa yang dapat digunakan untuk menulis aplikasi iPhone mengungkapkan lebih banyak tentang pemikiran Apple: Objective-C harus cukup baik untuk siapa saja.

Seseorang dapat dimaafkan jika setuju dengan pernyataan ini, karena Objective-C memenangkan penghargaan "Bahasa Pemrograman Tahun Ini" dari Indeks Tiobe dua tahun berturut-turut. Tetapi kenyataannya adalah bahwa popularitas Objective-C adalah fungsi dari ekosistem aplikasi yang berkembang, dan bukan sebaliknya. Bahkan di tahun 2010, banyak orang sudah tidak puas dengan Objective-C dan, sebagai hasilnya, cara alternatif untuk menulis aplikasi iPhone dalam bahasa pemrograman lain sudah bermunculan.

Akhirnya, di bawah tekanan dari komunitas pengembang pada umumnya, Apple membatalkan perubahan ini pada Bagian 3.3.1 dari Perjanjian Pengembang SDK hanya lima bulan kemudian. Namun, pesannya jelas: jika Anda ingin menulis aplikasi untuk iPhone, Anda mungkin harus menggunakan Objective-C.

… atau mungkin tidak. Masukkan bahasa iOS baru Swift.

Maju cepat 4 tahun sejak kejadian itu hingga Juni 2014 ketika Apple memperkenalkan pengembang ke bahasa barunya, Swift. Jika pesan 4 tahun sebelumnya adalah bahwa Apple sangat puas dengan Objective-C, maka pesan yang dikirim oleh perkenalan Swift adalah bahwa Apple akhirnya siap untuk mengakui kebenaran. Objective-C mungkin belum tentu menjadi bahasa terbaik untuk menulis aplikasi seluler.

Banyak yang telah dikatakan tentang bagaimana Swift adalah bahasa yang lebih "modern" daripada Objective-C. Jika Anda tertarik dengan cara mempelajari bahasa pemrograman Swift, Anda mungkin ingin melihat panduan untuk berpindah dari Objective-C ke Swift.

Namun, yang harus Anda perhatikan adalah bahwa ada dua perbedaan penting antara bahasa Objective-C dan Swift:

1. Swift bukan superset ketat dari bahasa C.
2. Swift diketik secara statis, bukan diketik secara dinamis.

Tidak menjadi superset ketat dari C berarti Swift bebas menggunakan konstruksi sintaksis yang seharusnya tidak diizinkan. Ini memungkinkan, misalnya, untuk mengimplementasikan operator khusus di Swift.

Diketik secara statis berarti Swift dapat memanfaatkan banyak kemajuan terbaru dalam sistem ketik yang dipelopori oleh bahasa seperti Haskell.

Meskipun telah dikembangkan selama 4 tahun sebelum diungkapkan ke publik, Swift masih merupakan bahasa pemrograman yang masih muda, sehingga ia hadir dengan sejumlah peringatan.

Kompatibilitas dengan Objective-C

iOS berbagi warisan yang sama dengan OS X, yang pada gilirannya mengambil sejarahnya dari sistem operasi NeXTSTEP yang pertama kali dirilis pada tahun 1989. NeXTSTEP awalnya ditulis sebagian besar di Objective-C, dan banyak perpustakaan inti di OS X dan iOS melacak akarnya semua jalan kembali ke implementasi asli ini. (Kebetulan, di sinilah awalan “NS” yang ada di mana-mana ditemukan pada kelas inti seperti NSString berasal.) Sementara Swift secara teoritis bisa ada tanpa adanya pustaka inti ini, kenyataannya adalah bahwa program Swift apa pun yang mungkin Anda tulis dalam waktu dekat harus berinteraksi dengan Objective-C.

Untuk penghargaan mereka, para pengembang di belakang Swift telah melakukan pekerjaan yang fantastis dengan membuat interaksi dengan perpustakaan Objective-C yang ada semudah mungkin. Itu tidak berarti bahwa prosesnya benar-benar bebas rasa sakit. Apple telah memberikan panduan bermanfaat yang menjelaskan cara memanggil kode Objective-C dari Swift, dan sebaliknya, tetapi ada beberapa ketidakcocokan impedansi penting yang harus diperhatikan.

Mungkin ketidakcocokan yang paling jelas berkaitan dengan file header. Objective-C, karena akar C-nya, masih mengharuskan fungsi dideklarasikan sebelum dipanggil. Saat memanggil ke perpustakaan, deklarasi ini akan ditemukan di file header perpustakaan. Swift, bagaimanapun, tidak menggunakan file header. Jadi, jika Anda ingin memanggil kode Swift dari Objective-C, Anda harus membuat "header penghubung" terlebih dahulu. Meskipun secara konseptual ini mungkin tidak tampak rumit, dalam praktiknya, ini sebenarnya bisa menjadi tugas yang cukup berat.

Seperangkat komplikasi lain dalam antarmuka antara Swift dan Objective-C berasal dari perbedaan yang melekat dalam sistem tipe mereka. Swift, mengambil isyarat dari bahasa modern lainnya, telah menghilangkan konsep nil . Sebagai gantinya adalah tipe opsional Swift. Misalnya, metode yang membuka file hanya jika sudah ada akan memiliki tipe pengembalian File? (bukan hanya File ) di Swift. Dengan melacak semua tempat di mana tipe adalah opsional, kompiler Swift dapat secara efektif membuat tidak mungkin menemukan "Kesalahan Pointer Null" yang ditakuti. Itu, tentu saja, kecuali Anda memanggil Objective-C. Karena Objective-C tidak memberikan jaminan untuk tidak mengembalikan nil , Swift memiliki kategori tipe khusus yang disebut Opsional yang Dibuka Secara Implisit yang digunakan saat memanggil kode Objective-C. Jenis ini dapat diperlakukan sebagai opsional dalam bahasa Swift, bersama dengan semua biaya tambahan yang diperlukan untuk pemeriksaan keberadaan. Atau, mereka dapat digunakan sama seperti jenis non-opsional, tetapi jika Objective-C tidak mengembalikan nil , Anda akan berakhir dengan kesalahan runtime, sehingga Anda kehilangan beberapa jaminan keamanan waktu kompilasi Swift.

Akhirnya, ketidakcocokan yang sedikit lebih halus untuk dipertimbangkan ketika pemrograman di antara Swift dan Objective-C berkaitan dengan bagaimana objek dan kelas dibuat di bawah penutup dalam dua bahasa ini. Objective-C, karena sifatnya yang dinamis, menggunakan pengiriman dinamis untuk memanggil metode pada objek (melalui objc_msgSend ). Swift tentu saja dapat menggunakan pengiriman dinamis, tetapi karena diketik secara statis, ia juga memiliki opsi untuk menggunakan vtable untuk menyimpan pointer fungsi untuk setiap metode. Manakah dari dua mekanisme yang digunakan Swift ini bergantung pada beberapa faktor. Objek Swift Lama Pesawat akan menggunakan mekanisme vtable , kecuali kelas atau metode di dalam kelas dijelaskan menggunakan atribut @objc Swift. Kelas Swift yang mewarisi dari kelas Objective-C akan menggunakan pengiriman dinamis untuk metode yang diwarisi, tetapi tidak untuk metode baru apa pun yang diperkenalkan oleh subkelas (meskipun, sekali lagi, Anda dapat memaksa penggunaan pengiriman dinamis dengan atribut @objc ). Terlepas dari itu, kode Swift akan selalu dapat bekerja dengan kelas Swift, tetapi kode Objective-C hanya dapat menggunakan objek dan metode Swift yang telah dianotasi dengan benar.

Lebih cepat dari Objective-C?

Saat Apple memperkenalkan peluncurannya, salah satu keunggulan Swift yang sangat ditonjolkan adalah kecepatannya. Ini dapat dimengerti ketika Anda mempertimbangkan bahwa salah satu alasan yang sering diberikan untuk keengganan Apple untuk beralih dari Objective-C ke bahasa tingkat yang lebih tinggi adalah bahwa Objective-C, yang pada dasarnya merupakan ekstensi ke C, mampu membuat program yang jauh lebih cepat dan lebih efisien. daripada sesuatu seperti Python atau Ruby. Meski begitu, Objective-C bukanlah kapal roket dalam hal kinerja absolut, dan sebagian besar dapat dikaitkan dengan pengetikan dinamis. Jadi dengan Swift yang mengadopsi sistem tipe statis, orang akan berharap bahwa Swift setidaknya secepat, atau lebih cepat, daripada Objective-C.

Tentu saja, seperti kata pepatah, “Ada tiga jenis kebohongan: kebohongan, kebohongan terkutuk, dan tolok ukur.” (Atau sesuatu seperti itu…) Tentu saja, ada banyak alasan mengapa bahasa Swift dapat berjalan lebih cepat. Sayangnya, tampaknya cara Swift menggunakan teknik ARC (Penghitungan Referensi Otomatis) Apple untuk manajemen memori terkadang menyebabkan kompiler Swift menghasilkan program yang jauh lebih lambat, terutama dengan pengaturan pengoptimalan yang lebih rendah (seperti yang mungkin Anda gunakan selama pengembangan). Kabar baiknya adalah sepertinya peningkatan Swift terus mengatasi masalah ini, dan karena itu kemungkinan dalam waktu dekat Swift akan menghasilkan executable setidaknya secepat, atau lebih cepat, daripada Objective-C.

Namun, ada peringatan lain untuk kecepatan Swift. Inti dari Swift adalah bahwa pengembang tidak akan menulis kode yang sama dengan yang mereka tulis di Objective-C. Apa artinya ini untuk kinerja? Yah, tentu saja itu berarti membandingkan kinerja antara Swift dan Objective-C lebih terlibat daripada yang bisa diungkapkan oleh tolok ukur sederhana. Ini juga berarti bahwa membandingkan kinerja runtime absolut dari executable yang dihasilkan hanya menceritakan setengah dari cerita.

Semua orang menginginkan program yang cepat, tetapi seringkali kecepatan pengembangan sama – jika tidak lebih – penting. Bahasa yang lebih ekspresif, mampu menyelesaikan lebih banyak pekerjaan dalam lebih sedikit baris kode, dapat menjadi manfaat besar dalam hal ini. Di sisi lain, ketika bekerja dalam bahasa yang dikompilasi di mana siklus edit-kompilasi-jalankan-debug menghabiskan sebagian besar hari programmer, kompiler yang lambat benar-benar dapat merusak produktivitas. Meskipun buktinya bersifat anekdot, tampaknya kompiler Swift saat ini cukup lambat untuk mengganggu, terutama saat bekerja dengan kode yang menggunakan sistem tipe lanjutan Swift. Satu grup bahkan menemukan kecepatan kompilasi cukup bermasalah untuk memotivasi peralihan kembali ke Objective-C.

Kompilator

Berbicara tentang kompiler Swift, itu sendiri merupakan sumber lebih banyak peringatan ketika mempertimbangkan untuk beralih ke bahasa Swift yang baru. Selain kecepatan kompilasi, karena Swift telah muncul dari kader kecil pengembang yang bekerja dengannya di Apple dan diluncurkan ke massa, kompiler mulai menunjukkan celah di bawah tekanan. Bahkan ada seluruh repositori GitHub yang didedikasikan untuk mengumpulkan contoh kode yang akan menyebabkan kompiler Swift mogok.

Ada juga pertanyaan tentang bagaimana kompiler Swift akan berubah. Proyek lain di GitHub mengumpulkan spekulasi dan analisis dari komunitas tentang perubahan apa yang mungkin akan terjadi pada Swift. Misalnya, operator khusus dapat memberikan tekanan yang signifikan pada parser. Awalnya, operator khusus di Swift tidak dapat menggunakan karakter tanda tanya (?). Meskipun ini telah diperbaiki dalam rilis Swift terbaru, permintaan terus mengalir dari komunitas pengembang Swift yang berkembang untuk lebih banyak fleksibilitas dalam apa yang dapat dianggap sebagai operator khusus yang valid.

Setiap kali Anda mendengar bahwa parser untuk suatu bahasa sedang berubah, itu akan memberi Anda jeda. Pengurai bahasa adalah jantung dan jiwa dari bahasa pemrograman. Sebelum semantik bahasa apa pun dapat diterapkan untuk memberikan makna pada kode, parserlah yang menentukan kode apa yang valid dan tidak valid untuk memulai. Oleh karena itu, sangat menggembirakan bahwa Apple telah berjanji untuk memastikan beberapa tingkat kompatibilitas runtime untuk Swift. Namun, itu tidak selalu menjamin bahwa kode Swift akan berjalan tanpa dikompilasi ulang untuk setiap rilis baru Xcode dan/atau iOS. Juga tidak menjamin bahwa Anda tidak perlu menulis ulang sebagian dari kode Swift Anda agar tetap kompatibel dengan rilis Swift mendatang. Tetapi sekali lagi, komitmen Apple untuk membuat proses ini senyaman mungkin setidaknya merupakan sedikit penghiburan.

Masyarakat

Beberapa bahasa pemrograman terburuk yang pernah dibuat (yang akan tetap tanpa nama) telah didukung, lama setelah akal sehat mengatakan bahwa mereka seharusnya diturunkan ke tempat sampah teknologi yang gagal oleh kekuatan komunitas masing-masing saja. Pada saat yang sama, kumpulan bahasa pemrograman yang benar-benar bagus yang gagal bertahan karena kebutuhan komunitas terlalu banyak untuk dihitung. Komunitas yang kuat menghasilkan tutorial, menjawab pertanyaan di Stack Overflow, hang out online atau secara langsung di konferensi, berbagi cerita, tip, dan trik, serta menulis dan berbagi perpustakaan yang bermanfaat satu sama lain. Saat memilih bahasa apa yang akan digunakan untuk sebuah proyek, komunitas jelas merupakan sesuatu yang perlu dipertimbangkan.

Sayangnya, komunitas iOS/Objective-C tidak memiliki reputasi terbaik untuk bersikap ramah dan bersahabat. Itu secara bertahap berubah, dan open source semakin memainkan peran yang lebih penting dalam pengembangan Objective-C. Namun, pada tahap awal ini sulit untuk mengatakan seperti apa komunitas Swift kedepannya. Akankah sebagian besar terdiri dari pengembang picik yang hanya bekerja dari API Apple resmi dan koleksi kode pribadi mereka sendiri? Atau apakah ini akan menjadi komunitas yang dinamis dari grup yang berbagi tip, trik, dan perpustakaan yang bermanfaat?

Sisi lain dari peran komunitas adalah peran pengembang Swift itu sendiri. Tren keseluruhan dalam pemrograman telah beralih dari bahasa dan platform pemrograman berpemilik ke solusi open source. Pengembangan Open Source, terutama pada tingkat bahasa pemrograman dan runtime, dapat menjadi keuntungan nyata. Sementara pengembang Swift telah menyatakan berkali-kali bahwa niat mereka adalah untuk sepenuhnya membuka sumber bahasa Swift dan runtime, itu belum terjadi sehingga diperlukan kehati-hatian.

Konon, pengembang di belakang Swift adalah beberapa pengembang yang sama di belakang proyek LLVM yang sudah berjalan lama. LLVM bukanlah analogi yang sempurna, karena ia memulai kehidupan di tempat terbuka sebagai proyek dari University of Illinois, Urbana-Champaign. Tetapi untuk penghargaan mereka, pengembang inti tetap sangat terbuka dan terlibat dengan komunitas, bahkan setelah sebagian besar dari mereka beralih bekerja untuk Apple. Sangat masuk akal untuk mengharapkan bahwa bahasa Swift akan terus dikembangkan (kebanyakan) di tempat terbuka, meskipun apakah patch dan saran fitur dari komunitas akan berhasil masuk ke dalam bahasa masih harus dilihat.

Haruskah Saya Belajar Swift?

Tentu saja, tidak ada jawaban “satu ukuran cocok untuk semua” di sini. Seperti biasa, memilih alat yang tepat untuk pekerjaan itu membutuhkan pengetahuan mendalam tentang semua detail proyek yang bersangkutan. Tentu saja, pada saat ini, Objective-C tetap menjadi pilihan "aman" untuk pengembangan iOS, tetapi Swift jelas layak untuk dipertimbangkan.

Namun, perubahan paling signifikan yang dibawa Swift ke pengembangan iOS adalah bahwa banyak pengembang akan, untuk pertama kalinya, bertanya pada diri sendiri pertanyaan: "Bahasa apa yang harus saya gunakan?" Mengingat sejarah Apple, Objective-C, dan platform iOS, perubahan ini sendiri agak menarik, terutama mengingat pilihannya tidak biner. Sementara Apple telah memperjelas preferensi mereka, komunitas pengembang iOS pada umumnya telah bekerja keras selama bertahun-tahun untuk memberikan jawaban yang lebih mungkin untuk pertanyaan ini.