May 18, 2012
On Friday, 18 May 2012 at 16:59:41 UTC, Bruno Medeiros wrote:
> On 12/05/2012 01:00, Timon Gehr wrote:
>> some essential properties:
>> - starts up instantaneously
> ....
>> some 'nice to have' properties:
>> - code analysis based code completion
> > - integrated debugger
>
> So just starting up the IDE is more important than actually writing code or fixing bugs?...
>
> Seriously, I'm never going to understand you "editor" people..

Latency vs. Throughput.


Both of them matter.
May 18, 2012
On 18-05-2012 18:59, Bruno Medeiros wrote:
> On 12/05/2012 01:00, Timon Gehr wrote:
>> some essential properties:
>> - starts up instantaneously
> .....
>> some 'nice to have' properties:
>> - code analysis based code completion
>  > - integrated debugger
>
> So just starting up the IDE is more important than actually writing code
> or fixing bugs?...

I shouldn't have to keep my IDE open all the time when I'm not using it. I should be able to just open it at any point where I need it and close it immediately when I'm done.

>
> Seriously, I'm never going to understand you "editor" people..
>

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
May 18, 2012
On Thursday, 17 May 2012 at 19:19:04 UTC, Andrei Alexandrescu wrote:
> On 5/17/12 11:52 AM, Peter Alexander wrote:
>> On Thursday, 17 May 2012 at 15:26:19 UTC, Andrei Alexandrescu wrote:
>>> I agree binarySearch is more precise, but I also think it's a minor
>>> issue not worth the cost of changing at this point. Improving names of
>>> things in the standard library is a quest that could go forever, make
>>> everybody happy we're making progress, and achieve no substantial gain.
>>
>> No need to change anything, just add something:
>>
>> bool binarySearch(Range, Value)(Range range, Value value)
>> {
>> return assumeSorted(range).contains(value);
>> }
>>
>> (constraints, predicates and the myriad of qualifiers/decorations
>> omitted for clarity).
>
> I don't see much benefit in this - just lateral walking. As long as the keyphrase "binary search" is present in the documentation, that's all that's needed as far as newcomers discoverability is concerned.

It's not just for newcomers discoverability, it's also for readability. Reading the assumeSorted version, it's not clear that a binary search is done.

May 18, 2012
On 5/18/12 4:11 PM, Peter Alexander wrote:
> On Thursday, 17 May 2012 at 19:19:04 UTC, Andrei Alexandrescu wrote:
>> On 5/17/12 11:52 AM, Peter Alexander wrote:
>>> On Thursday, 17 May 2012 at 15:26:19 UTC, Andrei Alexandrescu wrote:
>>>> I agree binarySearch is more precise, but I also think it's a minor
>>>> issue not worth the cost of changing at this point. Improving names of
>>>> things in the standard library is a quest that could go forever, make
>>>> everybody happy we're making progress, and achieve no substantial gain.
>>>
>>> No need to change anything, just add something:
>>>
>>> bool binarySearch(Range, Value)(Range range, Value value)
>>> {
>>> return assumeSorted(range).contains(value);
>>> }
>>>
>>> (constraints, predicates and the myriad of qualifiers/decorations
>>> omitted for clarity).
>>
>> I don't see much benefit in this - just lateral walking. As long as
>> the keyphrase "binary search" is present in the documentation, that's
>> all that's needed as far as newcomers discoverability is concerned.
>
> It's not just for newcomers discoverability, it's also for readability.
> Reading the assumeSorted version, it's not clear that a binary search is
> done.

I guess it is now :o).

Andrei
May 18, 2012
On Friday, 18 May 2012 at 21:28:45 UTC, Andrei Alexandrescu wrote:
> I guess it is now :o).
>
> Andrei

lol


One more thing that's also annoying about this is that it's not in std.algorithms, but std.range...

Asn't binary search an algorithm?
May 18, 2012
On 5/18/12 4:36 PM, Mehrdad wrote:
> On Friday, 18 May 2012 at 21:28:45 UTC, Andrei Alexandrescu wrote:
>> I guess it is now :o).
>>
>> Andrei
>
> lol
>
>
> One more thing that's also annoying about this is that it's not in
> std.algorithms, but std.range...
>
> Asn't binary search an algorithm?

It is, and the decision (after a good amount of deliberation) is arbitrary. Some rationale was that SortedRange has enough structure to make it an "interesting" range, so I put it in std.range. The argument could go either way. Now it's gone one way. Let's move on.

Andrei
May 18, 2012
On Fri, May 18, 2012 at 3:36 PM, Mehrdad <wfunction@hotmail.com> wrote:

> On Friday, 18 May 2012 at 21:28:45 UTC, Andrei Alexandrescu wrote:
>
>> I guess it is now :o).
>>
>> Andrei
>>
>
> lol
>
>
> One more thing that's also annoying about this is that it's not in std.algorithms, but std.range...
>
> Asn't binary search an algorithm?
>

I fairly often get confused about whether to look in std.range or std.algorithm for something.  filter is in algorithm but recurrence is in range, for instance. I can see why but I still sometimes go to the wrong module's documentation to look something up. There should probably be a lot more cross referencing between the two in the documentation.  Also, I think std.algorithm could use a mini-FAQ.  std.range is long overdue for an entire article explaining ranges but that's a well known omission that pretty much everyone agrees on.


May 18, 2012
On Fri, May 18, 2012 at 04:24:47PM -0600, Brad Anderson wrote: [...]
> Also, I think std.algorithm could use a mini-FAQ.  std.range is long overdue for an entire article explaining ranges but that's a well known omission that pretty much everyone agrees on.

What about the latest prerelease docs for std.range? I did clean up a lot of stuff there and tried to explain the basic idea of what a range is, and included a link to Andrei's article that describes the idea of ranges in-depth.

Or is that still not good enough? How can we improve the docs further?


T

-- 
Computers aren't intelligent; they only think they are.
May 18, 2012
On Friday, May 18, 2012 16:06:41 H. S. Teoh wrote:
> On Fri, May 18, 2012 at 04:24:47PM -0600, Brad Anderson wrote: [...]
> 
> > Also, I think std.algorithm could use a mini-FAQ. std.range is long overdue for an entire article explaining ranges but that's a well known omission that pretty much everyone agrees on.
> 
> What about the latest prerelease docs for std.range? I did clean up a lot of stuff there and tried to explain the basic idea of what a range is, and included a link to Andrei's article that describes the idea of ranges in-depth.
> 
> Or is that still not good enough? How can we improve the docs further?

Making improvements to the docs is great and definitely a good idea (I don't think that I've looked what you've done yet though, so I can't comment on the specifics of what's there), but we really should have an in-depth article on ranges in D and Phobos similar to Steven's article on arrays. Solid documentation is a good starting point, but I don't think that it would be appropriate to go as in-depth with the documentation as a good article would.

- Jonathan M Davis
May 18, 2012
On Fri, May 18, 2012 at 5:06 PM, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:

> On Fri, May 18, 2012 at 04:24:47PM -0600, Brad Anderson wrote: [...]
> > Also, I think std.algorithm could use a mini-FAQ.  std.range is long overdue for an entire article explaining ranges but that's a well known omission that pretty much everyone agrees on.
>
> What about the latest prerelease docs for std.range? I did clean up a lot of stuff there and tried to explain the basic idea of what a range is, and included a link to Andrei's article that describes the idea of ranges in-depth.
>
> Or is that still not good enough? How can we improve the docs further?
>
>
> T
>
> --
> Computers aren't intelligent; they only think they are.
>

I like it.  Looks like it's already up on the website and was included with 2.059 unless there are further changes beyond what's on http://dlang.org/phobos/std_range.html

It's very clean now and the link to Andrei's article definitely helps. Also, good thinking linking to the print version instead of the difficult to read and confusing non-print version. People I link to Andrei's articles on InformIT sometimes don't realize there is more than one page.

It's a great improvement to the documentation. I do agree with Jonathan, though, that a official article on dlang.org like Steven's arrays article would be a nice addition but what you've done helps enormously.