Should this work?

[Manu]

On 11 January 2014 14:53, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org
> wrote:

> On 1/10/14 6:14 PM, Manu wrote:
>
>> Maybe I can convey some tough love too.
>>
>
> Awes.
>
>  The docs are terrible;
>>
>
> Agreed, no need to even argue!
>
>
>  This thread is basically an account of my experience at face value
>> diving into something new(-ish). I personally think it's valuable in
>> some way; these are accounts of specific hurdles that may trip others,
>> but you're welcome to tell me to RTFM.
>>
>
> My perception (and excuse me if I was wrong) was that you came to the
> discussion already indisposed: you had no knowledge of the general phobos
> approach and little interest in acquiring it. Instead, you had to do some
> simple string manipulation and expected it to be done the C way, and if not
> the hell with'em all. That sets up things in a way that makes it difficult
> to negotiate.
>

I guess I usually post about this sort of thing when I get the shits, so it
likely comes across poorly, but I don't think this is an accurate summary
of my perspective.
I think you're also conflating a few different points on separate occasions.

I do have knowledge of the general phobos approach, I know it's about
ranges, except ranges and dynamic arrays are sort of conflated when it
comes to strings, so I probably have an impure concept of a 'range',
strictly speaking.

WRT the opening point, I was R-ing-TFM at the time, *following example code
from the docs* when I was lead to use find() and retro() together in an
effort to locate a character. People said things like: "retro() returns a
range, so you need to convert it to a string to read it"; I think to myself
char[] is a valid range type as far as I'm concerned, so retro!char[]
should surely produce the same type as output? Obviously wrong now that I
think about it, but hopefully you can see that there were multiple layers
to the situation that was confusing me, and then coupled with useless error
messages, and the fact that I'd already followed trails in the docs to get
there, you just get annoyed that something that sounds so simple, isn't.

Turns out there was a function that did what I wanted anyway, I just missed
it (easy to do with phobos!), and then I got lost on a tangent following
the docs showing about reverse iteration and all that.

So the FM is bad. At a point though it does need to be read.
>
>
>  Unlike someone who's looking at D for the first time, I know a lot about
>> the community, development process, and also many other parts of the
>> language.
>>
>
> One aspect of that is you know you can contribute to the FM :o).


I'm actively working on other things, which are what lead me to this in the
first place.
I'm fairly happy being an end-user. I actually think there's nowhere near
enough end-users hanging around here.

I think it's fair to say that there are a lot of people that hang out here
talking about D that write surprisingly little D code themselves.
I like to practically apply D in projects in the time that I have available.

 But I can hopefully still produce a reasonably objective
>> first-impression towards things I haven't really touched yet. I can
>> certainly highlight the rough edges.
>>
>
> Mos def. Particularly the part about the FM being bad is quite clear.
>
>  Telling people to RTFM isn't helpful, if it were intuitive and they
>> didn't fall into minor traps in the first place, then it would be a
>> non-issue. Which is a better place to be in?
>> Claims of RTFM are often a failure of intuitive design.
>>
>
> But intuition is a subjective matter. What's intuitive for one is not for
> the other. You seem to find strrchr the pinnacle of being intuitive, and I
> think it's a piece of of dung.


I don't think C string functions are the pinnacle of awesome, but they're
widely known by surely the vast majority of native programmers out there.
As such, they offer some precedents in terms of naming (which have been
absorbed by other languages too).
Interestingly, phobos refers to the crt in many cases, it uses words like
'icmp', 'stdio'; surely that was directly inspired by C?
So, is that a case of the library sending the user mixed messages? When I
see a few things like that, I start to conclude it's probably a pattern.

The thread has moved on past the OP though, I've used this thread to
demonstrate 3 issues that have come up the last couple of days.

What I find ultimately 'intuitive', is when I'm writing some code, and I
press the '.' key, a list of things I might want to do appears, and the one
that I do want is obvious among the rest.
C# does this remarkably well. I don't think the value of this can be
overstated, and I think the success of C# is almost premised upon this
alone. I know many will completely disagree though.

I know so many people that love C# for the mere reason that their first
experience with it was so frictionless; familiar syntax, logical patterns,
and the functions listed in the auto-complete were obvious and intuitive.
D is perfectly capable of the same experience, except Microsoft have put
far more thought into the design and presentation of their standard library
than phobos has received.

There's always the issue too that phobos is a stone tablet. Nothing can
ever change in phobos, so it can never be refined.
Please seriously consider an experimental module group, where things are
readily available to be beta tested by many users (raising the opportunity
for useful feedback) without being set in stone.

 Here's an idea; next time a phobos module is released, specifically
>> request that people give it a spin without reading the docs (using only
>> auto-complete popups and intellisense), ask them to keep a journal of
>> significant moments in their experience; ie, moments when they had to
>> resort to the docs, when they tried something that didn't work how that
>> imagined, when they were confused by conflicting function names and not
>> sure which to choose. Gather a bunch of these reports, and there's a
>> very good chance that the author may be able to improve the intuitive
>> design of their module significantly.
>>
>
> Great. Let's do that for std.simd.


How about let's do it for everything?
What's the one in the review pipeline right now?

 There's a reason Apple are so successful. It's because rather than
>> telling their users to RTFM and harden up, they use extremely careful
>> design and lots of feedback to factor out the issues people are likely
>> to encounter in the first place.
>>
>
> In fact I know independently from several friends that iOS has really good
> FMs for their APIs compared to Android.


Umm, that's precisely my point. Apple tend to produce intuitive products at
every level, their spectacular success is built upon that principle. I
think it's a good principle... it's clearly a winning principle.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140111/3caca6ca/attachment-0001.html>