On Thursday, 2 June 2016 at 19:17:39 UTC, bob belcher wrote:
> to #makedlanggreatagain

lol, can I get a shirt of that somewhere?

> The website looks bad. But is very fast.

If you have ideas, PRs are always welcome at https://github.com/dlang/dlang.org

> IDE. mono-d and visual studio. Rest of them are bad

Can you be more specific? The problems are never going to get fixed if they're never reported.

> I would love to help, but, I have no idea how to start, where to go

Well, there's this article for contributing to the site: http://wiki.dlang.org/Contributing_to_dlang.org

and this article for contributing to the language: http://wiki.dlang.org/Starting_as_a_Contributor

> what is the plan.

There's this: https://wiki.dlang.org/Vision/2016H1

But honestly that's just Andrei and Walter basically saying "this would be a good idea if we followed this". There is no plan; D is a very bottom up style developed language with 100% volunteer work. Just submit a PR for whatever you feel like fixing/improving.

On Thursday, 2 June 2016 at 18:14:08 UTC, Jack Stouffer wrote:
> On Thursday, 2 June 2016 at 15:40:28 UTC, Seb wrote:
>>I heard this a lot too.
>> "You don't have a web server in your standard libary?? It's 2016!"
>
> Just to be clear, it's not a good idea to have a full blown server in your stdlib. Non-toy web servers are complicated pieces of software involving > 10KLOC.

Agreed, but a toy web server please. Python has one and it is useful.

On 2016-06-02 20:14, Jack Stouffer wrote:

> Just to be clear, it's not a good idea to have a full blown server in
> your stdlib. Non-toy web servers are complicated pieces of software
> involving > 10KLOC. Not only that, but there are many ways to skin a cat
> in this field. Different products need varying, sometimes mutually
> exclusive, features from their servers.
>
> Therefore, I don't web servers are good candidates for standardization.

Don't you have that issue with most stuff. Not everything can fit everyone's need. I have never used std.bigint but it still present in Phobos because it's useful from someone.

I agree with the complexity of web servers but they don't need to handle all the gory details off clients not following the protocol. I would think it works perfectly fine for non-public facing servers. For public facing servers it should sit behind a well test well understood implementation like Apache or nginx, regardless if the implementation is in Go, Node.js or D.

-- 
/Jacob Carlborg

On Thursday, 2 June 2016 at 21:01:53 UTC, Jacob Carlborg wrote:
> Don't you have that issue with most stuff. Not everything can fit everyone's need.

Sure, it's a sliding scale. But, web servers, even ones that sit behind Apache or Nginx, are specialized much more than what we currently have in Phobos.

It would make more sense from a maintenance standpoint to have a toy server, but I don't see the utility of including one in Phobos over just having it in dub.

The largest blocking point to me is the community attitude. D constantly wants to 'rule them all' instead of integrating with other language ecosystems. This only recently started to change, but only towards C/C++ and not in the other direction, which is dynamic languages. PyD is only barely alive, and nobody seems to be interested to take it to the next level—of making it easy to distribute the created packages.

I'm speaking here from a researcher's perspective. One must realize that in our universe, there is often no time to learn yet another language, so people consolidate around Python so that everyone stays productive, and this situation will not change until someone rolls out a complete replacement for numpy, scipy, pandas, and scikit-learn at the very least. (and that won't happen any time soon) A fancy custom Jupyter kernel is nice but often half-baked and not really necessary. But solving distribution of shared libraries is a must if you (still) want to become a C++ replacement.

To me it seems that D currently has a unique advantage of being able to easily generate in compile time all the boilerplate binding code that everybody hates to write in C++ (or if one uses boost::python, hates to wait to compile). Combine that with the fact that many are terrified of C/C++ insomuch that Cython was invented, and D offers a much nicer language with GC for those who don't want to even know about memory management. Research people would love this, but only if it's a production-ready solution that needs no extra time investment.

On Saturday, 4 June 2016 at 13:18:02 UTC, Artem Tarasov wrote:
> The largest blocking point to me is the community attitude. D constantly wants to 'rule them all' instead of integrating with other language ecosystems. This only recently started to change, but only towards C/C++ and not in the other direction, which is dynamic languages. PyD is only barely alive, and nobody seems to be interested to take it to the next level—of making it easy to distribute the created packages.

Fair point :/

> I'm speaking here from a researcher's perspective. One must realize that in our universe, there is often no time to learn yet another language, so people consolidate around Python so that everyone stays productive, and this situation will not change until someone rolls out a complete replacement for numpy, scipy, pandas, and scikit-learn at the very least. (and that won't happen any time soon)

We are working on it - see mir.dlang.io
The more people help, the faster it will happen!

On Saturday, 4 June 2016 at 13:18:02 UTC, Artem Tarasov wrote:

> which is dynamic languages. PyD is only barely alive, and nobody seems to be interested to take it to the next level—of making it easy to distribute the created packages.

D integrates quite easily with R. I speak from experience, regularly using the two together. You can embed R inside your D program and pass data trivially between them. The technical side is not an issue. Distribution is not an issue - it is the same as any D program calling into a C library. All the other stuff (support for three OSes, documentation, etc.) takes a lot of time and is no fun.

> Research people would love this, but only if it's a production-ready solution that needs no extra time investment.

Yep. And if nobody wants to do the work, it will never happen. I originally did it as a fun way to pass the time while waiting for my son at his many events. I may have been the only one in the world with that particular set of circumstances though. You'll probably be waiting a long time for that production-ready solution that needs no extra time investment.

On Sat, Jun 4, 2016 at 5:56 PM, bachmeier via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>
> D integrates quite easily with R. I speak from experience, regularly using the two together. You can embed R inside your D program and pass data trivially between them. The technical side is not an issue. Distribution is not an issue - it is the same as any D program calling into a C library. All the other stuff (support for three OSes, documentation, etc.) takes a lot of time and is no fun.


Embedding is easy indeed, and it is rather fun (also speaking from experience), but it again shifts the focus towards D, while most people would like to call D from R, and that's where things start to go awry, especially once you start to think about all the complicacies of cross-platform/multithreaded/GC-reliant extensions, possibly several loaded at the same time. That requires quite a bit of enthusiasm that I admittedly no longer have.

On Saturday, 4 June 2016 at 16:36:18 UTC, Artem Tarasov wrote:
> Embedding is easy indeed, and it is rather fun (also speaking from experience), but it again shifts the focus towards D, while most people would like to call D from R, and that's where things start to go awry, especially once you start to think about all the complicacies of cross-platform/multithreaded/GC-reliant extensions, possibly several loaded at the same time. That requires quite a bit of enthusiasm that I admittedly no longer have.

I've also gone in the other direction, basically Rcpp with D. Until there is actually interest though (beyond "show me which button to push so I can use it for my research") it's still not going to happen.

On Saturday, 4 June 2016 at 13:18:02 UTC, Artem Tarasov wrote:
> The largest blocking point to me is the community attitude. D constantly wants to 'rule them all' instead of integrating with other language ecosystems. This only recently started to change, but only towards C/C++ and not in the other direction, which is dynamic languages.

PyD is not a recent project.  Nor is LuaD.  Or bachmeier's work on R integration.

> PyD is only barely alive
Really?  You have submitted pull requests and nobody has looked at them ?  Seemed alive enough to me when I looked a few months back.  It's normal activity diminishes as a project reaches maturity.  What is it you think PyD should do that it doesn't today, and what was the response when you raised it with the maintainer ?  Was it just about distribution of packages?
>
> I'm speaking here from a researcher's perspective. One must realize that in our universe, there is often no time to learn yet another language, so people consolidate around Python so that everyone stays productive, and this situation will not change until someone rolls out a complete replacement for numpy, scipy, pandas, and scikit-learn at the very least.


Adoption doesn't work like that.  If nobody ever switched until the next thing was perfect, nobody would ever switch.  What happens is something new gets adopted in certain niches by people who really like what it has to offer and don't mind the rest and who have the power to do so.  Then as it starts to be adopted in some niches, it spreads to adjacent niches.

If you would like to help with dlangscience I am sure John Colvin and colleagues would appreciate the manpower or support in other ways.  If you're not in a position to help, then I understand that, but grumbling won't change much because open source projects are constrained by the supply of able people willing to roll up their sleeves and help.

 (and
> that won't happen any time soon) A fancy custom Jupyter kernel is nice but often half-baked and not really necessary. But solving distribution of shared libraries is a must if you (still) want to become a C++ replacement.

What a great opportunity to give something back!  Why not sketch out a vision for what this should look like, as John has done with dlangscience.


To me it seems that D currently has a unique advantage of being
> able to easily generate in compile time all the boilerplate binding code that everybody hates to write in C++ (or if one uses boost::python, hates to wait to compile). Combine that with the fact that many are terrified of C/C++ insomuch that Cython was invented, and D offers a much nicer language with GC for those who don't want to even know about memory management. Research people would love this, but only if it's a production-ready solution that needs no extra time investment.

Yes it has a unique advantage.  But it isn't realistic to expect others to do the work for you at this stage in the development of the ecosystem...