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