Köszönjük, Kemény János!
"A BASIC nemcsak informatikai, de pedagógiai bravúr is volt, ami hamar túl is nőtt a készítőin.
Azon túl, hogy a BASIC Kemény János miatt részben nemzeti büszkeségünk, óriási befolyással volt az informatikaoktatás fejlődésére – mondta a Telexnek Képes Gábor, a Neumann János Számítógép-tudományi Társaság (NJSZT) ügyvezetője. – A programnyelvnek számos nyelvjárása jelent meg a hetvenes–nyolcvanas években, és a BASIC etalonná vált, aminek az ismerete hozzátartozott a számítógép kezeléséhez. Sőt, tulajdonképpen a BASIC lett abban az időben az ember-gép kapcsolat alapja. Ezzel összefüggően elkezdődött az informatikaoktatás nagy korszaka, amikor a digitális írástudás terjesztése teljesen összefonódott a programozás és az algoritmikus gondolkodás tanításával.”
https://telex.hu/eszkombajn/2024/05/01/basic-60-kemeny-janos-programnye…
Hozzászólások
10 PRINT "HB!"
20 GOTO 10
RUN
trey @ gépház
Tegyél mellé egy ;-őt, hogy egymás mellé írja, ne egymás alá, úgy szebb! :)
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Gyerekként nagyon szerettem, egyszerű benne programozni. Ami miatt ma nem használnám, az az, hogy 1) nincs szabványosítva normálisan, amit követnének is, 2) a hozzá írt tokenizáló interpreterek meg fordítók nagyon szar hatásfokkal és teljesítménnyel futtatják a kódot, egy átlag C, C++ fordítóhoz képest a kanyarban sincsenek, de még csak egy modern scriptnyelvhez sincsenek sehol sebességben (Lua, Python, Perl). Pedig magában a nyelvben benne lenne a potenciál, még a szintaxisban is, mert csináltak hozzá OOP-s kiegészítéseket, csak mivel a kutya sem nagyon használja már, ezért normális, hatékony fordító nincs hozzá. Pedig van hozzá mindenféle, még FOSS licenccel is, FreeBasic, QB64, Gambas, PC-BASIC, SmallBASIC, miegymás, de mind nagyon fos sajnos.
Ami modern korban leginkább hasonlít egyszerűségben a BASIC-re, az egyébként a Lua, majdnem egy az egyben használható benne a BASIC szintaxis. Jó, a sorszámozás nem, meg a parancsok se írhatók nagybetűsítve, de a többi igen. Pl. a fenti kód is alig változik
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
A régi gépeken írt ill. futtatott programok sokkal jobb teljesítménnyel mentek volna ha basic helyett assembly-ben írják meg azokat? Akkor miért volt népszerű a basic, ha 30-40+ éve még sokkal gyengébbek voltak az akkori gépek, és assembly-ben megìrva is lassan futottak a programok, nemhogy a nagyságrenddel lassabb basic-ben?
> sokkal jobb teljesítménnyel mentek volna ha basic helyett assembly-ben írják meg azokat?
igen. C64-en biztosan, sajat tapasztalat.
> Akkor miért volt népszerű a basic
ahogy a neve mondja, mert egyszeru.
az ASM a regi gepeken eleg hardcore volt, keves (c64-en pl. 3db) regiszter, mindenfele limitaciokkal, csak primitiv utasitasok, ugy remlik meg szorozni se lehetett, csak osszeadas-kivonas volt. amugy a C64-es basic programokban gyakori volt a beagyazott asm resz, pl. DATA sorokkal, a sebessegkritikus reszekhez.
Na, mondjuk azt kicsit sajnalom hogy anno a ZX Spectrum koraban nem tanultam meg az(t az) assemblyt :) Persze "jobb keson mint megkesobb" alapokon azert az x86-nal bepotoltam.
bármelyik emberi agynál ezerszer gyorsabb egy szarul megírt BASIC program is && többen értik a BASICet mint az assemblyt
A programok nagy részét eleve ASM-ben írták a profi kiadók, és programozók. A BASIC inkább a home usernek, az amatőröknek volt ott, de abban is születtek jelentős szoftverek, és igen, azokat ha átírod, sokkal gyorsabban futnak ugyanazon a hardveren.
A BASIC azért volt népszerű, mert ahogy a neve is mutatja, 1) egyszerű megtanulni, 2) azt mellékelték a géphez, ha szeretted, ha nem, nem volt más. Főleg, míg új volt a gép, később jelentek meg fordítók más nyelvekhez.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Azt se felejtsük el, hogy az a basic interpreter el kellett férjen egy 4, esetleg 8kB-os ROM-ban.
Régóta vágyok én, az androidok mezonkincsére már!
C64-en általában úgy kezdték hogy legyalulták a búsba a basicet és mindent assemblyben írtak meg, gyakorlatilag minden helyet kihasználtak.
így születtek meg olyan finomságok mint a turbo, irq loader, digi zene, sprite multiplexer, fli, nufli, stb.
ebben a demóban kábé minden benne és szájtáti végig!:D
Next Level - Performers 2023 X Party győztese.
van egy rész amikor 100 játékból mutatnak részeket egymás után 1 lemez oldalra (170 kb) gyömöszölve...
Vagy, aki igazán cseles, az a basic rom-ból kölcsönöz dolgokat a demojához: Machine Yearning (4096-byte album) - a számok címeit érdemes megnézni :)
Régóta vágyok én, az androidok mezonkincsére már!
PC 64k intro scenerek tudnának mesélni!:D
revision 64k intro győztes: empires - conspiracy
csak 48k!:D
persze saját demotool-al dolgoznak, amikor verziót lépnek akkor az előzőt ingyenessé teszik.
Apex
A Süni magazinban voltak (sokszor igencsak) bugyuta BASIC programok, de akkor nagyon sokat lehetett tanulni belőlük.
Mondjuk amíg begépeltem őket, addig biztosan nem voltam vicces kedvemben.
Azt hiszem a "Villany Vili a szerelő" volt a legjobb :D mint látható, a címe beégett rendesen.
Ui: jah, meg a Basic-kártyát is forgattuk rendesen!
Vortex Rikers NC114-85EKLS
Emlékszem, középiskolás osztálytársammal valahogy mindig feladatot akartunk az eszközhöz. Írjunk programot! Eddig el is jutottunk:
10 CLS
Aztán persze semmi ötlet, mit is akarunk megírni. :) Az assembly-hez képest nyilvánvaló előnye, hogy egy hibás Basic programra vigyázott az interpreter, míg egy hibás assembly kód gépi kódra fordítva majd futtatva beleállt a földbe, és ugye nincs oprendszer, szóval reset, minden adat, kód elveszett. Ha volt róla mentés, az jó, ha nem az kellemetlen.
Amúgy nem szerettem, interpretált lassú szörny, különösképp egy majdnem 3.5 MHz-en járó Z80 CPU-n.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ezt anno én is csináltam így. Egyébként ma sem haszontalan tudás a BASIC, pl. Excelben, LibreOffice Calc-ban saját makrókat írni elég hasznos tud lenni, ha olyan területen mozog az ember fia. Tény viszont, hogy nem sok mindenre használják ezen kívül, az XP-ig még a MS használta VBS scriptekhez, de az is elavultatták, és bár tovább él egy FOSS klónja a Gambas, de ezt se nagyon használja semmi, csak a LinuxFx/Wubuntu.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Volt egy Beta Basic nevű a Spectrumra, ami ismert PROC ... ENDPROC parancsot, nem igényelt sorszámozást és lehetett benn eolyan programot írni, ami önmagát módosította.
https://worldofspectrum.net/pub/sinclair/games-info/b/BetaBasicV4.0.pdf
Aki BASIC-ban tanult programozni, az minden nyelvben tud basicban programozni...
https://www.esp8266.org/
Igen, van egy kicsit destruktív jellege, ha az ember először BASIC-ben, ASM-ben, vagy más lineáris, nem strukturált nyelven kezd el programozni, nagyon rászokik a goto-kra, meg a low level technikákra, és később meg azok a nyelvek fognak neki nagyon nehezen menni, amikben meg több az absztrakció, struktúra, OOP, miegymás, azzal fog vért hugyozni, mert a gondolkodása mindig vissza akar térni a BASIC-es gondolkodásmódhoz.
Dijkstra-nak van egy ezzel kapcsolatos híres mondása: “It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.”
Ennek ellenére azért el lehet engedni, aki akarja. Én is el tudtam, de csak nagy nehézségek árán. Ami nem megy a mai napig, azok a funkcionális nyelvek, pedig azokról is néztem egy csomó videót, kurzust, könyvet, értem is a lényegét, de az agyam nem áll rá arra a fajta programozási logikára, hogy minden függvény, nem lehet a változókat megváltoztatni kézzel, nincsenek hagyományos ciklusok (helyette rekurzióval meg egyebekkel kell trükközni). Valahogy olyan faramuci, hogy mindig lepattanok róla. Időről-időre nekifutok azért.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Abban a rövid időszakban, amikor tanultam is programozást, nem csak írtam programokat, akkor volt időszak, amikor a Jackson programtervezést próbálták belénk verni (végül is nem hiába, bár a modern fejlesztőkörnyezetekben messze nem annyira használható). Ha abban tervezed meg a programod (illetve csak az adott részt), akkor a GOTO nyugodtan felejthető. De persze az igazi progrmozó nem fél a GOTO-tól :)
Az asm vonatkozásában nem értek egyet az általad írottakkal. Ha megtanulsz egy assembly nyelvet, megérted, hogyan tárolódik az adat a memóriában, hogyan hajtódik végre a kód, megérted a pointer fogalmát, ha meg ugyanazt a memóriaterületet más-más célra használod, megérkezel a union fogalmához. Én éppen kötelezővé tenném az assembly tanulását.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Pontosan! Aki nem írt soha semmit ASM-ben, pláne ha még C-ben sem (persze ide érthető minden más nyelv is amiben van közvetlen memóriakezelés, de nem sorolom fel őket), annak nagyon nehéz elképzelnie, hogy mit csinál a számítógép, és többnyire nem tud optimalizálni.
Egyébként én is BASIC-ben kezdtem és tényleg nehéz BASIC után C-zni, de ezt a problémakört olyan 10 éves korom körül sikerült azért magam mögött hagyni, nem volt lehetetlen megugrani.
Sajnos ez igaz, bár "a BASIC-es gondolkodásmódot" tagadom, mert ahhoz ki kell operáltatni az agyamat. Az absztrakció az más. Azért utálom, mert annál a nyelvnél amely ilyennel rendelkezik, mindig társul hozzá egy side-effect halmaz. Az assembler azért jó, mert pontosan le tudod írni mi is történjen. Magasabb szinten pedig csak egy specifikációd van, mit hitt az alkotó, aki nem gondolt mindenre. No, ezzel specifikáltam a side-effect keletkezésének mechanizmusát. ;)
A goto utálatot nem tartom helyesnek. Utálják azok, akik nem tudják mit csinálnak vagy nem tudják hogyan múködik egy cpu! Az áttörés a "magas szintű nyelvek támogatására" kifejlesztett utasítások és a stack frame kezelésével kezdődött valahol a struktúrált programozás hajnalán. Az alap modell szerint a függvénybe érkezvén megvizsgálod, hogy végre kell-e hajtani. Ha nem, akkor goto (!) kijárat, mert a stack manipuláció miatt nem kehet csak úgy elhagyni a függvényt. És ezzel meg is szűntek pl. a return on condition típusú utasítások, amelyeket kiválóan támogatták a vezérlési algoritmusok írását. Ezért tagadják a tudósok még a goto létezését is, mert a nagy absztrahálás közepette fogalmad sincs, mikor fut alattad egy olyan struktúra, amiből nem lehet ugrani.
A mai OOP is csak egy absztrakcióhalmaz, amelyet mindenki tud meg ért. Pedig láttam már ilyet bipoláris processzoron futni, meg írtam is shell scriptben is, ami onnan nézve legfeljebb assembler logikával lefedhető. Vagyis semmi "magasszintű".
Azért picit pontosítsunk: a GOTO létezését azért tagadják, mert GOTO nélkül bizonyítani lehet egy program helyességét, GOTO-val meg nem.
Mit kellene egy program helyességén érteni? Szőke, nagydudájú és szép a mosolya? ;)
A valóságban csak egy önkényes és sokak által vitatott konvencióról van szó.
wut? Hogy lehet a goto nélküli program helyességét bizonyítani? Még a leállási probléma is eldönthetetlen. A helyességet meg nem tudjuk definiálni.
Valóban, a feladat definíciója a nehézkes, de azért létezik programozás-elémélet, és ha már definiáltunk egy feladatot, akkor bizonyítható, hogy az adott program azt a feladatot oldja-e meg.
Ezzel nekem az a bajom, hogy tulajdonképpen az implementáció, a program definiálja a feladatot. Ha ugyanis meg tudod fogalmazni pontosan, hogy mit szeretnél csinálni, akkor megírtad a programot. Ha meg nem tudod megfogalmazni, akkor nem tudsz teszt gerjesztő vektorokat és eredménymátrixot generálni sem.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Pontosabban az implementáció is egy definíció. De valóban, egy program pontos definiálása nem életszerű. Az esetek zömében - szerintem - nem is lehetséges. Ennek ellenére ez a megközelítés mégiscsak ad egy strukturált szemléletet, ami a valós programírás során mégiscsak hatékony.
Úgy tűnik, hogy kevesen jutottak el a gosub használatáig. :)
Az persze jó dolog, de már egy if feltételt sem tudsz BASIC-ben GOTO nélkül megcsinálni.
De, sokunk eljutott, csak az a baj, hogy az nem minden BASIC nyelvjárásban volt támogatva. Mint írtam, ez is baj volt a BASIC-kel, hogy egyik ezt támogatott, a másik amazt, és nem voltak az implementációk egymással teljesen kompatibilisek.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Eleve nem volt a mikroszámítógépek perifériakezelésében sem olyan közös nevező, ami értelmes alkalmazások hordozhatóságát lehetőve tette volna. Ha egyszer egyik géphez kazettás magnó van, a másikhoz floppi, a harmadikhoz semmi, a negyediknél meg esetleg lyukszalag, és az első kettő implementációjában is óriási különbségek vannak, akkor úgy nehéz BASIC-ben bármilyen produktivitást segítő programot úgy megírni, hogy hordozható legyen. Ehhez képest az MS-DOS vagy CP/M azzal, hogy fileokat kezel már óriás előrelépés. És akkor nem is szóltunk a gép egyéb perifériáinak kihasználásáról, hang, grafika, nyomtató, egyedi beviteli eszközök. Még a karakterkészlet se volt egységes, tehát kb bármi, ami a betűkön, számokon és általános szimbólumokon kívül van.
Ja, pont ez az. Pedig volt egy szigorúbb subset, amire ha figyeltél, akkor portolhatóbb volt a BASIC program, pl. bizonyos ilyen utasításokat nem használtál, mint WHILE/WEND, GOSUB, stb., meg értékadásnál mindig kitetted a LET parancsot, stb., akkor jobbak voltak az esélyeid, de még így se volt semmi garantálva, mert ahogy írod, egyik floppy-s, a másik magnós volt, már az se volt szabványos, ahogy a magnót kezelték, egyiknél LOAD/SAVE, a másiknál CLOAD/CSAVE, egyik implementáción volt grafika, meg rajzoló utasítások, hangadó-zenélő parancsok, a másikon nem, nyomtatóperifériára máshogy hivatkoztak, szórtak aszerint is, hogy milyen matekfüggvényeket ismert, hogyan hívatkoztál változótípusokra, egész, lebegőpontos, string, vagy épp egyes implementációknál egységesek voltak, típus nélküliek a változók. Karakterkészlet pláne szopás volt, főleg, ha grafikus-rajzoló karakterek kellettek, meg nem angol, ékezetes karakterek, nagyon függött, hogy melyik gépen milyen ROM van. Azért nem is kívánom vissza.
Ilyen Commodore-ok után nekem is megváltás volt az MS-DOS, mert az IBM PC kompatibilis BIOS-szal karöltve lehetett építeni rá, hogy a legtöbb gépen futni fog a kód. Akkoriban CP/M-et nem ismertem, az kimaradt, azt csak így utólag, retrospetív tanultam meg. A Unix ebben még előrébb járt, főleg miután POSIX-ként szabványosítva volt, meg a C is ANSI-ként, arra tudsz támaszkodni, hogy mit támogat, milyen unixos rendszerhívások vannak, libc, stb., ott nagyon figyeltek a portolhatóságra. Csak az akkoriban nem az átlag ember szintje volt, nem annak a pénztárcájához volt igazítva, aki nem ilyen kutatóintézetben, egyetemen, állami helyen, komoly cégnél dolgozott, nem fért hozzá ilyen komolyabb rendszerhez, maradt neki a BASIC-es home micro meg a PC-nek a DOS-os ökoszisztémája. Már az Amiga is olyan volt, hogy az átlag embernek nem volt itthon nagyon.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Arról nem is beszélve, hogy vagy ASCII-ben volt tárolva a forráskód, azaz a script, vagy tokenizálva, de ez utóbbi nem volt szabványosítva, egyedi megoldás volt.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ez a felhasználó oldalán transzparens volt. Mármint hogy bájtonként vagy tokenenként volt-e tárolva. Az előbbi több memóriát használt, az utóbbi kevesebbet, de cserében lassabban futott miatta az értelmező. Leginkább a tokenek mellett döntöttek, mert a memória drágább és a 16 bites címtér szűkösebb volt, mint a prociidő.
Az ASCII vs. saját karakterkészlet (pl. CBM karakterek) ott voltak inkább jelentősek, ha pl. egy rutin karakterkódként próbált valamit megjeleníteni, vagy input esetén értelmezni, mondjuk a 210-es karaktert akarta kiírni vagy lereagálni, de ez nem biztos, hogy az adott gépen, implementációban ténylegesen azonos alakzatot, billentyűt, stb. takart. Ha már ASCII volt egy rendszer, már az egy nagy haladásnak számított, mert azt legalább az ANSI szabványosította normálisan, de ez is csak a karakterkódolást egységesítette, a billentyűzetkezelést nem feltétlenül.
A vicc az, hogy a BASIC-et ugyanez az ANSI szintén szabványosította, csak épp nem követte senki, továbbra is minden implementáció saját szájíz, meg a célgép platformja alapján döntötte el, hogy mit támogat. Igaz cserében egyik értelmező és fordító sem állította magáról, hogy szabványos, nem is lett volna neki megengedve. A MS-féle BASIC, ami a mikrókon meg a PC-n (BASICA, GW-BASIC, stb.) elterjedt, azt kezelték kvázi gyakorlati szabványként, de ezt se követte minden platform, főleg, ha nem akarta a gyártó pénzért lincencelni a BASIC-et a MS-tól, de még ha licencelte is, nem volt teljesen kompatibilis, lásd Altair BASIC vs. Commodore BASIC. De már maga a MS sem kezelte a BASIC-et egységesen, volt egy kis eltérés a GW-BASIC, QBASIC, QuickBASIC között, később a Visual Basic is eltért némileg, illetve ezekhez közel állt a Turbo Basic is, de az sem volt 100%-ban kompatibilis, csak sok felhasználónak kellően közel volt. Ezt a MS BASIC vonalat követik a modern BASIC fordítók is, FreeBASIC, QB64.
Így meg teljesen vadnyugat volt, sose tudtál semmire támaszkodni, pl. az sem volt biztosra vehető, hogy az adott implementáció fog-e az adott gépen lebegőpontos utasításokat kezelni.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Ha nem figyelnék, simán rászedhetnél, de figyelek! :P
Írtam Z80 assemblert és szerkesztőt tokenizált tárolással. A fordító vagy interpreter nem lesz lassabb a tokenizálástól, sőt, gyorsabb lesz, mert a token lényegében a token implementációjának a táblázat indexe, vektorcíme. Ha sima ASCII a tárolás, akkor lesz még egy olyan feladat, hogy keresni kell, a forrásban leírt szót megtaláljuk-e a szótárban. Kimenetünk az, hogy ha igen, a szótár hanyadik eleme volt. Tokenizálásnál ez a lépés szerkesztési időben történik, nem fordításkor vagy interpretált futtatáskor.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ezt én a fortran nyelvvel ismerem.
számomra a sorrend a nem sruktúrált --> struktúrált (Turbo Pascal) --> Objektum Orientált (Java) volt. *
És ez egy teljesen egészséges és jól bejárható sorrend. Szerintem nem kihagyható az első lépés, de érdemes lerövidíteni, tehát mielőtt egynél több GOTO-t igénylő feladatot csinálna a tanuló, érdemes továbblépni a struktúráltra.
* A LOGO féle kerülőutat szerencsére kihagytam, tanultam róla, de már mint lehetséges oktatási programnyelvről, és akkor már régen sturktúráltan programoztam.
Az attól függ, hogy ki miben akar programozni. A low level, nem strukurált programozást pl. ismerni kell, ha low level, bare metal kódot írsz, pl. valami mikrokontrollerre, vagy OS kernelt vagy drivert írsz, akkor valóban megkerülhetetlen. Aki csak normi, soydev, meg webes, üzleti, GUI szoftvert, vagy szkripeket ír, annak nem feltétlenül, annak tényleg jobb, ha min. OOP-vel kezd.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Bla-bla a köbön. ;) Eléggé diszjunkt fogalmak ezek, ráadásul akár a hardvert is lehet ojjektumként absztraháni. :-D Mint ahogy az alső mondatodban helyesen írod:
Kiegészítem azzal, hogy miben érdemes. Hiába lehe bármit megírni még sql-ben vagy java-ban is, nem biztos hogy célszerű. Ami lényeges változást látok a 80-as évek óta az csak annyi, hogy akkoriban folyamatábrából készültek a programok. Manapság már mindenki fejből írja. :-DDD A legnagyobb sértés, amit a fejemhez vágtak: Ti assembler programozók addig tesztelitek a programot, amíg jó nem lesz. - mondta aki soha nem dolgozott folyamatábrából.
A bare metal különféle absztrakciós rétegek nélkül működik, vagy, amint egyes szakértők leírják, "anélkül, hogy támogatná az operációs rendszert". Retkes szoftveres csürhe! :-D Ki mondta, hogy mindig van operációs rendszer. És mi van, ha az absztrakciók helyett azt írom, ami a bizonyíthatóan helyes működéshez szükséges?
Mutatok egy példaprogramot (részlet):
Ez egy CDROM vezérlő főprogramja, részletezve:
A fiatalok kedvéért itt egy old school 3 irányú CDROM interfész működik:
A progam struktúráját tekintve fázisregiszteres vezérlés. Szóval semmi olyan, amit a szoftveresek szoftvernek hívnának. Nem hívnám bare metalnak sem - annak ellenére, hogy a hardvert hajtja - hiszen jól definiált feladatot hajt végre egy szoftver interfészen keresztül. A program kb. 20 oldal folyamatábra alapján készült. Fordítja Isis-II as vagy Macro 80.
De láttam már 300 ic-ből álló (két db SN74181 -mint ALU) 8 bites és 20 bit utasításszélességű bipoláris videoprocesszoron struktúrált programot (szinte OOP). De ez ugye bare metal, mert nem volt oprendszer. (?)
Pojjén: CBM-ben írta már be valaki, hogy WAIT 6502,1? A folklór szerint Bill Gates személyesen, saját kezűleg kódolta le ezt az utasítást.
És ha már BASIC, akkor egy kis történelem, mert látom, a mai fiatalok nagyon nincsenek képben.
Szóval nem azért lett a BASIC népszerű és elterjedt, mert hű de jó vagy könnyen tanulható lett volna a nyelv, hanem szimplán azért, mert a gyártóknak anyagilag ez érte meg:
- ingyenes specifikáció, konkrét implementációs részletekkel, ami a Dr Dobb's Journal 1976-os számában általánosan hozzáférhetővé vált (FIGYELEM, Free and Open Source 1976-ban!)
- pofonegyszerű (minimális kulcsszókészlet), amihez a lexer kis helyen, könnyedén implementálható (minden utasítás és változó maximum csak 2 betű lehet!)
- alapvetően egy tokenizált futási környezet (ez manapság úgy szokás mondani, hogy bytecode VM), megintcsak, emiatt a tokenizáló és a tokeninterpreter is kis helyen elfért (belefért a kor hardver nyújtotta kereteibe, úm. 8 bit és pár K RAM)
- nem is volt igen más alternatíva, a kor összes többi fordítója drága, zárt forrású és csak nagy gépeken voltak képesek futni (messze nem fértek el 4K-ban)
Manapság úgy tálalják a WebAssembly-t, mintha azzal szarták volna a spanyol viaszt. Ehhez képest emlékszem, mekkora szenzációt csaptak a Java körül is, hogy az már bájtkódra fordul. Hát, ez egyáltalán nem újdonság, a BASIC rávert pár évtizedet mindkettőre. Megjegyzem, a manapság annyira népszerű Lua működési elve is pontosan ugyanez, egy nyelv függő bájtkód VM valójában, csak ott elmaradt a bájtkód-marketing-bullshit-hájp. A Python is hasonló, csak ott basztak specifikálni a bájtkódot, ezért még önmagával sem kompatíbilis. (Azt meg kell hagyni, a Java bájtkódja a többihez képest kifejezetten elegáns, jól átgondolt és hatékonyan interpretálható. A WASM egy agyrém, az egyetlen előnye, hogy nem kötötték a JavaScript nyelvhez, egyébként csak hátránya van.)
További érdekesség, hogy nemcsak a kor otthoni számítógépei (mint a ZX Spectrum vagy a Commodore), hanem még az eredeti IBM PC is beépített BASIC-el érkezett.
Ha a BIOS nem talált operációs rendszert, akkor nem hibaüzetet írt ki, mint manapság, hanem elindította a ROM BASIC-et.
Azzal, hogy a mai gépek csak egy hibaüzenetet dobnak bekapcsoláskor, ahelyett, hogy egy egyből használható programozási környezetet nyújtanának, rengeteget vesztett a szakma. Ma már nem állnak neki a gyerekek a szabadidejükben kódolni, mert nincs hol, és ami mégnagyobb baj, hogy a "hacker mentalitás" (csakazért is rájövök, ezt vagy azt hogy kell benne megcsinálni) helyett csak az 1 bites fogyasztó magatartást szívják magukba, emiatt felnővén se lesznek belőlük jó programozók.
Cserébe fogalmunk sem volt arról, hogy mi fán terem az, hogy 'operációs rendszer', előbb tanultunk meg programozni, mint hogy egyáltalán értettük volna a gép működését. Kétségtelenül kedvezett ez a rendszer annak, aki a gyakorlat alapján kezdett foglalkozni a számítástechnikával, de nem feltétlenül előny, hogy az operációs rendszerbe illő parancsokat egy adott programnyelvbe illesztik be. A C64 után teljesen szokatlan volt megismerni a CP/M-et, elsőre nem is értettem, hogy ez mire jó (főleg, hogy a CP/M-mel először egy C64 bővítményen keresztül ismerkedtem meg, és hát az a 1541-es floppyval bűn lassú volt. Első használható CP/M akkor lett nálam, amikor a C128-hoz beszereztem a hozzávaló 1571-es floppy drive-ot, akkor már használható sebességgel futott).
>Ha a BIOS nem talált operációs rendszert, akkor nem hibaüzetet írt ki, mint manapság, hanem elindította a ROM BASIC-et.
>Azzal, hogy a mai gépek csak egy hibaüzenetet dobnak bekapcsoláskor, ahelyett, hogy egy egyből használható programozási környezetet nyújtanának, rengeteget vesztett a szakma. Ma már nem állnak neki a gyerekek a szabadidejükben kódolni, mert nincs hol
Igen, ez egy komoly probléma, és emiatt régebben azt találtam ki, hogy a gyerekeknek csinálok egy olyan gépet, ami BASIC interpreter módban indul, mint annó a C64 vagy az Enterprise (ilyenem volt, azért említem), meg az összes többi abban a korban. Meg is csináltam annó, de aztán rájöttem, hogy mégsem úgy lesz.
Az eredeti elképzelésem az volt, hogy konzol módú gépet kapnak először saját gépnek, csinálunk egy ablakkezelőt, animációt programozunk, majd 3D-t, stb és akkortól lehetnek egy adott technológiának a felhasználói, amikor bizonyították, hogy értik az alapjait. Aztán erről letettem, hanem inkább csak simán tiltom az összes mozgóképet egyelőre. Azért nem feltétlenül ésszerű a konzolos megközelítés, mert talán tényleg nem a konzol volt a lényeg, hanem hogy a programozó eszköz azonnal elérhető volt. Ezt meg úgy is meg lehet adni a gyereknek, ha telepítesz és beállítgatsz egy jó IDE-t neki, meg megmutatod, hogy hogy kell használni. De még lehet, hogy úgy lesz, ahogy annó elterveztem.
Az a probléma a programozássa. hogy hiába tanulod és érted "a nyelvet", feladat kell! Hiába adok neked egy kalapácsot és szögeket, nem mész vele semmire. Ha deszkákat is adok hozzájuk, akkor is elképzelhető, hogy abszolút értelmetlen két deszkát összeszögelni. Tehát feladat kell ami értelmezhető és a megoldó hasznosítani is tudja a megoldást! Erre nem adja meg a választ a "Milyen IDE?" kérdés. :-D
Én is megcsináltam ezt. Megy persze applikációként is, külön szívás volt azzal, hogy gépbekapcsolás után, operációs rendszer nélkül is elinduljon, de megoldottam:
MEG-4.
Miután elkészült, persze azután egyből találtam más hasonló fantasy console-t, ami tud BASIC-et, pl. BASIC8 vagy SmileBASIC (mondjuk mindkettő fizetős), illetve a TIC-80-ba is tervezik már (bár még nagyon csak ötlet szintjén áll a dolog). Szóval talán mégsem volt potyára, hogy megcsináltam :-)
Úgy van, az eszköz elérhetősége volt a kulcs.
Ez nálunk a második lépés. Mostanra elég jól belejött a MEG-4 használatába, most jön az, hogy megtanítom Linux-ot telepíteni (ez már úgy ahogy megy neki), és hogy hogyan kell feltenni és beállítani azokat a programokat, amiket ott készen kap (szövegszerkesztő - valszeg scite vagy geany, mindenképp valami egyszerűbb indulásnak; képszerkesztő - GIMP és GrafX2; térképszerkesztő - Tiled; zeneszerkesztő - Audacity, MilkyTracker és MuseScore; fontszerkesztő - FontForge; fordító - gcc és make, stb. stb. stb.)
Jól látható, hogy ez azért nem kis falat így, és már kezdi értékelni a gyerek, hogy mennyi mindent nyújt neki egyből a MEG-4.
assembly rulez!:D