MATLAB Answers

Walter Roberson

What parts of MATLAB would you not miss?

Asked by Walter Roberson
on 21 Feb 2011
Latest activity Commented on by per isakson
on 7 Apr 2014

Are there parts of MATLAB that could disappear as far as you were concerned, things you don't need or which were "bad ideas" or which cause more trouble than they are worth in your experience?

One suggestion per answer please, so we can see how other people feel about the same matters.



15 Answers

Answer by Jan Simon
on 21 Feb 2011

The non-functional form of commands like "load file.mat" instead of "load('file.mat')".


I sometimes like using the non-functional form when doing things from the command line. If I need to search the doc, I'd rather type:

docsearch functional form


docsearch('functional form')

I'm still faster at typing things that don't require using the shift key.

@Jiro: You got me: I admit I type "help plot" also. But the non-functional form is (and will be) still inconsistent. E.g. "fullfile * *" is ok in Matlab 2009a, but "fullfile * p" is not - but it was in earlier versions.

hm, I would prefer having this around for 'cd' and 'dir'.

Answer by Sean
on 21 Feb 2011

I wish the MathWorks would not "dumb things down". This is especially apparent in the GUI development tools, but there are other examples also. Why are the powerful capabilities of the underlying java GUI objects hidden from the user? There is a whole market for utilizing this capability that drives websites like People want/need to be able to access this functionality. Thanks to Yair Altman, I have been able to include some of the functionality that I need. But it is so painful (and questionable for future compatibility), the question of whether to use Matlab at all is difficult to justify with my peers.

I suspect that one of the concerns here is the complexity of supporting advanced functionality. I think that sometimes the need to support the basic user overshadows the needs of people who want everything a GUI has to offer. Most unfortunate.


Answer by Jan Simon
on 21 Feb 2011

I personally would not miss GUIDE. Because I have to create programs which are compatible to Matlab 6.5, the compatibility limitations of GUIDE are too strong.

I use GUIDE sometimes to create the layout of a GUI. But then I create it programatically.


I've a lot experiences with creating GUIs programmatically now and I've a set of templates for standard tasks like: Open a dialog, load prefs, save prefs and windows position in the DeleteFcn. Therefore I will not use GUIDE even if it is improved. But most of all: For me, "improved" would mean a backward compatibility until Matlab 6.5... But this would exclude UITREE and UITAB from modern GUIs, what would not user-firendly. Therefore I've inserted "personally" in my answer - I do not expect that this opinion matchs the majority of Matlab users.

GUIDE might be acceptable if it emitted code that was position-independent and auto-resizing by default. Something usable as a starting point for developing further code rather than something best suited for Bad Coding Practices Hall of Fame.

GUIDE should rather just generate programmatic UI code.

Answer by Paulo Silva
on 21 Feb 2011


I would never miss that function because matlab is always open on my laptop :)

  1 Comment

Even when you're installing a new version?

Answer by Aurelien Queffurust on 24 Jun 2011

I never used the "Start" Button which provides access to tools, demos, shortcuts, and documentation. I would be very curious to know if you are using it !!

I already asked this question on the "Mike on the MATLAB Desktop" blog: MATLAB User Survey (and maybe a free polo shirt) after answering their survey.


I never use that either. Maybe it's designed for people who work on Windows machines, use the tools a lot or aren't old MATLAB users who are set in their ways.

I use it frequently to get to demos for various toolboxes. Sorry to rain on the parade...

There's a "Start" button?

Answer by Walter Roberson
on 21 Feb 2011

For me, probably the easiest to identify would be the Java interface. Yep, I know the UI is implemented in Java, and that lots of tricky things can be done to extend Matlab functionality using the (ever-changing) Java interface, but personally I'd be happier if there was a clean break between the graphics and UI model and the underlying implementation so that the graphics could be replaced (with something faster and more flexible) without changing the programs. Diddling with things one can reach off of the Java frame is a hack unless you are going to whole-heartedly embrace Java as part of the programming model rather than as "private information" that the tricksters can manipulate.

Go ahead, try to convince me that Java is a big Win for Matlab. Who knows, maybe you will succeed.


Correct! And the Java interface is still less readable as the old Windows methods in Matlab 6.5: E.g. in an edit UICONTROL with Arial in 10 pt the characters start directly at the left margin without a single pixel border. Ugly.
And GETFRAME captures the all elements of a figure after PAUSE(0.02) in 99.99% of the cases, so PAUSE(0.03) is "safer" in Matlab 2009a (and higher?). Strange.

I don't think I can convince you (but maybe others can), but what about using java in MATLAB for non-graphics related stuff. There are some nice network utilities that's rather hard to do with regular MATLAB. Here's an example I found in one of my files:

% Find out all the IP addresses for this computer
myComputer =;
allMyIps =;

@Jiro: You are right. I limit my criticism about java to the graphics and GUI related functions.

Answer by Jan Simon
on 21 Feb 2011

Case-insensitive command recognition.

When I'm working on Linux, I have to consider the correct upper/lower case. The ability to call a command with a deviating case is a source of bugs and not a valuable freedom.

I appreciate, that case conflicts create a warning in modern Matlab versions.


No. Just no. That some operative systems do not differentiate between upper/lower case might be handy, but to (suddenly) not do this in those OSes that do recognise the difference would be far worse.

Mycommand = @(x) x.^2;
myCommand = @(x) x.^3;

Now if the user asks for


then which should be invoked?

You can't get rid of case sensitivity for "commands" without getting rid of case sensitivity for variable names.

@Walter: I assume a missunderstanding.
If Mycommand and myCommand is defined, mycommand should and does fail. But currently "MEAN(1:2)" runs under Windows, but fails under Linux (is this still true with modern Matlab versions?). Since 2008b (or earlier) at least a warning appears on Windows when "MEAN" is called the first time. I think the inconsistent behaviour between Windows and Linux is not useful and a source of bugs. Fortunately TMW agrees and calling a function with the wrong case will become an error.

Answer by Jan Simon
on 21 Feb 2011

It would be helpful, if a modification of the window icon will not conflicts with the license conditions.

When I open 120 Matlab figures, it can be helpful to group them optically in the popup-menu of the Windows-taskbar, e.g. by different colors in the icon.


Answer by Wes
on 24 Jun 2011

I think we could do without one curious perversion of functions: a function where you don't pass a variable's value, but you pass the name of the variable instead! I'm lookin' at you, save():

save( 'foo.mat', 'x' );


They could easily implement a version that accepts variables in the usual manner. I could do it myself using inputname.

I wonder if they're worried about people doing stuff like save('foo.mat',@tan(x))?

People *do* construct (compute) the name of the variable to save, and thus need to be able to pass a variable that contains a string but that variable is not itself the thing to be saved.

Answer by Krishna Kumar
on 24 Jun 2011

My pick would be obsolete tools like gatool, which can now be accessed via optimtool.


Answer by Jan Simon
on 21 Feb 2011


FIND(STRNCMP) is much faster.


Your wish has been granted! As seen in the DOC, "strmatch" will be removed in a future release.

@Jiro: Fine. Fine? Why not just implementing it more efficiently?! You can be sure, that there will be a fast STRMATCH in the FEX as soon as TMW removes the original function.

Answer by Walter Roberson
on 21 Feb 2011

That the colon operator and linspace produce slightly different answers. I know, I know, there reasons involving round-off when people innocently use step sizes such as 0.001, but 0:.01:100 not being the same as linspace(0,100,101) or (0:100)./100 {which come out the same as each other} is just asking for trouble.

Although it might mess the semantic model up a bit, it would not fluster me if the step size in a colon operator could be expressed as a rational whose rationality was recognized and used to create more precise steps -- e.g., 0:3/100:1 being interpreted as 3.*(0:100)./100.


@Walter: I'm not sure this is an answer for this question. What exactly would you not miss if it went away? Colon operator?

I think this answer is more for this question:

I wouldn't miss colon being implemented through cumulative sums when it could be implemented by begin + (idx - 1) * step, which would at least _reduce_ the errors.

But in particular I wouldn't miss the countless questions that the current behaviour leads to. The current implementation is a mis-feature IMHO.

Answer by Jan Simon
on 21 Feb 2011

I never use multi-row CHAR arrays.


This is one that I do actually use, and which I think has a lot of internal uses. For example, dec2bin() applied to a vector produces a multi-row char array.

I create formatted output by horzcat'ing together blocks of text. Although that sometimes has relationships to things that could be done through appropriate sprintf(), the char array approach is faster -- and there is no obvious mechanism to cellstr() an sprintf() output (regex split is too much overhead for such a thing.)

I'm using a modified version of DEC2BIN, which assigns UINT8 arrays instead of a CHAR. This uses the half memory and the export to a Mex is more direct.

I use them quite often... mostly for UI related things

Answer by Wes
on 24 Jun 2011

We do not need deterministic finalisation for reference types, especially when they form part of a reference cycle. More simply put, we don't need MATLAB to go to great lengths to guarantee it will call the delete method on (and free the memory of) objects the very instant that they are no longer used.

The fact that MATLAB has this feature is apparently the cause of performance-sapping overhead. Case in point: it takes O(n) time to get or set a single element in a cell array if that array is a property of a reference-typed object. Try building an O(1) collection class with that restriction!

I'm not aware of any other runtime with managed memory that wastes time giving this guarantee. CPython uses reference-counting similar to MATLAB, but doesn't have deterministic finalisation for objects in a cycle. Java and .NET of course don't have deterministic finalisation for any objects!

The MATLAB language really would be better off though with support for a proper finally block instead.


Answer by Wes
on 24 Jun 2011

Class events. Does anybody actually use these?

The model for these in MATLAB is a little strange. For instance, listeners keep a reference to the object they are listening to, thereby preventing that object being destroyed. The reference is unnecessary given that events are a 'push' mechanism.

This makes the ObjectBeingDestroyed event defined on handle useless, becuase as soon as you listen for it, you prevent the event from ever firing! (Barring evil explicit calls to delete.) It's the ol' watched kettle that never boils.

  1 Comment

I use them and don't want to be without. However, I cannot say whether the implementation in Matlab is the best.

Join the 15-year community celebration.

Play games and win prizes!

Learn more
Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

MATLAB Academy

New to MATLAB?

Learn MATLAB today!