On 12/15/2014 6:51 PM, evenex wrote:
> On Monday, 15 December 2014 at 23:04:20 UTC, Walter Bright wrote:
>> We've made great progress fixing bugs - but if they aren't reported, they
>> don't get fixed. Please make sure all the ones you encounter are filed on
>> bugzilla.
>
> Yes, the reports are getting filed -

Thank you. This is critical.

On 16/12/2014 5:11 p.m., MattCoder wrote:
> On Tuesday, 16 December 2014 at 03:50:59 UTC, Rikki Cattermole wrote:
>> I started writing a small booklet on this, if you got an email if
>> you're interested or some way to send you. Please let me know.
>
> Do you mind to share with us all? :)
>
> Matheus.

https://drive.google.com/file/d/0B-EiBquZktsLc0czUzZVeGlLM00/view?usp=sharing
No guarantees of how long it'll stay up there.

And to reiterate, its only just a start. And I don't know if I ever complete it. There isn't really enough material for an actual book. Maybe booklet but meh.

On Tuesday, 16 December 2014 at 05:48:27 UTC, Rikki Cattermole wrote:
> On 16/12/2014 5:11 p.m., MattCoder wrote:
>> On Tuesday, 16 December 2014 at 03:50:59 UTC, Rikki Cattermole wrote:
>>> I started writing a small booklet on this, if you got an email if
>>> you're interested or some way to send you. Please let me know.
>>
>> Do you mind to share with us all? :)
>>
>> Matheus.
>
> https://drive.google.com/file/d/0B-EiBquZktsLc0czUzZVeGlLM00/view?usp=sharing
> No guarantees of how long it'll stay up there.
>
> And to reiterate, its only just a start. And I don't know if I ever complete it. There isn't really enough material for an actual book. Maybe booklet but meh.

This is a great start, keep going with it!!

A book that looked at the details of CTFE with examples and comparison of patterns implemented in CTFE vs. RT would be a really nice addition to the D books already available.

On Tuesday, 16 December 2014 at 05:48:27 UT
>
> https://drive.google.com/file/d/0B-EiBquZktsLc0czUzZVeGlLM00/view?usp=sharing
> No guarantees of how long it'll stay up there.
>
> And to reiterate, its only just a start.

Agreed its a great start.

Nick

On Tuesday, 16 December 2014 at 05:48:27 UTC, Rikki Cattermole wrote:
> https://drive.google.com/file/d/0B-EiBquZktsLc0czUzZVeGlLM00/view?usp=sharing
> No guarantees of how long it'll stay up there.
>
> And to reiterate, its only just a start. And I don't know if I ever complete it. There isn't really enough material for an actual book. Maybe booklet but meh.

Very good I liked and thank you for this!

Matheus.

On Monday, 15 December 2014 at 22:23:17 UTC, evenex wrote:
> On Monday, 15 December 2014 at 21:15:21 UTC, CraigDillabaugh wrote:
>> Is your project open source?   If so as a student we will likely be looking for applications to the 2015 Google Summer of Code, if D is accepted as a mentoring organization.  I would need to investigate if having a student working on their existing project would be allowable, but it might be possible.
>>  We would still have to find a mentor for you.
>>
>> Alternately GSOC 2015 might be your chance to learn a bit more about compilers!
>
> It's not currently open source (I am hoping to use this software to help me support myself - maybe open-sourcing could open the door for that, but it's a one way trip so I am hesitant) but I do like the idea of doing GSOC and improving the D language. If it involves work with the compiler, I'd also come out better equipped to deal with related future issues... How do I find out more?

The current state of things is summarized (sort of) in this
thread:

http://forum.dlang.org/thread/fpaxvelugeltxbfmzwqa@forum.dlang.org

I am hoping to get some work done on the DWiki projects page over the
holidays, so you can look on there for ideas.  If we are accepted
as a mentoring organization then you could find a project on there
you are interested in working on, or come up with your own proposal.

Cheers,

Craig

On 15 December 2014 at 05:39, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 12/14/2014 12:37 AM, Manu via Digitalmars-d wrote:
>>
>> There were a few contributing factors, but by far the most significant factor was the extremely poor Windows environment support and Visual Studio debugging experience.
>
>
> This is valuable information, while it's fresh in your mind can you please submit a bugzilla issue for each point?

I'll probe for more feedback.
Sorry, I don't have work time allocated to this >_<


>> 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.
>
>
> I understand what you're saying, but I find it hard to figure out just what to do to change it. Any specific suggestions?

I don't really know either. I can recall my own experience that the
documentation was really confronting, but I'm used to it now, and I
don't refer it frequently enough to really care anymore.
I think any of us in this community will have trouble seeing the
problems with the presentation here.

One thing I know for sure, is when they are confronted with constraints, especially on templates, they have absolutely no idea what they're looking at... and even I find it hard to read them. For my money, the constraints are less important information, and I think it should be separated from the declaration in the docs. Perhaps a better approach would be to convey that information in the parameter descriptions; ie, "'A' must be a forwardRange".

I think there's also a lot of magic letters in function declarations, especially in templates. I wonder if more meaningful names would help in a lot of cases?

I think it would be a good idea to make the template args and the runtime args look more visually distinct. D has a subtle template syntax, and it would be good to have something that clarifies which args are template or runtime args at a glance. It can look like quite a confusing mess currently in many cases.


I'd suggest to look at high-quality commercial documentation, like
MSDN or wherever.
Here's one I'm familiar with:
http://msdn.microsoft.com/en-us/library/windows/desktop/hh309466(v=vs.85).aspx
My feeling is the MS docs are well organised, there's always the lest
amount of text on a page at any given time.
It starts with 'getting started':
http://msdn.microsoft.com/en-us/library/windows/desktop/hh769064(v=vs.85).aspx
Then there is 'how to's for many common tasks:
http://msdn.microsoft.com/en-us/library/windows/desktop/hh404569(v=vs.85).aspx
This is a reference for a class:
http://msdn.microsoft.com/en-us/library/windows/desktop/ff476379(v=vs.85).aspx
For comparison, our pages show reference for multiple classes, and you
can only tell that something is contained in a class with a subtle
indentation: (consider SList)
http://dlang.org/phobos/std_container.html

Each page only has one thing. It dynamically fetches bits of data as you navigate, rather than reloading whole pages and assaulting you with a wall of text.

Let's look at something else... Since none of us had ever written a
line of javascript, and we had to learn to write a node.js server in a
few hours, this came up: http://jquery.com/
They have interactive tutorials with video presentations and even a
theme song O_O: http://try.jquery.com/levels/1/sections/2
Their API reference is a bit lame compared to Microsoft, but the
function reference is pretty good:http://api.jquery.com/dequeue/
What's interesting about that link is they're doing something cool
that we already have; they have some example code, and they offer the
button to run it. We have that on the front page of dlang.com, but we
don't use it in the docs anywhere that I know of.

The node.js docs are disgraceful: http://nodejs.org/api/child_process.html#child_process_event_disconnect they're practically as bad as ours, but I find the styling much more readable. Our docs are dominated by horizontal bars, weird colours, random bold-ness, but no real distinctions in font size or style. Their docs use text styling much more effectively than we do to my eye.

It's all subjective. My point is, the feeling I get from looking around the big players docs, there is a clear difference in quality. Past the installation process, and path to 'hello world', this is probably the most important first impression the language will make.

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.

On 15 December 2014 at 07:00, Kiith-Sa via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 14 December 2014 at 19:40:16 UTC, Walter Bright wrote:
>>
>> On 12/14/2014 12:37 AM, Manu via Digitalmars-d wrote:
>>>
>>> There were a few contributing factors, but by far the most significant factor was the extremely poor Windows environment support and Visual Studio debugging experience.
>>
>>
>> This is valuable information, while it's fresh in your mind can you please submit a bugzilla issue for each point?
>>
>>
>>> 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.
>>
>>
>> I understand what you're saying, but I find it hard to figure out just what to do to change it. Any specific suggestions?
>
>
> One thing I ran into often when I was inexperienced with D:
>   the template constraints make some signatures extremely messy, and it
> takes a while to figure out when you have e.g. 3 template functions of the
> same name in
> std.algorithm, all with crypric signatures.
>
> Example:
>
> ptrdiff_t countUntil(alias pred = "a == b", R, Rs...)(R haystack, Rs
> needles) if (isForwardRange!R && Rs.length > 0 && isForwardRange!(Rs[0]) ==
> isInputRange!(Rs[0]) && is(typeof(startsWith!pred(haystack, needles[0]))) &&
> (Rs.length == 1 || is(typeof(countUntil!pred(haystack, needles[1..$])))));
> ptrdiff_t countUntil(alias pred = "a == b", R, N)(R haystack, N needle) if
> (isInputRange!R && is(typeof(binaryFun!pred(haystack.front, needle)) :
> bool));
>
> countUntil is trivial to use, but the docs make it seem complicated
> and it takes a while to read them.
> (This is not really a good example as with countUntil it's not *that*
>  bad, but I think it should be enough to show the problem)
>
> In this specific case, it would be useful if the constraint was somehow separated from the rest of the signature and less emphasized (CSS).
>
> Also, in this example, the documentation text itself immediately goes into detail (e.g. mentioning startsWith!) instead of starting with a simple explanation of the concept.
>
> I think this could be helped somewhat if the example
>
> This is one example of "too much noise".

This is an excellent example. That wall of text is totally unacceptable.
It was the string functions that had my colleagues head spinning.
He wanted to do some extremely basic string operations, and
to!int(myString)... these things were all very hard for him to
understand from the docs.

On 15 December 2014 at 11:29, Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via Digitalmars-d wrote:
>>
>> We were trying to use vibe.d, and we encountered bugs.
>>
>> We were unable to build Win64 code ...
>
>
> 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.

What's our budget for this process? A few million? Plus finding new staff to replace the ones that quit because they don't like linux.


> Well, that was somewhat off-topic grumpy remark. On actual marketing thing:
>
> In my opinion biggest evangelist mistake everyone makes it trying to advertise D for something it simply isn't. Which inevitably fails and leaves people extremely frustrated with false advertising, like to remain there forever as a prejudice against D. Because you will have a better luck torturing kittens than try false advertising and get caught.

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.


> 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 think trying to sell D should look something like this "Yes, D is horrible because of X, Y and Z but here is why it doesn't matter for our case : A, B and C". Don't pretend perfection but explain trade-offs.
>
> You won't beat node.js in getting started curve. You won't beat Java in designing huge complex systems (well, at least everyone says that). You won't beat C in raw low-level performance. But D will easily beat C in getting started curve and complex design, easily beat node.js in performance and complex design and (not-so-easily) beat Java in performance and overall versatility.

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.


> Remember the talk by Stephan (http://dconf.org/2014/talks/dilly.html) about their vibe.d usage in production and points he has made when comparing vs node.js? It was about performance, it was about resource overhead, it was about benefits of static type system and horrors of callback hell. It wasn't about how vibe.d is more shiny than node.js - and it was good.

Yeah, we weren't interested in literally anything about node.js.
Actually, the concept repulsed us.
We just tried it, and it didn't crash. That is all.

If vibe.d didn't crash, *or* if the debugger actually worked (such
that we could have debugged the crash), then we would have surely
stuck with that.
But we couldn't get behind a solution that was impossible to debug.


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

Is not the case. We would have preferred write our code in a native language, but we don't have working time allocated to debug library problems with tools that don't work.