On Wednesday, 18 March 2015 at 18:40:41 UTC, Steve Wood wrote:
> On Friday, 13 March 2015 at 04:49:38 UTC, Walter Bright wrote:
>
>>
>> Google does abandon significant projects now and then, such as this one:
>>
>> http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html
>
> In fairness pretty much everything that was on google-code has moved, mostly to GitHub. E.g. for Go stuff see https://github.com/golang

https://cloud.google.com/tools/repo/source-tools

On 3/18/2015 4:53 AM, Elazar Leibovich wrote:
> On Friday, 13 March 2015 at 17:31:09 UTC, Andrei Alexandrescu wrote:
>>   File("/tmp/a").byChunk(4096).joiner.startsWith(s)
>>
> Something like
>
>      while (n != EOF) {
>          n = read(fd, buf, sizeof(buf));
>          if (n==-1) throw(...);
>          if (strcmp(buf, PREFIX) == 0) {
>               return buf;
>          }
>      }
>      return NULL;
>
> Requires no prior knowledge, and have similar effect.

The trouble with the latter example is it's full of bugs. Part of the whole point of the former example is it's much more likely to be correct.

* should use memcmp, not strcmp which depends on a 0 termination

* the entire buf is not necessarily read

* what happens when buf is entirely read, and strcmp reads past the end

* read() sometimes requires multiple calls to fill a buffer

* the former example is complete while the latter is missing a LOT of code, like opening the file, closing it, etc.

I don't want to rag too much on you for the bugs, but having buggy file reading loops like this is terribly commonplace. (I've done it wrong many times, too, and I even implemented read() and strcmp().)

Ranges+algorithms are much more likely to be correct. Yes, there is a learning curve to it, one has to reorient one's thinking and learn new names and what they do. But it's worth it, the payoff is big.

On 3/18/2015 5:59 AM, bearophile wrote:
> High level constructs in D are often slower than low-level code, so in
> some cases you don't want to use them.

They're often faster, too, for several reasons.

Like any programming construct, including traditional loops, one has to pay attention and use them with some skill in order to get max performance.

On 3/18/2015 5:45 AM, CraigDillabaugh wrote:
> You said that "Unfortunately" this thinking is going out of style "for good
> reasons".   I am confused (sorry, I am at work, and didn't have time to watch
> the 1+ hour video you linked to - maybe some clues were there)!

Consider this C code:

#include <stdbool.h>
#include <stdio.h>

typedef long T;
bool find(T *array, size_t dim, T t) {
 int i;
 for (i = 0; i <= dim; i++);
 {
    int v = array[i];
    if (v == t)
        return true;
 }
}

There are several bugs in it. I've showed this to probably over 1000 programmers, and nobody found all the bugs in it (they are obvious once pointed out). It is not easy to write bug free loop code, and find() is a trivial function.

On Wednesday, 18 March 2015 at 23:41:41 UTC, Walter Bright wrote:
> On 3/18/2015 5:45 AM, CraigDillabaugh wrote:
>> You said that "Unfortunately" this thinking is going out of style "for good
>> reasons".   I am confused (sorry, I am at work, and didn't have time to watch
>> the 1+ hour video you linked to - maybe some clues were there)!
>
> Consider this C code:
>
> #include <stdbool.h>
> #include <stdio.h>
>
> typedef long T;
> bool find(T *array, size_t dim, T t) {
>  int i;
>  for (i = 0; i <= dim; i++);
>  {
>     int v = array[i];
>     if (v == t)
>         return true;
>  }
> }
>
> There are several bugs in it. I've showed this to probably over 1000 programmers, and nobody found all the bugs in it (they are obvious once pointed out). It is not easy to write bug free loop code, and find() is a trivial function.

just for fun:

1/ '<=' instead of '<'
2/ array should be tested against null before entering the loop
3/ 'int v' instead of 'T v'

Got them all ?

On 3/18/15 4:48 PM, jkpl wrote:
> On Wednesday, 18 March 2015 at 23:41:41 UTC, Walter Bright wrote:
>> On 3/18/2015 5:45 AM, CraigDillabaugh wrote:
>>> You said that "Unfortunately" this thinking is going out of style
>>> "for good
>>> reasons".   I am confused (sorry, I am at work, and didn't have time
>>> to watch
>>> the 1+ hour video you linked to - maybe some clues were there)!
>>
>> Consider this C code:
>>
>> #include <stdbool.h>
>> #include <stdio.h>
>>
>> typedef long T;
>> bool find(T *array, size_t dim, T t) {
>>  int i;
>>  for (i = 0; i <= dim; i++);
>>  {
>>     int v = array[i];
>>     if (v == t)
>>         return true;
>>  }
>> }
>>
>> There are several bugs in it. I've showed this to probably over 1000
>> programmers, and nobody found all the bugs in it (they are obvious
>> once pointed out). It is not easy to write bug free loop code, and
>> find() is a trivial function.
>
> just for fun:
>
> 1/ '<=' instead of '<'
> 2/ array should be tested against null before entering the loop
> 3/ 'int v' instead of 'T v'
>
> Got them all ?

4. The semicolon after the for loop's closing paren...

On 3/18/15 4:54 PM, David Gileadi wrote:
> On 3/18/15 4:48 PM, jkpl wrote:
>> On Wednesday, 18 March 2015 at 23:41:41 UTC, Walter Bright wrote:
>>> On 3/18/2015 5:45 AM, CraigDillabaugh wrote:
>>>> You said that "Unfortunately" this thinking is going out of style
>>>> "for good
>>>> reasons".   I am confused (sorry, I am at work, and didn't have time
>>>> to watch
>>>> the 1+ hour video you linked to - maybe some clues were there)!
>>>
>>> Consider this C code:
>>>
>>> #include <stdbool.h>
>>> #include <stdio.h>
>>>
>>> typedef long T;
>>> bool find(T *array, size_t dim, T t) {
>>>  int i;
>>>  for (i = 0; i <= dim; i++);
>>>  {
>>>     int v = array[i];
>>>     if (v == t)
>>>         return true;
>>>  }
>>> }
>>>
>>> There are several bugs in it. I've showed this to probably over 1000
>>> programmers, and nobody found all the bugs in it (they are obvious
>>> once pointed out). It is not easy to write bug free loop code, and
>>> find() is a trivial function.
>>
>> just for fun:
>>
>> 1/ '<=' instead of '<'
>> 2/ array should be tested against null before entering the loop
>> 3/ 'int v' instead of 'T v'
>>
>> Got them all ?
>
> 4. The semicolon after the for loop's closing paren...
5. No return if the item isn't found, leading to undefined behavior.

There may well be more, but I'll stop spamming this topic. Sorry Walter.

On 3/18/2015 4:48 PM, jkpl wrote:
> just for fun:
>
> 1/ '<=' instead of '<'
> 2/ array should be tested against null before entering the loop
> 3/ 'int v' instead of 'T v'
>
> Got them all ?


Nope! I'll post late tonight.

On 3/18/2015 4:58 PM, David Gileadi wrote:
> There may well be more,

Yup!


> but I'll stop spamming this topic. Sorry Walter.

Of course, what the bugs actually are is not really the point, although it is fun hunting them out.

But it isn't so much fun hunting them out in a large codebase, nor is it fun spending hours tracking down a bug. The ranges+algorithms method is far easier to check by inspection and get right.

On Wednesday, 18 March 2015 at 23:41:41 UTC, Walter Bright wrote:
> On 3/18/2015 5:45 AM, CraigDillabaugh wrote:
>> You said that "Unfortunately" this thinking is going out of style "for good
>> reasons".   I am confused (sorry, I am at work, and didn't have time to watch
>> the 1+ hour video you linked to - maybe some clues were there)!
>
> Consider this C code:
>
> #include <stdbool.h>
> #include <stdio.h>
>
> typedef long T;
> bool find(T *array, size_t dim, T t) {
>  int i;
>  for (i = 0; i <= dim; i++);
>  {
>     int v = array[i];
>     if (v == t)
>         return true;
>  }
> }
>
> There are several bugs in it. I've showed this to probably over 1000 programmers, and nobody found all the bugs in it (they are obvious once pointed out). It is not easy to write bug free loop code, and find() is a trivial function.

i is of type int and dim of type size_t which can grow bigger so the loop may overflow... I can't find more.

Either way, I think your point couldn't be clearer :)

Maybe there should be a "part 2" to the C-to-D little tutorial, one that shows how to code at a higher level introducing gently functional structures instead of just teaching how to write C in D. To stop thinking about steps to think about transformations isn't an easy thing.