Metaprogramarea se referă la o varietate de moduri în care un program are cunoștințe despre el însuși sau se poate manipula singur.

În limbaje precum C#, reflecția este o formă de metaprogramare, deoarece programul poate examina informații despre el însuși. De exemplu, returnarea unei liste cu toate proprietățile unui obiect.

În limbaje precum ActionScript, puteți evalua funcții în timpul execuției pentru a crea programe noi, cum ar fi eval(„x” + i). DoSomething() ar afecta un obiect numit x1 atunci când i este 1 și x2 atunci când i este 2.

În cele din urmă, o altă formă obișnuită de metaprogramare este atunci când programul se poate modifica singur în moduri non-triviale. LISP este bine cunoscut pentru acest lucru și este un lucru pe care Paul Graham l-a susținut cu aproximativ un deceniu în urmă. Va trebui să caut câteva dintre eseurile sale specifice. Dar ideea este că programul ar schimba o altă parte a programului în funcție de starea acestuia. Acest lucru permite un nivel de flexibilitate pentru a lua decizii în timpul execuției care este foarte dificil în majoritatea limbajelor populare de astăzi.

De asemenea, este demn de remarcat faptul că în vremurile bune ale programării în asamblare directă, programele care se modificau singure în timpul execuției erau necesare și foarte obișnuite.

Din eseul lui Paul Graham „What Made Lisp Different”:

Multe limbaje au ceva numit macro. Dar macrourile Lisp sunt unice. Și, credeți sau nu, ceea ce fac ele este legat de paranteze. Proiectanții lui Lisp nu au pus toate acele paranteze în limbaj doar pentru a fi diferiți. Pentru programatorul Blub, codul Lisp arată ciudat. Dar acele paranteze sunt acolo cu un motiv. Ele sunt dovada exterioară a unei diferențe fundamentale între Lisp și alte limbaje.

Codul Lisp este alcătuit din obiecte de date Lisp. Și nu în sensul trivial că fișierele sursă conțin caractere, iar șirurile de caractere sunt unul dintre tipurile de date suportate de limbaj. Codul Lisp, după ce este citit de parser, este alcătuit din structuri de date pe care le puteți parcurge.

Dacă înțelegeți cum funcționează compilatoarele, ceea ce se întâmplă de fapt nu este atât de mult faptul că Lisp are o sintaxă ciudată, cât faptul că Lisp nu are sintaxă. Scrieți programe în arborii de analiză care sunt generați în cadrul compilatorului atunci când sunt analizate alte limbaje. Dar acești arbori de analiză sunt pe deplin accesibili pentru programele dumneavoastră. Puteți scrie programe care să le manipuleze. În Lisp, aceste programe se numesc macros. Ele sunt programe care scriu programe.

Programe care scriu programe? Când ați dori vreodată să faceți așa ceva? Nu foarte des, dacă vă gândiți în Cobol. Tot timpul, dacă gândești în Lisp. Ar fi convenabil aici dacă aș putea să dau un exemplu de macro puternic și să spun acolo! ce zici de asta? Dar dacă aș face acest lucru, ar părea doar niște baliverne pentru cineva care nu cunoaște Lisp; nu este loc aici pentru a explica tot ce ar trebui să știți pentru a înțelege ce înseamnă. În Ansi Common Lisp am încercat să avansez lucrurile cât de repede am putut, și chiar și așa nu am ajuns la macro-uri până la pagina 160.

Dar cred că pot da un fel de argument care ar putea fi convingător. Codul sursă al editorului Viaweb era probabil în proporție de 20-25% macros. Macros sunt mai greu de scris decât funcțiile Lisp obișnuite și se consideră că este un stil prost să le folosești atunci când nu sunt necesare. Așadar, fiecare macro din acel cod este acolo pentru că trebuie să fie acolo. Asta înseamnă că cel puțin 20-25% din codul acestui program face lucruri pe care nu le puteți face cu ușurință în orice alt limbaj. Oricât de sceptic ar fi programatorul Blub cu privire la afirmațiile mele despre puterile misterioase ale Lisp, acest lucru ar trebui să îl facă curios. Nu am scris acest cod pentru amuzamentul nostru. Eram un mic start-up, programând cât de tare puteam pentru a pune bariere tehnice între noi și competitorii noștri.

O persoană suspicioasă ar putea începe să se întrebe dacă nu cumva există o corelație aici. O mare parte din codul nostru făcea lucruri care sunt foarte greu de făcut în alte limbaje. Software-ul rezultat făcea lucruri pe care software-ul concurenților noștri nu le putea face. Poate că a existat un fel de legătură. Vă încurajez să urmăriți acest fir. S-ar putea să fie mai mult decât se vede la prima vedere la acel bătrân care șchiopătează în cârje.

Lasă un răspuns

Adresa ta de email nu va fi publicată.