Trochę to wygląda na kontrofensywę przeciw Lua . Ja jednak szykuję wersję 0.6 w której będzie kilka kolejnych fajnych rzeczy, np. monitorowanie wykorzystania pamięci przez skrypt w Lua Exploradorze, przeglądanie tablic w tymże, przekazywanie argumentów do skryptu z linii komend i parę innych drobiazgów.

Najpierw w kwestii formalnej, co do słowa „tworząc”. Faktem jest, że MorphOS-owy port Lua to daleko posunięta modyfikacja oryginału, oddajmy jednak honor twórcom tego świetnego języka – to mimo wszystko tylko port. Przechodząc natomiast do ARexxa – w 90% przypadków Lua jest go w stanie zastąpić już w obecnej wersji 0.5, ponieważ ma możliwość wysyłania komend do portów ARexxa programów i odbierania wyników tych komend (coś, czego BRexx nie potrafi). W Lua można już teraz pisać np. skrypty rysujące cokolwiek w TVPaincie, czy używające portów ARexxa innych aplikacji. Piszę o tym dość obszerny artykuł do pisma PPA #6, później artykuł ten znajdzie się również na naszym portalu. W przyszłości widzę 3 zastosowania Lua: po pierwsze jako język skryptowy, zamiennik ARexxa. Po drugie jako język używany wewnątrz większych programów do różnych celów. Po trzecie wreszcie planuję wyposażyć Lua w bezpośredni dostęp do MUI, co pozwoli w Lua pisać kompletne aplikacje i da rozsądną alternatywę dla koszmarków tworzonych w Hollywood.

Tworzenie własnego języka, istniejącego tylko pod MorphOS-em, nie miałoby moim zdaniem sensu. Lua jest językiem wieloplatformowym, a przez to całkiem popularnym i można znaleźć w sieci dziesiątki tutoriali, fora dyskusyjne, przykłady, biblioteki i tak dalej. Co więcej, jest ciekawy projekt LuaJIT, czyli dynamiczny kompilator Lua, który również obsługuje procesory PowerPC (rdzeń e500v2, co oznacza, że praktycznie bez bólu powinien pójść na naszych e600 w Pegasosach czy Makach wszelakich). Mam na ten projekt oko, bo po jego zastosowaniu Lua zaczyna się zbliżać prędkością do języków kompilowanych i naprawdę może się z niej zrobić mocny język do pisania aplikacji. Na razie jednak skupiam się na rzeczach bardziej w Lua potrzebnych.

Obecnie nie zachodzi de facto kompilacja skryptów. Aktualnie przy ładowaniu skryptu kod źródłowy tłumaczony jest na rozkazy maszyny wirtualnej Lua i tak zapamiętywany. W czasie wykonywania skryptu, każda operacja maszyny wirtualnej powoduje wykonanie szeregu rozkazów procesora, powiedzmy kilkunastu, czy kilkudziesięciu. Teraz wyobraźmy sobie że mamy pętlę wykonującą się sto razy. Obecny interpreter przy każdym nawrocie będzie tłumaczył zawartość tej pętli z kodu maszyny wirtualnej, rozkaz po rozkazie na sekwencje rozkazów maszynowych procesora i te sekwencje wykonywał. LuaJIT może wnętrze pętli raz przetłumaczyć na blok kodu maszynowego procesora i zapamiętać. Wtedy przy każdym nawrocie nie będzie zachodziła interpretacja – procesor będzie dostawał gotowy blok instrukcji do wykonania i działał z taką samą prędkością, jakby program został napisany np. w C i skompilowany.

Jest tu pełna analogia do UAE. Tam „maszyną wirtualną” jest emulowany procesor M68k. Zwykłe UAE bierze jeden rozkaz emulowanego M68k i wykonuje go, co sprowadza się do wykonania kilkunastu, czy kilkudziesięciu rozkazów PPC. Potem bierze następny rozkaz motorolki… i tak dalej. Natomiast WinUAE z JIT-em bloki, których wykonywanie się powtarza, tłumaczy w całości na kod maszynowy x86 raz, a potem go tylko wykonuje. Jaką to daje różnicę wydajności – wiadomo.

To zależy czy są to biblioteki kompilowane (pisane w C/C++) czy pisane w Lua. Trudność portowania tych pierwszych zależy od przenośności kodu C. Jeżeli używają standardów uniksowych to o ile libnix wystarczy do ich skompilowania, można zawalczyć. Te drugie natomiast powinny działać po drobnych poprawkach uwzględniających np. fakt, że morphosowa Lua nie ładuje modułów standardowych automatycznie, albo faktu, że używa morphosowych ścieżek do plików.