Egy sikerélményhez vezető eszköz a gondolkodásfejlesztésben, annak a téveszmének elkerülésére, hogy „mivel a programozás absztrakt tevékenység – s ilyen formán programozási nyelvtől független –, ezért a programozás tanítás is nyelvfüggetlenül végezhető”.
Az informatikaoktatás hajnalán jellemző volt a programnyelv oktatásának túlhangsúlyozása, egy „téveszme a négyzeten”, nevezetesen „informatika = programozás = programozási nyelv”.
E két szélsőség között kell a megfelelő utat megtalálni.
Nem szorul magyarázatra – meggyőződésünk szerint – az, hogy mekkora oktatási előnnyel jár, ha a tanuló egy rendszert (lehet az fizikai, kémiai, közgazdasági ...) maga is kipróbálhat, ha egy rendszerrel maga is kísérletezhet. A működés száraz leírásánál sokszorta többet jelent a „testközeli” próbálgatás, még akkor is, ha a valós rendszernek csak egy többé-kevésbé idealizált modelljét használhatja. Ilyen számítógépes eszközöket jelenthetnek a szimulációs programok.
A modell megismerése szempontjából a puszta programhasználatnál is több a modell tervezése és megvalósítása, azaz a szimulációs modellezés. Ilyen modellek elkészítésénél természetesen nem állhatunk meg. A modellnek a kísérlet aktív résztvevőjévé, számítógépes eszközzé kell válnia. Kijelenthetjük, hogy a való világ rendszereinek megismeréséhez, működésük megértéséhez a számítógépes szimuláció gondolkodásmódjának megértetésén, és annak programozásán keresztül vezet az út.
Észre kell vegyük, hogy ez a hozzáállás, tehát a „feladatmegoldás algoritmikus alapon” rendelkezik egyfajta „univerzalitással”, azaz: a téma és az idealizáció fokától nagyban független. (Szemben például a hagyományosabb matematikai módszerekkel, amelyek jelentősen módosulnak, „durvulnak” az idealizáció csökkentésével. Kezdetben esetleg elegendő egy lineáris egyenlet, vagy egyenletrendszer, később ez magasabb fokúvá válik, amely megoldása már teljesen eltérő módszert igényel, végül akár differenciál egyenletrendszerek megoldására kényszerülünk.) [SzP1]
Egy részről fontos cél a különféle programozási nyelvosztályok modellezése. Pl.:
Más oldalról hasznos lehet az alkalmazói rendszerekhez kapcsolódó nyelvek modellezése; mint például a Quattro/Excel vagy a WinWord makrónyelvéből kinőtt WordBASIC, majd Visual BASIC, de gondolhatunk a TEX rejtélyesebb képességeit kiaknázó makrók nyelvezetére, esetleg a MAPLE-höz hasonló matematikai rendszerek programozási lehetőségeire ...
Bizonyos körülmények esetén szó lehet az átlag műveltséget meghaladó programozási ismeretek tanításáról is. Így például felvételi előkészítés, OKJ-vizsga címén.
Ebben a fejezetben magához a programozási nyelv értékeléséhez adunk néhány fontos szempontot, most nem foglalkozunk a hozzákapcsolódó fejlesztői környezettel.
A fentiek alapján legalább háromféle szempontból beszélhetünk első programozási nyelvről:
A nyelv egyszerűsége alapja a könnyű megtanulásának. Ez több tényezőtől függ: az alapszavak, alapelemek egymáshoz és a forráskódba illeszkedésének milyensége, a programszerkezet, és a következetesség.
2.2.1.1. Alapszavak, azonosítók
Az alapszavak milyensége befolyásolja a kezdőlépések gyors megtehetőségét, hiszen a kezdők ezekkel találkoznak először. Az „ősi” BASIC-ben pl. 6½ kulcsszó volt csupán: LET, IF, GOTO, FOR, INPUT, PRINT, DIM.
A LET kulcs-szó hamar kikopott a nyelvből, mivel – kiderült – az értelmezőprogramnak nem volt szüksége az utasítás felismeréséhez. Erre utaltunk a 6½-lel.
Ennél egyszerűbb tehát aligha lehet egy programozási nyelv. Vitathatatlan, hogy ha egy alapszó rövid, akkor legalábbis a bebillentyűzése egyszerű. Ezen az alapon dicséretes tömörségű az APL de, hogy ez valóban az egyszerű megértést szolgálja-e, az alábbi ábra megnézése után válaszoljunk.
Egy APL programrészlet, amely kiválogatja az összes prímet 1 és R közöttHa a Forth programozási nyelvre gondolunk, akkor valahol a BASIC és az APL közötti bonyolultságra gondolhatunk, hiszen vannak kulcsszavai, amelyek kiolvashatók, és vannak jellé töményülőek. Az utóbbiak funkciója az azonosítójából kitalálhatatlan.
Egy Forth programrészlet, amellyel megelőzte a korát (a vektor „objektuma”)Az alapszavakon túllépve: a BASIC korai verzióiban a változók azonosítójának az a tömörsége, hogy egy speciális szimbólum, egy (a változó végéhez illesztett) ún. sigil jelzi a benne tárolható tartalom típusát, kétség kívül a gépelést egyszerűsítő szerepű, de a nem kifejező volta miatt erősen kritizálható. Hasonló a „logikája” a Perl-nek is, amelyben a változók azonosítója kap egy „előkét”, amely az adat struktúrájára utal ($ – skalár, @ – tömb, % – hash-tábla...). Ezek a sigilek implicit attribútum-jelölők, bár rövidek, mégsem szolgálják a kezdők programozás tanulását.
A C-ben sem segíti a kezdő programozók dolgát a beolvasás vagy kiírás elvégzésénél megadandó formátumkarakter, amellyel a változó típusát konkretizáljuk – nem is beszélve a beolvasásnál használatos & operátor értelmezéséről.
Egy C programtöredékElgondolkodtató az olvashatóság túlhangsúlyozása pl. a COBOL esetén. Aritmetikai műveleti „jeleknek” is nevük van: ADD, SUBTRACT, MULTIPLY, DIVIDE...
Megállapítható, hogy olyan szimbólumok rövidítés célú alkalmazása lehet elfogadható, amelyek esetleg más (tudomány-) területen (pl. a matematikában) már meghonosodtak, és közismertségnek örvendenek, de természetesen az ottanival azonos értelemben használható. Így világos a kifejeznivalója, és rövid. Ilyenek például a legtöbb nyelvben a négy alapműveletet jelző operátorok, vagy a C-szerű nyelvekben található kapcsos zárójelpár.
Az alapszavak programba illeszkedésének a módja is érdekes lehet: kiemelendők-e, nagybetűkkel (mint az ELAN-ban, a COMAL-ban, vagy a Modulaban), kisbetűkkel (mint a C-szerű nyelvekben), vagy máshogyan (pl. aposztróffal, mint az ALGOL 60-ban)? Általában a kis- és nagybetűk megkülönböztetésének kényszere is fontos (stílust meghatározó) módszertani kérdés. (A C-szerű nyelvek kisbetű-nagybetű érzékenyek, szemben a Pascal vagy a BASIC nyelv megoldásával.) Bonyolítja ugyan a gépelést, hogy erre a „finomságra” is ügyelni kell, de világosabbá teheti a program struktúráját, javítja az olvashatóságát, és nem utolsó sorban pontosságra nevel.
Sunyi hibákat okozhatnak bizonyos alapszavak hiánya, mint pl. a típusokat jelölők hiánya. Gyakori hiba: a hibaüzenetet sem okozó típuskeveredés az explicit típusdeklaráció nélküli nyelvekben, amelyekben dinamikusan és automatikusan definiálódik egy-egy adat típusa. (Lásd Perl, JavaScript, PHP.)
Az explicit típusdeklaráció számlájára írható a következő JavaScript-beli, dátumot meghatározó utasítás hibája: 1900+ev+":"+ho+1+":"+nap. Nem mindegy, hogy a + műveletet milyen típusú operandusokon hajtjuk végre először. A helyes megoldás: 1900+ev+":"+(ho+1)+":"+nap, ahol az ev=(new Date()).getYear(), ho=(new Date()).getMonth(), nap=(new Date()).getDate().
2.2.1.2. A programszerkezet, a programbeli szerkezetek egyszerűsége
A program áttekinthetősége mind a program írásakor, mind a program olvasásakor sarkalatos. Az áttekinthetőség szempontjából nyilvánvaló előny az egyszerű szerkezet. (Általános jó tanácsként mondhatjuk, hogy ezt a célt elősegítendő igyekezzünk kialakítani a megfelelően strukturált programkód írásának igényét.) Számos programozási nyelvben az adatok deklarációjának a helye nincs fixen rögzítve (C-alapúak), sőt akár el is hagyhatók (JavaScript, PHP). Tehát alig van ezzel kapcsolatban a programozónak megjegyezni valója. Viszont gondoljunk bele, hogy ez utóbbi esetben egy-egy elgépelés során egy új, általunk nem kívánt azonosítóval rendelkező változó jön létre. Az ilyen hibák felfedezése bizony nem egyszerű feladat.
Vajon tényleg az-e az egyszerű, amely nem szabályozott? Azaz, ha egy szabállyal kevesebbet kell megtanulni, akkor könnyebbé is válik a programozó dolga? Nyilvánvaló a válasz: a kevesebb szabály csak akkor tekinthető előnyösnek, ha a kód áttekinthető marad, és az egyszerűsítés nem okozhat rejtélyes hibákat. Tehát deklarációval kapcsolatos példánk előnyösnek éppen nem mondható. Amit sugall, a slamposság, határozottan káros magatartásra buzdít.
A szabályok memorizálhatóságát a következetesség nagyban támogathatja, hiszen van ugyan megtanulandó szabály, de az adott szabály – a következetesen alkalmazhatóság miatt – többféle szinten, vagy helyzetben is használható.
Kezdjük a példák sorát néhány pozitívval! Gondoljunk a Pascal hierarchikus programszerkezetére: program-szerkezet → procedure / function-szerkezet; vagy a C-szerű nyelvek összetett operátoraira: a+=b ugyanaz, mint a=a+b → a-=b ugyanaz, mint a=a-b; és még néhány hasonló operátor. Nem így a ++i vagy i++, amelyek ugyan rövidek, de a jelentésbeli különbség kitalálhatatlan megfelelő magyarázat nélkül.
Találhatunk azonban további negatív példákat is. A szintaxisban érthetetlen „környezetfüggőségek” tapasztalhatók pl. a Pascalban: a Var és Const eltérő alkalmazása a kétféle deklaratív részben, nevezetesen a lokális adatok és a formális paraméterek megadásánál.
Két Pascal programtöredékIde sorolható a Pascalbeli While és Repeat ciklusok egymástól eltérő feltétel-értelmezése okozta bizonytalanság is. A BASIC-beli ciklusszervezési lehetőségek bősége is zavaró lehet a kezdők számára: Do {While|Until} Loop és a Do Loop {While|Until}. Ezzel szemben a C-szerű nyelvekben az elöl- és hátultesztelő ciklusok mindegyike bennmaradási feltételt használ, így könnyebb a megjegyzésük. De a C++ is szolgál rossz példával: gondoljunk a típusdefiniálásra a struktúra, illetve pl. a tömbtípus definiálásának eltérő szintaxisára: struct tipusnév{tip1 mező1; tip2 mező2; ...} ↔ typedef tip típusnév[méret] . Ezen a következetlenségen csak némileg segít a struktúra alternatív definiálási lehetősége: typedef struct { tip1 mező1; tip2 mező2; ...} típusnév. (Az persze világos, hogy a struct-tal egy típust hozunk létre, a typedef-fel pedig egy alias nevet egy meglévő típushoz. Ezt a „filozófia-különbséget” azonban csak a vájt fülű ismeri, a kezdőknek megnehezíti az adatabsztrahálást.)
Összetett szerkezetek eleje-vége jelzésének a kérdése: például az utasításokból álló blokk létrehozása a Pascal nyelvben a Begin-End kulcsszó párral történik, a C-szerű nyelvekben (C, C++, C#, Java, Javascript, PHP stb.) az ezt helyettesítő { és }-k rövidek és világosak. A Pascalban a Begin-End sokszor, de néha Case-End, Record-End, Repeat-Until; a C-szerű nyelvek esetén a ciklusmag vagy az elágazás ágai körül elhagyható (egy utasításos esetben) a { } zárójelpár. Nem vitás, az egy utasításos esetben alkalmazható egyszerűsítés (bármely nyelvben) igen veszélyes! Hasonlóan zavaró lehet a BASIC nyelv egyes verzióiban az, hogy az If utasításnak van lezáró párja, ha a kódban sortörést használunk, ha pedig ugyanazt egy sorba írjuk, akkor nincs. A Python szükségtelenné teszi a struktúrazáró kulcs-szavakat, mivel egyértelmű a blokk-struktúra a kijjebb-beljebb kezdés miatt. Ezzel két legyet üt egy csapásra: megspórol némi gépelést, és a struktúra könnyen felismerhető marad. De vegyük észre a dolog árnyoldalát is! Ez által a szerkezet tudatos kialakításának igénye sérülhet, így a továbblépést nehezítheti.
Zárjuk a felsorolást egy-két jó példával! Az ELAN-ban IF-ENDIF, REP-ENDREP
Maple-ben: if-fi, do-od... vagy a UNIX shell nyelvében az if-fi, for do-done és a case-esac szerkezete.
2.2.2.1. Egyszerű kódolás, könnyen tanulhatóság
Szemantikusan nem tér el lényegesen az algoritmikus nyelvtől, annak csak „precizírozása”. A kódolás érdekében ne kelljen a programon lényeges átalakításokat végezni. A nehézségeket néhány negatív példával mutatjuk be.
Elsőként gondoljunk a függvény érték-típusára tett korlátozások miatti procedurára történő áttérés kényszerére, a standard Pascal esetén. Jó hír: a FreePascalban már megengedett a rekord-, vagy a tömbértékű függvény is! Említhetünk egy másik tipikus „konverziós” kényszert is: az általános többirányú elágazás egymásba ágyazott If-ekké alakításának kényszerét (a switch-szerű utasítások szűk volta miatt), amely a procedurális nyelvek általános gondja; illetve a hátulfeltételes ciklus kilépési Repeat-Until ciklusbeli feltétel negálásának kényszerét, ismét a Pascal esetében.
Veszélyforrás a C-szerű nyelvek az algoritmikus nyelvben meghonosodottól eltérő operátor-szintaxisa::= (értékadás) helyett =; = (azonosság) helyett ==. A BASIC-ben az előbbi problémának csak a „fele” van meg, ui. az értékadás és az azonosság jele azonos.
2.2.2.2. Jó modellje nyelvosztályának
Következetesen, érzékletesen tartalmazza azon jellemzőket, amik lényegesek az osztálya szempontjából. Az OOP nyelvek családjába tartozik például a Java vagy a C# nyelv, amelyek tisztán valósítanak meg minden fontos OOP-s jellegzetességet. A Prolog pedig jól példázza a logikai nyelvek osztályát. A Logo „eklektikussága” azonban ebből a szempontból nem ideális, ugyanis nem mutatja meg világosan sem az automata-elvű, sem a funkcionális nyelvek jellemzőit.
A tipikusság másik irányú előnye jól harmonizál az 1.3-ban említett elvárások egyikével: a programozási nyelv legyen jó alap a továbblépéshez. Például a szabványos Pascal után kiváló lehetőségeink vannak az OOP-s vagy a 4GL-s folytatásra. A C-stílusú nyelveknek is számos alkalmas „folytatója” létezik.
2.2.3.1. Fejlesztés – haladó programozási stílus
Mivel az oktatásban alkalmazott nyelv a kialakuló programozási stílust is jócskán befolyásolja, ezért ez a szempont különösen fontos szerepet játszik a nyelvválasztásban.
A figyelembe veendő legfontosabb „stílusjegyek”:
people.inf.elte.hu/szlavi/InfoOkt/SzoftErt/Kivetelkezeles.htm
Pascal programtöredék 
Pascal programtöredék 
Az N-vezér backtrack feladat megoldása Pascal include-dalA 4GL-környezetek legtöbbje is támogatja ezt a modulokra épülő, „keretprogramos” oktatási stratégiát: az alkalmazói felületet kezelő modult készen adhatjuk a tanulónak, hogy ne ezzel a látványos, ámde az algoritmikus gondolkodást nem igénylő feladattal kelljen bíbelődnie, cserében egy külön modulba kiemeljük a lényeget jelentő alprogramokat (az eseménykezelők algoritmikusan érdekes funkcióit), s ezt a modult kínáljuk föl a tanulónak programozási feladatul.
A modularizáció lehetőségére néhány programozási nyelv példa: Pascal – include, unit; Modula, COMAL – modul; Ada – package; ELAN – pack; C, C++ – include, Java – imports, ...
A C#-ban, C++-ban vagy Javaban megtalálható, a típussal paraméterezett típus (generic vagy template típus) részben pótolható ellenőrzött include-dal (Pascal).
2.2.3.2. Használat – téma-univerzalitás
Rendelkezzen valódi „téma-univerzalitással”! Ez azt jelenti, hogy a nyelv támogassa bármely, oktatásban előforduló témához írandó program elkészítését: legyen szó akár szimulációról, amely egyrészt viszonylag nagy számítási sebességet, komolyabb méretű tömböket kíván, s nem mellesleg grafikai képességeket a megjelenítéshez.
Egy szimulációs program futás közben, amely egy konzolos Pascallal lett fejlesztveA lassúság oka lehet a nyelvhez kötődő végrehajtási stratégia, az interpretáltság is. Ez is számításba veendő!
A mai „shareware-world”-ben különösen fontos kérdés: van-e a kósza híreken, és a kísérletezéssel megszerezhető ismereteken túl más is, ami alapján megismerhető a nyelv? A szabványok és/vagy dokumentációk léte csak a szükséges (bár nem feltétlenül elégséges) feltétele annak, hogy egyáltalán szóba kerülhessen oktatásba bevezetendőként egy nyelv. Az elterjedtség viszont garancia lehet erre.
Az elterjedést olajozó tényezők: az ingyenesség, egy webes fejlesztői közösség támogatása.
  |
 |
 |
A tananyag az ELTESCORM keretrendszerrel készült