<?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: It&#8217;s All About Interfaces</title>
	<atom:link href="http://blog.regehr.org/archives/666/feed" rel="self" type="application/rss+xml" />
	<link>http://blog.regehr.org/archives/666</link>
	<description></description>
	<lastBuildDate>Thu, 23 May 2013 17:10:41 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Ferenc Mihaly</title>
		<link>http://blog.regehr.org/archives/666/comment-page-1#comment-3826</link>
		<dc:creator>Ferenc Mihaly</dc:creator>
		<pubDate>Sun, 22 Jan 2012 23:26:42 +0000</pubDate>
		<guid isPermaLink="false">http://blog.regehr.org/?p=666#comment-3826</guid>
		<description><![CDATA[I read this post with great interest, software interface design being a passion of mine. I completely agree that getting the interfaces right is the key to building large-scale software systems. 

The current situation is not very good. I only realized just how bad some interfaces can be after I left academia and started working in the software industry. I haven&#039;t seen truly bad  interfaces, at least not interfaces used by hundreds of thousands of programmers, until I worked with some &quot;enterprise systems&quot;.  

Large scale systems are built by necessity using interfaces at a much higher level of abstraction than the operating system. If these interfaces were built at least with as much care as those of the OS, this, in itself, would be a huge improvement.  While I&#039;m sure new knowledge will continue to emerge, I&#039;m convinced that we can achieve big improvements by simply spreading and applying the knowledge we already have.]]></description>
		<content:encoded><![CDATA[<p>I read this post with great interest, software interface design being a passion of mine. I completely agree that getting the interfaces right is the key to building large-scale software systems. </p>
<p>The current situation is not very good. I only realized just how bad some interfaces can be after I left academia and started working in the software industry. I haven&#8217;t seen truly bad  interfaces, at least not interfaces used by hundreds of thousands of programmers, until I worked with some &#8220;enterprise systems&#8221;.  </p>
<p>Large scale systems are built by necessity using interfaces at a much higher level of abstraction than the operating system. If these interfaces were built at least with as much care as those of the OS, this, in itself, would be a huge improvement.  While I&#8217;m sure new knowledge will continue to emerge, I&#8217;m convinced that we can achieve big improvements by simply spreading and applying the knowledge we already have.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: gasche</title>
		<link>http://blog.regehr.org/archives/666/comment-page-1#comment-3824</link>
		<dc:creator>gasche</dc:creator>
		<pubDate>Sun, 22 Jan 2012 15:12:49 +0000</pubDate>
		<guid isPermaLink="false">http://blog.regehr.org/?p=666#comment-3824</guid>
		<description><![CDATA[I feel you are misinterpreting the VPRI initiative a bit. Indeed, their stated goal is to reduce the total size of code in a system. But what&#039;s interesting is what they&#039;re doing in practice: designing small, hopefully clean and powerful abstractions to capture the different problem domains of personal computing. So the approach they have to size reduction is exactly the approach you advertise for system robustness, and in practice I expect both initial motivations to provide related results.]]></description>
		<content:encoded><![CDATA[<p>I feel you are misinterpreting the VPRI initiative a bit. Indeed, their stated goal is to reduce the total size of code in a system. But what&#8217;s interesting is what they&#8217;re doing in practice: designing small, hopefully clean and powerful abstractions to capture the different problem domains of personal computing. So the approach they have to size reduction is exactly the approach you advertise for system robustness, and in practice I expect both initial motivations to provide related results.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Greg Morrisett</title>
		<link>http://blog.regehr.org/archives/666/comment-page-1#comment-3812</link>
		<dc:creator>Greg Morrisett</dc:creator>
		<pubDate>Thu, 19 Jan 2012 15:29:08 +0000</pubDate>
		<guid isPermaLink="false">http://blog.regehr.org/?p=666#comment-3812</guid>
		<description><![CDATA[Great post.  Seems like there are two kinds of durability for interfaces though.  On the one hand, there are interfaces like ASCII that replaced a bunch of other things, were clearly superior and simpler, and made the world a better place for a long time.  

Then there are interfaces like x86 ISA and Win32 and GCC that are durable, but out of necessity---too much on top needs to keep running---and so heroic engineering is done to keep them viable.  These things are ripe for replacement, but the trick is figuring out when, and getting sufficient mass/compatibility to make it stick.  A good recent example is LLVM which has taken on the GCC interface.]]></description>
		<content:encoded><![CDATA[<p>Great post.  Seems like there are two kinds of durability for interfaces though.  On the one hand, there are interfaces like ASCII that replaced a bunch of other things, were clearly superior and simpler, and made the world a better place for a long time.  </p>
<p>Then there are interfaces like x86 ISA and Win32 and GCC that are durable, but out of necessity&#8212;too much on top needs to keep running&#8212;and so heroic engineering is done to keep them viable.  These things are ripe for replacement, but the trick is figuring out when, and getting sufficient mass/compatibility to make it stick.  A good recent example is LLVM which has taken on the GCC interface.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ben L. Titzer</title>
		<link>http://blog.regehr.org/archives/666/comment-page-1#comment-3805</link>
		<dc:creator>Ben L. Titzer</dc:creator>
		<pubDate>Wed, 18 Jan 2012 18:34:38 +0000</pubDate>
		<guid isPermaLink="false">http://blog.regehr.org/?p=666#comment-3805</guid>
		<description><![CDATA[Sometimes things get simpler when we look at the stack of layers as a whole. Each the layers was built up incrementally upon the layers below, and they usually co-evolve from simpler forms, with more rapid evolution happening in higher layers. But after a sufficient end-state of the higher layers (those closest to the application) has been reached, it sometimes yields surprising simplicity gains to collapse adjacent layers together and redesign them together. Lower layers are necessarily more general-purpose than the layers above, and sometimes that generality is unwarranted, and the vestigial parts can be removed.

I think as computer scientists and architectures we should be courageous enough to throw out all of our lower level software and rebuild it from scratch at least once a decade, reusing the knowledge from the previous iteration. If the abstractions from the previous iteration are worthwhile they will reemerge. If they aren&#039;t, they will die. 

/axe-grind
And I think each iteration should also strive for a better language in which to be expressed. 40 years of C/C++ is about 25 too long, in my opinion.
/axe-grind-off]]></description>
		<content:encoded><![CDATA[<p>Sometimes things get simpler when we look at the stack of layers as a whole. Each the layers was built up incrementally upon the layers below, and they usually co-evolve from simpler forms, with more rapid evolution happening in higher layers. But after a sufficient end-state of the higher layers (those closest to the application) has been reached, it sometimes yields surprising simplicity gains to collapse adjacent layers together and redesign them together. Lower layers are necessarily more general-purpose than the layers above, and sometimes that generality is unwarranted, and the vestigial parts can be removed.</p>
<p>I think as computer scientists and architectures we should be courageous enough to throw out all of our lower level software and rebuild it from scratch at least once a decade, reusing the knowledge from the previous iteration. If the abstractions from the previous iteration are worthwhile they will reemerge. If they aren&#8217;t, they will die. </p>
<p>/axe-grind<br />
And I think each iteration should also strive for a better language in which to be expressed. 40 years of C/C++ is about 25 too long, in my opinion.<br />
/axe-grind-off</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: reno</title>
		<link>http://blog.regehr.org/archives/666/comment-page-1#comment-3798</link>
		<dc:creator>reno</dc:creator>
		<pubDate>Wed, 18 Jan 2012 09:56:58 +0000</pubDate>
		<guid isPermaLink="false">http://blog.regehr.org/?p=666#comment-3798</guid>
		<description><![CDATA[@Eddie Kohler &quot; For RISC, wordy ISAs&quot;
Remember that during some time, the number of transistors used to decode CISC was a real issue and slowed down significantly the CPU: x86s were much slower than RISCs, even if x86s used more transistors..
SW compatibility with Windows proved more important than raw performance and nobody cares about the number of transistors in the decoder anymore (except for their power usage),  still you cannot say that RISC was only about &quot;wordy ISA&quot;, it was about better performances.]]></description>
		<content:encoded><![CDATA[<p>@Eddie Kohler &#8221; For RISC, wordy ISAs&#8221;<br />
Remember that during some time, the number of transistors used to decode CISC was a real issue and slowed down significantly the CPU: x86s were much slower than RISCs, even if x86s used more transistors..<br />
SW compatibility with Windows proved more important than raw performance and nobody cares about the number of transistors in the decoder anymore (except for their power usage),  still you cannot say that RISC was only about &#8220;wordy ISA&#8221;, it was about better performances.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
