but W.B. say you are not writing d compiler thousand hours.
What you say doesn't count.

On 27/05/2021 1:58 AM, Ola Fosheim Grostad wrote:
> On Wednesday, 26 May 2021 at 13:51:38 UTC, rikki cattermole wrote:
>> Fixing it, makes other issues much more visible to the point where they: HAVE TO BE FIXED RIGHT NOW.
>>
>> Without the rearranging to match concepts and complexities in the file structure, it is a lot harder to properly scope modules to doing one and only one thing.
> 
> Exactly. The core principle for anything that has to do with computers at basically any level is surprisingly simple: Divide and Conquer.

I actually have an article on code quality and how I measure it.

https://cattermole.co.nz/article/code_qual

But the important list I use (for which dmd fails completely at):

1. Organized in a way that reflects the idea/concept.
2. Seperate concepts, seperate areas (files/areas of a file).
3. Grouping of resource usage
4. Depth from purpose
5. Naming

1, 2 and 4 is what this part of the thread is all about.

5 is stuff like what is STC? Variable names ext.

3. ok just look at the filename of this.
https://github.com/dlang/dmd/blob/master/src/dmd/libelf.d

or...

https://github.com/dlang/dmd/blob/master/src/dmd/libomf.d

I hope I don't need to say why these files fail that test when they are in the same directory as:

https://github.com/dlang/dmd/blob/master/src/dmd/doc.d

On Wednesday, 26 May 2021 at 01:38:59 UTC, Paul Backus wrote:
>
> For what it's worth, I've found that exploration and navigation of DMD code becomes much more manageable with an editor that supports "goto definition"--ideally with history, so you can jump backwards too.

That's if you've got a starting point in the source code, then yeah it is a lot better (thx to all who did work on LSP related projects for D), however it won't help when you try to find some functionality which you don't know in what module is.

On 27/05/2021 5:28 AM, Alexandru Ermicioi wrote:
> On Wednesday, 26 May 2021 at 01:38:59 UTC, Paul Backus wrote:
>>
>> For what it's worth, I've found that exploration and navigation of DMD code becomes much more manageable with an editor that supports "goto definition"--ideally with history, so you can jump backwards too.
> 
> That's if you've got a starting point in the source code, then yeah it is a lot better (thx to all who did work on LSP related projects for D), however it won't help when you try to find some functionality which you don't know in what module is.

There is a file list (somewhere, I'm not looking for it) that tells you what is what. But a proper directory structure + good header comments can do this even better :D

On Wednesday, 26 May 2021 at 14:21:06 UTC, rikki cattermole wrote:
> I actually have an article on code quality and how I measure it.
>
> https://cattermole.co.nz/article/code_qual


I like your motto: Code is documentation!

> But the important list I use (for which dmd fails completely at):
>
> 1. Organized in a way that reflects the idea/concept.
> 2. Seperate concepts, seperate areas (files/areas of a file).
> 3. Grouping of resource usage
> 4. Depth from purpose
> 5. Naming
>
> 1, 2 and 4 is what this part of the thread is all about.

But, my main issues are not these, these are symptoms. My main concerns are the consequenses of the ubderlying cause for these symptoms. The real challenge is not having a clean way of introducing new components ( like an IR between front and backend or a new solver related to the type system ). There is missing an analysis of where the compiler should allow extensions (compile time) with ease.

That prevents experimentation, and lowers interest in participation. LDC has achieved a lot and it is, I think, because they could specialize on THEIR piece, and take pride in maintaining it in a (I can only assume) busy life. They can also make their own decisions, so there is a sense of autonomous control, which is a high motivation factor (generally speaking).

On Wednesday, 26 May 2021 at 19:13:42 UTC, Ola Fosheim Grostad wrote:
> But, my main issues are not these, these are symptoms. My main concerns are the consequenses of the ubderlying cause for these symptoms. The real challenge is not having a clean way of introducing new components ( like an IR between front and

I guess another way of putting it is that it is ok that some authors want to maintain and fix bugs in their own component, so that component can have little documentation and so on, if there is an architecture to support having components! (Which is a desirable quality because it allows a sense of autonomous ownership etc.)

On 27/05/2021 7:13 AM, Ola Fosheim Grostad wrote:
> On Wednesday, 26 May 2021 at 14:21:06 UTC, rikki cattermole wrote:
>> I actually have an article on code quality and how I measure it.
>>
>> https://cattermole.co.nz/article/code_qual
> 
> 
> I like your motto: Code is documentation!

Thanks!

>> But the important list I use (for which dmd fails completely at):
>>
>> 1. Organized in a way that reflects the idea/concept.
>> 2. Seperate concepts, seperate areas (files/areas of a file).
>> 3. Grouping of resource usage
>> 4. Depth from purpose
>> 5. Naming
>>
>> 1, 2 and 4 is what this part of the thread is all about.
> 
> But, my main issues are not these, these are symptoms. My main concerns are the consequenses of the ubderlying cause for these symptoms. The real challenge is not having a clean way of introducing new components ( like an IR between front and backend or a new solver related to the type system ). There is missing an analysis of where the compiler should allow extensions (compile time) with ease.

Yeah, although I'll stay out of the whole IR thing as I'm no where near thinking about something like that.

On Wednesday, 26 May 2021 at 20:03:28 UTC, rikki cattermole wrote:
> Yeah, although I'll stay out of the whole IR thing as I'm no where near thinking about something like that.

Ok, one simple way is to just have a standard high level intermediary language like SIL for Swift. Then authors can build auxillary IRs that point back to the language nodes if needed. Then run the algorithm on the auxillary IR, then modify the language node graph accordingly. Then drop the auxillary IR and move on to the next stage. In the end the backend receives whatever is left of the intermediate datastructure.

Another option could be to have a mediating layer between front and backend. The default noop layer could be designed such that the optimizer will remove most of the overhead. Then people can replace the mediating layer with their own datastructure that obtains what it needs from the frontend, does something with it, and pass everything the backend needs down to the backend.

Probably more options. I have no strong opinion of what is best.

Just settle for something that puts a clean separation layer between front and backend without loosing sought information.

On 5/25/2021 6:25 PM, Nicholas Wilson wrote:
> ...Illusions of Progress provide no actual utility, hence illusions.
> Packaging DMD otoh, provides _lots_ of utility: exploration and navigation is greatly eased, moreso for people who are less familiar with the codebase.

Creating a FILES.md file, the content of which is each source file with a brief description, will accomplish the same thing.