Just in case the case needs to be made…
Why bother scripting in the first place? Why not just
write a program to solve your problems? A scripter is a program, of
course, just one that accepts programming input from a console or a file.
Scripting is a different architecture for solving a problem. The scripting
architecture goes like this: let me write a program that CAN solve my
problem given appropriate input in a script. The program architecture goes like
this: let me write a program that DOES solve my problem; input and algorithms
are all built-in to the program.
Why bother writing a bunch of scripting infrastructure on
the way to solving some problem rather than just getting to the job of solving
the problem? The reasons are the following
1. The
scripter infrastructure can be reused for future problems
2. It’s
more flexible to have the input outside the program, where it can be changed
independently
a. Having
input outside the program saves a compilation step. The compilation step can be
anywhere from inconvenient to impossible (imagine having to recompile Windows
every time you changed win.ini? Same goes for any application with .ini files.
The gizmo that reads the .ini file is a miniscripter built into the application.)
3. Distributing
the program to others is easier: users don’t need source to the program, just
the script
4. Scripting
supports interaction for pedagogy, exploration, discovery, tinkering,
debugging; hard-baked programs don’t
5. Scripting,
as opposed to mousey GUI interaction, supports iteration and conditionals (it’s
hard to write a GUI that lets you replicate some gesture N times or do
some click and drag only if some logical condition is true)
6. Scripting
supports unattended automation
7. Scripting
saves programmer time
8. With
extension technology, scripters can call ANY library on the system
Let me contrive an example to illustrate some advantages
of scripting. Let’s say you want to write a program to solve Rubik’s Cube. Somewhere along the way, you’re
going to write routines to rotate faces of the cube and some other routines to
rotate the whole cube. Let’s call the face-rotation routines u, d, l, r, f, and
b; for up, down, left, right, front, and back. Calling u results in one
clockwise rotation of the current up face. To get a counterclockwise
rotation, just call u three times. Let’s call the cube-rotation routines U, R,
F; we don’t need D, L, and B since D would just be U U U. The cube-rotation
routines change the identity of the faces; for instance, U is faceRàfaceF, faceFàfaceL, faceLàfaceB,
and faceBàfaceR.
Now, with a scripting architecture, your program would
just read commands from a listener console or from a file and perform rotations
on a display of the cube. You could have all your complexity in the script,
where you can change it without recompiling the your input. For instance, if
you could also call random number generation from your script, you could
scramble the cube by building up a string of the commands listed above. If your
scripter supported abstraction, you could define new macros, like u’ ß u u u, representing a counterclockwise
rotation, or c1ß(u’ r u)
representing a commutator. With enough programming muscle in the scripter, you
could write your analyzer and solver entirely in script, also. A GUI is going
to have a hard time giving you any facilities for defining macros: you have to
have the macros in your head and execute them in ‘unrolled’ form by dragging
the faces of the cube around.
Composition would let us build up whole solutions and
libraries of macros, all in the script. Here’s the point: once we wrote the
scripter, we wouldn’t have to write much compiled code at all to work on the
solution of Rubik’s cube, and we wouldn’t have to do lots of tedious clicking
and dragging to perform manual solutions. Without a scripter, we would have to
build up all our macros, compositions, analyzer, and solver, all in compiled code.
The extra compilation step every iteration through the code adds up to a lot of
precious programmer time. Having macro, analyzer, and solution code mixed in
with the code that just mechanically moves and displays faces blurs the
distinction and reduces our opportunities to see and exploit the differences.