Vlákno názorů k článku Factor: revoluce v programování nebo propadák? od dejfson - basic ze ZX spectra. Nadupany a nedovoli udelat...

Ehm, schválně, co najdeš na http://www.symbolics.com ? ;-) Mimochodem, vřele doporučuju zkusit whois symbolics.com, a obzvlášť se kouknout na datum. :-)

Pokud jde o Symbolics, opravdu by bylo bývalo možné, aby ho IBM bylo koupilo kvůli nízkému výkonu Lispu na strojích 704/709. Nicméně mi není příliš jasné, proč by to byli dělali (ať žijí kondicionály préterita! :D). V době vzniku firmy Symbolics měly 704ky "odpočítáno" nějakých dvacet pět let a 709ky dvacet let, a snad už všude byly nahrazeny novějšími systémy IBM. ;-)

Symbolics (ZetaLisp) se jako startup odštěpil z MIT, stejně jako LMI. Texas Instruments vyráběly vlastní stroje TI Explorer, co používaly dialekt odvozený od dialektu LMI, a Lisp (InterLisp-D) běžel nativně i na strojích Xeroxu, jen se přebootoval mikrokód ze Smalltalku na Lisp. ;-)

> Něco jako bajtkód měl u mě na Commodoru jen Forth

Který? U Forthu obecně bych byl velmi opatrný v terminologii. Ale bytekódem bych to rozhodně nenazýval. Dalo by se říci, že sám program ve Forthu je vlastně symbolicky zapsaným bytekódem. Po přeložení forthovského programu (ač interpeter, jedná se o "částečně kompilovaný" jazyk) nedostaneme nijak standardizovaný a už vůbec ne přenositelný tok směsi kódů operací a literálů; v případě realizace interpreteru/překladače formou STC (subroutine threaded code) už de facto k žádné interpretaci kódu nedochází, ale je přímo prováděn procesorem. Po doplnění volitelného modifikátoru, který požaduje okopírování PFA (=CFA v této implementaci) místo vložení odkazu na slovníkovou položku při přikompilovávání nového slova, se už výsledný kód stává klasickým produktem kompilátoru (který má oproti klasickým kompilátorům tu výhodu, že je dynamický a vzhledem k absenci zásobníkového rámce v mnoha případech i rychlejší).

U BASICů na osmibitech bych souhlasil, že také nejde o bytekód - jedná se pouze o (částečně) tokenizovaný zdrojový text, tedy elementární makroprocesing, nikoli o kódy operací majících instrukční charakter. Některé implementace dokonce měly samostatné tokeny pro "GO", "TO", "SUB", takže GOTO a GOSUB sestávaly ze dvou tokenů (a GO TO a GO SUB ze dvou tokenů oddělených mezerou), přičemž stejný token "TO" byl použit ve smyčce FOR...TO.
BTW - on si to dnes už málo kdo uvědomuje, ale tehdejší interpretery BASICu byly koncipovány poměrně flexibilně - snad jen s výjimkou ZX Spectra nebyl vůbec žádný problém obohatit interpreter o nové příkazy a vlastnosti (i když, pravda, obvykle ne prostředky BASICu :-) Nicméně autoři zmiňovaných interpreterů těmto budoucím uživatelským rozšířením očividně nechávali doširoka otevřená zadní vrátka).

Pravda, tokenizované příkazy použité u Basiců (aspoň těch na osmibitech) se dost podstatně odlišuje například od bytekódu pro JVM. Zase je však bližší například bytekódu Pythonu (tomu klasickému, u Parrotu je to trošku jinak). Asi by bylo zapotřebí rozlišovat, jestli se jedná o bytekód na "vyšší" úrovni, což je právě případ Basicu (co příkaz, to jeden byte, co proměnná to většinou také jeden byte odkazující do tabulky názvů, čísla jsou převedena na binární reprezentaci, čísla řádků typicky 2 byty, řetězce formou odkazů do paměti - tady dokonce některé Basicy měly něco jako garbage collector) nebo o bytekód, který vlastně s původním programem nemá skoro nic společného - viz JVM, kde se některé informace ztrácí.

Osobně Basicy vůbec nezatracuju (vždyť jsem na nich vyrostl, než jsem utekl k asm :-)), ono taky nacpat do 4-8 kB ROMky interpreter i s de facto velmi dobrým debuggerem a k tomu ještě na osmibitovém procesoru, který má většinou dost omezený repertoár instrukcí, byl docela kumšt (na druhou stranu je na tom jazyku vidět jeho stáří). Není ostatně tajemstvím, že Atari chtělo Basic původně koupit od Microsoftu, ale ten nedokázal svůj Basic nacpat do požadovaných 8 kB ROM, tak se nakonec použil Basic přímo vytvořený pro Atari.