Având în vedere că nu am găsit niciun thread dedicat subiectului “tipizare statică vs. tipizare dinamică” (știu: cam forțată traducerea) mă gândeam că ar fi interesant de dezbătut.
Din moment ce nu prea văd cu ce aș putea să contribui la acest subiect, exceptând opinii neavizate și/sau pur subiective, vin cu următoarea lectură de weekend (deși lungă de 2h, aş zice că merită să-i dați o șansă):
În ciuda titlului, nu se rezumă la types în JavaScript, ci se ating multe alte puncte adiacente interesante:
static/dynamic typing, strongly/loosely typing, duck typing, gradual typing, type inference
comparații între abordări ale subiectului types, în cadrul altor limbaje precum TypeScript, Go, Java, Python
aspecte legate de software engineering, software quality, impactul uman asupra evoluției software în timp
tooling-ul și interdependența acestuia cu/de type systems
se insistă mult pe a scoate în evidentă numeroasele nuanțe ale unor adevăruri circulate ca fiind absolute
necesitatea formalizării vs. supraformalizare
Aștept și alte puncte de vedere, sau comentarii/adăugiri la cele relatate în înregistrare.
Initial feedback: Jesus Christ, 2 ore o singura discuție. Thanks god ca putem seta in ziua de azi viteza de playback.
Ar fi fost cool daca tot te-ai uitat sa pui si niste concluzii, sau TR DL ale tale.
Fara a fi terminat inca de vizionat discutia, eu cred ca discutia ar fi trebuit mai degraba axata pe “la ce NU ajuta static types” sau mai degraba “ce e rau in static types”. Faptul ca ceva nu exista in acest moment, nu inseamna ca nu ar trebui sa fie, ca e rau, si in concluzie n-am nevoie de static types.
Orice tehnologie se schimba, se transforma, se dezvolta. JavaScript s-a schimbat oarecum mai mult (desi unele din asa zise schimbari sunt de fapt doar syntactic sugar) doar in ultimii ani. Poate gresesc dar e unul din limbaje care are cele mai mici schimbari de-a lungul vietii, in special corelat cu popularitatea lui.
Eu sunt super incantat de async await, mi se pare huge ca s-au pus de acord sa-l aduca in ES7. Ramane insa amuzant cum nu poti sa faci inca usor o encapsulare adevarata(ma refer la private data) chiar si cu asa zisele “clase” in ES6.
Un lucru interesant e ca JavaScript e atat de raspundit si folosit in a scrie aplicatii complexe, incat au inceput sa apara in mod evident noi nevoi. Senzatia mea e ca se fac patchuri in limbaj, dar in esenta, ca limbaj si tehnologie, incepe parca parca sa arate ca nu e right tool or the job. Numai pura existenta a Flow sau TypeScript arata ca exista o nevoie reala, caci complexitatea aplicatiilor web de exemplu azi e hilar de mare cu ce se scria in anii 1998 de exemplu.
Astept insa sa descopar in video ceva interesant legat de “la ce NU ajuta static types” sau mai degraba “ce e rau in fixed types”.
Meh, iar aud ca SOLID inseamna OOP https://youtu.be/SikO_SC9tRg?t=17m10s
E adevarat ca contextul in care a aparut e OOP si chiar in definita pe Wikipedia e legat de OOP, dar poti sa aplici multe din aceste concepte si in ASM daca vrei.
Clasele la urma urmei sunt syntactic sugar in orice limbaj, sunt doar functii si variabile intr-un anume context. Daca vrei, poti sa mimezi clase fara a avea efectiv suport de clase, nu spun ca trebuie sa faci asta, dar e aberant sa spui ca SOLID sau design patterns se refera doar la OOP.
Inca ma uit, daca pana la sfarsitul discutie nu vad exemple clare de cod cu comparatii, e trist
Exact acelasi sentiment l-am avut si eu. Am renuntat sa ma uit la tot, am sarit la diverse momente, slaba organizare a discutiei. 2 ore e foarte mult doar pentru un singur topic.
M-am uitat pana la sfarsit, mai bine zis am ascultat si din pacate n-au fost exemple de cod si comparatii.
Ar fi fost interesante cateva exemple, uite aici chiar e necesar “static type” si facem asa, dincolo nu este necesar ba “chiar incurca” cum spunea unul dintre ei.
Pe ansambul discutia a fost placuta, oamenii simpatici insa senzatia mea este ca in public erau oameni care stapaneau mai bine subiectul si practic au pierdut timpul (12 utilizatori TypeScript sau similar).
