Swift vs. Objective-C: 10 powodów, dla których przyszłość faworyzuje Swift

Języki programowania nie umierają łatwo, ale sklepy programistyczne, które trzymają się zanikających paradygmatów, tak. Jeśli tworzysz aplikacje na urządzenia mobilne i nie zbadałeś Swift, zwróć uwagę: Swift nie tylko zastąpi Objective-C, jeśli chodzi o tworzenie aplikacji na Maca, iPhone'a, iPada, Apple Watcha i przyszłych urządzeń, ale zastąpi również C do programowania wbudowanego na platformach Apple.

Dzięki kilku kluczowym funkcjom Swift ma potencjał, aby stać się de facto językiem programowania do tworzenia wciągających, responsywnych aplikacji przeznaczonych dla konsumentów przez wiele lat.

Wydaje się, że Apple ma wielkie cele dla Swift. Zoptymalizował kompilator pod kątem wydajności i języka programowania, aw dokumentacji Swifta nawiązuje do tego, że Swift został „zaprojektowany do skalowania od„ hello, world ”do całego systemu operacyjnego”. Chociaż Apple nie określił jeszcze wszystkich swoich celów dla języka, wprowadzenie Xcode 6, Playgrounds i Swift razem sygnalizuje zamiar Apple, aby tworzenie aplikacji było łatwiejsze i bardziej przystępne niż w przypadku jakiegokolwiek innego łańcucha narzędzi programistycznych.

Oto 10 powodów, aby wyprzedzić grę, zaczynając już teraz pracę z Swift.

1. Szybki jest łatwiejszy do odczytania

Objective-C cierpi na wszystkie brodawki, jakich można oczekiwać od języka zbudowanego na C. Aby odróżnić słowa kluczowe i typy od typów C, Objective-C wprowadził nowe słowa kluczowe za pomocą symbolu @. Ponieważ Swift nie jest oparty na C, może ujednolicić wszystkie słowa kluczowe i usunąć liczne symbole @ przed każdym słowem kluczowym typu Objective-C lub związanym z obiektem.

Szybko upuszcza starsze konwencje. W związku z tym nie potrzebujesz już średników na końcach wierszy ani nawiasów do otaczania wyrażeń warunkowych w instrukcjach if / else. Inną dużą zmianą jest to, że wywołania metod nie zagnieżdżają się wewnątrz siebie, co powoduje powstanie piekła nawiasów - pa pa pa [[[ ]]]. Wywołania metod i funkcji w języku Swift używają standardowej listy parametrów rozdzielonych przecinkami w nawiasach. Rezultatem jest czystszy, bardziej wyrazisty język z uproszczoną składnią i gramatyką.

Swift kod bardziej przypomina naturalny angielski, oprócz innych współczesnych popularnych języków programowania. Ta czytelność ułatwia istniejącym programistom z JavaScript, Java, Python, C # i C ++ zaadoptowanie języka Swift do ich łańcucha narzędzi - w przeciwieństwie do brzydkiego kaczątka, które było Objective-C.

2. Szybki jest łatwiejszy w utrzymaniu

Dziedzictwo jest tym, co powstrzymuje Objective-C - język nie może ewoluować bez ewolucji C. C wymaga, aby programiści utrzymywali dwa pliki kodu w celu skrócenia czasu kompilacji i zwiększenia wydajności tworzenia wykonywalnej aplikacji, co przenosi się na Objective-C.

Swift rezygnuje z wymogu dwóch plików. Xcode i kompilator LLVM mogą automatycznie wykrywać zależności i wykonywać kompilacje przyrostowe w języku Swift 1.2. W rezultacie powtarzalne zadanie oddzielenia spisu treści (pliku nagłówkowego) od treści (pliku implementacji) należy już do przeszłości. Swift łączy nagłówek Objective-C (.h) i pliki implementacji (.m) w jeden plik kodu (.swift).

Dwuplikowy system Objective-C nakłada dodatkową pracę na programistów - i jest to praca, która odwraca uwagę programistów od szerszego obrazu. W Objective-C musisz ręcznie zsynchronizować nazwy metod i komentarze między plikami, miejmy nadzieję, używając standardowej konwencji, ale nie jest to gwarantowane, chyba że zespół ma na miejscu reguły i recenzje kodu.

Xcode i kompilator LLVM mogą pracować w tle, aby zmniejszyć obciążenie programisty. Dzięki Swift programiści zajmują się mniejszą księgowością i mogą spędzać więcej czasu na tworzeniu logiki aplikacji. Swift eliminuje standardowe prace i poprawia jakość kodu, komentarzy i obsługiwanych funkcji.

3. Swift jest bezpieczniejszy

Jednym z interesujących aspektów Celu-C jest sposób, w jaki obsługiwane są wskaźniki - szczególnie wskaźniki zerowe (zerowe). W Objective-C nic się nie dzieje, jeśli spróbujesz wywołać metodę ze zmienną wskaźnika, która jest zerowa (niezainicjowana). Wyrażenie lub wiersz kodu przestaje działać (nie działa) i chociaż może wydawać się korzystne, że nie ulega awarii, jest to ogromne źródło błędów. Brak operacji prowadzi do nieprzewidywalnego zachowania, co jest wrogiem programistów próbujących znaleźć i naprawić przypadkową awarię lub zatrzymać błędne zachowanie.

Typy opcjonalne sprawiają, że możliwość zerowej wartości opcjonalnej jest bardzo wyraźna w kodzie Swift, co oznacza, że ​​może generować błąd kompilatora podczas pisania złego kodu. Tworzy to krótką pętlę sprzężenia zwrotnego i pozwala programistom kodować z zamiarem. Problemy można naprawiać w trakcie pisania kodu, co znacznie zmniejsza ilość czasu i pieniędzy, które można wydać na naprawianie błędów związanych z logiką wskaźnika z Objective-C.

Tradycyjnie w Objective-C, jeśli wartość została zwrócona z metody, to programista był odpowiedzialny za udokumentowanie zachowania zwracanej zmiennej wskaźnikowej (przy użyciu komentarzy i konwencji nazewnictwa metod). W języku Swift opcjonalne typy i typy wartości jasno określają w definicji metody, czy wartość istnieje lub czy może być opcjonalna (to znaczy, że wartość może istnieć lub może być zerowa).

Aby zapewnić przewidywalne zachowanie, Swift wyzwala awarię środowiska wykonawczego, jeśli zostanie użyta zerowa zmienna opcjonalna. Ta awaria zapewnia spójne zachowanie, co ułatwia proces naprawiania błędów, ponieważ zmusza programistę do natychmiastowego naprawienia problemu. Awaria środowiska uruchomieniowego Swift zatrzyma się w wierszu kodu, w którym użyto zerowej zmiennej opcjonalnej. Oznacza to, że błąd zostanie naprawiony wcześniej lub całkowicie uniknięty w kodzie Swift.

4. Swift jest ujednolicony z zarządzaniem pamięcią

Swift ujednolica język w sposób, jakiego nigdy nie było w Objective-C. Obsługa automatycznego zliczania referencji (ARC) jest pełna w proceduralnych i obiektowych ścieżkach kodu. W Objective-C, ARC jest obsługiwane przez API Cocoa i kod obiektowy; nie jest jednak dostępny dla proceduralnego kodu C i interfejsów API, takich jak Core Graphics. Oznacza to, że to programista ponosi odpowiedzialność za zarządzanie pamięcią podczas pracy z interfejsami API Core Graphics i innymi niskopoziomowymi interfejsami API dostępnymi w systemie iOS. Ogromne wycieki pamięci, które może mieć programista w Objective-C, są niemożliwe w Swift.

Programista nie powinien myśleć o pamięci dla każdego obiektu cyfrowego, który tworzy. Ponieważ ARC obsługuje całe zarządzanie pamięcią w czasie kompilacji, siła umysłu, która poszłaby na zarządzanie pamięcią, może zamiast tego skupić się na podstawowej logice aplikacji i nowych funkcjach. Ponieważ ARC w języku Swift działa zarówno w kodzie proceduralnym, jak i obiektowym, nie wymaga już od programistów mentalnych przełączników kontekstu, nawet jeśli piszą kod, który dotyka interfejsów API niższego poziomu - problem z obecną wersją Objective-C.

Automatyczne i wydajne zarządzanie pamięcią to problem, który został rozwiązany, a firma Apple udowodniła, że ​​może zwiększyć produktywność. Innym efektem ubocznym jest to, że zarówno Objective-C, jak i Swift nie cierpią z powodu programu Garbage Collector, który czyści nieużywaną pamięć, taką jak Java, Go lub C #. Jest to ważny czynnik dla każdego języka programowania, który będzie używany do responsywnej grafiki i wprowadzania danych przez użytkownika, szczególnie na urządzeniu dotykowym, takim jak iPhone, Apple Watch lub iPad (gdzie opóźnienie jest frustrujące i sprawia, że ​​użytkownicy uważają, że aplikacja jest zepsuta).

5. Swift wymaga mniej kodu

Swift zmniejsza ilość kodu wymaganego do powtarzających się instrukcji i manipulacji na ciągach. W Objective-C praca z ciągami tekstowymi jest bardzo rozwlekła i wymaga wielu kroków, aby połączyć dwie informacje. Swift przyjmuje nowoczesne funkcje języka programowania, takie jak dodanie dwóch ciągów razem z operatorem „+”, którego brakuje w Objective-C. Obsługa łączenia znaków i ciągów, takich jak ta, ma fundamentalne znaczenie dla każdego języka programowania, który wyświetla tekst użytkownikowi na ekranie.

System typów w języku Swift zmniejsza złożoność instrukcji kodu - ponieważ kompilator może wykryć typy. Na przykład, celem C wymaga programistów zapamiętać ciąg znaków specjalnych ( %s, %d, %@) i dostarczyć listę oddzielonych zmiennych w celu zastąpienia każdego tokena. Swift obsługuje interpolację ciągów, co eliminuje potrzebę zapamiętywania tokenów i umożliwia programistom wstawianie zmiennych bezpośrednio do ciągu widocznego dla użytkownika, takiego jak etykieta lub tytuł przycisku. System wnioskowania typu i interpolacja ciągów znaków łagodzą typowe źródło awarii, które są powszechne w Objective-C.

W przypadku Objective-C zepsucie zamówienia lub użycie niewłaściwego tokena ciągu powoduje awarię aplikacji. Tutaj Swift ponownie zwalnia Cię z pracy księgowej, przekładając się na mniej kodu do napisania (kod, który jest teraz mniej podatny na błędy) ze względu na wbudowaną obsługę manipulowania ciągami tekstowymi i danymi.

6. Swift jest szybszy

Porzucenie starszych konwencji C znacznie poprawiło działanie Swifta pod maską. Testy porównawcze wydajności kodu Swift nadal wskazują na zaangażowanie Apple w poprawę szybkości, z jaką Swift może uruchamiać logikę aplikacji.

Według Primate Labs, twórców popularnego narzędzia wydajności GeekBench, Swift zbliżał się do charakterystyk wydajnościowych C ++ dla zadań związanych z obliczeniami w grudniu 2014 roku, używając algorytmu Mandelbrota.

W lutym 2015 r. Primate Labs odkryło, że Xcode 6.3 Beta poprawił wydajność algorytmu GEMM - algorytmu związanego z pamięcią - z sekwencyjnym dostępem do dużych macierzy - Swift o współczynnik 1,4. Początkowa implementacja FFT - algorytm związany z pamięcią z losowym dostępem do dużych macierzy - dała 2,6-krotny wzrost wydajności.

Dalsze ulepszenia zaobserwowano w Swift poprzez zastosowanie najlepszych praktyk, co skutkowało 8,5-krotnym wzrostem wydajności algorytmu FFT (pozostawiając C ++ tylko 1,1-krotny wzrost wydajności). Ulepszenia umożliwiły również Swiftowi przewyższenie C ++ dla algorytmu Mandelbrota zaledwie o współczynnik 1,03.

Swift prawie dorównuje C ++ zarówno w algorytmach FFT, jak i Mandelbrot. Według Primate Labs wydajność algorytmu GEMM sugeruje, że kompilator Swift nie może wektoryzować kodu, tak jak może to zrobić kompilator C ++ - łatwy wzrost wydajności, który można by osiągnąć w następnej wersji Swift.

7. Mniej kolizji nazw z projektami open source

Jednym z problemów, który nękał kod Objective-C, jest brak formalnego wsparcia dla przestrzeni nazw, co było rozwiązaniem C ++ do kodowania kolizji nazw plików. Gdy ta kolizja nazw ma miejsce w Objective-C, jest to błąd konsolidatora i aplikacja nie może działać. Istnieją obejścia, ale mają one potencjalne pułapki. Powszechną konwencją jest używanie dwu- lub trzyliterowych przedrostków w celu rozróżnienia kodu Objective-C napisanego, powiedzmy, przez Facebooka, od kodu własnego.

Swift zapewnia niejawne przestrzenie nazw, które pozwalają na istnienie tego samego pliku kodu w wielu projektach bez powodowania błędu kompilacji i wymagających nazw takich jak NSString (następny krok - firma Steve'a Jobsa po zwolnieniu z Apple) lub CGPoint (Core Graphics). Ostatecznie ta funkcja w Swift sprawia, że ​​programiści są bardziej produktywni i oznacza, że ​​nie muszą wykonywać księgowości, która istnieje w Objective-C. Możesz zobaczyć wpływ Swift za pomocą prostych nazw, takich jak Array, Dictionary i String zamiast NSArray, NSDictionary i NSString, które powstały z braku przestrzeni nazw w Objective-C.

W języku Swift przestrzenie nazw są oparte na celu, do którego należy plik kodu. Oznacza to, że programiści mogą rozróżniać klasy lub wartości za pomocą identyfikatora przestrzeni nazw. Ta zmiana w Swift jest ogromna. Znacznie ułatwia włączanie projektów, frameworków i bibliotek open source do twojego kodu. Przestrzenie nazw umożliwiają różnym producentom oprogramowania tworzenie tych samych nazw plików kodu bez obawy o kolizje podczas integracji projektów open source. Teraz zarówno Facebook, jak i Apple mogą używać pliku kodu obiektowego o nazwie FlyingCar.swift bez żadnych błędów i niepowodzeń kompilacji.

8. Swift obsługuje biblioteki dynamiczne

Największą zmianą w Swift, której nie poświęcono wystarczającej uwagi, jest przejście z bibliotek statycznych, które są aktualizowane w głównych wydaniach (iOS 8, iOS 7 itd.), Na biblioteki dynamiczne. Biblioteki dynamiczne to wykonywalne fragmenty kodu, które można połączyć z aplikacją. Ta funkcja umożliwia łączenie obecnych aplikacji Swift z nowszymi wersjami języka Swift w miarę jego ewolucji.

Deweloper przesyła aplikację wraz z bibliotekami, które są podpisane cyfrowo certyfikatem programistycznym w celu zapewnienia integralności (witaj, NSA). Oznacza to, że Swift może ewoluować szybciej niż iOS, co jest wymagane dla nowoczesnego języka programowania. Wszystkie zmiany w bibliotekach można uwzględnić w najnowszej aktualizacji aplikacji w App Store i wszystko po prostu działa.

Biblioteki dynamiczne nigdy nie były obsługiwane na iOS aż do premiery Swift i iOS 8, mimo że biblioteki dynamiczne były obsługiwane na Macu przez bardzo długi czas. Biblioteki dynamiczne są zewnętrzne w stosunku do pliku wykonywalnego aplikacji, ale są zawarte w pakiecie aplikacji pobranym z App Store. Zmniejsza początkowy rozmiar aplikacji, gdy jest ona ładowana do pamięci, ponieważ kod zewnętrzny jest połączony tylko wtedy, gdy jest używany.

Możliwość odroczenia ładowania w aplikacji mobilnej lub aplikacji osadzonej na Apple Watch poprawi postrzeganą wydajność dla użytkownika. Jest to jedna z różnic, które sprawiają, że ekosystem iOS jest bardziej responsywny. Apple skupił się na ładowaniu tylko zasobów, zasobów, a teraz skompilowany i połączony kod w locie. Ładowanie w locie skraca początkowy czas oczekiwania, aż zasób będzie rzeczywiście potrzebny do wyświetlenia na ekranie.