Re: Should gnuplot become a programming environment? - If yes, how?

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

On 11/13/14 17:58, Philipp K. Janert wrote:
>
> One more question in the whole argument:
>
> Even if we agree that adding programming
> functionality to gnuplot is a good thing,
> it nevertheless leaves open the decision
> HOW this should be done.
>
> Is adding convenience features to the core
> language in an essentially ad-hoc manner
> the best strategy?
>
> Or would it make sense to invest some effort
> to have tighter integration with an existing
> programming environment (rather than reinventing
> loops, functions, data structures within gnuplot)?
>
> Or would it be possible to split functionality
> into a "core" (graphics) part and an "optional"
> part, with a clear separation of concerns?
>
> Or can one have an "extension" framework so
> that people can add features without having
> to hack gnuplot backend C code?
>
> The current strategy seems to be that there
> is none. That may give short term wins, but
> the end result is going to be a mess.
>
> Best,
>
> 		Ph.
>

Of course a bit of planning and a design strategy is better than bolt-on 
evolution.

Since Ethan seems to do most of the work around here and it was he who 
started all this by implementing my variable assignment suggestion  and 
IFAIK he has done all the other programming feature in gnuplot, maybe he 
has a fair idea where he's going and has given it some top-down planning 
but  never saw the need to bother making a formal design study about it.

He seems to have a fairly good idea where he's going with this.

Unless I saw something going badly wrong or there was substantial input 
from others that required some team planning and a formal strategy, I'd 
not want start making demands.

Peter.