Re: Should gnuplot become a programming environment?

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

[snip]

> > Do we want differentiation and integration -
> > in a PLOTTING program??? My answer is: hell, no!
> 
> I don't think such hard-line attitudes are helpful.

Yes, you are right. And I don't want to give
the impression of being rigid and dogmatic here.

As you (and others) point out, it's a balancing
act - how much scripting should gnuplot support,
and where to draw the line? 

But the line has to be drawn somewhere, otherwise
you end up with the kitchen sink.

I will also admit that I am much less clear in my
own mind what the right course of action is here.
To a certain extent, I am playing devil's advocate.

Two sentiments motivate my recent postings:

1) In my opinion, we are crossing "the line" 
   from a simple, stateless, straightforward
   graphical plotting program towards a much
   more complicated programming and computing
   environment.

2) I lack a sense of direction in the recent
   crop of gnuplot features. I get the sense
   that features are implemented on a whim,
   and with little consideration of their 
   follow-up costs and implications.
   That's ok if it's yet another interpolation
   algorithm - because its scope is so limited
   (and because it's still strictly within the
   graphical plotting world.)
   But general-purpose programming infrastructure
   is not limited in the same way: it opens up
   "huge possibilities" as you say, and I am sure
   that it will continue to beget more features
   (local vars, data structures, functions, etc),
   that have nothing to do with "plotting data in
   a file".

I have looked at several scientific (and general)
programming environments over time, and one of the 
essential ingredients seems to be the ability to
say "No". Or at least: "Not here".

Because this is another direction in which this
discussion could be taken: not "yes" or "no", but 
"how". If there is a desire to enable scripting 
with gnuplot, is the right way to achieve this to 
kludge for-loops onto the (already overloaded) plot 
command? 

Is there a way to structure this better? For
instance, maybe rather than cluttering the 
commands with even more sub-options, should 
one think about a really clean and simple 
plugin architecture for programming needs?

(And at that point, one can ask whether one 
could leverage an existing scripting language,
rather than inventing one ad-hoc.)

[snip]

> 
> If I want to do an FFT I would not try to do it in gnuplot script !!!!

All I can say is: not YET.