Lost a new commercial user this week :(

[Manu via Digitalmars-d]

On 29 December 2014 at 13:52, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 12/28/14 6:43 PM, Manu via Digitalmars-d wrote:
>>
>> On 27 December 2014 at 02:21, Andrei Alexandrescu via Digitalmars-d
>> <digitalmars-d at puremagic.com> wrote:
>>>
>>> On 12/25/14 5:18 PM, Mike Parker wrote:
>>>>
>>>>
>>>> On 12/26/2014 9:48 AM, Manu via Digitalmars-d wrote:
>>>>
>>>>>
>>>>> Ironically, the string and algorithm functions are probably the worst
>>>>> offenders, but coincidentally, there is a high chance that these are
>>>>> the first functions anyone will ever reach for, so they present a
>>>>> terrible first impression.
>>>>>
>>>>
>>>> +1
>>>>
>>>> When I first made the move from D1 to D2, this caused me no end of
>>>> frustration. The docs were quite unhelpful in this regard. It irked me
>>>> enough that I wrote a rant about it on my old blog. It doesn't bother me
>>>> anymore, so I haven't thought about it in years. This post brings it
>>>> back.
>>>
>>>
>>>
>>> I thought the std.algorithm stuff is decently documented. What would be
>>> the
>>> major pain points? -- Andrei
>>>
>>
>> The first line of text respectively:
>>
>> C#:
>>    public static void Sort<T>(T[] array)
>>
>> D:
>>    SortedRange!(Range, less) sort(alias less = "a < b", SwapStrategy ss
>> = SwapStrategy.unstable, Range)(Range r) if ((ss ==
>> SwapStrategy.unstable && (hasSwappableElements!Range ||
>> hasAssignableElements!Range) || ss != SwapStrategy.unstable &&
>> hasAssignableElements!Range) && isRandomAccessRange!Range &&
>> hasSlicing!Range && hasLength!Range);
>>
>>
>> I'm sure you can see the problem...
>
>
> Thanks, following your feedback I have recently submitted an enhancement
> request. Just for the sake of humblebragging, C#'s sort works only on arrays
> whereas D's sort (a) returns a statically-informed sorted range with
> specific primitives, (b) is configurable to use a custom predicate, (c)
> allows stability selection, (d) works for any range satisfying certain
> requirements. Yay...? :o)

I'm not making any comment on the quality of the implementation (I
agree, it's awesome), but the prototype as presented in the docs is
seriously intimidating.
I think careful consideration to design/layout/formatting of the docs
in general could alleviate a lot of the perceived noise alone. More
breathing room (whitespace), typeface, colour coding,
bold/italic/etc...
It probably wouldn't wouldn't be hard to be known for excellent docs.
Many other competing ecosystems have horrific documentation
experiences.

It'd be nice to get an experienced designer to invent a really
professional and quality style guide for the docs. Any designer mates
anyone?
This is probably the most important user-facing experience in the
ecosystem, so it can't hurt to get a bang-up design by someone really
experienced.