Would MATLAB benifit from scrapping backwards compatibility

The MATLAB language has been under active development for around 30 years. While I don't have any 30 year old code, I do have 20 year old code can that can run without modification on the newest versions. The newest versions, however, offer lots of new features. Sometimes I think the new features are not as well integrated into MATLAB as they can be to preserve backwards compatibility.

I am curious if MATLAB would benefit from a one time scraping of backwards compatibility so that some of the low level awkwardness can be dealt with?

As for things that would break backwards compatibility, but might be useful, I can think of 3 categories.

There are things that would help me as an end user. For example, the use of global namespaces causes me (and I believe others) headaches with accidental overloads of functions. If the name spaces were local, questions that are answered by requests for the output of "which" would be reduced. The support of extended character sets is pretty limited also.

There are things that would make writing and maintaining code, both mine and TMW, easier. Right now I can think of 4 ways that MATLAB plays a sound: the playsnd mex (called by sound), asyncio (called by audioplayer), the winsound driver of the data acquisition toolbox, the DSP toolbox sound drivers. I cannot think of a reason why you would want 4 different drivers. Another example is that there are two different ways to implement classes. Does TMW really need to continue supporting the ability to run MATLAB without JAVA?

There are also things that I think make optimizing MATLAB, from a perspective of TMW, difficult. I think that dynamic memory allocation and and dynamic typing of MATLAB makes implementing the JIT problematic. If MATLAB additional requirements were added to allocation and typing rules, I would think MATLAB might become much faster. This wasn't as much of a problem when everything was a double and there was no JIT and loops were painful.

[Walter Roberson]

It might help to list some of the backwards compatibilities that might be holding up future development.

[Cedric]

It's not completely related, but I would love to have MATLAB functions treated as objects, with methods that could allow us choosing some version of them or sending directives to the JIT engine (which could include enforcing backward compatibility). For example assuming two versions of MATLAB functions sets..

 squeeze(M)              % Default set = most recent = v2.
 squeeze.v1(M)           % Use v1 for backward compat.
 squeeze.noArgCheck(M)   % Disable the internal call to ISMATRIX.

 ..or even better imho
 squeeze(M).jit('argcheck', false, 'version', 1)

I'm not sure what would be the best syntax though. In any case, such a mechanism would give users options for managing backward compatibility.

A lighter solution could be to have some "compiler directives"-like lines at the top of M-files enforcing backward compatibility.

Answer 1

[Walter Roberson]

The feature that comes to mind that I currently feel is most deserving of being scrapped, is assignin() and evalin() in their current forms.

There circumstances under which working with workspaces is warranted: some of those circumstances could be handled by enhancing functions() to obtain workspace access, perhaps with a new 'parent' option to be able to climb the stack.

Assigning into the stack should not be common, and should perhaps be reserved for a new user defined "operators" feature, such as providing a mechanism to allow people to create an "++" operator.

[Daniel Shub]

My guess is that there might be some good JIT speedups if you could be assured that the workspace wasn't going to get screwed up with an evalin.

Answer 2

[Jan]

I had a lot of troubles with broken backward compatibility already. In this forums I've partially mentioned:

• lost of VaxD-format in fopen
• changed behavior of strncmp when the arguments are shorter than the limit
• unordered and therefore random replies of the multi-threaded sum
• change of the order in the replies of unique and other set functions
• deprecated status of dataread and strmatch
• case-sensitivity under Windows
• uitable is not really powerful yet, but it even lost the output of the java handle
• Old MEX interfaces declare mxCreateScalarDouble, new interfaces mxCreateDoubleScalar, but there is no documented flag, which allows to identify the MEX interface version by the preprocessor
• the tools for creating random numbers got more and more complicated, while the intuitive commands like rand('seed', s) are deprecated

Such differences makes it extremely hard to prove, that a medium sized program, e.g. 200'000 lines of code, produces the same results in R2011b and 6.5, but for a scientific work it is obligatory, that results can be reproduced for 10 years.

My conclusion: Matlab's degree of backward compatibility is on the hard lower limit already.

The JIT profits automatically already, when neither eval(in) nor assignin() create variables dynamically, as well as from not changing the class of variables. Or the other way around: As soon as there is are entries in the lookup table of dynamically created variables, the JIT gets inactive (or at least less powerful).