Re: Should heredocs be included in "save"?

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

On Wed, 29 Oct 2014 15:59:21 -0700
Ethan A Merritt <sf...@us...> wrote:

> On Wednesday, 29 October, 2014 15:14:40 Philipp K. Janert wrote:
> 
> [big snip to get to a discussion point]
> 
> > > Placing it in a heredoc makes the script self-contained.    

I am splitting this thread into two.

This one is to heredocs: My argument is
that if heredocs stay, then they should
be thought through and implemented in 
such a way as to present a consistent
user experience.

They can be loaded with "load" and in no
other way. Hence, they should be written
(or at least: be writeable) with "save".

That would support your intended use case,
but also support other uses people will 
find for heredocs.

> > 
> > I totally disagree, and I wish there would be a much
> > bigger discussion: we are now breaking the distinction
> > of data and commands. Is this really a good idea? We
> > are also abandoning the idea of not maintaining data 
> > in the session state. Is this architecturally a good
> > direction? I am not at all sure - on balance, I would
> > say: it is not.
> > 
> > One of gnuplot's strong features has always been its
> > simplicity: data was in unstructured text files,
> 
>    Binary data files were introduced some time between verions 3.5
> and 3.7. So - about 20 years ago
> 
> > there was no session state,
> 
>    I am not sure what you mean here.
>    Isn't the session state exactly what you are saving in a "save"
> command? I.e. all the current settings, variable assignments,
> function defs, etc 
> > command files were separate from data.
> 
>    In-line data via plot '-'
>    has been supported at least as far back as version 3.7
> 
> > We are now breaking this. We are beginning to maintain
> > state - which means that before long, there will be 
> > a desire to "reload the session just as it was before",
> > with various preloaded data sets and all that. 
> 
>   Hasn't there all along been a current state that can be saved
>   and later reloaded?
> 
> > We are also now mixing data and commands. At what point
> > will it become habitual to save data always in command
> > files? There goes the ability to load them into Excel
> > or pipe them through sort.
> 
>  Sorry, I'm lost now. 
>  What is it that you would be loading into excel?
>  While I have taken data _out_ of excel as a *.csv file to plot
>  in gnuplot, I am sure I have never wanted to export anything
>  back in the other direction.   
> 
>  I am honestly confused at this point whether you are arguing
>  that a datablock ("heredoc") is part of the current state and
>  therefore should be included in save/restore, or whether you
>  are arguing that data should never be part of the current state
>  and therefore it should not be saved.
> 
> 	Ethan
> 
> > 
> > At the end of this process stands something like R. If
> > you know R, you'll see that it has exactly those features:
> > complicated sessions, complicated internal data models,
> > the whole shmear. 
> > 
> > But: R is a pain to learn.
> > And: if gnuplot wants to compete with R, it will lose.
> >   (In their field, their headstart is too great.)
> > 
> > Do we need to go there, just in order to simplify the
> > maintenance of the demo/ folder?
> > 
> > Sometimes one should simply say "No" to a new feature.
> > Simplicity is a virtue. It should not be abandoned
> > unnecessarily.
> > 
> > I think that heredocs (and some other recent features,
> > but heredocs in particular) take gnuplot in an unhealthy
> > direction. I don't think their consequences have been
> > properly thought through. These features add complexity, 
> > and they will invariably lead to unforeseen and undesirable
> > interactions between features - which will lead to even 
> > more complexity to fix.
> > 
> > Maybe there is a valid need for some of these (and other,
> > yet unproposed) features. But then we should try to
> > understand the ramifications, and - quite possibly -
> > reject some of these ideas, in the name of long-term
> > health and survival.
> > 
> > (To give you a sense for what I foresee: now that we
> > have loops, there is a need for an iterable data 
> > structure. (Currently there is none.) Then there will
> > be the desire to be able to iterate over the entries
> > in a heredoc. Now you pretty much have what R calls a
> > "data frame". Once you have data frames, it makes sense
> > to operate on them - things like vector addition or the
> > odd indexing magic that R and matlab delight in. At 
> > that point, it makes sense to link a matrix library
> > to do some numerics. And so on.)
> > 
> > I think the Numpy/Scipy universe is suffering from the
> > inability to say "No". This has led to a humongous,
> > impenetrable, and totally unstructured API - and
> > serious quality problems! (Adding "one more feature"
> > is easy, but working out all the edge cases and 
> > interactions is not!) 
> > 
> > Gnuplot has always been simple, but reliable. I think
> > we are at risk of abandoning them - without realizing
> > it.
> > 
> > > 
> > > For this type of application, "save" is not a normal command.
> > > If you want to regenerate a plot you just run the script again.
> > > 
> > > 	Ethan  
> > > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via:
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta