A programozási technikák és jellemzõik.

A szoftver krízis.

A strukturált és az objektum-orientált tervezés jellemzõi.

A kezdetek

A legelsõ elektronikus számítógépek utasításait, programját kapcsolótáblákon állították be, de már az I. generációs gépek korában megjelentek azok a módszerek, amelyekkel off-line eljá­rás­sal lyuksza­lagra vagy lyukkártyára rögzítették a gépi utasításokat, a 8-as vagy a 16-os szám­rendszer jeleivel rövi­dített formában. Ezekbõl a kódokból a bináris változatot "egyszerû" konvertáló áramkörökkel hozták létre. Ezt a programozási technikát nevezzük ma gépi kódú programozásnak. A gépi kódú progra­mok tervezés 424j99e e nem volt könnyû feladat. A folyamatáb­rák, mint programtervezési eszközök ebbõl a korból származnak. Jelentõségük a programter­ve­zés­ben ma már meglehetõsen korlátozott, de a bo­nyolultabb elágazások, ciklusok szemlél­tetésére, illetve a következõkben tárgyalt assembly nyelvi környezetben még ma is használjuk õket.

A programozási nyelvek fejlõdésének következõ állomása az Assembly-nek nevezett nyelvi struktúra volt. Ez az alábbi könnyítéseket jelentette a gépi kóddal szemben:

- Az utasítások kódjait azok angol nevének rövidített alakjaival helyettesítjük. Ezeket emlé­keztetõ kódoknak, idegen szóval mnemoikoknak nevezzük (pl. az összeadás uta­sítás 04 gépi kódja helyett az írhatjuk, hogy ADD).

- Az operandusok tárbeli címeinek oktális vagy hexadecimális alakja helyett valami­lyen ér­telmes vagy értelmezhetõ karaktersoroz­ato­kat, úgynevezett szimbólumokat használhatunk (pl. ADD szám1, szám2).

- A számokat a megszokott tízes számrendszerbeli alakjukban írhatjuk a programban.

- Az utasítások egy-egy sorozatát összefoghatjuk és egyetlen névvel hivatkozhatunk rá. Ezeket makroutasításoknak hívjuk.

Az assembly szintû programnyelvek hasonlóan a gépi kódú programokhoz, a különbözõ uta­sításkész­letû (processzorú) gépeken különbözõek, ezért ezeket a nyelveket gépre orientált nyelveknek nevez­zük.

Az assembly-ben megírt programkódot már nem lehetett a processzor által elfogadott kódúvá alakítani áramkörök segítségével. Készítettek viszont olyan programokat, amelyek ezt a kon­verziót elvégezték. Ezeket assemblereknek, vagy assembly fordítóprogramoknak nevezték

A magas szintû, vagy eljárás-orientált programnyelvek kora

A géptõl független programozási nyelvek (magas szintû nyelvek) elmélete a digitális számító­gépek megjelenésekor már igen jelentõs eredményeket mondhatott magáénak. Turing, Church, Neumann ne­vét említhetjük meg ezzel kapcsolatban. A 60-as években az új programozási nyelvek száma exponen­ciális növekedésnek indult, de ezek közül csak kevés vált fontossá új fogalmak vagy az alkalmazások szempontjából.

Az elsõ alkalmazható magas szintû nyelv - amihez már fordítóprogram, a compiler is elké­szült- a FORTRAN az 1950-es évek közepére az IBM támogatásával jött létre. Elnevezése a FORmula TRANslation -képlet átalakító- rövidítésébõl származik. Elsõsorban matematikai-mûszaki alkalmazá­sokra szánták. Különbözõ, egyre fejlettebb verzióit egészen a 70-es évekig széleskörûen használták.

Az ALGOL 60 1963-ban jelent meg, ez elméletileg sokkal jobban kidolgozott nyelv volt, mint a FORTRAN. Az ALGOL 60-ban bevezetett fogalmak nagy része szinte minden késõbbi programnyelv­ben megmaradt, például a blokk, az eljárás, stb. Annak ellenére, hogy az algo­ritmuselmélettel kap­csolatos publikációk szinte kizárólag ALGOL-ban jelentek meg, ezt a nyelvet konkrét alkalmazások­ban csak nagyon ritkán használták fel. Ennek oka talán az volt, hogy I/O utasításokkal nem rendelke­zett.

1959-ben az USA hadügyminisztériumának szorgalmazására alkották meg a COBOL-t, a név a COmmon Business Oriented Language - közös üzleti célú nyelv -bõl származik. Kidolgozá­sa­kor elsõ­sorban adatfeldolgozási szempontokat tartottak szem elõtt. A COBOL számos új fogalmat vezetett be. Ezek egyike a géptõl független adatleíró rész ötlete, ami késõbb az adat­bázisrendszerek fogalmához vezetett. A nyelv az angolt olyan mértékben használta, hogy a programot szinte olvasni lehessen.

A szoftver krízis

A 60-as évek közepén az IBM egy nagyszabású nyelvtervezésbe kezdett a 360-as gépeire. Ez az új nyelv a PL/I (Programming Language One) azzal a szándékkal született meg, hogy a FORTRAN, ALGOL és COBOL lehetõségeit egyesítse. Az univerzális számítógépek univer­zá­lis nyelvének szán­ták. Két alapvetõ, új fogalmat vezettek be benne:

- a kivételkezelést, ami lehetõvé tette, hogy a programozó szokatlan események     bekövetkezé­sé­­hez utasításokat rendeljen (on endfile.., on error...., stb.),

- a párhuzamosan végrehajtható feladatok (multitasking) kezelésének lehetõségét.

A PL/I számos kedvezõ tulajdonsága ellenére sem terjedt el olyan mértékben, ahogy azt vár­ták. Ezt elsõsorban az okozta, hogy a szoftverkrízis egyre inkább érzékelhetõ problémaköre nem viselte el a PL/I-ben programozók viszonylag hosszú kiképzési idejét.

A gépi kódú programozás korában a programokkal szemben támasztott legfontosabb köve­telmény a tárral való takarékosság és a futási idõ minimalizálása volt. Ezt az akkori hardver fejlettségi szintjét tekintve nem is kifogásolhatjuk. A processzorok sebességének és az opera­tív tárak kapacitásának nö­vekedésével azonban egyre nagyobb és egyre bonyolultabb progra­mok születtek. Ezek tervezése, il­letve a helyes mûködés bizonyítása egyre több gondot oko­zott. A rendszerek kidolgozása késett (néha éveket is), a költség sokkal több lett, mint ahogy azt eredetileg tervezték, a kifejlesztett rendszer pedig megbízhatatlan volt, nehéz volt karban­tartani és nem volt olyan hatékony, amint azt el lehetett volna várni. Nyilvánvalóvá vált, hogy a programok méretének növekedésével, a programszerkezetekkel szemben támasztott igénye­ket át kell értékelni. Amint Dahl a "Strukturált programozásról" címû dol­gozatában írta:

"Arra a következtetésre jutottam, hogy legsürgõsebben véget kell vetni annak a szemléletnek, amely szerint a programozásban a legfontosabb feladat a ráfordítás/ teljesítmény viszony op­timalizálása. Fel kell ismernünk, hogy a programozás már ma is sokkal inkább a bonyolultság megszervezésének, a nagy méretekkel járó hatalmas káosz lehetõ leghatékonyabb elkerülésé­nek a mûvészete."

A strukturált programozás kényszere

A növekvõ szoftverkrízis és a programhelyesség bizonyítása iránti igény egy új (európai) nyelvhez, a PASCAL-hoz vezetett. Ez a korábbiaknál sokkal hatékonyabbnak bizo­nyult ( ter­mészetesen akadnak hibái is, pl. a  dinamikus tömbindex-határok, a kivételkezelés vagy a pár­huzamos, konkurens eljárások hiánya), amit elsõsorban az új tervezési módszerek erõs támo­gatásának köszönhetett. Ezeket a mód­szereket összefoglaló néven strukturált programozásnak, illetve tervezésnek nevezzük Ezek részleteseb­ben a következõ­ket jelentik:

A tervezés elsõ szakaszában az algoritmust részmûveletek sorozatára bontjuk. Például, ha a t_i-vel egy bizonyos, meghatározott résztevékenységet jelöltünk, akkor a t₁ t₂,t₃,..,t_n szekvenciális sorozat végre­hajtása egyben a program végrehajtását is jelenti. Ezeket a hagyományos folya­matábra szimbólumok­kal is ábrázolhatjuk:

Ha a résztevékenységek az adott programnyelven közvetlenül kódolhatók, vagy ismert alapal­goritmu­sokkal helyettesíthetõk, akkor a tervezést ezen a ponton be is fejezhetjük. A t_i-ket ilyenkor elemi lépé­seknek hívjuk. Legtöbbször azonban nem ilyen egyszerû a helyzet. Elõször is nem minden program építhetõ fel csupán szekvenciális elemi lépéssorozatokból. Elõfor­dul­hat, hogy az egyes tevékenységek végrehajtása bizonyos feltételektõl függ. Ezt tisztán a szek­venciális sorozattal nem lehet leírni. A fel­tételektõl függõ végrehajtás az

if feltétel then t1;

if feltétel then t1 else t2;

case szelektor of sl :t1; s2:t2;... sn:tn [else tn+1] end

elemi döntésekkel írható le a PASCAL-ban. Az alábbiakban megadtuk a megfelelõ folyamatábra szimbólumokat is, de fontos hangsúlyozni, hogy a strukturált tervezésben ezeket önálló egységeknek kell tekinteni, tehát nem bonthatók fel tovább utasításokra.

Könnyen beláthatjuk, hogy a második if és a case utasítás helyettesíthetõ az elsõ if utasítással azonos szerkezetû elágazásokkal és szekvenciális tevékenységek sorozataival. Sõt bebizonyít­ható, hogy ez minden programra igaz.

A többször végrehajtandó programrészeket a ciklusutasítások segítségével írhatjuk le. A PASCAL-ban ciklusszervezésre az alábbi utasításokat használhatjuk:

a.) for ciklusváltozó := kezdõérték to végérték do t;

b.) for ciklusváltozó := kezdõérték downto végérték t;

c.) while feltétel do t;

d.) repeat t1,t2,..tn until feltétel,

ahol a t és a t₁,..,t_n a ciklusmag, vagyis azt a tevékenységet jelöli, amit a paraméterektõl füg­gõen eset­leg többször is végre kell hajtani. Természetesen a tervezéskor megadhatjuk a fenti utasítások mind­egyikét magyarul is. Az ilyen tervet "mondatszerû" programtervnek hívták. Emellett számos más grafikus tervezési módszert is kitaláltak, de egyik sem lett olyan népszerû és sikeres, mint a korábbi, az assembly szin­tû tervezésben bevezetett folyamatábra-rendszer.

Ha a tervezés során a forrásnyelvû kódhoz lépésenkénti finomítással jutunk el és mindenütt csak a fenti sémákat engedjük meg, vagyis a szekvenciális tevékenységek sorozatát, a felté­teltõl függõ elága­zásokat és a ciklusokat, akkor az ilyen programtervet strukturáltnak mond­hatjuk. Ez persze nem azt jelenti, hogy az algoritmust a fenti folyamatábra szintig kell lebon­tani, hiszen ehhez az elemi tevé­kenységeket a nyelv utasításainál kisebb egységekkel kellene megadni, holott a programterv végsõ alakja a forrásnyelven kódolt program.

A jól strukturált programok megértését, illetve a helyes mûködésük bizonyítását a

lépésenkénti elemzés,

a teljes indukció és

az absztrakció

módszereinek alkalmazásával kielégítõen elvégezhetjük. A lépésenkénti elemzéssel a szek­venciális tevékenységek és az elágazások jól vizsgálhatók, a teljes indukció pedig a ciklusok elemzésének esz­köze. Az absztrakció például abban lehet segítségünkre, hogy a programok által kezelt objektumokat egzakt, többnyire matematikai fogalmakkal helyettesíthessük.

Az, hogy a programtervet bizonyos mértékig meghatározza a feladat szintjén megfogalmazott algorit­mus, nem szorul különösebb magyarázatra. Talán kevésbé ilyen nyilvánvaló, hogy a program szerke­zetére a feldolgozandó adatok szerkezete is igen jelentõs hatással lehet. A PASCAL például egy olyan programnyelv, ami rendkívül sokféle és rugalmas adatszerkezettel rendelkezik, így nagyon jól struktu­rált programokat készíthetünk ezen a nyelven, ha helyesen választjuk meg az adattípusokat. Egy konk­rét feladat megoldására persze nagyon sok jó meg­oldás készíthetõ. A programozó felelõssége az, hogy jól használja ki az adott programnyelv által nyújtott lehetõségeket úgy az algoritmusok, mint az adat­strukturák megválasztásakor. A jól strukturált programok az alábbi elõnyöket nyújtják:

- Az algoritmus könnyen érthetõ lesz a forráskódból, mûködését nyomon lehet követni.

- A program moduláris szerkezetû lesz, ami megkönnyíti  a lépésenkénti elemzést és az egyes tevékenységek önálló tervezését és kódolását.

A számítógép rendszerek nagyméretû, nagyon összetett és nagyfokú párhuzamosságot tartal­ma­zó al­kalmazásainak elõsegítésére (ismét az USA Hadügyminisztériuma támogatásával) 1980-ra egy a PASCAL-on alapuló nyelvet hoztak létre, az ADA-t. Megalkotásakor úgy tûnt, a jövõ nagy számító­gépeinek nyelvét hozták létre. A mikrogépek viharos térhódítása azonban minden jóslatot felborított. Ma már biztosra vehetõ, hogy az ADA a strukturált program­ter­ve­zés korá­nak egyik utolsó, nagygépes eljárás-orientált nyelve maradt.

Rendszerközeli programozás

Az eddig említett programnyelveket a számítógépes alkalmazásokhoz fejlesztették ki, az ope­rá­ciós rendszerek, a magas szintû programnyelvek fordítóprogramjai, bizonyos szerviz-prog­ra­mok fejleszté­séhez nagyon sokáig még az assembly-ket használták. Ez érthetõ is, hiszen ezeknél a szoftvereknél a hardver hatékony kihasználása sokkal fontosabb lehet, mint az alkal­ma­zá­sok esetében. A közepes ka­tegóriájú számítógépek operációs rendszeréhez, a UNIX-hoz fejlesztették ki a C nyelvet. Ez egyesíti magában a magasszintû nyelvek szerkezeti tulaj­don­sá­ga­it, támogatja a strukturált és ma már az ob­jektum-orientált programfejlesztést is, illetve az assembly nyelvekhez hasonló szinten lehetõvé teszi a hardverhez való közvetlen hozzáférést. A C a közepes kategóriájú gépeken általánosan használt, de ma úgy tûnik, hogy népszerûsége a mikrogépek körében is egyre növekszik. Legújabb, már OOP-s vál­tozataival olyan szoftver rendszereket hoztak létre, mint a WINDOWS vagy a NOVELL.

Interaktív rendszerek

Egy másik területen, a gép és a felhasználó közötti interaktív kapcsolat kezelésében a magyar szárma­zású John Kemeny által kifejlesztett BASIC-et (Beginners All-purpose Symbolic Instruction Code- kezdõk általános célú szimbolikus utasítás kódja) említhetjük meg. Ez a nyelv nem fordítóként, hanem értelmezõként (interpreter) lett bevezetve és a negyedik generá­ciós gépeken nem várt karriert futott be. Eredeti változatai nem tartoztak az elméletileg jól megkonstruált nyelvek közé, egyik nyilvánvaló hibájuk a strukturált programtervezés támo­gatásának hiánya volt. Javított, már objektum-orientált változatai azonban szinte mindenütt elõ­fordulnak, ahol inter­aktivitásra van szükség.

Adatbázis-kezelõk

A programozási nyelvekkel, illetve a programozási technikával szembeni újabb kihívást jelen­tettek a tömegtárolók elterjedésével megjelenõ óriási adathalmazok, az adatbázisok. Olyan új algoritmusokra volt szükség, amelyek kielégítik például az alábbi követelményeket:

1. több, egymással összefüggõ adatfájlon átvezetett adatmanipulációk,

2. az állományokhoz való párhuzamos hozzáférés lehetõsége,

3. az adtatok védelme illetéktelen felhasználóktól és véletlen hibáktól,

4. könnyen tanulható kezelõfelület biztosítása a felhasználónak.

Ezeket az új programrendszereket  adatbázis-kezelõ rendszereknek nevezték el. Az adatbá­zisok szer­vezési módja kétféle adatmodellt használ, a hálóst és a relációst. Ezek közül szá­mítógépen az utóbbi kezelése bizonyult sikeresebbnek. A relációs adatbázis-kezelõ rendszerek már a számítógépek III. ge­nerációjának végén, IV. gene­rá­ciój­á­nak elején megjelentek, de iga­zán széleskörûen csak a IV. generá­ciós mikrogépeken terjedtek el. Az elsõ relációs adatbázis-kezelõ mikrogépes nyelv a dBase interpreter volt. A FOXBASE tulajdonképpen a dBase ja­vított változatának tekinthetõ, de késõbbi verziói, pl. a FOXPRO­, már igen jelentõs eszközöket tartalmaznak, elsõsorban a felhasználói kap­csolatok tervezésében. Az interpreteres változatok mellett fordítókat is készítettek, ilyen például a CLIPPER, a dBase-hez hasonló adottságok­kal.

A relációs modell lehetõvé tette egy olyan adatmanipulációs nyelv elkészítését, amely az adatszerke­zetek megadását, az adatkezelést és az adatbiztonságot matematikailag megalapozott, szabványos esz­közrendszerrel oldja meg. Ez a nyelv a SEQUEL (Structured Query Language), az IBM terméke (1976). A nevét késõbb SQL-re változtatták. Az SQL-t ma már min­den adatbáziskezelõ rendszer tar­talmazza, illetve amelyek nem, azok egyszerûen kihaltak. 

Integrált környezetek

A miroszámítógépek fejlõdésével és robbanásszerû elterjedésével az operációs rendszerek fejlesztõi nem tudtak lépést tartani. Az alkalmazások fejlesztõire hárult az a feladat, hogy egy-egy, még erõsen hardver-orientált operációs rendszerre építve egy nagyobb feladatcsoport igé­­nyei­nek megfelelõ, könnyen kezelhetõ alrendszereket hozzanak létre. Ezeket a szoftvereket összefoglaló néven integrált rendszereknek nevezzük. A hardver gyors fejlõdése és a struktu­rált tervezési módszerek lehetõvé tet­ték az egyre bonyolultabb programrendszerek létrehozá­sát. Ennek következtében a számítógépeket olyan területeken kezdték használni, amit koráb­ban szinte el sem lehetett képzelni. A teljesség igénye nélkül csak néhány ilyen alrendszert említünk meg.

A DTP (DeskTop Publishing) a szövegkészítés és feldolgozás integrált rend­szereinek gyûjtõ­neve. Elterjedt képviselõje pl. a PageMaker és a Corell Draw. A CAD (Computer Aided De­sign) a mûszaki tervezést, a CAM (Computer Aided Manufacturing) a gyártási folyamatok automatizálását segítõ al­rendszer. Megjelentek az elsõ próbálkozások az oktatás és tanulás számítógépes segítéséhez, a CAI (Computer Aided Instruction) és a CALL (Computer Aided Language Learning). Ma már az integrált rendszerek olyan tömegével találkozik a felhasz­náló, amit nem lehet egykönnyen rendszerezni. Azt azonban szinte mindegyikrõl elmondhat­juk, beleértve a legkorábban megjelenteket is, hogy nem le­zárt, hanem folyamatosan, néha na­gyon gyorsan fejlõdõ rendszerek.

Objektum-orientált programozás és tervezés (OOP, OOD)

A mikrok elterjedésével csakhamar kiderült, hogy a szoftver krízist nem lehet leszûkíteni a hardver és az alkalmazói szoftver illesztési problémáira. A felhasználói  környezet szerepének növekedése oda vezetett, hogy a strukturált programtervezést támogató nyelvek, mint például a PASCAL vagy a C nem bizonyultak elég hatékonynak az új feladatokhoz. Az új program­terve­zési módszer, amitõl a fel­használói interfésszel kapcsolatos gondok megoldását remélhet­jük, az objektum-orientált programo­zás. Alapjait szintén egy a 60-as években megje­lent programnyelvben, a SMALLTALK -ban fektet­ték le. Ma már a hagyományos nyelvek újabb változa­ta­iba átvették az OOP alapelveit , amelyeket az alábbiakban foglalhatjuk össze:

Az objektumtípus (osztály) a valóság egy modellje, amiben a valóságos objektumtípus (va­lami­lyen létezõ egyed, pl. ember, vagy absztrakt fogalom, pl. mátrix, négyszög, stb.)  adatmodelljét és az ezen manipuláló függvényeket és/vagy eljárásokat, metódusokat ad­hatjuk meg. A metódusok az objektumok viselkedését írják le.

Objektumtípus=adatmodell+metódusok.

Az objektumok egy objektumtípushoz tartozó változók. Ezek zárt egységek, adataikat csak saját tí­pusuk metódusai ismerik, illetve változtathatják meg. Az objektum környeze­te, ha ismeri az objektum metódusait, kérheti azok végre­haj­tását. Ezt a kérést üzenetnek nevezzük.

Egy objektumtípusból további objektumtípusok származtathatók úgy, hogy vagy az adat­mo­dell, vagy a metódusok egy részét megváltoztatjuk vagy kibõvítjük. Ez az új típus is­meri az õsének az összes adattípusát és metódusát.  

Ha a leszármaztatott objektumtípusban az õs típus adattípusát vagy metódusát újra, ugyan­olyan név­vel, de más tartalommal adjuk meg, akkor a leszármaztatott objektum ugyanarra az üzenetre másképpen viselkedhet.

Az objektum orientált tervezés és programozás segítségével sokkal nagyobb és bonyolultabb felada­tok programjai készíthetõk el gyorsan és megbízhatóan, mint a strukturált módszerek­kel. Tulajdon­képpen a grafikus felhasználói felület (GUI) igénye indukálta ezt a felismerést, de ma már nincs olyan területe a szoftverfejlesztésnek, ahol ne törekednének az alkalmazá­sára. Az említett elõnyöknek természetesen ára van, mégpedig a hardver rosszabb kihaszná­lása

Negyedik generációs eszközök

Az OOP elterjedése a szoftverfejlesztésben oda vezetett, hogy a hagyományos programozási techni­kák helyett új grafikus fejlesztõ eszközök jelentek meg. Ezek a formális nyelvek szinta­xisának isme­rete helyett vizuális manipulációkból képesek helyes magas szintû kódot gene­rálni. Ez azt jelenti, hogy a programozás "mûvészete" szakmai szintrõl felhasználói szintre csök­kenthetõ. A hagyományos nyelvek "visual" változatai már megjelentek, de más területe­ken is gyors, használható eredmények várhatók. Pédaként megemlíthetjük az SQL-t és a HTML-t is.

Azt hihetnénk, hogy a hagyományos programozási technikákra ezek után már nem sokáig lesz szük­ség.  Sajnos, ez nem igaz. A számítógépekkel való emberi kommu­nikáció továbbra is a formális nyel­vekre épül. A negyedik generációs eszközök fejlesztése, megbízható használata nem képzelhetõ el nélkülük.

A Java

Az Internetes alkalmazások iránti fokozott igény következménye a JAVA programnyelv, a SUN cég fejlesztése. Természetesen támogatja, sõt egyenesen kikényszeríti az objektum-ori­entált fejlesztési technikát. Hasonlít a C++-hoz, de könnyebben tanulható és kifejezetten "el­osztott" környezetre tervezték.. Ez azt jelenti, hogy a futó program egyes részei, illetve az adatai nem kell, hogy ugyanazon a gépen legyenek. Ahogy a SUN-szlogen mondja: " a hálózat a számítógép". A "hordozható" programokat készít, azaz környezettõl, operációs rendszerek­tõl függetlenül használható. Ezt úgy oldják meg, hogy a különbözõ operációs rendszerekre te­lepítenek egy JAVA "vituális gépet" (JAVA plattform), ami a fordítóprogram outputját értel­mez­ni fogja. Ezt természetesen operációs rendszerenként külön-külön kell elkészíteni. A for­dító egységes, úgynevezett "bájt kódot" készít, amit virtuális gép fog értelmezni és végrehaj­tani. Emellett a JAVA virtuális gép opcionálisan végrehajtható formára is képes fordítani a bájt kódot, a gyorsabb futás érdekében.

A JAVA applet-ek a WEB-lapokba építhetõ kis alkalmazások vagy modulok. A JAVA scrip-t­ek viszont nem tekinthetõk igazi JAVA alkalmazásoknak. A script­­-eket  a NETSCAPE cég vezette be, és bár JAVA formátumban írhatók, más értelmezõt igényelnek, nem "hordoz­hatók" és nem fordíthatók bájt kódra.

Egyéb "egzotikus" nyelvek

A 60-as években keletkezett nyelvek között megjelentek olyanok is, amelyek nem a Neu­manni architektúrák kiszolgálását célozzák. Az utasításcentrikus, úgynevezett imperatív nyel­vektõl megkülönböztetve, ezeket applikatív nyelveknek nevezzük. Egyik legfontosabb kép­vi­se­lõ­jük a LISP, amit máig is alapnyelvnek tekinthetünk ezen a területen (Az AUTOCAD pl. LISP-ben programozható). A PROLOG, vagy a magyar fejlesztésû M­-PROLOG szintén is­mert képviselõje ennek a nyelvcsaládnak. Az e nyelveken fejlesztett alkalmazások általában a mesterséges intelligencia körébe tartoznak. és természetesen ma még nagyobb részben Neumann-elvû gépeken futnak, de találhatunk már ötödik generációs megvalósításokat is.

Zárszó, 2000 körül:

Minden elõzetes jóslat és várakozás ellenére ma még mindig a Neumman-elvû gépek uralják a számítástechnikát. A nem-Neumanni architektúrák evolúciója sokkal lassúbb lett, mint ahogy azt vártuk. A hardver fejlesztések tartalékai még igen jelentõsnek látszanak ahhoz, hogy ez az állapot hosszabb ideig fennmaradjon. Elmondhatjuk, hogy most, elsõ felismerése után 40 év­vel, a szoftver krízis még mindig velünk van. Bár valódi fejlõdés következett be tervezési szemléletünkben, fejlesztési módszereinkben, a fejlesztõi gárda oktatásában, ennek ellenére a programok iránti igény gyorsabban nõtt, mint ahogy azt a fejlesztõk ki tudták volna elégíteni. Még jobb eszközökre, technikára és módszerekre lenne szükség és talán a legfontosabb: jobb oktatásra és több tapasztalatra.