Re: Should gnuplot become a programming environment?

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

On Thursday, 13 November, 2014 08:15:01 Philipp K. Janert wrote:
> 
> What bothers me about those "programming features"
> is that they WILL start a paradigm shift in how
> gnuplot is used, and in what ways it will be 
> developed. Today, you can "ignore" them. But my
> prediction is that before too long, you won't
> anymore, because that's simply "how it's done".

You can still ignore them, even if many other people use them.

> Programming features have a tendency to beget more
> programming features. Look at almost any language
> out there - they all keep growing (C being the 
> exception).
> 
> The horror story here is Python - every single 
> "clever" feature they introduced turned out to
> have edge cases that needed even more, even
> "cleverer" features to handle them properly.

The horror arises largely because Python development assigns
no worth to backward compatibility.  This is exacerbated by the
poorly-chosen guiding principle that there should be only one
way to do any given task.  Together these [mis]features of the
language act to impose a short life expectancy on working code
and carefully developed scripts.

Fortunately gnuplot development has and will continue to 
proceed under the very different guiding principle that 
backward-compatibility is a primary virtue.  If you've been
paying attention, you'll recall that much of the tuning that
has gone into version 5 release candidates -rc2 and -rc3 has
been to restore backwards compatibility wherever the introduction
of new features damaged it.

> Individual arguments aside, I'd like to raise
> the strategic question: does gnuplot want to
> catch up to matlab, R, numpy - is that the right
> direction? 

matlab  -  I've never used it, so no opinion

numpy  -  in a sense, yes.  The value I see in numpy is that it tries to
make up for Python's own failings as a computational language by
making it easy to call into an external numerical library written in a more
suitable language.  The addition of the "import" capability in gnuplot
version 5 is similar, and if it can be further improved, I'm in favor.

R  -  I don't think "catch up" is the right way to view it.
R and gnuplot have complementary strengths.
I'd be interested in discussion about whether there are missing 
pieces on either side (R or gnuplot) that hinder making optimal
use of both tools together.

	Ethan