<?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"
	>
<channel>
	<title>Comments on: Verifying Specifications</title>
	<atom:link href="http://mjtsai.com/blog/2007/12/03/verifying-specifications/feed/" rel="self" type="application/rss+xml" />
	<link>http://mjtsai.com/blog/2007/12/03/verifying-specifications/</link>
	<description></description>
	<pubDate>Sat, 22 Nov 2008 00:51:53 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Michael</title>
		<link>http://mjtsai.com/blog/2007/12/03/verifying-specifications/#comment-189880</link>
		<dc:creator>Michael</dc:creator>
		<pubDate>Tue, 04 Dec 2007 03:59:38 +0000</pubDate>
		<guid isPermaLink="false">http://mjtsai.com/blog/2007/12/03/verifying-specifications/#comment-189880</guid>
		<description>David: I agree about the problems of the waterfall model. Still, I think that in many kinds of software there is some design, an algorithmic core or protocol, that’s separable from the implementation. This is the part that you might want a specification for.</description>
		<content:encoded><![CDATA[<p>David: I agree about the problems of the waterfall model. Still, I think that in many kinds of software there is some design, an algorithmic core or protocol, that’s separable from the implementation. This is the part that you might want a specification for.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Leif</title>
		<link>http://mjtsai.com/blog/2007/12/03/verifying-specifications/#comment-189829</link>
		<dc:creator>Leif</dc:creator>
		<pubDate>Tue, 04 Dec 2007 01:18:18 +0000</pubDate>
		<guid isPermaLink="false">http://mjtsai.com/blog/2007/12/03/verifying-specifications/#comment-189829</guid>
		<description>David: As Michael pointed out, what really matters here is the level of abstraction you use for your specification. 

Specifications in natural language are not suitable to compile a program from but, if you omit a sufficient amount of detail, are comparatively easy to read and write. 

Specifications in Java or C code are very detailed and hard to write, but can be compiled into an executable. 

Maybe model-driven development is a step towards a suitable compromise: if you design a domain-specific metamodel for a range of programs you need to build, you can make sure it's reasonably easy to read and write for humans as well as easy for a machine to generate a program from. Of course the waterfall argument is still valid, since parts of specification, design and implementation merge into the modeling process.</description>
		<content:encoded><![CDATA[<p>David: As Michael pointed out, what really matters here is the level of abstraction you use for your specification. </p>
<p>Specifications in natural language are not suitable to compile a program from but, if you omit a sufficient amount of detail, are comparatively easy to read and write. </p>
<p>Specifications in Java or C code are very detailed and hard to write, but can be compiled into an executable. </p>
<p>Maybe model-driven development is a step towards a suitable compromise: if you design a domain-specific metamodel for a range of programs you need to build, you can make sure it's reasonably easy to read and write for humans as well as easy for a machine to generate a program from. Of course the waterfall argument is still valid, since parts of specification, design and implementation merge into the modeling process.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Magda</title>
		<link>http://mjtsai.com/blog/2007/12/03/verifying-specifications/#comment-189821</link>
		<dc:creator>David Magda</dc:creator>
		<pubDate>Tue, 04 Dec 2007 00:58:59 +0000</pubDate>
		<guid isPermaLink="false">http://mjtsai.com/blog/2007/12/03/verifying-specifications/#comment-189821</guid>
		<description>Brian Cantrill said the following in his Google Tech talk on DTrace (2007-8-15) that I think has some relevance here:

&lt;blockquote&gt;In software the blueprints are the machine. In software once you design the thing you've built it: the design is the machine. That's why the waterfall model is  so fundamentally flawed. This idea that you could design the design before you design it, which is what the waterfall model is essentially saying, is flawed. Software is both, it's both information and machine.&lt;/blockquote&gt;

http://video.google.com/videoplay?docid=-8002801113289007228</description>
		<content:encoded><![CDATA[<p>Brian Cantrill said the following in his Google Tech talk on DTrace (2007-8-15) that I think has some relevance here:</p>
<blockquote><p>In software the blueprints are the machine. In software once you design the thing you've built it: the design is the machine. That's why the waterfall model is  so fundamentally flawed. This idea that you could design the design before you design it, which is what the waterfall model is essentially saying, is flawed. Software is both, it's both information and machine.</p></blockquote>
<p><a href="http://video.google.com/videoplay?docid=-8002801113289007228" rel="nofollow">http://video.google.com/videoplay?docid=-8002801113289007228</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Leif</title>
		<link>http://mjtsai.com/blog/2007/12/03/verifying-specifications/#comment-189800</link>
		<dc:creator>Leif</dc:creator>
		<pubDate>Tue, 04 Dec 2007 00:15:56 +0000</pubDate>
		<guid isPermaLink="false">http://mjtsai.com/blog/2007/12/03/verifying-specifications/#comment-189800</guid>
		<description>Glad to see I'm not the only one having a funny feeling reading the talk. I like the Laplace analogy a lot!</description>
		<content:encoded><![CDATA[<p>Glad to see I'm not the only one having a funny feeling reading the talk. I like the Laplace analogy a lot!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
