Swift vs. Objective-C: Den trending up-and-comer vs. dinosauren

En kort historie om Swift

Jeg husker, hvor afgørende det var, da Swift blev introduceret på Apples 2014 WWDC (Worldwide Developers Conference). Det var byens samtale, og alle de devs, jeg arbejdede med, kunne ikke vente med at prøve det. IOS-samfundet summede, og der var meget spænding omkring det nye sprog.

Det blev udviklet for at videreføre nogle koncepter, vi så i Objective-C, såsom udvidelig programmering. Men det skubbede mod en anden tilgang til kodning med det protokolorienterede design og øgede sikkerhed med statisk typing.

Det var et kæmpe hit og så sin væksthimleraket i årene efter introduktionen. Det var det mest elskede programmeringssprog i 2015, det næstbedste i 2016, det 11. mest populære programmeringssprog i 2017, der slog Objective-C, og det slog også Objective-C i 2018.

Swift er også et væddemål fra Apple om at vinde nybegyndere for at blive iOS-udviklere. Håbet er, at nye udviklere vil lære sproget og bruge det til at opbygge iOS-apps. Dette øger derefter økosystemet i appbutikken. Da Swift er optimeret til at arbejde med iOS-apps, sikrer dette, at de apps, der skrives, er af høj kvalitet.

Swifts popularitet fortsætter kun med at stige, især for mindre apps og start-ups. Kløften mellem Swift og Objective-C vil kun fortsætte med at vokse. Fremtiden er lys for dette unge sprog.

En kort historie med Objective-C

Objective-C er et objektorienteret programmeringssprog, der er et supersæt af C, som navnet på sproget måske afslører. Dette betyder, at ethvert gyldigt C-program kompileres med en Objective-C-kompilator. Det stammer al sin ikke-objektorienterede syntaks fra C og dens objektorienterede syntaks fra SmallTalk. Det blev udviklet i 1984, så det har haft tid til at modnes som sprog og er meget mere stabil end Swift.

De fleste mennesker kender Objective-C som det sprog, der bruges til at udvikle apps til iPhone, men historien går meget dybere end det. Jeg vil anbefale at læse denne artikel for et mere dybtgående kig.

Styrkerne ved Swift

Swift er vokset enormt i popularitet af nogle få vigtige grunde. For det første er der mange gode udviklingsværktøjer, som Apple har leveret til at arbejde sammen med Swift. En af mine personlige favoritter er legepladsen, som kun er kompatibel med Swift. Apple introducerede Playgrounds i 2016. De blev introduceret som en måde at lære at kode, men jeg elskede dem af en anden grund.

Mobiludvikling har altid haft flere vejspærringer end webudvikling. Du har brug for en simulator, du har normalt brug for et proprietært integreret udviklingsmiljø (IDE), og du skal oprette et helt projekt bare for at teste en lille prototype. I Apples tilfælde har du også brug for en udviklerkonto. Det pæne ved Legepladser er, at du kommer omkring noget af dette. Du har brug for Xcode eller Playgrounds-appen, men det er alt. Og du kan komme i gang med kodning og kompilering af din kode med det samme.

Endnu en anden stor fordel ved Swift er, at det er open source. Hvis du nogensinde har spekuleret på, hvordan et programmeringssprog fungerede under emhætten, kan du gå og se selv! Dette er en fantastisk måde at forstå det programmeringssprog, du arbejder med dagligt på et dybere niveau.

En hæderlig omtale går til et godt værktøj, der kun er tilgængeligt for Swift, Swift Package Manager. Swift Package Manager er simpelthen en afhængighedsmanager, der er integreret med Swift build-systemet. Det er på ingen måde en spilskifter, da CocoaPods og Carthage gjorde dette job for længe siden, men det er en anden tilgængelig løsning, hvis det er nødvendigt.

En masse beviser her understøtter det faktum, at Apple gør meget for at gøre Swift mere ønskeligt som det valgte programmeringssprog for iOS-udviklere. De skaber gode hjælpeprogrammer og hjælpestoffer for at lokke folk til at begynde at bruge sproget. Dette viser, at Apple presser på for Swift i fuld styrke.

Sprogfunktioner

Lad os komme ind på nogle af detaljerne i selve sproget. Swift er sikrere på grund af sin statiske typning og brugen af ​​ekstraudstyr. I Swift, hvis din kode kræver en streng, garanterer funktionerne i Swift, at din kode får en streng og ikke en anden type, såsom en int. Dette afhænger naturligvis af, om du bruger sproget, som det er beregnet til, og ikke tvinger til at pakke alt ud.

Et andet godt træk ved Swift er dens syntaks. Især sammenlignet med Objective-C. Det bedste ord til at beskrive syntaksen ville være ”kortfattet”. Der er ikke behov for semikolon, kald til sig selv eller parenteser, hvis udsagn. Det føles som om du springer over mange ting, som du alligevel ikke rigtig har brug for. Det kan gøre processen med at skrive en masse kode "flow" bedre.

Nogle mennesker siger, at dette fører til forbedringer af udviklingshastigheden, men jeg ville ikke ligefrem sige det selv. Det løbende behov for at pakke genstande ud for at overholde Swifts-typesikkerhed opvejer de udviklingsgevinster, der følger med kortfattethed.

Swift har også mange gode kontrolflowmuligheder med vagt, if-let, avancerede switch-sætninger, gentagelse og udsættelse. Jeg kan godt lide alle de forskellige muligheder, fordi det lader folk kontrollere strømmen af ​​deres kode på en måde, der giver mening for dem. Mange mennesker hader defers, men elsker vagter og omvendt. Det betyder ikke rigtig hvad du kan lide eller ikke kan lide, men mulighederne er der, og du kan kode på den måde, der føles bedst for dig.

Jeg kan ikke glemme alle de funktionelle programmeringsfunktioner såsom filter, kort og reducer. Dette er fantastisk til håndtering af samlinger og kommer til nytte ganske ofte.

Svaghederne

Swift er et ungt sprog, og med det kommer nogle skiftende. Migrationerne mellem versioner er simpelthen en smerte. Hos et lille firma kan migrationsværktøjet fra Apple være nyttigt og dække de fleste tilfælde. Det bliver mindre nyttigt, jo mere kode du har. Det er endnu værre, hvis din codebase indeholder både Objective-C og Swift-kode, der fungerer sammen.

På mit sidste firma tog migreringsindsatsen en dedikeret gruppe en hel weekend at gøre. De var nødt til at gøre det i weekenden, så de ikke løb ind i flette konflikter fra andre devs, der skubber kode. Dette var utroligt smertefuldt for alle involverede.

En grund til disse migrationer er, at Swift ikke er ABI-stabil. Det betyder, at nyere versioner af Swift ikke kan fungere med ældre versioner af Swift. Det betyder også, at sproget ikke kan pakkes med operativsystemet. Dette er en big deal for virksomheder med store apps, der aktivt bekæmper appstørrelse, fordi Swift bundtes med appen og øger størrelsen.

Et andet problem er, at Swift ikke spiller godt med Xcode. Xcode føles meget urolig, når du arbejder med Swift, og autofuldførelse virker simpelthen ikke nogle gange. Dette er underligt i betragtning af hvor hårdt Apple skubber Swift. Du tror, ​​at de vil gøre oplevelsen af ​​at bruge Swift med Xcode til en fornøjelse.

Swift har også problemer med strenghåndtering, se kodeeksemplet ovenfor. Det er klodset som helvede. I din dag til dag er det ikke så slemt. Hvor dette kommer mest i spil er under interviews. Desværre for Swift-udviklere elsker interviewere at stille spørgsmål, der involverer strengmanipulation. Dette forstærkes af det faktum, at den måde, strenge håndteres på, har ændret sig mellem versioner af Swift.

Styrkerne ved Objective-C

Objective-C er et meget dynamisk, objektorienteret sprog. Det er dynamisk til det punkt, at du kan bytte metodeopkald ved runtime ved hjælp af teknikker som Swizzling. Det er i stand til at gøre denne slags ting på grund af dets budskabsudsendelsesparadigme. Dette lader objekter sende beskeder til andre objekter på kørselstid for at bestemme påkaldelsen af ​​den metode, der kaldes.

Hvad betyder det i praktiske formål? Nå, en stor fordel er tilpasningsevne ved kørsel. Det betyder, at det bliver muligt at få adgang til private API'er eller gøre ting som at spotte objekter under kørsel. Dette kan være særligt nyttigt, når det kommer til enhedstest. Biblioteker som OCMock gør dette endnu nemmere og giver mulighed for meget detaljerede testopsætninger. At have gode enhedstest vil gøre din app mere stabil og pålidelig.

Apropos stabilitet har Objective-C eksisteret i lang tid, hvilket gør det til et meget stabilt sprog. Med Swift støder du på bugs, der er ret overraskende og ville være forstyrrende for stabiliteten af ​​din app. I eksemplet, jeg linkede ovenfor, ville dette nedbrud være forårsaget af det faktiske sprog, du bruger til at kode din app, ikke på grund af nogen fejl oprettet af den kode, du skrev. Dette kan være frustrerende.

Det sidste punkt, som er vigtigere for visse virksomheder, er kompatibilitet med C- og C ++ - biblioteker. At være, at Objective-C er et supersæt af C, er det let at bruge C- og C ++ -kode med Objective-C. Du kan endda bruge Objective-C ++, hvis du føler dig så tilbøjelig. Dette er vigtigt, hvis du er afhængig af tredjeparts C- og C ++ - biblioteker.

Svaghederne

Den første hovedklage, jeg hører om Objective-C, er syntaksen. Jeg startede min professionelle karriere ved hjælp af Objective-C, så jeg har ingen problemer med det. Det er detaljeret og lidt ukonventionelt med brugen af ​​firkantede parenteser. Men meninger om syntaks er netop det, meninger. Jeg regnede med, at jeg ville liste dette punkt, da det er en af ​​de første ting, der kommer op, når du nævner Objective-C.

En ting, som jeg dog er enig med, er, at bloksyntaks er frustrerende. Der er endda et websted dedikeret til at afkode mysterierne om blokke i Objective-C. Jeg bruger faktisk dette websted ret ofte som reference.

Det største problem, Objective-C står over for lige nu, er det faktum, at Apple en dag måske dropper støtte til Objective-C med kakao og andre almindelige biblioteker, der bruges til at oprette iOS-apps. Da Objective-C primært bruges til at oprette iOS-apps, ville dette være et dødsfald for sproget. Det betyder også, at nyankomne i iOS-samfundet er bange for at forpligte sig til at lære Objective-C lige nu, da det muligvis ikke længere vil blive brugt i fremtiden.

Lad os vende tilbage til selve sproget. Det er tilbøjeligt til at have svært ved at fejle problemer på grund af sprogets dynamiske karakter. Evnen til at sende meddelelser til nul og ikke gå ned oven på manglen på streng skrivning er nogle eksempler på ting, der fører til disse vanskelige fejlfindingsproblemer.

Objective-C holder heller ikke din hånd, når det kommer til disse ting. Selvom det er rart, at appen ikke går ned, når du sender en besked til nul, kan den muligvis sætte din app i en underlig tilstand. Det er meget svært at debugge problemer som disse. Det faktum, at Swift har streng skrivning og brugen af ​​udpakning af optioner, forhindrer disse ting på kompileringstidspunktet.

Skal jeg lære Swift eller Objective-C?

Svaret for de fleste mennesker vil være Swift. Apple skubber tydeligt Swift som det valgte sprog for dets iOS applikationsudviklingssamfund. Swift vil kun fortsætte med at blive mere performant, når ABI-stabilitet introduceres, og Swift bliver pakket med selve operativsystemet.

Hvis du ønsker at få et job som iOS-udvikler, vil Swift være det sprog, du vil lære. De fleste opstart til mellemstore virksomheder får deres iOS-apps skrevet fuldstændigt i Swift. Dette betyder, at du vil kunne søge og interviewe flere job, hvis du lærer Swift.

Selv i større virksomheder, hvor Objective-C stadig bruges meget, kan der stadig foretages interviews i Swift. Så du kan lære Objective-C, når du først er medlem af virksomheden og ikke bekymre dig om at belaste dig selv med flere ting at lære før interviewet.

Du vil gerne lære Objective-C, hvis du allerede arbejder i en start-up eller mellemniveau virksomhed og ønsker at hoppe til en større virksomhed. Færdigheder med mål-C giver dig specialiseret viden og en fordel i forhold til andre interviewkandidater.

Kan du lide det, du læser? Se på nogle af mine andre artikler:

Tips til dit første tekniske interview.

At starte en teknisk karriere fra ingenting.

Skal du få en datalogisk grad?