Should gnuplot become a programming environment?

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

(This started as a discussion on heredocs, but
is really about a bigger-picture-issue. So, I'll
try to restart this thread again.)

Recently, gnuplot has begun to acquire features
that are typical of a programming language:

- loops and conditionals
- structured data types
- statefulness and persistence.

I don't think this is a good trend, and I'd like
to raise awareness for what's happening.

Gnuplot used to be a simple plotting tool - that
was its weakness, but also its strength.

Now, gnuplot has begun to become a programming
environment. This will make gnuplot more 
complicated: more complicated to learn, but
eventually also more complicated to develop for. 

I doubt that the benefits of turning gnuplot
into a programming environment outweigh the
costs. I also think that this will lead gnuplot 
into a competition with more established
"scientific workbenches" (R, NumPy/SciPy,
Octave) that it will lose. 

I think gnuplot would be better off to stay
a plotting tool, and not try to become a
programming environment. I suggest that we 
should evaluate each such feature very 
carefully before accepting it into gnuplot -
and be ready to reject certain ideas (and/or
look for alternatives that do not require
changes to the gnuplot main program).

I am concerned about "creeping featurism",
where each new "simple/useful" feature drags 
in bigger and bigger features. (Example: gnuplot 
now has loops. It is only natural that it should
have an iterable data structure. Once it has
that, it will be natural to ask for vector
operations and indexing magic - and for 
matrix computations. At that point there will
be demand for local variables and proper blocks,
which will lead to subroutines. And so on.)

I don't think anybody INTENDS to turn gnuplot
into a matlab competitor, but that - in fact -
makes it worse: because there is no thought
given to design upfront, stuff is just being
kludged on. (The result will not be pretty.)

There are only ways to stop this:
- to collectively say "No"
- to collectively say "Yes", discuss the
  direction, and then accept features if
  they fit with the agreed upon direction.

One more thing: scientists are not language
designers, and therefore tend to underestimate
the difficulties in designing a consistent
and maintainable language.

In doing research for my book on
open-source tools for data analysis, I have
looked at a wide variety of "scientific"
programming environments, and got the sense
that most (if not all) of them struggle under
their own weight: they were started, without
much thought, design, or knowledge, by 
scientists who "just wanted to do some 
calculations", but who did not have much
knowledge or experience in the theory of
languages and data structures, who did not
understand large-scale programming, and who -
more than anything - underestimated what they 
were in for. All these programming environments 
(no names, to protect the guilty) are now big,
overgrown, and unstructured monsters. I 
don't want to see gnuplot go the same way.

What do others think?

Best,

		Ph.