<?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: Co-Developing Killer Apps</title>
	<atom:link href="http://chipdesignmag.com/lpd/sperling/2009/11/12/co-developing-killer-apps/feed/" rel="self" type="application/rss+xml" />
	<link>http://chipdesignmag.com/lpd/sperling/2009/11/12/co-developing-killer-apps/</link>
	<description>Making Semiconductor Architectures More Efficient</description>
	<lastBuildDate>Mon, 21 May 2012 22:00:50 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=</generator>
	<item>
		<title>By: Herb</title>
		<link>http://chipdesignmag.com/lpd/sperling/2009/11/12/co-developing-killer-apps/comment-page-1/#comment-110</link>
		<dc:creator>Herb</dc:creator>
		<pubDate>Fri, 11 Dec 2009 00:09:36 +0000</pubDate>
		<guid isPermaLink="false">http://chipdesignmag.com/lpd/sperling/?p=142#comment-110</guid>
		<description>Here&#039;s the real problem: 

For at least four decades, following Moore&#039;s law, computer manufacturers have made their machines exponentially faster with more memory, since it&#039;s about the only way to differentiate a product that has so little to do with the real world that the only way to tell it&#039;s running is to check the fan or power light.

Programmers don&#039;t make code smaller unless it&#039;s too big, and they don&#039;t make it faster unless it&#039;s too slow. It&#039;s simple economics. The result is forty years of exponentially increasingly bad code. Even bright, well trained, experienced programmers find themselves swimming in septic tanks trying to glue the refuse together with spit, rather than productively providing software solutions, as well as why the most successful OS vendor has to update my software most every Tuesday.

It&#039;s the most significant factor in the state of the industry, and it certainly helps to explain why programmers have no idea what parts of the circuitry are in use.

I only blame myself. I should have stopped the process somehow. I feel like Charlton Heston in &quot;The Towering Inferno&quot; looking up at the smoldering behemoth and stating &quot;We never should have built them this tall...&quot; On the bright side, there&#039;s usually no software in tube-based guitar amps.</description>
		<content:encoded><![CDATA[<p>Here&#8217;s the real problem: </p>
<p>For at least four decades, following Moore&#8217;s law, computer manufacturers have made their machines exponentially faster with more memory, since it&#8217;s about the only way to differentiate a product that has so little to do with the real world that the only way to tell it&#8217;s running is to check the fan or power light.</p>
<p>Programmers don&#8217;t make code smaller unless it&#8217;s too big, and they don&#8217;t make it faster unless it&#8217;s too slow. It&#8217;s simple economics. The result is forty years of exponentially increasingly bad code. Even bright, well trained, experienced programmers find themselves swimming in septic tanks trying to glue the refuse together with spit, rather than productively providing software solutions, as well as why the most successful OS vendor has to update my software most every Tuesday.</p>
<p>It&#8217;s the most significant factor in the state of the industry, and it certainly helps to explain why programmers have no idea what parts of the circuitry are in use.</p>
<p>I only blame myself. I should have stopped the process somehow. I feel like Charlton Heston in &#8220;The Towering Inferno&#8221; looking up at the smoldering behemoth and stating &#8220;We never should have built them this tall&#8230;&#8221; On the bright side, there&#8217;s usually no software in tube-based guitar amps.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

