Re: Patterns of Human Error - my presentation at the DC ACM

2011-05-06 Thread Lutger Blijdestijn
Nice slides, very simple and elegant. 

This reminds me of when I started with D. I found a lot of these 'details' 
unload quite some burden I had with C++ and made programming that much more 
enjoyable.


Re: Patterns of Human Error - my presentation at the DC ACM

2011-05-06 Thread Andrei Alexandrescu

On 5/5/11 10:18 PM, Andrei Alexandrescu wrote:

On 5/5/11 9:04 PM, Walter Bright wrote:

The slides: http://www.slideshare.net/dcacm/patterns-of-human-error

A review:
http://computopics.dcacm.org/2011/05/04/review-dcacm-patterns-of-human-error-with-walter-bright/



Anyone want to reddit this?


http://www.reddit.com/r/programming/comments/h5ehu/patterns_of_human_errors_link_to_slides_in_the/



Andrei


Unfortunately the post has been junked. I wrote a polite message to the 
moderators, you all may want to do the same.


Thanks,

Andrei


Re: Patterns of Human Error - my presentation at the DC ACM

2011-05-06 Thread bearophile
Walter:

 The slides: http://www.slideshare.net/dcacm/patterns-of-human-error

Nice. Please put your PDFs everywhere but Slideshare. I'd love a simple link to 
just the PDF, thank you very much (Slideshare requires Flash, JavaScript, other 
things, and the flash viever doesn't allow me copypaste of URLs like that 
joelonsoftware.com one or snippets that I have to copy manually here).

-

- 9V battery: it has keyd connectors *and* inverting its polarity often doesn't 
lead to large damages (you may damage the curcuit in some cases). This means 
that a car batter has to be designed *safer* than a 9V battery because an error 
often causes more damages than in 9V batteries.

-

 Simple fix: make l suffix illegal. No more possibility of this error. End of 
 story.

This is exactly the solution used by JSF-AV. They use a pre-compiler that 
generates a compile error if you use l as suffix (and maybe even if you use 
it as variable name). So they aren't using normal C++.

-

 int i = 1_000_000;

A downside of the current implementation is visible here:
long i = 1_000_000_00_000L;
The underscores are not enforced every 3 (or 4 on hex/binary literals) digits.
But in practice this has not caused me troubles, so far.

-

 Error Patterns Eliminated [Slide 32]

It's a very nice slide :-)

-

 i should be size_t [Slide 31]

Something related to this has caused me a not immediately visible bug in D, 
this is the original correct function:

double[][] matgen(int n) {
double[][] a;
double tmp = 1.0 / n / n;
a.length = n;
for (int i = 0; i  n; ++i) a[i].length = n;
for (int i = 0; i  n; ++i)
for (int j = 0; j  n; ++j)
a[i][j] = tmp * (i - j) * (i + j);
return a;
}


Second improved version:

double[][] matgen(int n) {
double tmp = 1.0 / n / n;
auto a = new double[][](n, n);
foreach (i, row; a)
foreach (j, ref x; row)
x = tmp * (i - j) * (i + j);
return a;
}


Problem: (i - j) gives a wrong result because i and j are now unsigned.

See some of the discussion:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learnarticle_id=26563
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learnarticle_id=26587
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learnarticle_id=26629

-

 Uninitialized memory [Slide 41]

This compiles with no errors, but maybe you meant heap memory:

@safe void main() { int x = void; }

-

 Validated data: validated!(T) [Slide 46]

I don't remember/know what this is.

Thank you for all this stuff you give us for free, people used to pay for such 
texts.

-

 http://www.joelonsoftware.com/articles/wrong.html

From the blog post:

All strings that come from the user must be stored in variables (or database 
columns) with a name starting with the prefix us (for Unsafe String). All 
strings that have been HTML encoded or which came from a known-safe location 
must be stored in variables with a name starting with the prefix s (for Safe 
string).

A better solution:
http://blog.moertel.com/articles/2006/10/18/a-type-based-solution-to-the-strings-problem

Bye,
bearophile


Re: Patterns of Human Error - my presentation at the DC ACM

2011-05-06 Thread Andrej Mitrovic
Is that a typo on page 31?

= should be =

maybe = should be 

I guess that further drives the point though. :)


Re: Patterns of Human Error - my presentation at the DC ACM

2011-05-06 Thread bearophile
Andrej Mitrovic:

 I guess that further drives the point though. :)

Yup .I didn't see it.

Bye,
bearophile


Re: Patterns of Human Error - my presentation at the DC ACM

2011-05-06 Thread Walter Bright

On 5/6/2011 8:13 AM, Andrej Mitrovic wrote:

Is that a typo on page 31?

= should be =

maybe= should be

I guess that further drives the point though. :)


You're right. Good catch.


Re: Patterns of Human Error - my presentation at the DC ACM

2011-05-06 Thread Walter Bright

On 5/6/2011 1:46 PM, Brad Roberts wrote:

That was the first error I caught.. since I've seen you use it as a common
error and reason to use foreach() style loops before.


Interestingly, nobody saw all 5 bugs.


Re: Patterns of Human Error - my presentation at the DC ACM

2011-05-06 Thread bearophile
Walter:

 Interestingly, nobody saw all 5 bugs.

You show this as a bug:
typedef long T;

But did you meant to write this?
typedef long long T;

With this change the C lint finds this bug too.

Bye,
bearophile


Re: Patterns of Human Error - my presentation at the DC ACM

2011-05-06 Thread Andrej Mitrovic
I still giggle at the long long name. Good thing there are no floats
floats and char chars.