Re: Blocking points for further D adoption

[dalailambda via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Seb via Digitalmars-d]

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

Re: Blocking points for further D adoption

[Tofu Ninja via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Andrew Godfrey via Digitalmars-d]

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?

Re: Blocking points for further D adoption

[qznc via Digitalmars-d]

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).

Re: Blocking points for further D adoption

[Tofu Ninja via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Puming via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Tofu Ninja via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[dalailambda via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Mike Parker via Digitalmars-d]

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'.

Re: Blocking points for further D adoption

[Mike Parker via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[dalailambda via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[qznc via Digitalmars-d]

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

Re: Blocking points for further D adoption

[Bastiaan Veelo via Digitalmars-d]

On Monday, 6 June 2016 at 18:49:21 UTC, ag0aep6g wrote:

Works in /phobos-prerelease and /library-prerelease.


Thanks.

Re: Blocking points for further D adoption

[ag0aep6g via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Bastiaan Veelo via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Artem Tarasov via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Laeeth Isharc via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[ag0aep6g via Digitalmars-d]

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

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.

Re: Blocking points for further D adoption

[David via Digitalmars-d]

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

Re: Blocking points for further D adoption

[ag0aep6g via Digitalmars-d]

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 
 it 
works.

Re: Blocking points for further D adoption

[David via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[David via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[David via Digitalmars-d]

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

Re: Blocking points for further D adoption

[David via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Vladimir Panteleev via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Vladimir Panteleev via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[ag0aep6g via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Vladimir Panteleev via Digitalmars-d]

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

Re: Blocking points for further D adoption

[ag0aep6g via Digitalmars-d]

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?

Re: Blocking points for further D adoption

[David via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[David via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[David via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[ag0aep6g via Digitalmars-d]

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.


[...]

clampclamp(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...

isPermutationisPermutation([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

Re: Blocking points for further D adoption

[David via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Artem Tarasov via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Laeeth Isharc via Digitalmars-d]

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

Re: Blocking points for further D adoption

[bachmeier via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Artem Tarasov via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[bachmeier via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Seb via Digitalmars-d]

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!

Re: Blocking points for further D adoption

[Artem Tarasov via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Jack Stouffer via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Jacob Carlborg via Digitalmars-d]

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

Re: Blocking points for further D adoption

[qznc via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Jack Stouffer via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[bob belcher via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Andrei Alexandrescu via Digitalmars-d]

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

Re: Blocking points for further D adoption

[dewitt via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Basile B. via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[jmh530 via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Jack Stouffer via Digitalmars-d]

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.

Re: Blocking points for further D adoption

[Jack Stouffer via Digitalmars-d]

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".

Re: Blocking points for further D adoption

[Dmitry Olshansky via Digitalmars-d]

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

Re: Blocking points for further D adoption

[Andrei Alexandrescu via Digitalmars-d]

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