www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D3 - Programming in 3D

reply Chris <wendlec tcd.ie> writes:
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
Jun 12 2020
next sibling parent reply oddp <oddp posteo.de> writes:
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
Jun 12 2020
parent Chris <wendlec tcd.ie> writes:
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.
Jun 15 2020
prev sibling next sibling parent reply mw <mingwu gmail.com> writes:
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.
Jun 12 2020
parent reply Chris <wendlec tcd.ie> writes:
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.
Jun 15 2020
parent aberba <karabutaworld gmail.com> writes:
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.
Jun 15 2020
prev sibling next sibling parent reply angel <andrey.gelman gmail.com> writes:
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.
Jun 12 2020
next sibling parent reply drug007 <drug2004 bk.ru> writes:
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.
Jun 12 2020
parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Friday, 12 June 2020 at 21:00:20 UTC, drug007 wrote:

 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.


Your scenario sounds totally predictable? With refcounting you 
get a "free" mark phase (ref goes to 0), and then you know you're 
holding the only reference so you can just hand it off to a 
cleanup thread and stop thinking about it for the low cost of an 
atomic write.

Now, cycles do make it fully GC but they're in the control of the 
developer and can usually be broken with weak pointers. In 
general, people don't mind costs so long as they feel they're 
responsible for them and can do something about them. This is why 
people will always distrust stop-the-world GC for realtime tasks.
Jun 15 2020
parent reply drug <drug2004 bk.ru> writes:
15.06.2020 13:40, FeepingCreature пишет:

 Your scenario sounds totally predictable? With refcounting you get a 
 "free" mark phase (ref goes to 0), and then you know you're holding the 
 only reference so you can just hand it off to a cleanup thread and stop 
 thinking about it for the low cost of an atomic write.
 


How do you know that you have the only reference? the node can be both 
the root and a leaf node.


 Now, cycles do make it fully GC but they're in the control of the 
 developer and can usually be broken with weak pointers. In general, 
 people don't mind costs so long as they feel they're responsible for 
 them and can do something about them. This is why people will always 
 distrust stop-the-world GC for realtime tasks.
Jun 15 2020
parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Monday, 15 June 2020 at 14:38:31 UTC, drug wrote:

 15.06.2020 13:40, FeepingCreature пишет:

 Your scenario sounds totally predictable? With refcounting you 
 get a "free" mark phase (ref goes to 0), and then you know 
 you're holding the only reference so you can just hand it off 
 to a cleanup thread and stop thinking about it for the low 
 cost of an atomic write.
 


 How do you know that you have the only reference? the node can 
 be both the root and a leaf node.


You know you have the only reference because your refcount goes 
to 0...
Jun 16 2020
parent reply drug <drug2004 bk.ru> writes:
16.06.2020 13:23, FeepingCreature пишет:

 On Monday, 15 June 2020 at 14:38:31 UTC, drug wrote:

 15.06.2020 13:40, FeepingCreature пишет:

 Your scenario sounds totally predictable? With refcounting you get a 
 "free" mark phase (ref goes to 0), and then you know you're holding 
 the only reference so you can just hand it off to a cleanup thread 
 and stop thinking about it for the low cost of an atomic write.


 How do you know that you have the only reference? the node can be both 
 the root and a leaf node.


 
 You know you have the only reference because your refcount goes to 0...


How do you know how many childs this node has? You don't know the height 
of the subtree, so you can't predict how many childs will be freed.
Jun 16 2020
parent FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 16 June 2020 at 12:35:35 UTC, drug wrote:

 16.06.2020 13:23, FeepingCreature пишет:

 On Monday, 15 June 2020 at 14:38:31 UTC, drug wrote:

 15.06.2020 13:40, FeepingCreature пишет:

 Your scenario sounds totally predictable? With refcounting 
 you get a "free" mark phase (ref goes to 0), and then you 
 know you're holding the only reference so you can just hand 
 it off to a cleanup thread and stop thinking about it for 
 the low cost of an atomic write.


 How do you know that you have the only reference? the node 
 can be both the root and a leaf node.


 
 You know you have the only reference because your refcount 
 goes to 0...


 How do you know how many childs this node has? You don't know 
 the height of the subtree, so you can't predict how many childs 
 will be freed.


The point is you don't need to worry about this memory in the 
main thread anymore, so you can gradually free it in a background 
thread and it doesn't matter how many children it has, because 
the problem with memory management isn't CPU consumption but 
latency, and the latency of "send this pointer to the cleanup 
thread" is constant.
Jun 17 2020
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Jun 12 2020
parent Chris <wendlec tcd.ie> writes:
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?
Jun 15 2020
prev sibling parent IGotD- <nise nise.com> writes:
On Friday, 12 June 2020 at 20:35:03 UTC, angel wrote:

 3. Reference counted memory management. It is predictable.


Which D supports today, but only explicitly.

If you want it built in today we would need two pointer types. 
Raw pointers and pointers to fat pointer structures.

raw pointer -> whatever
fat pointer -> fat pointer structure -> whatever

It will a new language and we will call it "D Phat".
Jun 15 2020
prev sibling next sibling parent Luis <luis.panadero gmail.com> writes:
If someone accepts my humble opinions.
On Friday, 12 June 2020 at 13:12:35 UTC, Chris wrote:

 How would you go about D3?

     1. Which features would you keep?


Interop with C and C++, metaprograming with mixins & templates.


     2. Which features would you definitely get rid of?
     3. What type(s) of memory management would you chose?


I don't know, but at least a way to use GC, ref counting or 
malloc/free on a more transparent way. Perhaps like Beeflang 
handles allocators.


     4. How would you design Phobos?


I really miss a solid collections framework. Perhaps it's my Java 
background speaking here, but I really miss allow to declare a 
attribute/variable to a Map interface and initialize with a 
specific implementation of Map.

Another option it's to have a lightweight Phobos and have some 
community sanctioned dub packages that implements basic stuff 
like collections framework, xml/json/whatever serialization, test 
runner, etc.



     5. What restrictions would you impose? (see below)
     6. How would you handle backwards compatibility?


A flag to change between language versions ? ie --release d3 and 
--release d2
Also, the rust epoch's idea, looks interesting. And the 
suggestion of Andrei about versions the standard library it's 
interesting : 
https://forum.dlang.org/post/rc3a7r$178f$1 digitalmars.com


     7. How would you design the tooling?


Q. Schroll "mini dip" of alternative way to declare a mixing 
string, would make a lot more easy to IDE/tools to check the 
mixing code. Something similar should be considered.


     8. How would you make it “industry friendly”? (see below)



 D3 - Programming in 3D
Jun 15 2020
prev sibling parent reply Ernesto Castellotti <erny.castell gmail.com> writes:
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)

 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


Removing new 
(https://dlang.org/spec/expression.html#new_expressions) and 
replacing it with a library-based solution (such as 
https://dlang.org/phobos/std_experimental_allocator.html)
New is seen as the obligation to use the gc, we need a new 
solution that includes the choice of allocator.

I know that you can currently choose but it is not a great 
marketing to propose two methods of allocating one of which uses 
gc and the other would be excellent but it has been 
"experimental" for years
Jun 15 2020
parent Luis <luis.panadero gmail.com> writes:
On Monday, 15 June 2020 at 22:30:23 UTC, Ernesto Castellotti 
wrote:

 Removing new 
 (https://dlang.org/spec/expression.html#new_expressions) and 
 replacing it with a library-based solution (such as 
 https://dlang.org/phobos/std_experimental_allocator.html)
 New is seen as the obligation to use the gc, we need a new 
 solution that includes the choice of allocator.

 I know that you can currently choose but it is not a great 
 marketing to propose two methods of allocating one of which 
 uses gc and the other would be excellent but it has been 
 "experimental" for years


You not need to removed new. Only to improve it. Again... I think 
that the approach that BeefLang did it's really good on this :

String AllocGlobalString(int len)
{
     return new String(len);
}
String AllocCustomString(int len)
{
     return new:customAllocator String(len);
}
Jun 16 2020