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