Glenford J. Myers, "Projektowanie niezawodnego oprogramowania", WNT 1980, oryginał John Willey and Sons 1976, rozdział Języki programowania programowania a niezawodność, podrozdział Procedury i zakresy danych:

Podstawowa reguła powiada, że - o ile programista nie określi jej inaczej - zmienna powinna być lokalna względem jednego modułu lub procedury. W APL przyjęto wręcz odwrotną zasadę: jeśli programista jawnie nie określi zmiennej jako lokalnej względem danego modułu (funkcji APL), to jest ona zmienną globalną. To zjawisko powoduje zdradliwe błędy, na przykład wówczas, gdy programista konsekwentnie używa zmiennej I jako sterującej pętlą w wielu funkcjach APL, lecz przynajmniej w jednej z nich zapomina okreslić I jako zmienną lokalną.

(...)

Należy przyjąć kilka zasad kontroli zakresu i globalności danych. Wszystkie dane powinny być lokalne względem procedury, w której są deklarowane, jeżeli programista nie określi ich inaczej.

Skądś znajome? Przeczytawszy to od razu pomyślałem o JavaScripcie, który powstał 19 lat później. Jeżeli nie znacie JS i nie wiecie o co chodzi, poniżej podaję przykład sytuacji opisanej na przykładzie obecnie bardzo mało popularnego już APL występującej w JavaScripcie.

A podobno rozważano stworzenie języka dla przeglądarek opartego na Scheme...

Swoją drogą nie do końca prawidłowe jest też współczesne używanie języka stworzonego do irytujących animacji na stronach w dużych aplikacjach serwerowych.

function aaa () {
        /* Zapomniałeś deklaracji. */

        i = 0; /* Nada wartość 0 zmiennej GLOBALNEJ o nazwie i,
                  tworząc taką jeśli nie istniała. */
}

function bbb () {
        /* ... */

        ++i;
        aaa (); /* Nic z tego, i jest teraz w stanie pozostawonym
                   przez funkcję aaa. */

        /* ... */
}

Poprawnie byłoby:

function aaa () {
        var i; /* Deklaracja zmiennej wewnątrz funkcji,
                  co czyni ją zmienną lokalną. */

        i = 0;
}

No i światło dzienne ujrzał program służący do wykonywania prostych skryptów, o którym marzyłem od dawna i pisałem sobie w wolnym czasie.

https://github.com/andrzejlisek/ScriptSDCCWeb

Sam pomysł nie jest nowy, tylko bardzo stary, zrealizowany w tym projekcie: https://github.com/andrzejlisek/ScriptSDCC

Historycznie, pomysł był taki, żeby na szybko coś przeliczyć, na szybko coś namalować. Zamiast wymyślać jakiś język skryptu, postawiłem wtedy na coś gotowego, co już prawie rozwiązywało problem. Jest program https://sdcc.sourceforge.net/ , który kompiluje kod w języku C do różnych mikroprocesorów 8-bitowych, czyli prostych w symulacji. Miałem już gotową implementację procesorów 8051 i Z80 zrealizowaną na potrzeby innych programów, czyli wystarczyło wziąć gotowy kod, odpowiednio dostosować, usunąć, co niepotrzebne i już.

Interakcja z użytkownikiem też jest prosta. Na potrzeby tego jest określony adres w pamięci zwany jako "swap page", czyli strona wymiana danych. Wystarczy śledzić jeden wybrany bajt w tej pamięci i jak zmieni wartość, to symulator wykona określoną czynność, np. wypisze tekst, pobierze dane, namaluje coś. Pomysł został zrealizowany z powodzeniem, a nawet posłużył do sprawdzenia, jak duży obszar w pamięci zajmuje dany program, a nawet do testowania różnych algorytmów implementowanych w SDCC na potrzeby implementacji czegokolwiek.

Bardzo szybko zamarzyło mi się, żeby mieć taki program na telefonie, choćby bez kompilacji, bo na telefonie nie można uruchomić SDCC. Pomysł odpuściłem, bo jakoś nie widziało mi się przerabiać tego wszystkiego do JavaScript. Teraz, WebAssembly umożliwia tworzenie "logiki biznesowej" w C++, więc wróciłem do tego projektu. Jednakże, zamiast przerabiać na 1:1, co nie byłoby łatwe, postanowiłem zrobić interfejs od początku, wg nowego pomysłu. Głównym elementem interakcji będzie prosty formularz, co zresztą zacząłem realizować w starym projekcie, ale nie skończyłem i nie publikowałem. Grafika będzie taka sama, jak w poprzednim projekcie, same algorytmy malowania już miałem w tamtym projekcie.

W ten oto sposób projekt zrealizowałem bazując na źródłach starego i spełnia swoją funkcję. Dodatkowo dorobiłem symulację procesroa 6502, bo to tez jest prosty procesor, a SDCC od którejś wersji kompiluje do niego. W celu demonstacji możliwości ScriptSDCC, umieściłem kilka skryptów zarówno w postaci źródłowej, jak i skompilowanej na wszystkie trzy procesory, a także opisałem te skrypty wraz ze screenami. Na screenach widać, że grafikę można prezentować z różnych perspektyw, skalować w różny sposób. Co prawda, bardzo daleko do zaawansowanych narzędzi przeznaczonych do tego celu, jak np. Matlab, a w grafice bardzo dalego do możliwości OpenGL, ale to miało być proste narzędzie, łatwe w użyciu i celem nie jest "konkurowanie" z profesjonalnym oprogramowaniem.

Oprócz podstawowego zastosowania narzędzia, można porównywać, jaki obszar pamięci zajmuje kod tego samego na różnych procesorach, a także porównywać wydajność, bo o ile tempo pracy silnika jest podobne (liczba instrukcji na sekundę), o tyle czas wykonania jakiegoś przeliczenia może się znacznie różnic.