Recent, tot mai mulți oameni au ales limbi de programare cu tastare dinamică. Suporterii tipăririi dinamice susțin că studiul lui Erlang'a durează două săptămâni, după care puteți începe să scrieți un cod de luptă. În același timp, Internetul este tastat dinamic, acele erori de tip sunt rapid localizate și eliminate cu ușurință, iar problema reală este erorile logice complexe, în care tastarea statică încă nu ar ajuta. Această scriere statică este lentă și plictisitoare, iar pe Clojure poți scrie cu ușurință Mortal Kombat în două seri. Să aflăm de ce nu ar trebui să dorești într-adevăr tastarea dinamică.
Să începem cu una simplă. Toată lumea știe că limbile cu tastare statică sunt de obicei mai rapide decât limbile cu tastare dinamică. Acest lucru nu este surprinzător, pentru că într-un tipuri de limbaj tastate sunt verificate static la momentul compilării, și, prin urmare, de multe ori nu au nevoie pentru a stoca informații despre tipurile într-un program compilat, și cu siguranță nu trebuie să în mod constant re-examina tipuri în timpul rulării. În plus, informații exacte despre tipuri vă permit să aplicați coduri suplimentare de optimizare, lucru imposibil de realizat în limbile cu tastare dinamică. Orice s-ar putea spune, viteza devine importantă atunci când se dovedește că puteți utiliza doar 10 servere în loc de 200 de servere.
Chiar și în limbi tastate dinamic folosesc o variabilă pentru a stoca valorile de diferite tipuri, cum ar fi un șir de caractere sau un număr de cod considerat miros. Drept rezultat, încă mai scoateți tipurile în minte. Doar, spre deosebire de compilator, uneori vă greșiți. În unele limbi dinamice tipizate, există opțional verificarea tipului la momentul compilării. Dar, de exemplu, în cazul Erlang (1) funcționează uneori mai lent decât tipul de verificare în Haskell, (2), atunci când te folosește de fapt, trebuie să se deducă manual tipuri sau semi-automat folosind Typer, (3) programul potrivit, dializor, foarte sablat. Nu este surprinzător faptul că, în practică, de multe ori erlangisty sacrificate pentru dializor și ieșire tipuri în minte. Întrebarea este, deoarece încă mai folosiți tipuri, de ce să nu instruiți compilatorul să emită și să le verifice?
Supliment: Raportul surselor independente. că probleme similare au locul lor în lumea Clojure.
Unii programatori dau vina în mod nemărginit de limbi statice tipărite pentru verbositate sau lipsa de flexibilitate. De fapt, nimic nu împiedică, de exemplu, să scrie pe Haskell, ca și cum ar fi Erlang cu un Dialyzer înșurubat. Adică, folosiți liste, tuple, șiruri și numere, fără a introduce alte tipuri suplimentare. Dacă dintr-o dată doriți să declarați o listă în care sunt stocate atât șiruri și numere, puteți introduce pur și simplu tipul de date StrOrInt = S String | Eu int si apoi declar lista listei lui StrOrInt. Sau ia tipul finit Either. Sau puteți utiliza tipuri existențiale.
Mulți oameni cred în mod eronat că tastarea statică nu protejează decât de o clasă limitată de erori, de exemplu, că nu adăugați un șir cu un număr. De fapt, cu ajutorul ei puteți face mult mai mult. De exemplu, în cadrul web Yesod, folosind tipuri, printre altele, verifică faptul că aplicația nu se referă la o adresă URL inexistentă. Pe parcursul lui Haskell, tipurile sunt controlate de efectele secundare. Printre altele, acest lucru are un efect pozitiv asupra performanței aplicațiilor. De exemplu, dacă aveți nevoie să efectuați calcule pentru unele date, le veți primi odată într-un cod "murdar" și apoi le veți transfera la o funcție curată, în loc să obțineți în mod constant aceleași date în diferite funcții. În Haskell, datorită tipurilor, se garantează faptul că atunci când lucrați cu STM. fiind în interiorul tranzacției, nu veți încerca să transferați nimic prin rețea, dar când lucrați cu Template Haskell - nu inserați șablonul în care nu aparține.
Datorită tipurilor vă petrece mai puțin timp pentru toate de rutina cum ar fi O și tipul de verificare în minte, pentru a găsi și de a elimina erorile de triviale, optimizare cod, care, se pare, și încetini un nicăieri și scris teste plictisitoare de „două serii plus două sunt egale cu patru. " Refactorizarea este mult simplificată. În general, în loc să faceți față tuturor acestor prostii, faceți ceea ce ar trebui să facă programatorul - scriind caracteristici.
Apropo, despre testele. Experiența arată că colegii convinși de necesitatea de a scrie teste sunt dificil. Ce păcat să ascundeți, chiar să vă convingeți, nu este ușor. Testele de scriere sunt plictisitoare. Ei trebuie să-și petreacă timpul pe sprijinul lor. În lumea reală, cerințele pentru aplicație se schimbă în mod constant. Și asta înseamnă o rescriere constantă a testelor. Prin urmare, fie programatorii sunt mai lenți, fie aveți nevoie să angajați persoane suplimentare pentru a susține testele. Atunci când se testează o aplicație mare și complexă, testele se transformă și într-o aplicație complexă și complexă, care nu este mai mică decât cea testată, trebuie optimizată și, de asemenea, să găsească și să remedieze erorile. În practică, este imposibil să se acopere 100% din cod cu teste, iar modul de automatizare a testelor aplicațiilor cum ar fi compilatoarele, jocurile 3D sau motoarele de căutare este, în general, de neînțeles. Nu vorbesc despre faptul că testele sunt adesea pur și simplu ciocănite.
În cele din urmă, ca o lipsă de limbi cu scriere statică, se numește de multe ori complexitatea lor în studiu. În primul rând, personal am îndoieli serioase cu privire la acest lucru. Nu aș spune că Scala sau OCaml este mult mai greu de învățat decât Perl sau Erlang. Și Haskell, de fapt, nu foarte dificil, pur și simplu trebuie să-l învețe încet și gânditor, mai degrabă decât în grabă. În al doilea rând, chiar dacă acest lucru este atât, în practică, este puțin probabil să aibă o dorință puternică de a scrie un proiect pe Erlang cu un programator, care a citit o carte în urmă cu o săptămână Cesarini și Thompson. Cel mai probabil, veți dori să găsiți o persoană care, cel puțin în șase luni, a scris către Erlang orice proiecte pentru ele însele. Și în al treilea rând, este mai bine să-și petreacă N luni pentru a studia Haskell, apoi începe să scrie pe ea se potrivesc destul de cod decât câteva săptămâni pentru a învăța orice altă limbă, și să înțeleagă cum să aibă de fapt, să scrie pe ea, doar câțiva ani mai târziu.
În concluzie, observ că scrierea statică îmi amintește de un parașut de rezervă. Cu un parașut, sarele sunt puțin mai convenabile și chiar și acest parașut de rezervă prost nu sa dovedit niciodată util mulțimii. Din aceasta rezultă că parașutele de rezervă doar împovărează inutil parașutiștii?