Swift vs. Objective-C: 10 redenen waarom de toekomst in het voordeel is van Swift

Programmeertalen sterven niet gemakkelijk, maar ontwikkelingswinkels die zich vastklampen aan vervagende paradigma's wel. Als je apps voor mobiele apparaten ontwikkelt en je hebt Swift niet onderzocht, let dan op: Swift vervangt niet alleen Objective-C als het gaat om het ontwikkelen van apps voor de Mac, iPhone, iPad, Apple Watch en toekomstige apparaten, maar het zal ook C vervangen voor ingebedde programmering op Apple-platforms.

Dankzij verschillende belangrijke functies heeft Swift de potentie om de de facto programmeertaal te worden voor het creëren van meeslepende, responsieve, consumentgerichte applicaties voor de komende jaren.

Apple lijkt grote doelen te hebben voor Swift. Het heeft de compiler geoptimaliseerd voor prestaties en de taal voor ontwikkeling, en het zinspeelt erop dat Swift "ontworpen is om te schalen van 'hallo, wereld' naar een volledig besturingssysteem" in de documentatie van Swift. Hoewel Apple nog niet al zijn doelen voor de taal heeft genoemd, geven de lanceringen van Xcode 6, Playgrounds en Swift samen de intentie van Apple aan om app-ontwikkeling gemakkelijker en toegankelijker te maken dan met enige andere keten van ontwikkeltools.

Hier zijn 10 redenen om voorop te lopen door nu met Swift te gaan werken.

1. Swift is gemakkelijker te lezen

Objective-C lijdt aan alle wratten die je zou verwachten van een taal die is gebouwd op C. Om trefwoorden en typen te onderscheiden van C-typen, introduceerde Objective-C nieuwe trefwoorden met het @ -symbool. Omdat Swift niet op C is gebouwd, kan het alle trefwoorden verenigen en de talrijke @ -symbolen voor elk Objective-C-type of objectgerelateerd trefwoord verwijderen.

Swift laat oude conventies vallen. U hebt dus geen puntkomma's meer nodig om regels te beëindigen of haakjes om voorwaardelijke uitdrukkingen binnen if / else-instructies te omringen. Een andere grote verandering is dat methodeaanroepen niet nesten in elkaar waardoor bracket hel afscheid afscheid, [[[ ]]]. Methode- en functieaanroepen in Swift gebruiken de door komma's gescheiden lijst met parameters tussen haakjes volgens de industriestandaard. Het resultaat is een schonere, expressievere taal met een vereenvoudigde syntaxis en grammatica.

Swift-code lijkt meer op natuurlijk Engels, naast andere moderne populaire programmeertalen. Deze leesbaarheid maakt het gemakkelijker voor bestaande programmeurs van JavaScript, Java, Python, C # en C ++ om Swift in hun gereedschapsketen op te nemen - in tegenstelling tot het lelijke eendje dat Objective-C was.

2. Swift is gemakkelijker te onderhouden

Legacy is wat Objective-C tegenhoudt - de taal kan niet evolueren zonder dat C evolueert. C vereist dat programmeurs twee codebestanden onderhouden om de bouwtijd en efficiëntie van het maken van de uitvoerbare app te verbeteren, een vereiste die wordt overgedragen naar Objective-C.

Swift schrapt de vereiste voor twee bestanden. Xcode en de LLVM-compiler kunnen afhankelijkheden achterhalen en automatisch incrementele builds uitvoeren in Swift 1.2. Daardoor behoort het steeds opnieuw scheiden van de inhoudsopgave (header-bestand) van de body (implementatiebestand) tot het verleden. Swift combineert de Objective-C-header (.h) en implementatiebestanden (.m) in één codebestand (.swift).

Het systeem met twee bestanden van Objective-C legt extra werk op aan programmeurs - en het is werk dat programmeurs afleidt van het grotere geheel. In Objective-C moet je de namen van methoden en opmerkingen tussen bestanden handmatig synchroniseren, hopelijk met behulp van een standaardconventie, maar dit is niet gegarandeerd tenzij het team regels en codebeoordelingen heeft ingevoerd.

Xcode en de LLVM-compiler kunnen achter de schermen werken om de werklast van de programmeur te verminderen. Met Swift doen programmeurs minder boekhouding en kunnen ze meer tijd besteden aan het maken van app-logica. Swift elimineert standaardwerk en verbetert de kwaliteit van code, opmerkingen en functies die worden ondersteund.

3. Swift is veiliger

Een interessant aspect van Objective-C is de manier waarop pointers - met name nihil (null) pointers - worden behandeld. In Objective-C gebeurt er niets als u een methode probeert aan te roepen met een pointervariabele die nul is (niet-geïnitialiseerd). De uitdrukking of regel code wordt een niet-bewerking (niet-op), en hoewel het misschien gunstig lijkt dat het niet crasht, is het een enorme bron van bugs geweest. Een no-op leidt tot onvoorspelbaar gedrag, wat de vijand is van programmeurs die een willekeurige crash proberen te vinden en op te lossen of grillig gedrag te stoppen.

Optionele typen maken de mogelijkheid van een nihil optionele waarde heel duidelijk in Swift-code, wat betekent dat het een compilatiefout kan genereren terwijl u slechte code schrijft. Dit creëert een korte feedbacklus en stelt programmeurs in staat om met intentie te coderen. Problemen kunnen worden opgelost terwijl er code wordt geschreven, wat de hoeveelheid tijd en geld die u besteedt aan het oplossen van bugs met betrekking tot aanwijzerlogica van Objective-C aanzienlijk vermindert.

Traditioneel, in Objective-C, als een waarde werd geretourneerd door een methode, was het de verantwoordelijkheid van de programmeur om het gedrag van de geretourneerde pointervariabele te documenteren (met behulp van opmerkingen en methode-naamgevingsconventies). In Swift maken de optionele typen en waardetypes het expliciet duidelijk in de methodedefinitie of de waarde bestaat of dat deze de potentie heeft om optioneel te zijn (dat wil zeggen, de waarde kan bestaan ​​of kan nul zijn).

Om voorspelbaar gedrag te bieden, activeert Swift een runtime-crash als een nul optionele variabele wordt gebruikt. Deze crash zorgt voor consistent gedrag, wat het oplossen van fouten vergemakkelijkt omdat het de programmeur dwingt het probleem meteen op te lossen. De Swift-runtime-crash stopt op de coderegel waar een nul optionele variabele is gebruikt. Dit betekent dat de bug eerder wordt verholpen of volledig wordt vermeden in Swift-code.

4. Swift is verenigd met geheugenbeheer

Swift verenigt de taal op een manier die Objective-C nooit heeft gedaan. De ondersteuning voor Automatic Reference Counting (ARC) is compleet over de procedurele en objectgeoriënteerde codepaden. In Objective-C wordt ARC ondersteund binnen de Cocoa API's en objectgeoriënteerde code; het is echter niet beschikbaar voor procedurele C-code en API's zoals Core Graphics. Dit betekent dat het de verantwoordelijkheid van de programmeur wordt om het geheugenbeheer af te handelen bij het werken met de Core Graphics API's en andere low-level API's die beschikbaar zijn op iOS. De enorme geheugenlekken die een programmeur kan hebben in Objective-C zijn onmogelijk in Swift.

Een programmeur hoeft niet na te denken over geheugen voor elk digitaal object dat hij of zij maakt. Omdat ARC al het geheugenbeheer tijdens het compileren afhandelt, kan de denkkracht die naar geheugenbeheer zou zijn gegaan, in plaats daarvan worden gericht op de logica van de kernapp en nieuwe functies. Omdat ARC in Swift zowel procedurele als objectgeoriënteerde code omvat, heeft het geen mentale contextwisselingen meer nodig voor programmeurs, zelfs niet als ze code schrijven die in aanraking komt met lagere API's - een probleem met de huidige versie van Objective-C.

Automatisch en krachtig geheugenbeheer is een probleem dat is opgelost en Apple heeft bewezen dat het de productiviteit kan verhogen. Het andere neveneffect is dat zowel Objective-C als Swift geen last hebben van een Garbage Collector die bezig is met het opruimen van ongebruikt geheugen, zoals Java, Go of C #. Dit is een belangrijke factor voor elke programmeertaal die zal worden gebruikt voor responsieve grafische afbeeldingen en gebruikersinvoer, vooral op een tactiel apparaat zoals de iPhone, Apple Watch of iPad (waar vertraging frustrerend is en gebruikers het gevoel geeft dat een app kapot is).

5. Swift vereist minder code

Swift vermindert de hoeveelheid code die nodig is voor repetitieve instructies en stringmanipulatie. In Objective-C is het werken met tekstreeksen erg uitgebreid en vereist het veel stappen om twee stukjes informatie te combineren. Swift maakt gebruik van moderne programmeertaalfuncties zoals het toevoegen van twee strings samen met een "+" operator, die ontbreekt in Objective-C. Ondersteuning voor het combineren van tekens en strings zoals deze is fundamenteel voor elke programmeertaal die tekst op een scherm weergeeft aan een gebruiker.

Het typesysteem in Swift vermindert de complexiteit van codeverklaringen - aangezien de compiler types kan achterhalen. Als een voorbeeld, Objective-C moet de programmeur speciale string lopers onthouden ( %s, %d, %@) en een door komma's gescheiden lijst van variabelen elk token vervangen. Swift ondersteunt stringinterpolatie, waardoor het niet meer nodig is om tokens te onthouden en programmeurs variabelen direct inline in een naar de gebruiker gerichte string kunnen invoegen, zoals een label of knoptitel. Het type-inferentiesysteem en tekenreeksinterpolatie verminderen een veelvoorkomende bron van crashes die veel voorkomen in Objective-C.

Met Objective-C zorgt het verpesten van de volgorde of het gebruik van de verkeerde string-token ervoor dat de app crasht. Hier verlost Swift u opnieuw van boekhoudkundig werk, door te vertalen naar minder code om te schrijven (code die nu minder foutgevoelig is) vanwege de inline ondersteuning voor het manipuleren van tekstreeksen en gegevens.

6. Swift is sneller

Het laten vallen van oude C-conventies heeft Swift aanzienlijk verbeterd onder de motorkap. Benchmarks voor de prestaties van de Swift-code blijven wijzen op Apples toewijding aan het verbeteren van de snelheid waarmee Swift app-logica kan uitvoeren.

Volgens Primate Labs, makers van de populaire GeekBench-prestatietool, benaderde Swift in december 2014 de prestatiekenmerken van C ++ voor computergebonden taken met behulp van het Mandelbrot-algoritme.

In februari 2015 ontdekte Primate Labs dat de Xcode 6.3 Beta de prestaties van Swift van het GEMM-algoritme - een geheugengebonden algoritme met sequentiële toegang tot grote arrays - met een factor 1,4 verbeterde. De eerste FFT-implementatie - een geheugengebonden algoritme met willekeurige toegang tot grote arrays - had een 2,6-voudige prestatieverbetering.

Verdere verbeteringen werden waargenomen in Swift door best practices toe te passen, resulterend in een 8,5-voudige boost voor de prestaties van het FFT-algoritme (waardoor C ++ slechts 1,1 keer prestatieverbetering heeft). Dankzij de verbeteringen kon Swift ook beter presteren dan C ++ voor het Mandelbrot-algoritme met een factor van slechts 1,03.

Swift is bijna gelijk aan C ++ voor zowel de FFT- als de Mandelbrot-algoritmen. Volgens Primate Labs suggereren de prestaties van het GEMM-algoritme dat de Swift-compiler geen code kan vectoriseren die de C ++ -compiler wel kan - een gemakkelijke prestatiewinst die kan worden behaald in de volgende versie van Swift.

7. Minder naambotsingen met open source-projecten

Een probleem dat Objective-C-code heeft geplaagd, is het gebrek aan formele ondersteuning voor naamruimten, wat C ++ 's oplossing was voor botsingen met codebestanden. Wanneer deze naambotsing plaatsvindt in Objective-C, is dit een linkerfout en kan de app niet worden uitgevoerd. Er zijn tijdelijke oplossingen, maar ze hebben mogelijke valkuilen. De gebruikelijke conventie is om voorvoegsels van twee of drie letters te gebruiken om Objective-C-code die bijvoorbeeld door Facebook is geschreven te onderscheiden van uw eigen code.

Swift biedt impliciete naamruimten waarmee hetzelfde codebestand in meerdere projecten kan bestaan ​​zonder een build-fout te veroorzaken en namen als NSString (Next Step - het bedrijf van Steve Jobs nadat het door Apple is ontslagen) of CGPoint (Core Graphics) nodig. Uiteindelijk houdt deze functie in Swift programmeurs productiever en hoeven ze niet de boekhouding te doen die in Objective-C bestaat. Je kunt de invloed van Swift zien met eenvoudige namen als Array, Dictionary en String in plaats van NSArray, NSDictionary en NSString, die werden geboren uit het gebrek aan naamruimten in Objective-C.

Met Swift zijn naamruimten gebaseerd op het doel waartoe een codebestand behoort. Dit betekent dat programmeurs klassen of waarden kunnen onderscheiden met behulp van de naamruimte-ID. Deze verandering in Swift is enorm. Het vergemakkelijkt enorm het opnemen van open source-projecten, frameworks en bibliotheken in uw code. De naamruimten stellen verschillende softwarebedrijven in staat om dezelfde codebestandsnamen te maken zonder zich zorgen te hoeven maken over botsingen bij het integreren van open source-projecten. Nu kunnen zowel Facebook als Apple een objectcodebestand genaamd FlyingCar.swift gebruiken zonder fouten of buildfouten.

8. Swift ondersteunt dynamische bibliotheken

De grootste verandering in Swift die niet genoeg aandacht heeft gekregen, is de overstap van statische bibliotheken, die worden bijgewerkt bij belangrijke point-releases (iOS 8, iOS 7, enzovoort), naar dynamische bibliotheken. Dynamische bibliotheken zijn uitvoerbare stukjes code die aan een app kunnen worden gekoppeld. Met deze functie kunnen huidige Swift-apps worden gekoppeld aan nieuwere versies van de Swift-taal naarmate deze zich in de loop van de tijd ontwikkelt.

De ontwikkelaar dient de app in samen met de bibliotheken, die beide digitaal zijn ondertekend met het ontwikkelingscertificaat om de integriteit te waarborgen (hallo, NSA). Dit betekent dat Swift sneller kan evolueren dan iOS, wat een vereiste is voor een moderne programmeertaal. Wijzigingen in de bibliotheken kunnen allemaal worden opgenomen met de laatste update van een app in de App Store, en alles werkt gewoon.

Dynamische bibliotheken werden nooit ondersteund op iOS tot de lancering van Swift en iOS 8, hoewel dynamische bibliotheken al heel lang op Mac worden ondersteund. Dynamische bibliotheken staan ​​buiten het uitvoerbare bestand van de app, maar zijn opgenomen in de app-bundel die is gedownload van de App Store. Het verkleint de aanvankelijke grootte van een app wanneer deze in het geheugen wordt geladen, aangezien de externe code alleen wordt gekoppeld wanneer deze wordt gebruikt.

De mogelijkheid om het laden in een mobiele app of een ingesloten app op Apple Watch uit te stellen, zal de waargenomen prestaties voor de gebruiker verbeteren. Dit is een van de verschillen waardoor het iOS-ecosysteem responsiever aanvoelt. Apple heeft zich gefocust op het laden van alleen activa, bronnen en nu gecompileerde en gekoppelde code on the fly. Het on-the-fly laden vermindert de initiële wachttijden totdat een bron daadwerkelijk nodig is om op het scherm weer te geven.