On Saturday, 19 October 2019 at 17:18:34 UTC, H. S. Teoh wrote:

> IMO, you should file a bug for this one.

IIRC, I did years ago. I'll try to find it.

On Sunday, 20 October 2019 at 03:41:08 UTC, Walter Bright wrote:
> On 10/19/2019 6:52 PM, Nicholas Wilson wrote:
>> On Saturday, 19 October 2019 at 23:38:51 UTC, aliak wrote:
>>> Plus, IIRC dmd is a prime example where splitting is not happening because of "reasons". So it's not always doable either.
>> Those reasons are largely "Walter" and are unrelated.
>
> I know I'm not popular with this idea, but packagizing dmd is akin to painting a rusty/dirty car without prepping the metal first.

Obviously I think you're wrong, but for the sake of getting shit done:
Do you mean to imply that now is not the time, as opposed to it will never happen?
Because it _really_ needs to happen, and the sooner the better, as Rikki notes it is an absolute requirement compiler as a library.

 If so, what do you think needs to happen before that?

On Sunday, 20 October 2019 at 09:02:18 UTC, Mike Parker wrote:
> On Sunday, 20 October 2019 at 08:44:37 UTC, aliak wrote:
>> On Sunday, 20 October 2019 at 05:43:52 UTC, Walter Bright wrote:
>
>>>
>>> In D, declarations are grouped into a module that would otherwise need "friend" access if it were developed in C++.
>>
>> Yeah this was related to benefits around being able to keep some things private from your friends (which is not d-able currently).
>
> ===
> module mypack.publicstuff.stuff.secretstuff;
>
> class SecretStuff {
>    public foo {}
>    package friendlyFoo {]
>    private secretFoo {]
> }
>
> ===
> module mypack.publicstuff.stuff.friends;
>
> void beFriendly(SecretStuff s) {
>    s.friendlyFoo();
> }
> ...
> ===
> module mypack.publicstuff;
>
> public import mypack.publicstuff.stuff.friends,
>               mypack.publicstuff.stuff.secretstuff;
>
> ...
> ===

Ha! Seems it is d-able.

project/
-- type/
---- package.d // definition of type
---- friends.d // can access package of type and not private of type

Thanks, added that data to da faq.

On Fri, 2019-10-18 at 14:01 +0000, Guillaume Piolat via Digitalmars-d wrote: […]
> Where is no data or conclusive evidence, there are some anecdotes.

But that is the point, they are anecdotes, reports of individual's experience. Very useful for building theories and hypotheses, but definitely not conclusive evidence.

> - some people with large python codebases, even full-time, tend to tell me that dynamic types don't "scale" that well past 10 kLOC

And some people have no problem using dynamic types with 10kLOC codebases.

> - some problems reveal themselves "at scale". For example in a C++ constructor you can leave a filed uninitialized. I've once 2 weeks on such a bug that cascaded in a complicated system.  D has .init and would have avoided that.

Which is good.

> - Java seems to scale exceptionally well thanks to a culture of reuse and comparably simple language

That there are some very big Java codebases doesn't necessarily support the thesis that Java supports scaling. That some people have found ways of working with big codebases is a testament to their ingenuity as much as it is to the classes and packages. But yes packages definitely help with all languages that have them – we could posit that as a theory.

> I don't think it's all in our heads that some language are more conducive to "scale", whatever that means.

If we do not define "scaling" then there can be no statement of "some language support scaling better than others". We need to be clear what we mean by scaling in codebases, but I thought we had a common definition of this already.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On 20/10/2019 10:39 PM, Nicholas Wilson wrote:
> On Sunday, 20 October 2019 at 03:41:08 UTC, Walter Bright wrote:
>> On 10/19/2019 6:52 PM, Nicholas Wilson wrote:
>>> On Saturday, 19 October 2019 at 23:38:51 UTC, aliak wrote:
>>>> Plus, IIRC dmd is a prime example where splitting is not happening because of "reasons". So it's not always doable either.
>>> Those reasons are largely "Walter" and are unrelated.
>>
>> I know I'm not popular with this idea, but packagizing dmd is akin to painting a rusty/dirty car without prepping the metal first.
> 
> Obviously I think you're wrong, but for the sake of getting shit done:
> Do you mean to imply that now is not the time, as opposed to it will never happen?
> Because it _really_ needs to happen, and the sooner the better, as Rikki notes it is an absolute requirement compiler as a library.
> 
>   If so, what do you think needs to happen before that?

While I agree with your sentimentality, this is not something worth fighting over until a solid use case comes up.

Because of dub its already separated out when loaded in an IDE.

My estimate based upon my last evaluation around 6-8 months ago was it would take around a week of concentrated effort to get the lexer into a good state for use as a library. The parser would be ridiculous compared to this (includes AST).

Semantic analysis while needing to be callable shouldn't need its internals exposed.

Point is, you will end up needing a dmd developer even if we were to separate out the lexer today and get it into a good state. If he wants to leave it for now we should. He has a lot of other things on his mind which are far more important.

On 10/20/2019 2:57 AM, Russel Winder wrote:
> If we do not define "scaling" then there can be no statement of "some language
> support scaling better than others". We need to be clear what we mean by
> scaling in codebases, but I thought we had a common definition of this
> already.

I don't know what the common definition of it is, but I'd define it as the complexity of the code goes up linearly with the number of lines. I'd say the close the complexity is to linear, the better it "scales".

I'd then define complexity as the number of interactions between the lines of code.

This means that the better a language supports encapsulation, the more scalable it is.

For example, if a language has only one namespace, the larger it gets, the harder it is to declare a new variable, as it would have to be unique. This would be a quadratic increase in complexity as the number of declarations increased.

On Sunday, 20 October 2019 at 10:08:29 UTC, rikki cattermole wrote:
> While I agree with your sentimentality, this is not something worth fighting over until a solid use case comes up.

You mean apart from chunking up a 125 file megapackage? Because thats the use case to me, not so much compiler as a library although that has packaging and aa sane codebase as a prerequisite.
 DMD is an actively hostile codebase to comprehend and reason about precisely because it is unstructured, not within files or sprawling dependencies across files, but that the is no logical structuring to the codebase imposed despite that it obviously exists.

See https://github.com/dlang/dmd/pull/9844#issuecomment-498110957 for an example of the less than exemplary behaviour from the leadership. That veiled threat is more true than ever.

If there is a exists path to the packaging of dmd it needs to be made clear by Walter and progress can be made towards it. If not, then he should accept the fate of a dearth of contributors that follows and the consequences that entails.

> If he wants to leave it for now we should. He has a lot of other things on his mind which are far more important.

On the contrary, the malorganised state of the (lack of) packages is one of _the_ top barriers to entry.

On Sunday, 20 October 2019 at 06:44:45 UTC, Russel Winder wrote:
> On Sun, 2019-10-20 at 03:23 +0000, John Belmonte via Digitalmars-d wrote:
>> 
> […]
>> Rust appears to be going down the wrong concurrency path.
> […]
>
> I believe you need to expand on this claim. As far as I am aware there are a number of structured concurrency crates, e.g. Rayon.

long discussion here:  https://trio.discourse.group/t/structured-concurrency-in-rust/

My summary as an onlooker:
  * Rust and/or the structured concurrency libraries don't have cancellation scopes (see https://vorpus.org/blog/timeouts-and-cancellation-for-humans/)
  * Rust has a competing ecosystem by way of futures, which adds significant API complexity and fractures the concurrency ecosystem for no advantage over async/await + structured concurrency

excerpt:
>> There are multiple crates out there that implement coroutines, but for now the futures ecosystem seems to be some orders of magnitude more popular.
>
> Right – if you don’t have compiler support, then coroutines are really inefficient (you need to allocate big stacks, like threads) and futures are the only viable path. If you do have compiler support, then they’re equally efficient, and coroutines are simpler and easier to work with.
>
> That’s why async is such a trap for language designers: if you knew from the start that you were going to add syntax/compiler-support for async, then coroutines would be the obvious way to go. But generally by the time you’ve convinced yourself that you need syntax/compiler support, then you already have a large futures ecosystem, and you’ve trained yourself to think in terms of futures. It’s very difficult to step back and realize that as soon as you add async syntax, all your awesome futures APIs, which were important and tricky and crucial, suddenly become unnecessary bloat.

On Sunday, 20 October 2019 at 06:01:23 UTC, Walter Bright wrote:
> On 10/16/2019 12:28 PM, H. S. Teoh wrote:
>> Given how much time and effort has been poured
>> into -betterC recently,
>
> It wasn't that much. It was mainly turning some things off. I probably spent more time documenting it, writing an article, and doing a presentation on it than implementation.
I think its very important that this was said and I think it should be repeated in the future. Too many people incorrectly estimate the cost of things and then come to the wrong conclusions

On Sun, Oct 20, 2019 at 01:00:22PM +0000, welkam via Digitalmars-d wrote:
> On Sunday, 20 October 2019 at 06:01:23 UTC, Walter Bright wrote:
> > On 10/16/2019 12:28 PM, H. S. Teoh wrote:
> > > Given how much time and effort has been poured into -betterC recently,
> > 
> > It wasn't that much. It was mainly turning some things off. I probably spent more time documenting it, writing an article, and doing a presentation on it than implementation.
>
> I think its very important that this was said and I think it should be repeated in the future. Too many people incorrectly estimate the cost of things and then come to the wrong conclusions

And that is exactly why I said we need official statements on this sort of things.  It's an important part of communicating with the community.


T

-- 
A computer doesn't mind if its programs are put to purposes that don't match their names. -- D. Knuth