Re: Unintended consequences - things to think about

[Philipp K. J. <ja...@ie...>]

Here are some things to think about:

1) We now have loops. But we don't have an
iterable data structure. No, wait, we have
one - we fake it as white-space separated 
string. (I admit the ingenuity of the thought,
but - how kludgy is THAT?)

So, before too long, the loops will beget
an array. That seems certain.

2) Once we have arrays, there will be a
desire to load files into them. Otherwise,
why have arrays, right? So, arrays will
beget a "read_file" feature. 

3) Now that we can read file(s) into 
arrays, it's natural that we want to 
operate on them. One could do that with
loops, but (again) it's natural to do 
things like array1 + array2, right? 

4) Whereas items 1-3 lie in the future, the 
following is already an issue today: we have
loops and conditionals, so it seems natural
to write functions. Well - we don't HAVE
functions, but we can fake them as scripts
that we load with "call". Problem is that
these scripts don't define local variables -
any variable I use in my script will become
a variable in the gnuplot session. To prevent
clobbering existing variables, I therefore
need to prepend a prefix to the name of each
variable "MY_SCRIPT_i", "MY_SCRIPT_j", and so
on. Very kludgy. Hence, it is reasonable to
ask for functions with local variables.

(Side question: is that not how matlab 
implements functions - as separate command
files? I seem to remember something like
that. Do we really need to repeat every
mistake that has been made before?)

Anyway...

My point, in case this still isn't clear:

Once you have one programming feature (say:
loops), there is a natural tendency for them 
to require all other programming features 
(data structures, functions, local scope).

Therefore, what starts like a local convenience 
today will - invariably - grow until it has 
acquired all the features that are already 
provided by R, matlab, Octave, Perl, Python, Ruby.

And THAT I think is the wrong direction. If 
somebody wants R, why would they use gnuplot? 

I also think that it is a misdirection of effort: 
do we really need to figure out how to design 
functions with locally scoped variables? This
has already been done, several times. Would it
not be better to leverage other people's work?

If gnuplot needs to acquire programming features
to stay competitive, then it should try to borrow
them from somewhere else, where all these problems
have already been solved - rather than inventing
the wheel (and poorly, at that).

Best,

		Ph.