Swift vs. Objective-C: 10 alasan masa depan mendukung Swift

Bahasa pemrograman tidak mudah mati, tetapi toko pengembangan yang berpegang teguh pada paradigma yang memudar akan mati. Jika Anda mengembangkan aplikasi untuk perangkat seluler dan Anda belum menyelidiki Swift, perhatikan: Swift tidak hanya akan menggantikan Objective-C dalam hal mengembangkan aplikasi untuk Mac, iPhone, iPad, Apple Watch, dan perangkat yang akan datang, tetapi juga akan menggantikan C untuk pemrograman yang disematkan pada platform Apple.

Berkat beberapa fitur utama, Swift berpotensi menjadi bahasa pemrograman de-facto untuk membuat aplikasi yang imersif, responsif, dan menghadap konsumen di tahun-tahun mendatang.

Apple tampaknya memiliki tujuan besar untuk Swift. Ini telah mengoptimalkan kompiler untuk kinerja dan bahasa untuk pengembangan, dan itu menyinggung Swift yang "dirancang untuk skala dari 'halo, dunia' ke seluruh sistem operasi" dalam dokumentasi Swift. Meskipun Apple belum menyatakan semua tujuannya untuk bahasa tersebut, peluncuran Xcode 6, Playgrounds, dan Swift secara bersama-sama menandakan niat Apple untuk membuat pengembangan aplikasi lebih mudah dan lebih mudah didekati daripada dengan rantai alat pengembangan lainnya.

Berikut 10 alasan untuk menjadi yang terdepan dengan mulai bekerja dengan Swift sekarang.

1. Swift lebih mudah dibaca

Objective-C menderita semua kutukan yang Anda harapkan dari bahasa yang dibangun di atas C. Untuk membedakan kata kunci dan tipe dari tipe C, Objective-C memperkenalkan kata kunci baru menggunakan simbol @. Karena Swift tidak dibangun di atas C, itu dapat menyatukan semua kata kunci dan menghapus banyak simbol @ di depan setiap tipe Objective-C atau kata kunci yang berhubungan dengan objek.

Swift menjatuhkan konvensi lama. Dengan demikian, Anda tidak lagi memerlukan titik koma untuk mengakhiri baris atau tanda kurung untuk mengapit ekspresi bersyarat di dalam pernyataan if / else. Perubahan besar lainnya adalah bahwa pemanggilan metode tidak bertumpuk di dalam satu sama lain sehingga mengakibatkan braket hell — bye-bye [[[ ]]],. Panggilan metode dan fungsi di Swift menggunakan daftar parameter yang dipisahkan koma standar industri dalam tanda kurung. Hasilnya adalah bahasa yang lebih bersih dan ekspresif dengan sintaks dan tata bahasa yang disederhanakan.

Kode Swift lebih mirip dengan bahasa Inggris alami, selain bahasa pemrograman populer modern lainnya. Keterbacaan ini mempermudah pemrogram yang sudah ada dari JavaScript, Java, Python, C #, dan C ++ untuk mengadopsi Swift ke dalam rantai alat mereka — tidak seperti itik jelek yang merupakan Objective-C.

2. Swift lebih mudah dirawat

Legacy adalah yang menahan Objective-C — bahasa tidak dapat berkembang tanpa C berkembang. C mengharuskan pemrogram untuk memelihara dua file kode untuk meningkatkan waktu pembuatan dan efisiensi pembuatan aplikasi yang dapat dieksekusi, persyaratan yang dibawa ke Objective-C.

Swift menjatuhkan persyaratan dua file. Xcode dan compiler LLVM dapat mengetahui dependensi dan melakukan build inkremental secara otomatis di Swift 1.2. Akibatnya, tugas berulang untuk memisahkan daftar isi (file header) dari badan (file implementasi) adalah sesuatu dari masa lalu. Swift menggabungkan header Objective-C (.h) dan file implementasi (.m) ke dalam satu file kode (.swift).

Sistem dua file Objective-C memberlakukan pekerjaan tambahan pada pemrogram — dan pekerjaan itulah yang mengalihkan pemrogram dari gambaran yang lebih besar. Di Objective-C Anda harus menyinkronkan nama metode dan komentar antar file secara manual, mudah-mudahan menggunakan konvensi standar, tetapi ini tidak dijamin kecuali tim memiliki aturan dan tinjauan kode.

Xcode dan compiler LLVM dapat melakukan pekerjaan di belakang layar untuk mengurangi beban kerja programmer. Dengan Swift, programmer melakukan lebih sedikit pembukuan dan dapat menghabiskan lebih banyak waktu untuk membuat logika aplikasi. Swift memotong pekerjaan boilerplate dan meningkatkan kualitas kode, komentar, dan fitur yang didukung.

3. Swift lebih aman

Satu aspek menarik dari Objective-C adalah cara penanganan pointer — terutama pointer nil (null). Di Objective-C, tidak ada yang terjadi jika Anda mencoba memanggil metode dengan variabel pointer yang nil (tidak diinisialisasi). Ekspresi atau baris kode menjadi no-operation (no-op), dan meskipun tampaknya bermanfaat karena tidak macet, itu telah menjadi sumber bug yang sangat besar. Tanpa operasi menyebabkan perilaku yang tidak dapat diprediksi, yang merupakan musuh pemrogram yang mencoba menemukan dan memperbaiki kerusakan acak atau menghentikan perilaku tidak menentu.

Tipe opsional membuat kemungkinan nilai opsional nihil menjadi sangat jelas dalam kode Swift, yang berarti dapat menghasilkan kesalahan kompiler saat Anda menulis kode yang buruk. Ini menciptakan umpan balik singkat dan memungkinkan pemrogram membuat kode dengan niat. Masalah dapat diperbaiki saat kode ditulis, yang sangat mengurangi jumlah waktu dan uang yang akan Anda keluarkan untuk memperbaiki bug yang terkait dengan logika penunjuk dari Objective-C.

Secara tradisional, di Objective-C, jika sebuah nilai dikembalikan dari sebuah metode, itu adalah tanggung jawab pemrogram untuk mendokumentasikan perilaku variabel pointer yang dikembalikan (menggunakan komentar dan konvensi penamaan metode). Di Swift, tipe opsional dan tipe nilai membuatnya jelas secara eksplisit dalam definisi metode jika nilainya ada atau jika memiliki potensi untuk menjadi opsional (yaitu, nilainya mungkin ada atau mungkin nihil).

Untuk menyediakan perilaku yang dapat diprediksi, Swift memicu error runtime jika variabel opsional nihil digunakan. Kerusakan ini memberikan perilaku yang konsisten, yang memudahkan proses perbaikan bug karena memaksa pemrogram untuk segera memperbaiki masalah tersebut. Kerusakan waktu proses Swift akan berhenti di baris kode tempat variabel opsional nol telah digunakan. Ini berarti bug akan diperbaiki lebih cepat atau dihindari sepenuhnya dalam kode Swift.

4. Swift disatukan dengan manajemen memori

Swift menyatukan bahasa dengan cara yang tidak pernah dimiliki Objective-C. Dukungan untuk Penghitungan Referensi Otomatis (ARC) selesai di seluruh jalur kode prosedural dan berorientasi objek. Di Objective-C, ARC didukung dalam Cocoa API dan kode berorientasi objek; itu tidak tersedia, bagaimanapun, untuk kode C prosedural dan API seperti Core Graphics. Ini berarti menjadi tanggung jawab programmer untuk menangani manajemen memori saat bekerja dengan Core Graphics API dan API tingkat rendah lainnya yang tersedia di iOS. Kebocoran memori yang sangat besar yang dapat dialami seorang programmer di Objective-C tidak mungkin terjadi di Swift.

Seorang programmer tidak harus memikirkan memori untuk setiap objek digital yang dia buat. Karena ARC menangani semua manajemen memori pada waktu kompilasi, kekuatan otak yang akan mengarah pada manajemen memori malah dapat difokuskan pada logika aplikasi inti dan fitur baru. Karena ARC di Swift berfungsi di kedua kode prosedural dan berorientasi objek, itu tidak memerlukan lagi sakelar konteks mental untuk pemrogram, bahkan saat mereka menulis kode yang menyentuh API tingkat yang lebih rendah — masalah dengan versi Objective-C saat ini.

Otomatis dan manajemen memori berkinerja tinggi adalah masalah yang telah diselesaikan, dan Apple telah membuktikannya dapat meningkatkan produktivitas. Efek samping lainnya adalah Objective-C dan Swift tidak mengalami Garbage Collector yang sedang membersihkan memori yang tidak digunakan, seperti Java, Go, atau C #. Ini adalah faktor penting untuk bahasa pemrograman apa pun yang akan digunakan untuk grafik responsif dan masukan pengguna, terutama pada perangkat taktil seperti iPhone, Apple Watch, atau iPad (di mana jeda membuat frustrasi dan membuat pengguna merasa aplikasi rusak).

5. Swift membutuhkan lebih sedikit kode

Swift mengurangi jumlah kode yang diperlukan untuk pernyataan berulang dan manipulasi string. Di Objective-C, bekerja dengan string teks sangat bertele-tele dan membutuhkan banyak langkah untuk menggabungkan dua bagian informasi. Swift mengadopsi fitur bahasa pemrograman modern seperti menambahkan dua string bersama dengan operator “+”, yang tidak ada di Objective-C. Dukungan untuk menggabungkan karakter dan string seperti ini sangat penting untuk bahasa pemrograman apa pun yang menampilkan teks kepada pengguna di layar.

Sistem tipe di Swift mengurangi kompleksitas pernyataan kode - karena kompilator dapat mengetahui tipe. Sebagai contoh, Objective-C membutuhkan programmer untuk menghafal token string khusus ( %s, %d, %@) dan memberikan daftar dipisahkan koma variabel untuk mengganti setiap tanda. Swift mendukung interpolasi string, yang menghilangkan kebutuhan untuk menghafal token dan memungkinkan pemrogram memasukkan variabel langsung sebaris ke string yang menghadap pengguna, seperti label atau judul tombol. Jenis sistem inferensia dan interpolasi string mengurangi sumber umum error yang umum di Objective-C.

Dengan Objective-C, mengacaukan urutan atau menggunakan token string yang salah menyebabkan aplikasi mogok. Di sini, Swift sekali lagi membebaskan Anda dari pekerjaan pembukuan, menerjemahkan ke lebih sedikit kode untuk ditulis (kode yang sekarang lebih rentan kesalahan) karena dukungan sebarisnya untuk memanipulasi string teks dan data.

6. Swift lebih cepat

Menghilangkan konvensi C lama telah sangat meningkatkan kemampuan Swift. Tolok ukur untuk kinerja kode Swift terus menunjukkan dedikasi Apple untuk meningkatkan kecepatan di mana Swift dapat menjalankan logika aplikasi.

Menurut Primate Labs, pembuat alat kinerja GeekBench yang populer, Swift mendekati karakteristik kinerja C ++ untuk tugas terikat komputasi pada Desember 2014 menggunakan algoritme Mandelbrot.

Pada bulan Februari 2015, Primate Labs menemukan bahwa Xcode 6.3 Beta meningkatkan kinerja Swift dari algoritme GEMM — algoritme terikat memori dengan akses sekuensial dari larik besar — ​​dengan faktor 1,4. Implementasi FFT awal — algoritme terikat memori dengan akses acak dari array besar — ​​memiliki peningkatan kinerja 2,6 kali lipat.

Peningkatan lebih lanjut diamati di Swift dengan menerapkan praktik terbaik, menghasilkan peningkatan 8,5 kali lipat untuk kinerja algoritme FFT (menyisakan C ++ dengan hanya peningkatan kinerja 1,1 kali). Penyempurnaan tersebut juga memungkinkan Swift mengungguli C ++ untuk algoritme Mandelbrot dengan faktor hanya 1,03.

Swift hampir setara dengan C ++ untuk algoritme FFT dan Mandelbrot. Menurut Primate Labs, performa algoritme GEMM menunjukkan bahwa compiler Swift tidak dapat melakukan vektorisasi kode yang dapat dilakukan oleh compiler C ++ - peningkatan performa yang mudah yang dapat dicapai dalam versi Swift berikutnya.

7. Lebih sedikit benturan nama dengan proyek open source

Satu masalah yang mengganggu kode Objective-C adalah kurangnya dukungan formal untuk ruang nama, yang merupakan solusi C ++ untuk benturan nama file kode. Jika benturan nama ini terjadi di Objective-C, itu adalah kesalahan penaut, dan aplikasi tidak dapat berjalan. Ada beberapa solusi yang tersedia, tetapi memiliki potensi jebakan. Ketentuan umum adalah menggunakan awalan dua atau tiga huruf untuk membedakan kode Objective-C yang ditulis, katakanlah, oleh Facebook versus kode Anda sendiri.

Swift menyediakan namespace implisit yang memungkinkan file kode yang sama ada di beberapa project tanpa menyebabkan kegagalan build dan memerlukan nama seperti NSString (Langkah Berikutnya - perusahaan Steve Jobs setelah dipecat dari Apple) atau CGPoint (Core Graphics). Pada akhirnya, fitur di Swift ini membuat pemrogram lebih produktif dan berarti mereka tidak perlu melakukan pembukuan yang ada di Objective-C. Anda dapat melihat pengaruh Swift dengan nama sederhana seperti Array, Dictionary, dan String, bukan NSArray, NSDictionary, dan NSString, yang lahir dari kurangnya namespace di Objective-C.

Dengan Swift, namespace didasarkan pada target yang dimiliki file kode. Ini berarti programmer dapat membedakan kelas atau nilai menggunakan pengenal ruang nama. Perubahan Swift ini sangat besar. Ini sangat memudahkan penggabungan proyek open source, kerangka kerja, dan pustaka ke dalam kode Anda. Namespace memungkinkan perusahaan perangkat lunak yang berbeda untuk membuat nama file kode yang sama tanpa mengkhawatirkan tabrakan saat mengintegrasikan proyek sumber terbuka. Sekarang Facebook dan Apple dapat menggunakan file kode objek bernama FlyingCar.swift tanpa kesalahan atau kegagalan pembuatan.

8. Swift mendukung perpustakaan dinamis

Perubahan terbesar di Swift yang kurang mendapat perhatian adalah peralihan dari pustaka statis, yang diperbarui pada rilis poin utama (iOS 8, iOS 7, dan seterusnya), ke pustaka dinamis. Perpustakaan dinamis adalah potongan kode yang dapat dieksekusi yang dapat ditautkan ke aplikasi. Fitur ini memungkinkan aplikasi Swift saat ini ditautkan dengan versi bahasa Swift yang lebih baru seiring perkembangannya dari waktu ke waktu.

Pengembang mengirimkan aplikasi bersama dengan pustaka, keduanya ditandatangani secara digital dengan sertifikat pengembangan untuk memastikan integritas (halo, NSA). Ini berarti Swift dapat berkembang lebih cepat daripada iOS, yang merupakan persyaratan untuk bahasa pemrograman modern. Perubahan pada perpustakaan semuanya dapat disertakan dengan pembaruan terbaru aplikasi di App Store, dan semuanya berfungsi dengan mudah.

Perpustakaan dinamis tidak pernah didukung di iOS hingga peluncuran Swift dan iOS 8, meskipun perpustakaan dinamis telah didukung di Mac untuk waktu yang sangat lama. Library dinamis berada di luar aplikasi yang dapat dieksekusi, tetapi disertakan dalam app bundle yang diunduh dari App Store. Ini mengurangi ukuran awal aplikasi saat dimuat ke memori, karena kode eksternal hanya ditautkan saat digunakan.

Kemampuan untuk menunda pemuatan di aplikasi seluler atau aplikasi yang disematkan di Apple Watch akan meningkatkan kinerja yang dirasakan oleh pengguna. Inilah salah satu perbedaan yang membuat ekosistem iOS terasa lebih responsif. Apple telah difokuskan untuk memuat hanya aset, sumber daya, dan sekarang menyusun dan menautkan kode dengan cepat. Pemuatan on-the-fly mengurangi waktu tunggu awal hingga sumber daya benar-benar dibutuhkan untuk ditampilkan di layar.