<div dir="ltr"><div>Dear Moreton,</div><div>I think that you might have touched the most important question of all. I'll express my own professional opinion in regards to this (not wishing to convince others - just expressing my own).</div><div><br></div><div>I've been thinking on this question for more than 20 years. If you own a company and your developers develop code towards speed to a point that is too hard to find new employees able to understand the code, you will be in a dangerous/costly zone. Firstly, because you have to spend too much finding brave/qualified developers. Secondly, the harder the code gets to be understood, the harder will be future improvements and eventual bug fixes. Imagine that you own a company and your developers can't fix a bug introduced 10 years before...Worst, some companies that I worked for in the past had contractual requirements for fixing some problems in just 2 hours... It's a horrible place to be. In my mind, when you start modifying a code with only speed in mind, your code optimization reaches a local maxima (<a href="https://en.wikipedia.org/wiki/Maxima_and_minima">https://en.wikipedia.org/wiki/Maxima_and_minima</a>). No one can safely optimize a code that doesn't fully understand. So, there is a paradox: by optimizing, you may prevent future optimizations because the human energy needed to understand the code might defuse future optimization attempts. The harder the code gets, more numerous voices will say "we need to trash and recode this".</div><div><br></div><div>There are ways to deal with extreme optimizations. One way is extreme documentation.  As an example, there is a 12 pages documentation about a one page code here: <a href="https://cnugteren.github.io/tutorial/pages/page1.html">https://cnugteren.github.io/tutorial/pages/page1.html</a> .</div><div><br></div><div>As this email will be, our code will be read by others. I don't care if my mind understands it. Will others understand it?</div><div><br></div><div>Food for thought I hope.</div><div><br></div><div>Cheers!</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 26, 2019 at 5:20 PM J. Gareth Moreton <<a href="mailto:gareth@moreton-family.com">gareth@moreton-family.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This is a question regarding the compiler <br>
in general, and I sense there is no single <br>
correct answer.<br>
<br>
As you may already know, FPC compiles <br>
source code into intermediate nodes. Most <br>
of these are quite straightforward, like <br>
addition and a procedure call, but then <br>
you get quite a few that map onto internal <br>
functions and intrinsics like "abs" and <br>
are otherwise handled directly by the <br>
compiler rather than calling a function in <br>
the System unit, say.<br>
<br>
In your experience, and through theory, <br>
where should the line be drawn with <br>
internal routines and explicitly writing a <br>
function? I can see advantages in both <br>
approaches, like it's easier to assemble a <br>
node into a specific instruction set, but <br>
it can cause a lot of bloat in the <br>
compiler, while having an explicit <br>
function reduces this compiler complexity <br>
and allows for internal code improvements <br>
and better acceptance of features like <br>
pure functions, but may increase <br>
compilation time and make optimisation <br>
more difficult, depending on how it is <br>
implemented.<br>
<br>
Just looking for discussion.<br>
<br>
Gareth aka. Kit<br>
<br>
<br>
_______________________________________________<br>
fpc-devel maillist  -  <a href="mailto:fpc-devel@lists.freepascal.org" target="_blank">fpc-devel@lists.freepascal.org</a><br>
<a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel" rel="noreferrer" target="_blank">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a><br>
</blockquote></div></div>