Why Perl
========
There are many reasons (even serious reasons :-)
why you should be doing your graphical
programming in perl.

The Happening Language
----------------------
Perl is becoming the language of choice for more and more things.
In fact perl is exploding with more and more
modules coming out, and new users every day.
What was once a simple scripting thing has evolved into
a many-featured, highly-expressive language with powerful stuff
like object-oriented programming.
You can do everything in perl.
You are already parsing those large data files using perl, why not
plot/draw/render your data in the same perl program?
Soon, everything in /bin and /usr/bin will just be a link to perl :-)
And most importantly, PERL is cool!!  
(Since OpenGL is cool, now you can be twice as cool :-)


Simple Administration
---------------------
Consider a small program written in perl.
Its nice not having a ".c" file, a ".o" file, an executable,
and possibly a makefile to worry about.  
With perl the source is the executable (1 file <--> 1 program), 
so there's no compiling and
you wont accidently execute something that isn't "up to date".

Also, since there is no compiling stage (and no sloooowww linking stage),
the development cycle is shortened.


Interact With A Running Program
-------------------------------
Because perl is interpreted, it can do things that C/C++ cant do.
Consider a perl program that evaluates (using eval()) strings it gets as
input from stdin or a socket.  For example a user types:
	for($x=0;$x<100;$x++){plant_tree($x,0);}
This would cause 100 trees to be planted (or whatever the
subroutine plant_tree does).  Unless the C developer anticipates
this need (by providing a "plant 100 trees" menu option) then the user
will have to do 100 operations (mouse things or keyboard things) to
acomplish this goal. 
  
Hitting closer to home - Imagine you want to contine playing
this great VR game but you're almost dead.  Would you rather speak
	$life += 50;
into the microphone, or:
	- fumble out of your headgear
	- wonder over to the keyboard
	- hit ctrl-\ to generate a core
	- load up a debugger
	- change the value of variable life
	- contine execution
	- strap your HMD back on
The choice is obvious.

Not every user need can be anticipated, therefore the best thing
to do is allow a higher degree of user expressability.
I realize it is hard for some people to "C" this benefit :-)

Graphics From Non Graphical Sources
-----------------------------------
There is a class of applications
that can be described as "graphically disadvantaged".
i.e. for some reason the application cannot make direct
calls like glBegin(GL_POLYGON).  This could be a multi process
application running on many machines which makes it hard for everyone
to write to the same window.  Perhaps the application is running
on the supercomputer in the back room which doesn't even have
a /usr/include/GL/ directory on its disk.  
Or, the language of the application
doesn't allow OpenGL functions to be called (the program is written in csh).

As long as the application can stream some sort of output, you 
can send it to stdin of the following program:
	perl -e 'use OpenGL; while(<>){eval;}'
Now everybody can be a happy OpenGL program.
i.e. from the non graphical machine:
	myprogram | rsh grfx_box "perl -e 'use OpenGL; while(<>){eval;}'"
(Uhm, environment variable DISPLAY may have to be set.)
Alternatively you might want to use sockets.
Also, you really dont want to block on input if you want
to multiplex for X events or do animation.

Alternatively, you could write the C program:
	...
	if(!strcmp(input,"glEnd()") { glEnd(); }
	if(!strcmp(input,"glLoadIdentity()") { glLoadIdentity(); }
	<and so on>
	...
I'm sure I would have had fewer bugs in the past (forgetting the "!") 
if strcmp() was named strdiff() instead :-) 

