On 12/27/2014 2:57 PM, Andrei Alexandrescu wrote:
> On 12/27/14 3:42 AM, Jacob Carlborg wrote:
>> There's also "split" vs "splitter" and "join" vs "joiner". This doesn't
>> make it easier.
>
> Not to mention findSplit - my all-times favorite. -- Andrei

Just a minute Doc lets not start splitting hares!

http://wiseacre-gardens.com/sound/bugs_minute.wav

On 27 December 2014 at 02:21, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@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...

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@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)

Andrei

On 12/28/2014 7:52 PM, Andrei Alexandrescu wrote:
> 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)

sort() could sure use a [Params:] section!

For example, the parameter 'ss' is never mentioned in the description.

On 12/20/2014 6:04 AM, Jacob Carlborg wrote:
> On 2014-12-19 20:20, Walter Bright wrote:
>
>> No. It's attributable to I use different methods of debugging.
>>
>> The dmd source code is littered with debugging aids I've written. The
>> classic example is having a pretty-printer for each data structure. I
>> don't find the typical debugger pretty-printer to be adequate at all -
>> they never dump the type in the way that I think about the type.
>
> It can still be handy with a debugger. If you have written a custom
> pretty-printer you can still call that one from the debugger.
>
> In LLDB it's possible to write custom formatters/pretty-printer for your own types.
>

Often I'll pipe the pretty-printed debug output to a file, as it can be voluminous, and then actually edit the file to bring out what I need.

Not possible with a debugger.

(dmd can have pretty complex relationships between data structures and the path through the code. I might want to look at these fields of a type, but not those fields. Etc. I.e. I routinely build custom debugging aids for particular problems.)

On 12/20/2014 10:08 AM, Daniel Davidson wrote:
> Sure, sounds like a winning strategy. Probably not applicable, but were you to
> run into an issue with vibe or websockets would you proceed to write pretty
> printers for the supplied data structures, the returned data structures, etc,

probably yes, as I've done so when given someone else's program to debug. Writing a pretty-printer is often the first thing I do, as it also helps enormously in learning the data structures

> or would you live with the not so pretty gdb structures just to get your debug
> session over with?

unlikely

On 29 December 2014 at 03:52, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@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@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)
>
> Andrei
>

The new layout solves half the problem in that it hides the template constraints.

http://dlang.org/library/std/algorithm/sort.html

Shouldn't our focus also be to get the new layout out of "preview" mode and do our standardization of documentation from there?

By the way, I would also nick pick on top of Manu's suggestion that the short description for sort() is just "Sorts".  I'm sure this can be expanded to more than one word and less than twelve.

Iain.

On Saturday, 27 December 2014 at 08:32:29 UTC, Mike Parker wrote:
> It would also be nice to anticipate that people looking to operate on strings would look in std.string for things that are elsewhere. Once upon a time, the std.string docs actually did have a table of links for functions that had been moved to other pages. That was convenient and shouldn't have been removed, IMO.
>

Finding a string in another comes to mind. Is it "countUntil"?
I'm still unsure if there is a min/max function I could use for builtin types in Phobos.

I've found myself several times searching the following in Rosetta Code, and wished there was a site for common idioms.

On Monday, 29 December 2014 at 09:35:25 UTC, Iain Buclaw via
Digitalmars-d wrote:
>
> The new layout solves half the problem in that it hides the template
> constraints.
>
> http://dlang.org/library/std/algorithm/sort.html
>
> Shouldn't our focus also be to get the new layout out of "preview"
> mode and do our standardization of documentation from there?
>
> Iain.

Couldn't agree more.

It also scales way better than DDOC at the module level
(http://dlang.org/library/std/datetime.html VS
http://dlang.org/phobos/std_datetime.html).
Additionally, it could allow us to have multiple version of the
doc supported, which is quite useful when migrating stuff /
working with an older release.

What is missing / required to definitely switch ?

On Friday, 26 December 2014 at 01:11:42 UTC, Manu via Digitalmars-d wrote:
> Many bug reports and case studies, and often, a persistent voice for
> minority issues that don't get enough attention. My time spent arguing
> in this forum is substantial, and as annoying as it may seem, I think
> if I didn't invest that time, there are things in the past 5-6 years
> that would have moved in a different direction, and the language would
> be less attractive to me and my industry as a result.

Yes, I am doing pretty much the same. Does that mean I should be more friendly to your lobby of your industry/projects if it directly harms my interests? I have been supporting your push for better low-level control because it helps me too, not because I am kind person. Wasting effort of core contributors on a toolchain I will never use is against my interests and makes me naturally hostile about it.

> No, I'm not a compiler dev, and I feel like you're trying to discredit
> me because I'm not.

It is exactly what I am trying to do and I am not hiding it.

> I don't want to be a compiler dev. I want to *use* D to make my life
> and work easier for my numerous existing projects and commercial
> activity.

I wish I could do the same - I have never wanted to read compiler sources or be part of Phobos dev team. But I do recognize it is the only pragmatical way to make things work as per my needs and it is better to act according to how things are, not how things should have been.

> No other language community has ever demanded I contribute to the
> compiler to be eligible to have my case considered relevant.

It is not about relevance but about priority. If you are willing to wait for something like 10 years it will surely be addressed at some point. But you demand it being addressed soon, right?

And yes, D is probably least staffed language development project among non-hobby projects.

> If I contributed code to DMD, I know it will become my life, and that
> means I'm stepping away from my existing interests and areas of
> development. I'm not interested in doing that.

Then you will have to wait until someone appears who have same interests as you but IS willing to start contributing.

> Surely you can understand that my desire to *use* D as a tool is not
> at odds with my desire to continue to work in the fields that I prefer
> to work in?

I am simply telling that D is not ready to be used in your industry if you are adamant about such desire. Sad but true. And by complaining you don't improve situation as a whole but simply force redistribution of already existing set of limited resources.

>> I keep asking you simple question you avoid answering - who personally
>> should work to address your concerns? Those are all legit concerns and I
>> doubt anyone would willingly prefer to keep things as they are. But who will
>> do it if apparently you are the person who needs it most and you don't want
>> to do it?
>
> Any of the existing dev's that particularly care about the long-term
> success of the language and the health of the ecosystem?
> Perhaps new dev's will be attracted by making the ecosystem inclusive
> of their work and development practice. That tends to be the way open
> source works no?

No, not really. Open source is about people working to fulfill their own personal goals and not minding to share resulting code if it doesn't mean much added effort. Only few care about things like long-term success and only tiny minority will be interested in working on ecosystem they don't use.

Motivation you speak about has its place but it is more of a "luxury" contribution that only happens after primary concerns are dealt with. It just happens that if some open-source project is big and mature enough there is a very high chance that your problems are already addressed by someone else. That gives a wrong impression to those who mostly use open-source and rarely contribute.

> I'm glad you work on the compiler, the community needs people like you
> more than anyone...

I don't really work on compiler, sorry :)

> although I'm not sure about your attitude. Right
> now, I'm finding it quite corrosive.

Being all kind and nice is not really in my skill set. I hope I have explained better my dislike for this specific set of complaints despite the fact I usually tend to support your cause.