<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: R2011b Command Window Formatting Improvements</title>
	<atom:link href="http://blogs.mathworks.com/community/2011/10/17/r2011b-command-window-formatting-improvements/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.mathworks.com/community/2011/10/17/r2011b-command-window-formatting-improvements/</link>
	<description>News from the intersection of MATLAB, Community, and the web.</description>
	<lastBuildDate>Wed, 22 May 2013 17:07:59 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Yair Altman</title>
		<link>http://blogs.mathworks.com/community/2011/10/17/r2011b-command-window-formatting-improvements/#comment-8165</link>
		<dc:creator>Yair Altman</dc:creator>
		<pubDate>Sat, 29 Oct 2011 17:16:57 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.mathworks.com/desktop/2011/10/17/r2011b-command-window-formatting-improvements/#comment-8165</guid>
		<description><![CDATA[Dear @Mike,

MathWorks management may indeed place a high premium on backward compatibility, but instances such as this and the fact that changes that originate from &lt;a href=&quot;http://www.mathworks.com/matlabcentral/answers/17089-changes-in-strncmp&quot; rel=&quot;nofollow&quot;&gt;internally-discovered bug fixes are not reported&lt;/a&gt; (by a strange coincidence this was recently discovered by chance by Jan and confirmed by Mathworker Andreas Goser), lead me to believe that perhaps the need for strong backward compatibility has not permeated throughout the entire organization to the level that you, me and TMW management would have liked. 

Please understand that to developers of mission-critical (possibly human-life-related) software, this is an extremely sensitive issue. It is a matter of trust to a large degree, and such cases may break this trust.

Perhaps the new generation of developers need some reminding about the basic fact that software on which airplane and car and building designers rely, has to be 100.000000% reliable and backward compatible, at least in the core documented functionality. This is not a startup and is not a place for experiments.

It is also in TMW&#039;s commercial interest, because if your clients cannot be certain of backward compatibility, then fewer people will choose to upgrade. In my particular case I have once advised a client not to upgrade, and this is a real pity. 

Matlab is an excellent product, developed by top-rate engineers. I do not wish to disparage the developers&#039; efforts. But sometimes engineers (me included) need to be reminded that 100%-reliable and backward-compatible software is better than software which is less reliable and perhaps not fully backward compatible, but has a few more &quot;cool&quot; features. It is entirely natural for engineers to race ahead with new functionality, so this needs constant oversight.

Please accept this comment in the constructive spirit in which it is meant.]]></description>
		<content:encoded><![CDATA[<p>Dear @Mike,</p>
<p>MathWorks management may indeed place a high premium on backward compatibility, but instances such as this and the fact that changes that originate from <a href="http://www.mathworks.com/matlabcentral/answers/17089-changes-in-strncmp" rel="nofollow">internally-discovered bug fixes are not reported</a> (by a strange coincidence this was recently discovered by chance by Jan and confirmed by Mathworker Andreas Goser), lead me to believe that perhaps the need for strong backward compatibility has not permeated throughout the entire organization to the level that you, me and TMW management would have liked. </p>
<p>Please understand that to developers of mission-critical (possibly human-life-related) software, this is an extremely sensitive issue. It is a matter of trust to a large degree, and such cases may break this trust.</p>
<p>Perhaps the new generation of developers need some reminding about the basic fact that software on which airplane and car and building designers rely, has to be 100.000000% reliable and backward compatible, at least in the core documented functionality. This is not a startup and is not a place for experiments.</p>
<p>It is also in TMW&#8217;s commercial interest, because if your clients cannot be certain of backward compatibility, then fewer people will choose to upgrade. In my particular case I have once advised a client not to upgrade, and this is a real pity. </p>
<p>Matlab is an excellent product, developed by top-rate engineers. I do not wish to disparage the developers&#8217; efforts. But sometimes engineers (me included) need to be reminded that 100%-reliable and backward-compatible software is better than software which is less reliable and perhaps not fully backward compatible, but has a few more &#8220;cool&#8221; features. It is entirely natural for engineers to race ahead with new functionality, so this needs constant oversight.</p>
<p>Please accept this comment in the constructive spirit in which it is meant.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike</title>
		<link>http://blogs.mathworks.com/community/2011/10/17/r2011b-command-window-formatting-improvements/#comment-8160</link>
		<dc:creator>Mike</dc:creator>
		<pubDate>Wed, 26 Oct 2011 12:24:09 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.mathworks.com/desktop/2011/10/17/r2011b-command-window-formatting-improvements/#comment-8160</guid>
		<description><![CDATA[@Matt,
I was not at the review meeting for the change to capitalization, but I bet it has to do with readability and consistency.]]></description>
		<content:encoded><![CDATA[<p>@Matt,<br />
I was not at the review meeting for the change to capitalization, but I bet it has to do with readability and consistency.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike</title>
		<link>http://blogs.mathworks.com/community/2011/10/17/r2011b-command-window-formatting-improvements/#comment-8159</link>
		<dc:creator>Mike</dc:creator>
		<pubDate>Wed, 26 Oct 2011 12:23:28 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.mathworks.com/desktop/2011/10/17/r2011b-command-window-formatting-improvements/#comment-8159</guid>
		<description><![CDATA[@Yair &amp; @Jan,
 Those are good points. I don&#039;t have any comments as to why that change was made, but I will see if I can get one from the help team. 

As for the backwards compatibility, I&#039;d have to strongly argue that backwards compatibility is at the forefront of every new feature we design, and is often the reason why some features take a long time to release and why we don&#039;t document other capabilities. Although this is a change in behavior, it&#039;s not an incompatibility in the sense that you can&#039;t get to the MATLAB-file help. But I do empathize with your feelings regarding the documentation browser. Also, this is my personal opinion and not an official one.]]></description>
		<content:encoded><![CDATA[<p>@Yair &#038; @Jan,<br />
 Those are good points. I don&#8217;t have any comments as to why that change was made, but I will see if I can get one from the help team. </p>
<p>As for the backwards compatibility, I&#8217;d have to strongly argue that backwards compatibility is at the forefront of every new feature we design, and is often the reason why some features take a long time to release and why we don&#8217;t document other capabilities. Although this is a change in behavior, it&#8217;s not an incompatibility in the sense that you can&#8217;t get to the MATLAB-file help. But I do empathize with your feelings regarding the documentation browser. Also, this is my personal opinion and not an official one.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jan Simon</title>
		<link>http://blogs.mathworks.com/community/2011/10/17/r2011b-command-window-formatting-improvements/#comment-8155</link>
		<dc:creator>Jan Simon</dc:creator>
		<pubDate>Wed, 26 Oct 2011 11:08:11 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.mathworks.com/desktop/2011/10/17/r2011b-command-window-formatting-improvements/#comment-8155</guid>
		<description><![CDATA[Dear Yair, it is not just you. I&#039;ve opened the help browser unintentionally dozens of times now. Especially when I&#039;m working with different releases at the same time the confusion level high and this new feature reduces the usability.
When an error message appears in the command line, I never have the need to open the help browser. I have to open the editor to look at the line at first. Afterwards I will not go back to the command window to open the help, but use the context menu after selecting the command in the editor.

Therefore I&#039;d prefer the former style or at least the &quot;Footprint proportional to importance&quot; rule:
Error using &lt;a&gt;myfun at line 3&lt;/a&gt;  &#160; [&lt;a&gt;?&lt;/a&gt;]
Thanks, Jan]]></description>
		<content:encoded><![CDATA[<p>Dear Yair, it is not just you. I&#8217;ve opened the help browser unintentionally dozens of times now. Especially when I&#8217;m working with different releases at the same time the confusion level high and this new feature reduces the usability.<br />
When an error message appears in the command line, I never have the need to open the help browser. I have to open the editor to look at the line at first. Afterwards I will not go back to the command window to open the help, but use the context menu after selecting the command in the editor.</p>
<p>Therefore I&#8217;d prefer the former style or at least the &#8220;Footprint proportional to importance&#8221; rule:<br />
Error using <a>myfun at line 3</a>  &nbsp; [<a>?</a>]<br />
Thanks, Jan</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matt Fig</title>
		<link>http://blogs.mathworks.com/community/2011/10/17/r2011b-command-window-formatting-improvements/#comment-8149</link>
		<dc:creator>Matt Fig</dc:creator>
		<pubDate>Tue, 25 Oct 2011 19:19:46 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.mathworks.com/desktop/2011/10/17/r2011b-command-window-formatting-improvements/#comment-8149</guid>
		<description><![CDATA[Mike, when did the command line help stop showing functions as capitalized?  What was the rational for this change?  

Thanks.]]></description>
		<content:encoded><![CDATA[<p>Mike, when did the command line help stop showing functions as capitalized?  What was the rational for this change?  </p>
<p>Thanks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Yair Altman</title>
		<link>http://blogs.mathworks.com/community/2011/10/17/r2011b-command-window-formatting-improvements/#comment-8146</link>
		<dc:creator>Yair Altman</dc:creator>
		<pubDate>Sun, 23 Oct 2011 22:27:51 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.mathworks.com/desktop/2011/10/17/r2011b-command-window-formatting-improvements/#comment-8146</guid>
		<description><![CDATA[Maybe it&#039;s just me, but I keep forgetting that the function name now links to the docpage browser rather than to the editable file, and I keep cursing whenever I click (because the help browser takes so long to load...

If I were the designer of this new feature, I would keep backward compatibility by keeping the old link and simply adding new links to the help and doc pages. Something like this:

Error using &lt;a href=&quot;&quot; rel=&quot;nofollow&quot;&gt;myfun at line 3&lt;/a&gt; (&lt;a href=&quot;&quot; rel=&quot;nofollow&quot;&gt;help&lt;/a&gt;, &lt;a href=&quot;&quot; rel=&quot;nofollow&quot;&gt;doc&lt;/a&gt;)

Although this is really a minor issue, I think it is important to instill the need for backward compatibility to all developers. It starts with small stuff like this, and then one day we find that functions change their behavior and/or interface, breaking years-old code. Ensuring backward compatibility as a core value needs to be part of the corporate culture. 

Sorry if I overreact a bit - after all, this &lt;i&gt;is&lt;/i&gt; a useful new feature.]]></description>
		<content:encoded><![CDATA[<p>Maybe it&#8217;s just me, but I keep forgetting that the function name now links to the docpage browser rather than to the editable file, and I keep cursing whenever I click (because the help browser takes so long to load&#8230;</p>
<p>If I were the designer of this new feature, I would keep backward compatibility by keeping the old link and simply adding new links to the help and doc pages. Something like this:</p>
<p>Error using <a href="" rel="nofollow">myfun at line 3</a> (<a href="" rel="nofollow">help</a>, <a href="" rel="nofollow">doc</a>)</p>
<p>Although this is really a minor issue, I think it is important to instill the need for backward compatibility to all developers. It starts with small stuff like this, and then one day we find that functions change their behavior and/or interface, breaking years-old code. Ensuring backward compatibility as a core value needs to be part of the corporate culture. </p>
<p>Sorry if I overreact a bit &#8211; after all, this <i>is</i> a useful new feature.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
