<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>video &amp;mdash; dominicDS</title>
    <link>https://dominicds.com/tag:video</link>
    <description>always learning</description>
    <pubDate>Wed, 22 Apr 2026 17:08:16 +0000</pubDate>
    <item>
      <title>Scooping the Loop Snooper</title>
      <link>https://dominicds.com/scooping-the-loop-snooper?pk_campaign=rss-feed</link>
      <description>&lt;![CDATA[---&#xA;In the following video, I read a rhyming poem about a popular part of computability theory, the Halting Problem.&#xA;&#xA;!--more--&#xA;&#xA;iframe width=&#34;560&#34; height=&#34;315&#34; src=&#34;https://www.youtube.com/embed/vBSqgsRSmk&#34; frameborder=&#34;0&#34; allow=&#34;accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture&#34; allowfullscreen/iframe&#xA;&#xA;Find the original poem here: http://www.lel.ed.ac.uk/~gpullum/loopsnoop.html&#xA;&#xA;The halting problem is an interesting part of computability theory. It tells us that there&#39;s no way, using a certain type of computer, to be able to always detect if a given program will eventually stop running. &#xA;&#xA;Although it&#39;s often attributed to computer science hero and queer icon Alan Turing, the problem was first stated in the 1950s by a mathematician named Martin Davis. &#xA;&#xA;It&#39;s an abstract idea, but it has real-world impact. &#xA;&#xA;Computing worked differently in the fifties. This was before time-sharing, so each (large, expensive, fragile) computer could essentially only run one program at a time. A program was fed into the machine, and it cranked away before producing a result.  Programs could potentially run for hours or days before successfully completing. During that time no other programs could be executed. Long-running programs can create a bottleneck, with many others waiting to run.&#xA;&#xA;As you can imagine, an infinite loop was an expensive problem, as the program could run for a long time without anyone realizing it&#39;s gone wrong. Eventually, either the machine breaks (very common in the era of vacuum tubes) or the operators manually halt the machine because they realize something&#39;s gone wrong.&#xA;&#xA;An effective and cost-saving way of avoiding this was manual review of the program&#39;s code before running it. An engineer looks at the code and tries to figure out what will happen as the computer executes it. A lot of time, this process can detect an error before the program starts to run, which is the best time to find a bug.&#xA;&#xA;But engineers are human, and they make mistakes. That&#39;s why we have these infinite loops to begin with. The manual review process occasionally overlooks bugs. So why not get a static analyzer to detect them for us, a machine that looks at the software and detects issues? Well, we have done just that. These are amazing tools and I love them.&#xA;&#xA;So the halting problem shows us that these analyzers can never be perfect. Due to the dynamic relationship between code and its input data, it&#39;s impossible to know (with total certainty) from the code alone whether an infinite loop won&#39;t occur. &#xA;&#xA;As a side note, because it&#39;s a work of computability theory and mathematics, none of this work tends to address many external factors that can cause a computer glitch to occur, such as hardware failures, environmental factors, and malicious actors.&#xA;&#xA;#video #computers&#xA;]]&gt;</description>
      <content:encoded><![CDATA[<hr/>

<p>In the following video, I read a rhyming poem about a popular part of computability theory, the Halting Problem.</p>



<iframe width="560" height="315" src="https://www.youtube.com/embed/vBS_qgsRSmk" frameborder="0" allowfullscreen=""></iframe>

<p>Find the original poem here: <a href="http://www.lel.ed.ac.uk/~gpullum/loopsnoop.html">http://www.lel.ed.ac.uk/~gpullum/loopsnoop.html</a></p>

<p>The <a href="https://en.wikipedia.org/wiki/Halting_problem"><em>halting problem</em></a> is an interesting part of computability theory. It tells us that there&#39;s no way, using a <a href="https://en.wikipedia.org/wiki/Turing_machine">certain type of computer</a>, to be able to always detect if a given program will eventually stop running.</p>

<p><a href="https://www.sciencedirect.com/science/article/pii/S235222082100050X">Although it&#39;s often attributed to computer science hero and queer icon Alan Turing, the problem was first stated in the 1950s by a mathematician named Martin Davis</a>.</p>

<p>It&#39;s an abstract idea, but it has real-world impact.</p>

<p>Computing worked differently in the fifties. This was before <a href="https://en.wikipedia.org/wiki/Time-sharing">time-sharing</a>, so each (large, expensive, fragile) computer could essentially only run one program at a time. A program was fed into the machine, and it cranked away before producing a result.  Programs could potentially run for hours or days before successfully completing. During that time no other programs could be executed. Long-running programs can create a bottleneck, with many others waiting to run.</p>

<p>As you can imagine, an <a href="https://en.wikipedia.org/wiki/Infinite_loop">infinite loop</a> was an expensive problem, as the program could run for a long time without anyone realizing it&#39;s gone wrong. Eventually, either the machine breaks (very common in the era of vacuum tubes) or the operators manually halt the machine because they realize something&#39;s gone wrong.</p>

<p>An effective and cost-saving way of avoiding this was manual review of the program&#39;s code before running it. An engineer looks at the code and tries to figure out what will happen as the computer executes it. A lot of time, this process can detect an error before the program starts to run, which is the best time to find a bug.</p>

<p>But engineers are human, and they make mistakes. <em>That&#39;s why we have these infinite loops to begin with.</em> The manual review process occasionally overlooks bugs. So why not get a static analyzer to detect them for us, a machine that looks at the software and detects issues? Well, we have done just that. These are amazing tools and I love them.</p>

<p><img src="https://i.snap.as/SrnwcMm8.png" alt=""/></p>

<p>So the halting problem shows us that these analyzers can never be perfect. Due to the dynamic relationship between code and its input data, it&#39;s impossible to know (with total certainty) from the <em>code alone</em> whether an infinite loop won&#39;t occur.</p>

<p>As a side note, because it&#39;s a work of computability theory and mathematics, none of this work tends to address many external factors that can cause a computer glitch to occur, such as hardware failures, environmental factors, and malicious actors.</p>

<p><a href="https://dominicds.com/tag:video" class="hashtag"><span>#</span><span class="p-category">video</span></a> <a href="https://dominicds.com/tag:computers" class="hashtag"><span>#</span><span class="p-category">computers</span></a></p>
]]></content:encoded>
      <guid>https://dominicds.com/scooping-the-loop-snooper</guid>
      <pubDate>Tue, 16 Nov 2021 22:10:08 +0000</pubDate>
    </item>
  </channel>
</rss>