www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Blocking points for further D adoption

reply Seb <seb wilzba.ch> writes:
I don't see it the same way. Yes, I agree my opinion is not 
representative. I'd also say I'm glad I can do something about 
this.
Moved Andrei's post (http://forum.dlang.org/post/nipb14$ldb$1 digitalmars.com) to a new thread.
 [...]
 Meanwhile, I go to conferences. Train and consult at large 
 companies.
 Dozens every year, cumulatively thousands of people. I talk 
 about D
 and ask people what it would take for them to use the 
 language.
 Invariably I hear a surprisingly small number of reasons:
 [..]
 * Tooling is immature and of poorer quality compared to the
 competition.
And what have we done about it? How long has it been since dfix existed, yet we still haven't really integrated it into the dmd toolchain?
I've spoken to Brian about it. Dfix does not do lookup, which makes it sadly not up for meaningful uses.
How about we start calling dfix and dscanner "official", move them over to the Dlang github namespace and ship them with every release?
 * Hiring people who know D is a problem.
There are many willing candidates right here. :-P
Nice.
We should start to list companies that use D - that solves the chicken vs. egg problem too: https://github.com/dlang/dlang.org/pull/1312
 * Documentation and tutorials are weak.
And what have we done about this?
http://tour.dlang.org is a good start.
Yes it is good step, but we need to improve this and create more! Having a MOOC (usually >50K viewers!) would be the best way to move forward.
 * There's no web services framework (by this time many folks 
 know of
 D, but of those a shockingly small fraction has even heard of 
 vibe.d).
 I have strongly argued with Sönke to bundle vibe.d with dmd 
 over one
 year ago, and also in this forum. There wasn't enough 
 interest.
I heard this a lot too. "You don't have a web server in your standard libary?? It's 2016!" We should close the gap to NodeJS, Go (and all the other languages) ASAP and standardize the API for the following: 1) event loop library (e.g. https://github.com/etcimon/libasync) 2) bare-metal http server with full HTTP2 support (e.g. https://github.com/etcimon/libhttp2) NodeJS provides such a low-level API and this has been a key part of their success, because so many libraries built on-top of this without breaking each other. https://nodejs.org/api/http.html
 What about linking to it in a prominent place on dlang.org?  
 This isn't
 a big problem, AFAICT.  I don't think it takes months and 
 years to put
 up a big prominent banner promoting vibe.d on, say, the 
 download page of
 dlang.org.
PR please. I can't babysit everything. I'm preparing for a conference where I'll evangelize for D next week (http://ndcoslo.com/speaker/andrei-alexandrescu/). As I mentioned at DConf, for better or worse this is the kind of stuff I cannot delegate.
That could help, but it's needs more work: https://github.com/dlang/dlang.org/pull/1314
Jun 02 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/02/2016 11:40 AM, Seb wrote:
 How about we start calling dfix and dscanner "official", move them over
 to the Dlang github namespace and ship them with every release?
From my email dated 2015/05/31 entitled "Make dformat and dfix part of the dmd distribution":
 Hi Brian,


 I was very pleased at DConf to see that your toolset has nicely
 reached maturity.

 The logical next step is to make your tools part of the dmd
 distribution. I'm thinking making dformat and dfix trivially easy to
 use and of great help to folks.

 What do you think? Could you work on that? Any blockers you could
 see?

 I'm thinking getting this done for 2.068.


 Thanks,

 Andrei
I have followed that with several attempts to push things forward with dfix, last on 2016/03/03, with various major contributors. There was no blocker, but also no finalization. We have made tools "official" in the past. Some we've put in our github (e.g. VisualD). As far as I can tell that did nothing to accelerate work on them. But I'd be hasty to generalize from that and would be willing to try it again. Andrei
Jun 02 2016
parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 2 June 2016 at 16:18:45 UTC, Andrei Alexandrescu 
wrote:
 We have made tools "official" in the past. Some we've put in 
 our github (e.g. VisualD). As far as I can tell that did 
 nothing to accelerate work on them. But I'd be hasty to 
 generalize from that and would be willing to try it again.
Maybe development won't accelerate, but if you bundled dfmt/dscanner with the dmd zip downloads, I'd be willing to bet money that they'd get a huge boost in usage.
Jun 02 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/02/2016 02:18 PM, Jack Stouffer wrote:
 On Thursday, 2 June 2016 at 16:18:45 UTC, Andrei Alexandrescu wrote:
 We have made tools "official" in the past. Some we've put in our
 github (e.g. VisualD). As far as I can tell that did nothing to
 accelerate work on them. But I'd be hasty to generalize from that and
 would be willing to try it again.
Maybe development won't accelerate, but if you bundled dfmt/dscanner with the dmd zip downloads, I'd be willing to bet money that they'd get a huge boost in usage.
I'd be willing to experiment with that. -- Andrei
Jun 02 2016
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 02-Jun-2016 18:40, Seb wrote:
 I don't see it the same way. Yes, I agree my opinion is not
 representative. I'd also say I'm glad I can do something about this.
Moved Andrei's post (http://forum.dlang.org/post/nipb14$ldb$1 digitalmars.com) to a new thread.
Biggest issue w.r.t. "Blocking points for further adoption" is doesn't solve any of "my" problems. That is problems of potential user. Then it turns out that language per se is rarely a problem (barring some older ones) but rather the platform or the ecosystem. It's a rare thing to have a user that wants to build something new in the vacuum (where D actually shines) using X times less code with the resulting speed of C++. In contrast a typical app is 95% frameworks/libraries haphazardly glued together in an MVP or demo that would then become a product eventually. Compare to the extreme example - Go. A pedestrian (IMHO) language that however built an attractive platform for web-services. Nobody goes to Go (pun) because of language features, but they do for hype (ad populum), builtin goroutines with scheduler and standard http library. All the hard work Go team done on the GC also payed off. TL; DR : The platform is the key. -- Dmitry Olshansky
Jun 02 2016
prev sibling next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
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. 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.
 We should close the gap to NodeJS Go (and all the other 
 languages) ASAP and standardize the API for the following:

 1) event loop library (e.g. https://github.com/etcimon/libasync)
 2) bare-metal http server with full HTTP2 support (e.g. 
 https://github.com/etcimon/libhttp2)
A low level HTTP library, sure. Event loop libraries however, have the same problems with servers, i.e. a wide variety possible solutions with no clear "always use this method".
Jun 02 2016
next sibling parent dewitt <dkdewitt gmail.com> writes:
On Thursday, 2 June 2016 at 18:14:08 UTC, Jack Stouffer wrote:
 A low level HTTP library, sure. Event loop libraries however, 
 have the same problems with servers, i.e. a wide variety 
 possible solutions with no clear "always use this method".
I like Python's HTTP and URL libraries and use them quite often.
Jun 02 2016
prev sibling next sibling parent qznc <qznc web.de> writes:
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.
Jun 02 2016
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Jun 02 2016
parent reply Jack Stouffer <jack jackstouffer.com> writes:
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.
Jun 02 2016
parent reply Artem Tarasov via Digitalmars-d <digitalmars-d puremagic.com> writes:
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=E2=80=94of 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.
Jun 04 2016
next sibling parent Seb <seb wilzba.ch> writes:
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!
Jun 04 2016
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
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.
Jun 04 2016
parent reply Artem Tarasov via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Jun 04 2016
parent bachmeier <no spam.net> writes:
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.
Jun 04 2016
prev sibling parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
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...
Jun 05 2016
parent reply Artem Tarasov via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, Jun 5, 2016 at 9:35 AM, Laeeth Isharc via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 PyD is not a recent project.  Nor is LuaD.  Or bachmeier's work on R
 integration.
I've learned about the last one only from this thread, and the first two are listed only on http://wiki.dlang.org/Scripting_Libraries, thus I draw the conclusion that's how they are used most often.
 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.
You are right in that it's well maintained. I say 'barely' because for such kind of project I'd expect to see at least one user per each platform (Linux/OS X/Win), and I couldn't find that many. I ran a global search 'pyd std.range' on Github to get an idea of usage, and the outcome was rather disappointing for a mature project. I'm not a Win user so I can't help on this one.
 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.
I'm afraid vision is also not going to help a lot, but here you go: - LDC starts to provide libphobos2.a compiled with -fPIC - PyD: 1) Links druntime dynamically and Phobos statically (with -Bsymbolic to avoid symbol clashes between different Phobos versions) 2) Prepares a tiny libdruntime.so wrapper as a Python package, such that 'import druntime' in Python code initializes D runtime; all PyD packages start to use this import. 3) Someone should help to sort out multithreading-related gotchas, if any crop up - D Language Foundation registers an official account on PyPI and publishes the aforementioned package - Finally, someone makes a useful PyD-based extension, publishes it, makes sure his colleagues can use it with a single `pip install`, and puts a link to reddit/hackernews
 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...
Well, it's not for me, I'm mostly out already, back to C++14/Python, after careful weighing of offerings w.r.t. infrastructure/pain of coding. The ideal people for these kind of tasks are students, imho. I've read on this forum about some magic place where D is being taught at a university, that's where I'd try to get an influx from.
Jun 05 2016
parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Sunday, 5 June 2016 at 09:54:53 UTC, Artem Tarasov wrote:
 I've learned about the last one only from this thread, and the 
 first two are listed only on http://wiki.dlang.org/
 Scripting_Libraries, thus I draw the conclusion that's how they 
 are used most often.
One area where I do agree with you is that D hides it's light under a bushel. Unless one is willing to look for them, there are many hidden gems that aren't easy to learn about from the front page (or the obvious links off that). So I do think the idea of creating some channels per typical use case would be a good one. I would help with that, but I simply have no time for now, though it might change in a few months. Possibly it's something the D Foundation could look at once it's fully up and running. Wrt PyD usage, not every project happens on GitHub in public, and it may well be the case that commercial users don't open-source code that uses PyD. I use it a little and haven't put stuff up on github for that for the time being. But the functionality is there - took a quick look just recently for another reason, and last commit was no more than 4 days ago. Code base could be cleaned up a little, as could the docs, but it works and I think the cleanup will happen at some point. For OS X, not sure if the shared library problem is relevant (I don't use a Mac), but I know that John uses a Mac, so I expect it works with dmd. Have you seen any problems with multithreading in PyD? Ie have you any reasons to be concerned? Obviously on the python side there is the GIL, but I don't understand well enough any complications posed by using shared libraries for threading - I am not aware of any problems with PyD and threads though. Re tiny druntime, that might suit you, but I think many people would prefer that it's one simple import and, after all, you are not actually using it. Probably Benjamin Thaut or others will know the real resource cost of initializing D runtime on multiple occasions (I presume it won't crash, but haven't tried, and I imagine the cost is small if any). Your point 1 sounds like a minor change rather than something existential. I'll ask John Colvin.
 Well, it's not for me, I'm mostly out already, back to
 C++14/Python, after careful weighing of offerings w.r.t.
 infrastructure /pain of coding.
Well, fair enough. Knuth welcomed the proliferation of languages because language reflects thought and people think differently. A language like D at this stage shouldn't try to cater to everyone, because that's a recipe for spreading oneself too thin. As Walter says, it is much better to cater to those who already love the language and use it, and want to do more with it.
 The ideal people for these kind of tasks are students, imho.
I think the whole point about D is that it is very helpful for many purposes, and these can't be usefully captured by a single abstract domain description. For what it's worth, I am using it at the other extreme, for the alternative investment management business. And it's already used by a $20bn fund for absolutely critical functions, so I am not sure that one can describe D as a language suited mostly to the educational sphere, though I am sure it is useful there too. It suits how I personally think, fits the problem domain well, and the main costs are wrapping/porting libraries, and that is a one-off cost that can be amortised over a larger project (set off against quite substantial gains due to D's benefits).
 I've read on this forum about some magic place where D is being
taught at a university, that's where I'd try to get an influx
 from.
Seems to me that looking at metrics of growth there is hardly a need to try to get an influx, and that also doesn't fit the model of how D has developed - much more organically, where people address their own pain, and by doing so open up the language for broader use (just like with bachmeier's work on D<->R. dconf was 140+ people this year, and 40 in prior years. daily downloads went from 200 odd in 2013 to 1300 odd lately. compound growth is quite powerful. Sorry to hear it doesn't fit what you want to do right now. Maybe it just isn't for you. Or maybe you need more things to be developed first and you should check back in a year. But if one isn't making some people unhappy one is trying to be all things to all people, and that's not a recipe for success either. Given finite resources and no ability to tell people what to do, I doubt the language would be in a better place if people had worked on what you wished they had worked on rather than what they did work on.
Jun 05 2016
parent Artem Tarasov via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, Jun 5, 2016 at 7:59 PM, Laeeth Isharc via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 Have you seen any problems with multithreading in PyD?  Ie have you any
 reasons to be concerned?  Obviously on the python
 side there is the GIL, but I don't understand well enough any
 complications posed by using shared libraries for threading -
 I am not aware of any problems with PyD and threads though.
It applies to shared libraries in general. I do get a segfault on exit when trying to use std.parallelism in a shared library (linked dynamically with druntime/phobos), which seems to be in accordance with Martin Nowak's comments here: https://github.com/dlang/druntime/pull/593 Re tiny druntime, that might suit you, but I think many people would prefer
 that it's one simple import and, after all, you are not actually using it.
 Probably Benjamin Thaut or others will know the real resource cost of
 initializing D runtime on multiple occasions (I presume it won't crash, but
 haven't tried, and I imagine the cost is small if any).
It's not about tiny druntime, it's about its clear separation from Phobos so that extensions built with different versions of Phobos can be safely loaded together (there can't be two druntime GC running at the same time).
 Well, fair enough.  Knuth welcomed the proliferation of languages because
 language reflects thought and people think differently.
Now that is deep! In reality, though, most programming languages nowadays are object-oriented with decent support for functional programming. It's libraries and tooling that matter the most. E.g. nobody would give a damn about Ruby nowadays if not for RoR. Or consider JS: it's the language of the web, but it wasn't at all designed for its current usage, and workarounds that are used are just mind-blowing.
 Seems to me that looking at metrics of growth there is hardly a need to
 try to get an influx, and that also doesn't fit the
 model of how D has developed - much more organically, where people address
 their own pain, and by doing so open up the language
 for broader use (just like with bachmeier's work on D<->R.
These metrics show growing interest, but this interest apparently comes mostly from busy people, who often address 'their own pain' with undocumented/unorganized code which never makes it to d.announce. Students, on the other hand, are interested also in proper documentation and testing.
Jun 05 2016
prev sibling parent reply qznc <qznc web.de> writes:
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. 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.
Here is one argument to have a (minimalistic) web server in Phobos: Testing. You don't want to require internet access for testing. You don't want the (heavy) vibed dependency just for the unittests. Specific use case: https://github.com/ikod/dlang-requests/issues/11#issuecomment-229354711
Jun 29 2016
parent reply dalailambda <rubenslabbert gmail.com> writes:
As someone who has recently chosen D for a major project (a 
game/engine), I can confidently say that the biggest distinction 
for me between getting start with D versus something like Go is 
developer tooling. For Go I installed Go, installed a go intellij 
plugin, which automatically installed gocode and I was up and 
running. For D I had to install DMD (and learn about all the 
different compilers)[0], install dub, install workspace-d, 
install visual studio code (because the visual studio plugin had 
a linking error), and then I could finally have a complete setup.

I think if dub were distributed with DMD, along with a utility to 
install global programs (that way a D plugin can just call `dub 
install workspace-d` or similar), it would make it very easy to 
get started with D.

For reference, Cargo (Rust's package manager) allows `cargo 
install` 
https://github.com/rust-lang/rfcs/blob/master/text/1200-cargo-install.md

[0] As much as the "reference compiler vs faster compiler" 
distinction, I feel like languages that have a single official 
compiler that you can use for development and production (e.g. 
Go/Rust) are much friendlier.
Jun 30 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 30 June 2016 at 22:48:44 UTC, dalailambda wrote:

 I think if dub were distributed with DMD, along with a utility 
 to install global programs (that way a D plugin can just call 
 `dub install workspace-d` or similar), it would make it very 
 easy to get started with D.
DUB only recently hit 1.0. Now that it has, it is planned to begin bundling it with DMD.
 [0] As much as the "reference compiler vs faster compiler" 
 distinction, I feel like languages that have a single official 
 compiler that you can use for development and production (e.g. 
 Go/Rust) are much friendlier.
DMD *is* the official compiler. That's what a reference compiler is. The other compilers are there for those who want them and are developed independently of DMD. It's no different from the situation with Java (with the exception that Oracle doesn't link to other compilers on their JDK download page). No one says you *have* to use LDC or GDC for production, or that you can't use DMD. It's just as a recommendation for those who care about squeezing out every last drop of performance.
Jun 30 2016
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 30 June 2016 at 23:48:29 UTC, Mike Parker wrote:
 On Thursday, 30 June 2016 at 22:48:44 UTC, dalailambda wrote:

 I think if dub were distributed with DMD, along with a utility 
 to install global programs (that way a D plugin can just call 
 `dub install workspace-d` or similar), it would make it very 
 easy to get started with D.
DUB only recently hit 1.0. Now that it has, it is planned to begin bundling it with DMD.
Oh, and I forgot to add that DUB is not intended generally intended as a package installer. That said, you've got 'dub fetch package-name' already, which will pull a package down into the cache. If it's an executable, you can then do 'dub run package-name'.
Jun 30 2016
prev sibling parent reply dalailambda <rubenslabbert gmail.com> writes:
On Thursday, 30 June 2016 at 23:48:29 UTC, Mike Parker wrote:
 DMD *is* the official compiler. That's what a reference 
 compiler is. The other compilers are there for those who want 
 them and are developed independently of DMD. It's no different 
 from the situation with Java (with the exception that Oracle 
 doesn't link to other compilers on their JDK download page). No 
 one says you *have* to use LDC or GDC for production, or that 
 you can't use DMD. It's just as a recommendation for those who 
 care about squeezing out every last drop of performance.
Sure, but overwhelmingly the community suggests to use DMD for development for fast compilation speeds and then use LDC/GDC for production. I'm not saying that the law mandates it but the impression I get as a newcommer to the community is that DMD is the ugly stepchild that isn't suitable for real world use case. As an example, look at whenever a benchmark comes up, someone will say "have you tried compiling with LDC?". I feel the is relevant since, as a systems language, performance should be a feature.
Jun 30 2016
parent reply Puming <zhaopuming gmail.com> writes:
On Friday, 1 July 2016 at 00:08:51 UTC, dalailambda wrote:
 On Thursday, 30 June 2016 at 23:48:29 UTC, Mike Parker wrote:
 DMD *is* the official compiler. That's what a reference 
 compiler is. The other compilers are there for those who want 
 them and are developed independently of DMD. It's no different 
 from the situation with Java (with the exception that Oracle 
 doesn't link to other compilers on their JDK download page). 
 No one says you *have* to use LDC or GDC for production, or 
 that you can't use DMD. It's just as a recommendation for 
 those who care about squeezing out every last drop of 
 performance.
Sure, but overwhelmingly the community suggests to use DMD for development for fast compilation speeds and then use LDC/GDC for production. I'm not saying that the law mandates it but the impression I get as a newcommer to the community is that DMD is the ugly stepchild that isn't suitable for real world use case. As an example, look at whenever a benchmark comes up, someone will say "have you tried compiling with LDC?". I feel the is relevant since, as a systems language, performance should be a feature.
It's been suggested that DMD/LDC/GDC could be combined into a bundle, say DCC, and when you call DCC hello.d it will call dmd hello.d, and if you call DCC -fast hello.d it will call ldc hello.d or gdc hello.d This will give newcomers a different experience.
Jul 06 2016
next sibling parent reply Tofu Ninja <joeyemmons yahoo.com> writes:
On Wednesday, 6 July 2016 at 07:10:07 UTC, Puming wrote:
 It's been suggested that DMD/LDC/GDC could be combined into a 
 bundle, say DCC, and when you call

 DCC hello.d

 it will call dmd hello.d,

 and if you call

 DCC -fast hello.d

 it will call ldc hello.d or gdc hello.d

 This will give newcomers a different experience.
Problem with that is ldc and gdc are always a few versions behind dmd.
Jul 06 2016
parent reply qznc <qznc web.de> writes:
On Wednesday, 6 July 2016 at 07:22:26 UTC, Tofu Ninja wrote:
 Problem with that is ldc and gdc are always a few versions 
 behind dmd.
LDC is quite close now. LDC v1.0.0 was released June 6 with DMD 2.070.2 compatibility. DMD 2.070.2 was released Mar 3 and superseded by 2.071.0 on Apr 5 (and 2.071.1 on June 27).
Jul 06 2016
parent Andrew Godfrey <X y.com> writes:
On Wednesday, 6 July 2016 at 07:38:50 UTC, qznc wrote:
 On Wednesday, 6 July 2016 at 07:22:26 UTC, Tofu Ninja wrote:
 Problem with that is ldc and gdc are always a few versions 
 behind dmd.
LDC is quite close now. LDC v1.0.0 was released June 6 with DMD 2.070.2 compatibility. DMD 2.070.2 was released Mar 3 and superseded by 2.071.0 on Apr 5 (and 2.071.1 on June 27).
This is a great point. DMD feels incomplete on its own, and that's a real adoption blocker. The downsides of keeping the LDC and DMD releases in sync seem like a price worth paying. Are the licenses compatible enough to release them as one thing?
Jul 06 2016
prev sibling parent dalailambda <rubenslabbert gmail.com> writes:
 It's been suggested that DMD/LDC/GDC could be combined into a 
 bundle, say DCC, and when you call

 DCC hello.d

 it will call dmd hello.d,

 and if you call

 DCC -fast hello.d

 it will call ldc hello.d or gdc hello.d

 This will give newcomers a different experience.
I'm wondering if you couldn't achieve DMD's compilation speed in LDC by turning off some of the optimisation passes for debug builds. I understand that it will probably still be slower to compile, but if it's a negligible difference, and the community can fully support a single compiler I think that would be really good for D as a whole.
Jul 08 2016
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 2 June 2016 at 15:40:28 UTC, Seb wrote:
 * Documentation and tutorials are weak.
Ugh, I was just looking at the classes section of the Spec and it has a header for alias this, but no header for inheritance.
Jun 02 2016
prev sibling next sibling parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 2 June 2016 at 15:40:28 UTC, Seb wrote:
 How about we start calling dfix and dscanner "official", move 
 them over to the Dlang github namespace and ship them with 
 every release?
Brian's tools are based on libdparse which is not in sync with the official D grammar and semantic. They can't be official. For example libdparse doesn't support some stuff that are deprecated byt still supported by DDMD.
Jun 02 2016
prev sibling next sibling parent reply bob belcher <claudiu.garba gmail.com> writes:
On Thursday, 2 June 2016 at 15:40:28 UTC, Seb wrote:
I don't see it the same way. Yes, I agree my opinion is not 
representative. I'd also say I'm glad I can do something about 
this.
Moved Andrei's post (http://forum.dlang.org/post/nipb14$ldb$1 digitalmars.com) to a new thread.
 [...]
 Meanwhile, I go to conferences. Train and consult at large 
 companies.
 Dozens every year, cumulatively thousands of people. I talk 
 about D
 and ask people what it would take for them to use the 
 language.
 Invariably I hear a surprisingly small number of reasons:
 [..]
 * Tooling is immature and of poorer quality compared to the
 competition.
And what have we done about it? How long has it been since dfix existed, yet we still haven't really integrated it into the dmd toolchain?
I've spoken to Brian about it. Dfix does not do lookup, which makes it sadly not up for meaningful uses.
How about we start calling dfix and dscanner "official", move them over to the Dlang github namespace and ship them with every release?
 * Hiring people who know D is a problem.
There are many willing candidates right here. :-P
Nice.
We should start to list companies that use D - that solves the chicken vs. egg problem too: https://github.com/dlang/dlang.org/pull/1312
 * Documentation and tutorials are weak.
And what have we done about this?
http://tour.dlang.org is a good start.
Yes it is good step, but we need to improve this and create more! Having a MOOC (usually >50K viewers!) would be the best way to move forward.
 * There's no web services framework (by this time many folks 
 know of
 D, but of those a shockingly small fraction has even heard 
 of vibe.d).
 I have strongly argued with Sönke to bundle vibe.d with dmd 
 over one
 year ago, and also in this forum. There wasn't enough 
 interest.
I heard this a lot too. "You don't have a web server in your standard libary?? It's 2016!" We should close the gap to NodeJS, Go (and all the other languages) ASAP and standardize the API for the following: 1) event loop library (e.g. https://github.com/etcimon/libasync) 2) bare-metal http server with full HTTP2 support (e.g. https://github.com/etcimon/libhttp2) NodeJS provides such a low-level API and this has been a key part of their success, because so many libraries built on-top of this without breaking each other. https://nodejs.org/api/http.html
 What about linking to it in a prominent place on dlang.org?  
 This isn't
 a big problem, AFAICT.  I don't think it takes months and 
 years to put
 up a big prominent banner promoting vibe.d on, say, the 
 download page of
 dlang.org.
PR please. I can't babysit everything. I'm preparing for a conference where I'll evangelize for D next week (http://ndcoslo.com/speaker/andrei-alexandrescu/). As I mentioned at DConf, for better or worse this is the kind of stuff I cannot delegate.
That could help, but it's needs more work: https://github.com/dlang/dlang.org/pull/1314
Hello, My first post on dlang. :) to #makedanggreatagain I guess dlang just needs to go where is noise and fish people from there. That place is web and mobile, and games The same as go, adding a html library a tiny sinatra style web framework given the speed of dlang, my bet this will manage to add more people. Even this website is amazing how fast it is. I know is vibe.d. But vibe.d is forever in beta mode. Mobile. This is long and complicated. I read that there some movements in this direction using android, but having in the next few years one lib to build cross platform will be a kill Games. Even here, adding a library to make with work with android or ios. Similar with sprite kit, or cocoa will move more people. tour.dlang.io is a nice beginning. Just a beginning. dfmt tool. In tour.dlang.io is a different style of writting code than what will generate for you. code.dlang. The website looks bad. But is very fast. I do have a domain, grab it last year, http://dlangbyexample.com/. I would like to donate it to dlang foundation and there someone should use https://www.gitbook.com/ and add a really nice website. IDE. mono-d and visual studio. Rest of them are bad I hope this post will not add any kind of rant over the people here. I know you are amazing. I would love to help, but, I have no idea how to start, where to go, what is the plan.
Jun 02 2016
parent Jack Stouffer <jack jackstouffer.com> writes:
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.
Jun 02 2016
prev sibling next sibling parent reply David <dave.dave dave.com> writes:
As someone who recently tried D and dropped it to learn Python I 
can tell you, tooling was not an issue for me. I worked on a 
windows computer (which it seems a lot of this community are 
linux users based on the examples I see in the 
documentation...very *nix type examples) I will say I had dmd + 
codeblocks up and running and a hello world programming printing 
to the console in < 20 minutes.

D's major issue is it doesn't have much of a presence on sites 
like stackoverflow (or at least they don't appear to show up well 
in my google searches) and the documentation google does give me 
links to are poorly done. Two main issues I saw? Broken links and 
poor examples. Also occasionally I get pages that look like a 
different a style from google searches than the main 
documentation pages, which makes me feel one is outdated. I ended 
up actually just going to dlang.org itself to be sure...

But I should probably show some examples, because this post is 
meant to be productive not just critical.

Looking at the std.algorithm module page we get a description of 
functions that...well aren't really descriptions. For instance:

clamp	clamp(1, 3, 6) returns 3. clamp(4, 3, 6) returns 4.

Yeah...that does not explain anything. Definition writing 101 
tells you to never use the word you are trying to define in the 
sentence defining it. In fact, most of the descriptions for the 
functions in std.algorithm should probably come with better 
descriptions. D doesn't offer a lot of return on investment for 
learning it, so you could at least make it easy to learn...

isPermutation	isPermutation([1, 2], [2, 1]) returns true.

^^^ How is that helpful? BTW, I'm getting this from this page:

https://dlang.org/library/std/algorithm/comparison.html

Now, if I click on each function I get a little bit better of an 
explanation (in some cases), but why have a useless description? 
It serves nothing and just distracts. You might as well as not 
have a description column on std.algorithm, and just provide 
links.

The other beef I see, is that examples for functions seem like 
they are just ripped from random unittests and frequently 
reference other standard library calls without context of what 
they are doing.

For example readText:

https://dlang.org/library/std/file/read_text.html

It provides an example of this:

import std.string;
write("someUniqueFilename", "abc\n");
scope(exit)
{
     assert(exists("someUniqueFilename"));
     remove("someUniqueFilename");
}

enforce(chomp(readText("someUniqueFilename")) == "abc");

So reading it, it looks like we crate a file with "abc" in it, 
then do some scope(exit) thingy, then assert the file exists, 
then remove it? Odd...

Then we move down and it looks like "after" we delete it we read 
the file using "readText" and make sure it's contents are equal 
to what we wrote to the file? So first thing I had to do is look 
up what the hell scope(exit) was doing and found that it gets 
called when the scope gets killed not inline where it was. Ok 
fine. That sounds useful. So by the time we get to the readText 
line we still have a file. But what the hell is chomp? Do I need 
chomp to use readText? Turns out...no...I read a file literally 
by doing auto text = readText(fileName). So yeah...

To understand this example I had to a lot more work than I should 
of had to just understand how to use readText correctly, and it 
turns out I didn't need to do 90% of the code for my purposes, 
which means the rest is really more of just a distraction. Sure, 
I learned what scope(exit) does and what chomp did, but I didn't 
need them.
Jun 05 2016
next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 06/05/2016 02:58 PM, David wrote:
 D's major issue is it doesn't have much of a presence on sites like
 stackoverflow (or at least they don't appear to show up well in my
 google searches) and the documentation google does give me links to are
 poorly done. Two main issues I saw? Broken links and poor examples. Also
 occasionally I get pages that look like a different a style from google
 searches than the main documentation pages, which makes me feel one is
 outdated. I ended up actually just going to dlang.org itself to be sure...
The different style pages are most probably dlang.org/phobos/ pages and dlang.org/library/ pages. They are built from the same source, so they should contain the same information. Neither of them should be outdated. We're actively working on bringing the new style (/library/) up to speed. If you've hit broken links recently (in the last few days), it would help us if you could point them out. [...]
 clamp    clamp(1, 3, 6) returns 3. clamp(4, 3, 6) returns 4.

 Yeah...that does not explain anything. Definition writing 101 tells you
 to never use the word you are trying to define in the sentence defining
 it. In fact, most of the descriptions for the functions in std.algorithm
 should probably come with better descriptions. D doesn't offer a lot of
 return on investment for learning it, so you could at least make it easy
 to learn...

 isPermutation    isPermutation([1, 2], [2, 1]) returns true.

 ^^^ How is that helpful? BTW, I'm getting this from this page:

 https://dlang.org/library/std/algorithm/comparison.html

 Now, if I click on each function I get a little bit better of an
 explanation (in some cases), but why have a useless description? It
 serves nothing and just distracts. You might as well as not have a
 description column on std.algorithm, and just provide links.
Interesting. We've been thinking about this exact thing lately [1]. So from your fresh experience, the "Cheat Sheet" is not very helpful. If you scroll down on that documentation page you get to another table under the heading "Functions". It looks very similar to the cheat sheet, but the descriptions are different. (Having two almost identical tables like that is the problem we're trying to fix.) Would you consider the description in the "Functions" table more helpful than the ones in the "Cheat Sheet"? [1] http://forum.dlang.org/post/niv2hc$2l7k$1 digitalmars.com
Jun 05 2016
next sibling parent reply David <dave.dave dave.com> writes:
On Sunday, 5 June 2016 at 13:35:18 UTC, ag0aep6g wrote:
 On 06/05/2016 02:58 PM, David wrote:
 [...]
The different style pages are most probably dlang.org/phobos/ pages and dlang.org/library/ pages. They are built from the same source, so they should contain the same information. Neither of them should be outdated. We're actively working on bringing the new style (/library/) up to speed. If you've hit broken links recently (in the last few days), it would help us if you could point them out. [...]
 [...]
Interesting. We've been thinking about this exact thing lately [1]. So from your fresh experience, the "Cheat Sheet" is not very helpful. If you scroll down on that documentation page you get to another table under the heading "Functions". It looks very similar to the cheat sheet, but the descriptions are different. (Having two almost identical tables like that is the problem we're trying to fix.) Would you consider the description in the "Functions" table more helpful than the ones in the "Cheat Sheet"? [1] http://forum.dlang.org/post/niv2hc$2l7k$1 digitalmars.com
Yes those descriptions below are much better. I guess I glossed over them. I focused too much on the cheat sheet, because I assumed the cheat sheet was the quick link to function main pages (which seems to be the case). Perhaps this is a case where 'more' isn't better? I'm not quite sure what the cheat sheet really is providing... I mean if it was an example of common uses of the function that would be one thing. But I guess I'm not sure what information one is supposed to get from the 'cheat' sheet.
Jun 05 2016
parent reply ag0aep6g <anonymous example.com> writes:
On 06/05/2016 03:52 PM, David wrote:
 Yes those descriptions below are much better. I guess I glossed over
 them. I focused too much on the cheat sheet, because I assumed the cheat
 sheet was the quick link to function main pages (which seems to be the
 case). Perhaps this is a case where 'more' isn't better? I'm not quite
 sure what the cheat sheet really is providing...
The cheat sheet comes from the older style documentation which has all functions on one page and no generated listing of them. The cheat sheet provides a quick overview there, so that you don't have to scroll so much to find something. For example, see the same page in the older style: https://dlang.org/phobos/std_algorithm_comparison.html In the newer style documentation, the cheat sheets don't really make sense. We're in the process of figuring out what to do about it.
 I mean if it was an example of common uses of the function that would be
 one thing. But I guess I'm not sure what information one is supposed to
 get from the 'cheat' sheet.
Maybe it's just a case of bad documentation. Do you think that all descriptions in the the cheat sheet are bad, or are some acceptable? For example, `either`'s description is this: Return first parameter p that passes an if (p) test, e.g. either(0, 42, 43) returns 42. Is that good/bad/acceptable?
Jun 05 2016
parent reply David <dave.dave dave.com> writes:
On Sunday, 5 June 2016 at 14:12:53 UTC, ag0aep6g wrote:
 Maybe it's just a case of bad documentation. Do you think that 
 all descriptions in the the cheat sheet are bad, or are some 
 acceptable?
For the one I referenced for std.algorithm, I'd say pretty much all of the descriptions in the cheat sheet were essentially useless to me. The best description was among Checks if a value is among a set of values, e.g. if (v.among(1, 2, 3)) // v is 1, 2 or 3 Which I guess is better than the rest, but to be honest the description pretty much confirmed what I had guessed by the name. So they range from "just barely passing" to "useless" to be a little brutally honest about it. To be honest I guessed based off the description that among would return a bool, but it doesn't. It returns an uint, which brings up more questions...
Jun 05 2016
parent reply David <dave.dave dave.com> writes:
On Sunday, 5 June 2016 at 14:51:27 UTC, David wrote:
 On Sunday, 5 June 2016 at 14:12:53 UTC, ag0aep6g wrote:
 [...]
For the one I referenced for std.algorithm, I'd say pretty much all of the descriptions in the cheat sheet were essentially useless to me. The best description was among Checks if a value is among a set of values, e.g. if (v.among(1, 2, 3)) // v is 1, 2 or 3 Which I guess is better than the rest, but to be honest the description pretty much confirmed what I had guessed by the name. So they range from "just barely passing" to "useless" to be a little brutally honest about it. To be honest I guessed based off the description that among would return a bool, but it doesn't. It returns an uint, which brings up more questions...
Btw, all of my questions are fully answered with the bit below the cheat, meaning, I think the cheat sheets are just useless at this point.
Jun 05 2016
parent reply David <dave.dave dave.com> writes:
On Sunday, 5 June 2016 at 15:04:15 UTC, David wrote:
 On Sunday, 5 June 2016 at 14:51:27 UTC, David wrote:
 [...]
Btw, all of my questions are fully answered with the bit below the cheat, meaning, I think the cheat sheets are just useless at this point.
Also an FYI, every module in std.algorithm's documentation have the same documentation link broken.
Jun 05 2016
parent reply ag0aep6g <anonymous example.com> writes:
On 06/05/2016 05:08 PM, David wrote:
 Also an FYI, every module in std.algorithm's documentation have the same
 documentation link broken.
The one on the top to std.algorithm, right? Those should be fixed in the prerelease version, e.g. on <https://dlang.org/library-prerelease/std/algorithm/comparison.html> it works.
Jun 05 2016
parent reply David <dave.dave dave.com> writes:
On Sunday, 5 June 2016 at 15:13:26 UTC, ag0aep6g wrote:
 On 06/05/2016 05:08 PM, David wrote:
 Also an FYI, every module in std.algorithm's documentation 
 have the same
 documentation link broken.
The one on the top to std.algorithm, right? Those should be fixed in the prerelease version, e.g. on <https://dlang.org/library-prerelease/std/algorithm/comparison.html> it works.
And... https://dlang.org/library/std/algorithm/searching.html https://dlang.org/library/std/algorithm/iteration.html https://dlang.org/library/std/algorithm/mutation.html ...etc I don't know how you have your website setup. But all of these have the same broken link under the std.algorithm tree.
Jun 05 2016
parent ag0aep6g <anonymous example.com> writes:
On 06/05/2016 05:20 PM, David wrote:
 On Sunday, 5 June 2016 at 15:13:26 UTC, ag0aep6g wrote:
 On 06/05/2016 05:08 PM, David wrote:
 Also an FYI, every module in std.algorithm's documentation have the same
 documentation link broken.
The one on the top to std.algorithm, right? Those should be fixed in the prerelease version, e.g. on <https://dlang.org/library-prerelease/std/algorithm/comparison.html> it works.
And... https://dlang.org/library/std/algorithm/searching.html https://dlang.org/library/std/algorithm/iteration.html https://dlang.org/library/std/algorithm/mutation.html ...etc I don't know how you have your website setup. But all of these have the same broken link under the std.algorithm tree.
Yeah, notice the difference in the URLs: .../library/... vs .../library-prerelease/... The latter is the upcoming version. That means the problem has been fixed in the code, but it's going to take until the next release for the fix to reach the stable documentation.
Jun 05 2016
prev sibling next sibling parent reply David <dave.dave dave.com> writes:
On Sunday, 5 June 2016 at 13:35:18 UTC, ag0aep6g wrote:
 On 06/05/2016 02:58 PM, David wrote:
 [...]
The different style pages are most probably dlang.org/phobos/ pages and dlang.org/library/ pages. They are built from the same source, so they should contain the same information. Neither of them should be outdated. [...]
I encountered quite a few broken links. One I recall was the std.container link at the top of this page: https://dlang.org/library/std/container/array.html I don't remember the rest.
Jun 05 2016
next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Sunday, 5 June 2016 at 13:56:55 UTC, David wrote:
 On Sunday, 5 June 2016 at 13:35:18 UTC, ag0aep6g wrote:
 On 06/05/2016 02:58 PM, David wrote:
 [...]
The different style pages are most probably dlang.org/phobos/ pages and dlang.org/library/ pages. They are built from the same source, so they should contain the same information. Neither of them should be outdated. [...]
I encountered quite a few broken links. One I recall was the std.container link at the top of this page: https://dlang.org/library/std/container/array.html I don't remember the rest.
Fixed in master: https://dlang.org/library-prerelease/std/container/array.html
Jun 05 2016
parent ag0aep6g <anonymous example.com> writes:
On 06/05/2016 04:14 PM, Vladimir Panteleev wrote:
 Fixed in master:

 https://dlang.org/library-prerelease/std/container/array.html
Heh. I've been starting to question my sanity.
Jun 05 2016
prev sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Sunday, 5 June 2016 at 13:56:55 UTC, David wrote:

 I encountered quite a few broken links.
The links in the library menu under core->stdcpp are 404 in /phobos (the corresponding links in /library just point to empty pages). I am not sure how to fix these.
Jun 05 2016
parent reply ag0aep6g <anonymous example.com> writes:
On 06/06/2016 12:05 AM, Bastiaan Veelo wrote:
 The links in the library menu under core->stdcpp are 404 in /phobos (the
 corresponding links in /library just point to empty pages).

 I am not sure how to fix these.
Works in /phobos-prerelease and /library-prerelease.
Jun 06 2016
parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Monday, 6 June 2016 at 18:49:21 UTC, ag0aep6g wrote:
 Works in /phobos-prerelease and /library-prerelease.
Thanks.
Jun 06 2016
prev sibling parent David <dave.dave dave.com> writes:
On Sunday, 5 June 2016 at 13:35:18 UTC, ag0aep6g wrote:
 On 06/05/2016 02:58 PM, David wrote:
 [...]
The different style pages are most probably dlang.org/phobos/ pages and dlang.org/library/ pages. They are built from the same source, so they should contain the same information. Neither of them should be outdated. [...]
FYI, I think I encountered a broken link on most of the pages I visited.
Jun 05 2016
prev sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Sunday, 5 June 2016 at 12:58:56 UTC, David wrote:
 D doesn't offer a lot of return on investment for learning it,
That sort of sets the tone for the rest of your post, doesn't it...
 ^^^ How is that helpful?
Replied to this on GitHub: https://github.com/dlang/phobos/pull/4397#issuecomment-223813719
 The other beef I see, is that examples for functions seem like 
 they are just ripped from random unittests and frequently 
 reference other standard library calls without context of what 
 they are doing.
Yes, many examples are actually unit tests, to verify that the displayed examples actually work. Most examples are written in the style that the result of the documented function is `assert`ed or `enforce`d to be correct, which may be unusual at first. The chomp call does seem unnecessary in that example, though.
Jun 05 2016
next sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Sunday, 5 June 2016 at 14:20:36 UTC, Vladimir Panteleev wrote:
 The chomp call does seem unnecessary in that example, though.
https://github.com/dlang/phobos/pull/4408 BTW, thanks for the feedback. It is appreciated even if I disagreed with some of it.
Jun 05 2016
prev sibling parent David <dave.dave dave.com> writes:
On Sunday, 5 June 2016 at 14:20:36 UTC, Vladimir Panteleev wrote:
 On Sunday, 5 June 2016 at 12:58:56 UTC, David wrote:
 D doesn't offer a lot of return on investment for learning it,
That sort of sets the tone for the rest of your post, doesn't it...
Maybe. I mean no offense. I just happened to have some frustrations getting started with actually coding in D (not setting it up) and saw this post. So I voiced my frustrations. I really am not meaning to sound confrontational if that is what you meant by your comment. I obviously found some potential value otherwise I wouldn't have bothered.
 ^^^ How is that helpful?
Replied to this on GitHub: https://github.com/dlang/phobos/pull/4397#issuecomment-223813719
 The other beef I see, is that examples for functions seem like 
 they are just ripped from random unittests and frequently 
 reference other standard library calls without context of what 
 they are doing.
Yes, many examples are actually unit tests, to verify that the displayed examples actually work. Most examples are written in the style that the result of the documented function is `assert`ed or `enforce`d to be correct, which may be unusual at first. The chomp call does seem unnecessary in that example, though.
To be honest, I was just looking to read a text file. string source = readText("file.txt"); ...seems like the obvious example to show as it is simple, shows a common use for the function call and it's using a primitive of the language. And make no mistake about it, it's a good solution. I was pleased by the actually D solution. It's just a shame I had to filter out noise in the documentation to get to see it. It sounds small, but the delay does propagate over time. The code that took me 3 hours to figure out in D (not just that little blerp above) I reproduced in Python in like 20 minutes by just googling.
Jun 05 2016
prev sibling next sibling parent Tofu Ninja <joeyemmons yahoo.com> writes:
You know what's kinda sad, there are only 2,052 question on SO 
with the "d" tag. I think if more d questions could be answered 
on SO then it would make googling d related things a lot easier. 
Another problem with SO is that it uses "d" instead of "dlang", 
"dlang" is generally better for google.
Jul 05 2016
prev sibling parent reply Tofu Ninja <joeyemmons yahoo.com> writes:
You know I just had an idea for documentation that might be nice. 
Why not make all the examples interactive like the "Your code 
here" box on the front page? We have the technology, could be 
cool.
Jul 06 2016
parent Seb <seb wilzba.ch> writes:
On Thursday, 7 July 2016 at 04:37:30 UTC, Tofu Ninja wrote:
 You know I just had an idea for documentation that might be 
 nice. Why not make all the examples interactive like the "Your 
 code here" box on the front page? We have the technology, could 
 be cool.
That's already WIP, but turned out to be harder than initially thought: https://github.com/dlang/dlang.org/pull/1297
Jul 07 2016