Merge pull request #2 from bencochran/ibooks-errors

Thanks Ben!  Verified that your fixes allows the epub to open in iBooks without error.

Author: tmciver

OEBPS/section-12.html

@@ -28,7 +28,7 @@ <h2 id="section-12">12 Conclusions</h2>
     </p>
 
     <p>
-      So, what is the way out of the tar pit? What is the silver bullet? &hellip; it may not be FRP, but we believe there can be no doubt that it is <em>simplicity</em>.
+      So, what is the way out of the tar pit? What is the silver bullet? … it may not be FRP, but we believe there can be no doubt that it is <em>simplicity</em>.
     </p>
     </article>
   </body>

OEBPS/section-2.html

@@ -26,32 +26,32 @@ <h2 id="section-2">2 Complexity</h2>
       The relevance of complexity is widely recognised.
       As Dijkstra said [<a href="references.html#Dij97" class="reference">Dij97</a>, EWD1243]
 	    <blockquote>
-        “&hellip;we have to keep it crisp, disentangled, and simple if we refuse to be crushed by the complexities of our own making&hellip;”
+        “…we have to keep it crisp, disentangled, and simple if we refuse to be crushed by the complexities of our own making…”
       </blockquote>
     </p>
 
     <p>
-      &hellip;and the Economist devoted a whole article to software complexity [<a href="references.html#Eco04" class="reference">Eco04</a>] — noting that by some estimates software problems cost the American economy $59 billion annually.
+      …and the Economist devoted a whole article to software complexity [<a href="references.html#Eco04" class="reference">Eco04</a>] — noting that by some estimates software problems cost the American economy $59 billion annually.
     </p>
 
     <p>
       Being able to think and reason about our systems (particularly the effects of changes to those systems) is of <em>crucial</em> importance.
       The dangers of complexity and the importance of simplicity in this regard have also been a popular topic in ACM Turing award lectures.
       In his 1990 lecture Corbato said [<a href="references.html#Cor91" class="reference">Cor91</a>]:
 	    <blockquote>
-        “The general problem with ambitious systems is complexity.”, “&hellip;it is important to emphasize the value of simplicity and elegance, for complexity has a way of compounding difficulties”
+        “The general problem with ambitious systems is complexity.”, “…it is important to emphasize the value of simplicity and elegance, for complexity has a way of compounding difficulties”
       </blockquote>
     </p>
 
     <p>
       In 1977 Backus [<a href="references.html#Bac78" class="reference">Bac78</a>] talked about the “complexities and weaknesses” of traditional languages and noted:
-	    <blockquote>“there is a desperate need for a powerful methodology to help us think about programs. &hellip; conventional languages create unnecessary confusion in the way we think about programs”</blockquote>
+	    <blockquote>“there is a desperate need for a powerful methodology to help us think about programs. … conventional languages create unnecessary confusion in the way we think about programs”</blockquote>
     </p>
 
     <p>
       Finally, in his Turing award speech in 1980 Hoare [<a href="references.html#Hoa81" class="reference">Hoa81</a>] observed:
 	    <blockquote>
-        “&hellip;there is one quality that cannot be purchased &hellip; — and that is reliability.
+        “…there is one quality that cannot be purchased … — and that is reliability.
         The price of reliability is the pursuit of the utmost simplicity”
       </blockquote>
     </p>
@@ -73,7 +73,7 @@ <h2 id="section-2">2 Complexity</h2>
     </blockquote>
 
     <p>
-      &hellip;but the purpose of this paper is to give some cause for optimism.
+      …but the purpose of this paper is to give some cause for optimism.
     </p>
 
     <p>

OEBPS/section-3.html

@@ -56,7 +56,7 @@ <h2 id="section-3">3 Approaches to Understanding</h2>
       The huge number of different possible inputs usually rules out the possibility of testing them all, hence the unavoidable concern with testing will always be — <em>have you performed the </em>right<em> tests</em>?.
       The only certain answer you will ever get to this question is an answer in the negative — when the system breaks.  Again, as Dijkstra observed [<a href="references.html#Dij71" class="reference">Dij71</a>, EWD303]:
       <blockquote>
-        “testing is hopelessly inadequate.&hellip;(it) can be used very effectively to show the presence of bugs but never to show their absence.”
+        “testing is hopelessly inadequate.…(it) can be used very effectively to show the presence of bugs but never to show their absence.”
       </blockquote>
     </p>