A metaprogramozás arra a sokféle módra utal, ahogyan egy program önmagáról tudással rendelkezik vagy önmagát manipulálni tudja.

A C#-hoz hasonló nyelvekben a reflexió a metaprogramozás egy formája, mivel a program képes megvizsgálni az önmagáról szóló információkat. Például egy objektum összes tulajdonságának listájának visszaadása.

Az olyan nyelvekben, mint az ActionScript, futás közben kiértékelhetünk függvényeket, hogy új programokat hozzunk létre, például eval(“x” + i). A DoSomething() egy x1 nevű objektumra hatna, ha i 1, és x2-re, ha i 2.

Végezetül, a metaprogramozás egy másik gyakori formája az, amikor a program nem triviális módon megváltoztathatja önmagát. A LISP jól ismert erről, és ez olyasmi, amit Paul Graham körülbelül egy évtizeddel ezelőtt védelmezett. Meg kell keresnem néhány konkrét esszéjét. De a lényege az, hogy a program egy másik programrészt változtatna meg annak állapota alapján. Ez olyan szintű rugalmasságot tesz lehetővé a futásidejű döntések meghozatalában, ami a legtöbb mai népszerű nyelvben nagyon nehéz.

Azt is érdemes megjegyezni, hogy a régi szép időkben, amikor még egyenesen assembly-ben programoztunk, a futásidőben önmagukat módosító programok szükségesek és nagyon gyakoriak voltak.

Paul Graham “What Made Lisp Different” című esszéjéből:

Néhány nyelvben van valami, amit makrónak hívnak. De a Lisp makrók egyedülállóak. És akár hiszed, akár nem, amit csinálnak, az a zárójelekhez kapcsolódik. A Lisp tervezői nem azért tették a nyelvbe a sok zárójelet, hogy más legyen. A Blub programozó számára a Lisp kód furcsán néz ki. De azok a zárójelek okkal vannak ott. Ezek a külső bizonyítékai a Lisp és más nyelvek közötti alapvető különbségnek.

A Lisp kód Lisp adatobjektumokból áll. És nem abban a triviális értelemben, hogy a forrásfájlok karaktereket tartalmaznak, és a karakterláncok a nyelv által támogatott adattípusok egyike. A Lisp-kód, miután az elemző beolvasta, olyan adatstruktúrákból áll, amelyeken át lehet haladni.

Ha érted, hogyan működnek a fordítók, akkor valójában nem is annyira az történik, hogy a Lispnek furcsa szintaxisa van, hanem inkább az, hogy a Lispnek nincs szintaxisa. A programokat a fordítóprogramon belül generált elemzőfákba írod, amikor más nyelveket elemezel. De ezek a parse fák teljesen hozzáférhetőek a programjaid számára. Írhatsz olyan programokat, amelyek manipulálják őket. A Lispben ezeket a programokat makróknak hívják. Ezek olyan programok, amelyek programokat írnak.

Programok, amelyek programokat írnak? Mikor akarsz ilyet csinálni? Nem túl gyakran, ha Cobolban gondolkodsz. Mindig, ha Lispben gondolkodsz. Kényelmes lenne itt, ha adhatnék egy példát egy erős makróra, és mondhatnám, hogy tessék! mit szólsz hozzá? De ha ezt tenném, az csak halandzsának tűnne annak, aki nem ismeri a Lispet; itt nincs hely arra, hogy elmagyarázzak mindent, amit tudnod kell ahhoz, hogy megértsd, mit jelent. Az Ansi Common Lispben igyekeztem olyan gyorsan haladni a dolgokkal, ahogy csak tudtam, és még így sem jutottam el a makrókig a 160. oldalig.

De azt hiszem, tudok egy olyan érvet mondani, ami meggyőző lehet. A Viaweb szerkesztő forráskódja valószínűleg 20-25%-ban makrókból állt. A makrókat nehezebb megírni, mint a közönséges Lisp függvényeket, és rossz stílusnak tartják a használatukat, ha nem szükségesek. Tehát a kódban minden makró azért van ott, mert muszáj. Ez azt jelenti, hogy a program kódjának legalább 20-25%-a olyan dolgokat csinál, amiket más nyelven nem lehet könnyen megcsinálni. Bármennyire is szkeptikus a Blub programozója a Lisp titokzatos erejéről szóló állításaimmal kapcsolatban, ez kíváncsivá kell, hogy tegye. Nem a saját szórakoztatásunkra írtuk ezt a kódot. Egy aprócska startup voltunk, olyan keményen programoztunk, ahogy csak tudtunk, hogy technikai akadályokat állítsunk magunk és a versenytársaink közé.

Egy gyanakvó ember elkezdhetne azon gondolkodni, hogy van-e itt valami összefüggés. A kódunk nagy része olyan dolgokat csinált, amelyeket más nyelveken nagyon nehéz megcsinálni. Az így létrejött szoftver olyan dolgokat csinált, amire a versenytársaink szoftverei nem voltak képesek. Talán volt valamilyen kapcsolat. Arra bátorítom, hogy kövesse ezt a szálat. Lehet, hogy több van abban a mankóval bicegő öregemberben, mint amennyire látszik.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.