This is a question regarding the compiler
in general, and I sense there is no single
correct answer.

As you may already know, FPC compiles
source code into intermediate nodes. Most
of these are quite straightforward, like
addition and a procedure call, but then
you get quite a few that map onto internal
functions and intrinsics like "abs" and
are otherwise handled directly by the
compiler rather than calling a function in
the System unit, say.

In your experience, and through theory,
where should the line be drawn with
internal routines and explicitly writing a
function? I can see advantages in both
approaches, like it's easier to assemble a
node into a specific instruction set, but
it can cause a lot of bloat in the
compiler, while having an explicit
function reduces this compiler complexity
and allows for internal code improvements
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

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 (https://en.wikipedia.org/wiki/Maxima_and_minima). 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: https://cnugteren.github.io/tutorial/pages/page1.html .

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!

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
opinion.

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"
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 (

https://en.wikipedia.org/wiki/Maxima_and_m
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: 

https://cnugteren.github.io/tutorial/pages
/page1.html

[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

compiler

in general, and I sense there is no

single

correct answer. As you may already know, FPC compiles source code into intermediate nodes.

Most

of these are quite straightforward, like addition and a procedure call, but then you get quite a few that map onto

internal

functions and intrinsics like "abs" and are otherwise handled directly by the compiler rather than calling a function

in

a

function? I can see advantages in both approaches, like it's easier to assemble

a

node into a specific instruction set,

but

it can cause a lot of bloat in the compiler, while having an explicit function reduces this compiler

complexity

and allows for internal code

improvements