How would you go about D3?

    1. Which features would you keep?
    2. Which features would you definitely get rid of?
    3. What type(s) of memory management would you chose?
    4. How would you design Phobos?
    5. What restrictions would you impose? (see below)
    6. How would you handle backwards compatibility?
    7. How would you design the tooling?
    8. How would you make it “industry friendly”? (see below)

As to point 5: I know that it’s great to have a lot of freedom (I know: freedom => responsibility). However, there’s a reason why a lot of programming languages impose certain restrictions on the programmer. E.g. if every library is designed differently, it’s hard to build up a proper ecosystem of libs and reusable code. There’s the aspect of security too.

As to point 8: it closely ties in with point 7. Approach it from the point of view of a project manager or a small tech company. It is important that it is easy to set up and use (IDE, toolchain) and that it caters for different needs. One of the first questions will be how well it ties in with other technologies (e.g. C interop) and if it can easily be ported to the most common platforms (Android, iOS etc.) and architectures. It should be as easy as writing a few lines of a CMake file to cross compile and it should easily interop with the host OS (e.g. it can be laoded as a dynamic lib out of the box). IMO, this is something one should think about right from the start and not leave for later, especially because D already has features that would facilitate this.

D3 - Programming in 3D

On 2020-06-12 15:12, Chris via Digitalmars-d wrote:
> How would you go about D3?

I would take a long, hard look at rust's epochs [1][2] and see if and how that process could be adapted for d, similar to what some c++ folks are trying to do[3], before even thinking about dividing the community.

[1] https://github.com/rust-lang/rfcs/blob/master/text/2052-epochs.md
[2] https://github.com/rust-lang/rfcs/pull/2052
[3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html

On Friday, 12 June 2020 at 13:12:35 UTC, Chris wrote:
> How would you go about D3?

Taking into account of the questions in your other thread:

https://forum.dlang.org/thread/hamqlfpwrxnyzwydfwqv@forum.dlang.org

Are you planning to provide funding for D3 dev? :-)

It will be always welcomed, even for D2.

On Friday, 12 June 2020 at 13:12:35 UTC, Chris wrote:
> How would you go about D3?
>
>     1. Which features would you keep?
>     2. Which features would you definitely get rid of?
>     3. What type(s) of memory management would you chose?
>     4. How would you design Phobos?
>     5. What restrictions would you impose? (see below)
>     6. How would you handle backwards compatibility?
>     7. How would you design the tooling?
>     8. How would you make it “industry friendly”? (see below)

3. Reference counted memory management. It is predictable.
5. I would design layered restrictions, kinda @most_restricted, @very_restricted, @slightly_restricted, @c_style
6. I would handle backward compatibility responsibly, but without fanaticism - occasionally one must cut through the live tissue.
7. I don't know how to design tooling, but it definitely won't fly without tooling.
8. Interoperability and good tooling are your entrance tickets to the industry.
---
I actually don't think D needs D3.
Designing a perfect language right from the start is possible probably only in theory, but in the real life evolution works better - you add missing features, you drop what doesn't belong, otherwise you risk to end where you start.

On Friday, 12 June 2020 at 20:35:03 UTC, angel wrote:
> 3. Reference counted memory management. It is predictable.

Sorry for offtopic but why do you think so? Reference counted memory management is a form of garbage collection and is unpredictable too. Imagine you have a large tree and you free the last reference to a node. All child of this node will be freed and this process takes time depending on child nodes count. It is unpredictable in general.

On Fri, Jun 12, 2020 at 08:35:03PM +0000, angel via Digitalmars-d wrote: [...]
> I actually don't think D needs D3.
> Designing a perfect language right from the start is possible probably
> only in theory, but in the real life evolution works better - you add
> missing features, you drop what doesn't belong, otherwise you risk to
> end where you start.

What is needed, IMO, is a language where change is both anticipated and prepared for, where language versioning is built into the language itself. I.e., each file should have some kind of version identifier to indicate what version of the language it is intended for, and the semantics of that language version will be applied. Interop between modules written to different language versions will be supported as much as is practical (obviously, sometimes it won't work if language semantics have changed drastically enough that ABI compatibility is impossible).  Older versions of the language will be supported by the compiler up to N major releases back (where N is some predetermined number, preferably infinity though that's probably impractical :P).

The compiler code will also be structured in such a way that upon every major release, current code is copied into a self-contained package dedicated for that major release's language version, and thereafter only updated for bugfixes. The "main" code continues to be developed without restriction.

The idea is that development will never stop, and the language will continue to improve and embrace change, even breaking changes where necessary, but existing code will continue to work up to N releases, and can continue to interop with new code where language semantics don't contradict between the language versions. Newer versions of the language need not be constrained by decisions made in the past, because existing code will still be compiled with old semantics until the authors decide to bump the version tag (and fix any issues that may result).


T

-- 
Valentine's Day: an occasion for florists to reach into the wallets of nominal lovers in dire need of being reminded to profess their hypothetical love for their long-forgotten.

On Friday, 12 June 2020 at 15:47:54 UTC, oddp wrote:
> On 2020-06-12 15:12, Chris via Digitalmars-d wrote:
>> How would you go about D3?
>
> I would take a long, hard look at rust's epochs [1][2] and see if and how that process could be adapted for d, similar to what some c++ folks are trying to do[3], before even thinking about dividing the community.
>
> [1] https://github.com/rust-lang/rfcs/blob/master/text/2052-epochs.md
> [2] https://github.com/rust-lang/rfcs/pull/2052
> [3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html

Dividing the community? Always these heavy words that evoke emotions - in a tech context. Don't you remember this post:

https://forum.dlang.org/thread/r5l7no$317c$1@digitalmars.com?page=1

I don't think Steven is trying to divide the community. He just stated the obvious that everybody who has used D for a while knows.

On Friday, 12 June 2020 at 18:57:26 UTC, mw wrote:
> On Friday, 12 June 2020 at 13:12:35 UTC, Chris wrote:
>> How would you go about D3?
>
> Taking into account of the questions in your other thread:
>
> https://forum.dlang.org/thread/hamqlfpwrxnyzwydfwqv@forum.dlang.org
>
> Are you planning to provide funding for D3 dev? :-)
>
> It will be always welcomed, even for D2.

If I had that sort of money and I wanted to create something like D3, I would certainly not give it to the D Foundation. It's not even clear to me how the Foundation's structure looks like (e.g. Atila in or out?), how the money is spent (by whom and on what), and they don't even answer when you ask them.

On Friday, 12 June 2020 at 21:16:03 UTC, H. S. Teoh wrote:

>
> What is needed, IMO, is a language where change is both anticipated and prepared for, where language versioning is built into the language itself. I.e., each file should have some kind of version identifier to indicate what version of the language it is intended for, and the semantics of that language version will be applied. Interop between modules written to different language versions will be supported as much as is practical (obviously, sometimes it won't work if language semantics have changed drastically enough that ABI compatibility is impossible).  Older versions of the language will be supported by the compiler up to N major releases back (where N is some predetermined number, preferably infinity though that's probably impractical :P).
>
> [...]

Thanks. That's an interesting answer. I like your ideas. How difficult would it be to reshape D into something like that?

On Monday, 15 June 2020 at 10:21:17 UTC, Chris wrote:
> On Friday, 12 June 2020 at 18:57:26 UTC, mw wrote:
>> On Friday, 12 June 2020 at 13:12:35 UTC, Chris wrote:
>>> How would you go about D3?
>>
>> Taking into account of the questions in your other thread:
>>
>> https://forum.dlang.org/thread/hamqlfpwrxnyzwydfwqv@forum.dlang.org
>>
>> Are you planning to provide funding for D3 dev? :-)
>>
>> It will be always welcomed, even for D2.
>
> If I had that sort of money and I wanted to create something like D3, I would certainly not give it to the D Foundation.


> and on what), and they don't even answer when you ask them.

Thats sucks but yeah, its true. This communication things has been mentioned for yrs here.