Why I will no longer support Matlab

Written 2015.

I was a Matlab supporter for the past 15 years. I wrote and re-wrote four textbooks built around Matlab toolboxes. The toolboxes represent around 100,000 lines of code. So, a significant effort and time expended.

My concern is the student whom I strive to familiarize with programming. He or she typically does not enjoy sitting down with a cup of coffee to hammer out some code just because they like the activity. It is a struggle sometimes to convince those kids that programming is a worthwhile skill...

For programming engineering computations Matlab used to have an advantage over almost any alternative language: It was very obvious, with few side effects, and very few surprises. The code a+b meant add two matrices (or a matrix and a number: an unfortunate historical artifact). Now a+b for two vectors a and b can mean three different things. Consider two column vectors. Then the following three operations lead to three different results: Regular addition of vectors 

>> a+b

ans =

    1.4471
    1.0033
    0.4055
    1.4603
Addition of vectors with broadcasting (implicit expansion) 
>> a'+b

ans =

    1.4471 1.5382 0.7593 1.5457
    0.9123 1.0033 0.2245 1.0109
    1.0932 1.1843 0.4055 1.1919
    1.3616 1.4527 0.6739 1.4603
And another addition of vectors with broadcasting 
>> a+b'

ans =

    1.4471 0.9123 1.0932 1.3616
    1.5382 1.0033 1.1843 1.4527
    0.7593 0.2245 0.4055 0.6739
    1.5457 1.0109 1.1919 1.4603

Here we were given clues with the transpose, but take it away and the intent of a+b is suddenly far from clear, since either of the two vectors can be a column vector or a row vector. Pass the sum to a function and you may never find out that the result of the operation was wrong.

To a non-programmer kid, the simpler the language, the more explicit the intent, and the fewer the surprises, the better. Matlab used to be like this. With 2016b The Mathworks (TMW) erased this advantage!

Release 2016b introduced the so-called implicit expansion. Prior to this release incompatible matrices could not be operated upon. The result would've been an error. This provided valuable error checking, and hence many programmers did not think it necessary to implement their own checks that the arguments of the functions had the right shape. The assumption was that Matlab was sufficiently stable so that this behavior could be relied upon. Implicit expansion allows operations on incompatible matrices via broadcasting, as shown above. Therefore the intent of the line of code which used to mean that two compatible matrices 

>> a+b
were being added together is no longer clear: it may mean different things depending on the shape of the operands. This is a clear backward-compatibility break. The new behavior makes debugging harder and the intent of the code is obscured.

Compare with the break in backward compatibility between python 2 and 3. Here is what the developers did: They bent over backwards to make sure they heard their customers' (programmers') opinions. It wasn't just "because Guido said so", here is your new release and if you don't like it, too bad!

From https://www.python.org/dev/peps/pep-0387/:

It's a fact: design mistakes happen. Thus it is important to be able to change APIs or remove misguided features. This is accomplished through a gradual process over several releases:

  1. Discuss the change. Depending on the size of the incompatibility, this could be on the bug tracker, python-dev, python-list, or the appropriate SIG. A PEP or similar document may be written. Hopefully users of the affected API will pipe up to comment.
  2. Add a warning [2] . If behavior is changing, the API may gain a new function or method to perform the new behavior; old usage should raise the warning. If an API is being removed, simply warn whenever it is entered. DeprecationWarning is the usual warning category to use, but PendingDeprecationWarning may be used in special cases were the old and new versions of the API will coexist for many releases.
  3. Wait for a release of whichever branch contains the warning.
  4. See if there's any feedback. Users not involved in the original discussions may comment now after seeing the warning. Perhaps reconsider.
  5. The behavior change or feature removal may now be made default or permanent in the next release. Remove the old version and warning.

Compare this with the approach of TMW: the break in backward compatibility was not even mentioned in the documentation when I installed 2016b! And now they are stonewalling instead of engaging in a meaningful discussion.

Let me point out that all programmers who wrote a significant number of lines of Matlab co-own the language in a way. So for TMW to release the s/w with a major backward compatibility break and to turn a deaf ear to those programmers who are unhappy with their investment in the language having been degraded, is not right.

I no longer think Matlab has an edge over its competitors in the programming education of college engineering students. The new release, R2016b, represents a significant erosion of the prior advantage that Matlab used to have due to its simplicity and obviousness. Matlab used to be perceived as relatively stable language. This seems to be drastically changing.

Since I no longer feel Matlab is the best language for my students, I will no longer support Matlab. I will not support the toolboxes that I wrote, and I will not maintain the textbooks.

Where do you build your following as a programming-environment company? I would say the college classroom is a big part of the answer. TMW is underestimating the problems that their current course of actions will produce at their own peril.

Views: web counter