How one can consider pip a good thing for packaging and blame dub at the same time is beyond my comprehensions. I have nothing but hatred against both pip and gems.

On Thursday, 18 December 2014 at 14:46:33 UTC, Dicebot wrote:
> How one can consider pip a good thing for packaging and blame dub at the same time is beyond my comprehensions. I have nothing but hatred against both pip and gems.

You missed the point:
- to me dub is a pip like

but in python they split into 3 software
- a builder (setuptool and newer version)
- a package manager (pip)
- a package index (pypi)

This is better to me, people which do not care about pip and other can to use only the builder.
End user to get their killer app working can use pip

with the same file setup.py they add many software level:
- end user do not care about standard path and want something easy to use
- packager need to insert correctly the software inside OS environment

With the json file for dub I think that is possible to get it

On Thursday, 18 December 2014 at 14:34:10 UTC, Manu via Digitalmars-d wrote:
> On 18 December 2014 at 23:52, Mathias LANG via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On Thursday, 18 December 2014 at 10:47:56 UTC, Manu via Digitalmars-d wrote:
>>>
>>>
>>> I think you've missed my entire point.
>>> The summary is this:
>>> Tried D, tried a very popular and often hyped D library/framework,
>>> encountered bugs. There was friction along the way which undermines
>>> confidence, but the critical point, the thing that caused the call to
>>> be made, was that the debugger didn't work, and we were unable to
>>> diagnose the bug with relative ease.
>>> It's possible that wouldn't have inspired the call to be made if it
>>> weren't for the prior friction... ie, if it were the first point of
>>> friction, we might have persevered through that one, but the aggregate
>>> prior to that point painted a clear picture, and that was the
>>> proverbial straw.
>>>
>>> Immaturity in the language seemed to allow for greater tolerance than
>>> immaturity in the tooling.
>>> This is the experience I was trying to convey... which was to be taken
>>> as a case study, that is all.
>>>
>>
>> What I'm wondering is how is it you didn't encounter this issue yourself
>> before ? If you've been using D for 6 or 7 years, and it was a small project
>> that was done in 20 to 30 lines of node.js ? So you clearly entered unknown
>> territory and expected everything to be fine, despite your experience with
>> D.
>
> Simple, I never tried to use websockets in vibe.d
> I had some past experience with vibe.d to do some web page stuff, and
> my experience was practically flawless, which is why I had confidence
> in it in the first place.
>
> Other common language issues that I did anticipate, I expected to be
> able to work through. I did know the debugger was an issue; it was
> actually my biggest fear going in. It did turn out to be the thing
> that bit me in the arse!
> I just hoped/expected we wouldn't need the debugger in such a small
> and simple program.
> The debugger does work okay for certain tasks, particularly if you
> control your coding style and make sure it's compatible with the
> debugger. I didn't have that luxury though as I usually do, since we
> were working on a foreign framework.
>
>
>> Can you link us to the issue(s) you created on Vibe.d's Github ?
>
> https://github.com/rejectedsoftware/vibe.d/issues/931
>
> I can't really articulate the problem well. Google's Native Client is
> a part of the puzzle, and that's a complex environment to get working.
> We tested the NaCl client against some other websocket servers though,
> and the problem didn't occur.
>
> I want to try and isolate a test case if I ever get some free time at work :/
>
>
> The other problem I can't isolate, it's just that the first file
> that's requested from time to time locks up the browser... if I kill
> the browser, reload and refresh, the problem goes away.
> I'll also see if I can post some code that demonstrates that case, but
> I have my suspicions that's client specific too.
>
>
>> We know some stuff sux. Just look at std.datetime's documentation. On my 15"
>> laptop, the links take all the screen. And this part is totally useless, as
>> no one is going to use it (beside ctrl + f, but you have to know what you
>> are looking for). Not mentioning the size of enum (just look at how much
>> space trivial enums such as "DayOfWeek" or "Month" takes).
>>
>> However, many of us lack the time and interest to fix this, as we know our
>> way around. The same goes for all the tooling/libraries, they were
>> developped, and are maintained out of one's necessity, not because "we" need
>> it.
>
> I know. I only said that there were a lot of complaints relating to
> the documentation, because there were.
> Although that said, as far as I can tell, it wasn't a particularly
> heavily weighting factor in the decision. Just worth noting; it wasn't
> endearing to anyone.

So to sum things up

1. you blindly walked into something you had no real experience with, apart from some vague memory that some parts of vibed worked for you a while ago.

2. you knew the debugger might be an issue, if not _the_ issue, but chose not to test it beforehand, or couldn't test it beforehand, because

3. you were working on a foreign framework (and simply hoped things would work out fine, fingers crossed!).

These are crucial bits of information that were missing from your first report.

Please try to be more accurate the next time. Holding back crucial information gets us nowhere. It only leaves the (false) impression that D is completely unusable.

Wow, uh...I didn't think I was saying anything particularly controversial, but I won a wall of text anyway.  But it's cool; turns out I've got one I can spare to reimburse you! :P  I don't think we fundamentally disagree, but I do think our differing experience has informed our view of the issue.

On Wednesday, 17 December 2014 at 22:47:21 UTC, Chris wrote:
>
> However, and this is the second point, if you want to use a language _properly_ and efficiently, you have to learn it in depth, no matter how advanced your skills as programmer are. You have to learn the concepts and ways that are peculiar to the language. Are you telling me that you never read TDPL or Ali's tutorial and that you grasped everything from templates and ranges to what you can do with D's structs immediately? If so, I doff my hat. I for my part had to ponder on the more advanced features of D and go back and rewrite some parts of my code in a better, more D-like style.
>
See, when I started learning D, neither of those existed.  ;)  No, really though: most of what I've learned has been from the docs, trying things to see what works, and the odd example snippet where I learn new tricks for things I already use or never noticed or have seen and then forgotten.  There weren't well-established idioms then or, in a lot of ways, now; the language to express the ones we think we want isn't even complete.  Whatever "proper" D is is all in a flux of multiparadigm soup (and by god, it's beautiful).  (In the now, I've skimmed sections of TDPL and use Ali's book a decent amount to refresh things I've forgotten.)

Sure, there are concepts that won't (didn't) come "immediately"; they take a little bit to think about and a bit more to play with and get the basics (a couple hours or so).  And then we apply what we've learned.  This is how learning works.  Later, when we've learned more, we might come back to something we wrote in the past and chide ourselves for all the "mistakes"; that's all normal.  But it worked then.  It works now.  And with a tweak there and a simple rewrite here...it works better than ever.  Great!  That's what growth looks like.  Feels amazing.

We work in a discipline where no one ever writes gold on their first attempt, even in languages they've been using for a decade.  And our understanding of how features of the language can be used continues to grow, too, so it's not like there's a definitive point at which you "know" D (or any language).  Because of these factors, I take serious issue with this attitude that you require a certain level of achievement before you're allowed to be productive (or even read the documentation).

And given the pitch for D, I think "you must be this tall to ride" is pretty much the antithesis of what we're after anyway.  Realistically, people can and will use Google and they'll find what they need to get the job done, and then they will do the job.  (And this is a valuable trait because an engineer that won't sully themselves with doing work is kind of worthless.)  So it's a dangerous sort of hubris to assume that because they're "not for" the "basic" user that they won't be used.

(I want to be clear: if you're in a situation where you can dedicate even a moderate chunk of time to learning a new language or experimenting when there's work to do, more power to you!  I encourage you to treasure that privilege, because it's not common and it could be snatched away at any moment by a shift in the power structure of your firm.  Seriously, that's awesome; I'm pretty jealous.)

Better?

-Wyatt

On Thursday, 18 December 2014 at 16:34:15 UTC, Wyatt wrote:
> Wow, uh...I didn't think I was saying anything particularly controversial, but I won a wall of text anyway.  But it's cool; turns out I've got one I can spare to reimburse you! :P  I don't think we fundamentally disagree, but I do think our differing experience has informed our view of the issue.
>
> On Wednesday, 17 December 2014 at 22:47:21 UTC, Chris wrote:
>>
>> However, and this is the second point, if you want to use a language _properly_ and efficiently, you have to learn it in depth, no matter how advanced your skills as programmer are. You have to learn the concepts and ways that are peculiar to the language. Are you telling me that you never read TDPL or Ali's tutorial and that you grasped everything from templates and ranges to what you can do with D's structs immediately? If so, I doff my hat. I for my part had to ponder on the more advanced features of D and go back and rewrite some parts of my code in a better, more D-like style.
>>
> See, when I started learning D, neither of those existed.  ;)  No, really though: most of what I've learned has been from the docs, trying things to see what works, and the odd example snippet where I learn new tricks for things I already use or never noticed or have seen and then forgotten.  There weren't well-established idioms then or, in a lot of ways, now; the language to express the ones we think we want isn't even complete.  Whatever "proper" D is is all in a flux of multiparadigm soup (and by god, it's beautiful).  (In the now, I've skimmed sections of TDPL and use Ali's book a decent amount to refresh things I've forgotten.)
>
> Sure, there are concepts that won't (didn't) come "immediately"; they take a little bit to think about and a bit more to play with and get the basics (a couple hours or so).  And then we apply what we've learned.  This is how learning works.  Later, when we've learned more, we might come back to something we wrote in the past and chide ourselves for all the "mistakes"; that's all normal.  But it worked then.  It works now.  And with a tweak there and a simple rewrite here...it works better than ever.  Great!  That's what growth looks like.
>  Feels amazing.
>
> We work in a discipline where no one ever writes gold on their first attempt, even in languages they've been using for a decade.
>  And our understanding of how features of the language can be used continues to grow, too, so it's not like there's a definitive point at which you "know" D (or any language).  Because of these factors, I take serious issue with this attitude that you require a certain level of achievement before you're allowed to be productive (or even read the documentation).
>
> And given the pitch for D, I think "you must be this tall to ride" is pretty much the antithesis of what we're after anyway.
>  Realistically, people can and will use Google and they'll find what they need to get the job done, and then they will do the job.  (And this is a valuable trait because an engineer that won't sully themselves with doing work is kind of worthless.)  So it's a dangerous sort of hubris to assume that because they're "not for" the "basic" user that they won't be used.
>
> (I want to be clear: if you're in a situation where you can dedicate even a moderate chunk of time to learning a new language or experimenting when there's work to do, more power to you!  I encourage you to treasure that privilege, because it's not common and it could be snatched away at any moment by a shift in the power structure of your firm.  Seriously, that's awesome; I'm pretty jealous.)
>
> Better?
>
> -Wyatt

I completely agree, that's how we all learn new languages. That's how I've done it over the years. I never said that you're not allowed to write, unless you're an expert. I started straight away, like you, before there was TDPL (however, the book clarified a lot of things for me later). This also means that the doc can't be that bad after all!

"you must be this tall to ride" was never my attitude, else I would never have touched D. What I took issue with was that the developers where lead straight into the jungle (vibed :-) without ever being told which animals live there and how to handle them.

But that is irrelevant now, because the posts above made clear that there were far more things at play than the (perceived) bad tooling.

> So to sum things up
>
> 1. you blindly walked into something you had no real experience with, apart from some vague memory that some parts of vibed worked for you a while ago.
>

Pure bile. No - reread the thread.

> 2. you knew the debugger might be an issue, if not _the_ issue, but chose not to test it beforehand, or couldn't test it beforehand, because
>
> 3. you were working on a foreign framework (and simply hoped things would work out fine, fingers crossed!).
>

Isn't that what you would hope? I would.

> These are crucial bits of information that were missing from your first report.
>
> Please try to be more accurate the next time. Holding back crucial information gets us nowhere. It only leaves the (false) impression that D is completely unusable.

How can you read this thread and think he was holding back anything. Everything he says is *easily* relatable and understandable. Besides he is trying to provide valuable information in a way that is much less abusive than many of the threads in this community. What I read was not that "D is completely unusable" but rather "the D debug story on Windows is a big problem and it lost D some potential users".

On 19 December 2014 at 00:55, Chris via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Thursday, 18 December 2014 at 14:34:10 UTC, Manu via Digitalmars-d wrote:
>
> So to sum things up
>
> 1. you blindly walked into something you had no real experience with, apart from some vague memory that some parts of vibed worked for you a while ago.
>
> 2. you knew the debugger might be an issue, if not _the_ issue, but chose not to test it beforehand, or couldn't test it beforehand, because
>
> 3. you were working on a foreign framework (and simply hoped things would work out fine, fingers crossed!).
>
> These are crucial bits of information that were missing from your first report.
>
> Please try to be more accurate the next time. Holding back crucial information gets us nowhere. It only leaves the (false) impression that D is completely unusable.

Fuck you guys.
I'm done here.

On Friday, 19 December 2014 at 06:47:31 UTC, Manu via Digitalmars-d wrote:
> On 19 December 2014 at 00:55, Chris via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On Thursday, 18 December 2014 at 14:34:10 UTC, Manu via Digitalmars-d wrote:
>>
>> So to sum things up
>>
>> 1. you blindly walked into something you had no real experience with, apart
>> from some vague memory that some parts of vibed worked for you a while ago.
>>
>> 2. you knew the debugger might be an issue, if not _the_ issue, but chose
>> not to test it beforehand, or couldn't test it beforehand, because
>>
>> 3. you were working on a foreign framework (and simply hoped things would
>> work out fine, fingers crossed!).
>>
>> These are crucial bits of information that were missing from your first
>> report.
>>
>> Please try to be more accurate the next time. Holding back crucial
>> information gets us nowhere. It only leaves the (false) impression that D is
>> completely unusable.
>
> Fuck you guys.
> I'm done here.

I think it's a fair criticism that you knew D projects like vibe.d and perhaps the language itself tend to favor linux and that the tooling on Windows, ie linker and debugger, is not so great, yet jumped in and hoped it would work.  You took a low-odds gamble that it would all work and it crapped out.

Perhaps Chris is too accusatory and defensive about the language when pointing this out, but D has its weak spots and you walked into some of them.  Thanks for pointing them out, even if the core team already knew about most of them, as it's another anecdote to add to the list.

Perhaps this thread you started will spur people to work on some of these issues.

On Friday, 19 December 2014 at 06:47:31 UTC, Manu via
Digitalmars-d wrote:
> On 19 December 2014 at 00:55, Chris via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On Thursday, 18 December 2014 at 14:34:10 UTC, Manu via Digitalmars-d wrote:
>>
>> So to sum things up
>>
>> 1. you blindly walked into something you had no real experience with, apart
>> from some vague memory that some parts of vibed worked for you a while ago.
>>
>> 2. you knew the debugger might be an issue, if not _the_ issue, but chose
>> not to test it beforehand, or couldn't test it beforehand, because
>>
>> 3. you were working on a foreign framework (and simply hoped things would
>> work out fine, fingers crossed!).
>>
>> These are crucial bits of information that were missing from your first
>> report.
>>
>> Please try to be more accurate the next time. Holding back crucial
>> information gets us nowhere. It only leaves the (false) impression that D is
>> completely unusable.
>
> Fuck you guys.
> I'm done here.

me too. it's really disgusting how you guys treat (verbally
mistreat) others, who take a chance with D.
Good luck to you all on your pet project.

On Friday, 19 December 2014 at 07:25:20 UTC, ole wrote:
> me too. it's really disgusting how you guys treat (verbally
> mistreat) others, who take a chance with D.
> Good luck to you all on your pet project.

And how? Explaining mistakes and reasons why just taking a chance brings nothing (and can as well do a harm)?

Chris point was overblown, sure, but so was original post.

Manu has explained his case in great details and that was very good. However it was missing single most important part - explanation of what he wants to achieve, what actions he expects from community. So far it sounded like "hey guys I know you are nerds so go implement everything I need for my projects instead of working on yours". I'd be glad to be mistaken but it still looks like that so far.