capcana


În ultima vreme se pare că toată lumea vrea creați un superset al limbilor ce sunt ei mai complex, pentru a facilita utilizarea acestuia fără a pierde funcționalitatea. În principiu, este o idee foarte lăudabilă și ar fi dificil să înțelegem că cineva este împotrivă, dar vreau să vă arăt câteva motive pentru care, de exemplu, crearea TypeScript poate fi contraproductiv (și nu are nimic de-a face cu a fi de la Microsoft, nu mă luați pentru un maniac).

Un limbaj de bază și popular

Vom face un exercițiu de imaginație. Să începem de la presupunerea că avem un limbaj de desenat în orice browser, care a fost adoptat ca standard și pentru care se propun actualizări care, afectând atât de mulți participanți (dezvoltatorii tuturor browserelor existente), practic nu ajung niciodată, deoarece este dificil să se ajungă la acorduri.

Limbajul nostru se va baza pe desenul liniar, așa că îl vom numi LineaScript. În el, desenarea unei linii va consta din doi pași: desenarea unui vector și acordarea de culoare. La rândul său, vectorul va fi generat din două puncte, cu coordonatele lor respective x și y.

După cum puteți vedea, limba noastră poate atrage orice, deoarece totul poate fi reprezentat în termeni de linii. Dificultatea începe atunci când vrem să desenăm o formă geometrică, nu neapărat complexă. De exemplu, pentru a desena un pătrat trebuie să o faceți folosind bucle:

Și oamenii ar fi de acord afirmând că LineaScript este un limbaj puternic și că trebuie să știți, deoarece este acceptat în toate browserele, dar că învățarea sa este foarte grea și utilizarea sa, plictisitoare.

Să o rezolvăm cu un nou limbaj

Deoarece este foarte dificil pentru noi să programăm eficient cu LineaScript și consorțiul de participanți la acesta nu este de acord când vine vorba de actualizarea limbajului, am decis obțineți un nou limbaj mult mai simplu, FiguraScript, care acceptă toată sintaxa LineaScript, dar adaugă și facilități la reprezentarea figurilor.

Acesta este FiguraScript ar fi un superset al LineaScript, deci nimeni nu ar trebui să se plângă că reinventăm roata. Dimpotrivă, acest lucru îi va face pe mulți oameni care nu îndrăznesc să programeze cu LineaScript să abordeze limbajul fără teamă.

Deci, cu noul nostru limbaj, ar fi practic la fel de ușor să trasăm un punct, o linie sau un dreptunghi:

Nimeni nu poate nega că limba noastră este mai completă decât LineaScript de bază. Permite experimentatului să continue programarea așa cum a făcut înainte, iar novicilor să folosească metode echivalente care necesită codificați mai puține linii pentru a obține același rezultat.

Oferim ușurință, concizie, compatibilitate completă (să nu uităm că limba noastră este un superset), simplitate ... Haide, toate sunt avantaje, corect?

Noua versiune a limbii originale

Marea greșeală a inițiativei noastre este să gândim în prezent și nu în viitor. Ce se va întâmpla când LineaScript lansează o nouă versiune mai completă? Indiferent cât de lent este procesul de extindere a limbajului, sunt atât de mulți interesați să-l îmbunătățească, lucru logic este că la un moment dat apare o nouă versiune a LineaScript care oferă funcționalități noi și este probabil ca o parte din funcționalitatea respectivă să se ciocnească cu ceea ce reflectasem în FiguraScript.

De exemplu, poate exista și clasa Rectangle, dar cu un constructor diferit care ia un singur punct, lățimea și înălțimea dreptunghiului. Poate credeți că aceasta nu este cea mai gravă problemă, deoarece dacă există o supraîncărcare a metodei, ambele inițializări pot fi compatibile.

Dar lucrurile se pot agrava, deoarece poate în noua versiune se creează o nouă funcție cu aceiași parametri pe care i-am folosit în FiguraScript, dar cu un comportament diferit. De exemplu, un constructor pentru un vector care primește coordonatele punctului de origine, o lungime pentru vector și o lățime de cale, ar avea aceeași sintaxă ca și constructorul pe care l-am adăugat în FiguraScript din coordonatele a două puncte.

Care dintre cele două comportamente trebuie să implementeze FiguraScript 2.0 pentru constructorul care primește patru numere întregi ca parametri?

Confruntat cu această situație, vom fi obligați să producem o nouă versiune a limbii noastre în care trebuie să decidem între două rele:

  • Adoptați noua sintaxă a LineaScript extins, făcând astfel FiguraScript 2.0 să nu mai poată interpreta programele scrise în versiunea 1.0, ca pierdeți compatibilitatea înapoi.
  • Continuați să susțineți metodele definite în 1.0 și pierde calitatea de a fi un superset din LineaScript și că nu orice programator al acestui limbaj își poate folosi codul direct în al nostru.

În orice caz, limba noastră va fi pierdut una dintre calitățile cu care ne lăudam inițial și, încetul cu încetul, își va pierde rațiunea de a fi și va ajunge probabil să dispară în uitare.

Ce am greșit?

Dacă noi, cu bună credință, am creat un limbaj care a facilitat accesul la unul mai popular, dar mai complex, ce am greșit? De ce trebuie să fim sortiți eșecului?

Oricine cunoaște teoria jocurilor lui John Nash va ști că problema este că am fost prea ambițioși și am căutat beneficiul nostru ignorând progresul LineaScript. Am propus un scenariu în care noua noastră limbă avea să fie un succes, aducând multe îmbunătățiri, în timp ce vechea limbă a rămas imobilă.

Cu toate acestea, strategia care oferea cel mai mare beneficiu comun a fost aceea de a colaborează activ la dezvoltarea LineaScript, astfel încât noua sa versiune, în care toate programele dezvoltate în versiunile anterioare ar continua să fie compatibile, ar încorpora și mai multe îmbunătățiri decât poate dezvolta fără colaborarea noastră.

Acum schimbați „Linie” la „Java” și „Figura” la „Tip” și veți ști părerea mea despre noua încercare a Microsoft de a muta spre complotul său.

Împărtășiți Capcana limbilor ca superseturi ale altor limbi