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

[Juan Pablo Carbajal]

Hi all,

On Mon, Aug 21, 2017 at 8:10 AM, Julien Bect
<address@hidden> wrote:
> 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.
>>

I agree with all the points but there is more considerations to throw in.
In particular, since this is a personal decision, having
M-compatibility or not in a package is up to the developers.
Also, if the package offers something that is not so easily found in
proprietary software, then it is worth considering (from the ethical
point of view) to force it t run only on free software by using
octave's pidgin.

>> 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.
Well, I would suggest that you detect whether it is run on Matlab or
Octave and load the statistics package accordingly.
Again, if stk offers something beyond what's found in prop. software,
you better do this to seduce users to move to free software and get
the extra cool functionalities.

>
> Just my two cents.
>