<li>Then stopped working like an engineer monkey</li>
<li>Used a pen and a sheet of paper</li>
<li>Made some math.</li>
<li>Crushed the problem in 10 minutes</li>
<li>Conclusion: The pragmatism shouldn’t mean “never use theory”.</li>
</ul>
</div>
<h2id="abstract-longer-than-tldr">Abstract (longer than <spanclass="sc"><abbrtitle="Too long; didn't read">tl;dr</abbr>: </span>)</h2>
<p>For my job, I needed to resolve a problem. It first seems not too hard. Then I started working directly on my program. I entered in the <em>infernal</em>: <em>try & repair loop</em>. Each step was like:</p>
<blockquote>
<p>– Just this thing to repair and that should be done.<br/>
– OK, now that should just work.<br/>
– Yeah!!!<br/>
– Oops! I forgotten that…<br/>
<code>repeat until death</code></p>
</blockquote>
<p>After two days of this <ahref="http://fr.wikipedia.org/wiki/Sisyphe">Sisyphus</a> work, I finally just stopped to rethink the problem. I took a pen, a sheet of paper. I simplified the problem, reminded what I learned during my Ph.D.about trees. Finally, the problem was crushed in less than 20 minutes.</p>
<p>I believe the important lesson is to remember that the most efficient methodology to resolve this <em>pragmatic</em> problem was the <em>theoretical</em> one. And therefore, argues opposing science, theory to pragmatism and efficiency are fallacies.</p>
<hr/>
<h1id="first-my-experience">First: my experience</h1>
<p>Apparently 90% of programmer are unable to program a binary search without bug. The algorithm is well known and easy to understand. However it is difficult to program it without any flaw. I participated to <ahref="http://reprog.wordpress.com/2010/04/19/are-you-one-of-the-10-percent/">this contest</a>. And you can see the <ahref="http://reprog.wordpress.com/2010/04/21/binary-search-redux-part-1/">results here</a><ahref="#fn1"class="footnote-ref"id="fnref1"><sup>1</sup></a>. I had to face a problem of the same kind at my job. The problem was simple to the start. Simply transform an <sc>xml</sc> from one format to another.</p>
<p>The source <sc>xml</sc> was in the following general format:</p>
<p>At first sight I believed it will be easy. I was so certain it will be easy that I fixed to myself the following rules:</p>
<oltype="1">
<li>do not use <sc>xslt</sc></li>
<li>avoid the use of an <sc>xml</sc> parser</li>
<li>resolve the problem using a simple perl script[^2]</li>
</ol>
<p>You can try if you want. If you attack the problem directly opening an editor, I assure you, it will certainly be not so simple. I can tell that, because it’s what I’ve done. And I must say I lost almost a complete day at work trying to resolve this. There was also, many small problems around that make me lose more than two days for this problem.</p>
<p>Why after two days did I was unable to resolve this problem which seems so simple?</p>
<p>What was my behaviour (workflow)?</p>
<oltype="1">
<li>Think</li>
<li>Write the program</li>
<li>Try the program</li>
<li>Verify the result</li>
<li>Found a bug</li>
<li>Resolve the bug</li>
<li>Go to step 3.</li>
</ol>
<p>This was a <em>standard</em> workflow for computer engineer. The flaw came from the first step. I thought about how to resolve the problem but with the eyes of a <em>pragmatic engineer</em>. I was saying:</p>
<blockquote>
<p>That should be a simple perl search and replace program.<br/>
Let’s begin to write code</p>
</blockquote>
<p>This is the second sentence that was plainly wrong. I started in the wrong direction. And the workflow did not work from this entry point.</p>
<h2id="think">Think</h2>
<p>After some times, I just stopped to work. Tell myself <em>“it is enough, now, I must finish it!”</em>. I took a sheet of paper, a pen and began to draw some trees.</p>
<p>I began by make by removing most of the verbosity. I first renamed <code><item name="Menu"></code> by simpler name <code>M</code> for example. I obtained something like:</p>
<p>Then I made myself the following reflexion:</p>
<p>Considering Tree Edit Distance, each unitary transformation of tree correspond to a simple search and replace on my <sc>xml</sc> source<ahref="#fn2"class="footnote-ref"id="fnref2"><sup>2</sup></a>. We consider three atomic transformations on trees:</p>
<ul>
<li><em>substitution</em>: renaming a node</li>
<li><em>insertion</em>: adding a node</li>
<li><em>deletion</em>: remove a node</li>
</ul>
<p>One of the particularity of atomic transformations on trees, is ; if you remove a node, all children of this node, became children of its father.</p>
<p>An example:</p>
<preclass="twilight">
r - x - a
\ \
\ b
y - c
</pre>
<p>If you delete the <code>x</code> node, you obtain</p>
<preclass="twilight">
a
/
r - b
\
y - c
</pre>
<p>And look at what it implies when you write it in <sc>xml</sc>:</p>
<p>Therefore, if there exists a one state deterministic transducer which transform my trees ; I can transform the <sc>xml</sc> from one format to another with just a simple list of search and replace directives.</p>
<h1id="solution">Solution</h1>
<p>Transform this tree:</p>
<preclass="twilight">
R - C - tag1
\ \
\ tag2
E -- R - C - tag1
\ \ \
\ \ tag2
\ E ...
R - C - tag1
\ \
\ tag2
E ...
</pre>
<p>to this tree:</p>
<preclass="twilight">
tag1
/
M - V - M - V - tag2 tag1
\ /
M --- V - tag2
\ \
\ M
\ tag1
\ /
V - tag2
\
M
</pre>
<p>can be done using the following one state deterministic tree transducer:</p>
<blockquote>
<p>C -> ε<br/>
E -> M<br/>
R -> V</p>
</blockquote>
<p>Wich can be traduced by the following simple search and replace directives:</p>
<p>It should seems a bit paradoxal, but sometimes the most efficient approach to a pragmatic problem is to use the theoretical methodology.</p>
<sectionclass="footnotes">
<hr/>
<ol>
<liid="fn1"><p>Hopefully I am in the 10% who had given a bug free implementation.<ahref="#fnref1"class="footnote-back">↩</a></p></li>
<liid="fn2"><p>I did a program which generate automatically the weight in a matrix of each edit distance from data.<ahref="#fnref2"class="footnote-back">↩</a></p></li>
