Суифт срещу Цел-С: 10 причини бъдещето да благоприятства Суифт

Езиците за програмиране не умират лесно, но магазините за разработки, които се придържат към избледняващите парадигми, умират. Ако разработвате приложения за мобилни устройства и не сте разследвали Swift, обърнете внимание: Swift не само ще измести Objective-C, когато става въпрос за разработване на приложения за Mac, iPhone, iPad, Apple Watch и бъдещите устройства, но също така ще замени C за вградено програмиране на платформи на Apple.

Благодарение на няколко ключови функции, Swift има потенциала да се превърне в фактически език за програмиране за създаване на завладяващи, отзивчиви, ориентирани към потребителите приложения за години напред.

Apple изглежда има големи цели за Swift. Той е оптимизирал компилатора за производителност и езика за разработка и намеква, че Swift е „проектиран да се мащабира от„ здравей, свят “до цяла операционна система“ в документацията на Swift. Въпреки че Apple все още не е посочила всичките си цели за езика, стартирането на Xcode 6, Playgrounds и Swift заедно показват намерението на Apple да направи разработката на приложения по-лесна и по-достъпна, отколкото с която и да е друга верига от инструменти за разработка.

Ето 10 причини да изпреварите играта, като започнете да работите със Swift сега.

1. Суифт е по-лесен за четене

Objective-C страда от всички брадавици, които бихте очаквали от език, изграден на C. За да разграничи ключовите думи и типовете от типовете C, Objective-C въведе нови ключови думи, използвайки символа @. Тъй като Swift не е изграден на C, той може да обедини всички ключови думи и да премахне многобройните символи @ пред всеки тип Objective-C или свързана с обект ключова дума.

Суифт отпада наследените конвенции. По този начин вече не се нуждаете от точка и запетая към крайните редове или скоби, за да обградите условни изрази вътре в if / else изрази. Друга голяма промяна е, че извикванията на методите не се влагат едно в друго, което води до адски скоби - чао-чао [[[ ]]],. Извикванията на методи и функции в Swift използват стандартния за индустрията списък с параметри в скоби. Резултатът е по-чист, по-изразителен език с опростен синтаксис и граматика.

Swift кодът наподобява повече естествения английски, в допълнение към други модерни популярни езици за програмиране. Тази четливост улеснява съществуващите програмисти от JavaScript, Java, Python, C # и C ++ да приемат Swift във веригата си от инструменти - за разлика от грозното пате, което беше Objective-C.

2. Суифт е по-лесен за поддръжка

Наследството е това, което задържа Objective-C обратно - езикът не може да се развива без C да се развива. C изисква програмистите да поддържат два кодови файла, за да подобрят времето за изграждане и ефективността на създаването на изпълними приложения, изискване, което се пренася в Objective-C.

Суифт отпада изискването за два файла. Xcode и компилаторът LLVM могат да разберат зависимости и да извършват автоматично нарастващи компилации в Swift 1.2. В резултат на това повтарящата се задача за отделяне на съдържанието (заглавен файл) от тялото (внедрен файл) е в миналото. Swift комбинира заглавката Objective-C (.h) и файловете за изпълнение (.m) в един кодов файл (.swift).

Двуфайловата система на Objective-C налага допълнителна работа на програмистите - и това е работата, която отвлича вниманието на програмистите от по-голямата картина. В Objective-C трябва ръчно да синхронизирате имената на методите и коментарите между файловете, надяваме се да използвате стандартна конвенция, но това не е гарантирано, освен ако екипът не разполага с правила и прегледи на кодове.

Xcode и компилаторът LLVM могат да работят зад кулисите, за да намалят натоварването на програмиста. С Swift програмистите правят по-малко счетоводство и могат да отделят повече време за създаване на логика на приложенията. Swift прекъсва работата с шаблони и подобрява качеството на кода, коментарите и поддържаните функции.

3. Суифт е по-безопасен

Един интересен аспект на Objective-C е начинът, по който се обработват указатели - особено нулеви (нулеви) указатели. В Objective-C нищо не се случва, ако се опитате да извикате метод с променлива на указателя, която е нула (неинициализирана). Изразът или редът на кода се превръщат в бездействие (no-op) и макар да изглежда полезно, че не се срива, той е огромен източник на грешки. Неоперацията води до непредсказуемо поведение, което е враг на програмистите, които се опитват да намерят и поправят случаен срив или да спрат хаотичното поведение.

Незадължителните типове правят възможността за нулева незадължителна стойност много ясна в Swift кода, което означава, че може да генерира грешка в компилатора, докато пишете лош код. Това създава кратък цикъл на обратна връзка и позволява на програмистите да кодират с намерение. Проблемите могат да бъдат отстранени при писане на код, което значително намалява количеството време и пари, които ще похарчите за отстраняване на грешки, свързани с логиката на указателя от Objective-C.

Традиционно, в Objective-C, ако дадена стойност беше върната от метод, отговорността на програмиста беше да документира поведението на върнатата променлива на указателя (използвайки коментари и конвенции за именуване на методи). В Swift незадължителните типове и типовете стойности ясно дават ясно да се разбере в дефиницията на метода дали стойността съществува или има потенциал да бъде незадължителна (т.е. стойността може да съществува или да е нула).

За да осигури предсказуемо поведение, Swift задейства срив по време на изпълнение, ако се използва нулева незадължителна променлива. Този срив осигурява последователно поведение, което улеснява процеса на отстраняване на грешки, защото принуждава програмиста да отстрани проблема веднага. Сривът на изпълнението на Swift ще спре на реда с код, където е използвана нулева незадължителна променлива. Това означава, че грешката ще бъде поправена по-рано или ще бъде избегната изцяло в Swift код.

4. Swift е унифициран с управление на паметта

Суифт обединява езика по начин, който Objective-C никога не е имал. Поддръжката за автоматично преброяване на референции (ARC) е пълна в процедурните и обектно-ориентираните кодови пътища. В Objective-C ARC се поддържа в API на какао и обектно-ориентиран код; не е налице обаче за процедурен C код и API като Core Graphics. Това означава, че става отговорност на програмиста да се справи с управлението на паметта, когато работи с Core Graphics API и други API на ниско ниво, налични в iOS. Огромните течове на памет, които програмистът може да има в Objective-C, са невъзможни в Swift.

Програмистът не трябва да мисли за паметта за всеки цифров обект, който създава. Тъй като ARC се справя с цялото управление на паметта по време на компилиране, мозъчната сила, която би отишла към управлението на паметта, може вместо това да бъде фокусирана върху основната логика на приложението и новите функции. Тъй като ARC в Swift работи както в процедурен, така и в обектно-ориентиран код, той не изисква повече превключватели на ментален контекст за програмисти, дори когато те пишат код, който докосва API на по-ниско ниво - проблем с текущата версия на Objective-C.

Автоматичното и високоефективно управление на паметта е решен проблем и Apple доказа, че може да увеличи производителността. Другият страничен ефект е, че и Objective-C, и Swift не страдат от Garbage Collector, който работи за почистване на неизползвана памет, като Java, Go или C #. Това е важен фактор за всеки език за програмиране, който ще се използва за отзивчива графика и въвеждане от потребителя, особено на тактилно устройство като iPhone, Apple Watch или iPad (където изоставането е разочароващо и кара потребителите да усетят, че приложението е счупено).

5. Swift изисква по-малко код

Swift намалява количеството код, което е необходимо за повтарящи се оператори и манипулиране на низове. В Objective-C работата с текстови низове е много подробна и изисква много стъпки за комбиниране на две части информация. Swift възприема съвременни функции на езика за програмиране като добавяне на два низа заедно с оператор „+“, който липсва в Objective-C. Поддръжката за комбиниране на символи и низове като тази е от основно значение за всеки език за програмиране, който показва текст на потребител на екран.

Типовата система в Swift намалява сложността на кодовите инструкции - тъй като компилаторът може да разбере типовете. Като пример, Objective-C изисква програмистите да запомните специални жетони низ ( %s, %d, %@) и да представят разделен със запетаи списък на променливи, за да замените всеки знак. Swift поддържа интерполация на низове, което елиминира необходимостта от запаметяване на маркери и позволява на програмистите да вмъкват променливи директно вградени в низ, обърнат към потребителя, като етикет или заглавие на бутон. Системата за инфериране на типа и интерполация на низове намаляват общия източник на сривове, които са често срещани в Objective-C.

С Objective-C объркването на поръчката или използването на грешен маркер на низа причинява срив на приложението. Тук Swift отново ви освобождава от счетоводната работа, като превежда в по-малко код за писане (код, който сега е по-малко склонен към грешки) поради вградената си поддръжка за манипулиране на текстови низове и данни.

6. Суифт е по-бърз

Отпадането на старите конвенции C значително подобри Swift под капака. Бенчмарковете за изпълнение на кода на Swift продължават да сочат към отдадеността на Apple да подобри скоростта, с която Swift може да изпълнява логиката на приложението.

Според Primate Labs, създатели на популярния инструмент за производителност GeekBench, Swift се доближава до характеристиките на производителността на C ++ за задачи, свързани с изчисления през декември 2014 г., използвайки алгоритъма Mandelbrot.

През февруари 2015 г. Primate Labs откриха, че Xcode 6.3 Beta подобри производителността на Swift на алгоритъма GEMM - алгоритъм, свързан с памет с последователен достъп до големи масиви - с коефициент 1,4. Първоначалното внедряване на FFT - алгоритъм, свързан с памет с произволен достъп до големи масиви - имаше подобрение на производителността 2,6 пъти.

По-нататъшни подобрения бяха наблюдавани в Swift чрез прилагане на най-добрите практики, което доведе до 8,5-кратен тласък за изпълнение на алгоритъма на FFT (оставяйки C ++ само с 1,1-кратно увеличение на производителността). Подобренията също така позволиха на Swift да надмине C ++ за алгоритъма на Mandelbrot с коефициент от само 1,03.

Суифт е почти равен на C ++ както за алгоритмите FFT, така и за Mandelbrot. Според Primate Labs, производителността на алгоритъма GEMM предполага, че компилаторът Swift не може да векторизира кода на компилатора C ++ - лесна печалба в производителността, която може да бъде постигната в следващата версия на Swift.

7. По-малко сблъсъци на имена с проекти с отворен код

Един проблем, който измъчва кода на Objective-C, е липсата му на официална поддръжка за пространства от имена, което беше решението на C ++ за сблъсъци на имена на файлове. Когато това сблъсък на име се случи в Objective-C, това е грешка на линкер и приложението не може да се стартира. Заобиколни решения съществуват, но те имат потенциални клопки. Обичайната конвенция е да се използват префикси с две или три букви, за да се разграничи код Objective-C, който е написан, да речем, от Facebook спрямо вашия собствен код.

Swift предоставя имплицитни пространства от имена, които позволяват един и същ кодов файл да съществува в множество проекти, без да причинява неуспех при изграждането и да изисква имена като NSString (Следваща стъпка - компанията на Стив Джобс след уволнение от Apple) или CGPoint (Core Graphics). В крайна сметка тази функция в Swift поддържа програмистите по-продуктивни и означава, че не е нужно да правят счетоводството, което съществува в Objective-C. Можете да видите влиянието на Swift с прости имена като Array, Dictionary и String вместо NSArray, NSDictionary и NSString, които са родени от липсата на пространства от имена в Objective-C.

С Swift пространствата от имена се основават на целта, към която принадлежи кодов файл. Това означава, че програмистите могат да разграничават класове или стойности, използвайки идентификатора на пространството от имена. Тази промяна в Swift е огромна. Това значително улеснява включването на проекти, рамки и библиотеки с отворен код във вашия код. Пространствата от имена позволяват на различни софтуерни компании да създават едни и същи кодови имена на файлове, без да се притесняват от сблъсъци при интегриране на проекти с отворен код. Сега и Facebook, и Apple могат да използват файл с обектен код, наречен FlyingCar.swift, без никакви грешки или грешки при изграждането.

8. Swift поддържа динамични библиотеки

Най-голямата промяна в Swift, която не е получила достатъчно внимание, е превключването от статични библиотеки, които се актуализират в основните версии (iOS 8, iOS 7 и т.н.), към динамични библиотеки. Динамичните библиотеки са изпълними парчета код, които могат да бъдат свързани към приложение. Тази функция позволява на текущите приложения на Swift да се свързват с по-новите версии на езика Swift, тъй като той се развива с течение на времето.

Разработчикът изпраща приложението заедно с библиотеките, които и двете са цифрово подписани със сертификата за разработка, за да се гарантира целостта (здравей, NSA). Това означава, че Swift може да се развива по-бързо от iOS, което е изискване за съвременен език за програмиране. Промените в библиотеките могат да бъдат включени с последната актуализация на приложение в App Store и всичко просто работи.

Динамичните библиотеки никога не са се поддържали в iOS до стартирането на Swift и iOS 8, въпреки че динамичните библиотеки се поддържат на Mac от много дълго време. Динамичните библиотеки са външни за изпълнението на приложението, но са включени в пакета с приложения, изтеглен от App Store. Той намалява първоначалния размер на приложението, когато се зарежда в паметта, тъй като външният код е свързан само когато се използва.

Възможността да се отложи зареждането в мобилно приложение или вградено приложение на Apple Watch ще подобри възприеманата производителност на потребителя. Това е едно от разликите, които карат екосистемата на iOS да се чувства по-отзивчива. Apple се съсредоточи върху зареждането само на активи, ресурси и сега компилира и свързва код в движение. Зареждането в движение намалява първоначалното време за изчакване, докато ресурсът действително е необходим за показване на екрана.