On 11 January 2014 02:28, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org
> wrote:

> On 1/10/14 6:02 AM, Manu wrote:
>
>> I won't start another annoying thread.
>>
>
> Great idea.
>
>
>  What's the go with popFront()... it returns nothing?
>> I almost always want to pop and return the front element. I can't find a function to do that... have I missed something again?
>>
>
> http://dlang.org/phobos/std_range.html#.dropOne
>
> What do you want us to do, RTFM to you?
>

That's not what I want at all.
Maybe moveFront is what I want... but it's not clear. It doesn't really say
what it does in the docs.
Looking at the code, it's way more complex than I'd expect, and I can't see
anywhere that it pops it from the range, which leads me to suspect it's not
what I want either. I have no idea what moveFront is.

On 11 January 2014 05:57, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org
> wrote:

> On 1/10/14 7:23 AM, Manu wrote:
>
>> This is what I've done. I'm just surprised that such an obvious function
>> doesn't exist, and suspect I was just retarded at phobos again.
>> Having a function that does this is kinda important to simplify lots of
>> expressions that otherwise need to be broken out across a bunch of lines.
>>
>
> I doubt it simplifies a lot.


Well you can pass it as an argument, or use it as a term in an expression
without splitting it across a whole bunch of lines.
Yes, it really does simplify many expressions.

I'm working on something where I go along munching tokens from the stream,
and performing fairly arbitrary sequential logic on them.
My code would be almost twice as long if I needed a second line to advance
the range after each line where I consider the front token's value.

It sucks particularly when there's 'if's involved:

if(r.front == x)
{
  r.popFront();
  x = r.front();
  r.popFront();
}
else
{
  r.popFront();
  y = r.front();
  r.popFront();
}


Surely this is obviously better:

if(r.getAndPopFront() == x)
  x = r.getAndPopFront();
else
  y = r.getAndPopFront();


 Does nobody see this coming up in their code? I have it basically every
>> time I use ranges, and as usual, surprised others don't feel the same way.
>>
>
> If it would have been frequent, it would have been a common request. Apparently it isn't. Even before ranges there wasn't a function that got you s[0] and also assigned s = s[1 .. $] in one shot, and that wasn't asked for either.


I agree. Which is why I asked for it here before writing my own; I assumed it must already exist, it would have been asked for before...

On 11 January 2014 03:32, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org
> wrote:

> On 1/10/14 9:01 AM, Kira Backes wrote:
>
>> On Friday, 10 January 2014 at 16:28:58 UTC, Andrei Alexandrescu wrote:
>>
>>> On 1/10/14 6:02 AM, Manu wrote:
>>>
>>>> What's the go with popFront()... it returns nothing?
>>>> I almost always want to pop and return the front element.
>>>>
>>>
>>> http://dlang.org/phobos/std_range.html#.dropOne
>>>
>>> What do you want us to do, RTFM to you?
>>>
>>
>>
>> I think he wants to return the popped element and this function does not do it. So it may actually be a missing convenience function.
>>
>
> Oh, I misunderstood. Anyhow, just wanted to convey some tough love to him :o).


Maybe I can convey some tough love too.
The docs are terrible; very unhelpful (often just one line that basically
repeats the function name), which is particularly problematic since phobos
is far from intuitive (to me at least), and most people here probably
severely underestimate the magnitude of the problem, since they've all
closely watched the development of phobos step-by-step, participated in
discussions related to it's design merits, and generally grown alongside
the body of code.
You personally have an obvious bias; naturally this stuff seems reasonable
and intuitive to you, you wrote most of it.

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

I think we've highlighted here that the documentation, errors, location of functions, and perhaps some of the names needs greater consideration, that is all. I'm not arguing with the concepts, just that it's surprisingly simple to fall into traps if you don't already know what you're doing, and then the errors often don't help you identify and fix the problems so much.

I've seen a lot of promotion recently positioning this stuff as a superior
use case for D. And maybe it's true, but that's not apparently at face
value.
If this is to be one of D's 'killer-features', and a major selling point
for D, then it needs to be polished to perfection. Currently, it is not.
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. And sure, that's a
subjective quantity, but you can't approach a design WRT intuitive-ness
without feedback from a whole bunch of different first impressions.

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.

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.
That is the world today, that is where the bar is. D will be wildly
successful on the day that programmers that have never seen it before can
come along, effortlessly write whatever code they're trying to write,
offered useful help by the compiler along the way, walk away feeling really
smart and happy with their experience.

Likening the experience to when I was learning C 20 years ago (earlier in this thread) is completely worthless, there was no internet, no competition, and the bar was so much lower then.

On 11 January 2014 00:26, monarch_dodra <monarchdodra@gmail.com> wrote:

> On Friday, 10 January 2014 at 14:13:37 UTC, marcpmichel wrote:
>
>> On Friday, 10 January 2014 at 14:02:21 UTC, Manu wrote:
>>
>>  I won't start another annoying thread.
>>>
>>> What's the go with popFront()... it returns nothing?
>>> I almost always want to pop and return the front element. I can't find a
>>> function to do that... have I missed something again?
>>>
>>
> There isn't (at least, not that I know of). I would be trivial to implement, but because it would be implemented in terms of front/popFront, it would not be any faster.
>
> *However*, depending on the range type (non-transitive), popping might
> instantaneously invalidate the element you are operating on (think
> "byLine", that returns a "char[]", not a "string").
>

Since you mentioned it here yesterday, I thought 'byLine' would be useful
this morning... but I can't find it!
This is an embarrassing theme.

Does it actually exist, and I am even further retarded... or did you just make that up?

File seems to have one, but that's no good for general text processing. I can see std.string.splitLines, but that's not the same thing; it allocates in a case where I don't need to.

 It seems you have to use both the .front property to access the element,
>> and popFront() to advance to the next element.
>> I can't understand why you need two methods; maybe there's a very good
>> reason for that.
>>
>
> You *need* two methods for the very simple use case of reading without popping.
>
> As for returning the popped element when calling pop: It's an extra cost. C++ introduced back and pop_back (as well as pop/top) with those exact semantics for this reason. D also adds an issue of data integrity.
>

On Sat, Jan 11, 2014 at 12:14:55PM +1000, Manu wrote:
[...]
> Maybe I can convey some tough love too.
> The docs are terrible; very unhelpful (often just one line that
> basically repeats the function name), which is particularly
> problematic since phobos is far from intuitive (to me at least), and
> most people here probably severely underestimate the magnitude of the
> problem, since they've all closely watched the development of phobos
> step-by-step, participated in discussions related to it's design
> merits, and generally grown alongside the body of code.

I'm sure we're all well aware of the documentation problem. Pull requests are always welcome. ;-)


[...]
> I've seen a lot of promotion recently positioning this stuff as a superior use case for D. And maybe it's true, but that's not apparently at face value.
>
> If this is to be one of D's 'killer-features', and a major selling point for D, then it needs to be polished to perfection. Currently, it is not.  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?

The problem with this is that "intuitive" means different things to different people.

The other issue is that what we need at this point is not just to polish up the library docs (which, as we all know, needs lots of love). We also need *tutorials* targeted toward new learners, which right now are even more scant than Phobos docs, sad to say. Things that introduce key concepts that, if you don't grok it, you won't be able to really use the language effectively. Just as if you don't understand what a pointer is, your C code is going to have problems of a fundamental sort, certain things in D require that you understand key concepts, like ranges. Right now, though, these things are buried deep under obscure layers of incomprehensible (to a newbie) docs, so they may never find it.  The doc header in every module's docs should have an explanation of such key features, at the very least. Plus, we also need "bird's-eye view" tutorials that explain, in a very general way, how things are laid out and where to look for things, what you must know to understand the layout, etc.. Phobos does have an overview page, but it's so out of date and no longer accurate that I'd argue it's actually detrimental, not just unhelpful.


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

While this might be a helpful exercise to locate problematic parts of the API, IMO "intuitiveness" is overblown. It is no substitute for actually reading the docs and learning how to use something effectively. Driving a car is pretty intuitive -- nobody needs anyone to teach them that you just turn the key in the ignition, step on the gas, and off you go -- but if this is *all* they know, you'd hardly call their driving "effective", nor will you feel comfortable handing the keys over to them.


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

To be quite honest, I find Apple's interfaces an annoyance to use. But I know I'm in the minority in this issue. :-)


> That is the world today, that is where the bar is. D will be wildly successful on the day that programmers that have never seen it before can come along, effortlessly write whatever code they're trying to write, offered useful help by the compiler along the way, walk away feeling really smart and happy with their experience.
> 
> Likening the experience to when I was learning C 20 years ago (earlier in this thread) is completely worthless, there was no internet, no competition, and the bar was so much lower then.

While I agree in principle, I still think that intuitiveness is overblown. Computation is complex -- inherently complex -- and you can't expect to just dawdle in and wing it and get good results without ever spending any effort to learn anything. That's no excuse for things that *should* be easy to do being unnecessarily difficult, of course, but you can't expect good results for no effort. The universe just doesn't work that way.


T

-- 
Computers shouldn't beep through the keyhole.

On Saturday, 11 January 2014 at 03:49:28 UTC, Manu wrote:
> Since you mentioned it here yesterday, I thought 'byLine' would be useful
> this morning... but I can't find it!
> This is an embarrassing theme.
>
> Does it actually exist, and I am even further retarded... or did you just
> make that up?
>
> File seems to have one, but that's no good for general text processing.
> I can see std.string.splitLines, but that's not the same thing; it
> allocates in a case where I don't need to.

std.algorithm.splitter and std.regex.splitter can easily be leveraged to split lines.

However, a convenient, generic `byLine` algorithm that splits on any Unicode line break sequence in a carefully defined manner that guarantees optimal performance might be something we need to add to Phobos. When composing with `splitter`, the user is prone to introducing subtle limitations, like relying on "\r\n" vs "\n" or not supporting the non-ASCII line break characters, and is prone to introducing bugs due to subtle behaviour on empty lines.

On 11 January 2014 14:20, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:

> On Sat, Jan 11, 2014 at 12:14:55PM +1000, Manu wrote:
> [...]
> > Maybe I can convey some tough love too.
> > The docs are terrible; very unhelpful (often just one line that
> > basically repeats the function name), which is particularly
> > problematic since phobos is far from intuitive (to me at least), and
> > most people here probably severely underestimate the magnitude of the
> > problem, since they've all closely watched the development of phobos
> > step-by-step, participated in discussions related to it's design
> > merits, and generally grown alongside the body of code.
>
> I'm sure we're all well aware of the documentation problem. Pull requests are always welcome. ;-)
>
>
> [...]
> > I've seen a lot of promotion recently positioning this stuff as a superior use case for D. And maybe it's true, but that's not apparently at face value.
> >
> > If this is to be one of D's 'killer-features', and a major selling point for D, then it needs to be polished to perfection. Currently, it is not.  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?
>
> The problem with this is that "intuitive" means different things to different people.
>
> The other issue is that what we need at this point is not just to polish up the library docs (which, as we all know, needs lots of love). We also need *tutorials* targeted toward new learners, which right now are even more scant than Phobos docs, sad to say. Things that introduce key concepts that, if you don't grok it, you won't be able to really use the language effectively. Just as if you don't understand what a pointer is, your C code is going to have problems of a fundamental sort, certain things in D require that you understand key concepts, like ranges. Right now, though, these things are buried deep under obscure layers of incomprehensible (to a newbie) docs, so they may never find it.  The doc header in every module's docs should have an explanation of such key features, at the very least. Plus, we also need "bird's-eye view" tutorials that explain, in a very general way, how things are laid out and where to look for things, what you must know to understand the layout, etc.. Phobos does have an overview page, but it's so out of date and no longer accurate that I'd argue it's actually detrimental, not just unhelpful.
>
>
> [...]
> > 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.
>
> While this might be a helpful exercise to locate problematic parts of the API, IMO "intuitiveness" is overblown. It is no substitute for actually reading the docs and learning how to use something effectively.
>

I think you underestimate the importance of someone new to something (and
probably with zero, or less, vested interest) being able to just getting in
and do something useful with as little friction as possible.
The positive impression left by that experience is huge. With this as a
starting point, users will often learn the finer details through
observation, experience, and osmosis.

Many(/most?) programmers don't love programming; it's a job. They have a
task to complete, and the sooner they get it done, and it works properly (D
promotes correctness, this is the correct approach), the sooner they can go
home and get on with shagging the mrs, or watching tv, or whatever they
prefer to be doing.
Many(/most?) programmers I've worked with have never read a programming
book (other than maybe some material at school), they simply don't care
enough.
Naturally this forum is full of very committed enthusiasts, and that
fosters an unrealistic perspective of what programming is to most
programmers, and the investment people are realistically expected to make
in learning a new thing.

I just want to reiterate (I've made this point before) that most of my criticisms/complaints here are positioned from the angle that I always try to approach D like 'the average joe programmer'. I've been a project lead on large teams, and before I can realistically imagine adopting D full-scale in the commercial environment, I need to be convinced that these kinds of people are properly satisfied, certainly, they make up the majority of professional programmers.

Driving a car is pretty intuitive -- nobody needs anyone to teach them
> that you just turn the key in the ignition, step on the gas, and off you go -- but if this is *all* they know, you'd hardly call their driving "effective", nor will you feel comfortable handing the keys over to them.
>

I'm not convinced this is a good analogy.

> 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.
> [...]
>
> To be quite honest, I find Apple's interfaces an annoyance to use. But I know I'm in the minority in this issue. :-)
>

Me too, but until Google(/Samsung?) outright lifted their ideas and
lessons, they were the dominant force by far, and for good reason.
Again, you (and I) are an enthusiast, and among the severe minority...
although the analogy doesn't work so well anymore, because Android lifted
the good bits from iOS, and Apple hasn't done the same in return, so iOS
has kinda fallen behind, even with mainstream users. (In fact, I wonder if
that's even a valid demonstration of the principle I'm trying to
illustrate?)

> That is the world today, that is where the bar is. D will be wildly
> > successful on the day that programmers that have never seen it before can come along, effortlessly write whatever code they're trying to write, offered useful help by the compiler along the way, walk away feeling really smart and happy with their experience.
> >
> > Likening the experience to when I was learning C 20 years ago (earlier in this thread) is completely worthless, there was no internet, no competition, and the bar was so much lower then.
>
> While I agree in principle, I still think that intuitiveness is overblown. Computation is complex -- inherently complex -- and you can't expect to just dawdle in and wing it and get good results without ever spending any effort to learn anything. That's no excuse for things that *should* be easy to do being unnecessarily difficult, of course, but you can't expect good results for no effort. The universe just doesn't work that way.
>

Some of the things I'm talking about are trivial things like function
names, and where the functions should be found, whether there are 2
functions named similarly enough to cause confusion over which one is which.
I think these sorts of 'trivial' API details are far more significant than
has been recognised.
The fact that my question about popFront spawned 10's of emails, and
conversation about things like dropFront, moveFront, and there was
legitimate controversy over what things did, and every person that said
what I wanted already existed was wrong... and there are powerful
authorities in this thread.

There simply can't be a thread with hundreds of posts about something that's dead obvious.

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.

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

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

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

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


Andrei

On 11 January 2014 14:53, Andrei Alexandrescu <SeeWebsiteForEmail@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.

On 1/10/14 9:46 PM, Manu wrote:
> What's the one in the review pipeline right now?

http://forum.dlang.org/thread/ujlhznaphepibgtpcoqz@forum.dlang.org#post-ujlhznaphepibgtpcoqz:40forum.dlang.org

Andrei