On Saturday, 8 June 2019 at 09:23:54 UTC, H. S. Teoh wrote:
> On Sat, Jun 08, 2019 at 09:02:46AM +0200, Andrei Alexandrescu via Digitalmars-d wrote:
>> On 1/21/19 4:52 PM, H. S. Teoh wrote:
>> > split up std.algorithm (at Andrei's protest)
>> 
>> Shouldn't have been splitted.
>
> It should have been. The old std.algorithm was a monster of 10,000 LOC that caused the compiler to exhaust my RAM and thrash on swap before dying horribly, when building unittests. It was an embarrassment.
>
> The old std.datetime had the same problem and I'm very glad Jonathan eventually also split it up into more sensible chunks.
>
>
> T

+1

It's just about not having too much code in the first place.

On Saturday, 8 June 2019 at 12:32:54 UTC, KnightMare wrote:
> On Saturday, 8 June 2019 at 12:26:56 UTC, KnightMare wrote:

I watched a video now from conference https://youtu.be/OsOfTVm2ExY?t=2107
where Walter said that deserialization some AST can be same speed as parsing source. should to think

On 6/8/19 5:23 AM, H. S. Teoh wrote:
> The old std.datetime had the same problem

That should indeed have been broken as it was.

On 6/8/19 5:23 AM, H. S. Teoh wrote:
> It should have been. The old std.algorithm was a monster of 10,000 LOC
> that caused the compiler to exhaust my RAM and thrash on swap before
> dying horribly, when building unittests. It was an embarrassment.

The appropriate response would have been (and still is) to fix the compiler. A more compact working set will also accelerate execution due to better locality.

On Saturday, 8 June 2019 at 14:48:24 UTC, Andrei Alexandrescu wrote:
>A more compact working set will also accelerate
> execution due to better locality.

OTOH, a more sparse working set will accelerate development since it lessens cognitive load.

On Saturday, 8 June 2019 at 14:53:20 UTC, Nicholas Wilson wrote:
> OTOH, a more sparse working set will accelerate development since it lessens cognitive load.

I personally find it is a LOT easier to work with one big file than multiple small files.

But that said, with something like an IDE, it shouldn't matter either way since the computer should be able to work with both equally well.

On Saturday, 8 June 2019 at 14:58:17 UTC, Adam D. Ruppe wrote:
> I personally find it is a LOT easier to work with one big file than multiple small files.

I feel the same.

> But that said, with something like an IDE, it shouldn't matter either way since the computer should be able to work with both equally well.

Well a friend of mine would discord on this over his hog electron based IDE. :)

Depending on the IDE people will complain about the size of the file, but I'm not one of them, because I'm not IDE type of guy.

Matheus.

On Saturday, 8 June 2019 at 14:58:17 UTC, Adam D. Ruppe wrote:
> On Saturday, 8 June 2019 at 14:53:20 UTC, Nicholas Wilson wrote:
>> OTOH, a more sparse working set will accelerate development since it lessens cognitive load.
>
> I personally find it is a LOT easier to work with one big file than multiple small files.
>
> But that said, with something like an IDE, it shouldn't matter either way since the computer should be able to work with both equally well.


I never understand complaints about where files are located and what goes where. That's for the computer to know and for me to pretty much never care about.

Likewise, I don't understand why anyone would want a tree view of their filesystem in their editor. When I know the file name and care, I use fuzzy matching to open it instead of clicking on directories.

Do you know when I care about code organisation? When it impacts compile times negatively and/or affect coupling.

On 6/8/19 10:48 AM, Andrei Alexandrescu wrote:
> On 6/8/19 5:23 AM, H. S. Teoh wrote:
>> It should have been. The old std.algorithm was a monster of 10,000 LOC
>> that caused the compiler to exhaust my RAM and thrash on swap before
>> dying horribly, when building unittests. It was an embarrassment.
> 
> The appropriate response would have been (and still is) to fix the compiler. A more compact working set will also accelerate execution due to better locality.

Sheesh, this is *exactly* the sort of "Perfection is the enemy of the good" foot-shooting that's been keeping D years behind where it could be.

In D1 days, things got fixed and improved quickly. But now, problems that have a working solution available remain unfixed for years just because "there's a better way to do it, but it takes far more work, isn't going to ready anytime soon, there or may or may not even be anyone active being working on it."

A fix in master is worth two in the bush.

On Saturday, 8 June 2019 at 00:00:17 UTC, Mike Franklin wrote:
> On Friday, 7 June 2019 at 16:38:56 UTC, Seb wrote:
>
>> Reading files is really cheap, evaluating templates and running CTFE isn't. That's why importing Phobos modules is slow - not because of the files it imports, but because of all the CTFE these imports trigger.
>
> Yes that makes much more sense to me.  But, if that's the case, what's all the concern from Walter and Andrei expressed in this thread and in the conversations linked below?
>
> https://forum.dlang.org/post/q7dpmg$29oq$1@digitalmars.com
> https://github.com/dlang/druntime/pull/2634#issuecomment-499494019
> https://github.com/dlang/druntime/pull/2222#issuecomment-398390889

Another recent comment from Walter:  https://github.com/dlang/dmd/pull/9814#issuecomment-493773769

It seems there is disagreement about what the actual issue is.

Mike