Re: Should heredocs be included in "save"?

[Ethan A M. <sf...@us...>]

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 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