tooling quality and some random rant

[Walter Bright]

Paulo Pinto wrote:
> Why C and not directly D?
> 
> It is really bad adversting for D to know that when its creator came around 
> to rewrite the linker, Walter decided to use C instead of D.

That's a very good question.

The answer is in the technical details of transitioning optlink from an all 
assembler project to a higher level language. I do it function by function, 
meaning there will be hundreds of "hybrid" versions that are partly in the high 
level language, partly in asm. Currently, it's around 5% in C.

1. Optlink has its own "runtime" system and startup code. With C, and a little 
knowledge about how things work under the hood, it's easier to create "headless" 
functions that require zero runtime and startup support. With D, the D compiler 
will create ModuleInfo and TypeInfo objects, which more or less rely on some 
sort of D runtime existing.

2. The group/segment names emitted by the C compiler match what Optlink uses. It 
matches what dmd does, too, except that dmd emits more such names, requiring 
more of an understanding of Optlink to get them in the right places.

3. The hybrid intermediate versions require that the asm portions of Optlink be 
able to call the high level language functions. In order to avoid an error-prone 
editting of scores of files, it is very convenient to have the function names 
used by the asm code exactly match the names emitted by the compiler. I 
accomplished this by "tweaking" the dmc C compiler. I didn't really want to mess 
with the D compiler to do the same.

4. Translating asm to a high level language starts with a rote translation, i.e. 
using goto's, raw pointers, etc., which match 1:1 with the assembler logic. No 
attempt is made to infer higher level logic. This makes mistakes in the 
translation easier to find. But it's not the way anyone in their right mind 
would develop C code. The higher level abstractions in C are not useful here, 
and neither are the higher level abstractions in D.

Once the entire Optlink code base has been converted, then it becomes a simple 
process to:

1. Dump the Optlink runtime, and switch to the C runtime.

2. Translate the C code to D.

And then:

3. Refactor the D code into higher level abstractions.


I've converted a massive code base from asm to C++ before (DASH for Data I/O) 
and I discovered that attempting to refactor the code while translating it is 
fraught with disaster. Doing the hybrid approach is much faster and more likely 
to be successful.


TL,DR: The C version is there only as a transitional step, as it's somewhat 
easier to create a hybrid asm/C code base than a hybrid asm/D one. The goal is 
to create a D version.