www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D forbearance(Official backing of libs)

reply Jason Jeffory <JasonJeffory doodle.com> writes:
I think maybe one of the problems with D is that there seems to 
be no focused backing of official d libs that are required to 
create apps.

e.g., GUI, Audio, Graphics, etc...

If the D community could decide to officially support(with a 
distinct web page for such things) such libraries, real progress 
might be made.

So much work is done on the compiler itself but most of the 
actually things required to make real world use of the compiler 
are neglected, It's left up to individuals to do the work and 
make all the choices.

But there is a different mentality that happens when it's 
"Official". Others are more willing to support, develop, and use 
it.

Is this at all possible in the D community?
Jan 01
next sibling parent reply tsbockman <thomas.bockman gmail.com> writes:
On Saturday, 2 January 2016 at 00:20:37 UTC, Jason Jeffory wrote:
 I think maybe one of the problems with D is that there seems to 
 be no focused backing of official d libs that are required to 
 create apps.

 e.g., GUI, Audio, Graphics, etc...

 If the D community could decide to officially support(with a 
 distinct web page for such things) such libraries, real 
 progress might be made.

 So much work is done on the compiler itself but most of the 
 actually things required to make real world use of the compiler 
 are neglected, It's left up to individuals to do the work and 
 make all the choices.

 But there is a different mentality that happens when it's 
 "Official". Others are more willing to support, develop, and 
 use it.

 Is this at all possible in the D community?
Making a competitive GUI library is a MASSIVE task. While there are some usable options available for D currently, I think the most desirable solution is to make a high quality Qt binding. Various people have looked into doing so in the past, but I think they were stalled by D's immature C++ interop. There have been great strides forward in this area recently, and work is ongoing. I'd bet a Qt binding will be viable within a year or two, if it's not already. As to graphics - it depends on your use case. If you're thinking of 3D simulations and games, I was under the impression that the D ecosystem already covers the basics (OpenGL, SDL, SFML) fairly well. I'm not sure about audio. More generally, though - there is a lot of work going into the compiler and the standard library because they need it quite badly. With basic issues like safe non-GC memory management yet unresolved, I don't think it would yet be beneficial to D in the long run to shift attention away towards other parts of the ecosystem. The C++ interop, especially, will do far more to expand the D ecosystem than the relatively small team working on it could possibly accomplish by just writing more D libraries.
Jan 01
parent reply Jason Jeffory <JasonJeffory doodle.com> writes:
On Saturday, 2 January 2016 at 00:56:42 UTC, tsbockman wrote:
 On Saturday, 2 January 2016 at 00:20:37 UTC, Jason Jeffory 
 wrote:
 I think maybe one of the problems with D is that there seems 
 to be no focused backing of official d libs that are required 
 to create apps.

 e.g., GUI, Audio, Graphics, etc...

 If the D community could decide to officially support(with a 
 distinct web page for such things) such libraries, real 
 progress might be made.

 So much work is done on the compiler itself but most of the 
 actually things required to make real world use of the 
 compiler are neglected, It's left up to individuals to do the 
 work and make all the choices.

 But there is a different mentality that happens when it's 
 "Official". Others are more willing to support, develop, and 
 use it.

 Is this at all possible in the D community?
Making a competitive GUI library is a MASSIVE task. While there are some usable options available for D currently, I think the most desirable solution is to make a high quality Qt binding. Various people have looked into doing so in the past, but I think they were stalled by D's immature C++ interop. There have been great strides forward in this area recently, and work is ongoing. I'd bet a Qt binding will be viable within a year or two, if it's not already. As to graphics - it depends on your use case. If you're thinking of 3D simulations and games, I was under the impression that the D ecosystem already covers the basics (OpenGL, SDL, SFML) fairly well. I'm not sure about audio. More generally, though - there is a lot of work going into the compiler and the standard library because they need it quite badly. With basic issues like safe non-GC memory management yet unresolved, I don't think it would yet be beneficial to D in the long run to shift attention away towards other parts of the ecosystem. The C++ interop, especially, will do far more to expand the D ecosystem than the relatively small team working on it could possibly accomplish by just writing more D libraries.
I think you misunderstand. I realize that D has a ton of library solutions... I am talking about having the "top dogs" come out and decide to support one or the other "officially" and try to turn it into something that people can use knowing that it is "supported". D, as a compiler, might be amazing but without any proper tools to make it do things that are common, it won't be used much. By proper, I mean "officially supported". (basically it means Walter and Andrei come out and decide to support one of the current packages or to start the push on a new one)
Jan 01
parent tsbockman <thomas.bockman gmail.com> writes:
On Saturday, 2 January 2016 at 01:18:45 UTC, Jason Jeffory wrote:
 I think you misunderstand. I realize that D has a ton of 
 library solutions... I am talking about having the "top dogs" 
 come out and decide to support one or the other "officially" 
 and try to turn it into something that people can use knowing 
 that it is "supported".

 D, as a compiler, might be amazing but without any proper tools 
 to make it do things that are common, it won't be used much. By 
 proper, I mean "officially supported". (basically it means 
 Walter and Andrei come out and decide to support one of the 
 current packages or to start the push on a new one)
This would accomplish little unless Walter and Andrei actually invested their own time working on such "officially supported" packages; although they are highly respected and have veto power over things like language changes, no one around here actually takes orders from them. My point was that their time is better spent on what they are already doing: improving the core language facilities, to make it easier for others who are so inclined to build/bind to the library solutions you are looking for.
Jan 01
prev sibling next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
So, if you consider me a "top dog" then yes we're getting it.
Of course I am only really a commoner round these parts.

I'm almost ready to ask for feedback for windowing and image library 
(stage 1 and 2 out of like 4 for each).

Now in terms of audio, honestly?
Its a difficult task, unless you're into that area you won't be writing 
the primitives or input/output mechanisms.

Lastly a GUI toolkit. Of course everyone wants that in Phobos.
Yeah not going to happen. At least once we have all the more core 
libraries in Phobos we can start experimenting in creating them.

Hopefully in the 10 year plan we could get a GUI toolkit that is 
"standard" but who knows.

[0] 
https://github.com/rikkimax/alphaPhobos/tree/master/source/std/experimental
Jan 01
next sibling parent reply Jason Jeffory <JasonJeffory doodle.com> writes:
On Saturday, 2 January 2016 at 01:26:30 UTC, Rikki Cattermole 
wrote:
 So, if you consider me a "top dog" then yes we're getting it.
 Of course I am only really a commoner round these parts.

 I'm almost ready to ask for feedback for windowing and image 
 library (stage 1 and 2 out of like 4 for each).

 Now in terms of audio, honestly?
 Its a difficult task, unless you're into that area you won't be 
 writing the primitives or input/output mechanisms.

 Lastly a GUI toolkit. Of course everyone wants that in Phobos.
 Yeah not going to happen. At least once we have all the more 
 core libraries in Phobos we can start experimenting in creating 
 them.

 Hopefully in the 10 year plan we could get a GUI toolkit that 
 is "standard" but who knows.

 [0] 
 https://github.com/rikkimax/alphaPhobos/tree/master/source/std/experimental
10 years? Half the people here will be dead! lol... The sooner the better. I'm not talking about a massive roundup of all resources and using them to develop this stuff. Again, much of the stuff has already been done. I'm talking about *focus*. A focused mental effort to have a plan of action. If you built it, they will come! If you don't, well, they won't.
Jan 01
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 02/01/16 2:38 PM, Jason Jeffory wrote:
 On Saturday, 2 January 2016 at 01:26:30 UTC, Rikki Cattermole wrote:
 So, if you consider me a "top dog" then yes we're getting it.
 Of course I am only really a commoner round these parts.

 I'm almost ready to ask for feedback for windowing and image library
 (stage 1 and 2 out of like 4 for each).

 Now in terms of audio, honestly?
 Its a difficult task, unless you're into that area you won't be
 writing the primitives or input/output mechanisms.

 Lastly a GUI toolkit. Of course everyone wants that in Phobos.
 Yeah not going to happen. At least once we have all the more core
 libraries in Phobos we can start experimenting in creating them.

 Hopefully in the 10 year plan we could get a GUI toolkit that is
 "standard" but who knows.

 [0]
 https://github.com/rikkimax/alphaPhobos/tree/master/source/std/experimental
10 years? Half the people here will be dead! lol... The sooner the better. I'm not talking about a massive roundup of all resources and using them to develop this stuff. Again, much of the stuff has already been done. I'm talking about *focus*. A focused mental effort to have a plan of action. If you built it, they will come! If you don't, well, they won't.
Focused? really? Yeah no. Big companies like Facebook, Google and Microsoft spend a lot of money on UI design. Not to mention efforts such as Qt. Its a big job. As a community focused language we cannot expect it to happen. At this stage the best way we can go is build the necessary tools for somebody who is able to make said GUI toolkit. Unless you have a few million dollars to throw at this, I wouldn't expect it to happen anytime soon. Although you're welcome to help out. I have lists of things that would contribute towards these goals if you want.
Jan 01
prev sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Saturday, 2 January 2016 at 01:26:30 UTC, Rikki Cattermole 
wrote:
 Lastly a GUI toolkit. Of course everyone wants that in Phobos.
 Yeah not going to happen. At least once we have all the more 
 core libraries in Phobos we can start experimenting in creating 
 them.

 Hopefully in the 10 year plan we could get a GUI toolkit that 
 is "standard" but who knows.
Allocators took years and many rewrites IIRC. As of now only Andrei knows how to Design by Introspection so Though we can know the thought process with: https://www.youtube.com/watch?v=LIb3L4vKZ7U Personally I'm waiting eagerly for guidelines for achieving DbI with merely human abilities :), else we library-writers make libraries that look like C++ instead of Phobos-quality. Let's be patient?
Jan 01
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 2 January 2016 at 00:20:37 UTC, Jason Jeffory wrote:
 If the D community could decide to officially support(with a 
 distinct web page for such things) such libraries, real 
 progress might be made.
They've attempted this before. DWT was crowned the official library for a while and got its own forum http://forum.dlang.org/group/dwt a note on the home page, etc. Never really went anywhere though. Of course, they never really aggressively marketed it either. Every so often, Andrei asks me to put my libs through the formal process to be included in Phobos. I'm actually not inclined to do that for a lot of reasons, including the slowdown such a thing would bring to me. See, with me doing them myself, I can unilaterally make changes at any time. I've gotten bug reports and had a fix live inside ten minutes. Phobos doesn't, and probably can't, work at that kind of pace. And if it did get other contributions, there's a good chance I'd lose my mental model of the code and be slowed down by that. Bottom line, if my libs were to join phobos, it'd probably end my involvement in their development. (I'm also sure my code would never pass the rigor of technical review anyway. I use tabs.)
Jan 01
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Saturday, 2 January 2016 at 01:39:58 UTC, Adam D. Ruppe wrote:
 I've gotten bug reports and had a fix live inside ten minutes. 
 Phobos doesn't, and probably can't, work at that kind of pace.
No kidding...
Jan 01
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/1/16 9:11 PM, tsbockman wrote:
 On Saturday, 2 January 2016 at 01:39:58 UTC, Adam D. Ruppe wrote:
 I've gotten bug reports and had a fix live inside ten minutes. Phobos
 doesn't, and probably can't, work at that kind of pace.
No kidding...
How do you mean that? It can, and it does. It has often happened that bugs have been quickly fixed. -- Andrei
Jan 03
next sibling parent tsbockman <thomas.bockman gmail.com> writes:
On Sunday, 3 January 2016 at 15:18:30 UTC, Andrei Alexandrescu 
wrote:
 On 1/1/16 9:11 PM, tsbockman wrote:
 On Saturday, 2 January 2016 at 01:39:58 UTC, Adam D. Ruppe 
 wrote:
 I've gotten bug reports and had a fix live inside ten 
 minutes. Phobos
 doesn't, and probably can't, work at that kind of pace.
No kidding...
How do you mean that? It can, and it does. It has often happened that bugs have been quickly fixed. -- Andrei
Trivial fixes to Phobos or DMD might take, on average, two days to get merged, and the average user won't see any benefit until the next stable release, which happens one or two months later. Non-trivial fixes to Phobos or DMD take months or years to get merged. In either case, there is often a 90% fix available right from the start, but rather than merging it quickly to mitigate the bug, the PR will be stalled until it is deemed "ready" (which may be never). Don't misunderstand me - I recognize that there are advantages to the current approach, as well. Nevertheless, it ought not to be controversial, to say that Phobos and DMD development is a high-latency process.
Jan 03
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 3 January 2016 at 15:18:30 UTC, Andrei Alexandrescu 
wrote:
 How do you mean that? It can, and it does. It has often 
 happened that bugs have been quickly fixed. -- Andrei
Maybe quickly fixed in git, but usually not in the user's system since the average user waits for the next release to update Phobos.. which sometimes breaks their build. My libs are just independent files they can download at any time with little risk. To test a new version of simpledisplay.d for example: mv simpledisplay.d simpledisplay.d.old wget https://raw.githubusercontent.com/adamdruppe/arsd/master/simpledisplay.d make And see what happens. No need to mess with git dmd or anything like you do to use a prerelease Phobos version.
Jan 03
parent Dicebot <public dicebot.lv> writes:
On Sunday, 3 January 2016 at 21:10:53 UTC, Adam D. Ruppe wrote:
 On Sunday, 3 January 2016 at 15:18:30 UTC, Andrei Alexandrescu 
 wrote:
 How do you mean that? It can, and it does. It has often 
 happened that bugs have been quickly fixed. -- Andrei
Maybe quickly fixed in git, but usually not in the user's system since the average user waits for the next release to update Phobos.. which sometimes breaks their build. My libs are just independent files they can download at any time with little risk. To test a new version of simpledisplay.d for example: mv simpledisplay.d simpledisplay.d.old wget https://raw.githubusercontent.com/adamdruppe/arsd/master/simpledisplay.d make And see what happens. No need to mess with git dmd or anything like you do to use a prerelease Phobos version.
That is exactly the reason why I have been concerned about creation of std.experimental :(
Jan 03