On Wednesday, 17 December 2014 at 08:09:10 UTC, Manu via Digitalmars-d wrote:
> On 15 December 2014 at 06:44, Jacob Carlborg via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On 2014-12-14 09:37, Manu via Digitalmars-d wrote:
>>
>>> They immediately made comments about goto-definition not working, and
>>> auto-completion not working reliably.
>>
>>
>> I'm curious to know which tools they used to get autocompletion and
>> go-to-definition to work with JavaScript.
>
> Well, since everything just worked, and we didn't need to try and
> debug crashes in libraries... those things didn't really come up.
> Our node.js code was only about 20-30 lines in the end.
>
> Visual Studio does an okay job of .js too.

Are you aware of node.js tooling support in Visual Studio?

http://nodejstools.codeplex.com/

On 15 December 2014 at 11:35, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 12/14/2014 5:29 PM, Dicebot wrote:
>>
>> If your colleagues went with node in the end and kept happy with it, quite
>> likely they simple don't need advantages vibe.d can give to their project.
>> There
>> is no shame in it.
>
>
> I also noted that none of the issues were the language itself.

Exactly! And I've been repeating this for some years now; I think D's
biggest 'issue' today is the environment.
The language can always be improved, but I think it's a bigger issue
that the tooling is, in my experience, the primary detail that
inhibits adoption.

How can we stimulate this area of development?
Companies will pay money for tooling, if it works! ;)

Do we have any vector's into Microsoft to get fixes for D'd debugging experience into their debugger? Are there any sympathetic developers at MS?

On 15 December 2014 at 14:46, Martin Nowak via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 12/14/2014 09:37 AM, Manu via Digitalmars-d wrote:
>>
>> The real trouble hit when vibe.d's WebSocket support didn't work as advertised; it crashed in various circumstances, and debugging was impossible.
>
>
> Please file that one https://github.com/rejectedsoftware/vibe.d/issues. What browser did you use?

Native Client, PNaCL build, under Chrome, Windows. WebSockets lock up randomly, data stream hangs.

We also have a problem with a super-basic server where the first file after booting the server seems to fail, page fails to load, refreshing hangs chrome. Kill Chrome in task manager, restart, reload the page, and it usually works fine thereafter.

We're also using a lot of range GET's, those seemed to be a bit fragile. I'm not sure why.

On 15 December 2014 at 14:51, Martin Nowak via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 12/14/2014 09:37 AM, Manu via Digitalmars-d wrote:
>>
>> Sadly, I failed to create a new commercial D user this week, and I'm
>> really disappointed.
>> It was rejected for exactly the same practical reasons I've been saying
>> forever.
>
>
> Doesn't surprise me too much to be honest. We aren't there yet and I'm always a bit uneasy when someone runs around advertising D to professional users.

Well... when? I've been here 6 years. When can I start to use D for my work? Other languages seem to have a higher velocity. Are we fighting a losing battle?

On 15 December 2014 at 20:46, Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 15 December 2014 at 10:42:26 UTC, Paulo  Pinto wrote:
>>
>> On Monday, 15 December 2014 at 08:13:33 UTC, Dicebot wrote:
>>>
>>> On Monday, 15 December 2014 at 07:48:37 UTC, Paulo  Pinto wrote:
>>>>
>>>> Well, lots of Fortune 500 companies do.
>>>
>>>
>>> I have heard good enough first 9000 times, thanks.
>>>
>>>> If you want to appeal to those users
>>>
>>>
>>> No.
>>
>>
>> So how to you plan to make game developers adopt D?
>
>
> I don't plan it and don't realistically ever expect it. Considering the fact that game development industry is traditionally one of the worst in contributing upstream I also don't have any motivation to convince them adopt D.
>
> If there ever appears a game development company / community interested in _investing_ into programming language that would be totally different story but also irrelevant to enterprise culture you refer to.

So, in your world, D is a language for nerds (linux nerds at that!),
and not for serious productivity by enterprise?
Give me a break!

On 16 December 2014 at 00:04, Kagamin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via Digitalmars-d wrote:
>>
>> They then made HUGE noises about the quality of documentation. The
>> prevailing opinion was that the D docs, in the eyes of a
>> not-a-D-expert, are basically unreadable to them. The formatting
>> didn't help, there's a lot of noise and a lack of structure in the
>> documentation's presentation that makes it hard to see the information
>> through the layout and noise. As senior software engineers, they
>> basically expected that they should be able to read and understand the
>> docs, even if they don't really know the language, after all, "what is
>> the point of documentation if not to teach the language..."
>> I tend to agree, I find that I can learn most languages to a basic
>> level by skimming the docs, but the D docs are an anomaly in this way;
>> it seems you have to already know D to be able to understand it
>> effectively. They didn't know javascript either, but skimming the
>> node.js docs they got the job done in an hour or so, after having
>> wasted *2 days* trying to force their way through the various
>> frictions presented but their initial experience with D.
>
>
> Comparing node.js to D? You probably speak about vibe, not D?

The majority of hours spent were not really related to vibe.d so much
as trying to wrangle the tooling, debugging crashes, and understand
the docs to get some very basic things done.
These are 'D' experience if you ask me.


>> One of the take-away quotes I think, was "D seems to be a language for people who actively want to go and look for it, and take the time to learn it. That's never going to be a commercial success."
>
>
> O_O Huh? Your team really didn't learn C++?

We didn't 'learn' javascript, or python, or html, or whatever else you
pick up on the job.
The investment in learning 'programming' is decades behind us, and I
think it's a reasonable expectation that a language present itself in
such a way that it's intuitive and easy to get some basic things
going.
Leveraging small example snippets from the docs, etc. D is very easy
for a C/C++ programmer, but the docs don't make it appear that way,
and they give the wrong impression.
The overpowering presence of templates in the docs give a first
impression that reminds people of everything that's wrong with C++,
which I suspect most C++ programmers looking into D are actively
trying to escape!

There simply can't be friction on step 1! There can be friction on
step 4 or 5 when you've already made some minor achievements, and have
a good few hours invested.
Any friction on step 1 or 2 will lead to an almost immediate rejection.

On 17 December 2014 at 18:36, Paulo  Pinto via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, 17 December 2014 at 08:09:10 UTC, Manu via Digitalmars-d wrote:
>>
>> On 15 December 2014 at 06:44, Jacob Carlborg via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> On 2014-12-14 09:37, Manu via Digitalmars-d wrote:
>>>
>>>> They immediately made comments about goto-definition not working, and auto-completion not working reliably.
>>>
>>>
>>>
>>> I'm curious to know which tools they used to get autocompletion and go-to-definition to work with JavaScript.
>>
>>
>> Well, since everything just worked, and we didn't need to try and debug crashes in libraries... those things didn't really come up. Our node.js code was only about 20-30 lines in the end.
>>
>> Visual Studio does an okay job of .js too.
>
>
> Are you aware of node.js tooling support in Visual Studio?
>
> http://nodejstools.codeplex.com/

Good to see they recognised the importance of the effort ;)

On Wednesday, 17 December 2014 at 08:30:59 UTC, Manu via Digitalmars-d wrote:
>> Here is exactly your problem - trying to do a web development on Windows :P
>> Really I have never understood that counter-productive obsession with a
>> habit that makes people differentiate development environments and
>> production environments so much. You aren't going to use Windows servers,
>> are you?
>
> Okay, you go and tell the CEO of my company that we're switching environments!
> We'll need all new software licensing, we'll need to re-jig the
> company server and IT infrastructure, we'll also need to retrain ALL
> the staff.
> Then we'll have to deal with the vast majority of staff who hate
> linux, and refuse to work in that environment.

I expect you to go and do that. Well, actually, in any reasonable company I'd expect environment to be defined at the initial design document stage and always be the one fitting for the specific product. Choosing inferior tools (assuming those are proved inferior) simply because of some bullshit policies is just ridiculous.

This is exactly what happened on one of my old jobs - upon encountering some pressure from company management team leads just went there and said "Stop messing with our tool choices if you want this project live. Or start looking for new programmers." Worked like magic.

It is not like I think that web servers shouldn't work on Windows - it is just realistic to expect much less effort to be put into bringing it to production quality. And impractical to lobby for putting more (limited) effort there. Same applies to most server technology out there per my experience.

> Actually, I recommended it because I had had a positive experience
> with vibe.d in the past. It seemed pretty solid.
> Gotta start somewhere. I've had success promoting D to commercial
> users in the past.

Promoting to commercial users is indeed possible but one needs to explain risks and trade-offs straight. I wonder though how you have not noticed debugger issues before if there was some positive experience. There was nothing to debug? :)

>> Idea that any D project can compete with node.js in "easy to jump in" domain
>> is absolutely ridiculous. Attempting this is just dooming yourself to fail.
>> Same is trying to advertise it is stable mature language - reality is it is
>> simply not true and people will find out it sooner or later.
>
> Sorry, maybe it wasn't clear, we never tried it out against node.js,
> we tried it first, on my recommendation.
> When it was rejected, someone else suggested to look at node.js. We
> looked at that, it just worked.

I mean that if "it just worked" was enough to make decision to use the node.js, then you didn't have any critical requirements that it fails to address (otherwise you would have looked for those first). Which means that pretty much any framework out there was suitable and ease of use was only truly important criteria.

Interesting part starts when you say "yeah, it have just worked, BUT.." and start evaluating if ease development will be enough to compensate for certain architectural issues in the long term (budget-wise).

> We didn't want any of those things from .js though. We're all
> low-level/native coders.
> We don't have time to debug language and library issues though. If we
> didn't have tooling/library issues, we would have been perfectly happy
> writing whatever code we needed to do our job.

If developer time is more expensive than server time in your project, most likely there is no point in going for native languages even if you prefer those. Otherwise debugger issues and/or necessity to switch the OS environment would not have stopped you.

>> If there ever appears a game development company / community interested in
>> _investing_ into programming language that would be totally different story
>> but also irrelevant to enterprise culture you refer to.
>
> So, in your world, D is a language for nerds (linux nerds at that!),
> and not for serious productivity by enterprise?
> Give me a break!

Of course it is language for nerds. Do you see a paid developer team working on D? At least ONE paid developer? Maybe someone of existing commercial users pays for adding tools / features? It is not a product, it is not funded and can't be anything but language for nerds unless YOU start paying for the change.

Which doesn't mean that it can be very productive language for serious projects. Nerds are pretty good at doing projects when there is no one from enterprise to create trouble. I think Sociomantic has proven quite strongly that such an attitude can work for successful business.

To start using D effectively in production one needs to stop considering himself a customer. This is absolutely critical.

> We didn't 'learn' javascript, or python, or html, or whatever else you
> pick up on the job.
> The investment in learning 'programming' is decades behind us, and I
> think it's a reasonable expectation that a language present itself in
> such a way that it's intuitive and easy to get some basic things
> going.
> Leveraging small example snippets from the docs, etc. D is very easy
> for a C/C++ programmer, but the docs don't make it appear that way,
> and they give the wrong impression.
> The overpowering presence of templates in the docs give a first
> impression that reminds people of everything that's wrong with C++,
> which I suspect most C++ programmers looking into D are actively
> trying to escape!
>
> There simply can't be friction on step 1! There can be friction on
> step 4 or 5 when you've already made some minor achievements, and have
> a good few hours invested.
> Any friction on step 1 or 2 will lead to an almost immediate rejection.

I second this. I remember very well that the docs really annoyed me
when I was starting with D. Sadly I can't see the issues I had
any more, because I'm used to it now, so it's kind of hard to
improve in a meaningful way.

But two things come to mind. The first is that the language documentation actually is a very dense language specification. If you look at the rust documentation you'll find a ‘Guide’ and a ‘Reference’. We need such a tutorial as well. Just linking to some books is not enough.

Second thing is template arguments and constraints. For example std.container.Array has a specialization for bool. That looks like this in the docs:

std.container.Array(T) if(is(Unqual!T == bool)) vs.
std.container.Array(T) if(!is(Unqual!T == bool)).

That's super unhelpful for newcomers. The difference is hard to spot, newcomer don't know what a qualified or unqualified type is and they won't recognize the is-expression.

I think the documentation should call those to overloads Array!T and Array!bool.

On Wednesday, 17 December 2014 at 09:34:45 UTC, Dicebot wrote:
>
> To start using D effectively in production one needs to stop considering himself a customer. This is absolutely critical.

This is a very interesting point: thanks you.
---
Paolo