On 5/24/2021 3:41 AM, Tobias Pankrath wrote:
> Putting the files into directories would make those violations obvious and
> serve as documentation on how the deps should be. Than all others can
> start work towards that goal.

When you've got a rusty car, it sure is tempting to just paint it. But it's all for naught if the real work, the hard work, the boring work -repairing the rust- is not done.

Just shooting color out of the sprayer is fun and looks great. But it avoids accomplishing anything worthwhile.

It's an Illusion of Progress.

On Wednesday, 26 May 2021 at 00:31:48 UTC, Walter Bright wrote:
> On 5/24/2021 3:41 AM, Tobias Pankrath wrote:
>> Putting the files into directories would make those violations obvious and
>> serve as documentation on how the deps should be. Than all others can
>> start work towards that goal.
>
> When you've got a rusty car, it sure is tempting to just paint it. But it's all for naught if the real work, the hard work, the boring work -repairing the rust- is not done.
>
> Just shooting color out of the sprayer is fun and looks great. But it avoids accomplishing anything worthwhile

That is correct for the analogy you used, however that is a false analogy because...

> It's an Illusion of Progress.

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

On Wednesday, 26 May 2021 at 01:25:23 UTC, 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.

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.

I use vim's built-in ctags support for this, but I imagine most popular code editors can be configured to do something similar.

On Wednesday, 26 May 2021 at 01:38:59 UTC, Paul Backus wrote:
> On Wednesday, 26 May 2021 at 01:25:23 UTC, 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.
>
> 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.
>
> I use vim's built-in ctags support for this, but I imagine most popular code editors can be configured to do something similar.

I dont know if it is funny or sad that a thread about enabeling more compiler experiments ends with a note on adding basic IDE features to arcane editors...

On Wednesday, 26 May 2021 at 05:39:19 UTC, Ola Fosheim Grostad wrote:
> On Wednesday, 26 May 2021 at 01:38:59 UTC, Paul Backus wrote:
>> On Wednesday, 26 May 2021 at 01:25:23 UTC, Nicholas Wilson 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.
>>
>> I use vim's built-in ctags support for this, but I imagine most popular code editors can be configured to do something similar.
>
> I dont know if it is funny or sad that a thread about enabeling more compiler experiments ends with a note on adding basic IDE features to arcane editors...

😅

You can use VS tho = bliss

On Wednesday, 26 May 2021 at 08:35:04 UTC, Imperatorn wrote:
> 😅
>
> You can use VS tho = bliss

Ok, we choose to laugh! 😅

(thanks, that helped on a rainy day :-)

On 26/05/2021 1:38 PM, 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.

It also becomes significantly more manageable when you have things like the parser, ast, semantic analysis and backend all grouped together in different projects of your solution! This way you can ignore significant chunks of the compiler which are irrelevant to what you are working on.

Imagine if there was a way to standardize this experience for everyone! If only...

On Wednesday, 26 May 2021 at 12:37:58 UTC, rikki cattermole wrote:
> Imagine if there was a way to standardize this experience for everyone! If only...

The experience is irrelevant in this context.

Partitioning is a necessary first step for decoupling.

Let us stop pretending this is a matter of taste.
It is not.

It is a matter of basic Software Engineering (the profession).

On 27/05/2021 1:04 AM, Ola Fosheim Grostad wrote:
> On Wednesday, 26 May 2021 at 12:37:58 UTC, rikki cattermole wrote:
>> Imagine if there was a way to standardize this experience for everyone! If only...
> 
> The experience is irrelevant in this context.
> 
> Partitioning is a necessary first step for decoupling.
> 
> Let us stop pretending this is a matter of taste.
> It is not.
> 
> It is a matter of basic Software Engineering (the profession).

Agreed.

When the directory structure does not match the concepts and complexity involved in a project, it is a symptom of much larger issues from my experience.

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.

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.