Swift vs. Objective-C: 10 skäl till att framtiden gynnar Swift

Programmeringsspråk dör inte lätt, men utvecklingsbutiker som håller fast vid blekande paradigmer gör det. Om du utvecklar appar för mobila enheter och du inte har undersökt Swift, notera: Swift ersätter inte bara Objective-C när det gäller att utveckla appar för Mac, iPhone, iPad, Apple Watch och enheter som kommer, men det kommer också att ersätta C för inbäddad programmering på Apple-plattformar.

Tack vare flera viktiga funktioner har Swift potential att bli det faktiska programmeringsspråket för att skapa uppslukande, lyhörda och konsumentinriktade applikationer under många år framöver.

Apple verkar ha stora mål för Swift. Det har optimerat kompilatorn för prestanda och språket för utveckling, och det antyder att Swift är "designat för att skala från" hej, värld "till ett helt operativsystem" i Swifts dokumentation. Medan Apple inte har uttalat alla sina mål för språket ännu, lanserar Xcode 6, Playgrounds och Swift tillsammans Apples avsikt att göra apputveckling enklare och mer tillgänglig än med någon annan utvecklingskedja.

Här är tio skäl att komma före spelet genom att börja arbeta med Swift nu.

1. Swift är lättare att läsa

Objective-C lider av alla vårtor du kan förvänta dig av ett språk som bygger på C. För att skilja nyckelord och typer från C-typer introducerade Objective-C nya nyckelord med symbolen @. Eftersom Swift inte är byggt på C kan det förena alla nyckelorden och ta bort de många @ symbolerna framför varje Objective-C-typ eller objektrelaterat nyckelord.

Swift tappar äldre konventioner. Således behöver du inte längre semikolon för att avsluta rader eller parenteser för att omge villkorliga uttryck inuti if / else-uttalanden. En annan stor förändring är att metodanrop inte boet inuti varandra vilket resulterar i fästet hell-bye-bye, [[[ ]]]. Metod- och funktionssamtal i Swift använder den industristandard kommaseparerade listan över parametrar inom parentes. Resultatet är ett renare, mer uttrycksfullt språk med en förenklad syntax och grammatik.

Snabbkod liknar mer naturlig engelska, förutom andra moderna populära programmeringsspråk. Denna läsbarhet gör det lättare för befintliga programmerare från JavaScript, Java, Python, C # och C ++ att använda Swift i deras verktygskedja - till skillnad från den fula ankungen som var Objective-C.

2. Swift är lättare att underhålla

Arv är det som håller tillbaka Objective-C - språket kan inte utvecklas utan att C utvecklas. C kräver att programmerare underhåller två kodfiler för att förbättra byggtiden och effektiviteten i skapandet av den körbara appen, ett krav som överförs till Objective-C.

Swift tappar kravet på två filer. Xcode och LLVM-kompilatorn kan räkna ut beroenden och utföra stegvisa byggnader automatiskt i Swift 1.2. Som ett resultat är den upprepade uppgiften att separera innehållsförteckningen (rubrikfil) från kroppen (implementeringsfil) en historia. Swift kombinerar Objective-C-rubriken (.h) och implementeringsfilerna (.m) i en enda kodfil (.swift).

Objective-C: s två-filsystem påför programmerare ytterligare arbete - och det är arbete som distraherar programmerare från den större bilden. I Objective-C måste du manuellt synkronisera metodnamn och kommentarer mellan filer, förhoppningsvis med hjälp av en standardkonvention, men detta garanteras inte om inte teamet har regler och kodrecensioner på plats.

Xcode och LLVM-kompilatorn kan arbeta bakom kulisserna för att minska arbetsbelastningen på programmeraren. Med Swift gör programmerare mindre bokföring och kan spendera mer tid på att skapa applogik. Swift skär ut pannplattans arbete och förbättrar kvaliteten på kod, kommentarer och funktioner som stöds.

3. Swift är säkrare

En intressant aspekt av Objective-C är det sätt på vilket pekare - särskilt noll (null) pekare - hanteras. I Objective-C händer ingenting om du försöker anropa en metod med en pekervariabel som är noll (oinitialiserad). Uttrycket eller raden av kod blir en no-operation (no-op), och även om det kan verka fördelaktigt att det inte kraschar, har det varit en enorm källa till buggar. No-op leder till oförutsägbart beteende, vilket är fienden till programmerare som försöker hitta och fixa en slumpmässig krasch eller stoppa oregelbunden uppförande.

Tillvalstyper gör möjligheten till ett noll valfritt värde mycket tydligt i Swift-kod, vilket innebär att det kan generera ett kompileringsfel när du skriver dålig kod. Detta skapar en kort återkopplingsslinga och låter programmerare koda med avsikt. Problem kan åtgärdas när koden skrivs, vilket avsevärt minskar den tid och pengar du kommer att spendera på att fixa buggar relaterade till pekarlogik från Objective-C.

Traditionellt, i Objective-C, om ett värde returnerades från en metod, var det programmerarens ansvar att dokumentera beteendet hos den pekervariabel som returnerats (med hjälp av kommentarer och metodnamnkonventioner). I Swift gör de valfria typerna och värdetyperna det tydligt tydligt i metoddefinitionen om värdet existerar eller om det har potential att vara valfritt (det vill säga värdet kan finnas eller det kan vara noll).

För att tillhandahålla förutsägbart beteende utlöser Swift en runtime-krasch om en noll valfri variabel används. Denna krasch ger konsekvent beteende, vilket underlättar felsökningsprocessen eftersom den tvingar programmeraren att åtgärda problemet direkt. Swift runtime-krasch stoppas på kodraden där en noll valfri variabel har använts. Detta betyder att felet kommer att åtgärdas tidigare eller helt undvikas i Swift-kod.

4. Swift förenas med minneshantering

Swift förenar språket på ett sätt som Objective-C aldrig har. Stödet för automatisk referensräkning (ARC) är komplett över de procedurella och objektorienterade kodvägarna. I Objective-C stöds ARC inom Cocoa API: er och objektorienterad kod; det är dock inte tillgängligt för procedurell C-kod och API som Core Graphics. Detta innebär att det blir programmerarens ansvar att hantera minneshantering när man arbetar med Core Graphics API: er och andra API: er på låg nivå som är tillgängliga på iOS. De enorma minnesläckage som en programmerare kan ha i Objective-C är omöjliga i Swift.

En programmerare borde inte behöva tänka på minne för varje digitalt objekt som han eller hon skapar. Eftersom ARC hanterar all minneshantering vid sammanställning kan hjärnkraften som skulle ha gått mot minneshantering istället fokuseras på kärnapplogik och nya funktioner. Eftersom ARC i Swift fungerar över både procedur- och objektorienterad kod, behöver det inga fler mentala kontextomkopplare för programmerare, även om de skriver kod som berör API: er på lägre nivå - ett problem med den nuvarande versionen av Objective-C.

Automatisk och högpresterande minneshantering är ett problem som har lösts och Apple har visat att det kan öka produktiviteten. Den andra bieffekten är att både Objective-C och Swift inte lider av att en Garbage Collector kör som rensar upp för oanvänt minne, som Java, Go eller C #. Detta är en viktig faktor för alla programmeringsspråk som kommer att användas för responsiv grafik och användarinmatning, särskilt på en taktil enhet som iPhone, Apple Watch eller iPad (där fördröjning är frustrerande och gör att användare uppfattar att en app är trasig).

5. Swift kräver mindre kod

Swift minskar mängden kod som krävs för repetitiva uttalanden och strängmanipulation. I Objective-C är arbetet med textsträngar mycket ordentligt och kräver många steg för att kombinera två informationsstycken. Swift antar moderna programmeringsspråkfunktioner som att lägga till två strängar tillsammans med en "+" -operator, som saknas i Objective-C. Stöd för att kombinera tecken och strängar som detta är grundläggande för alla programmeringsspråk som visar text för en användare på en skärm.

Typsystemet i Swift minskar komplexiteten i koduttalanden - eftersom kompilatorn kan räkna ut typer. Som ett exempel, kräver Objective-C programmerare att memorera speciella sträng polletter ( %s, %d, %@) och tillhandahålla en kommaseparerad lista av variabler för att ersätta varje token. Swift stöder stränginterpolering, vilket eliminerar behovet av att memorera tokens och låter programmerare infoga variabler direkt inline i en användarvänd sträng, till exempel en etikett eller knapptitel. Typavledningssystemet och stränginterpolering mildrar en vanlig källa till kraschar som är vanliga i Objective-C.

Med Objective-C kan det hända att appen kraschar genom att förstöra ordern eller använda fel strängtoken. Här befriar Swift dig från bokföringsarbetet, översätter till mindre kod att skriva (kod som nu är mindre felbenägen) på grund av dess inbyggda stöd för att manipulera textsträngar och data.

6. Swift är snabbare

Att släppa äldre C-konventioner har förbättrat Swift kraftigt under huven. Riktmärken för Swift-kodprestanda fortsätter att peka på Apples engagemang för att förbättra den hastighet med vilken Swift kan köra applogik.

Enligt Primate Labs, tillverkare av det populära prestandaverktyget GeekBench, närmade sig Swift prestandaegenskaperna för C ++ för beräkningsbundna uppgifter i december 2014 med Mandelbrot-algoritmen.

I februari 2015 upptäckte Primate Labs att Xcode 6.3 Beta förbättrade Swifts prestanda för GEMM-algoritmen - en minnesbunden algoritm med sekventiell åtkomst av stora matriser - med en faktor på 1,4. Den första FFT-implementeringen - en minnesbunden algoritm med slumpmässig åtkomst för stora matriser - hade en prestationsförbättring på 2,6 gånger.

Ytterligare förbättringar observerades i Swift genom att använda bästa praxis, vilket resulterade i en 8,5-faldig boost för FFT-algoritmprestanda (vilket lämnade C ++ med endast en 1,1-gångs prestationsförstärkning). Förbättringarna gjorde det också möjligt för Swift att överträffa C ++ för Mandelbrot-algoritmen med en faktor på bara 1,03.

Swift är nästan i nivå med C ++ för både FFT- och Mandelbrot-algoritmerna. Enligt Primate Labs föreslår GEMM-algoritmprestanda att Swift-kompilatorn inte kan vektorisera kod som C ++ -kompilatorn kan - en enkel prestationsförstärkning som kan uppnås i nästa version av Swift.

7. Färre namnkollisioner med projekt med öppen källkod

En fråga som har plågat Objective-C-koden är bristen på formellt stöd för namnområden, vilket var C ++: s lösning på kollisioner med kodfilnamn. När detta namnkollision inträffar i Objective-C är det ett länkfel och appen kan inte köras. Lösningar finns, men de har potentiella fallgropar. Den vanliga konventionen är att använda två- eller trebokstavsprefix för att differentiera Objective-C-kod som är skriven av Facebook jämfört med din egen kod.

Swift tillhandahåller implicita namnområden som gör att samma kodfil kan existera i flera projekt utan att orsaka ett byggfel och kräver namn som NSString (Nästa steg - Steve Jobs företag efter att ha sparkats från Apple) eller CGPoint (Core Graphics). I slutändan håller den här funktionen i Swift programmerare mer produktiva och innebär att de inte behöver göra bokföring som finns i Objective-C. Du kan se Swifts inflytande med enkla namn som Array, Dictionary och String istället för NSArray, NSDictionary och NSString, som föddes på grund av bristen på namnområden i Objective-C.

Med Swift baseras namnrymden på det mål som en kodfil tillhör. Detta innebär att programmerare kan skilja på klasser eller värden med hjälp av namnområdesidentifieraren. Denna förändring i Swift är enorm. Det underlättar i hög grad införlivande av öppen källkodsprojekt, ramar och bibliotek i din kod. Namnytorna gör det möjligt för olika programvaruföretag att skapa samma kodfilnamn utan att oroa sig för kollisioner när man integrerar projekt med öppen källkod. Nu kan både Facebook och Apple använda en objektkodfil som heter FlyingCar.swift utan några fel eller byggfel.

8. Swift stöder dynamiska bibliotek

Den största förändringen i Swift som inte har fått tillräckligt med uppmärksamhet är övergången från statiska bibliotek, som uppdateras vid större punktreleaser (iOS 8, iOS 7 och så vidare), till dynamiska bibliotek. Dynamiska bibliotek är körbara bitar av kod som kan länkas till en app. Med den här funktionen kan nuvarande Swift-appar länka till nyare versioner av Swift-språket när det utvecklas över tiden.

Utvecklaren skickar in appen tillsammans med biblioteken, som båda är digitalt signerade med utvecklingscertifikatet för att säkerställa integritet (hej, NSA). Detta innebär att Swift kan utvecklas snabbare än iOS, vilket är ett krav för ett modernt programmeringsspråk. Ändringar av biblioteken kan alla inkluderas i den senaste uppdateringen av en app i App Store, och allt fungerar helt enkelt.

Dynamiska bibliotek har aldrig stödts på iOS förrän lanseringen av Swift och iOS 8, även om dynamiska bibliotek har stödts på Mac under mycket lång tid. Dynamiska bibliotek är externa för appens körbara, men ingår i apppaketet som laddas ner från App Store. Det minskar en apps initiala storlek eftersom den laddas i minnet, eftersom den externa koden endast är länkad när den används.

Möjligheten att skjuta upp laddningen i en mobilapp eller en inbäddad app på Apple Watch kommer att förbättra användarens upplevda prestanda. Detta är en av skillnaderna som gör att iOS-ekosystemet känns mer lyhört. Apple har fokuserat på att bara ladda tillgångar, resurser och nu sammanställt och länkad kod i farten. On-the-fly-belastningen minskar de initiala väntetiderna tills en resurs verkligen behövs för att visas på skärmen.