The program for creating the maze and implementing the maze-
solving game is written in a high-level language using a
high-level graphics package. To a decent approximation,
it's visual python, or a subset thereof. Visual python
is IMHO a remarkably easy-to-use graphics package. It's
surprisingly powerful, given how easy to use it is. OTOH
it's not without bugs.
This is a Big Deal for the following reason: IMHO it is an
unwise use of resources to write programs in a low-level
language. It is double-especially unwise for naïve students
to mess around with low-level stuff. They need to learn
modern programming structures and methods.
The goal is to have a system that lots of people can use for
doing nontrivial things. This goal has been only imperfectly
achieved. There are several current efforts aiming in
this general direction. Several of them show promise, but
all of them have terrible limitations. In addition to the
maze program itself, which was already written, I had to
write several hundred lines of code. I had to invent a
bunch of dirty tricks and claw my way through a thicket
of compiler bugs, misfeatures, and undocumented features.
However, the next guy to come along should have a
relatively less-difficult time of it. Not easy,
but less difficult, certainly less difficult than
trying to write nontrivial programs in a low-level
language such as javascript.
One thing to be aware of: There are examples out there of
people doing things like this, but it is virtually impossible
to find them, because google refuses to index javascript.
They keep saying they are going to fix that RSN, but it
hasn't happened yet. I get only 7 hits from https://www.google.com/search?q="glowscript_compile";
most of which are not at all informative. One of those
hits is my own work, which is not informative to me,
although it may be to others.
My point is, there is other work in this direction; it's
just hard to find. One example is https://trinket.io/
which touts itself as
"A Coding Environment Designed for Education"
It uses the rapydscript compiler and the glowscript runtime
libraries, which is the same foundation that I use.
Rapydscript is a compiler that can run entirely in the browser.
(You can also run it without a browser, if you want to, using
node.js, but that's tangential to the present discussion.)
Any compiler takes in high-level language and emits assembly
language. In this case the high-level language is python,
and the assembly-language is javascript, which then gets
executed by the browser.
The overall bundle I'm calling /glorpy/ which refers to a
combination of glowscript, rapydscript, and visual python.
It must be emphasized that this system is not ready for prime
time. Maybe in a year or two, but not now. For example, one
of the things that makes python nice to use is the large zoo
of importable modules. However, if you try to "import random"
in the glorpy environment, not only does the random library
not get imported, but the attempt makes your program worse off
than it was before: unrelated things start failing.
Chasing compiler bugs is Not Fun.
==============
Another example of a compiler that lives in the browser can
be found within: https://jupyter.org/
However, that's also not ready for prime time. It may be
of interest to a certain market segment that does not include
me. It is far too much of an all-encompassing control-freaky
nanny environment. I want a lot more flexibility that it
provides, more than it will provide anytime soon. It's a
pretty safe bet that when I use a tool, I use it in ways
that the tool-designer never envisioned. I need an all-
terrain vehicle, not a monorail that goes from Point A to
Point B.