<div dir="ltr"><div class="gmail_extra"><span id="docs-internal-guid-24aabbca-cf48-163a-9791-a5288e0df45c"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">Janne,</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">First, I strongly object to being characterized as a “random rewriter”.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">I have used proj since 1993, did my first (tiny) contribution to the code base in 1999, and I facilitated the inclusion of the etmerc, high precision transverse mercator code written by my colleague Karsten Engsager, in 2008.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">It is correct that I have not touched the code base since then, but that does not turn me into a “random rewriter”. </span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">Also, I described my intended work, and asked for comments and opinions on the proj mailing list more than a month ago. It attracted one comment, which was very much in favor of the work. It did not attract any comments from you.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">Also, the pull request has been open since the beginning of april. Howard Butler, Even Rouault, and Micah Cochran have commented and given constructive criticism. I have seen no comments from you.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">So all in all, you have had plenty of time to air your opinion. It would have been very helpful if you had done it a bit earlier than 2 months into the process. As a long term proj-list member, I know that you are a frequent and very helpful list contributor, so I have great respect for your experience and willingness to share it, and I believe you could have been a very helpful commenter and mentor for this work.</span></p><br><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">Second: In general I agree with your opinion of “not touching what works”.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">However, what “works” is not easily definable - especially not in the long term.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">Kristian Evers and I have turned to proj after having spent time updating trlib, the transformation system of the Danish national mapping agency (now SDFE, formerly GST, formerly KMS, formerly GI).</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">trlib originated as Algol code written around 1961, for the GIER system (a, for that time, medium sized computer, which was highly optimized for geodetic computations). The code survived and evolved through more than 5 decades following what was “current best practice” all along.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">And the one “best practice” that has been prevalent through all these decades has been exactly the one you forward here.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">The problem is that, while commendable for the medium term, for the long term “not touching what works” leads to kludge-upon-kludge, from bolting on additional functionality, while not touching existing code.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">In the long term, the “not touching what works” dogma (NTWW in the following) leads to stale and unmaintainable code.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">As an example, for trlib, one of the things we have removed during the last few years of code revision, is a complete user-space Virtual Menory mangagement system. It was evidently needed when added to the code around 1970, and left in due to NTWW when the code was migrated from Algol to C around 1980. And kept ever since, due to NTWW.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">So our experience is very much that NTWW should be challenged now and then. Things change, and so do the hardware platforms the code is supposed to run on.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">The proj.4 macro system reflects a development environment of Tektronix style, green phosphor 24x80 terminals, where saving vertical whitespace directly translated into a better general view, by having more context on screen at a time.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">This is not the problem for modern coding tools on modern high-resolution displays. In today’s coding environment the proj internal macro system is a high barrier for entry: It makes it extremely hard for new coders to get productive.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">If you look at the commit history, you will notice that new people enter the project in order to contribute one or two new projectione that they need.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">They do not stay to help evolving proj further. I hypothesize that this is at least partially because the macro system is convoluted and not at all C-like (e.g. leading to syntax highlighter blues).</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">My intention was to make the code less impenetrable, in order to make it more welcoming to new contributors. As you will see when you study the code, this has been done without touching the algorithmic flow. The procedure has been designed to enhance the clarity for human readers - not to touch the flow.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">I suggest you read the description “A verbose justification for some highly intrusive code surgery” I wrote at the very beginning of this work, over at <a href="https://github.com/busstoptaktik/proj.4/blob/sdfe-refactor-macros--and-repair-generic-constructor-bug/src/PJ_minimal.c">https://github.com/busstoptaktik/proj.4/blob/sdfe-refactor-macros--and-repair-generic-constructor-bug/src/PJ_minimal.c</a>. Hopefully you will see that I have no intentions to break what works - but at medium time scale intervals, changing what works is necessary in order to keep things in shape.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">regards</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;margin-right:5pt"><span style="font-size:12px;font-family:Consolas;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap">Thomas</span></p><br></span></div></div>