Názory k článku Factor: revoluce v programování nebo propadák?

64 znaku staci kazdemu.

nebo to rekl nekdo jiny o necem uplne jinem?

Úúúf, Pavle, ty uvozovky u "maximalistického" prostředí jsou, doufám, míněny jako ironie. :-] Určitě padlo i v Tvém seriálu o Forthu, že OKAD I byl "napsaný" přímo do paměti hexeditorem ovládaným víceméně kurzorovými šipkami (když to trošku přeženu - sedm kláves není moc). Chuck se s nějakými zdrojáky nepáral a kompiloval forthovské programy přímo v hlavě. No, já bych si na to netroufl. :o)

Já jsem colorFort provozoval na notebooku, na kterém mi jedna z verzí fungovala z diskety. S colorForthem je hlavně problém co do kompatibility hardwaru. Chuck Moore si pro sebe svoji verzi upravá pro jakýkoli HW, ale co my, méně assemblerově zdatní nešťastníci? Pak jsem našel ještě něco, co běhalo v QEMU (nebo to byl jenom Bochs?)...on je v těch mutacích colorForthu trošku zmatek. :-)

VESA? Já nevím, přijde mi, že VESA verze byla až pozdější (to je to, co mi běhalo na notebooku :-)), mám pocit, že originál od Chucka - pokud ne "colorForth 2001", tak ty pozdější verze, co uvolnil někdy v roce 2005 - byl v mutacích nVidia a ATI. nVidii mám v desktopu, ale tam jsem zase neměl (a nemám) disketovou jednotku. Problém je zase v tom, že colorForth běhá z diskety a na něco jiného by se musel přepsat jeho loader. :-D

No on colorForth má přímo projekt na SourceForgi. Předpokládám, že tohle bude jedna z iniciativ s tím spojených. Ale já momentálně na Forth stejně nemám čas, hustím do sebe jiné zajímavé věci. :-) Mně by se colorForth spíš líbil na dedikovaném HW s minimální spotřebou. Dneska by to asi mohl být ARM. Mohlo by to mít velikost telefonu nebo kalkulačky, šlo by to připojit k televizi nebo monitoru, mělo by to modrozubou klávesnici... Řečeno po anglicku, "PC is so nineties!" :-D

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.