Învățarea programării rapide: este gata pentru Prime Time?

Lansarea de către Apple în iunie trecută a Swift, un nou limbaj de programare pentru scrierea de aplicații iOS, a creat o mulțime de entuziasm și entuziasm în întreaga comunitate de dezvoltatori iOS.

De la lansarea sa, mulți dezvoltatori iOS s-au luptat cu întrebarea dacă, cum și când să facă tranziția de la Objective-C la Swift. Răspunsul la această întrebare va fi, desigur, diferit pentru fiecare echipă și fiecare proiect.

Există o serie de articole pe care le puteți citi care acoperă multe dintre avantajele Swift. Deci, în loc să reluăm aceleași puncte, în acest articol ne vom concentra pe unele dintre preocupările pe care poate doriți să le luați în considerare înainte de a învăța dezvoltarea aplicației cu Swift.

Dar mai întâi, să întoarcem puțin ceasul înapoi...

Înainte de Swift: vei folosi Objective-C și îți va plăcea...

Anul era 2010. iPhone-ul nu avea încă 3 ani, iar capacitatea de a scrie aplicații native pentru iPhone exista doar de aproximativ 2 ani. Pe 8 aprilie a acelui an, Apple a anunțat versiunea iPhone OS. Sistemul de operare iPhone (acest lucru a fost înainte de a-și schimba numele în iOS) a inclus funcții noi atât de tentante, cum ar fi multitasking, comutare rapidă între aplicații și servicii de fundal. De înțeles, dezvoltatorii iPhone au fost dornici să pună mâna pe noul SDK și să înceapă să se joace cu toate acele funcții noi interesante.

Dar SDK-ul iPhone OS 4 conținea o bombă neașteptată. Această bombă nu era în software, era în acordul de utilizare. Cu iPhone OS 4 SDK, secțiunea 3.3.1 a Acordului pentru dezvoltatori a fost actualizată pentru a include următorul limbaj tulburător:

Aplicațiile trebuie să fie scrise inițial în Objective-C, C, C++ … și numai codul scris în C, C++ și Objective-C poate compila și conecta direct la API-urile documentate.
– Secțiunea 3.3.1 din Acordul pentru dezvoltatori SDK pentru iPhone OS 4

Inutil să spun că această nouă restricție i-a prins prin surprindere pe mulți dezvoltatori. Motivul oficial al schimbării, furnizat de însuși Steve Jobs, a fost acela de a preveni utilizarea instrumentelor multiplatforme, cum ar fi Flash CS5 recent anunțat. Jobs a fost citat spunând că „straturile intermediare dintre platformă și dezvoltator produc în cele din urmă [sic] aplicații substandard”. Dar faptul că abordarea Apple pentru combaterea acestor „straturi intermediare” a fost de a restricționa limbajele de programare care ar putea fi folosite pentru a scrie aplicații pentru iPhone a dezvăluit ceva mai mult despre gândirea Apple: Objective-C ar trebui să fie suficient de bun pentru oricine.

Cineva ar putea fi iertat pentru că este de acord cu această afirmație, deoarece Objective-C a câștigat premiul „Limbajul de programare al anului” al Indexului Tiobe doi ani la rând. Dar realitatea a fost că popularitatea Objective-C a fost o funcție a ecosistemului de aplicații în creștere, și nu invers. Chiar și în 2010, mulți oameni erau deja nemulțumiți de Objective-C și, ca urmare, au apărut deja modalități alternative de a scrie aplicații pentru iPhone în alte limbaje de programare.

În cele din urmă, sub presiunea comunității de dezvoltatori în general, Apple a anulat aceste modificări la Secțiunea 3.3.1 a Acordului pentru dezvoltatori SDK doar cinci luni mai târziu. Cu toate acestea, mesajul a fost clar: dacă doriți să scrieți aplicații pentru iPhone, probabil că ar trebui să utilizați Objective-C.

… sau poate nu. Introduceți noua limbă iOS Swift.

Cu 4 ani înainte, de la acel incident până în iunie 2014, când Apple a prezentat dezvoltatorilor noul său limbaj, Swift. Dacă mesajul cu 4 ani înainte a fost că Apple a fost perfect mulțumit de Objective-C, atunci mesajul transmis de prezentarea lui Swift a fost că Apple a fost în sfârșit gata să admită adevărul. Objective-C ar putea să nu fie neapărat cel mai bun limbaj pentru scrierea aplicațiilor mobile.

S-au spus multe despre cum Swift este un limbaj mai „modern” decât Objective-C. Dacă sunteți interesat de cum să învățați limbajul de programare Swift, poate doriți să consultați ghidul pentru trecerea de la Objective-C la Swift.

Ceea ce ar trebui să observați, totuși, este că există două diferențe importante între limbajele Objective-C și Swift:

1. Swift nu este un superset strict al limbajului C.
2. Swift este tastat static, nu dinamic.

Nefiind un superset strict al lui C înseamnă că Swift este liber să folosească constructe de sintaxă care altfel nu ar fi permise. Acest lucru face posibilă, de exemplu, implementarea operatorilor personalizați în Swift.

Fiind tipărit static înseamnă că Swift poate profita de multe dintre progresele recente în sistemele de tipare inițiate de limbi precum Haskell.

În ciuda faptului că a fost în dezvoltare timp de 4 ani înainte de a fi dezvăluit publicului, Swift este încă un limbaj de programare tânăr, așa că vine cu o serie de avertismente.

Compatibilitate cu Objective-C

iOS are o moștenire comună cu OS X, care, la rândul său, își ia istoria de la sistemul de operare NeXTSTEP lansat pentru prima dată în 1989. NeXTSTEP a fost scris inițial în mare parte în Objective-C, iar multe dintre bibliotecile de bază din OS X și iOS își urmăresc rădăcinile toate. drumul înapoi la aceste implementări originale. (De altfel, de aici provine prefixul omniprezent „NS” găsit pe clasele de bază, cum ar fi NSString .) În timp ce Swift ar putea exista teoretic în absența acestor biblioteci de bază, realitatea este că orice program Swift pe care le-ați putea scrie în viitorul apropiat va trebui să interacționeze cu Objective-C.

Spre meritul lor, dezvoltatorii din spatele Swift au făcut o treabă fantastică făcând interacțiunea cu bibliotecile existente Objective-C cât mai nedureroase posibil. Cu toate acestea, asta nu înseamnă că procesul este complet lipsit de durere. Apple a oferit un ghid util care explică cum să apelezi codul Objective-C de la Swift și invers, dar există câteva nepotriviri importante de impedanță de care trebuie să fii conștient.

Poate cea mai evidentă nepotrivire se referă la fișierele antet. Obiectivul-C, datorită rădăcinilor sale C, necesită în continuare ca funcțiile să fie declarate înainte de a fi apelate. Când apelați la o bibliotecă, aceste declarații vor fi găsite în fișierele antet ale bibliotecii. Swift, totuși, nu utilizează fișiere de antet. Deci, dacă doriți să apelați codul Swift din Objective-C, mai întâi va trebui să creați un „antet de legătură”. Deși din punct de vedere conceptual acest lucru poate să nu pară atât de complex, în practică, poate fi de fapt o sarcină destul de importantă.

Un alt set de complicații în interfața dintre Swift și Objective-C provine din diferențele inerente în sistemele lor de tip. Swift, luând un exemplu de la alte limbi moderne, a eliminat conceptul de nil . În locul lui sunt tipurile opționale ale lui Swift. De exemplu, o metodă care deschide un fișier numai dacă acesta există deja ar avea un tip de returnare File? (în loc de doar File ) în Swift. Urmărind toate locurile în care tipurile sunt opționale, compilatorul Swift poate face imposibilă întâmpinarea temutei „Eroare de indicator nul”. Asta, desigur, cu excepția cazului în care numiți Objective-C. Deoarece Objective-C nu oferă astfel de garanții cu privire la nereturnarea nil , Swift are o categorie specială de tipuri numite Opționaluri implicite neîmpachetate , care sunt folosite la apelarea codului Objective-C. Aceste tipuri pot fi tratate ca opționale în limbajul Swift, împreună cu toate cheltuielile generale necesare pentru verificarea existenței. Alternativ, ele pot fi folosite la fel ca orice tip non-opțional, dar dacă Objective - C returnează un nil , veți ajunge cu o eroare de rulare, astfel încât veți pierde unele dintre garanțiile de siguranță Swift la timp de compilare.

În cele din urmă, o nepotrivire puțin mai subtilă de luat în considerare atunci când programați între Swift și Objective-C are de-a face cu modul în care obiectele și clasele sunt create sub acoperire în aceste două limbi. Objective-C, datorită naturii sale dinamice, utilizează dispeceratul dinamic pentru a apela metode pe obiecte (prin objc_msgSend ). Swift poate folosi cu siguranță trimiterea dinamică, dar, deoarece este scris static, are și opțiunea de a folosi un vtable pentru a stoca indicatorii de funcție pentru fiecare metodă. Care dintre aceste două mecanisme le folosește Swift depinde de câțiva factori. Plane Old Swift Objects va folosi mecanismul vtable , cu excepția cazului în care clasa sau metodele din cadrul clasei sunt adnotate folosind atributul @objc Swift. Clasele Swift care moștenesc din clasele Objective-C vor folosi dispecerația dinamică pentru metodele moștenite, dar nu pentru orice metodă nouă introdusă de subclasă (deși, din nou, puteți forța utilizarea dispecerii dinamice cu atributul @objc ). Indiferent, codul Swift va putea întotdeauna să funcționeze cu clasele Swift, dar codul Objective-C poate utiliza numai obiecte și metode Swift care au fost adnotate corespunzător.

Mai rapid decât Objective-C?

Când Apple și-a prezentat lansarea, unul dintre beneficiile Swift care a fost subliniat în mod special a fost viteza sa. Acest lucru este de înțeles când considerați că un motiv adesea invocat pentru reticența Apple de a trece de la Objective-C la un limbaj de nivel superior a fost că Objective-C, fiind în esență o extensie a C, era capabil să creeze programe mult mai rapide și mai eficiente. decât ceva de genul Python sau Ruby. Chiar și așa, Objective-C nu este o navă rachetă atunci când vine vorba de performanță absolută și o mare parte din aceasta poate fi atribuită tastării dinamice. Deci, cu Swift adoptând un sistem de tip static, ne-am aștepta ca Swift să fie cel puțin la fel de rapid, sau mai rapid, decât Objective-C.

Desigur, așa cum se spune, „Există trei tipuri de minciuni: minciuni, minciuni blestemate și repere.” (Sau ceva de genul...) Cu siguranță, există numeroase motive pentru care limbajul Swift ar putea rula mai repede. Din păcate, se pare că modul în care Swift utilizează tehnica ARC (Contorarea automată a referințelor) Apple pentru gestionarea memoriei are ca rezultat uneori compilatorul lui Swift să genereze programe semnificativ mai lente, în special cu setări de optimizare mai scăzute (cum ar fi ceea ce ați putea folosi în timpul dezvoltării). Vestea bună este că se pare că îmbunătățirile aduse Swift abordează în mod continuu această problemă și, prin urmare, este probabil ca în viitorul apropiat Swift să genereze executabile cel puțin la fel de rapid sau mai rapid decât Objective-C.

Totuși, există o altă avertizare la viteza lui Swift. Scopul Swift este că dezvoltatorii nu vor scrie același cod pe care l-ar fi scris în Objective-C. Ce înseamnă asta pentru performanță? Ei bine, cu siguranță înseamnă că compararea performanței dintre Swift și Objective-C este mai implicată decât pot dezvălui simple benchmark-uri. De asemenea, înseamnă că compararea performanței absolute de rulare a executabilelor generate spune doar jumătate din poveste.

Toată lumea își dorește programe rapide, dar de multe ori viteza de dezvoltare este la fel de importantă – dacă nu mai mult. Un limbaj care este mai expresiv, capabil să realizeze mai multă muncă în mai puține linii de cod, poate fi un beneficiu imens în acest sens. Pe de altă parte, atunci când lucrezi într-un limbaj compilat în care ciclul editare-compilare-executare-depanare ocupă o mare parte din ziua unui programator, un compilator lent poate afecta productivitatea. Deși dovezile sunt în primul rând anecdotice, se pare că compilatorul Swift este în prezent suficient de lent pentru a fi enervant, mai ales când lucrează cu cod care exersează sistemul avansat de tip Swift. Un grup a considerat chiar că viteza de compilare este suficient de problematică pentru a motiva trecerea înapoi la Objective-C.

Compilatorul

Vorbind despre compilatorul Swift, acesta este în sine sursa și mai multor avertismente atunci când se ia în considerare trecerea la noul limbaj Swift. În afară de viteza de compilare, deoarece Swift a apărut din grupul mic de dezvoltatori care lucrează cu el la Apple și a fost dezlănțuit în masă, compilatorul a început să arate crăpături sub stres. Există chiar și un întreg depozit GitHub dedicat colectării de exemple de cod care vor cauza blocarea compilatorului Swift.

Există, de asemenea, întrebarea cum se va schimba compilatorul Swift. Un alt proiect de pe GitHub colectează speculații și analize din partea comunității cu privire la schimbările care ar putea fi pregătite pentru Swift. De exemplu, operatorii personalizați pot pune o presiune semnificativă asupra unui parser. Inițial, operatorii personalizați din Swift nu puteau folosi un semn de întrebare (?). Deși acest lucru a fost remediat în cea mai recentă versiune Swift, solicitările continuă să sosească din partea comunității în creștere de dezvoltatori Swift pentru și mai multă flexibilitate în ceea ce poate fi considerat un operator personalizat valid.

De fiecare dată când auziți că analizatorul pentru o limbă este în flux, ar trebui să vă dea o pauză. Analizatorul unui limbaj este inima și sufletul unui limbaj de programare. Înainte ca orice semantică a limbii să poată fi aplicată pentru a da semnificație codului, analizatorul este cel care determină ce este și ce nu este codul valid pentru început. Prin urmare, este încurajator faptul că Apple a promis că va asigura un anumit nivel de compatibilitate la timp de rulare pentru Swift. Acest lucru nu garantează, totuși, că codul Swift va rula fără a fi recompilat pentru fiecare nouă lansare a Xcode și/sau iOS. Nici nu garantează că nu va trebui să rescrieți porțiuni din codul dvs. Swift pentru a rămâne compatibil cu versiunile viitoare ale Swift. Dar din nou, angajamentul Apple de a face acest proces cât mai lipsit de durere este cel puțin o mică consolare.

Comunitate

Unele dintre cele mai proaste limbaje de programare create vreodată (care vor rămâne fără nume) au fost susținute, mult timp după ce bunul-simț spune că ar fi trebuit să fie relegate în coșul de gunoi al tehnologiei eșuate numai de puterea comunităților lor respective. În același timp, colecția de limbaje de programare cu adevărat drăguțe care nu au reușit să pună stăpânire în lipsa unei comunități sunt prea numeroase pentru a fi luate în considerare. Comunități puternice produc tutoriale, răspund la întrebări despre Stack Overflow, petrec online sau în persoană la conferințe, împărtășind povești, sfaturi și trucuri și scrieți și împărtășiți biblioteci utile. Atunci când alegeți ce limbă să utilizați pentru un proiect, comunitatea este cu siguranță ceva de luat în considerare.

Din păcate, comunitatea iOS/Objective-C nu are cea mai bună reputație de a fi prietenoasă și primitoare. Acest lucru se schimbă treptat, iar open source joacă un rol din ce în ce mai important în dezvoltarea Objective-C. Totuși, în acest stadiu incipient, este greu de spus cum va arăta comunitatea Swift în viitor. Va consta în principal din dezvoltatori insulari care lucrează numai din API-urile oficiale Apple și propriile lor colecții private de cod? Sau va fi o comunitate vibrantă de grupuri care împărtășesc sfaturi, trucuri și biblioteci utile?

O altă fațetă a rolului comunității este rolul dezvoltatorilor Swift înșiși. Tendința generală în programare a fost de a trece de la limbajele și platformele de programare proprietare la soluții open source. Dezvoltarea Open Source, mai ales la nivel de limbaje de programare și runtime, poate fi un real avantaj. În timp ce dezvoltatorii Swift au declarat de mai multe ori că intenția lor este să deschidă complet limba și timpul de rulare Swift, acest lucru nu a avut loc încă, așa că se impune precauție.

Acestea fiind spuse, dezvoltatorii din spatele Swift sunt unii dintre aceiași dezvoltatori din spatele proiectului LLVM de lungă durată. LLVM nu este o analogie perfectă, deoarece a început viața în aer liber ca un proiect de la Universitatea din Illinois, Urbana-Champaign. Dar spre meritul lor, dezvoltatorii de bază au rămas foarte deschiși și implicați în comunitate, chiar și după ce majoritatea dintre ei au trecut la lucrul pentru Apple. Este complet rezonabil să ne așteptăm că limbajul Swift va continua să fie dezvoltat (în mare parte) în mod deschis, deși rămâne de văzut dacă patch-urile și sugestiile de caracteristici din partea comunității își vor face vreodată drum în limbaj.

Ar trebui să învăț Swift?

Nu există, desigur, un răspuns „unică pentru toate” aici. Ca întotdeauna, alegerea instrumentului potrivit pentru job necesită o cunoaștere intimă a tuturor detaliilor proiectului în cauză. Cu siguranță, în acest moment, Objective-C rămâne alegerea „sigură” pentru dezvoltarea iOS, dar Swift este cu siguranță demn de luat în considerare.

Cea mai semnificativă schimbare pe care Swift o aduce dezvoltării iOS este că mulți dezvoltatori își vor pune, pentru prima dată, întrebarea: „Ce limbaj ar trebui să folosesc?” Având în vedere istoria Apple, Objective-C și platforma iOS, această schimbare este destul de interesantă, mai ales având în vedere că alegerea nu este binară. În timp ce Apple și-a clarificat preferințele, comunitatea de dezvoltatori iOS în general lucrează din greu de ani de zile, oferind deja și mai multe răspunsuri posibile la această întrebare.