Programmeringsspråk dør ikke lett, men utviklingsbutikker som holder fast ved falmende paradigmer gjør det. Hvis du utvikler apper for mobile enheter og ikke har undersøkt Swift, må du merke deg: Swift vil ikke bare erstatte Objective-C når det gjelder å utvikle apper for Mac, iPhone, iPad, Apple Watch og enheter som kommer, men det vil også erstatte C for innebygd programmering på Apple-plattformer.
Takket være flere viktige funksjoner har Swift potensialet til å bli det de facto programmeringsspråket for å skape oppslukende, responsive og forbrukervendte applikasjoner i årene som kommer.
Apple ser ut til å ha store mål for Swift. Det har optimalisert kompilatoren for ytelse og språk for utvikling, og det antyder at Swift er "designet for å skalere fra 'hei, verden' til et helt operativsystem" i Swifts dokumentasjon. Mens Apple ikke har uttalt alle sine mål for språket ennå, lanserer lanseringen av Xcode 6, Playgrounds og Swift sammen Apples hensikt om å gjøre apputvikling enklere og mer tilgjengelig enn med noen annen utviklingsverktøyskjede.
Her er 10 grunner til å komme foran spillet ved å begynne å jobbe med Swift nå.
1. Swift er lettere å lese
Objective-C lider av alle vorter du forventer av et språk bygget på C. For å skille søkeord og typer fra C-typer, introduserte Objective-C nye søkeord ved hjelp av @ -symbolet. Fordi Swift ikke er bygget på C, kan det forene alle søkeordene og fjerne de mange @ symbolene foran alle Objective-C-typer eller objektrelaterte søkeord.
Swift dropper arvskonvensjoner. Dermed trenger du ikke lenger semikolon for å avslutte linjer eller parentes for å omgir betingede uttrykk inne hvis / annet uttalelser. En annen stor forandring er at metodesamtaler ikke hekker inne i hverandre, noe som resulterer i braketthelvete - farvel, [[[ ]]]. Metode- og funksjonsanrop i Swift bruker den industristandard kommaseparerte listen over parametere innenfor parentes. Resultatet er et renere, mer uttrykksfullt språk med forenklet syntaks og grammatikk.
Swift-kode ligner mer naturlig engelsk, i tillegg til andre moderne populære programmeringsspråk. Denne lesbarheten gjør det lettere for eksisterende programmerere fra JavaScript, Java, Python, C # og C ++ å ta i bruk Swift i deres verktøykjede - i motsetning til den stygge andungen som var Objective-C.
2. Swift er lettere å vedlikeholde
Arv er det som holder Objective-C tilbake - språket kan ikke utvikle seg uten at C utvikler seg. C krever at programmerere vedlikeholder to kodefiler for å forbedre byggetiden og effektiviteten til å opprette den kjørbare appen, et krav som overføres til Objective-C.
Swift dropper kravet om to filer. Xcode og LLVM-kompilatoren kan finne ut avhengigheter og utføre trinnvise bygginger automatisk i Swift 1.2. Som et resultat er den gjentatte oppgaven med å skille innholdsfortegnelsen (header-fil) fra kroppen (implementeringsfil) en saga blott. Swift kombinerer Objective-C header (.h) og implementeringsfiler (.m) i en enkelt kodefil (.swift).
Objective-Cs to-filsystem pålegger programmerere ekstra arbeid - og det er arbeid som distraherer programmerere fra det større bildet. I Objective-C må du manuelt synkronisere metodenavn og kommentarer mellom filer, forhåpentligvis ved å bruke en standardkonvensjon, men dette er ikke garantert med mindre teamet har regler og kodevurderinger på plass.
Xcode og LLVM-kompilatoren kan jobbe bak kulissene for å redusere arbeidsbelastningen på programmereren. Med Swift gjør programmerere mindre bokføring og kan bruke mer tid på å lage applogikk. Swift kutter ut kokeplatearbeidet og forbedrer kvaliteten på koden, kommentarene og funksjonene som støttes.
3. Swift er tryggere
Et interessant aspekt av Objective-C er måten pekere - spesielt null (null) pekere - blir håndtert på. I Objective-C skjer ingenting hvis du prøver å kalle en metode med en pekervariabel som er null (ikke-initialisert). Uttrykket eller kodelinjen blir en no-operation (no-op), og selv om det kan virke gunstig at det ikke krasjer, har det vært en stor kilde til feil. No-op fører til uforutsigbar oppførsel, som er fienden til programmerere som prøver å finne og fikse et tilfeldig krasj eller stoppe uregelmessig atferd.
Valgfrie typer gjør muligheten for en null valgfri verdi veldig tydelig i Swift-kode, noe som betyr at den kan generere en kompilatorfeil når du skriver dårlig kode. Dette skaper en kort tilbakemeldingssløyfe og lar programmerere kode med intensjon. Problemer kan løses når koden skrives, noe som i stor grad reduserer mengden tid og penger du vil bruke på å fikse feil relatert til pekerlogikk fra Objective-C.
Tradisjonelt, i Objective-C, hvis en verdi ble returnert fra en metode, var det programmererens ansvar å dokumentere oppførselen til den pekervariabelen som ble returnert (ved hjelp av kommentarer og metodenavngivningskonvensjoner). I Swift gjør de valgfrie typene og verditypene det eksplisitt klart i metodedefinisjonen om verdien eksisterer eller hvis den har potensialet til å være valgfri (det vil si at verdien kan eksistere eller den kan være null).
For å gi forutsigbar oppførsel utløser Swift en kjøretidskrasj hvis en null valgfri variabel brukes. Denne krasjen gir jevn oppførsel, noe som letter feilrettingsprosessen fordi den tvinger programmereren til å løse problemet med en gang. Swift-kjøretidskrasj stopper på kodelinjen der en null valgfri variabel har blitt brukt. Dette betyr at feilen vil bli løst før eller helt unngås i Swift-kode.
4. Swift er enhetlig med minnestyring
Swift forener språket på en måte som Objective-C aldri har. Støtten for automatisk referansetelling (ARC) er komplett på tvers av de prosessuelle og objektorienterte kodestiene. I Objective-C støttes ARC innenfor Cocoa APIer og objektorientert kode; den er imidlertid ikke tilgjengelig for prosessuell C-kode og API-er som Core Graphics. Dette betyr at det blir programmererens ansvar å håndtere minneadministrasjon når du arbeider med Core Graphics API-er og andre API-er på lavt nivå som er tilgjengelige på iOS. De enorme minnelekkasjene som en programmerer kan ha i Objective-C er umulig i Swift.
En programmerer trenger ikke å tenke på minne for hvert digitalt objekt han eller hun lager. Fordi ARC håndterer all minneadministrasjon på kompileringstidspunktet, kan hjernekraften som ville ha gått mot minneadministrasjon i stedet fokuseres på kjerneapplogikk og nye funksjoner. Siden ARC i Swift fungerer på tvers av både prosessuell og objektorientert kode, krever det ikke flere mentale kontekstbrytere for programmerere, selv om de skriver kode som berører APIer på lavere nivå - et problem med den nåværende versjonen av Objective-C.
Automatisk og høytytende minnestyring er et problem som er løst, og Apple har bevist at det kan øke produktiviteten. Den andre bivirkningen er at både Objective-C og Swift ikke lider av at en søppeloppsamler kjører opprydding for ubrukt minne, som Java, Go eller C #. Dette er en viktig faktor for ethvert programmeringsspråk som skal brukes til responsiv grafikk og brukerinngang, spesielt på en taktil enhet som iPhone, Apple Watch eller iPad (der lag er frustrerende og får brukerne til å oppleve at en app er ødelagt).
5. Swift krever mindre kode
Swift reduserer mengden kode som kreves for repeterende utsagn og strengmanipulering. I Objective-C er det veldig omfattende å jobbe med tekststrenger og krever mange trinn for å kombinere to stykker informasjon. Swift vedtar moderne programmeringsspråkfunksjoner som å legge til to strenger sammen med en "+" -operator, som mangler i Objective-C. Støtte for å kombinere tegn og strenger som dette er grunnleggende for ethvert programmeringsspråk som viser tekst til en bruker på en skjerm.
Typesystemet i Swift reduserer kompleksiteten til kodeuttalelser - ettersom kompilatoren kan finne ut hvilke typer. Som et eksempel krever Objective-C at programmerere husker spesielle strengetokener (% s, % d, %@) og gi en kommaseparert liste over variabler som skal erstatte hvert token. Swift støtter interpolering av strenger, noe som eliminerer behovet for å huske tokens og lar programmerere sette inn variabler direkte inline til en brukervendt streng, for eksempel en etikett eller knappetittel. Type inferencesystem og strenginterpolering reduserer en vanlig kilde til krasj som er vanlig i Objective-C.
Med Objective-C fører til at appen krasjer hvis du ødelegger ordren eller bruker feil strengetoken. Her avlaster Swift deg igjen fra bokføringsarbeid, og oversetter til mindre kode å skrive (kode som nå er mindre utsatt for feil) på grunn av sin innebygde støtte for å manipulere tekststrenger og data.
6. Swift er raskere
Å slippe eldre C-konvensjoner har forbedret Swift under panseret. Benchmarks for Swift-kodeytelse peker fortsatt på Apples dedikasjon til å forbedre hastigheten som Swift kan kjøre applogikk på.
I følge Primate Labs, produsenter av det populære ytelsesverktøyet GeekBench, nærmet Swift seg ytelsesegenskapene til C ++ for beregningsbundne oppgaver i desember 2014 ved hjelp av Mandelbrot-algoritmen.
I februar 2015 oppdaget Primate Labs at Xcode 6.3 Beta forbedret Swifts ytelse av GEMM-algoritmen - en minnebundet algoritme med sekvensiell tilgang til store matriser - med en faktor på 1,4. Den første FFT-implementeringen - en minnebundet algoritme med tilfeldig tilgang til store matriser - hadde en forbedring av ytelsen på 2,6 ganger.
Ytterligere forbedringer ble observert i Swift ved å anvende beste praksis, noe som resulterte i en 8,5-fold boost for FFT-algoritmeytelse (etterlot C ++ med bare en 1,1-gangs ytelsesgevinst). Forbedringene gjorde det også mulig for Swift å overgå C ++ for Mandelbrot-algoritmen med en faktor på bare 1,03.
Swift er nesten på nivå med C ++ for både FFT- og Mandelbrot-algoritmene. I følge Primate Labs antyder GEMM-algoritmens ytelse at Swift-kompilatoren ikke kan vektorisere koden C ++ -kompilatoren kan - en enkel ytelsesgevinst som kan oppnås i neste versjon av Swift.
7. Færre navnekollisjoner med open source-prosjekter
Et problem som har plaget Objective-C-koden, er mangelen på formell støtte for navnerom, som var C ++ 's løsning på kodekollisjon av filnavn. Når dette navnekollisjonen skjer i Objective-C, er det en linkerfeil, og appen kan ikke kjøres. Løsninger finnes, men de har potensielle fallgruver. Den vanlige konvensjonen er å bruke et prefiks med to eller tre bokstaver for å differensiere Objective-C-kode som er skrevet, for eksempel, av Facebook versus din egen kode.
Swift tilbyr implisitte navneområder som gjør at den samme kodefilen kan eksistere på tvers av flere prosjekter uten å forårsake en byggesvikt og krever navn som NSString (Next Step - Steve Jobs 'firma etter å ha blitt sparket fra Apple) eller CGPoint (Core Graphics). Til slutt holder denne funksjonen i Swift programmerere mer produktive og betyr at de ikke trenger å gjøre bokføringen som finnes i Objective-C. Du kan se Swifts innflytelse med enkle navn som Array, Dictionary og String i stedet for NSArray, NSDictionary og NSString, som ble født av mangelen på navnerom i Objective-C.
Med Swift er navnerom basert på målet som en kodefil tilhører. Dette betyr at programmerere kan skille klasser eller verdier ved hjelp av navneområdet. Denne endringen i Swift er enorm. Det letter i stor grad å innlemme åpen kildekode-prosjekter, rammer og biblioteker i koden din. Navneplassene gjør det mulig for forskjellige programvareselskaper å lage de samme kodefilnavnene uten å bekymre seg for kollisjoner når de integrerer åpen kildekode-prosjekter. Nå kan både Facebook og Apple bruke en objektkodefil kalt FlyingCar.swift uten feil eller byggefeil.
8. Swift støtter dynamiske biblioteker
Den største endringen i Swift som ikke har fått nok oppmerksomhet, er byttet fra statiske biblioteker, som er oppdatert ved store punktutgivelser (iOS 8, iOS 7 og så videre), til dynamiske biblioteker. Dynamiske biblioteker er kjørbare biter av kode som kan kobles til en app. Denne funksjonen lar nåværende Swift-apper koble til nyere versjoner av Swift-språket når det utvikler seg over tid.
Utvikleren sender appen sammen med bibliotekene, som begge er signert digitalt med utviklingssertifikatet for å sikre integritet (hei, NSA). Dette betyr at Swift kan utvikle seg raskere enn iOS, noe som er et krav for et moderne programmeringsspråk. Endringer i bibliotekene kan inkluderes i den siste oppdateringen av en app i App Store, og alt fungerer rett og slett.
Dynamiske biblioteker har aldri blitt støttet på iOS før lanseringen av Swift og iOS 8, selv om dynamiske biblioteker har blitt støttet på Mac i veldig lang tid. Dynamiske biblioteker er eksterne for kjørbar app, men er inkludert i apppakken som er lastet ned fra App Store. Det reduserer den opprinnelige størrelsen på en app når den lastes inn i minnet, siden den eksterne koden bare er koblet når den brukes.
Evnen til å utsette lasting i en mobilapp eller en innebygd app på Apple Watch vil forbedre opplevelsen for brukeren. Dette er en av skillene som gjør iOS-økosystemet mer responsivt. Apple har vært fokusert på å laste bare eiendeler, ressurser, og nå samlet og koblet kode på farten. On-the-fly-belastningen reduserer de første ventetiden til en ressurs faktisk er nødvendig for å vises på skjermen.
