www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Vision for the first semester of 2016

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
Jan 24 2016
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/01/16 3:37 PM, Andrei Alexandrescu wrote:

 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


There is a couple of things I want on there.

1. scope to be fixed and fully implemented
    (I'll bring some use cases to the table)
2.  assumenogc or something similar.
    That way IAllocator can be  nogc. Which to me is a requirement 
before it is out of experimental.

Number 1 is the most important for me. Otherwise there will be no 
review/PR for image library this year.
Jan 24 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/24/2016 10:07 PM, Rikki Cattermole wrote:

 1. scope to be fixed and fully implemented
     (I'll bring some use cases to the table)
 2.  assumenogc or something similar.
     That way IAllocator can be  nogc. Which to me is a requirement
 before it is out of experimental.


Both are under the larger headline "Memory Management." -- Andrei
Jan 24 2016
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/01/16 4:13 PM, Andrei Alexandrescu wrote:

 On 01/24/2016 10:07 PM, Rikki Cattermole wrote:

 1. scope to be fixed and fully implemented
     (I'll bring some use cases to the table)
 2.  assumenogc or something similar.
     That way IAllocator can be  nogc. Which to me is a requirement
 before it is out of experimental.


 Both are under the larger headline "Memory Management." -- Andrei


Okay, I like specifics since then you can tick it off for next round ;)
Jan 24 2016
prev sibling next sibling parent tsbockman <thomas.bockman gmail.com> writes:
On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:

 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


Something went wrong here:


 We fell short of our 2000 pull requests goal in H2 2015. We 
 have had only 1 1378 pull requests.


In addition to the extraneous "1", the link is bad: "No results 
matched your search."
Jan 24 2016
prev sibling next sibling parent reply Puming <zhaopuming gmail.com> writes:
On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:

 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


For PRs, I suggest the goal to be number of PRs MERGED instead of 
created. That may provide the core team a subconsious incentive 
to look at long pending PRs and hit a good cycle.

For tooling, I suggest a look at GUI/IDEs, now that 
dlangui/dlangide seems a good candidate(native D, crossplatform). 
A good official supported GUI library will attract many people.
Jan 24 2016
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/01/16 4:21 PM, Puming wrote:

 On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote:

 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


 For PRs, I suggest the goal to be number of PRs MERGED instead of
 created. That may provide the core team a subconsious incentive to look
 at long pending PRs and hit a good cycle.

 For tooling, I suggest a look at GUI/IDEs, now that dlangui/dlangide
 seems a good candidate(native D, crossplatform). A good official
 supported GUI library will attract many people.


That won't be happening anytime soon.
Until we have image and windowing in Phobos (I'm working on both) there 
is no way a GUI toolkit is going in. And from what I know there will be 
a LOT of work to update it.
Jan 24 2016
next sibling parent reply Puming <zhaopuming gmail.com> writes:
On Monday, 25 January 2016 at 03:49:56 UTC, Rikki Cattermole 
wrote:

 On 25/01/16 4:21 PM, Puming wrote:

 On Monday, 25 January 2016 at 02:37:40 UTC, Andrei 
 Alexandrescu wrote:

 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- 
 Andrei


 For PRs, I suggest the goal to be number of PRs MERGED instead 
 of
 created. That may provide the core team a subconsious 
 incentive to look
 at long pending PRs and hit a good cycle.

 For tooling, I suggest a look at GUI/IDEs, now that 
 dlangui/dlangide
 seems a good candidate(native D, crossplatform). A good 
 official
 supported GUI library will attract many people.


 That won't be happening anytime soon.
 Until we have image and windowing in Phobos (I'm working on 
 both) there is no way a GUI toolkit is going in. And from what 
 I know there will be a LOT of work to update it.


Well I'm not saying that a GUI toolkit should go into Phobos.
I'd rather it stand alone, while taking some official support, 
say, link in D frontpage(like visualD).
Jan 24 2016
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/01/16 6:47 PM, Puming wrote:

 On Monday, 25 January 2016 at 03:49:56 UTC, Rikki Cattermole wrote:

 On 25/01/16 4:21 PM, Puming wrote:

 On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote:

 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


 For PRs, I suggest the goal to be number of PRs MERGED instead of
 created. That may provide the core team a subconsious incentive to look
 at long pending PRs and hit a good cycle.

 For tooling, I suggest a look at GUI/IDEs, now that dlangui/dlangide
 seems a good candidate(native D, crossplatform). A good official
 supported GUI library will attract many people.


 That won't be happening anytime soon.
 Until we have image and windowing in Phobos (I'm working on both)
 there is no way a GUI toolkit is going in. And from what I know there
 will be a LOT of work to update it.


 Well I'm not saying that a GUI toolkit should go into Phobos.
 I'd rather it stand alone, while taking some official support, say, link
 in D frontpage(like visualD).


I want us to hold off on that as well.
I want people to really have a go with making GUI toolkits in D without 
the worry about how to do the cross platformy technical things.

We just don't know what could be done yet and I'm looking forward to 
finding out.
Jan 24 2016
parent reply Puming <zhaopuming gmail.com> writes:
On Monday, 25 January 2016 at 05:50:34 UTC, Rikki Cattermole 
wrote:

 I want us to hold off on that as well.


I agree that we need a more solid base.


 I want people to really have a go with making GUI toolkits in D 
 without the worry about how to do the cross platformy technical 
 things.


Is dlangui a good start on this?


 We just don't know what could be done yet and I'm looking 
 forward to finding out.


I think improving dlangide will give us many opportunities for 
what a good D native GUI library needs.
Jan 24 2016
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/01/16 7:18 PM, Puming wrote:

 On Monday, 25 January 2016 at 05:50:34 UTC, Rikki Cattermole wrote:

 I want us to hold off on that as well.


 I agree that we need a more solid base.


 I want people to really have a go with making GUI toolkits in D
 without the worry about how to do the cross platformy technical things.


 Is dlangui a good start on this?


No, too much code for what the base needs.
For windowing you want it just above what the OS does in a cross 
platform abstracted way.

So no controls support or any other gruff that a GUI toolkit provides.


 We just don't know what could be done yet and I'm looking forward to
 finding out.


 I think improving dlangide will give us many opportunities for what a
 good D native GUI library needs.


No, it already has its core code. By in large what you want to innovate 
is the core code, not what a specific control does.

I'm not saying dlangui is the wrong way to go. We just don't know which 
way is right just yet and that is ok.
Jan 24 2016
prev sibling parent Andre Polykanine via Digitalmars-d-announce writes:
PvDda> I think improving dlangide will give us many opportunities for
PvDda> what a good D native GUI library needs.

Right   you   are.   However,   it  would  be  great  if  such  a  GUI
library/framework  could  be able to produce GUIs accessible to screen
readers.  And  it  would be more than great if the IDE itself could be
accessible.  However,  with  Dlangui  it's  not  the  case,  namely on
Windows.

Andre.
Jan 25 2016
prev sibling next sibling parent reply Russel Winder via Digitalmars-d-announce writes:
On Mon, 2016-01-25 at 16:49 +1300, Rikki Cattermole via Digitalmars-d-
announce wrote:

=20


[=E2=80=A6]

 That won't be happening anytime soon.
 Until we have image and windowing in Phobos (I'm working on both)
 there=C2=A0
 is no way a GUI toolkit is going in. And from what I know there will
 be=C2=A0
 a LOT of work to update it.


How about we have a D library infrastructure such that Phobos gets
smaller and smaller providing only absolutely necessary core things
over druntime.

If the Python, Rust, Go, etc. stories tell us anything, it is that the
days of "batteries included" distributions is long, long dead. DVCS
changes the game.

Phobos the library needs to go to be replaced by a library search and
use system. Oh we already have one, Dub.

The strategy should be "get rid of anything in Phobos that can be put
out as a separate library".
=C2=A0
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 24 2016
next sibling parent reply tsbockman <thomas.bockman gmail.com> writes:
On Monday, 25 January 2016 at 07:03:35 UTC, Russel Winder wrote:

 The strategy should be "get rid of anything in Phobos that can 
 be put
 out as a separate library".


This makes no sense as a standard: since neither DMD nor druntime 
is allowed to depend upon Phobos, everything in Phobos *could* be 
put into a separate library.
Jan 24 2016
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/01/16 8:16 PM, tsbockman wrote:

 On Monday, 25 January 2016 at 07:03:35 UTC, Russel Winder wrote:

 The strategy should be "get rid of anything in Phobos that can be put
 out as a separate library".


 This makes no sense as a standard: since neither DMD nor druntime is
 allowed to depend upon Phobos, everything in Phobos *could* be put into
 a separate library.


I had a long post replying to Russel and to put it bluntly, its just wrong.
We are most definitely losing people simply because they expect certain 
code in the standard library. Like windowing and image.
Things like sockets are lower on their priority list.

In their mind we are not even a 'programming language'.

Phobos does need to be bigger, but not fully inclusive.
If most people won't use something, don't add it.

Sure there is arguments against this, but there is a certain amount we 
must standardize and agree upon as a community. Phobos most certainly is 
the place to do this. Otherwise we will be going round in circles for a 
much longer period then we should and not growing much.
Jan 24 2016
next sibling parent reply Rory McGuire via Digitalmars-d-announce writes:
On Mon, Jan 25, 2016 at 9:34 AM, Rikki Cattermole via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:


 On 25/01/16 8:16 PM, tsbockman wrote:


 On Monday, 25 January 2016 at 07:03:35 UTC, Russel Winder wrote:


 The strategy should be "get rid of anything in Phobos that can be put
 out as a separate library".


 This makes no sense as a standard: since neither DMD nor druntime is
 allowed to depend upon Phobos, everything in Phobos *could* be put into
 a separate library.


 I had a long post replying to Russel and to put it bluntly, its just wrong.
 We are most definitely losing people simply because they expect certain
 code in the standard library. Like windowing and image.
 Things like sockets are lower on their priority list.

 In their mind we are not even a 'programming language'.

 Phobos does need to be bigger, but not fully inclusive.
 If most people won't use something, don't add it.

 Sure there is arguments against this, but there is a certain amount we
 must standardize and agree upon as a community. Phobos most certainly is
 the place to do this. Otherwise we will be going round in circles for a
 much longer period then we should and not growing much.


I'm going to quote you there: to put it bluntly you are plain wrong.

We do not, and no one does, need a kitchen sink standard library. Look at
python, look at Go, these are two of the fastest growing languages out
there. They are:
- Extremely easy to pick up and use.
- Have excellent documentation and simple naming conventions
- Have fantastic 3rd party open source libraries

How does one find the "right" library for a task?
- The community refers devs to their preferred / popular libs
- There are excellent tutorials / how-tos that show case the library

If we spent less time fussing of what gets into phobos and more time making
good libraries for code.dlang.org and let the best ones win out we'd get
much better stuff much quicker.
Jan 25 2016
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/01/16 9:21 PM, Rory McGuire via Digitalmars-d-announce wrote:

 On Mon, Jan 25, 2016 at 9:34 AM, Rikki Cattermole via
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com
 <mailto:digitalmars-d-announce puremagic.com>> wrote:

     On 25/01/16 8:16 PM, tsbockman wrote:

         On Monday, 25 January 2016 at 07:03:35 UTC, Russel Winder wrote:

             The strategy should be "get rid of anything in Phobos that
             can be put
             out as a separate library".


         This makes no sense as a standard: since neither DMD nor druntime is
         allowed to depend upon Phobos, everything in Phobos *could* be
         put into
         a separate library.


     I had a long post replying to Russel and to put it bluntly, its just
     wrong.
     We are most definitely losing people simply because they expect
     certain code in the standard library. Like windowing and image.
     Things like sockets are lower on their priority list.

     In their mind we are not even a 'programming language'.

     Phobos does need to be bigger, but not fully inclusive.
     If most people won't use something, don't add it.

     Sure there is arguments against this, but there is a certain amount
     we must standardize and agree upon as a community. Phobos most
     certainly is the place to do this. Otherwise we will be going round
     in circles for a much longer period then we should and not growing much.


 I'm going to quote you there: to put it bluntly you are plain wrong.

 We do not, and no one does, need a kitchen sink standard library. Look
 at python, look at Go, these are two of the fastest growing languages
 out there. They are:
 - Extremely easy to pick up and use.
 - Have excellent documentation and simple naming conventions
 - Have fantastic 3rd party open source libraries


Nope just no.
I am only talking about newbies here.
They will pick distributions of Python that are all encompassing.

http://winpython.github.io/#overview
When it comes to newbies who come into programming seeing from all of 
their previous experience that things like GUI toolkit just comes with 
the language they just don't care if it was provided "extra" by a 
distribution or by the language itself. Only that they did exactly 0 
beyond importing and using it.

During my degree, the final programming class was Python.
Everyone used WinPython except me. At the time pip didn't even work in 
it. Yes you heard me correct.

When they had to use other code, they had no way or will to even try 
what wasn't part of it and so in their eyes what they had downloaded was 
Python. Because it really does appear to be Python.

Especially with the IDE and QT being part of it...
And right here is the problem. They expected and there it was.
You will see this in every language. From Java to PHP.

The community in general misses the point here time and time again.
It wasn't until recently that Adam saw how bad things were just to add 
some context.


 How does one find the "right" library for a task?
 - The community refers devs to their preferred / popular libs
 - There are excellent tutorials / how-tos that show case the library

 If we spent less time fussing of what gets into phobos and more time
 making good libraries for code.dlang.org <http://code.dlang.org> and let
 the best ones win out we'd get much better stuff much quicker.


And I agree with you. As long as we have the bare bones in Phobos such 
as windowing and image library we can actually fight over GUI toolkits.
Instead of repeatedly doing the same code over and over poorly.
Jan 25 2016
next sibling parent reply Rory McGuire via Digitalmars-d-announce writes:
On Mon, Jan 25, 2016 at 10:31 AM, Rikki Cattermole via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:


 On 25/01/16 9:21 PM, Rory McGuire via Digitalmars-d-announce wrote:


 On Mon, Jan 25, 2016 at 9:34 AM, Rikki Cattermole via
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com
 <mailto:digitalmars-d-announce puremagic.com>> wrote:

     On 25/01/16 8:16 PM, tsbockman wrote:

         On Monday, 25 January 2016 at 07:03:35 UTC, Russel Winder wrote:

             The strategy should be "get rid of anything in Phobos that
             can be put
             out as a separate library".


         This makes no sense as a standard: since neither DMD nor druntime
 is
         allowed to depend upon Phobos, everything in Phobos *could* be
         put into
         a separate library.


     I had a long post replying to Russel and to put it bluntly, its just
     wrong.
     We are most definitely losing people simply because they expect
     certain code in the standard library. Like windowing and image.
     Things like sockets are lower on their priority list.

     In their mind we are not even a 'programming language'.

     Phobos does need to be bigger, but not fully inclusive.
     If most people won't use something, don't add it.

     Sure there is arguments against this, but there is a certain amount
     we must standardize and agree upon as a community. Phobos most
     certainly is the place to do this. Otherwise we will be going round
     in circles for a much longer period then we should and not growing
 much.


 I'm going to quote you there: to put it bluntly you are plain wrong.

 We do not, and no one does, need a kitchen sink standard library. Look
 at python, look at Go, these are two of the fastest growing languages
 out there. They are:
 - Extremely easy to pick up and use.
 - Have excellent documentation and simple naming conventions
 - Have fantastic 3rd party open source libraries


 Nope just no.
 I am only talking about newbies here.
 They will pick distributions of Python that are all encompassing.

 http://winpython.github.io/#overview
 When it comes to newbies who come into programming seeing from all of
 their previous experience that things like GUI toolkit just comes with the
 language they just don't care if it was provided "extra" by a distribution
 or by the language itself. Only that they did exactly 0 beyond importing
 and using it.

 During my degree, the final programming class was Python.
 Everyone used WinPython except me. At the time pip didn't even work in it.
 Yes you heard me correct.

 When they had to use other code, they had no way or will to even try what
 wasn't part of it and so in their eyes what they had downloaded was Python.
 Because it really does appear to be Python.

 Especially with the IDE and QT being part of it...
 And right here is the problem. They expected and there it was.
 You will see this in every language. From Java to PHP.

 The community in general misses the point here time and time again.
 It wasn't until recently that Adam saw how bad things were just to add
 some context.

 How does one find the "right" library for a task?

 - The community refers devs to their preferred / popular libs
 - There are excellent tutorials / how-tos that show case the library

 If we spent less time fussing of what gets into phobos and more time
 making good libraries for code.dlang.org <http://code.dlang.org> and let
 the best ones win out we'd get much better stuff much quicker.


 And I agree with you. As long as we have the bare bones in Phobos such as
 windowing and image library we can actually fight over GUI toolkits.
 Instead of repeatedly doing the same code over and over poorly.


Ouch yes, seen that before. I just would prefer the base library to be
exactly that a base. In fact if dub came with dmd, or if you downloaded dub
and it could install dmd/gdc/ldc I would be much happier, phobos could be
just another library on code.dlang.org. That why the one app to rule them
all could just be dub and newbies and veterans alike could be happy that
their needed libraries were just there. Something like:
- download dub
- double click installer
- present with options to install, defaults to dmd and phobos must be
installed (if not found)
  - other option to create blank project
  - opens project with a basic ide that uses dcd etc and allows compile and
run with a simple example that outputs to a console and opens a window with
the D logo.

(Just thinking out loud) :D


PS: Can you make sure its easy to do transparent shaped windows in your
bare bones windowing implementation?
Jan 25 2016
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/01/16 9:57 PM, Rory McGuire via Digitalmars-d-announce wrote:

 On Mon, Jan 25, 2016 at 10:31 AM, Rikki Cattermole via
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com
 <mailto:digitalmars-d-announce puremagic.com>> wrote:

     On 25/01/16 9:21 PM, Rory McGuire via Digitalmars-d-announce wrote:


         On Mon, Jan 25, 2016 at 9:34 AM, Rikki Cattermole via
         Digitalmars-d-announce <digitalmars-d-announce puremagic.com
         <mailto:digitalmars-d-announce puremagic.com>
         <mailto:digitalmars-d-announce puremagic.com
         <mailto:digitalmars-d-announce puremagic.com>>> wrote:

              On 25/01/16 8:16 PM, tsbockman wrote:

                  On Monday, 25 January 2016 at 07:03:35 UTC, Russel
         Winder wrote:

                      The strategy should be "get rid of anything in
         Phobos that
                      can be put
                      out as a separate library".


                  This makes no sense as a standard: since neither DMD
         nor druntime is
                  allowed to depend upon Phobos, everything in Phobos
         *could* be
                  put into
                  a separate library.


              I had a long post replying to Russel and to put it bluntly,
         its just
              wrong.
              We are most definitely losing people simply because they expect
              certain code in the standard library. Like windowing and image.
              Things like sockets are lower on their priority list.

              In their mind we are not even a 'programming language'.

              Phobos does need to be bigger, but not fully inclusive.
              If most people won't use something, don't add it.

              Sure there is arguments against this, but there is a
         certain amount
              we must standardize and agree upon as a community. Phobos most
              certainly is the place to do this. Otherwise we will be
         going round
              in circles for a much longer period then we should and not
         growing much.


         I'm going to quote you there: to put it bluntly you are plain wrong.

         We do not, and no one does, need a kitchen sink standard
         library. Look
         at python, look at Go, these are two of the fastest growing
         languages
         out there. They are:
         - Extremely easy to pick up and use.
         - Have excellent documentation and simple naming conventions
         - Have fantastic 3rd party open source libraries


     Nope just no.
     I am only talking about newbies here.
     They will pick distributions of Python that are all encompassing.

     http://winpython.github.io/#overview
     When it comes to newbies who come into programming seeing from all
     of their previous experience that things like GUI toolkit just comes
     with the language they just don't care if it was provided "extra" by
     a distribution or by the language itself. Only that they did exactly
     0 beyond importing and using it.

     During my degree, the final programming class was Python.
     Everyone used WinPython except me. At the time pip didn't even work
     in it. Yes you heard me correct.

     When they had to use other code, they had no way or will to even try
     what wasn't part of it and so in their eyes what they had downloaded
     was Python. Because it really does appear to be Python.

     Especially with the IDE and QT being part of it...
     And right here is the problem. They expected and there it was.
     You will see this in every language. From Java to PHP.

     The community in general misses the point here time and time again.
     It wasn't until recently that Adam saw how bad things were just to
     add some context.

         How does one find the "right" library for a task?
         - The community refers devs to their preferred / popular libs
         - There are excellent tutorials / how-tos that show case the library

         If we spent less time fussing of what gets into phobos and more time
         making good libraries for code.dlang.org <http://code.dlang.org>
         <http://code.dlang.org> and let
         the best ones win out we'd get much better stuff much quicker.


     And I agree with you. As long as we have the bare bones in Phobos
     such as windowing and image library we can actually fight over GUI
     toolkits.
     Instead of repeatedly doing the same code over and over poorly.



 Ouch yes, seen that before. I just would prefer the base library to be
 exactly that a base. In fact if dub came with dmd, or if you downloaded
 dub and it could install dmd/gdc/ldc I would be much happier, phobos
 could be just another library on code.dlang.org <http://code.dlang.org>.
 That why the one app to rule them all could just be dub and newbies and
 veterans alike could be happy that their needed libraries were just
 there. Something like:
 - download dub
 - double click installer
 - present with options to install, defaults to dmd and phobos must be
 installed (if not found)
    - other option to create blank project
    - opens project with a basic ide that uses dcd etc and allows compile
 and run with a simple example that outputs to a console and opens a
 window with the D logo.

 (Just thinking out loud) :D


Can't argue with that as long as there is a good list of set recommend 
libs for doing stuff like windowing on dlang.org. But that comes back to 
the same problem of standardization.
Really at the minimum we need Phobos broken up into dub sub packages. 
Preferably I'd like we to go all the way into separate repositories and 
let people own their own code. But I can understand why not.


 PS: Can you make sure its easy to do transparent shaped windows in your
 bare bones windowing implementation?


Transparent shaped windows? Nope.
That is a very hard and difficult thing to do especially cross platform.

But if people really really want it, I can add a window mode for no 
border + transparent I suppose.
Although based upon what I'm seeing I would be surprised if at least for 
Windows it can't be just one free function when using VRAM context to 
make it happen.
Jan 25 2016
next sibling parent reply Rory McGuire via Digitalmars-d-announce writes:
On Mon, Jan 25, 2016 at 11:05 AM, Rikki Cattermole via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:
[snip]

 Really at the minimum we need Phobos broken up into dub sub packages.
 Preferably I'd like we to go all the way into separate repositories and let
 people own their own code. But I can understand why not.


 [snip]

ha, I had typed a similar response:

Looking at the way we have things now, it would actually be quite simple to
make two downloads, one with everything and one with the bare minimum.

If we changed phobos to compile like the recent vibe.d version does then we
can even pick and choose sections of phobos. I suppose "he who has the
vision" can do either type of release with our current tools.
Jan 25 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/25/2016 04:17 AM, Rory McGuire via Digitalmars-d-announce wrote:

 Looking at the way we have things now, it would actually be quite simple
 to make two downloads, one with everything and one with the bare minimum.

 If we changed phobos to compile like the recent vibe.d version does then
 we can even pick and choose sections of phobos. I suppose "he who has
 the vision" can do either type of release with our current tools.


What would be the benefits of this? My knee-jerk reaction is this is a 
large and disruptive project with no palpable benefits. -- Andrei
Jan 25 2016
parent reply Rory McGuire via Digitalmars-d-announce writes:
On Mon, Jan 25, 2016 at 2:46 PM, Andrei Alexandrescu via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:


 On 01/25/2016 04:17 AM, Rory McGuire via Digitalmars-d-announce wrote:


 Looking at the way we have things now, it would actually be quite simple
 to make two downloads, one with everything and one with the bare minimum.

 If we changed phobos to compile like the recent vibe.d version does then
 we can even pick and choose sections of phobos. I suppose "he who has
 the vision" can do either type of release with our current tools.


 What would be the benefits of this? My knee-jerk reaction is this is a
 large and disruptive project with no palpable benefits. -- Andrei


Yep, thats kind of what I was saying in the end. If someone wanted to they
could make such a release independently.

I'm trying to hack on the compiler, personally I wish all those with the
know how would put their efforts into documenting how the compiler works
and what the different parts do, that way we could have more contributors.
Jan 25 2016
parent maik klein <maikklein googlemail.com> writes:
On Monday, 25 January 2016 at 13:08:18 UTC, Rory McGuire wrote:

 On Mon, Jan 25, 2016 at 2:46 PM, Andrei Alexandrescu via 
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com> 
 wrote:


 On 01/25/2016 04:17 AM, Rory McGuire via 
 Digitalmars-d-announce wrote:


 Looking at the way we have things now, it would actually be 
 quite simple to make two downloads, one with everything and 
 one with the bare minimum.

 If we changed phobos to compile like the recent vibe.d 
 version does then we can even pick and choose sections of 
 phobos. I suppose "he who has the vision" can do either type 
 of release with our current tools.


 What would be the benefits of this? My knee-jerk reaction is 
 this is a large and disruptive project with no palpable 
 benefits. -- Andrei


 Yep, thats kind of what I was saying in the end. If someone 
 wanted to they could make such a release independently.

 I'm trying to hack on the compiler, personally I wish all those 
 with the know how would put their efforts into documenting how 
 the compiler works and what the different parts do, that way we 
 could have more contributors.


+1 On lifetime management and tooling. I would like to see a lot 
of improvements for DCD also tools for refactoring would also be 
extremely useful.

As for splitting up everything into small packages, I don't think 
D is there yet. I am still new but I already found several 
libraries that I wanted to use that not follow the "official" D 
Style guide.

I would not want to include N different libraries that use N 
different coding styles. Look at Rust for example, you will find 
that pretty much every library uses the "official" style guide.

I think that is because it is mostly "enforced" by the compiler 
as a warning.

I really don't care how I write my code, but I care deeply about 
consistency.

Another point is that I couldn't find any metaprogramming library 
for D yet. Yes there is std.meta but it is extremely lacking, 
this is quite obvious if you look into the std.

For example in "zip"

return mixin (q{ElementType(%(.moveAt(ranges[%s], n)%|, 
%))}.format(iota(0, R.length)));

This could be easily expressed as a general metafunction. Also 
std.meta mostly focusses on compile time stuff but I don't think 
there is anything for a "Tuple".

Some inspiration could be found here 
https://github.com/boostorg/hana
Jan 25 2016
prev sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
I've had a bit more of a looksie into splash screens and I think I would 
prefer if it was completely separate actually.
Its not too hard, but its has semi incompatible features as to a window.
Jan 25 2016
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 25 January 2016 at 08:57:44 UTC, Rory McGuire wrote:

 Ouch yes, seen that before. I just would prefer the base 
 library to be exactly that a base.


I agree. Imagine if all the effort put into Phobos' extras was 
put into the compiler and tooling...
Jan 26 2016
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Tuesday, 26 January 2016 at 12:46:23 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 25 January 2016 at 08:57:44 UTC, Rory McGuire wrote:

 Ouch yes, seen that before. I just would prefer the base 
 library to be exactly that a base.


 I agree. Imagine if all the effort put into Phobos' extras was 
 put into the compiler and tooling...


It's not like you could just reallocate all the effort that goes 
into Phobos towards the compiler and stuff.

Especially with the compiler itself, most people are unqualified 
or uninterested in working on it. If it were suddenly announced 
that Phobos was "finished", I guarantee a lot of volunteers would 
just walk away (likely including myself).
Jan 26 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 20:38:16 UTC, tsbockman wrote:

 It's not like you could just reallocate all the effort that 
 goes into Phobos towards the compiler and stuff.


My impression is that the majority of the contributors to Phobos 
are capable D programmers.

DMD is implemented in D now, no longer C++, so with refactoring 
and documentation I think a lot more programmers are qualified to 
hack on the compiler.
Jan 26 2016
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Tuesday, 26 January 2016 at 20:43:29 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 26 January 2016 at 20:38:16 UTC, tsbockman wrote:

 It's not like you could just reallocate all the effort that 
 goes into Phobos towards the compiler and stuff.


 My impression is that the majority of the contributors to 
 Phobos are capable D programmers.

 DMD is implemented in D now, no longer C++, so with refactoring 
 and documentation I think a lot more programmers are qualified 
 to hack on the compiler.


The language in which DMD is written has never been the main 
barrier to working on it. The real issue is that DMD is a huge, 
poorly documented code base in which most of the various 
components are tightly coupled to everything else. This makes it 
both intimidating and time consuming to get started hacking on it.

In contrast, Phobos (although still very large) is fairly well 
documented, and has much less coupling between most of its 
components. Moreover, what coupling there is, is easily 
understood because the average (experienced) D programmer already 
knows his way around the standard library, from the outside.

Also, you skipped past the "uninterested" part - this is a 
volunteer project, remember?
Jan 26 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 21:03:01 UTC, tsbockman wrote:

 Also, you skipped past the "uninterested" part - this is a 
 volunteer project, remember?


I didn't think it was a relevant argument as you can still write 
libraries for distribution. Keep in mind that the standard 
library has to be maintained and API's cannot easily be 
redesigned because of backwards compatibility.

Even if C/C++ have small standard libraries they provide a 
depressing amount of low quality functionality that one should 
avoid. But it is kept in for backwards compatibility and 
sometimes even updated and extended...

That not a good thing.
Jan 26 2016
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Tuesday, 26 January 2016 at 21:47:41 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 26 January 2016 at 21:03:01 UTC, tsbockman wrote:

 Also, you skipped past the "uninterested" part - this is a 
 volunteer project, remember?


 I didn't think it was a relevant argument as you can still 
 write libraries for distribution. Keep in mind that the 
 standard library has to be maintained and API's cannot easily 
 be redesigned because of backwards compatibility.

 Even if C/C++ have small standard libraries they provide a 
 depressing amount of low quality functionality that one should 
 avoid. But it is kept in for backwards compatibility and 
 sometimes even updated and extended...

 That not a good thing.


There are certainly disadvantages to the standard library model 
of distribution and maintenance.

On the other hand:

1) The prospect of getting something into the standard library is 
a huge motivator for (at least some) potential contributors.

Why? Because building a library that no one knows about/trusts is 
wasted effort. Getting something into `std` is among the most 
effective forms of marketing available, and requires little 
non-programming-related skill or effort on the part of the 
contributor.

2) Standard libraries don't enforce backwards compatibility (and 
high code quality in general) just for the sake of bureaucracy - 
they do so because these are highly desirable characteristics for 
basic infrastructure. People shouldn't have to rewrite their 
entire stack every 6 months just because someone thought of a 
better API for some low-level component.

Making it through D's formal review process typically raises code 
quality quite a lot, and the knowledge that backwards 
compatibility is a high priority makes outsiders much more likely 
to invest in actually using a library module.

In short, while you make some valid points, your analysis seems 
very lopsided; it completely glosses over all of the positives 
associated with the status quo.
Jan 26 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 22:33:32 UTC, tsbockman wrote:

 1) The prospect of getting something into the standard library 
 is a huge motivator for (at least some) potential contributors.


I am not sure if that is the right motivation. Sounds like recipe 
for bloat. Good libraries evolve from being used in real 
applications. Many applications.


 characteristics for basic infrastructure. People shouldn't have 
 to rewrite their entire stack every 6 months just because 
 someone thought of a better API for some low-level component.


Then don't use libraries from unreliable teams.


 Making it through D's formal review process typically raises 
 code quality quite a lot, and the knowledge that backwards 
 compatibility is a high priority makes outsiders much more 
 likely to invest in actually using a library module.


Code quality is one thing, but if it has not been used in many 
applications, how can you then know if the abstraction is 
particularly useful?

There is nothing wrong with having a set of recommended 
libraries, e.g. a DSP library with FFT. But having things like 
FFT in the standard library is just crap. Even Apple does not do 
that, they have a separate library called Accelerate for such 
things. There is no way you can have the same interface for FFT 
across platforms. The structure of the data is different, the 
accuracy is different, all for max performance.

In general the standard library should just be the most basic 
things, even file system support is tricky for a system level 
programming language. For instance, on some cloud platforms you 
don't get to read/write parts of a file. You do it as one big 
atomic write/read.
Jan 26 2016
next sibling parent reply tsbockman <thomas.bockman gmail.com> writes:
On Tuesday, 26 January 2016 at 22:48:23 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 26 January 2016 at 22:33:32 UTC, tsbockman wrote:

 characteristics for basic infrastructure. People shouldn't 
 have to rewrite their entire stack every 6 months just because 
 someone thought of a better API for some low-level component.


 Then don't use libraries from unreliable teams.


Just using the standard library whenever possible is a simple and 
efficient way of accomplishing this - if the standard library 
actually has anything in it...


 Making it through D's formal review process typically raises 
 code quality quite a lot, and the knowledge that backwards 
 compatibility is a high priority makes outsiders much more 
 likely to invest in actually using a library module.


 Code quality is one thing, but if it has not been used in many 
 applications, how can you then know if the abstraction is 
 particularly useful?


This is why requiring modules to spend some time on DUB and/or in 
`std.experimental` before freezing the API is important.


 In general the standard library should just be the most basic 
 things, even file system support is tricky for a system level 
 programming language. For instance, on some cloud platforms you 
 don't get to read/write parts of a file. You do it as one big 
 atomic write/read.


Targeting 100% generality with APIs is pretty much always a bad 
idea.

Standard libary modules should endeavor to meet the needs of at 
least, say, 80% of potential users; they're not supposed to 
completely eliminate the need for specialized third-party 
libraries entirely. This is OK, because if you don't use a 
module, the compiler won't include it in the final executable.
Jan 26 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 23:04:57 UTC, tsbockman wrote:

 This is why requiring modules to spend some time on DUB and/or 
 in `std.experimental` before freezing the API is important.


Well, there aren't enough D applications written to ensure the 
usefulness of the API. Just take a look at widely adopted 
frameworks, they are "the one true thing" for a few years with 
100s or 1000s of applications using them. However as applications 
grow problems emerge. What happens? The entire framework is 
scrapped and replaced with something else.


 Targeting 100% generality with APIs is pretty much always a bad 
 idea.


Making a system level programming library based on what a current 
PC operating systems offers is also a bad idea. On Apple systems 
you are supposed to no longer use paths, but switch to URLs for 
files. Ok, you can do that by requiring URLs on all platforms, 
but what if you designed the API 10 years ago?

Operating systems changes, hardware changes. System level 
programming languages shouldn't provide an abstract machine, 
unlike the JVM.

I'm not at all convinced that D isn't tied too heavily to 
x86/POSIX/Windows. It isn't obvious that future systems will 
bother with POSIX.
Jan 26 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
Or let me put it this way. If the standard library requires 
POSIX, then it isn't really a standard library, but a POSIX 
abstraction library...
Jan 26 2016
prev sibling parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Tuesday, 26 January 2016 at 22:48:23 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 26 January 2016 at 22:33:32 UTC, tsbockman wrote:

 1) The prospect of getting something into the standard library 
 is a huge motivator for (at least some) potential contributors.


 I am not sure if that is the right motivation. Sounds like 
 recipe for bloat. Good libraries evolve from being used in real 
 applications. Many applications.


sayeth a low-level guy (if I understand correctly), which will 
certainly create a distinct perspective about what you would like 
to see in the standard library, and yet this may not be the right 
thing for the language as a whole.

fwiw, people that do use D on a serious scale have remarked that 
the richness of the standard library (even as it stands today) 
was a major advantage - in bioinformatics, at a London hedge 
fund, and I think AdRoll.
Jan 26 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 27 January 2016 at 06:17:44 UTC, Laeeth Isharc 
wrote:

 On Tuesday, 26 January 2016 at 22:48:23 UTC, Ola Fosheim 
 Grøstad wrote:



 I am not sure if that is the right motivation. Sounds like 
 recipe for bloat. Good libraries evolve from being used in 
 real applications. Many applications.


 sayeth a low-level guy (if I understand correctly), which will 
 certainly create a distinct perspective about what you would 
 like to see in the standard library, and yet this may not be 
 the right thing for the language as a whole.


I am both low-level and high level, but D's primary advantage is 
that it allows low level programming.


 fwiw, people that do use D on a serious scale have remarked 
 that the richness of the standard library (even as it stands 
 today) was a major advantage - in bioinformatics, at a London 
 hedge fund, and I think AdRoll.


Do you consider Angular to be low level? It was used in 100s if 
not 1000s of applications, but was considered inadequate and 
scrapped in favour of Angular2. This is the typical pattern for 
libraries and frameworks.
Jan 27 2016
parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Wednesday, 27 January 2016 at 09:15:27 UTC, Ola Fosheim 
Grøstad wrote:

 On Wednesday, 27 January 2016 at 06:17:44 UTC, Laeeth Isharc 
 wrote:

 On Tuesday, 26 January 2016 at 22:48:23 UTC, Ola Fosheim 
 Grøstad wrote:



 I am not sure if that is the right motivation. Sounds like 
 recipe for bloat. Good libraries evolve from being used in 
 real applications. Many applications.


 sayeth a low-level guy (if I understand correctly), which will 
 certainly create a distinct perspective about what you would 
 like to see in the standard library, and yet this may not be 
 the right thing for the language as a whole.


 I am both low-level and high level, but D's primary advantage 
 is that it allows low level programming.


Surely, that is C's primary advantage!  The whole point of D is 
that it doesn't just have one primary advantage, and that is why 
the front page no longer describes it is as a systems language, 
even though it's approaching suitable as such.


 fwiw, people that do use D on a serious scale have remarked 
 that the richness of the standard library (even as it stands 
 today) was a major advantage - in bioinformatics, at a London 
 hedge fund, and I think AdRoll.


 Do you consider Angular to be low level? It was used in 100s if 
 not 1000s of applications, but was considered inadequate and 
 scrapped in favour of Angular2. This is the typical pattern for 
 libraries and frameworks.


I really don't see how this relates to the point at hand.  You 
seemed to suggest that the standard library should be small, and 
I pointed out that many serious users in industries that are 
likely to be key markets for D do say that they find what's 
provided in the standard library to be quite appealing.  Nothing 
lasts forever, and all is change - that's something I agree with. 
  But it doesn't seem to have much bearing on the decision about 
what to put in the standard library.  Your suggestions that 
because some cloud environments don't have a conventional file 
system, D perhaps shouldn't even have this in the standard 
library really seemed to me to be a reductio ad absurdum of your 
own argument.  Of course there will be lots there that one 
doesn't need and can't use.  But over time things that were once 
cutting edge become bog standard, and it makes sense to have 
coherence and convenience rather than to have to search out the 
best library for the purpose each time.
Jan 27 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 27 January 2016 at 16:52:53 UTC, Laeeth Isharc 
wrote:

 your own argument.  Of course there will be lots there that one 
 doesn't need and can't use.  But over time things that were 
 once cutting edge become bog standard, and it makes sense to 
 have coherence and convenience rather than to have to search 
 out the best library for the purpose each time.



I agree about coherence being desirable, but evolution tends to 
lead to the opposite. Just look at C++ streams vs iterators vs 
ranges vs ... Coherence is a good reason to have independent 
libraries that are replaced as a whole.

The standard library should primarily cover stable types you need 
to describe APIs. Then you can have other recommended independent 
libraries with no mutual dependencies.
Jan 27 2016
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 25 January 2016 at 08:31:13 UTC, Rikki Cattermole 
wrote:

 Nope just no.
 I am only talking about newbies here.
 They will pick distributions of Python that are all 
 encompassing.

 http://winpython.github.io/#overview
 When it comes to newbies who come into programming seeing from 
 all of their previous experience that things like GUI toolkit 
 just comes with the language they just don't care if it was 
 provided "extra" by a distribution or by the language itself. 
 Only that they did exactly 0 beyond importing and using it.


I'm sympathetic to this. I still just download Anaconda and not 
bother with much else.
Jan 25 2016
next sibling parent Russel Winder via Digitalmars-d-announce writes:
On Mon, 2016-01-25 at 15:47 +0000, jmh530 via Digitalmars-d-announce
wrote:

=20


[=E2=80=A6]

=20
 I'm sympathetic to this. I still just download Anaconda and not=C2=A0
 bother with much else.


But that is the whole point I am trying to make. Anaconda (or
Miniconda) is not a single massive monolithic library, it is a package
management system for a Python milieu. You have a single command conda
that allows you to get the bits you want. It is just pip on steroids,
but with proper curation. Sadly they are still on Qt4, but=E2=80=A6

The analogy to Miniconda in Python is Dub in D.

The analogy to Anaconda in Python is downloading the whole of the Dub
repository before doing anything.

Actually Dub is more like Pip. Continuum Analytics put a lot of effort
into managing their separate repository. Very little crap, lots of good
stuff. But focused on data science.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 25 2016
prev sibling parent Rory McGuire via Digitalmars-d-announce writes:
On 25 Jan 2016 7:16 PM, "Russel Winder via Digitalmars-d-announce" <
digitalmars-d-announce puremagic.com> wrote:

 On Mon, 2016-01-25 at 15:47 +0000, jmh530 via Digitalmars-d-announce
 wrote:


 [=E2=80=A6]

 I'm sympathetic to this. I still just download Anaconda and not
 bother with much else.


 But that is the whole point I am trying to make. Anaconda (or
 Miniconda) is not a single massive monolithic library, it is a package
 management system for a Python milieu. You have a single command conda
 that allows you to get the bits you want. It is just pip on steroids,
 but with proper curation. Sadly they are still on Qt4, but=E2=80=A6

 The analogy to Miniconda in Python is Dub in D.

 The analogy to Anaconda in Python is downloading the whole of the Dub
 repository before doing anything.

 Actually Dub is more like Pip. Continuum Analytics put a lot of effort
 into managing their separate repository. Very little crap, lots of good
 stuff. But focused on data science.

 --
 Russel.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D

 Dr Russel Winder      t: +44 20 7585 2200   voip:


sip:russel.winder ekiga.net

 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
 London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


Reading the whole thread here it seems we're all pretty much in agreement
about lightweight phobos + dub on steroids.

- phobos should be the common glue allowing interoperability between
various libraries and apps.
- druntime should be OS abstraction?
- dub should be first or second  thing you download when using D (depends
if it can install d itself)

Perhaps:
'dub install dmd' installs dmd
'dub install ldc|gdc' ...
'dub init +gui ' could init a gui app with recommended dependencies.
'dub init +web' for Web dev.
Etc...

?



 Jan 25 2016



prev sibling  parent reply Russel Winder via Digitalmars-d-announce  writes:


On Mon, 2016-01-25 at 21:31 +1300, Rikki Cattermole via Digitalmars-d-
announce wrote:

=20


[=E2=80=A6]

 Nope just no.
 I am only talking about newbies here.
 They will pick distributions of Python that are all encompassing.
=20
 http://winpython.github.io/#overview
 When it comes to newbies who come into programming seeing from all
 of=C2=A0
 their previous experience that things like GUI toolkit just comes
 with=C2=A0
 the language they just don't care if it was provided "extra" by a=C2=A0
 distribution or by the language itself. Only that they did exactly 0=C2=


=A0

 beyond importing and using it.


I'm afraid this whole view on the Python world is an old and long gone
one. Even on Windows. Trust me on this I have been training people in
Python since 2006. I have seen the whole scene change. Dramatically.

Oh and by the way, noone actually uses the one graphics system that
comes as standard in Python. Everyone uses PyQt, wxPython, Phoenix,
Gtk, direct bindings to other graphics libraries.

Pip is now core to everyone, even beginners use of Python. PyPI =C2=A0may
still have elements of crapness about it, but it is there, it is used,
from Day 1 by most people learning Python.=C2=A0


 During my degree, the final programming class was Python.
 Everyone used WinPython except me. At the time pip didn't even work
 in=C2=A0
 it. Yes you heard me correct.


True, but how long ago was that? Python distributes pip in the Windows
and OSX distributions. Package-based platforms tend to package it
themselves. In fact all the commands are just entries into the library.
Analogy: Dub is part of Phobos. If tehre is anything to add to Phobos
it has to be Dub.=C2=A0


 When they had to use other code, they had no way or will to even try=C2=


=A0

 what wasn't part of it and so in their eyes what they had downloaded
 was=C2=A0
 Python. Because it really does appear to be Python.


Very true until four or five years ago. Now the whole situation is
changed. Yes people go first to the standard library, but now people
know to look in PyPI before writing their own.


 Especially with the IDE and QT being part of it...
 And right here is the problem. They expected and there it was.
 You will see this in every language. From Java to PHP.


Qt never has been and never will be a part of the Python standard
library.

Ah you agree with me: The Java folk have a huge library, some if which
is good, much of which is dross. But the real treasure of the Java
Platform is Bintray and Maven Central. How can anyone contemplate doing
Web stuff without Spring Hibernate, JavaEE, all of which are separate
libraries not in teh distribution.=C2=A0


 [=E2=80=A6]
=20
 And I agree with you. As long as we have the bare bones in Phobos
 such=C2=A0
 as windowing and image library we can actually fight over GUI
 toolkits.
 Instead of repeatedly doing the same code over and over poorly.


I am afraid this is just displacement reasoning. The problem with
graphics and D (other than GtkD, which is a very smooth operation) is
that too many people have too many different ideas and assume everyone
else will insist on doing their own thing. The problem is not Phobos
here, the problem is the people not wanting to collaborate to create
one or two things. Oh, that and resources. Whilst there is no money
swashing around the D community (compare the Java, C++, Rust, Go,
Python ones), there is little or no expectation of change. Given that
all activity is volunteer activity, then what is happening will not
change. And neither should it be forced to. On the other hand if a
consensus could happen=E2=80=A6

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 Jan 25 2016



  parent reply Rikki Cattermole <alphaglosined gmail.com>  writes:


On 26/01/16 6:07 AM, Russel Winder via Digitalmars-d-announce wrote:

 On Mon, 2016-01-25 at 21:31 +1300, Rikki Cattermole via Digitalmars-d-
 announce wrote:


 […]

 Nope just no.
 I am only talking about newbies here.
 They will pick distributions of Python that are all encompassing.

 http://winpython.github.io/#overview
 When it comes to newbies who come into programming seeing from all
 of
 their previous experience that things like GUI toolkit just comes
 with
 the language they just don't care if it was provided "extra" by a
 distribution or by the language itself. Only that they did exactly 0
 beyond importing and using it.


 I'm afraid this whole view on the Python world is an old and long gone
 one. Even on Windows. Trust me on this I have been training people in
 Python since 2006. I have seen the whole scene change. Dramatically.

 Oh and by the way, noone actually uses the one graphics system that
 comes as standard in Python. Everyone uses PyQt, wxPython, Phoenix,
 Gtk, direct bindings to other graphics libraries.

 Pip is now core to everyone, even beginners use of Python. PyPI  may
 still have elements of crapness about it, but it is there, it is used,
 from Day 1 by most people learning Python.


Well whoever these people are, they are most certainly not the people 
I've seen. They wouldn't care or even want to look at PyPI.


 During my degree, the final programming class was Python.
 Everyone used WinPython except me. At the time pip didn't even work
 in
 it. Yes you heard me correct.


 True, but how long ago was that? Python distributes pip in the Windows
 and OSX distributions. Package-based platforms tend to package it
 themselves. In fact all the commands are just entries into the library.
 Analogy: Dub is part of Phobos. If tehre is anything to add to Phobos
 it has to be Dub.


2 years ago, but I can guarantee for students that go through that 
course and tutors, it won't be changing anytime soon.


 When they had to use other code, they had no way or will to even try
 what wasn't part of it and so in their eyes what they had downloaded
 was
 Python. Because it really does appear to be Python.


 Very true until four or five years ago. Now the whole situation is
 changed. Yes people go first to the standard library, but now people
 know to look in PyPI before writing their own.


 Especially with the IDE and QT being part of it...
 And right here is the problem. They expected and there it was.
 You will see this in every language. From Java to PHP.


 Qt never has been and never will be a part of the Python standard
 library.

 Ah you agree with me: The Java folk have a huge library, some if which
 is good, much of which is dross. But the real treasure of the Java
 Platform is Bintray and Maven Central. How can anyone contemplate doing
 Web stuff without Spring Hibernate, JavaEE, all of which are separate
 libraries not in teh distribution.


 […]

 And I agree with you. As long as we have the bare bones in Phobos
 such
 as windowing and image library we can actually fight over GUI
 toolkits.
 Instead of repeatedly doing the same code over and over poorly.


 I am afraid this is just displacement reasoning. The problem with
 graphics and D (other than GtkD, which is a very smooth operation) is
 that too many people have too many different ideas and assume everyone
 else will insist on doing their own thing. The problem is not Phobos
 here, the problem is the people not wanting to collaborate to create
 one or two things. Oh, that and resources. Whilst there is no money
 swashing around the D community (compare the Java, C++, Rust, Go,
 Python ones), there is little or no expectation of change. Given that
 all activity is volunteer activity, then what is happening will not
 change. And neither should it be forced to. On the other hand if a
 consensus could happen…


You're 100% right that it is the people problem here.
But right now, Phobos is the only way I can emphasize reuse of the core 
bare-bones libraries.



 Jan 25 2016



  parent reply Russel Winder via Digitalmars-d-announce  writes:


On Tue, 2016-01-26 at 17:06 +1300, Rikki Cattermole via Digitalmars-d-
announce wrote:

 [=E2=80=A6]
=20
 Well whoever these people are, they are most certainly not the
 people=C2=A0
 I've seen. They wouldn't care or even want to look at PyPI.


The people you have seen are clearly not Pythonistas. This may be by
dint of their teachers/lecturer/tutors/mentors not actually
understanding Python and its culture.

[=E2=80=A6]

=20
 2 years ago, but I can guarantee for students that go through that=C2=A0
 course and tutors, it won't be changing anytime soon.


OK, in which case I infer the teachers/lecturers/tutors/mentors really
do not understand Python, and should learn more themselves as a matter
of urgency and professionalism.
=C2=A0
[=E2=80=A6]

=20
 You're 100% right that it is the people problem here.
 But right now, Phobos is the only way I can emphasize reuse of the
 core=C2=A0
 bare-bones libraries.


I disagree (hence my comment about displacement). I think we should fix
the Dub issues and the relationship between Dub, GDC, LDC, DMD,
druntime and Phobos. To use Phobos as a "hack" to solve the problem in
the short term will be a disservice to D in the medium to long term.
=C2=A0
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 Jan 25 2016



  parent reply Rikki Cattermole <alphaglosined gmail.com>  writes:


I wasn't going to reply, until you tweeted.
No just no.

When dealing with tertiary institutions especially New Zealand ones, 
you've got to understand they have massive pressure to get through 
content. Every single class is standardized nationally, by law.

You're all worried about doing things best practice in an eco-system.
That is just not the case here. In these courses they are not meant to 
be teaching a language. But instead use said language to teach with.

The most time a student gets in ANY language is 2 semesters. By the time 
they reach third year (last) they only have 1 per language.
In these classes the concern is teaching some other relevant concept 
such as design patterns.

So you're pushing limited class time for the purpose of teaching actual 
class content instead of non required information for assignments.
Its a balancing act.

But you've got to understand that most of the students going through it, 
are just not interested in going much further then the assignments.
Simple things like trying OpenGL are beyond them and this is ok. They 
have a lot of things to learn and have real life requirements outside of 
study.

The average person learning to program is not spending half the time 
most D developers do on a slow week. Again this is ok. But we need to 
acknowledge that they won't be anywhere near us or our expectations 
normally.

To assume the average person will play around and learn pip ext. is just 
ridiculous. Especially when they have most if not all the code they need 
already available to them via the distribution.

These are the same people who we may barely convince to try D out. If 
they struggle to do basic things or at least perceived basic things then 
they won't bother and just say 'too hard'.
If we can make them happy, most developers over all will be happy. Even 
the average D developer will be glad for it.

At the end of the day, the least amount of steps to do what is perceived 
as basic tasks without any conflicting arguments the better.

I keep saying about perceived basic tasks. Psychology. A fourteen year 
old today was born in 2002. I learned to program when I was 14. In 2001 
XP was just released. The people learning programming now expect GUI's 
and perceive it as basic. We may know better but at the end of the day, 
how can we appeal to them realistically?



 Jan 26 2016



  parent reply Russel Winder via Digitalmars-d-announce  writes:


Some of this apparently off-topic, but I will get back on-topic by the
end.

On Tue, 2016-01-26 at 21:17 +1300, Rikki Cattermole via Digitalmars-d-
announce wrote:

 I wasn't going to reply, until you tweeted.


Sorry for wrongly assigning geography.


 No just no.


Yes, oh yes, oh yes.=C2=A0


 When dealing with tertiary institutions especially New Zealand ones,=C2=


=A0

 you've got to understand they have massive pressure to get through=C2=A0
 content. Every single class is standardized nationally, by law.


Sounds like the NZ system is not as good a tertiary education system as
it should be. Having guidelines for curriculum and examination is fine,
but to stadardize at the class level is definitely too low. =C2=A0UK
universities went through this debate in the 1980 and managed to escape
from legal enforcement.


 You're all worried about doing things best practice in an eco-system.
 That is just not the case here. In these courses they are not meant
 to=C2=A0
 be teaching a language. But instead use said language to teach with.


There should also be classes in applications construction. Clearly
classes on specification, compilers, etc. the language is tool only and
workflow and best practice of programming are irrelevant.


 The most time a student gets in ANY language is 2 semesters. By the
 time=C2=A0
 they reach third year (last) they only have 1 per language.
 In these classes the concern is teaching some other relevant concept=C2=


=A0

 such as design patterns.


Design patterns are not language agnostic. GoF patterns are 23 year old
and many totally irrelevant with certain programming languages. However
that is a different debate for a different place.


 So you're pushing limited class time for the purpose of teaching
 actual=C2=A0
 class content instead of non required information for assignments.
 Its a balancing act.


It sounds like the law makers are getting it wrong then. If there is no
time for teaching programming best practice then graduates from the
programme are not ready for employment without first doing an
apprenticeship of some sort.


 But you've got to understand that most of the students going through
 it,=C2=A0
 are just not interested in going much further then the assignments.
 Simple things like trying OpenGL are beyond them and this is ok.
 They=C2=A0
 have a lot of things to learn and have real life requirements outside
 of=C2=A0
 study.


=46rom my time in academia (20 years) I can pretty much agree that most
computing students didn't actually give a shit about computing.
Certainly 40% of them couldn't program. But because of the curriculum
they get degrees, get jobs as programmers and we end up with the mass
of crap code we currently have in the world.=C2=A0


 The average person learning to program is not spending half the time=C2=


=A0

 most D developers do on a slow week. Again this is ok. But we need
 to=C2=A0
 acknowledge that they won't be anywhere near us or our expectations=C2=A0
 normally.


Which gets on to a huge hobby horse of mine. If degrees are about
knowledge then there has to be a follow on before people are employed.
Medics do this: three year degree, two or three years on the job
training. Effectively an apprenticeship. Sadly in computing, most
employers assume graduates have the knowledge and the work practice
skills. Clearly they do not.

It seems NZ is enshrining this in law. UK it is jsut what happens.

Of course most university computing academic staff cannot program
either.


 To assume the average person will play around and learn pip ext. is
 just=C2=A0
 ridiculous. Especially when they have most if not all the code they
 need=C2=A0
 already available to them via the distribution.


Ridiculous is the wrong word to use here. All Python programmers should
know about pip and PyPI. You are talking about students using Python to
code up answers to exercises. If the academic ensures there is no need
of anything other than the standard distribution, then that is a fine
compromise, in that situation. But a person off that course should
never claim they can program in Python, nor should tehy be considered
for Python programming jobs without further training.=C2=A0


 These are the same people who we may barely convince to try D out.
 If=C2=A0
 they struggle to do basic things or at least perceived basic things
 then=C2=A0
 they won't bother and just say 'too hard'.
 If we can make them happy, most developers over all will be happy.
 Even=C2=A0
 the average D developer will be glad for it.


Mostly because they cannot be arsed.

Academic's have a responsibility here to configure things for the
students. We did this with C++, Scheme, Miranda, Java, etc. Part of the
initial pack for each course were detailed tested instructions for
students to set up. They didn't have to think, they just had to follow
the recipe.


 At the end of the day, the least amount of steps to do what is
 perceived=C2=A0
 as basic tasks without any conflicting arguments the better.


True.

1. Download Dub.
2. Dub install standard-distribution

should do it.


 I keep saying about perceived basic tasks. Psychology. A fourteen
 year=C2=A0
 old today was born in 2002. I learned to program when I was 14. In
 2001=C2=A0
 XP was just released. The people learning programming now expect
 GUI's=C2=A0
 and perceive it as basic. We may know better but at the end of the
 day,=C2=A0
 how can we appeal to them realistically?


In the university context most of the problems you are pointing out
land squarely at teh feet of the academic, and law makers, not the
students. Students are clearly input and output being treated as cannon
fodder, not as individuals wishing to learn things.

But to get back on topic.

Yes modern development is about IDEs. VIM and Emacs do not count even
though a lot of programmers use them. IntelliJ IDEA (CLion, PyCharm,=E2=80=
=A6),
NetBeans, Visual Studio, Xcode, even Eclipse, are what people mean by
IDEs.

In various Scala, Java, Python, Clojure, workshops I have forced people
to use IDEs who would otherwise have used VIM or Emacs.It is amazing
how much further people get in learning a language and how to use it
with all the extras over and above editing that a good IDE provides. As
a confirmed believer in "Emacs is the One True Editor, VIM is a
scouring agent" I have been converted to good IDEs =E2=80=93 bad IDEs get m=
e
back to Emacs very quickly.

So we need a really good, preferably lightweight, but=E2=80=A6 IDEs that re=
ally
make programming, D in this context, easier and fun. The IDE should be
editor, manual, guide, mentor.

The single incident that really brought this home to me was at a
DevoxxUK workshop a couple of years ago, people new to Java were coding
up full on good quality RxJava applications in two hours. Without the
IntelliJ IDEA environment, they would have been nowhere.

So as well as DDT in Eclipse, there should be solid support for
Kingsley and the IntelliJ IDEA D plugin. If we get more people using D,
we will have more people willing to contribute to D development, in
terms of packages on Dub and otherwise.


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 Jan 26 2016



  parent  Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=  writes:


On Tuesday, 26 January 2016 at 10:52:17 UTC, Russel Winder wrote:

 Design patterns are not language agnostic. GoF patterns are 23 
 year old and many totally irrelevant with certain programming 
 languages. However that is a different debate for a different 
 place.


I found GoF underwhelming when I first read it as I had 
discovered many/most of those patterns on my own, but then 
someone said that the usefulness was in giving the pattern names. 
And that made sense.



 Jan 26 2016



prev sibling  parent reply Russel Winder via Digitalmars-d-announce  writes:


On Mon, 2016-01-25 at 20:34 +1300, Rikki Cattermole via Digitalmars-d-
announce wrote:

=20


[=E2=80=A6]

 I had a long post replying to Russel and to put it bluntly, its just
 wrong.
 We are most definitely losing people simply because they expect
 certain=C2=A0
 code in the standard library. Like windowing and image.
 Things like sockets are lower on their priority list.


It sounds like we will just have to disagree. Either than or agree that
you are wrong. ;-)

Most languages benefit from libraries that wrap and abstract OS APIs,
everything else can be handled by libraries (many of them) as long as
there is a single central resource that enables people to find and
trivially use. This message comes from Rust, Ceylon, other JDK
languages, and Python. Go is weird. The counter example is C++. D just
needs to get it's Dub act together properly.=C2=A0


 In their mind we are not even a 'programming language'.


Actually I think the core problem is that there is fashion and hype
around D. By simple observation Go and Rust got huge impetus via hype.
This led to a huge amount of activity most of which died a death, but
left a huge acceleration of real traction. Whilst usage figures are
dwarfed by Java, C, C++, and Python, Go and Rust have huge distributed
activity bases. By sheer volume of activity some good stuff appears.
Especially the stuff that gets funded, because some company is taking a
punt.=C2=A0

Consider the one obvious case of Cloudflare. Originally a PHP company,
Go was introduced by guerilla processes, and now Go is central to their
operation. Such they they fund meetings and conferences. There are many
other companies using Go who put money into meetings, conferences,
general marketing, etc. because they want the best programmers. I
suspect the same will happen with Rust in a couple of years. It is
already the case with Python.

This is the core of the issue with D for me: there isn't enough
corporate activity and will to put money into the D milieu.


 Phobos does need to be bigger, but not fully inclusive.
 If most people won't use something, don't add it.


Wouldn't it be better to be explicit about what has to be in Phobos and
what can be separate? Let me start a list:

Data structures that are not in the language. Phobos more or less has
most of the core ones. The job here is to define an architecture, which
is has in ranges.

OS APIs. The point here is to abstract away from Windows, OSX, Linux,
UNIX,=E2=80=A6 I am not sure Linux DVB API should be in here, it is more
threads, input/output, networking, memory management. Phobos host most
stuff here already doesn't it?

Signals and slots systems so as to be able to write asynchronous
systems.

Concurrency and Parallelism libraries.

Not a lot else.


 Sure there is arguments against this, but there is a certain amount
 we=C2=A0
 must standardize and agree upon as a community. Phobos most certainly
 is=C2=A0
 the place to do this. Otherwise we will be going round in circles for
 a=C2=A0
 much longer period then we should and not growing much.


What needs to be standardized? Data structure architecture. Already in
Phobos. Cross platform Input/Output. Already in Phobos.

Why isn't Dub the way forward on this? Why a centralized massive
library that is hard to change and evolve, why not a far more
lightweight management of contributions via a centralized mechanism,
i.e. Dub.

In so many ways vibe.d shows what can be right about D, and graphics
all that is wrong.

Of course in the end D just does not have the corporate backing that
Go, Rust, Python, Java, etc. are getting. Until that happens plus =C3=A7a
change,=C2=A0plus c'est la m=C3=AAme chose.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 Jan 25 2016



 next sibling parent  Rikki Cattermole <alphaglosined gmail.com>  writes:


On 26/01/16 5:49 AM, Russel Winder via Digitalmars-d-announce wrote:

 On Mon, 2016-01-25 at 20:34 +1300, Rikki Cattermole via Digitalmars-d-
 announce wrote:


 […]

 I had a long post replying to Russel and to put it bluntly, its just
 wrong.
 We are most definitely losing people simply because they expect
 certain
 code in the standard library. Like windowing and image.
 Things like sockets are lower on their priority list.


 It sounds like we will just have to disagree. Either than or agree that
 you are wrong. ;-)

 Most languages benefit from libraries that wrap and abstract OS APIs,
 everything else can be handled by libraries (many of them) as long as
 there is a single central resource that enables people to find and
 trivially use. This message comes from Rust, Ceylon, other JDK
 languages, and Python. Go is weird. The counter example is C++. D just
 needs to get it's Dub act together properly.


 In their mind we are not even a 'programming language'.


 Actually I think the core problem is that there is fashion and hype
 around D. By simple observation Go and Rust got huge impetus via hype.
 This led to a huge amount of activity most of which died a death, but
 left a huge acceleration of real traction. Whilst usage figures are
 dwarfed by Java, C, C++, and Python, Go and Rust have huge distributed
 activity bases. By sheer volume of activity some good stuff appears.
 Especially the stuff that gets funded, because some company is taking a
 punt.

 Consider the one obvious case of Cloudflare. Originally a PHP company,
 Go was introduced by guerilla processes, and now Go is central to their
 operation. Such they they fund meetings and conferences. There are many
 other companies using Go who put money into meetings, conferences,
 general marketing, etc. because they want the best programmers. I
 suspect the same will happen with Rust in a couple of years. It is
 already the case with Python.

 This is the core of the issue with D for me: there isn't enough
 corporate activity and will to put money into the D milieu.


 Phobos does need to be bigger, but not fully inclusive.
 If most people won't use something, don't add it.


 Wouldn't it be better to be explicit about what has to be in Phobos and
 what can be separate? Let me start a list:

 Data structures that are not in the language. Phobos more or less has
 most of the core ones. The job here is to define an architecture, which
 is has in ranges.

 OS APIs. The point here is to abstract away from Windows, OSX, Linux,
 UNIX,… I am not sure Linux DVB API should be in here, it is more
 threads, input/output, networking, memory management. Phobos host most
 stuff here already doesn't it?


So windowing, image library and audio handling.
They are core to any modern OS.

It wasn't until very recently that Windows Server ripped out all of the 
GUI aspects of its sdk for core edition.


 Signals and slots systems so as to be able to write asynchronous
 systems.

 Concurrency and Parallelism libraries.

 Not a lot else.


 Sure there is arguments against this, but there is a certain amount
 we
 must standardize and agree upon as a community. Phobos most certainly
 is
 the place to do this. Otherwise we will be going round in circles for
 a
 much longer period then we should and not growing much.


 What needs to be standardized? Data structure architecture. Already in
 Phobos. Cross platform Input/Output. Already in Phobos.

 Why isn't Dub the way forward on this? Why a centralized massive
 library that is hard to change and evolve, why not a far more
 lightweight management of contributions via a centralized mechanism,
 i.e. Dub.

 In so many ways vibe.d shows what can be right about D, and graphics
 all that is wrong.

 Of course in the end D just does not have the corporate backing that
 Go, Rust, Python, Java, etc. are getting. Until that happens plus ça
 change, plus c'est la même chose.





 Jan 25 2016



prev sibling  parent  Dicebot <public dicebot.lv>  writes:


On Monday, 25 January 2016 at 16:49:36 UTC, Russel Winder wrote:

 What needs to be standardized? Data structure architecture. 
 Already in Phobos. Cross platform Input/Output. Already in 
 Phobos.


On Monday, 25 January 2016 at 16:49:36 UTC, Russel Winder wrote:

 Why isn't Dub the way forward on this? Why a centralized 
 massive library that is hard to change and evolve, why not a 
 far more lightweight management of contributions via a 
 centralized mechanism, i.e. Dub.


I completely agree with Russel here. Kitchen-sink standard 
libraries are becoming legacy of old days and luxury of 
enterprise languages. It is the concept rather harmful to 
decentralized development nature of modern languages and very 
limited in flexibility. With a largely uncontrolled contribution 
flow D simply can't afford such approach.

There is quite a lot of missing in how dub works, how registry is 
organized and how it is featured from the dlang.org - in other 
words, in highlighting and endorsing valuable community projects. 
But that has nothing to do with Phobos.

Most important thing Phobos can do is to standardizes API's of 
various widespread concepts so that different independent 
libraries can work together cleanly. Good example would be 
std.experimental.logger - it doesn't provide much of "smart" 
logging functionality (like syslog or cyclic buffer) but allows 
to build one on top of Phobos bits in a way that you can be sure 
that any 2 loggers fetched from dub will be compatible with each 
other. This is the main deal.



 Jan 25 2016



prev sibling next sibling parent  =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com>  writes:


On 2016-01-25 07:03:35 +0000, Russel Winder via Digitalmars-d-announce said:


 Phobos the library needs to go to be replaced by a library search and
 use system. Oh we already have one, Dub.
 
 The strategy should be "get rid of anything in Phobos that can be put
 out as a separate library".


I see it exactly the other way: I want phobos to provide 90% of 
everything I need out-of-the-box. The linker will only bring in stuff I 
use and the rest is left out. So, what's the problem?

I just don't want to walk around until I find out, which parts 
(external libs) fit together just to cover the common 90%. That's 
wasting time.

Make it as simple as possible to get things done. Install, code, 
compile, deliver. That's it. One EXE, done.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster



 Jan 25 2016



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 01/25/2016 02:03 AM, Russel Winder via Digitalmars-d-announce wrote:

 If the Python, Rust, Go, etc. stories tell us anything, it is that the
 days of "batteries included" distributions is long, long dead. DVCS
 changes the game.


Could you please back up that assertion a little bit? From all I see, 
standard libraries of most languages grow very fast with each release. 
What are your facts? -- Andrei



 Jan 25 2016



  parent reply Russel Winder via Digitalmars-d-announce  writes:


On Mon, 2016-01-25 at 07:44 -0500, Andrei Alexandrescu via Digitalmars-
d-announce wrote:


 Could you please back up that assertion a little bit? From all I
 see,=C2=A0
 standard libraries of most languages grow very fast with each
 release.=C2=A0
 What are your facts? -- Andrei


Go has a very small core, if you want anything else you write a library
and publish it. There is a massive and vibrant activity writing many
versions of stuff most of which wither by lack of use. Some, usually
one or two, in each domain thrive and become the de facto standard.
Everything depends on Git, Mercurial, Bazaar, and go get.

Rust threw out large tracts of what was in the original library,
including all concurrency and parallelism things, in favour of separate
crates. There is a massive and vibrant activity writing many versions
of stuff most of which wither by lack of use. Some, usually one or two,
in each domain thrive and become the de facto standard. Everything
depends on crates.io and Cargo.

Python used to be batteries included, then they moved to having a core
to which only Python committers have access. =C2=A0There is a massive and
vibrant activity writing many versions of stuff most of which wither by
lack of use. Some, usually one or two, in each domain thrive and become
the de facto standard. Everything depends on PyPI, pip, and virtualenv.
Or Anaconda.

There are many facts out there favouring distributed over centralized
for everything except the language itself and the runtime system, you
just have to look. Calling for an explicit, detailed catalogue is not a
way forward in this debate.

Consider Java Platform, the system where lots gets deprecated and
nothing is removed. Ever. The library is big, and grows, but with JDK9
it will, finally be split up into modules, most of which will be
ignored since they are from the mid-1990s. There is a massive and
vibrant activity writing many versions of stuff most of which wither by
lack of use. Some, usually one or two, in each domain thrive and become
the de facto standard. Everything depends on Gradle or Maven, and
Bintray and Maven Central.

Distributed means duplicated effort, yes. It means many projects die.
Some will gain a following that leads to traction. Centralized systems
lead to stagnation and lack of contribution from all but the inner
circle, which often means a lack of energy and new idea (but sometimes
not).

The energy in the Go, Rust, Python, and indeed JVM-based communities
creating new libraries throwing them away, contributing a bit to the
core library, but generally leaving it to the core team, is actually
something missing from D except for the energy around vibe.d. Just
looking at the threads about DMD, druntime, Phobos, it is almost all
about angst rather than genuine progress.

The whole "graphics library" thing is an interesting case in point.
Lots of individual projects, very little consensus, no contribution in
the main playing fields of Windows, OSX, Wx, and Qt. I've got GtkD for
all my needs, so I don't actually care much, but as we see others care
about a cross platform GUI system, but it just isn't happening. There
is point at which small one person projects have to be pushed together
by management and made to work. Either than or one gets funded because
some organization does that. cf. PyQt, JavaFX, Qt.=C2=A0

Even if you do not rate this as facts it all is. The moral of the story
is, for me, very simple:

Dub needs to be front and centre, it represents D, not DMD, LDC, GDC,
druntime, Phobos. The core of a D distribution is Dub. In this D is
like Rust, Ceylon, Python, and JVM. And unlike Go. Go is too
libertarian in my view. Rust, Ceylon, Python, JVM have the right view
for me: centralized repository and management of distributed projects.
What Rust and Ceylon are missing that PyPI has is an highly opinionated
metric that helps you decide what is good and what is dross.

Of course Dub needs a better story around executables rather than
library packages. Go (go install) and Rust (Cargo build) do this so
much better. But then Go has a project structure model, and Rust uses
TOML. =C2=A0

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 Jan 25 2016



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 01/25/2016 11:26 AM, Russel Winder via Digitalmars-d-announce wrote:

 On Mon, 2016-01-25 at 07:44 -0500, Andrei Alexandrescu via Digitalmars-
 d-announce wrote:


 Could you please back up that assertion a little bit? From all I
 see,
 standard libraries of most languages grow very fast with each
 release.
 What are your facts? -- Andrei




Thanks for answering. I want to be convinced, and even if not, to gather 
a more precise view.

The rhetoric is appreciated. What would be helpful here in addition to 
it are a few links to evidence. You make lofty claims either of status 
quo in different languages, or major shifts in strategy. They definitely 
must have left a trail on the Internet. Any chance you'd substantiate 
these specific claims below with evidence?


 Go has a very small core, if you want anything else you write a library
 and publish it. There is a massive and vibrant activity writing many
 versions of stuff most of which wither by lack of use. Some, usually
 one or two, in each domain thrive and become the de facto standard.
 Everything depends on Git, Mercurial, Bazaar, and go get.


I look at https://golang.org/pkg/ and see a quite substantial standard 
library, including things that some people argue shouldn't be part of a 
standard library: archives and compression, cryptography, databases, 
character encodings (including json and xml!), html templating, image 
processing, suffix arrays (sic), logging, networking, regexp, testing, 
tokenization. This list is _after_ I eliminated topics that I believe 
should be part of a standard library, such as I/O, time, and even 
unicode, etc.

I'd like to believe our stdlib covers a few areas that Go's doesn't, but 
it is obvious to me Go's stdlib does (and reportedly very well) cover a 
bunch of areas that we haven't set foot in yet. This doesn't quite align 
quite at all with your view that Go is barebones and anyone who wants 
anything builds it. From what I can tell, Go comes with plenty. (It is 
of course relative; Go's stdlib may be small compared to externally 
available libraries, owing to its popularity which the Go team deserves 
due credit for.)


 Rust threw out large tracts of what was in the original library,
 including all concurrency and parallelism things, in favour of separate
 crates. There is a massive and vibrant activity writing many versions
 of stuff most of which wither by lack of use. Some, usually one or two,
 in each domain thrive and become the de facto standard. Everything
 depends on crates.io and Cargo.


Do you have reference to relevant material (core team blog posts, forum 
discussions, articles) documenting the shift, boundaries, strategy, 
motivation etc? A look at https://doc.rust-lang.org/std/ does support 
your view that Rust's stdlib is minimal.


 Python used to be batteries included, then they moved to having a core
 to which only Python committers have access.  There is a massive and
 vibrant activity writing many versions of stuff most of which wither by
 lack of use. Some, usually one or two, in each domain thrive and become
 the de facto standard. Everything depends on PyPI, pip, and virtualenv.
 Or Anaconda.


Again, a few links to evidence supporting these statements would be 
awesome. I am sorry for my being incult; I know of pip and used it a 
couple of times but know nothing about all else. At the same time you'll 
appreciate I can't just form an opinion on your authority.


 There are many facts out there favouring distributed over centralized
 for everything except the language itself and the runtime system, you
 just have to look. Calling for an explicit, detailed catalogue is not a
 way forward in this debate.


I am truly sorry but is appealing to your own authority a better 
alternative?


 Dub needs to be front and centre, it represents D, not DMD, LDC, GDC,
 druntime, Phobos. The core of a D distribution is Dub. In this D is
 like Rust, Ceylon, Python, and JVM. And unlike Go. Go is too
 libertarian in my view. Rust, Ceylon, Python, JVM have the right view
 for me: centralized repository and management of distributed projects.
 What Rust and Ceylon are missing that PyPI has is an highly opinionated
 metric that helps you decide what is good and what is dross.

 Of course Dub needs a better story around executables rather than
 library packages. Go (go install) and Rust (Cargo build) do this so
 much better. But then Go has a project structure model, and Rust uses
 TOML.


I do agree with Dub's importance. What's unclear to me is what are 
reasonable criteria for including some given functionality within the 
stdlib vs. an external one.


Andrei



 Jan 26 2016



 next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 2016-01-26 13:38, Andrei Alexandrescu wrote:


 Thanks for answering. I want to be convinced, and even if not, to gather
 a more precise view.

 The rhetoric is appreciated. What would be helpful here in addition to
 it are a few links to evidence. You make lofty claims either of status
 quo in different languages, or major shifts in strategy. They definitely
 must have left a trail on the Internet. Any chance you'd substantiate
 these specific claims below with evidence?


I don't really have an opinion but I found this [1] for Ruby.

[1] https://redmine.ruby-lang.org/projects/ruby/wiki/StdlibGem

-- 
/Jacob Carlborg



 Jan 26 2016



prev sibling  parent reply Martin Nowak <code dawg.eu>  writes:


On Tuesday, 26 January 2016 at 12:38:09 UTC, Andrei Alexandrescu 
wrote:

 including things that some people argue shouldn't be part of a 
 standard library: archives and compression, cryptography, 
 databases, character encodings (including json and xml!), html 
 templating, image processing, suffix arrays (sic), logging, 
 networking, regexp, testing, tokenization.


See my answer below, most of these are standard solutions that 
you need on a daily basis (except for the suffix array).


 I do agree with Dub's importance. What's unclear to me is what 
 are reasonable criteria for including some given functionality 
 within the stdlib vs. an external one.


A good criteria is whether some area has an established and hard 
to debate solution, then it can go into the standard library. But 
if there are many different ways around the same topic you should 
leave the decision to the users.

So for example there are 3 established ways to parse something, 
dom, stax and event based parsers. So you can add those parsers 
as sth. like std.xml or std.json.

There are about 500 different configuration file formats, so 
anything that isn't as established as xml or json should be left 
for libraries.

Likewise there are plenty of different GUI toolkits (taking 
imperative or declarative approaches). Leave it to people to pick 
one that suites their need.

You could discuss endlessly about the syntax of html templating, 
but how such a library should work is clear. This is at the edge 
of standardizable, b/c by putting it into std, you're making a 
decision for all language users. It's albeit possible, just like 
declaring a particular code style as standard.

Anything that is highly innovative or experimental should never 
go into standard libraries.



 Jan 27 2016



  parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=  writes:


On Wednesday, 27 January 2016 at 21:00:41 UTC, Martin Nowak wrote:

 A good criteria is whether some area has an established and 
 hard to debate solution, then it can go into the standard 
 library. But if there are many different ways around the same 
 topic you should leave the decision to the users.


I don't think this is the right criteria. Take a good hard look 
at the C++ standard library.
Plenty of things in there that nobody use, but which one would 
hope that almost everyone would use. Like for numerics.

When a good external numerics library emerge it will displace 
whatever numerics functionality the standard library provides.

D has too few users to see high quality external libraries, but 
that is not a good reason to bloat the standard library.

The argument that some functionality is needed on a daily basis 
is also misguided. Different applications have different needs.

What the standard library should support is essential interfacing 
with the system and what you need to interface with libraries, 
like basic types/iterators.

Once you have something in the standard library you have to 
maintain it forever. If something is in the standard library and 
it turns out to be impossible to implement it efficiently on a 
specific hardware platform then all libraries using that 
functionality will be dog slow on that platform.


 So for example there are 3 established ways to parse something, 
 dom, stax and event based parsers. So you can add those parsers 
 as sth. like std.xml or std.json.


There is no reason for xml or json to be in the standard library. 
You can have a set of recommended libraries, allowing for more 
efficient APIs to emerge over time.

Only functionality where you get unbreakable interdependencies 
between standard modules need to be in standard library.

Parsers and compressors have low levels of inter-library 
dependencies. DSP functionality has only internal dependencies. 
No need for such things in the standard library.


Scripting languages like Python is a horrible example to follow. 
Scripting languages require all C-implemented functionality to be 
in the standard library for the sake of being able to deploy pure 
python code on machines where you don't get to install binaries.



 Jan 28 2016



  parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=  writes:


This is what a good system programming standard library should 
provide:

1. Types needed to specify library APIs.

2. Functionality for accessing hardware in a non-emulated fashion.

3. Functionality that most _libraries_ need to build on (like 
arrays/iterators/ranges).

4. Functionality that is tied to the individual compiler (like 
intrinsics).

5. Memory management.


The primary goal of the standard library should not be to support 
building applications, but to enable building frameworks and 
libraries and the interaction between them.


So if one user says "My app needs to read WAV which is RIFF, 
therefore RIFF should be in the standard library" then the 
sensible response is: "Do most _libraries_ need RIFF? Why don't 
you use the recommended audio library which has optimized WAV 
support.".

Surely everyone uses string processing on a daily basis?

No. I personally almost never do string processing in system 
level programming languages, what I need is binary serializing 
support. Or Collada support. Or audio file format support.

I'd be happy to use a recommended string procesessing library 
when or if I need it.

But a standard library MUST have great support for SIMD 
intrinsics, i.e. interfacing the hardware,  that is much more 
critical for system level programming and is tied to the specific 
compiler.



 Jan 28 2016



  parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com>  writes:


On Thursday, 28 January 2016 at 10:00:59 UTC, Ola Fosheim Grøstad 
wrote:

 This is what a good system programming standard library should 
 provide:

 1. Types needed to specify library APIs.

 2. Functionality for accessing hardware in a non-emulated 
 fashion.

 3. Functionality that most _libraries_ need to build on (like 
 arrays/iterators/ranges).

 4. Functionality that is tied to the individual compiler (like 
 intrinsics).

 5. Memory management.


 The primary goal of the standard library should not be to 
 support building applications, but to enable building 
 frameworks and libraries and the interaction between them.


 So if one user says "My app needs to read WAV which is RIFF, 
 therefore RIFF should be in the standard library" then the 
 sensible response is: "Do most _libraries_ need RIFF? Why don't 
 you use the recommended audio library which has optimized WAV 
 support.".

 Surely everyone uses string processing on a daily basis?

 No. I personally almost never do string processing in system 
 level programming languages, what I need is binary serializing 
 support. Or Collada support. Or audio file format support.

 I'd be happy to use a recommended string procesessing library 
 when or if I need it.

 But a standard library MUST have great support for SIMD 
 intrinsics, i.e. interfacing the hardware,  that is much more 
 critical for system level programming and is tied to the 
 specific compiler.


I do like the building-block idea you suggest, but one must think 
about the deeper reasons for why things are owned by which 
people.  (I have found the Coase theorem and work on industrial 
organisation to be quite stimulating in thinking about this 
question).

In theory it's completely irrelevant as to whether is something 
is in the standard library or can just be imported via dub or a 
git clone, but in practice that's not the case.

As you yourself have mentioned, the size of the D community as it 
stands today presents some impediment to the possible maintenance 
and stability of alternative libraries.  If something is in 
Phobos you know that you can depend on it, that bugs will get 
fixed, and that changes to the language won't stop the code from 
compiling (since it will be fixed).  Being in Phobos is a focal 
point, whereas there simply isn't for now any kind of focal point 
for external libraries.  The bus factor is high for external 
libraries - people get sick, divorced, change interest, and so on.

There are also benefits from coherence, since the code will tend 
to converge on a similar style.

I appreciate that your own interests are quite different, but 
perhaps you can see that they are only part of what's important 
for the community as a whole.

It would be nice to have SIMD intrinsics, and in the time you 
have spent arguing over the years perhaps it would have been 
possible to help the process of having a high quality and 
consistent implementation along.  People would also be much more 
inclined to listen to what you say because then it comes from 
someone with serious skin in the game.  (Walter himself has 
spoken about the importance of listening to people who like your 
stuff and use it already over those who say if only you did X we 
could use it on a large scale - and that's also plain good 
business sense).  The gadfly can play a useful role in a 
community, but not if he continually diminishes the worth of what 
people are working hard trying to do (in inevitably imperfect 
human ways).

It really doesn't do any good to worry about what the crowd says 
and the applause you receive.  If you focus on doing good work 
(and have some reinforcement along the way because people are 
using your work to do serious things) then recognition will come.

The work that dlangscience is doing (and one could see ndslice as 
a part of that) opens up new possibilities that I am quite 
excited about.  I should say that John Colvin is a contractor for 
me, but I am not talking up dlangscience because he is helping 
me, but rather I asked him to help me because I was impressed by 
what he is doing.

It strikes me as a bit silly to get hung up over language 
specifications as some kind of mystical talisman.  C was used for 
years in a serious way before the ANSI spec.  Same for Ruby.  I 
couldn't immediately see what the situation was for Python.  
There isn't the manpower to go that route yet, and nor would it 
be constructive when certain aspects are not yet as polished as 
they will eventually be.

Ultimately the test of a language is in whether people can use it 
to do good work.  Compound growth can be very powerful, and more 
complex things take time to mature to the point where they are 
useful in certain domains.  I couldn't have used D for work five 
years ago, but I can now.  There are these threshold effects, 
just as Christensen described in the Innovator's Dilemma.  D 
continues to grow and isn't going to disappear any time soon.  It 
would be much better to put one's energy into actually writing 
code that can improve things (even as a proof of concept) than 
debating what might or might not happen if things don't change 
(when they always do).  Kingsley hadn't been using D long, liked 
his IDE, so wrote a D module for it.  It's not perfect yet, but 
it's a beginning and will mature in time.  That kind of thing 
will get us much further than debating about what people should 
do, when there is no army of troops that can be commanded to 
implement things they are not interested in doing anyway.

Walter clearly doesn't decide everything, any more than a prince 
does in a monarchy of old.  But we are lucky that he does have 
such an important influence because he has good taste and a rare 
skill set.  One gets a higher quality design that way than if you 
have something that is the pure creation of a committee.

At some point maybe there'll be a need for a committee and a 
language spec.  That's a higher quality problem to have, but it 
surely isn't the main concern today.



 Jan 28 2016



 next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=  writes:


On Thursday, 28 January 2016 at 11:25:08 UTC, Laeeth Isharc wrote:

 I do like the building-block idea you suggest, but one must 
 think about the deeper reasons for why things are owned by 
 which people.


It is much easier to get motivated if you have a certain level 
autonomy. Clearly, the "D foundation" should have criterions for 
making a recommendation, like API guidelines, Boost license and 
commitment to maintaining it for a period of time.

For instance, Ponce has made some efforts on audio. You and 
others have made some effort on economic modelling (?). I am 
interested in audio. Then we have an opportunity to form a team 
that builds a shared numerics library, with some input from some 
Phobos coordinator so that ranges are supported in a consistent 
matter.

But here is the key point: we don't have to get input from all D 
programmers. We can form consensus and take ownership and make 
faster decisions. And we can scrap it in two years, learn from 
our mistakes and create a much better API.

I think that Sonke received too much "negative motivation" for 
his contributions recently, if I had been in his shoes I'd 
probably found working on vibe.d more fun. IRRC Ruppe also have 
voiced that he want to work on libraries which he has more 
freedom with.

An frankly, as APIs have to be vetted on large applications in 
maintenance mode a lot of the effort put into arguing the design 
"perfect Phobos libraries" most likely will be in vain.


  (I have found the Coase theorem and work on industrial 
 organisation to be quite stimulating in thinking about this 
 question).


I noticed you and the other economic theory guys in the thread 
mentioning some interesting models. I'd like to look at those 
later when I have more time :-). Always nice to find some shared 
language for expressing system dynamics.


 In theory it's completely irrelevant as to whether is something 
 is in the standard library or can just be imported via dub or a 
 git clone, but in practice that's not the case.


Well, but if something is in the standard library, other 
libraries will build upon it and add dependencies to it even if 
they don't really have to. Meaning, they will pull in 
dependencies and bloat and make Phobos costly to maintain as you 
will end up with std.json, std.json2, std.json3 etc.


 As you yourself have mentioned, the size of the D community as 
 it stands today presents some impediment to the possible 
 maintenance and stability of alternative libraries.


No, I don't think so. I think that D has nurtured the idea that 
Phobos should provide everything and therefore the modus operandi 
is to complain that Phobos does not provide it.


 The bus factor is high for external libraries - people get 
 sick, divorced, change interest, and so on.


Recommended libraries should have at least 3-6 people behind them


 It would be nice to have SIMD intrinsics, and in the time you 
 have spent arguing over the years perhaps it would have been 
 possible to help the process of having a high quality and 
 consistent implementation along.


SIMD isn't critical to me at this point in time. I am currently 
using C++ for what I would have liked to use D for. D needs more 
compiler developers, a strategy to get there and someone to take 
D there with focused leadership.

The main challenge is not code, it is process.


 It really doesn't do any good to worry about what the crowd 
 says and the applause you receive.  If you focus on doing good


I don't worry about applause. Describe the key issues and explain 
it from various angels whenever it comes up and people start to 
develop a shared understanding of what needs to be done.

Without a timeline, why invest? The vision for 2016 looks pretty 
good, but there it lacks the details of what and when. What are 
the estimates. What are the explicit goals? How many man hours 
(min/max) are needed. Goals and estimates.


 excited about.  I should say that John Colvin is a contractor 
 for me, but I am not talking up dlangscience because he is 
 helping me, but rather I asked him to help me because I was 
 impressed by what he is doing.


That's great! :-)


 It strikes me as a bit silly to get hung up over language 
 specifications as some kind of mystical talisman.


It brings unfortunate inconsistencies and implementation effects 
to the foreground so that they can be addressed. It is near 
impossible to discuss the design without one.


 debating about what people should do, when there is no army of 
 troops that can be commanded to implement things they are not 
 interested in doing anyway.


Attract more developers.

1. Find out why they don't come.
2. Find out why they leave.
3. Address the issues they have with D.

In my case and for many others the reason go along the lines of: 
memory management, language inconsistencies, a refusal to add 
builtin tuples and platform support.



 Jan 28 2016



  parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


On Thursday, 28 January 2016 at 12:40:56 UTC, Ola Fosheim Grøstad 
wrote:

 I think that Sonke received too much "negative motivation" for 
 his contributions recently, if I had been in his shoes I'd 
 probably found working on vibe.d more fun. IRRC Ruppe also have 
 voiced that he want to work on libraries which he has more 
 freedom with.


Yeah, I think getting in Phobos is a waste of time and likely a 
net negative on the library due to how much harder it is to 
change phobos vs changing your own file.

In my perfect world, quality third party apps - as determined 
just by usage stats or something - would be automatically 
downloadable and their documentation searchable as if it was 
standard.

When you do `import std.string;` you expect it to just work, and 
you find std.string's docs easily from dmd.

I'd love it if you could do `import thirdparty.independent;` and 
it magically works too - without even need for a configuration 
file or an install command. And the docs are right there and 
tutorials are written however the author feels like writing them.


Then the line between "standard library" and other library 
basically disappears.


While that isn't likely to happen, we could at least start 
promoting third party stuff more equally.


 An frankly, as APIs have to be vetted on large applications in 
 maintenance mode a lot of the effort put into arguing the 
 design "perfect Phobos libraries" most likely will be in vain.


This is a reason why I tend to only write libs that I actually 
use myself - at least then I know every function has one happy 
user.



 Jan 29 2016



 next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=  writes:


On Friday, 29 January 2016 at 16:07:48 UTC, Adam D. Ruppe wrote:

 In my perfect world, quality third party apps - as determined 
 just by usage stats or something - would be automatically 
 downloadable and their documentation searchable as if it was 
 standard.


I've noticed that curated lists of libraries are popping up on 
github for various languages:
https://github.com/search?utf8=%E2%9C%93&q=awesome

If D gets more users maybe there would be a market for a 
commercial IDE with a reviewed repository with globally 
searchable reference documentation and cookbook recipes.

For popular languages stack overflow is pretty ok, but over time 
it is getting more chaotic.

Imagine an intelligent IDE that looks at the probability of a 
match between a cookbook recipe and what you type. A.I. 
templating of sorts.


 Then the line between "standard library" and other library 
 basically disappears.


I usually prefer to download from github for commercial code and 
put it in my project archive. I want to check out if the library 
programmers are maintaining it and have enough people as well. 
Then I lock that version until I find a reason to upgrade.

For me automatic downloading (dub etc) fits more with hobby 
projects and experiments.


 While that isn't likely to happen, we could at least start 
 promoting third party stuff more equally.


Yep, a curated list like those awesome-lists found on github 
would be a start.

Then write tutorials that only use libraries from that list.


 This is a reason why I tend to only write libs that I actually 
 use myself - at least then I know every function has one happy 
 user.


Yeah, I find myself constantly wanting to improve on even the 
simplest libraries for better interaction with the kind of code 
the functions/objects seem to be most used with.

More of a discovery process of usability than "mathematical 
deduction".



 Jan 29 2016



  parent  Puming <zhaopuming gmail.com>  writes:


On Friday, 29 January 2016 at 23:41:47 UTC, Ola Fosheim Grøstad 
wrote:


 Yep, a curated list like those awesome-lists found on github 
 would be a start.


I've got one before there were many awesome-lists: 
https://github.com/zhaopuming/awesome-d



 Jan 29 2016



prev sibling next sibling parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 1/29/16 11:07 AM, Adam D. Ruppe wrote:

 I'd love it if you could do `import thirdparty.independent;` and it
 magically works too - without even need for a configuration file or an
 install command. And the docs are right there and tutorials are written
 however the author feels like writing them.


I suggested that at a point, it was destroyed. -- Andrei



 Feb 02 2016



prev sibling next sibling parent reply earthfront <earthfront safetymail.info>  writes:


On Friday, 29 January 2016 at 16:07:48 UTC, Adam D. Ruppe wrote:

 When you do `import std.string;` you expect it to just work, 
 and you find std.string's docs easily from dmd.

 I'd love it if you could do `import thirdparty.independent;` 
 and it magically works too - without even need for a 
 configuration file or an install command. And the docs are 
 right there and tutorials are written however the author feels 
 like writing them.


OMG I would love this.
Often I write short scripts and use rdmd for rapid prototyping.

Having to dub initialize and pull in libraries is a pain for 
this. Python got it right with their package manager(s)



 Feb 02 2016



  parent reply Tofu Ninja <emmons0 purdue.edu>  writes:


On Wednesday, 3 February 2016 at 03:19:57 UTC, earthfront wrote:

 On Friday, 29 January 2016 at 16:07:48 UTC, Adam D. Ruppe wrote:

 When you do `import std.string;` you expect it to just work, 
 and you find std.string's docs easily from dmd.

 I'd love it if you could do `import thirdparty.independent;` 
 and it magically works too - without even need for a 
 configuration file or an install command. And the docs are 
 right there and tutorials are written however the author feels 
 like writing them.


 OMG I would love this.
 Often I write short scripts and use rdmd for rapid prototyping.

 Having to dub initialize and pull in libraries is a pain for 
 this. Python got it right with their package manager(s)


I suggested this once but there seems to be a group of people the 
viscerally oppose this.
See: 
http://forum.dlang.org/post/bdhmdbhyoirmwcbbxvln forum.dlang.org



 Feb 02 2016



  parent reply =?UTF-8?B?TcOhcmNpbw==?= Martins <marcioapm gmail.com>  writes:


On Wednesday, 3 February 2016 at 05:41:52 UTC, Tofu Ninja wrote:

 On Wednesday, 3 February 2016 at 03:19:57 UTC, earthfront wrote:

 On Friday, 29 January 2016 at 16:07:48 UTC, Adam D. Ruppe 
 wrote:

 When you do `import std.string;` you expect it to just work, 
 and you find std.string's docs easily from dmd.

 I'd love it if you could do `import thirdparty.independent;` 
 and it magically works too - without even need for a 
 configuration file or an install command. And the docs are 
 right there and tutorials are written however the author 
 feels like writing them.


 OMG I would love this.
 Often I write short scripts and use rdmd for rapid prototyping.

 Having to dub initialize and pull in libraries is a pain for 
 this. Python got it right with their package manager(s)


 I suggested this once but there seems to be a group of people 
 the viscerally oppose this.
 See: 
 http://forum.dlang.org/post/bdhmdbhyoirmwcbbxvln forum.dlang.org


How would you select the package version you want to use. 
Obviously it would be fine for small scripts to pick the latest 
version, but no so much for non-trivial projects.

Somewhat related: I would love to be able to install packages 
with dub "globally", and then have them automatically added to 
the compiler's search paths and working with import with rdmd and 
dmd.

I install version 0.1 of package X globally and now all my 
programs pick that up with import. If the package is a library, 
dub would (re)compile then upon installation and put the 
resulting libs in the correct places so that all my programs can 
simply link to them.
I should also be able to override the global import with a 
different version at the project level if I which to do so. 
Similar to what dub.selections.json currently does.

Having dub fully integrated with the compiler and it's 
configuration would be a major quality of life improvement, and a 
nice step towards the "it just works" state. Much like C/C++ 
libraries get installed by Linux's package managers and just 
work, but for D.

Right now the easiest way to boot up a new project is to copy one 
that already exists, rename it, and edit the dub.json file to 
add/remove any dependencies. This gets old really quickly and is 
the only reason why D doesn't really feel like a scripting 
language for small projects, because setting up the environment 
and frequently used dependencies takes longer than writing the 
script, and you need a project directory instead of a single .d 
file that just uses all your common imports.



 Feb 03 2016



  parent reply Tofu Ninja <emmons0 purdue.edu>  writes:


On Wednesday, 3 February 2016 at 11:22:50 UTC, Márcio Martins 
wrote:

 How would you select the package version you want to use. 
 Obviously it would be fine for small scripts to pick the latest 
 version, but no so much for non-trivial projects.

 Somewhat related: I would love to be able to install packages 
 with dub "globally", and then have them automatically added to 
 the compiler's search paths and working with import with rdmd 
 and dmd.

 I install version 0.1 of package X globally and now all my 
 programs pick that up with import. If the package is a library, 
 dub would (re)compile then upon installation and put the 
 resulting libs in the correct places so that all my programs 
 can simply link to them.
 I should also be able to override the global import with a 
 different version at the project level if I which to do so. 
 Similar to what dub.selections.json currently does.

 Having dub fully integrated with the compiler and it's 
 configuration would be a major quality of life improvement, and 
 a nice step towards the "it just works" state. Much like C/C++ 
 libraries get installed by Linux's package managers and just 
 work, but for D.

 Right now the easiest way to boot up a new project is to copy 
 one that already exists, rename it, and edit the dub.json file 
 to add/remove any dependencies. This gets old really quickly 
 and is the only reason why D doesn't really feel like a 
 scripting language for small projects, because setting up the 
 environment and frequently used dependencies takes longer than 
 writing the script, and you need a project directory instead of 
 a single .d file that just uses all your common imports.


There are a few problems with it. For instance dub packages have 
no information about the files in them, you can't ask dub for 
derelict.opengl3.gl3.d, you ask it for the package derelict-gl3. 
So for something like this to work, there would need to be some 
type of syntax to import the package.

Probably something simple could be done like pragma(dub, 
"derelict-gl3", "==1.0.12");. As far as I can tell a dub pragma 
could be 100% ignored by the compiler unless a flag gets passed 
to print the dub dependencies. Then a tool like rdmd that gets 
all the imports for a file could also get all the dub 
dependencies and call out to dub to download them and pass the 
import paths for the dub dependencies to the final invocation of 
dmd. Otherwise the dub pragma would really do nothing other than 
be a signifier to outside tools. Tools like dcd could even use 
the pragmas to automatically call out to dub to find the paths of 
the dependencies and start indexing them for auto completion.

Really would be a great day to have that all automatically work. 
Also dub could be packaged with dmd and make all this more simple.

Right now the easiest way to use dub is to make a .json for your 
own project and build with dub, but honestly that sucks a lot 
because really the only thing people want to use dub for is the 
dependencies, the rest of it kinda gets in the way and is 
annoying as hell to use. Like trying to figure out how to build 
projects for x64 or unittests or whatever with dub is a pain. Its 
not really what people want to use dub for, but it tries to pass 
itself off as a build system which it sucks at.



 Feb 03 2016



  parent reply Tofu Ninja <emmons0 purdue.edu>  writes:


On Wednesday, 3 February 2016 at 23:35:21 UTC, Tofu Ninja wrote:

 ...


Actually now that I think about it, you can do with out the 
pragma and just define something like this...

mixin template DubDependency(string dependency, string vers)
{
	// Does nothing but print a dependency
	version(Dub_Dependency){
		pragma(msg, "DubDependency: \"" ~ dependency ~ "\" \"" ~ vers ~ 
"\"");
	}
}


Then whenever you need it you just put:
mixin DubDependency!("derelict-gl3", "==1.0.12");

And to get the dependencies for a file you can just do
dmd test.d -o- -version=Dub_Dependency



 Feb 03 2016



  parent reply Tofu Ninja <emmons0 purdue.edu>  writes:


On Thursday, 4 February 2016 at 00:50:43 UTC, Tofu Ninja wrote:

 On Wednesday, 3 February 2016 at 23:35:21 UTC, Tofu Ninja wrote:

 ...


 Actually now that I think about it, you can do with out the 
 pragma and just define something like this...

 mixin template DubDependency(string dependency, string vers)
 {
 	// Does nothing but print a dependency
 	version(Dub_Dependency){
 		pragma(msg, "DubDependency: \"" ~ dependency ~ "\" \"" ~ vers 
 ~ "\"");
 	}
 }


 Then whenever you need it you just put:
 mixin DubDependency!("derelict-gl3", "==1.0.12");

 And to get the dependencies for a file you can just do
 dmd test.d -o- -version=Dub_Dependency


Actually, nvm, wouldn't actually work because as soon as you add 
an import derelict.opengl3.gl3; it would error out because it 
cant find the file and it wouldn't print the dependencies.



 Feb 03 2016



  parent  Chris Wright <dhasenan gmail.com>  writes:


On Thu, 04 Feb 2016 01:23:14 +0000, Tofu Ninja wrote:


 Actually, nvm, wouldn't actually work because as soon as you add an
 import derelict.opengl3.gl3; it would error out because it cant find the
 file and it wouldn't print the dependencies.


You could do it with libdparse, since it doesn't do semantic analysis.



 Feb 03 2016



prev sibling  parent  Chris Wright <dhasenan gmail.com>  writes:


On Fri, 29 Jan 2016 16:07:48 +0000, Adam D. Ruppe wrote:


 I'd love it if you could do `import thirdparty.independent;` and it
 magically works too - without even need for a configuration file or an
 install command. And the docs are right there and tutorials are written
 however the author feels like writing them.


That's how Go does it. It's not the case that Go doing things one way 
means that you should do the opposite, but it is an indication that you 
should look for other examples before following suit.

In the case of dependencies, they should always be versioned. The 
language and standard library should be stable enough that you don't have 
to specify a version you  depend on -- though that isn't always true. So 
are you going to include a version specifier in import statements now? 
That would be awkward.



 Feb 02 2016



prev sibling next sibling parent  Adam D. Ruppe <destructionator gmail.com>  writes:


On Thursday, 28 January 2016 at 11:25:08 UTC, Laeeth Isharc wrote:

 As you yourself have mentioned, the size of the D community as 
 it stands today presents some impediment to the possible 
 maintenance and stability of alternative libraries.  If 
 something is in Phobos you know that you can depend on it, that 
 bugs will get fixed, and that changes to the language won't 
 stop the code from compiling (since it will be fixed).



On the other hand, Phobos is so tightly coupled to dmd that if 
you want a Phobos bugfix, you might also be stuck with a dmd 
regression and get nowhere.

Moreover, Phobos doesn't really get all that many bug fixes. It 
lags on the release cycle and a few modules are basically just 
abandoned. Third party alternatives have been available the whole 
time though.


 The bus factor is high for external libraries - people get 
 sick, divorced, change interest, and so on.


But there's nothing stopping you from forking it yourself...



 Jan 28 2016



prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com>  writes:


On Thursday, 28 January 2016 at 11:25:08 UTC, Laeeth Isharc wrote:

 I do like the building-block idea you suggest, but one must 
 think about the deeper reasons for why things are owned by 
 which people.  (I have found the Coase theorem and work on 
 industrial organisation to be quite stimulating in thinking 
 about this question).

 In theory it's completely irrelevant as to whether is something 
 is in the standard library or can just be imported via dub or a 
 git clone, but in practice that's not the case.


Sigh...

The Coase Theorem is about externalities. The whole point of the 
Coase theorem is that when one person is causing a nuisance or 
polluting it is costly to bargain so the efficient allocation may 
not result. The law/courts should assign property rights in such 
a way to maximize efficiency. This does not seem relevant.

Based on the second paragraph, I think you meant Ronald Coase's 
work in the paper The Nature of the Firm. This paper asks the 
question why things are made in a firm or contracted to other 
firms. This clearly parallels your discussion of why things are 
included in phobos or not.

However, the whole point of the Nature of the Firm is that 
transaction costs exist in the real world. Firms trade-off the 
transaction costs of contracting business outside the firm with 
the benefits of doing things in house. These pressures lead to 
constraints on the maximum size of a firm.

Coming back to phobos and the fact that there are transaction 
costs in the real world (discussions on the forum about the 
future of D are clearly transaction costs), this implies that "in 
theory" it is not irrelevant as to whether something is in the 
standard library or not. As discussed elsewhere, there are 
clearly benefits to putting some things in phobos (if only for 
providing a framework for others), and there are costs as it gets 
too large.



 Jan 28 2016



  parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=  writes:


On Thursday, 28 January 2016 at 16:12:44 UTC, jmh530 wrote:

 the standard library or not. As discussed elsewhere, there are 
 clearly benefits to putting some things in phobos (if only for 
 providing a framework for others), and there are costs as it 
 gets too large.


That's the maintenance costs, but there are other related costs:

1. It takes a lot of work to get it in, you have to negotiate 
with non-domain experts to get in improvements.

2. The presence of sub-optimal standard functionality discourage 
development of slightly better functionality as a third party 
solution. So you loose evolutionary advantages.

3. You cannot easily modify it as it is distributed with the 
compiler. A standard library is essentially an API with a 
reference implementation, but compilers can do whatever they want 
in terms of implementation. Changes can therefore lead to 
incompatibilities between compilers.

4. You cannot easily fix bugs, because applications depends on 
the old behaviour. So a bug fix is a breaking change. You have to 
deprecate and provide the same functionality under a new name 
instead.

External libraries can avoid a lot of these issues by versioning. 
Selecting between many different versions of submodules of a 
standard library is way too complicated.



 Jan 28 2016



  parent  Rory McGuire via Digitalmars-d-announce  writes:


On 28 Jan 2016 6:30 PM, "Ola Fosheim Gr=C3=B8stad via Digitalmars-d-announc=
e" <
digitalmars-d-announce puremagic.com> wrote:


[snip]

 4. You cannot easily fix bugs, because applications depends on the old


behaviour. So a bug fix is a breaking change. You have to deprecate and
provide the same functionality under a new name instead.

 External libraries can avoid a lot of these issues by versioning.


Selecting between many different versions of submodules of a standard
library is way too complicated.


This is the main problem with "batteries included".
While just providing default libraries for specific domains through dub
solves the 3rd party Isis purple have mentioned there is no way a batteries
included standard library can keep backwards compatibility and be a
pleasure to work with, for those working on it and those using it.



 Jan 31 2016



prev sibling  parent  Matt Elkins <notreal fake.com>  writes:


On Thursday, 28 January 2016 at 11:25:08 UTC, Laeeth Isharc wrote:

 In theory it's completely irrelevant as to whether is something 
 is in the standard library or can just be imported via dub or a 
 git clone, but in practice that's not the case.


In support of this statement in particular I'd like to point out 
that there are many environments which, for various reasons of 
security and policy, often require that any 3rd-party libraries 
not included as a language's standard be explicitly vetted by 
teams of very slow-moving people who seem to actively enjoy 
paperwork. In practice this means that non-standard libraries 
simply don't get used in those environments. That said, if a 
library gets popular enough (Boost, parts of Apache), they might 
manage to get pre-vetted and still used in these situations.

I'm not really offering a good solution to the debate, I just 
wanted to make a note of this.



 Feb 03 2016



prev sibling  parent reply Martin Nowak <code dawg.eu>  writes:


On Monday, 25 January 2016 at 16:26:36 UTC, Russel Winder wrote:

 PyPI has is an highly opinionated metric that helps you decide 
 what is good and what is dross.


Could you help us on designing one for code.dlang.org as well?



 Jan 27 2016



  parent reply Chris Wright <dhasenan gmail.com>  writes:


On Wed, 27 Jan 2016 21:01:47 +0000, Martin Nowak wrote:


 On Monday, 25 January 2016 at 16:26:36 UTC, Russel Winder wrote:

 PyPI has is an highly opinionated metric that helps you decide what is
 good and what is dross.


 
 Could you help us on designing one for code.dlang.org as well?


I'd want to use the number of releases, how recent the most recent 
release was, the longevity of the project, and the number of other 
projects that depend on it. If people are willing to let dub submit 
anonymous usage information, the number of builds depending on a project 
is also an indicator of its value.

Longevity is an awkward one. If I create a project, do nothing with it 
for four years, then make a release, will that count as well as making a 
release once a month for four years? But the other metrics should account 
for that.

If possible, I'd include when the project last compiled and whether it 
passes its unittests. This requires setting up a continuous integration 
service for untrusted code. I've seen other people's designs for that, 
and I think I could replicate it without too much trouble.



 Jan 27 2016



 next sibling parent  jmh530 <john.michael.hall gmail.com>  writes:


On Wednesday, 27 January 2016 at 22:36:37 UTC, Chris Wright wrote:

 Longevity is an awkward one. If I create a project, do nothing 
 with it for four years, then make a release, will that count as 
 well as making a release once a month for four years? But the 
 other metrics should account for that.


Code I wrote below incorporates some of what you're talking about.

For simplicity, I represented the date of each release as a 
dynamic array of doubles. I applied a weighting function to each 
and then calculated the entropy. The score is 1 if you only have 
one release. The score is higher, the more releases you have. If 
you have one release five years ago and one release recently, 
then your score is only marginally higher than 1. But if you have 
lots of recent releases, then the score is much more favorable.

You could probably adjust this in a number of ways. For instance, 
adjusting the denominator in
return weight.map!(a => a / weight.sum());
you could make it so that a release today is better than a 
release five years ago.


auto weight(double[] x, double lambda)
{
	import std.algorithm : sum, map;
	import std.math : exp;
	import std.array : array;
	
	auto weight = x.map!(a => lambda * exp(-lambda * a));	// weights 
given by
								// exponential
								// distribution
	return weight.map!(a => a / weight.sum());
}

double entropy(T)(T x)
{
	import std.algorithm : sum, map;
	import std.math : exp, log;
	
	auto e = x.map!(a => a * log(a));
	return exp(-sum(e));
}

double calc_score(double[] x, double lambda)
{
	return x.weight(lambda).entropy();
}

void main()
{
	import std.stdio : writeln;
	
	double lambda = 0.5; // controls decay in weighting function
	double[] x;	     // represents years since last update
	x = [0.1, 0.25, 1, 2, 5];
	
	auto score = calc_score(x, lambda);

	writeln(score);
}



 Jan 27 2016



prev sibling  parent reply Twenty Two <sdffgfsd sgsd.com>  writes:


Parkinson's Law: work expands so as to fill the time available 
for its completion.

Having a set of vague tasks to finish within 6 months is great, 
but having a weekly more specific priority list to go along with 
it would be better. If, in addition, there was some 
accountability (not with negative implications, just a 
designation of responsibility) that would further narrow focus 
and ramp up productivity.

As a draft proposal, something like a weekly sticky TODO thread 
with clear goals could work. You'd list a few high priority items 
and ask for a volunteers for each and list them as they come in. 
You'd have bigger medium priority item list and ask for 
volunteers but only half of them need to be assigned to someone 
and completed. Then you'd have a much longer lower priority list 
that can be a bit more vague that people are encouraged to work 
on but that they don't need to volunteer for, just submit their 
pull requests (but they can flag an item and have it ticked off 
if they want). On top of that have a weekly pull request goal 
that updates daily (with a time stamp) and an overview of pull 
request numbers from previous weeks.

If an item isn't completed it gets rolled over to the next week 
with an asterisk (if it's medium or high priority) for each time 
it's been rolled over and the previous volunteer listed as such 
(and they can volunteer for the same item the next week giving 
them the perfect opportunity to say where they're at, what needs 
to be done, if the task should be broken down further, etc). 
It'll make it clear if whoever volunteered for a task needs some 
help or encouragement, or if certain high priority tasks need a 
volunteer or to be broken down into more manageable chunks even 
if someone drops off the face of the earth. With a one item at a 
time rule you're going to cut down on stagnation.

I'm sure there are lots of people who'd like to help out but 
they're not really sure what needs to be done or who else is 
doing it or if they'll step on toes, etc. Anyone wondering what's 
being worked on can take a look and help out themselves rather 
than getting upset in the forums about feature x never seeing the 
light of day. If they want feature x done they can take a look at 
the priority list and pick where it should go in the scheme of 
things, maybe even break it down - turn negative energy into 
productive energy :)



 Jan 27 2016



  parent reply Joakim <dlang joakim.fea.st>  writes:


On Thursday, 28 January 2016 at 00:28:26 UTC, Twenty Two wrote:

 Parkinson's Law: work expands so as to fill the time available 
 for its completion.

 [...]


I agree.  Some of the core team uses trello for this:

https://trello.com/b/XoFjxiqG/active

However, that's not really meant for noobs and a lot of the core 
team, including Walter, doesn't really use it.



 Jan 27 2016



  parent  Twenty Two <sdffgfsd sgsd.com>  writes:


On Thursday, 28 January 2016 at 02:36:55 UTC, Joakim wrote:

 On Thursday, 28 January 2016 at 00:28:26 UTC, Twenty Two wrote:

 Parkinson's Law: work expands so as to fill the time available 
 for its completion.

 [...]


 I agree.  Some of the core team uses trello for this:

 https://trello.com/b/XoFjxiqG/active

 However, that's not really meant for noobs and a lot of the 
 core team, including Walter, doesn't really use it.


Judging by the activity log, it's mostly just Martin... poor dawg.

Putting something together people will actually use is pretty 
hard, almost as hard as keeping the momentum to get people to 
keep using whatever you've put in place. Trello's not a bad tool 
but it's useless if there's no traction and no one's being 
reminded to use it. It's hard to attract contributors if you 
don't spell out who/what/when/where/how and funnel them all to 
the one place.

Maybe the core team could discuss among themselves what kind of 
workflow they think would really bring out their potential 
productivity and attract more hands to lighten the load. It seems 
unfair that some people get lumped with doing big jobs purely 
because there isn't really a good way to ask someone else to do 
pieces of it for them.

I'm certain there are lots more people who would get involved if 
only there was a lower barrier to entry. Something not over 
complicated and visible would really move things along, I think.



 Jan 28 2016



prev sibling  parent reply Piotrek <nodata nodata.pl>  writes:


On Monday, 25 January 2016 at 03:49:56 UTC, Rikki Cattermole 
wrote:

 That won't be happening anytime soon.
 Until we have image and windowing in Phobos (I'm working on 
 both) there is no way a GUI toolkit is going in. And from what 
 I know there will be a LOT of work to update it.


I've read this thread partially and I agree with you. In my 
opinion the key to the success is a good standard library with 
batteries included.

The opinion that this approach is outdated is very subjective.

I hope D GUI will be usable some day for me and other people not 
wanting to fight with tools (and external libraries).

If there is something from your project ready for test drive let 
me know.

Piotrek



 Jan 28 2016



 next sibling parent reply Rikki Cattermole <alphaglosined gmail.com>  writes:


On 29/01/16 6:40 AM, Piotrek wrote:

 On Monday, 25 January 2016 at 03:49:56 UTC, Rikki Cattermole wrote:

 That won't be happening anytime soon.
 Until we have image and windowing in Phobos (I'm working on both)
 there is no way a GUI toolkit is going in. And from what I know there
 will be a LOT of work to update it.


 I've read this thread partially and I agree with you. In my opinion the
 key to the success is a good standard library with batteries included.

 The opinion that this approach is outdated is very subjective.

 I hope D GUI will be usable some day for me and other people not wanting
 to fight with tools (and external libraries).

 If there is something from your project ready for test drive let me know.

 Piotrek


Right now, image library is more or less ready for next feedback.
Windowing is almost there, really just needs a bit of testing and its done.

So in other words, the hold up, is me.



 Jan 28 2016



  parent reply Piotrek <nodata nodata.pl>  writes:


On Friday, 29 January 2016 at 02:18:38 UTC, Rikki Cattermole 
wrote:

 Right now, image library is more or less ready for next 
 feedback.
 Windowing is almost there, really just needs a bit of testing 
 and its done.

 So in other words, the hold up, is me.


Where can I find the code to be tested? You have too many 
projects on github :)

Piotrek



 Feb 06 2016



  parent  Rikki Cattermole <alphaglosined gmail.com>  writes:


On 07/02/16 4:23 AM, Piotrek wrote:

 On Friday, 29 January 2016 at 02:18:38 UTC, Rikki Cattermole wrote:

 Right now, image library is more or less ready for next feedback.
 Windowing is almost there, really just needs a bit of testing and its
 done.

 So in other words, the hold up, is me.


 Where can I find the code to be tested? You have too many projects on
 github :)

 Piotrek


https://github.com/rikkimax/alphaPhobos



 Feb 06 2016



prev sibling  parent  Andre Polykanine via Digitalmars-d-announce  writes:


PvDda> I hope D GUI will be usable some day for me and other people not
PvDda> wanting to fight with tools (and external libraries).

Oh  yeah!  I  find  this  library  the  most  adequate  (and  the most
accessible, btw). But unfortunately it seems abandoned :(.


Andre



 Feb 02 2016



prev sibling  parent reply Andrew Edwards <edwards.ac gmail.com>  writes:


On Monday, 25 January 2016 at 03:21:51 UTC, Puming wrote:

 On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
 wrote:

 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- 
 Andrei




[snip]


 For tooling, I suggest a look at GUI/IDEs, now that 
 dlangui/dlangide seems a good candidate(native D, 
 crossplatform). A good official supported GUI library will 
 attract many people.


I truly doubt that. It would be truly amazing if that were to 
occur but history has proven otherwise. The sentiment was 
expressed so many times that Walter was finally moved to sanction 
DWT as the official GUI for D in 2006. Even a newsgroup was made 
for it. It's ten years later. DWT anyone?

Aurora was a recent attempt that was shelved for the sole 
author's personal reasons. Result?

Sadly, dlangui/dlangide is no different. It has one developer. If 
that individual gets discouraged, like so many others have so 
far, what becomes of it?

Until members of the community starts combining efforts and 
working together to improve the situation, it will not improve. 
You have Adam working on working on simpledisplay, Mike working 
on Derelict, Felix working on three-d, Vladimir working on 
ae-graphics, Martin on freeimage, Vadim on dlangui/dlangide and 
who knows what else is out there in the wood works. All of this 
is admirable and appreciated but imagine what would be possible 
if these minds teamed up, mapped out a graphic solution for the 
language and united efforts in implementing it!

I'm convinced that without such a deliberate effort, this 
situation will not change for years to come. Even if a particular 
library is dubbed "The One." Like I've said earlier, that was 
already done ten years ago.



 Jan 24 2016



 next sibling parent  Rikki Cattermole <alphaglosined gmail.com>  writes:


On 25/01/16 7:39 PM, Andrew Edwards wrote:

 On Monday, 25 January 2016 at 03:21:51 UTC, Puming wrote:

 On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote:

 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei




 [snip]


 For tooling, I suggest a look at GUI/IDEs, now that dlangui/dlangide
 seems a good candidate(native D, crossplatform). A good official
 supported GUI library will attract many people.


 I truly doubt that. It would be truly amazing if that were to occur but
 history has proven otherwise. The sentiment was expressed so many times
 that Walter was finally moved to sanction DWT as the official GUI for D
 in 2006. Even a newsgroup was made for it. It's ten years later. DWT
 anyone?

 Aurora was a recent attempt that was shelved for the sole author's
 personal reasons. Result?

 Sadly, dlangui/dlangide is no different. It has one developer. If that
 individual gets discouraged, like so many others have so far, what
 becomes of it?

 Until members of the community starts combining efforts and working
 together to improve the situation, it will not improve. You have Adam
 working on working on simpledisplay, Mike working on Derelict, Felix
 working on three-d, Vladimir working on ae-graphics, Martin on
 freeimage, Vadim on dlangui/dlangide and who knows what else is out
 there in the wood works. All of this is admirable and appreciated but
 imagine what would be possible if these minds teamed up, mapped out a
 graphic solution for the language and united efforts in implementing it!

 I'm convinced that without such a deliberate effort, this situation will
 not change for years to come. Even if a particular library is dubbed
 "The One." Like I've said earlier, that was already done ten years ago.


I agree.
This is why everything I'm doing right now for windowing and image 
library builds upon what has come before but in a Phobos quality way.

Unless it is in Phobos, its not good enough as a base IMO.



 Jan 24 2016



prev sibling next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2016-01-25 07:39, Andrew Edwards wrote:


 I truly doubt that. It would be truly amazing if that were to occur but
 history has proven otherwise. The sentiment was expressed so many times
 that Walter was finally moved to sanction DWT as the official GUI for D
 in 2006. Even a newsgroup was made for it. It's ten years later. DWT
 anyone?


DWT is still working perfectly fine. Just compiled it recently with the 
latest beta, 2.070.

-- 
/Jacob Carlborg



 Jan 25 2016



  parent reply Andrew Edwards <edwards.ac gmail.com>  writes:


On Monday, 25 January 2016 at 10:53:29 UTC, Jacob Carlborg wrote:

 On 2016-01-25 07:39, Andrew Edwards wrote:


 I truly doubt that. It would be truly amazing if that were to 
 occur but
 history has proven otherwise. The sentiment was expressed so 
 many times
 that Walter was finally moved to sanction DWT as the official 
 GUI for D
 in 2006. Even a newsgroup was made for it. It's ten years 
 later. DWT
 anyone?


 DWT is still working perfectly fine. Just compiled it recently 
 with the latest beta, 2.070.


Glad to see your spirit is not easily broken. That, however, does 
not invalidate my statement.  One would think that 10 years after 
being dubbed the official graphics library for the language, it 
would be simple to install DMD and DWT side by side on all DMD 
supported platforms and the two just work well together. 
Especially since people that advocated it claimed that by making 
it official, it would legitimize their contributions to help 
improve make improvements. It is not even usable on what appears 
to be the platform you develop on/for, MAC OS X, and you are the 
main maintainer/contributer.



 Jan 25 2016



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2016-01-25 14:22, Andrew Edwards wrote:


 Glad to see your spirit is not easily broken. That, however, does not
 invalidate my statement.  One would think that 10 years after being
 dubbed the official graphics library for the language, it would be
 simple to install DMD and DWT side by side on all DMD supported
 platforms and the two just work well together. Especially since people
 that advocated it claimed that by making it official, it would
 legitimize their contributions to help improve make improvements. It is
 not even usable on what appears to be the platform you develop on/for,
 MAC OS X, and you are the main maintainer/contributer.


The only thing that happened, as far as I know, in terms of official was 
that Walter announced it to be the official GUI and it got its own 
dedicated newsgroup. It's not on the web site, there's been no 
coordinated releases, no contribution from the core team, nothing. I 
don't see how anyone could expect progress to increase at all.

-- 
/Jacob Carlborg



 Jan 25 2016



 next sibling parent reply Iain Buclaw via Digitalmars-d-announce  writes:


On 25 January 2016 at 21:44, Jacob Carlborg via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:


 On 2016-01-25 14:22, Andrew Edwards wrote:

 Glad to see your spirit is not easily broken. That, however, does not

 invalidate my statement.  One would think that 10 years after being
 dubbed the official graphics library for the language, it would be
 simple to install DMD and DWT side by side on all DMD supported
 platforms and the two just work well together. Especially since people
 that advocated it claimed that by making it official, it would
 legitimize their contributions to help improve make improvements. It is
 not even usable on what appears to be the platform you develop on/for,
 MAC OS X, and you are the main maintainer/contributer.


 The only thing that happened, as far as I know, in terms of official was
 that Walter announced it to be the official GUI and it got its own
 dedicated newsgroup. It's not on the web site, there's been no coordinated
 releases, no contribution from the core team, nothing. I don't see how
 anyone could expect progress to increase at all.


With respect, I'm not sure whether anyone in core would have the slightless
hint of knowing how UI works. (Not that I speak for anyone but myself :-)



 Jan 25 2016



  parent  Jacob Carlborg <doob me.com>  writes:


On 2016-01-25 22:15, Iain Buclaw via Digitalmars-d-announce wrote:


 With respect, I'm not sure whether anyone in core would have the
 slightless hint of knowing how UI works. (Not that I speak for anyone
 but myself :-)


And you think that I have the slightest idea of what I'm doing ;)

-- 
/Jacob Carlborg



 Jan 26 2016



prev sibling  parent  Andrew Edwards <edwards.ac gmail.com>  writes:


On Monday, 25 January 2016 at 20:44:10 UTC, Jacob Carlborg wrote:

 On 2016-01-25 14:22, Andrew Edwards wrote:


 Glad to see your spirit is not easily broken. That, however, 
 does not
 invalidate my statement.  One would think that 10 years after 
 being
 dubbed the official graphics library for the language, it 
 would be
 simple to install DMD and DWT side by side on all DMD supported
 platforms and the two just work well together. Especially 
 since people
 that advocated it claimed that by making it official, it would
 legitimize their contributions to help improve make 
 improvements. It is
 not even usable on what appears to be the platform you develop 
 on/for,
 MAC OS X, and you are the main maintainer/contributer.


 The only thing that happened, as far as I know, in terms of 
 official was that Walter announced it to be the official GUI 
 and it got its own dedicated newsgroup. It's not on the web 
 site, there's been no coordinated releases, no contribution 
 from the core team, nothing. I don't see how anyone could 
 expect progress to increase at all.


My point exactly. Simply naming something official does not 
improve it's status or send contributors clamoring to assist in 
its improvement. It takes a deliberate effort and dedication of 
resources to accomplish that.



 Jan 25 2016



prev sibling  parent reply JohnCK <j j.com>  writes:


On Monday, 25 January 2016 at 06:39:54 UTC, Andrew Edwards wrote:

 On Monday, 25 January 2016 at 03:21:51 UTC, Puming wrote:

 On Monday, 25 January 2016 at 02:37:40 UTC, Andrei 
 Alexandrescu wrote:

 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- 
 Andrei




 [snip]


 For tooling, I suggest a look at GUI/IDEs, now that 
 dlangui/dlangide seems a good candidate(native D, 
 crossplatform). A good official supported GUI library will 
 attract many people.


 I truly doubt that. It would be truly amazing if that were to 
 occur but history has proven otherwise. The sentiment was 
 expressed so many times that Walter was finally moved to 
 sanction DWT as the official GUI for D in 2006. Even a 
 newsgroup was made for it. It's ten years later. DWT anyone?

 Aurora was a recent attempt that was shelved for the sole 
 author's personal reasons. Result?

 Sadly, dlangui/dlangide is no different. It has one developer. 
 If that individual gets discouraged, like so many others have 
 so far, what becomes of it?

 Until members of the community starts combining efforts and 
 working together to improve the situation, it will not improve. 
 You have Adam working on working on simpledisplay, Mike working 
 on Derelict, Felix working on three-d, Vladimir working on 
 ae-graphics, Martin on freeimage, Vadim on dlangui/dlangide and 
 who knows what else is out there in the wood works
 ...
 I'm convinced that without such a deliberate effort, this 
 situation will not change for years to come. Even if a 
 particular library is dubbed "The One." Like I've said earlier, 
 that was already done ten years ago.



Well, I think the question is: IDE is a main thing today? If you 
take the languages that emerged along the years, some of them are 
backed most on web toolkit/Internet.

Please don't get me wrong and I'm not saying this is NOT 
important. But today I think perhaps this kind of thing is 
turning into a niche.

I think vibe.d or whatever web toolkit should get more attention.

JohnCK.



 Jan 25 2016



  parent reply Daniel Kozak via Digitalmars-d-announce  writes:


V Mon, 25 Jan 2016 16:25:02 +0000
JohnCK via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> napsáno:


 On Monday, 25 January 2016 at 06:39:54 UTC, Andrew Edwards wrote:
 ...
 Well, I think the question is: IDE is a main thing today? If you 
 take the languages that emerged along the years, some of them are 
 backed most on web toolkit/Internet.
 
 Please don't get me wrong and I'm not saying this is NOT 
 important. But today I think perhaps this kind of thing is 
 turning into a niche.
 
 I think vibe.d or whatever web toolkit should get more attention.
 
 JohnCK.


I guess you mean GUI not IDE?



 Jan 25 2016



  parent  JohnCK <j j.com>  writes:


On Monday, 25 January 2016 at 16:34:15 UTC, Daniel Kozak wrote:

 I guess you mean GUI not IDE?


Yes GUI... my fault, thanks!

JohnCK.



 Jan 25 2016



prev sibling next sibling parent  tsbockman <thomas.bockman gmail.com>  writes:


On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:

 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


Re: "Safety" and "Library additions", I anticipate that my 
`checkedint` module (a refinement and extension of Robert 
Schadek's `SafeInt` work) will be ready to start formal review 
within the next 1-2 months.

I uploaded it to DUB yesterday: 
http://code.dlang.org/packages/checkedint

TODO: Mostly documentation (coming this week, probably) and unit 
tests (it has tests, but they're too slow to stick directly in 
Phobos), but also miscellaneous small things.



 Jan 24 2016



prev sibling next sibling parent  Chris Wright <dhasenan gmail.com>  writes:


On Sun, 24 Jan 2016 21:37:40 -0500, Andrei Alexandrescu wrote:


 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


I'm not fond of the militaristic terminology for participants. Novice, 
adept, master, maybe?

The section on safety is pretty short. I'd like to see in it:
* Guidelines for what should be made  trusted in Phobos (should we trust 
Win/Posix API functions? should we only trust wrappers that take D arrays 
rather than pointers? can we, for instance, create a  trusted wrapper 
around curl?)
* Efficiency / safety tradeoff guidelines (should Phobos provide a 
slightly faster implementations of things that aren't  safe? In those 
cases, should it provide both  safe and fast alternatives?)
*  safe /  trusted IO as a goal

As is, there are a smattering of things in Phobos that aren't  safe but 
seem like they could or should be, with no explanation and no safe 
alternatives. I think almost all IO is  system. This makes it hard and 
sometimes confusing to try to write  safe code.



 Jan 24 2016



prev sibling next sibling parent  Jack Stouffer <jack jackstouffer.com>  writes:


On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:

 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


My biggest issue with these documents is that they have good 
ideas but rarely have plans to achieve them. As a consequence, 
most of these documents say how half or more of the previous 
goals were not achieved.

I believe the best way to fix this is to simply have more focus. 
Have one large goal that can be broken down into smaller subsets, 
e.g. "2016 will be the year of a GC free Phobos". Something that 
has a very clear way of quantifying its success and a clear path 
to that goal.

Not that that the other things are not important, but if you 
constantly find yourself failing to meet your goals, the only 
rational option is to become more realistic in your plans.



 Jan 24 2016



prev sibling next sibling parent  rsw0x <anonymous anonymous.com>  writes:


On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:

 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


Would be great if shared finally got the love it needs, and 
you're one of the few people qualified to do it(in my humble 
opinion), Andrei.
It was part of the 2015H1 vision, IIRC.



 Jan 24 2016



prev sibling next sibling parent reply Dibyendu Majumdar <d.majumdar gmail.com>  writes:


On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:

 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


Hi,

I am new to D, and having my own language implementation (based 
off Lua) - therefore I think I can appreciate some of the 
difficulties around getting more contributors to D. For what its 
worth below are some thoughts on the H1 2016 priorities.

I am a would be D user - D is a tool that should help me get my 
job done. I guess the vast majority of potential users are in 
this bracket. To become a contributor requires one of the 
following - a) it must be your day job, i.e. someone paying you 
to work on the language, or b) you happen to have lots of free 
time and deeply interested in D's development, plus have the 
skills needed to contribute to D. I think that getting 
contributors to the core of D is going to be difficult. Most 
other languages/compilers that have big list of contributors 
usually have one or more large organisations funding the people 

into this category. I am not sure about Python, but I suspect 
companies like Google sponsored a lot of the work done in Python.

Assuming that above is correct and that you will only have a 
handful of people who can contribute to core D - then it seems to 
me that the effort needs to be a) least wasteful, and b) highly 
focused. Right now, there are multiple implementations of D 
compiler - DMD, GDC, LDC, SDC - here you have a bunch of people 
who obviously have the time, the knowledge and the desire to 
develop D. Yet the effort is spread out into several different 
implementations, and therefore wasteful. Why not form a core 
group and settle on one implementation and everyone focus on 
that? I know this is very hard as no one would be willing to give 
up their creation, but for the greater good of D? Perhaps you 
could assess each implementation and settle on the one that has 
the most technical merit and future proofing?

As a D user who wishes to use D as a better C / C++ - my personal 
needs are following:

a) D should work on the three major platforms - Windows, Linux 
and OSX.
b) It should be possible to write code in D that one would have 
written in C / C++ - i.e. let the programmer have full control.
c) A good debugger on all supported platforms is essential for 
any complex language.
d) A good IDE is essential to attract users accustomed to 
Eclipse, IntelliJ, Visual Studio.
e) A core library that handles the most basic stuff.
f) Ability to easily import C libraries. I struggled with htod - 
haven't tried dstep yet - but implementing tooling based on Clang 
seems sensible.

The need to have a good standard GUI toolkit is not so great 
these days as users are moving away from Desktop applications.

I realise that interfacing with C++ seems like a big goal - but 
to be honest this isn't important to me. C++ isn't the standard 
for cross language interfacing ... C is.

Regards
Dibyendu



 Jan 25 2016



  parent  Joakim <dlang joakim.fea.st>  writes:


On Monday, 25 January 2016 at 18:11:24 UTC, Dibyendu Majumdar 
wrote:

 On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
 wrote:

 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- 
 Andrei


 Hi,

 I am new to D, and having my own language implementation (based 
 off Lua) - therefore I think I can appreciate some of the 
 difficulties around getting more contributors to D. For what 
 its worth below are some thoughts on the H1 2016 priorities.

 I am a would be D user - D is a tool that should help me get my 
 job done. I guess the vast majority of potential users are in 
 this bracket. To become a contributor requires one of the 
 following - a) it must be your day job, i.e. someone paying you 
 to work on the language, or b) you happen to have lots of free 
 time and deeply interested in D's development, plus have the 
 skills needed to contribute to D. I think that getting 
 contributors to the core of D is going to be difficult. Most 
 other languages/compilers that have big list of contributors 
 usually have one or more large organisations funding the people 

 fall into this category. I am not sure about Python, but I 
 suspect companies like Google sponsored a lot of the work done 
 in Python.

 Assuming that above is correct and that you will only have a 
 handful of people who can contribute to core D - then it seems 
 to me that the effort needs to be a) least wasteful, and b) 
 highly focused. Right now, there are multiple implementations 
 of D compiler - DMD, GDC, LDC, SDC - here you have a bunch of 
 people who obviously have the time, the knowledge and the 
 desire to develop D. Yet the effort is spread out into several 
 different implementations, and therefore wasteful. Why not form 
 a core group and settle on one implementation and everyone 
 focus on that? I know this is very hard as no one would be 
 willing to give up their creation, but for the greater good of 
 D? Perhaps you could assess each implementation and settle on 
 the one that has the most technical merit and future proofing?


dmd, gdc, and ldc already share a common frontend.  Walter, the 
main dmd developer, will never look at the llvm or gcc backends 
for legal reasons; the gcc devs likely won't touch anything 
that's not GPL; and the ldc devs likely prefer the license or 
implementation of llvm.  I'm not sure what motivates the sdc 
devs, but it's likely having a frontend written in D itself that 
is focused on being easily used as a library, which dmd's 
recently translated D frontend isn't.  Other than sdc, I doubt 
there's actually much code duplication going on, so I don't think 
this redundancy hurts.


 As a D user who wishes to use D as a better C / C++ - my 
 personal needs are following:

 a) D should work on the three major platforms - Windows, Linux 
 and OSX.
 b) It should be possible to write code in D that one would have 
 written in C / C++ - i.e. let the programmer have full control.
 c) A good debugger on all supported platforms is essential for 
 any complex language.
 d) A good IDE is essential to attract users accustomed to 
 Eclipse, IntelliJ, Visual Studio.
 e) A core library that handles the most basic stuff.
 f) Ability to easily import C libraries. I struggled with htod 
 - haven't tried dstep yet - but implementing tooling based on 
 Clang seems sensible.


I don't think there has ever been a language that would fulfill 
all these requirements, let alone an OSS one that was available 
free of charge.  D gets you some of the way, but it cannot grant 
you all your wishes.


 The need to have a good standard GUI toolkit is not so great 
 these days as users are moving away from Desktop applications.


Yeah, a couple toolkits in dub is fine.


 I realise that interfacing with C++ seems like a big goal - but 
 to be honest this isn't important to me. C++ isn't the standard 
 for cross language interfacing ... C is.


Which is why D long didn't support interfacing with C++.  But the 
leadership feels there is some untapped market out there that 
will warm to D once it can interface with C++ better, and I avoid 
C++ like the plague so I can't say if that's true or not.  I know 
that I personally don't care for such C++ integration- nor do 
many in the D community, or they wouldn't be using D already- but 
those who do seem to have their ear for now.



 Jan 25 2016



prev sibling next sibling parent reply Tofu Ninja <emmons0 purdue.edu>  writes:


On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:

 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


Just out of curiosity, is getting the different compilers in sync 
still a priority? Right now we have dmd at 2.070, ldc at 2.068. 
and gdc at 2.066.



 Jan 29 2016



  parent reply Iain Buclaw via Digitalmars-d-announce  writes:


On 29 Jan 2016 6:55 pm, "Tofu Ninja via Digitalmars-d-announce" <
digitalmars-d-announce puremagic.com> wrote:

 On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote:

 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei



 Just out of curiosity, is getting the different compilers in sync still a


priority? Right now we have dmd at 2.070, ldc at 2.068. and gdc at 2.066.

If anyone wants to help out...

I have to also juggle working on GCC and GDB. :-)

When gdc reaches 2.068 (GCC 7.1 is the target release next year) - expect
it to stay there for a while...



 Jan 29 2016



  parent reply Tofu Ninja <emmons0 purdue.edu>  writes:


On Friday, 29 January 2016 at 18:13:21 UTC, Iain Buclaw wrote:

 On 29 Jan 2016 6:55 pm, "Tofu Ninja via Digitalmars-d-announce" 
 < digitalmars-d-announce puremagic.com> wrote:

 On Monday, 25 January 2016 at 02:37:40 UTC, Andrei 
 Alexandrescu wrote:

 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- 
 Andrei



 Just out of curiosity, is getting the different compilers in 
 sync still a


 priority? Right now we have dmd at 2.070, ldc at 2.068. and gdc 
 at 2.066.

 If anyone wants to help out...

 I have to also juggle working on GCC and GDB. :-)

 When gdc reaches 2.068 (GCC 7.1 is the target release next 
 year) - expect it to stay there for a while...


It would be nice if keeping them in sync was a priority, I would 
love to use GDC so I could use GDB, but not having the latest 
fixes is simply not worth it. Even simple things dont work when 
you go back just a few versions, like in 2.066 isForwardRange is 
not correct and does not work properly, something as simple as 
that does not work. Not to mention using the new stuff like 
allocators.



 Jan 29 2016



  parent reply Iain Buclaw via Digitalmars-d-announce  writes:


On 29 January 2016 at 21:14, Tofu Ninja via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:


 On Friday, 29 January 2016 at 18:13:21 UTC, Iain Buclaw wrote:


 On 29 Jan 2016 6:55 pm, "Tofu Ninja via Digitalmars-d-announce" <
 digitalmars-d-announce puremagic.com> wrote:


 On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote:


 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei



 Just out of curiosity, is getting the different compilers in sync still a


 priority? Right now we have dmd at 2.070, ldc at 2.068. and gdc at 2.066.

 If anyone wants to help out...

 I have to also juggle working on GCC and GDB. :-)

 When gdc reaches 2.068 (GCC 7.1 is the target release next year) - expect
 it to stay there for a while...


 It would be nice if keeping them in sync was a priority, I would love to
 use GDC so I could use GDB, but not having the latest fixes is simply not
 worth it. Even simple things dont work when you go back just a few
 versions, like in 2.066 isForwardRange is not correct and does not work
 properly, something as simple as that does not work. Not to mention using
 the new stuff like allocators.


How much of it actually depends on the compiler though?  I'd be a little
surprised if we couldn't backport at least 80% of phobos to 2.067/2.068
with zero changes.



 Jan 29 2016



  parent reply Tofu Ninja <emmons0 purdue.edu>  writes:


On Friday, 29 January 2016 at 20:30:35 UTC, Iain Buclaw wrote:

 How much of it actually depends on the compiler though?  I'd be 
 a little surprised if we couldn't backport at least 80% of 
 phobos to 2.067/2.068 with zero changes.


I have no idea, I think you are probably right. But having a 
compiler and phobos out of sync sounds even worse than the way it 
is now. A better solution for me would be to just stick with a 
version and wait for gdc to catch up but honestly it seems like 
as soon as a new version comes out I hit some bug that is only 
fixed in the latest version, forcing me to upgrade.

For example this literally happened days ago, I am currently at 
2.069 and the other day I needed to call some winapi stuff, only 
to realize the winapi bindings are way outdated, well guess what 
they are updated in 2.070. Its amazing how often I hit a problem 
and then find out its fixed in the next version.



 Jan 29 2016



  parent reply Iain Buclaw via Digitalmars-d-announce  writes:


On 29 January 2016 at 22:29, Tofu Ninja via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:


 On Friday, 29 January 2016 at 20:30:35 UTC, Iain Buclaw wrote:


 How much of it actually depends on the compiler though?  I'd be a little
 surprised if we couldn't backport at least 80% of phobos to 2.067/2.068
 with zero changes.


 I have no idea, I think you are probably right. But having a compiler and
 phobos out of sync sounds even worse than the way it is now. A better
 solution for me would be to just stick with a version and wait for gdc to
 catch up but honestly it seems like as soon as a new version comes out I
 hit some bug that is only fixed in the latest version, forcing me to
 upgrade.

 For example this literally happened days ago, I am currently at 2.069 and
 the other day I needed to call some winapi stuff, only to realize the
 winapi bindings are way outdated, well guess what they are updated in
 2.070. Its amazing how often I hit a problem and then find out its fixed in
 the next version.


I know, I've been hitting bug after bug in 2.067, and the answer has always
been to backport from 2.068.  I already have backported druntime's object.d
from 2.068 because 2.067's object module has drifted so far out of sync
with it's hidden implementation, I couldn't build anything!  So I might as
well backport the rest of the druntime library.  Nothing much has changed
as it was a "bugfix" release.

Iain.



 Jan 31 2016



  parent reply Daniel Murphy <yebbliesnospam gmail.com>  writes:


On 1/02/2016 8:46 AM, Iain Buclaw via Digitalmars-d-announce wrote:

 I know, I've been hitting bug after bug in 2.067, and the answer has always
 been to backport from 2.068.  I already have backported druntime's object.d
 from 2.068 because 2.067's object module has drifted so far out of sync
 with it's hidden implementation, I couldn't build anything!  So I might as
 well backport the rest of the druntime library.  Nothing much has changed
 as it was a "bugfix" release.


The process will be complete when you've backported the entirety of 2.068.



 Feb 01 2016



  parent  David Nadlinger <code klickverbot.at>  writes:


On Monday, 1 February 2016 at 11:42:54 UTC, Daniel Murphy wrote:

 The process will be complete when you've backported the 
 entirety of 2.068.


 From what I recall, 2.068 was fairly painless to merge anyway 
compared to other releases.

  — David



 Feb 01 2016



prev sibling  parent  Jon D <jond noreply.com>  writes:


On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:

 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


A couple comments:
a) No mention of targeting increased organizational participation 
(academic, corporate, etc). Not trying to suggest it should or 
shouldn't be a goal. Just that if it is goal meaningful effort 
will be directed toward in H1 then it'd be worth including in the 
writeup.

b) More specificity in the roadmap and priorities, to the extent 
they are known - As a potential D adopter, it'd be useful to have 
better insight into where the language might be a year or two 
out. For example, what forms of C++ integration might be 
available, or if the major components of the standard library are 
likely to be available nogc. However, it's hard to discern this 
from the writeup. Perhaps in many cases it would be premature to 
establish such goals, but to the extent there has been concrete 
thought it'd be useful to write it up. This comment is similar to 
a number of others suggesting a preference for more concrete 
goals.

--Jon



 Jan 29 2016