Re: OF packages using Matlab-compatible code (was "pending dataframe-1.2.0 release")

[Julien Bect]

Le 21/08/2017 à 00:49, Colin Macdonald a écrit :
> On 2017-08-20 08:32 AM, Oliver Heimlich wrote:
> > IMO, a package should be allowed to maintain Matlab compatibility.  In
> > the end this can only be beneficial to the end user at a low cost.
>
> I agree.  In addition to Doctest which was already mentioned, Symbolic 
> also tries to use Matlab-compatible syntax.
>
> 1.  Having people run it on Matlab has caught some bugs that I 
> otherwise might not have found.
>
> 2.  We might uncover and fix incompatibilities in core Octave. This 
> has happened with Doctest (the implementation of "evalc" for example).
>
> 3.  Its not inconceivable that a Matlab user might choose an 
> Octave-Forge package and thus be drawn towards software freedom.
>
> The situation is perhaps analogous to porting Free Software to 
> proprietary operating systems.  I think this is widely viewed as an 
> ethically-sound activity (I thought there was a better reference but 
> for now I found a list of [Free Software for Windows, hosted by 
> FSF](https://www.gnu.org/software/for-windows.en.html)).
>
> Overall, I think this is a decision best left to package authors and 
> maintainers.

I agree with Oliver and Colin's arguments.  The stk package is another 
example of a Matlab-Octave compatible package.

Keeping this compatibility undoubtedly makes it useful to a much larger 
group of potential users, including (as Colin observed) Matlab users 
that are later brought to use Octave for this reason.

I can also testify that maintaining this compatibility (over a 
wide-enough range of Octave and Matlab releases) lead me to report, and 
sometimes fix, many compatiblity problems in core Octave.

One more observation: the fact that most Octave Forge packages, and in 
particular "community" packages, are not MO-compatible, means that I can 
not have any of them as a dependency for the stk package.  As an 
example: I would probably use the OF statistics package as a dependency 
for the stk package if it were MO-compatible.  IConversely, it it were 
MO-compatible, and therefore usable as a dependency for the stk package, 
I would most certainly contribute to it and also indirectly bring new 
users to the statistics package.

Just my two cents.