Filozofia Fortha sprowadza się właściwie do tego, że tworzysz swój własny język na potrzeby konkretnego problemu (podobną strategię przyjął zresztą Racket). Budujesz kolejne warstwy abstrakcji, przystosowane do Twoich potrzeb – np. "goły" Forth nie ma mechanizmów GC, nie ma metod programowania obiektowego, ale to wszystko można zaimplementować, jeżeli ktoś ma taki kaprys; robi się nam wtedy język wysokiego poziomu, ale "skrojony na wymiar".
Jeżeli chodzi o GUI, dowiązania do popularnych bibliotek itd., to we wszystkich językach (oprócz może C, C++ i Javy) polega to na wykorzystaniu dynamicznych bibliotek napisanych w którymś z ww. języków. Tak jest na przykład z Pythonem, który ma imponujący ekosystem narzędzi, ale te bardziej wymagające nie są przecież napisane w Pythonie :-) Gforth pozwala na korzystanie z zewnętrznych bibliotek i w sumie nic nie stoi na przeszkodzie, żeby napisać dla niego np. interfejs do Qt5. Atarowskie Forthy oczywiście nie mają czegoś takiego, ale za to pozwalają na pisanie wstawek asemblerowych, które w małej skali dają podobne możliwości.
Forth na pewno nigdy nie będzie (i raczej nie bardzo był w swoich czasach) używany do tworzenia produkcyjnych aplikacji, ale to wynika raczej z czegoś innego: po pierwsze, jest praktycznie niszą w niszy, nie ma solidnego repozytorium pakietów "do wszystkiego", nie stoi za nim żadna duża firma itd. Po drugie, utrzymanie dużej bazy kodu bez solidnych narzędzi typu debuggery, lintery itp. to dla każdej firmy byłoby samobójstwo.
To tyle; nie wiem właściwie, co konkretnie chciałem udowodnić – chyba nic :D
Udało się uruchomić pod APX Extended Fig-Forth Rev. 2: "6502 DISASSEMBLER" (autor: JOHN MATTES, Antic 3 i 4 / 1984). Wydaje się działać w większości przypadków, tutaj deasembluje ! oraz C! (Forth-owy DPOKE i POKE).
Często wynik deasemblacji jest wątpliwy - tu muszę podszkolić się z asemblera, żeby stwierdzić czy są to kompromitujące błędy, czy niekoniecznie (autor przypomina, że w pamięci siedzi kod Fortha, dane itp - nie musi to być czysty kod maszynowy i wtedy deasemblacja wariuje). Nie jest to takie oczywiste i nieco studzi entuzjazm (no i dobrze, na teren fantazji wkracza rzeczywistość).
Nie są jasne skróty trybów adresowania ale rozpracuję z Ruszczycem i innymi oraz opiszę w komentarzach do kodu, używa się tam takich pięknych skrótów: ,X ,Y ,X (drugi raz to samo?) )Y .. ## 0P X) .Y () .A IM RE
Następne zadania do ogarnięcia: diff między ekranami, tuningi edytorów, prosty debugger "krokowy" (może się nie udać w APX Forth, zobaczymy).
Drogi Watsonie, wnioskuję że Piotr zainteresował się Forth-em w 2012 roku, eksperymentował z kodem z Tajemnic Atari, udało Mu się uruchomić Edytor Wprowadzania. Najwyraźniej działał z asemblerem Forth oraz słowami graficznymi z wbudowanej biblioteki. Użyty Forth to oczywiście APX Extended Fig-Forth z książki Ruszczyca oraz kursu Rolanda Pantoły.
Piotr pracował z klasycznym edytorem Forth'a (wbudowanym, liniowym), więc mógł się nieco umęczyć...
Pliki a8s to zrzuty pamięci Atari800Win - źródeł w oryginalnej postaci nie widać, tylko dekompilacja pokazuje ich zawartość (nie pokaże bez dodatkowych narzędzi słów typu "primitives", pisanych w asemblerze Forth). Jeśli faktycznie Piotr napisał kilka słów w asemblerze Forth (coś z funkcji trygonometrycznych), to czapki z głów!
Jeśli Piotr się nie zniechęcił do końca to być może zainteresuje Go już bliska reedycja "Poznajemy Forth" z interesującymi dodatkami, również związanymi z emulacją...
Bardzo ładna dedukcja drogi Sherlocku :) A to mi przypomina taki oto obrazek z Komputera 5/1988 (rysunek Piotra Kakieta towarzyszył opisowi algorytmu bisekcji):
