[fpc-devel] Simplicity vs. Complexity

J. Gareth Moreton gareth at moreton-family.com
Tue Mar 26 23:05:32 CET 2019

Food for thought indeed. One of my past 
contracts was to decipher an old database 
that I could only describe as 
Frankenstein's Monster. Everyone who had 
developed it had long left the company and 
no-one dared touch it, because it worked 
but no-one knew how! That is a very 
dangerous situation to be in in my 

Compilers are naturally going to be the 
most complex projects out there. The 
question was less about making it more 
approachable to others and more about an 
internal mechanic where some functions 
compile into actual functions coded in a 
library unit, and those that translate 
into a specialised node, since Free Pascal 
seems to favour the latter in quite a few 
places and certain combinations feel a 
little... finicky, like they could break 
off you're not careful.

Gareth aka. Kit

On Tue 26/03/19 21:04 , "Joao Schuler" 
jp at schulers.com sent:
> Dear Moreton,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).
> 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 ( 
inima [1]). 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".
> 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:  
> [2] .
> 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?
> Food for thought I hope.
> Cheers!
> On Tue, Mar 26, 2019 at 5:20 PM J. 
Gareth Moreton  wrote:
> This is a question regarding the 
> in general, and I sense there is no 
> correct answer.
> As you may already know, FPC compiles 
> source code into intermediate nodes. 
> of these are quite straightforward, like 
> addition and a procedure call, but then 
> you get quite a few that map onto 
> functions and intrinsics like "abs" and 
> are otherwise handled directly by the 
> compiler rather than calling a function 
> the System unit, say.
> In your experience, and through theory, 
> where should the line be drawn with 
> internal routines and explicitly writing 
> function? I can see advantages in both 
> approaches, like it's easier to assemble 
> node into a specific instruction set, 
> it can cause a lot of bloat in the 
> compiler, while having an explicit 
> function reduces this compiler 
> and allows for internal code 
> and better acceptance of features like 
> pure functions, but may increase 
> compilation time and make optimisation 
> more difficult, depending on how it is 
> implemented.
> Just looking for discussion.
> Gareth aka. Kit
> fpc-devel maillist  -  fpc-
devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-
bin/mailman/listinfo/fpc-devel [3]
> Links:
> ------
> [1] 
> [2] 
> [3] http://lists.freepascal.org/cgi-

More information about the fpc-devel mailing list