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.

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.

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

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.

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.

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.

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.

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.

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.

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.