A dolog érdekessége számunkra az, hogy
Az oktatást nyilván a (1) „hétköznapok”, ill. a (2) szoftverfejlesztés szoftverei érdeklik.
Alkalmazásához ne legyen szükség
Alkalmasint szolgálhasson útmutatóul más, „rokon” szoftverek felé; kezdő eszközül „rokon” problémák megoldásához. Pl.:
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ástaní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, hogy „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 –hitem 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. Lásd SzimVsMat.htm.)
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 rendszerekhöz 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.
Először azt a kérdést vizsgáljuk, hogy maga a nyelv milyen, s nem pedig valamely implementációja.
Milyen könnyű megírni az első programot?
Kulcsfeltétele a kezdőlépések megtehetőségének, hiszen a kezdők figyelmének elsődleges „célpontja”.
Az „ősi” BASIC-ben pl. 7,5 kulcs-szó van csupán:
LET, IF, FOR-NEXT, GOTO, INPUT, PRINT, DIM.
Elborzasztó szintaktikai példák: BASIC – változó-„utókák”: v%, v$, v!, v#, v&, mint implicit típusjelölők.
(Emlékeztetőül: v% – egész, v& – hosszú egész, v$ – string, v! – egyszeres pontosságú, v# – dupla pontosságú.)
Forth - !, @, ... .
APL - [, #, ... .
Perl $xxx, @xxx, &xxx, %xxx, @[, @_ mint implicit struktúrajelölők.
(Emlékeztetőül: $xxx – skalárváltozó; @xxx – tömbváltozó; %xxx – hash-táblázat… .)
C++ – cin>>, cout<< szokatlan elnevezése és bontása a tevékenységének.
Ezeknek némileg ellentmond (?) az a tapasztalat, hogy a C-t sokan éppen olyan vonásáért dicsérik, amely rövidíti a gépelést és amúgy világos is: { és }, ezért OK. Nem így a '++i' vagy 'i++'.
Elgondolkodtató az olvashatóság túlhangsúlyozása pl. a COBOL esetén. Aritmetikai műveleti „jelek”: ADD, SUBSTRUCT, 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. Természetesen az ottanival azonos értelemben használható, így világos a kifejeznivalója, és rövid.
Az alapszavak programba illeszkedéséről: kiemelendők-e, pl. nagybetűkkel (ELAN, COMAL, MODULA ...), vagy máshogyan (kisbetűkkel, mint a C-szerű nyelvekben, aposztróffal, mint az ALGOL 60-ban)? Általában a kis- és nagybetűk megkülönböztetésének kényszere is fontos módszertani kérdés.
Kijjebb-beljebb kezdés: Python szükségtelenné teszi a struktúrazáró kulcs-szavakat, mivel egyértelmű a blokk-struktúra a kijjebb-beljebb kezdés miatt.
Illetőleg az implicit (értsd alapszó nélküli) döntések egy programban szintén zavarólag hathatnak. Pl. a Pascalban (C-ben) komoly veszélyforrás a hozzáférési jog nélkül szervezett paraméterátadás, ráadásul nehezen érthető a Const-tal történő paraméterátadással való összevetése. Hasonlóan igen sunyi hibákat okozhat bizonyos alapszavak hiánya, mint pl. a típusokat jelölők hiánya. Tipikus 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. Perl, JavaScript.)
Még egy adalék: a Perl paraméterezési szokásaiban a kulcs-szavak „furcsa jelekké egyszerűsödését” tapasztalhatjuk, ami igen veszélyes lehet…
Érdemes elgondolkodni azon, hogy mikor?, mi? a jobb: világos kifejezése annak, hol és mi az alapszó, vagy „ahogy tetszik” írni be őket. (Programozási stílus=Kifejezőség, precízség ↔ Programírási egyszerűség.)
Világosan átlátható, memorizálható programszerkezet.
Nagy kérdés, hogy a BASIC (PHP, Perl) egyszerűsége, „szabad” programozási lehetősége (változó deklarációk elhagyhatók, vagy szabadon, ad hoc módon elhelyezhetők) hasznos-e. Ide illik a C++ ’deklaráció az első használatkor’ szokása. Pl. for (int i=0; i<n; ++i) {…}. Hajlok rá, hogy hasznosnak minősítsem, mivel nyomatékosítja (sőt garantálja is!), hogy csak a ciklusban használható!
A szigorúság-kifinomultság ára: lásd az Eiffel-t, az Adát vagy a korábbi nyelvek közül a PL/I-t, amelyek túlon-túl sok, látszólag –esetleg valóban– érthetetlen szabállyal terheltek.
Sarkalatos az oktathatóság szempontjából a típusosság „mértéke”. (Vö.: Pascal / C.) Jó indulattal egyfajta kifinomultságnak tekinthetjük a C-szerű nyelvek tömörségét eredményező ’értékadás a kifejezésben’ lehetőségét. Pl. az ’a=2+(b=5);’ utasítás valójában azonos a ’b=5; a=2+b;’ utasításkettőssel. (A „hatás” és az „érték” ilyen szétválasztása komoly veszélyforrás!) Tehát ismét felvethetjük a ’tömörség vagy világosság’ kérdését.
Következetesség = kevés szabály (kevés kivétel) → kitalálhatóság.
Könnyen megjegyezhetők pl. az elválasztó jelek. Ellenpélda: Pascal vessző, pontosvessző használata a paraméterezésben (aktuális, ill. formális paraméterek), vagy mikor kell vessző, mikor lehet, mikor nem szabad (lásd IF..THEN..ELSE → ELSE előtt szintaktikus hiba, vagy FOR/WHILE..DO → DO után hibajelzés nélküli, igen sunyi szemantikus hiba).
A szintaxisban érthetetlen „környezetfüggőségek” tapasztalhatók megint a Pascalban: a VAR és CONST eltérő alkalmazás a kétféle deklaratív részben, nevezetesen a lokális adatok és a formális paraméterek megadásánál. Ide sorolható a WHILE és REPEAT ciklusok „szokásostól” eltérő feltétel-értelmezése okozta bizonytalanság. 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 tipusnév[méret]).
Összetett szerkezetek eleje-vége jelzésének kérdése. Pl. LCN Logo és a Python bekezdéses tagolás, kontra LogoWriter „kikényszerített” hányaveti sorfogalma; vagy más ellenpélda: Pascalban BEGIN..END sokszor, de néha CASE..END, RECORD..END, REPEAT..UNTIL; C++ 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 – ahogy az elválasztójelekkel kapcsolatban már szóba került! És egy jó példa: ELAN-ban IF..ENDIF, REP..ENDREP... Maple-ben: if..fi, do..od...
Hierarchikus építkezés (a felülről lefelé tervezés kódtükröződése) – szintenként azonos gondolattal építhető program.
Másfajta következetesség jó példájaként dicsérhetjük a Perl értékadás-szerű operátorainak családját: „+=”, „–=”, „*=”, „/=”, „**=”, „%=”, „&=”, „|=”, … . (Ez hasonlóan meg van számos C-szerű nyelvnél.)
Milyen könnyű átvinni az első programozási nyelv tapasztalatait a későbbiekre?
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. Gondoljunk például a függvény értéktípusára tett korlátozások miatti eljárásra történő kényszerű áttérésre Pascal esetén (bár a Free Pascalban már megengedett a rekordértékű függvény), vagy egy másik tipikus konverziós kényszerre: a többirányú elágazás → If-ekké; s még egyre: a ciklus kilépési feltétel negálására...
Jó példa a Perl „struktúrakezelése” értékadásokban: ($Van, $Melyik) = &Kereses($N,@X), amely jól illeszkedik az algoritmikus nyelv, sőt a specifikációnál alkalmazott utasítás rövidítésekhez.
Veszély forrása a C-szerű nyelvek az algoritmikus nyelvben meghonosodottól eltérő operátorszintaxisa: ’:=’ (értékadás) helyett ’=’; ’=’ (azonosság) helyett ’==’. Különösen a korábban (2.1.2.) említett ’értékadás a kifejezésben’ szintaktikai megfelelés mellett!
Következetesen, érzékletesen tartalmazza azon jellemzőket, amik lényegesek az osztálya szempontjából. A Logo „eklektikusságát” ebből a szempontból nem tartom ideálisnak: nem mutatja meg világosan sem az automata, sem a funkcionális nyelvek jellemzőit.
Legyen jó alap a továbblépéshez. Pl. a Pascal után az OOP vagy a 4GL folytatásra lehetőséget kínál a Delphi, ill. a Lazarus. A C-nek is számos alkalmas „folytatója” létezik.
Milyen könnyű elviselni a kialakult programozási szokásokat programírás közben
és magát a programot használat közben?
Mivel az oktatásba alkalmazott nyelv a kialakuló programozási stílust is alaposan befolyásolja, ezért ez a szempont különösen fontos szerepet játszik a nyelvválasztásban.
A legfontosabb „stílusjegyek”:
a) felülről lefelé programtervezés, mint gondolkozást meghatározó stratégia – finomítások, paraméterek (vö. Pascal, ELAN, Perl),
b) algoritmikus absztrakció – szekvencia, elágazások (l. C switch-beli break „elhagyhatósága”), ciklusok, eljárások/függvények/operátorok; vannak-e egyáltalán operátorok (az utóbbiak léte az oktatás későbbi fázisában, az adatabsztrakció fontossá válásakor lesz lényeges),
c) adatabsztrakció – elemi típusok választéka, felsorolási típus (I/O-műveletek!), típuskonstrukciós eszközök (pl. rekord Pascalban és C-ben, vs. tömb Pascalban és C-ben), a típus korrekt megvalósíthatósága (vö. BASIC, Pascal, ELAN, objektumorientált nyelvek),
d) mentes az „illegális” és veszélyes lehetőségektől (pl. a Logo-ban nem lehet(ne) értékadás; az algoritmikus nyelvekben GOTO, STOP, HALT, EXIT tilos, helyettük kivételkezelés ajánlott; e lehetőség nélkül sajátos kódolási szabályok szükségeltetnek),
e) mentes a nehezen észrevehető mellékhatásoktól (pl. függvény paramétere megváltozik, a lokális adatok láthatósági kérdései, vagy érték nélküli visszatérés egy függvényből),
f) beszédes azonosítók használhatósága (vö. ősi BASIC max. 2-jelű ↔ ELAN szóközöket is tartalmazó „mondatnyi”; Perl „változó-előkéi” [$, @, %...]),
g) modularitás lehetősége pl. a típusmegvalósításhoz (pl. a Pascal include-ja, Unit-ja, a Modula és a COMAL modulja, az Ada package-e, az ELAN pack-ja…)
Tartsa meg a „téma-univerzalitását”! Bosszantó, ha bizonyos problémák vizsgálatától nyelvi korlátok miatt kell eltekinteni. Például: kivárhatatlan lassúság (szimulációnál), a grafika teljes hiánya (pl. JavaScript) stb. A lassúság oka persze lehet egy, a nyelvhez kötődő végrehajtási stratégia (interpretáltság) is. Ez is számításba veendő!
A konkrét gép/operációs rendszer adottságaihoz (minimális mértékig) alkalmazkodjon a nyitottsága által: (ko)processzor, memóriamodellek, grafikai lehetőségek, egérkezeléshez rutinok ... Mindazon által ne függjön tőlük meghatározóan, kizárólagosan.
„Ó, azok a csodálatos, hősi évek...
egy program = egy félév”
Eddig a nyelvről általában esett szó. Ettől kezdve a megvalósítás mikéntje a legfontosabb kérdés, mellesleg tovább finomítjuk a nyelvi „jóság” szempontjait.
Ellenpéldák a korai professzionális nyelvek: programszerkesztés + fordítás + futtatatás + programjavítás papíron + ugyanezek újra. (Bár bizonyos nyelvi környezetek ma is ilyenek. Lásd UNIX-os Adát; vagy a szkript nyelveket, a böngészőben futó kódok nyelvi környezeteit általában.) Ezen némileg segítenek az „univerzális” (szintaxist ismerő) programszerkesztők programszerkesztők az ún. kódkiemelő (code highlighting) szolgáltatásukkal. Pl. BSEdit, Note++…
Komplettebb fejlesztői környezetek is vannak: Geany – Pascal, PHP, Java, Python…; Code::Blocks – C, C++, MATHLAB; NetBeans – Java, PHP, C++, C#…; … Hasznos szolgáltatás az ún. kódkiegészítés (code completion), amely gyorsabbá és biztonságosabbá teheti a kódolást. Erre általában képesek az igényesebb fejlesztői környezetek.
Interaktív futtatási lehetőségek: nyomkövethetőség (előre és vissza), ..., adatok menetközbeni lekérdezhetősége, módosíthatósága. Ez a programmal való „együttlélegzés” záloga; s ilyenformán a programozási kedvet, a program iránti „empátiát”, a fejlesztés hatékonyágnövekedését szolgálja.
A nyomkövetés módszertani jelentőséggel is rendelkezik a programozástanítás kezdeti szakaszában: lehetővé teszi a „számítógép hogy csinálja?” kérdés mélyebb megértését. Másrészről viszont elkényelmesíthet: csábít a gondolkodás nélküli hibakeresésre.
Az oktathatóság szempontjából különösen nagy jelentőséggel bír a súgók léte, milyensége. Nagy nehézséget jelent, ha a súgás kimerül egy internetcímre való utalásban. (Pl. így volt a FreePascal, és a Lazarus „piacrakerülés” korai szakaszában.)
A menűvezérelt kívánja meg a legtöbb „humán beruházást”: hosszas keresést, rossz esetben nyelvi nehézségeket okoz (idegen nyelvű, félig lefordított, érthetetlenül fordított szövegekkel) → garantált kudarcélmény.
Speciális billentyű vezérelt menük sokszor rendelkeznek a helyzetérzékenységgel, azaz olajozzák a problémamegoldást.
Nagyra becsülendő az a keretrendszer, amely rendelkezik automatikus szintaxist mutató buborékokkal (hint).
Olyan-e a nyelv, mint amilyennek képzelem?
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ésen túl más is, ami alapján megismerhető a nyelv? (Szabványok, dokumentáció... )
2005. év aktualitása volt az ELTE IK-n: a FreePascal–Lazarus bevezetése; ennek tapasztalatai:
komoly kockázatai vannak egy kiforratlan szoftver (pl. fordítóprogram, fejlesztői környezet…) bevezetésének;
még abban az esetben is, amikor egy jól ismert „ős” (jelen esetben a Pscal, a Delphi) leszármazottjaként jön világra az új szoftver, kidolgozatlan súgó nélkül bevezetni az oktatásba;
nagy többlet terhet jelent a bevezető tanárnak (mindent előre, akkurátusan ki kell próbálni, és ki kell dolgozni kerülő utakat a fellelt hibákhoz, hiányosságokhoz, nem is beszélve a diákság számára készítendő segédanyagokról, keretprogramokról). Hogy csak egyetlen példát említsünk, a TP-FP áttérés nehézségeit: 1-ről 2-ablakúság, a grafikus képernyő (=ablak) felbontásának (operációs rendszertől függő) megnövekedése.
Egyedi –bár csudajó– nyelv –korlátozott, azaz egy iskolabeli– oktatásba való bevezetése nem praktikus. Ennek köszönhető pl. a COMAL elhalása. Két nem oktatási példa: Algol nem terjedt el igazán a programozási gyakorlatban, pedig ő az őse a Pascalnak, Adának is, míg a FORTRAN / BASIC igen, pedig...! Az ok kézenfekvő: olyan alapvető rész maradt kidolgozatlan a nyelvben, mint az I/O. Persze a cél egy publikációs nyelv definiálása volt. Hasonló sorsra jutott az APL (=„A Programming Language”) is, amely speciális jeleit bebillentyűzni sem lehet akármilyen környezetben (különleges billentyűzetet igényel), jól lehet erejét sokan dicsérik (lásd az IBM 360 számítógép leírása).
Az elterjedtség klasszikus rossz példája: a BASIC. A személyi számítógép korszak hajnalán ahány gép, annyi BASIC-nyelvjárás született, a számos szabványosítási kísérletek ellenére.
Érdekes a Pascal nyelv esetére gondolni. A Borlandék Turbo Pascalja a 1990-es évek elejéig nagy népszerűségnek örvendett. A Borland ódivatúnak minősítvén leállt a fejlesztésről, a keletkezett Pascal-űrt lassan a Free Pascal töltötte be. A Free Pascal sikere alighanem a nyílt forráskódúságnak köszönhető. Megjegyzem: a szárnybontogatás idején igen nagy kockázattal és sok nehézséggel járt a használata.
Egy nyelv körül kialakult webes fejlesztői közönség meghatározó lehet egy nyelv jövője szempontjából. (L. Python.)
A böngészőben futó nyelvek (szkript nyelvek) is könnyen terjedhetnek, hiszen „kéznél” van a futtató környezet; igaz, a fejlesztői környezet hiánya visszavesz a terjedés lendületéből.
A nyelv birtokba vételének ára... „Anyám, nem ilyen lovat akartam” 1.
Jó-e, ill. mennyire jó, ha a programszerkesztő kifejezetten a nyelv vagy egy (módszertani, oktatási ...) cél „logikáját” követi, erőlteti? Nem biztos. Lásd LCN Logo, ELAN. Miért mondható sikeresnek a „Turbo-szerkesztő”? (Elterjedt, a legfontosabb szövegszerkesztési és néhány speciális programszerkesztési funkciót megvalósít.) De az sem célszerű, ha a programszerkesztő bántóan igénytelen, amilyen pl. a Logo WRITER-é. Számos fejlesztői környezet (sőt fordítótól független programszerkesztő) képes „szép” programstruktúrák automatikus létrehozására, a bebillentyűzés támogatásra, ill. kulcs-szavak (sőt esetleg más lexikális elemek) kiemelésére. Alkalmasint a lexikális elem első néhány jele alapján felkínálja az odailleszthető lexikális elemeket; elárulja pl. egy eljárás paramétereinek típusát stb.
Mi tehát a baj az LCN Logo „konzekvens” programszerkesztőjével? Szokatlan a funkcionalitást tükröző hierarchikus programstruktúra, pláne ahogy kényszeríti a bevitelt... És az ELAN programszerkesztőjével? Fókusz-fogalom nehezen áttekinthetővé teszi a program egészét.
A milyenség más szempontból is érdekes: illeszkedik-e ahhoz a paradigmához, amelyet programozás szempontból megvalósítani igyekszik. Pl. a Turbo Pascal az objektum fogalmat teljesen alkalmatlan módon támogatja: minden kapcsolódó fogalmat (pl. metódus, property, „objektumhierarchia”…) kulcs-szószinten kell ismerni, semmi segítséget nem nyújt az ismerkedő számára. Ablakközéppontú programozáshoz elengedhetetlen a GUI-s, eszközpalettás, … fejlesztői környezet (4GL).
A Geany nem kínál nyomkövetési szolgáltatásokat, a Code::Blocks kínál, de hektikusan, NetBeans GUI és a Turbo UI példásan jár a programozó kedvében.
A nyomkövetés hiányára némi gyógyírt jelenthet a feltételes fordítás.
Több-ablakos megjelenítésű nyomkövetési rendszer hasznos (a párhuzamos, sok oldalról történő szemlélhetőség miatt): algoritmusok (tételek), paraméterezés, lokális-globális adatok lényegének megértetésénél, rekurziónál stb.
A fordítási opciók mikre vonatkozhatnak? Beállíthatók-e: memóriamodell, processzor, nyelvi változat (pl. Turbo Pascal, Free Pascal, Delphi dialektus; Pascal C-szerű elemekkel; típus-szigorúság stb.)?
Biztonságos vagy hatékony kód generálása közötti választást „lokálisan” (egy-egy kóddarabra fókuszálva) fölkínálja-e (opciók)? Automatikus és „kézi” hibafelderítő mechanizmusok (indextúllépés, típussértés) legyenek beépíthetők, ill. kikapcsolhatók. (V.ö.: Turbo/Free Pascal, Code::Blocks környezet fordítási opciókat és feltételes fordítási lehetőségeket.) Ez által ötvözhető a fejlesztői környezet programkészítést támogató funkciók és a végrehajtás hatékonysága (gyorsaság, kódtömörség).
Moduláris programozási lehetőségek oktatási szempontból is praktikusak: hisz elrejthetők a preparált célmodulok, amikkel a tanulás hatékonyabbá, élvezhetőbbé tehető (grafikai „primitívek”, fájl-, menü-kezelési stb. modulok, vagy gondoljunk a backtrack tanításánál egy sakkfigura-rajzoló „háttérmodul” mit jelenthet). Egy 4GL-környezet szinte kínálja ezt a modulokra épülő, „keretprogramos” oktatási stratégiát, amelyben az alkalmazói felületet kezelő modult készen adhatjuk a tanulóknak, s nekik „csak” a lényeget jelentő modul elkészítése a feladat.
Többplatformúság előnyös lehet, hiszen támogatja az esetleges operációs rendszer-változtatást. De figyelem! A végrehajtásnak szemantikusan ekvivalensnek kell lennie. (Sajnos messze nem igaz ez –ma még– a böngészőben futó programokra. Pl. JavaScript.)
A feltételes fordítás lehetősége némi esélyt adhat a készítendő program többplatformuságának megőrzésére.
A nyelv megtartásának ára... „Anyám, nem (is) ilyen lovat akartam” 2.
Azt teszi-e a lefordított, interpretált program, ami várható tőle, nincsenek –egy nem vájt fülű számára– megmagyarázhatatlan „effektusok”. Ilyen effektusok forrása igen sokrétű lehet. Van, amelyek nyelvi jellegűek, de számos a megvalósítással (akár a fordítóprogrammal, akár a fejlesztői környezettel) függ össze.
Egy nyelvvel összefüggő példa: a kezdőértékekkel kapcsolatos.A deklarációban (a változó létrejöttekor) kap-e a változó valamilyen definiált kezdőértéket vagy sem (véletlen állapot anomáliái). Az interpretált nyelvek esetében gyakorta a változók egy jóldefiniált „undef” kezdőértékkel jönnek létre, ami lehetővé teszi legalább a futás közbeni észlelést és esetleges hibajelzést. (Sőt a Perl által generált kód is ilyen!)
A fejlesztői környezet „szigora” összefügg a nyelvvel magával (pl. típusosság), de a filozófiával is (fordít vagy értelmez), sőt a konkrét megvalósítás minőségével is. Pl. a weben egy publikus JavaScript mintaprogramban találtam teljeséggel fölösleges és szintaktikusan hibás sort is, amellyel (és amely nélkül is) helyesen fut a program.
Fordítási stabilitás alatt azt értem, hogy a fordítás sikeressége nem függ a fordító verzió-számától. Rossz példa a Code::Blocks, amelynél tapasztalható, hogy a rendszerkönyvtár fájljainak tartalma változik (cserélődik), így egy korábban szintaktikusan helyes programot az újabb fordító hibásnak jelez. (Az ok prózai: bizonyos nyelvi elemek egy olyan header-állományba kerültek, amely korábban nem volt inklúdálandó.)
Végrehajtási stabilitást is a biztonságossághoz sorolom. Ez alatt azt értem, hogy a választható végrehajtó környezet milyenségétől függetlenül azonosan fut-e a készített program. Ebből a szempontból kritikusak a szkript nyelvek. (Az előbb említett JS-es példaporgram másként működik Explorerben, mint FireFox böngészőben!) Sajnos nem csak a szkript nyelvek szolgálnak „jó” példával. Ui. a Free Pascal (v1.0.10) végtelen ciklusba esik textfájl-beolvasás közben, ha az utolsó sor végén nincs sorvégjel, míg a Turbo Pascal helyesen lefut.
Mindenki fogja használni, tehát ilyenek ismerete az általános műveltség része. Az alapfogalmak és az „alapfogások” megismertetése a cél.
Valószínűleg nem pont a tanult rendszert fogja később alkalmazni, ezért fontos, hogy magát a „kategóriát” is megismerje: funkciók, típusfeladatok és megoldási lépések…
Munkakörök egy része (titkárnő, adminisztratív munkakörök stb.) profibb alkalmazói ismereteket igényel, ezért az ilyen helyre orientálódóknak fontos ebben tökéletesedni. (Lásd ECDL-, OKJ-s vizsga.)
Hierarchikus menürendszer, fontos az arányos és logikus csoportosítás. Rossz példaként említhető a WinWord 2.0 esetén a ’Fattyú/Özvegy sorok’ a ’Nyomtató’ opcióba helyezése, a WinWord 6.0 esetén a ’Fájl’ menübeli ’Oldalbeállítás…’-ba. Később került a mai ’Formátum/ Bekezdés/Szövegbeosztás’ menüsorral kiválasztható paraméterablakba. Nagyon kétséges az Office 2007 „felhasználó kezéhez simuló”, szokatlan és –rutinos és beavatatlan használok számára egyaránt– konfúzus menürendszer.
Ikonikus eszköz-sor (ami „analfabétáknak” különleges előnyt jelent :-) ), jó, ha van, de a túlzásba vitele ellentétes hatású. Itt is ügyelni kell az ikonok kifejező (és megfelelő méretű) voltára. Jó példa: WinWord 97 „összeválogathatóság” szolgáltatása („Testreszabás”, l. módszertani szempontból lényeges más vonatkozását is: 2.4.1.). Az ikonok méretnövelhetősége gyengénlátók iskolájában való alkalmazhatóság feltétele.
Van-e egyáltalán beépített súgó, ha van, használhatók-e szövegezésüket és terjedelmüket tekintve. Ha a szakszavakat előzetes magyarázat nélkül használja, a kezdőknek nem segítség. Ugyancsak hasznavehetetlen a rosszul, magyartalanul („félmagyarul”) megfogalmazott súgó. Probléma, ha csak idegen nyelven hozzáférhető. (A többnyelvűségnek van kihasználható oktatási jelentősége!) Szerencsés, ha jellegzetes példákat is tartalmaz. Jó példa az Excel-beli függvények némelyikéhez tartozó súgórész.
Helyzetérzékeny módon legyenek a segítő információk megjeleníthetők! Hasznos az automatikus ikon-magyarázó buborék: a „hint”.
„Hasonlóság” más szoftver-felületekhez. Uniformitás – pl. billentyű konvenciók (F1 = Help …), hasonló elhelyezkedésű és jelentésű menük stb. (Lásd Win98 és utódai – Explorer GUI „általánossá válása” pl. az Intéző esetén.) A szakma által elfogadott, egységes terminológia-, fogalomhasználat. Különösen megnehezítené az egyedi szókincs egy más, hasonló célú szoftverre való áttérést. (Gondoljunk olyan alkalmazásokra, amelyek a hétköznapi szókincsen túl, speciális fogalmakat, elnevezéseket is használnak, ilyenek pl. a grafikus vagy a prezentációkészítő szoftverek.)
Az uniformítás nem tisztelete sok bosszúság forrása lett pl. az Office 2007 GUI megreformálásakor. Ezen még „interaktív segítség” (a http://www.rufusz.hu/hirek/interaktiv-segitseg-az-office-2003-rol-2007-re-valo-attereshez címen elérhető webes, online súgó) sem tud hatékonyan segíteni, amely „megmutatja” az egykori menüpont új feltalálási helyét.
Egér és klaviatúra funkcionalitás tekintetében egyenértékű használhatósága.
„Előreláthatóság”, következetesség: kitalálható egy-egy funkció léte, működése (és szintaxisa) az addig megismert rokon funkciók alapján. Pl. az Excel 2003-ban DARABTELI függvényének paraméterezése eltér attól, amit várnánk az elemibb SZUM, ÁTLAG, MIN, DARAB stb. alapján. Érthetetlen módon rossz (bár nem szintaktikusan hibás!) a ’=DARABTELI($B$2:$E$2;"=A1")’ függvényalkalmazás, míg helyes a ’=DARABTELI($B$2:$E$2;A1)’ és az általánosításra is alkalmas következő alak: ’=DARABTELI($B$2:$E$2; "="&A1)’.
A WYSIWIG-ség alapkövetelmény az általános használatban, de különösen az oktatásban. Egykori rossz példa: az egykori TEX dokumentumszerkesztő igen átgondolt lehetőségei (matematikus akkurátusság tükröződik benne) és igénytelen „maj'meglátod'a'nyomtatáSután” ígéretű külső. (Már vannak WYSIWYG jellegű szerkesztők is.)
Vizuális lehetőségek mind teljesebb beépítése. Pl. egy szövegbe grafika beilleszthetősége, egy táblázatba változatos, kifejező hisztogramok generálhatósága, egy prezentációba a vetítés menetének animációs lehetőségekkel segítése, dinamizálása.
Jól „modellezze” azt az alkalmazói programcsaládot, amelynek tagja. Ez vonatkozik a szoftver „filozófiájára”, a funkciókra és fogalmakra egyaránt. L. 3. fejezetet.
Különösen fontos, hogy az oktatás adott fázisában a pillanatnyi célhoz, célközönséghez „idomítani” lehessen. A hétköznapi alkalmazásban sem nélkülözhető a tágabb (szoftver-, probléma-, és igény-) környezet figyelembe vétele, az ahhoz való igazíthatóság képessége.
A menük, a súgók magyar(osítható)sága az oktatásban elemi elvárás.
A menük szűkíthetősége, átcsoportosíthatósága előnyös lehet különösen a tanulás kezdeti stádiumába. (Lásd Quattro Pro, Word 97 újítása: „Testreszabás” - eszközsorok, menük, más beállítások [pl. nagy gombok].) Figyelem, ennek is lehetnek veszélyei! Előbb-utóbb át kell térni a „szabványos” környezetre.
Más szoftverekkel is legyen „beszélő viszonyban”: adatcsere, adatkonverzió. Adatcsere –pl. lásd Windows-os alkalmazások többségét: Write/Jegyzettömb-Excel-Word-Paint-...–, amelyben a vágólapon keresztül történhet az objektumok beillesztése, csatolása …. Adatkonverzió alatt értem a különféle fajtájú, „rendszerbe illő” dokumentumok exportálhatóságát-importálhatóságát. Pl. egy szövegszerkesztő tudjon beolvasni és kiírni a saját formátumán túl rtf, pdf, html, xml alakban is, vagy egy táblázatkezelő tudjon csv, tab-bal elválasztott „szövegmezőkből” álló táblázat, xml-ben definált struktúra beolvasására, kiírására; vagy egy adatbázis-kezelő számára elfogadható input legyen bármely standard relációs adatbázis, de akár xml-struktúra is…
„Taníthatóság”, azaz makrózás v. –magasabb szinten– „cél-programozás” lehetősége. De bármilyen programozási képesség előnyös lehet (pl. adatbázis-kezelők esetében SQL-irány, vagy más esetben a Visual Basic). A programozhatóság különösen érdekes, ha valamely, önmagában is érdekes nyelv irányába mutat: pl. ORACLE-beli eljárások Java-ban is megfogalmazhatók.
Megjegyzések:
1. motiváció – a saját munka egyszerűsítése,
2. éppenséggel előnyösen használható algoritmizálás bevezetésére, gyakorlására.
Lényege: automatikus javítás (vö. helyesírás-javítás, rövidítések kifejtése), vagy a „gondolatok kitalálása”. (Pl. Excel – a szöveg kezdetéből megpróbálja kitalálni a folytatást, Word – dátum elejéből a mait.)
Azonban ne felejtsük el ennek árnyoldalait sem! Hogy a leggyakoribb bosszantó automatizmust említsem: egy számozott felsorolás száma után kérés nélküli, szándék ellenére történő nagy-kezdőbetűre átváltás. Ennek a jó esetben egyszerűsítő szolgáltatásnak akkor van rugalmasságot növelő szerepe, ha a használónak is van módja a rendszer intelligenciáját bővíteni (pl. Excel egyéni listáinak definiálhatósága).
Visszavonhatóság –esetleg– több lépcsős lehetősége (UNDO). Jó példák az Office 97-beliek (meg a „leszármazottak”). Egyszerűbb szövegszerkesztők esetén (pl. Jegyzettömb) csak visszavonás és a visszavonás visszavonására van mód.
Automatikus, „több-változatos”, beállítható sűrűségű mentés (BACKUP). Ehhez persze jó, ha az operációs rendszer is támogatást nyújt pl. a fájlnév-szerkezettel („vezeték-” és „keresztnév”, azaz kiterjesztés, sőt verziószám). (Lásd VMS verziószámos, ill. a UNIX puritán, kiterjesztés nélküli fájlnevek világát is!)
Olyan esetben, amikor végérvényesen rongálódhat, megsemmisülhet adat, rá kell kérdezni, hogy „valóban így akarja-e”. A biztonságnövelés célját már nem szolgálja a „túl gyakori kérdezősködés” (sokkal inkább az idegbajét).
Betöltéskor „bizonytalan” (=nem saját formátumú) forrás esetén elvárható, hogy megerősítést, még jobb esetben, a választáshoz döntést kérjen a felhasználótól a forrás miben létéről, ahogy teszi pl. a Word és az Excel „idegennek” vélt szövegfájlok beolvasása közben.
Valóban WYSIWYG, mennyire az? Kitartó rossz példa a MS Word 2007 (!), amelyben töréspontok („folyamatos”, „következő oldal” stb.) elhelyezése esetén gyakorta fordul elő az, hogy a képernyőn az anyag a beállításnak megfelelően, helyesen folytatódik a töréspont után, de a nyomtatott anyagban ettől eltérően (s persze rosszul).
Egy kis szójáték: What You Get Is What You Think/Want. Gondolhatunk a korábbi Word-ök frame-ful (azaz „keretbő”) dokumentumainak szerkeszthetetlenségére.
Nem száll el semmilyen körülmények közt. Ellenpélda: a Word korábbi változatai „keretbő” dokumentumok esetén, vagy a Word 2000 többfájlos dokumentum ígérete: „izmosabb” fő- és aldokumentumok esetén. A Word-ök erre való hajlamának hivatalos elismerését jelenti az a funkció, amely ilyen események bekövetkezése utáni újrainduláskor (ami esetleg rögvest automatikusan is bekövetkezi) a baloldali panelon a (meg)sérült fájlokat felsorolja.
Kifejezett előnyt jelent, ha egy valamely platformon tanult szoftvernek más platformon is létezik változata. Pl. az OpenOffice.org/LibreOffice Windows és Linux mellett Solaris-on, Mac-en is fut, míg az egyébként elgondolkodtatóan drága –alighanem a kihasználható képességeihez viszonyítva is túl drága– (Adobe) PhotoShop vagy (Corel) PaintShop Pro csak Windows környezetben fut.
Az (alulról) kompatibilitás szempont nem csak az oktatás szempontjából fontos. Bár természetesen komolyan nehezítheti a tanár dolgát, ha egy korábbi változatban készített dokumentumot az aktuális verziójú szoftver nem vagy rosszul tölti be. Vö. uniformitással (2.1.4.).
Másik probléma: „extrémebb” jelek megváltozása, kiesése verzióváltáskor vagy formátumcsere alkalmával (pl. ékezetes betűk elromlása a ZurichCalligraphic betűtípus esetében, vagy doc → pdf/html áttéréskor a felsorolás jelek megváltozása) stb.
Hardverkörnyezettől (nyomtató, monitor...) legyen független, esetleg kis, paraméterátállítás árán!
Néhány negatív példa: a Word-ben (bár nem csak az ő esetében!) más nyomtató választásakor megváltozhat a szövegtördelés, sőt a szöveg egy-egy része... (Lehet, hogy még hiányzó szabványok vagy létező szabványok be nem tartása áll a probléma mögött.)
Az oktatás szempontjából alapvető elvárás, hogy a menük és súgók a diákok nyelvén „szóljanak”. Érdemes elgondolkodni persze a „többnyelvűség” egyéb célú kihasználhatóságán. Az OpenOffice.org e szempontból is kiváló, hiszen 2008 tájékán 20 nyelven érhető el. (A LibreOffice 2012 tavaszán még „csak” 5 nyelvű. [libreoffice.hu])
Legfontosabb fogalmak:
·
adattípusok (numerikus, szöveges, dátum stb.),·
altáblák mint műveletek „alanyai” (operandusai),·
képletek (alap aritmetika, statisztikai függvények, „programozási tételesek” [sum, max, lookup,...] stb.),·
szerkesztési funkciók,·
adatbázis-funkciók:*
keresés kulcs-szerint,*
rendezés kulcs-szerint,Megjegyzés: fölhasználhatók az adatbázis-kezelők bevezetéséhez...
·
grafikonok, grafikai attribútumok (fajták; kellékek: cím, címkék, tengelyszövegek és -léptékek stb.),·
nyomtatás (fej és oldallécek, altáblázatok stb.).Legfontosabb fogalmak:
·
szövegegységek (jel, sor, paragrafus, lap; és attribútumaik stb.),·
szerkesztési funkciók,·
nyelvi szolgáltatások (elválasztás, helyesírás-ellenőrzés, szinonima-, rövidítés-szótár stb.),·
grafikák beilleszthetősége és viszonya a szöveggel (elhelyezés, távolság, körülfuttatás stb.),·
nyomtatás („megtekintés”=PREVIEW stb.),·
haladóbb szövegegységek (szekció, hasáb, rajzos „objektumok” mint pl. képletek, táblázatok stb.), útban a DTP felé,·
haladó „könyvszerkesztési funkciók” (automatikus tartalomjegyzék, tárgymutató-készítés stb.),·
„interaktív”/multimédia szövegegységek (hipertext-lánc, különféle médiájú „objektumok” stb.), útban a multimédia-, a weblapszerkesztés felé.Legfontosabb fogalmak:
·
adattípusok (numerikus, szöveges, dátum, esetleg „makroszkopikus” objektumok stb.),·
adatbázis objektumok (táblák, űrlapok, jelentések),·
táblakapcsolatok (1-1, 1-sok, sok-sok),·
szerkesztési funkciók,·
„kuriózumok”: képletek (mezőkben), grafikonok,·
nyomtatás (összegfokozatos lista stb.).Legfontosabb fogalmak:
·
a priori objektumok (pont, szakasz, törtvonal, hajlított ív, keret, doboz, ellipszisív, -lap),·
rajzeszközök (ecset, ceruza, kitöltő eszköz, szórópisztoly, szöveg) és attribútumaik,·
objektum-műveletek (mozgatás, színezés, forgatás, nyújtás, mintázás),·
képméretezés, felbontás-megadás, színmélység-módosítás,·
kép-import (fájlfajták, esetleg scanner), -export,·
haladóbb grafikai műveletek (előre-, hátratolás, 2 alakzat „fokozatos közelítése”, „effektusok”, színmodellek),·
funkciók a 3D felé, az animáció felé,·
nyomtatás (különféle minoségben és méretben).Ugyanez a dokumentum pdf formátumban.
Egy kitöltött értékelési táblázat („Informatika oktatása” tárgy)
http://people.inf.elte.hu/szlavi/InfoOkt/SzoftErt02.xls
(
)
És egy kitöltetlen értékelési táblázat („Informatika oktatása” tárgy)
http://people.inf.elte.hu/szlavi/InfoOkt/SzoftErt.xls
(
)