Tényleg nem jó, ha BASIC-et tanulok?

A strukturáltságot pedig sokan félremagyarázzák, tulajdonképpen tudatlanságból. Elmesélem, az utókor okulására.

Arról van szó, hogy a programnak úgy kell készülnie, hogy a forráskód viszonylag könnyen áttekinthető legyen, különben nagyon zűrös megoldások születnek benne, amikben nehéz a hibákat megkeresni, más ember pedig vért izzad, mire megérti a gondolatmenetet. Ennek érdekében a jó program egymást követő, logikailag viszonylag kis blokkokból épül fel, ezért a program menete áttekinthetőbb. A strukturáltság követelményeinek megfogalmazói három szerkezeti típust tartanak elfogadhatónak: ez a szekvencia, az elágazás és a ciklus. A programoknak erre a mintára kell épülniük, és ezek egymásba ágyazottan is használhatók. A szekvencia nem más, mint hogy két vagy több programelem egymást követi, szerkezetileg és logikailag is. Az elágazás egy feltétel teljesülésének megvizsgálása után vagy egy megadott ponton folytatja a program végrehajtását, vagy egy másik megadott ponton. A ciklus pedig az, amikor egy bizonyos feltétel teljesüléséig egy adott programszakasz ismétlődően, többször hajtódik végre.

A vitát az okozza, hogy az elágazásnak és a ciklusnak az adott programnyelvben megvan-e a minden cifrázás nélküli, elemi szintű megvalósítása. A nagyon régi Basic nyelvekben ezek hiányoztak, kerülő úton kellett megoldani. De én már jó húsz évvel ezelőtt is használtam a Microsoft QuickBasicjét (v4.5), amely már teljesen megfelelt az igénynek. Vagyis ha elágazásra volt szükség, akkor az a Basic forráskódban valahogy így nézett ki: IF feltétel THEN egyik műveletsor ELSE másik műveletsor END IF. Gondolom, ez teljesen világos, a feltétel és a műveletsorok megfogalmazása már ebből a szempontból részletkérdés. A ciklus pedig valahogy így írandó: WHILE feltétel DO műveletsor LOOP.

Apróságokban különböznek a megoldások, van még több variáció is, de valójában a "komoly" programnyelvek is pont ugyanezt tartalmazzák, csak más szavakkal vagy jelekkel. Hiszen ha azt írom le, hogy "if (feltétel){ egyik műveletsor } else { másik műveletsor }", akkor nincs semmi különbség, csak ez C++, ami komoly nyelv.

Hogy akkor honnan jön az ellenszenv a Basic iránt? Élt egyszer egy hülye holland, Edsger W. Dijkstra, aki még akkoriban kezdett programokat írni, amikor még fizikus volt - az 50-es évek végén -, és a programozó, mint foglalkozás nem létezett. Ő aztán az egyike volt azoknak, akik ezt a foglalkozást maguknak feltalálták, és érthetően úttörő hősöknek érezték magukat. Akkoriban az ALGOL 60 volt az igazán menő nyelv, sok ma is ismert elemet tartalmazott, lényegében ma is teljesen működőképes lenne, néhány kis kiegészítéssel.

1968 táján, elsősorban Amerikában megjelent a "szoftverkrízis". Dijkstra úr is megírta, hogy mi a baj: a számítógépek kapacitása, a lehetőségeik olyan nagyra nőttek, hogy a régi kőbalta-módszerrel már nem tudtak áttekinthető programokat összetákolni, eluralkodott a programíró eszközök között a káosz, egyre rosszabb programokat írtak a nagymenők is. Erre megoldásként néhányan különféle tanulmányaikban végül is megfogalmazták, ami a strukturált programozásnak a lényege, és általánosan követendő módszernek mutatták be, ami teljesen rendben is van.

Ekkoriban az USA valamelyik egyetemén a diákoknak elkezdtek programozást tanítani. Dijkstra úrnak ez baromira csípte a szemét, hiszen ő a pionírok között kezdte a szakmát, most meg már mindenféle akárkiknek oktatják a programírást, megszentségtelenítik az eddig csak a beavatottak, a számítógépek papjai között ismert tudományt. Tanulmányozta a problémát, és arra jutott, hogy a Főbűn, az Eredendő Rossz a nyelvekben levő GOTO utasításban testesül meg. Ez az utasítás arra való, hogy a számítógép a program végrehajtását egy másik, megadott ponton folytassa, ez az "ugrás". Ez történhet előrefelé és visszafelé is.

Ezzel még nem lenne baj, de az ugrás, sőt, a sok helyen sokféle ugrás megírható úgy is, hogy aztán már végképp nem lehet követni a dolog logikáját. Meg kell tanulni úgy bánni vele, hogy nem ugrálunk jó nagyokat akárhová, főleg nem ugrunk elágazás vagy ciklus belsejébe, ámde maga a nyelv és a forráskódból végrehajtható gépi kódú programot előállító fordítóprogram ennek semmilyen korlátot nem szab. Azt, hogy a programot ne szövevényesen írjuk meg, hanem a strukturáltság letisztázott elve szerint, külön meg kell tanulni. Dijkstra úr rosszul tűrte, hogy a tanulók még csak tanulnak, ebből következően sokat hibáznak, ezért írt egy tanulmányt egy szaklapban "a GO TO utasítás elleni perirat" címmel. Ehhez mások is csatlakoztak, például az a Niklaus Wirth, aki ezen felbuzdulva kitalálta a Pascal nyelvet, amiből jól kihagyta azt a nyavalyás GOTO utasítást, és ettől helyreállt a világbéke, mostantól csakis jó programok fognak születni.

Megjegyzendő, hogy a gépi kódban és az annak közvetlen megvalósítására használt assembly nyelvekben is van ugró utasítás, nélkülözhetetlen, mert az elágazásokat és a ciklusokat is azzal kell megoldani. Minden létező programnyelv végterméke egy gépi kódú változat, merthogy a processzor csak azt érti. Vagyis végső soron a "komoly" nyelvek struktúraelemei is ugrásokkal vannak megvalósítva.

Egyébként pedig van GOTO utasítás a C++, a C# és a Java nyelvekben is, többek között, legfeljebb ritkán használják. Csak ezt valahogy nem szokták emlegetni.

És hogy jön ide a Basic nyelvcsalád? Amikor az első Basic nyelveket kidolgozták - az első változat kitalálója a budapesti születésű John G. Kemeny és az amerikai Thomas E. Kurtz voltak -, különféle okokból úgy határoztak, hogy a program sorai önállóan kezelhetők legyenek, ne legyen közöttük olyan kötöttség, mint például a DO cikluskezdő utasítás és a valahol később kötelezően elhelyezendő LOOP cikluszáró utasítás. Ha ezek valamelyike elmarad, vagy a sorrendjük megfordul, akkor a program az első ellenőrzéskor elbukik, és már el sem indul. A Basic nyelveknek célja volt az, hogy a végrehajtás menjen el addig, ameddig tud, és ha valahol hiba üt be, akkor majd ott körül lehet nézni. Sőt, miután a hibát kijavítottuk, a program folytatható (!) legyen, az addig kiszámított adatok elvesztése nélkül. Az elv egyáltalán nem rossz, és gyorsítja a programfejlesztési munkát.

Viszont a programsorok terjedelme véges, például a lyukkártyák idejében legfeljebb 80 karakter lehetett. Emiatt egy hosszabb műveletsor nem írható le úgy, hogy beférjen egy IF utasítás THEN vagy ELSE ágába. Tehát kötött, többsoros blokkszerkezet ne legyen, de az utasítássor sem lehet hosszú, a megoldás: az ágakból ugrással lehessen elvégeztetni a kívánt műveletsort.

Mutatok egy példát. Vegyük valamelyik későbbi Basic nyelvet, ilyen tekintetben ezek elég egyformák. Szóval ellenőrizzük, hogy a V változó tartalma negatív vagy pozitív, és ennek megfelelően négyzetre emeljük és kiírjuk egy adatbázis K. rekordjába, vagy a gyökét vesszük és az S értékét megkétszerezzük, mindegy, hogy mi okunk van erre.

IF V>0 THEN

V = V * V

SEEK #2, K

PUT #2, V

PRINT "az új érték"; V

ELSE

V = SQR(V)

S = S * 2

END IF

(A beljebb kezdés NEM maga a strukturálás, mint ahogy azt még ma is hiszik páran, az csak egy segítség magunknak, hogy lássuk, mettől meddig.)

Nézzük meg ugyanezt egy régi Basicben. Ha megpróbáljuk egy sorba írni,

IF V>0 THEN V = V * V : SEEK #2, K : PUT #2, K : PRINT "az új érték"; V ELSE V = SQR(V) : S = S * 2

akkor látszik, hogy túl hosszú. Sőt, némelyik Basic nyelvváltozatban nem is volt ELSE utasításszó. Mutatom, hogy hogy csinálták volna:

1200 IF V>0 THEN GOTO 1240

1210 V = SQR(V)

1220 S = S * 2

1230 GOTO 1280

1240 V = V * V

1250 SEEK #2, K

1260 PUT #2, V

1270 PRINT "az új érték"; V

1280 folytatás...

A programsorok akkoriban mindig meg voltak számozva, így lehetett hivatkozni rájuk.

Biztos van, akinek ez átláthatatlan, de megszokás dolga. Ha akkor a nyelv ezt tette szükségessé, akkor ezt kellett használni. Valamit valamiért. Aki ezt nem tudja megtanulni szabályosan kezelni, az más nyelveken is rossz programokat írna, nem ettől függ a minőség. Egyébként ha assemblyben, a leghíresebb vérprofik izzasztó nyelvén írunk programot, akkor szerkezetileg pontosan ugyanígy építkezünk, vagyis az ugrás nem ördögtől való borzalom. Kényelmesebb és biztonságosabb is lehet az írásban kötelezően jelölendő blokkos szerkezet, ugrások nélkül, ez igaz, de egy program nem attól lesz jó. A programnyelv sem.

A GOTO itt egy nélkülözhetetlen eszköz, csak éppen lehet rosszul is használni. Pascalban is tudok ijesztő dolgot írni, nem ezen múlik.

Ami egy fontos tanulság: A MÁSODIK VÁLTOZAT IS STRUKTURÁLT. Ezt általában el szokták felejteni a haragos kollégák. Ugyanis ha lerajzolom az utasításmenetet, egy rövid, világos, "S" alakú alapszerkezetet kapok, amely az elágazás struktúraelemének tekinthető. A strukturált programozás elvében nincs előírva a nyelvi megvalósítás, abban csak egymásba tett dobozok szerepelnek. Ha az elágazást is, a ciklust is egy letisztult, két-két GOTO utasítást tartalmazó alapszerkezetként valósítom meg, és az ugrások hossza semmivel sem nagyobb a szükségesnél, akkor minden rendben van. Csak tévedésből sokan azt gondolják, hogy egy nyelv csak akkor strukturált, ha mindig írásban jelölve van a blokk eleje és a vége is.

De ha úgy van, ha csak akkor tekintek egy nyelvet strukturáltnak, ha megvan benne a strukturált programelemek utasításszintű megvalósítása, akkor? Akkor a Basic is strukturált nyelv, mert már mindegyik nyelvváltozatában ott van, amit a komolyak hiányolnak. Kábé harminc éve.

Ha már programozni tanulsz, hadd hívjam fel a figyelmet arra, hogy ez a példa HIBÁS, nem pontosan azt csinálja, amit a feladat eredetileg leírt. Ugyanis a harmadik eset szerint V értéke lehet nulla is, és a program ebben az esetben a negatív értékhez tartozó műveletsort végzi el, mert a V>0 feltétel nem teljesül. Szóval akkor javítsuk ki:

...

PRINT "az új érték"; V

ELSEIF V<0 THEN

V = SQR(V)

S = S * 2

END IF

És akkor a 0 esetre nincs előírva tennivaló.

A strukturáltsághoz tartozik az is, hogy a nyelv használni tudjon elkülönült eljárásokat (SUB ... END SUB és effélék), a régi szubrutinok rugalmasabb változatait, paraméterátadással, lokális változókezeléssel, de a Basic nyelvek már ezt is réges-régóta tudják, csak legfeljebb a "komoly" programozóknak elfelejtettek szólni róla.

Hát ennyi.

Ja igen, és a híres objektumorientáltság. Na, az is elég kétélű fegyver. Van, amikor hasznos és kényelmes, és van, amikor csak komplikálja a helyzetet. Például ha egy programban egy ablakban van három külön szövegsor, és én, a program írója, úgy döntök, hogy a beléjük írt tartalmat egy egyszerű tömbben tárolom, a neve legyen T, akkor a 2. tartalmát így tudom kiírni a képernyőre: PRINT T$(2).

Már persze ha nem vagyok objektumilag orientálva. Mert akkor nevet kell adnom az ablaknak és a szövegsoroknak is, mindegyik egy-egy objektum, a három szövegsor az ablak-objektum egy-egy alárendelt tagja. A kiírás is csak a képernyő egy megnevezendő ablakán végzett 'metódus' vagy 'függvény' alakjában kérhető, egy egyszerű utasítás helyett, és akkor ez jön ki, mondjuk: Debug.Print fmInput.txLine(2).Text. Szerintem ez hülyeség, és én nem kérek az ilyen kényelmességből.

Az a baj, amikor erre az utóbbira vagyok kényszerítve, és nem magam választhatom ki, hogy nekem mi a kényelmesebb az adott esetben. Nagyszabású, sok adatcsoportot, adatbázisokat, képernyőelemeket kezelő programokban nagyon is megvan ennek a bonyolult megközelítésnek a maga értéke, főleg a dinamikusságában, a helyzethez igazodóságában. De programozás oktatására az objektumosdi egyszerűen kolonc, olyan többletvesződség, ami miatt a tanuló nem tud a fő feladatra figyelni. Életem legelső programjában, egy házi feladatban még én is elvesztem a részletekben, aztán a tanárom szólt, hogy ne a beviteli hibaellenőrzéssel tököljek, hanem először csináljam meg a lényeget, a számítást, a finomítás utána is ráér. Igaza volt. Hát akkor ne kelljen a tanulónak az osztályok példányosítását és a szabadon definiált adattípusokat emésztgetnie, hanem hadd legyen már az első élménye annyi, hogy INPUT A,B : PRINT A+B.

A Basicben az a jó, hogy az ilyen egyszerű. Akinek és amikor pedig kellenek a bonyolultabb elemek, egy jó Basicben már azok is ott vannak. De akkor már jöhet bármilyen "komoly" nyelv is, ha az kell.

Hát ez volt az én röpke megjegyzésem a dologról. :-D A lényeg az, hogy ne törődj az előítéletekkel, mert eleinte nem piacképes és felhasználóbarát szoftveralkalmazást kell fejleszteni, piszok korszerűen, hanem csak megírni egy működő, rövidke programot. Először az is elég munka.

Üdv az új pioníroknak.

1. Ez itt nem egy programozói, szakmai oldal, mint már az évek során kiderült

2. A Python és Java hívek néha rosszabbak - tisztelet a kivételnek - mint Jehova tanúi, bár még ők sem annyira erőszakosak

3. A konkrét, 'kézzel fogható' dolgokat sem fogadják el, ha nem az ő álláspontjukat tükrözik

4. Egy nyelv felületes, videókból tanult :), ismeretével azt hiszik ők a király

... és még sorolhatnám.

Lehet újra lepontozni, de előtte tessék mutatni valamit és megindokolni.

SimkoL:

"2. A Python és Java hívek néha rosszabbak - tisztelet a kivételnek - mint Jehova tanúi, bár még ők sem annyira erőszakosak

3. A konkrét, 'kézzel fogható' dolgokat sem fogadják el, ha nem az ő álláspontjukat tükrözik "

Vicces, hogy nem vagy hajlandó konkrét, kézzelfogható forrást felmutatni 2. állításodra, majd még te izélsz, amiért a Pythont kedvelők nem fogadják el. Szerintem azért illene egy ilyen esetben a forrást feltüntetni, mert másképp csak egy indoklatlan véleménynek tűnik.

És kérlek ne beszéljünk az állások menniységéről, mert akkor nagoyn sokat kell finomítani a keresésen, pl. A BASIC nyelvek közül melyik nyelveket vegyük be, Python fejlesztőnek minősül-s az, aki animációk gyártói mellé a mozgást Pythonnal oldja meg stb. Legyen egy másik vitatéma, köszönöm.

"Egy nyelv felületes, videókból tanult :), ismeretével azt hiszik ők a király "

Ez egy kényelmetlen általánosítás, ismét bizonyíték nélkül. Meg vagyok győződve, hogy ez nem a nyelvtől függ, hanem a személytől. Kiegészítő jellegű példa: Ha találkozol egy beképzelt rockerrel, és 5 perc múlva egy jóindulatú rapperrel, attól még maradnak a rockerek közt jófejek és a rapperek között beképzelt állatok.

"és még sorolhatnám. "

Kérlek, tedd meg a kedvemért.

"Lehet újra lepontozni, de előtte tessék mutatni valamit és megindokolni."

Nem érzed úgy, hogy bort iszol és vizet prédikálsz? Mert én igen, legalábbis jelen válaszod alapján.

"1. Ez itt nem egy programozói, szakmai oldal, mint már az évek során kiderült "

(A következő rész nem szarkasztikus letolás akar lenni, még ha a kommentem előző része után annak is tűnhet, mindössze ténymegállapítás)Szerintem az oldal neve azért GYAKORIkérdések, hogy kezdők, diákok vagy alkalmi programozók, és nem szakmabeliek is kérdezhessenek, elindulhassanak.

[link]

RFO basic, nézd meg. Egyre jobb. Én is ebben programozok.

Folyamatosan fejlesztik.

Fóruma is van. (nem magyar)