Re: Should gnuplot become a programming environment?

[<pl...@pi...>]

On 10/30/14 17:30, Philipp K. Janert wrote:
>
>
> [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?
>

I agree, that  while useful, the for loops do feel like a bit of a 
bolt-on kludge.

Maybe this could be done in a more structured way.

Also plot gets very messy at times. Off loading to a fn call can some 
times help.

I'd like something more compact than  :  linecol rgb "light-gray"  at 
times ;)

BTW, you mentioned why don't I use octave: because it's buggy and the 
main devs a snotty Mac elitists who think they know it all.

Here suggstions get a fair run and if they're good they get acted on fast.

h/t to Ethan.

Peter.




> (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.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>