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" j...@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 ( 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 > 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 > > __________________________________________ _____ > fpc-devel maillist - fpc- de...@lists.freepascal.org > http://lists.freepascal.org/cgi- bin/mailman/listinfo/fpc-devel [3] > > > Links: > ------ > [1] https://en.wikipedia.org/wiki/Maxima_and_m inima > [2] https://cnugteren.github.io/tutorial/pages /page1.html > [3] http://lists.freepascal.org/cgi- bin/mailman/listinfo/fpc-devel > > _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
