Re: Should gnuplot become a programming environment?

[sfeam <sf...@us...>]

On Wednesday, 29 October 2014 04:52:54 PM Philipp K. Janert wrote:
> 
> (This started as a discussion on heredocs, but
> is really about a bigger-picture-issue. So, I'll
> try to restart this thread again.)
> 
> Recently, gnuplot has begun to acquire features
> that are typical of a programming language:
> 
> - loops and conditionals

  Yes, loops are new.

  The only thing new about conditionals is that the
  introduction of bracketed clauses means that you
  no longer have to stuff the entire content on a
  single input line.

  IHMO both of these are significant improvements
  in usability.

> - structured data types

  There are no structured data types in gnuplot that I can think of
  other than complex numbers {R, I}, and they were in gnuplot from
  Day One.

> - statefulness and persistence.

  You said this before but I do not understand what you are
  referring to.  Could you give an example?

You don't mention the one programming-language feature added a
while back that I do regret:  macros.

Macros were one of my failed attempts to implement string variables,
one that I wish had been removed when real string variables were
added later.  The poor design is even more evident now that we
have loops, since it confuses people that the macros are only
evaluated outside the loop, even if the associated string variable
is changed inside the loop.  

Since you raise the issue of backing out bad ideas, 
could we start by deprecating macros?  

	Ethan

> 
> I don't think this is a good trend, and I'd like
> to raise awareness for what's happening.
> 
> Gnuplot used to be a simple plotting tool - that
> was its weakness, but also its strength.
> 
> Now, gnuplot has begun to become a programming
> environment. This will make gnuplot more 
> complicated: more complicated to learn, but
> eventually also more complicated to develop for. 
> 
> I doubt that the benefits of turning gnuplot
> into a programming environment outweigh the
> costs. I also think that this will lead gnuplot 
> into a competition with more established
> "scientific workbenches" (R, NumPy/SciPy,
> Octave) that it will lose. 
> 
> I think gnuplot would be better off to stay
> a plotting tool, and not try to become a
> programming environment. I suggest that we 
> should evaluate each such feature very 
> carefully before accepting it into gnuplot -
> and be ready to reject certain ideas (and/or
> look for alternatives that do not require
> changes to the gnuplot main program).
> 
> I am concerned about "creeping featurism",
> where each new "simple/useful" feature drags 
> in bigger and bigger features. (Example: gnuplot 
> now has loops. It is only natural that it should
> have an iterable data structure. Once it has
> that, it will be natural to ask for vector
> operations and indexing magic - and for 
> matrix computations. At that point there will
> be demand for local variables and proper blocks,
> which will lead to subroutines. And so on.)
> 
> I don't think anybody INTENDS to turn gnuplot
> into a matlab competitor, but that - in fact -
> makes it worse: because there is no thought
> given to design upfront, stuff is just being
> kludged on. (The result will not be pretty.)
> 
> There are only ways to stop this:
> - to collectively say "No"
> - to collectively say "Yes", discuss the
>   direction, and then accept features if
>   they fit with the agreed upon direction.
> 
> One more thing: scientists are not language
> designers, and therefore tend to underestimate
> the difficulties in designing a consistent
> and maintainable language.

I'm not sure history bears you out there.

Some of the most successful computer languages,
starting with Fortran, were designed by scientists.

Conversely some of the most unmaintainable languages
(I'm looking at you, Python) were created by people or
committees that fancied themselves as language designers.

 EAM

> 
> In doing research for my book on
> open-source tools for data analysis, I have
> looked at a wide variety of "scientific"
> programming environments, and got the sense
> that most (if not all) of them struggle under
> their own weight: they were started, without
> much thought, design, or knowledge, by 
> scientists who "just wanted to do some 
> calculations", but who did not have much
> knowledge or experience in the theory of
> languages and data structures, who did not
> understand large-scale programming, and who -
> more than anything - underestimated what they 
> were in for. All these programming environments 
> (no names, to protect the guilty) are now big,
> overgrown, and unstructured monsters. I 
> don't want to see gnuplot go the same way.
> 
> What do others think?
> 
> Best,
> 
> 		Ph.
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta