this is for holding javascript data
Attila Góbi edited intro.tex
about 8 years ago
Commit id: fceaefed7c7ce1005160e9f13ab85a80ac390955
deletions | additions
diff --git a/intro.tex b/intro.tex
index 5e09ab5..a6c06d2 100644
--- a/intro.tex
+++ b/intro.tex
...
\section{Bevezetés}
A magas szintű nyelvek megjelenésével egyidőben jelen meg az igény arra, hogy a fordítóprogramok képesek legyenek fordítási időben bizonyos programtulajsonságokat elemezni. Ennek eleinte két fontos praktikus oka volt. Az egyik, hogy így írt programok futási ideje felvegye a versenyt az assembly nyelven írt programokkal, ami különösen fontos volt az akkori szűkös hardware-eken. Másrész, akkoriban egy lyukkártyán leadott program esetében a fordítási hibát csak napokkal később kapta kézhez a programozó, célszerű volt tehát olyan fordítót írni, ami a lehető legtöbb hibát és lehetőséges hibáról visszajelzést ad a fejlesztőnek, illetve a lehető legtöbb esetben megpróbálja kitalálni a programozó szándékát.
A helyzet mára teljesen megváltozott, a szoftverfejlesztő a fordítás kimenetéről általában perceken belül visszajelzést kap, az assembly nyelv pedig csak néhány speciális területen van használatban. Érdekes módon azonban a programok fordítási idejű elemzésének igénye egyáltalán nem csökkent. Ellenkezőleg, a mai szoftverek olyan méretűre nőttek, hogy azokat egy ember már képtelen átlátni, ennek következtében egyre nagyobb szerepe van a fordítónak abban, hogy az esetleges programhibákat már fordítási időben kiszűrje.
Másrészt az utóbbi években egyre több mindent software vezérel (gondoljunk a mostanában terjedő Internet of Thingsre), és ezek egy része az emberi élet szempontjából is kritikus lehet. Egy ilyen példa a repülőgépek fly-by-wire rendszere, amelyek vezérlésének válaszidejére komoly garanciákat kell a gyártónak adnia. Ezeket rendkívül bonyolult szoftverekkel lehet csak bizonyítani, az emberi munkával történő bizonyítás komoly versenyhátrányt jelentene a tervezőknek.
Egy másik példa a mai beágyazott rendszerek. Egy mai készülék komoly hardware és software együttese, ha valahogy meg tudjuk határozni a beágyazott rendszeren futó software hardware-igényét, azzal a gyártó a gyártási költségeit tudja optimalizálni, ami egy nagy példányszámban eladott termék esetén hatalmas lehet. A legtöbb ilyen termékben a gyártók a mai napig C nyelvet használnak, mert a programozóknak ezen a nyelven van a legnagyobb kontrollja a memóriahasználat felett. Sajnos egy modernebb nyelv hardware-igénye és válaszideje (pl. szemétgyűjtés miatt) jóval kiszámíthatatlanabb, ezért ezekbe a szegmensekbe a modern nyelvek nem tudtak betörni annak ellenére, hogy a software-fejlesztési költségeket jelentősen csökkentené.
A fenti okok miatt kezdődött el a kutatása annak, hogy a programok erőforrásigényét elemző eszközökkel meg lehessen mutatni. Ennek egyik lehetséges megoldása, hogy a kész, lefordított programot vizsgáljuk. Másik megoldás, hogy a program struktúráit vizsgáljuk magas szinten. Ennek egyik példája a fejlett típusrendszer, amelynek nagy előnye, hogy a program és a program elemzése lényegében ugyanabban a programkódban történik lényegében külső nélkül. Más megközelítés az a módszer, amelyeket a fordítóprogramok használnak a programok elemzésére, pl. adatfolyam analízis és absztakt interpretáció.
Doktori dolgozatomban azzal foglalkoztam, hogy funkcionális nyelvekben (Haskell és F#) előforduló adatszerkezetek mérete hogyan határozható meg fordítási időben. Ez az információ közvetlenül segít a memóriahasználat kikövetkeztetésében, és közvetve felhasználható a futási idő elemzéséhez is.
