Re: Patterns of Human Error - my presentation at the DC ACM
Have you ever placed a 9-volt battery on your tongue? It's not very pleasant, specially when someone asks you to do it and you don't know what's coming. On a serious note, the topic reminds me of an interesting book that I read; The Design of Everyday Things by Donald Norman, is one of the classics of human interface design. Norman shows how badly something as simple as a kitchen stove can be designed, and everyone should read it who will design a dialog box, write an error message, or design just about anything else humans are supposed to use. --Qt Docs
Re: Patterns of Human Error - my presentation at the DC ACM
bearophile Wrote: The dynamic C# keyword and other things in other new languages tells me that we're going to languages that try to combine the advantages of both. As I understand, this feature is only to simplify interoperability with dynamic type systems like ActiveX, DOM and IronPython. This doesn't mean, it's a feature good by itself.
Re: Patterns of Human Error - my presentation at the DC ACM
bearophile Wrote: A better solution: http://blog.moertel.com/articles/2006/10/18/a-type-based-solution-to-the-strings-problem What do you think about unittesting efficiency section?
Re: Patterns of Human Error - my presentation at the DC ACM
bearophile Wrote: Kagamin: What do you think about unittesting efficiency section? I always use unit testing, in Python I especially like doctests. But often unit tests aren't enough, so I use Contracts too. I rather meant the assertion that in languages with duck type system unittesting eliminates to some degree the need for strong type system.
Re: Patterns of Human Error - my presentation at the DC ACM
Andrej Mitrovic Wrote: I still giggle at the long long name. Good thing there are no floats floats and char chars. `long` is not a type, it's a modifier and - accidentally - a shortcut for `long int`. `long long` is a shortcut for `long long int`. `short` is a shortcut for `short int`. `signed` is a shortcut for `signed int`.
Re: Patterns of Human Error - my presentation at the DC ACM
Kagamin: I rather meant the assertion that in languages with duck type system unittesting eliminates to some degree the need for strong type system. I like both dynamically typed languages and statically typed ones, both have advantages and disadvantages. The dynamic C# keyword and other things in other new languages tells me that we're going to languages that try to combine the advantages of both. I sometimes prefer dynamic typing to build prototypes, but sometimes a _flexible_ static typing (like Haskell one) is useful for prototypes too. Unit testing is able to replace some of the tests done by a static type system. On the other hand a type system is able to test _all_ code paths, while the unittests cover only the paths exercised in the tests. So in the end I use about an equal number of unit tests in D and Python. And beside normal unit testing there are other forms of testing, like QuickCheck (http://en.wikipedia.org/wiki/QuickCheck ). Very large Python programs (like Zope) implement some kind of interfaces (and recent versions of Python have added ABC, Abstract Base Classes), some some help from a bit more structured type system is useful even in dynamically typed languages when the programs become large. Bye, bearophile
Re: Patterns of Human Error - my presentation at the DC ACM
* Nick Sabalausky: Is there anything reddit doesn't auto-flag as junk? Perhaps content that is actually viewable and accessible?
Re: Patterns of Human Error - my presentation at the DC ACM
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
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
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
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
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
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
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
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
I still giggle at the long long name. Good thing there are no floats floats and char chars.
Re: Patterns of Human Error - my presentation at the DC ACM
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
