• bearophile <bearophileHUGS lycos.com> Jan 08 2011
• Walter Bright <newshound2 digitalmars.com> Jan 08 2011
• bearophile <bearophileHUGS lycos.com> Jan 08 2011

bearophile <bearophileHUGS lycos.com> writes:

The Reddit thread about this little article shows some interesting sub-threads:
http://www.reddit.com/r/programming/comments/exfnb/patterns_of_bugs/

So I add some more comments to my first answer to the article:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=126262


I too miss (a < b < c) in D, it's short, its meaning comes from mathematics and
it gives no confusion, it's more DRY than the D way and it evaluates the 'b'
variable only once. So it's a complete win across the whole line. But given the
original design decision of D, I agree that the D choice of disallowing it is
correct.


The design to prevent mistakes from entering the system is called Mistake
Proofing and was turned into a rigorous engineering practice by Shigeo Shingo.<


See: http://en.wikipedia.org/wiki/Poka-yoke


It is ironic that the company that created the technique that is a guiding
inspiration for Agile software, didn't use their own physical manufacturing
techniques when it came to writing their software.<


Right :-] Maybe they think they are just a hardware firm, or they don't
understand that software is way more complex than hardware, etc. I don't know
the causes.



The problem here is that writing code is a creative thinking process. Bolting
things to an airplane is not.<


This is an important insight that I think Walter article misses. 

This nice video talk about software engineering practice explains what that
means:
http://confreaks.net/videos/282-lsrc2010-real-software-engineering

Among other things, the talk explains an important difference between software
engineering and other engineering fields where an engineer draws a project and
then some people build it. In software engineering the program is the project,
the "people" that "build it" are the computer languages, and the final result
is the software running for the user. 

If in software engineering the program is the project, then writing a program
is the equivalent of creating the project. According to the talk programming is
like the design stage of an aeroplane, so comparing programming to bolting
things to an aeroplane is the wrong analogy for writing software. If this is
true, then a language has to be designed to help the design stage, that
probably is better done Agile.


Over in the D newsgroups, there are often impassioned debates about whether
particular patterns should be justifiably banned as being more trouble than
they are worth. More than a few suggest I set the bar unreasonably high - in
that D allows things that many suggest are fatally error prone (an example is
the default fall-through on switch case statements).<


This was written by Walter and I don't understand what he is trying to say.
But I'd like to improve the D switch, as we have discussed:
http://d.puremagic.com/issues/show_bug.cgi?id=4349


In general, this strategy works, but there's this odd thing that happens in the
other direction also. Sometimes a bit less checking can lead to more diligence.
We see this with dynamic typing. People often consider it inherently unsafe,
but programmers adjust and often end up without worse runtime error rates. It's
sort of like this: http://www.wired.com/wired/archive/12.12/traffic.html



This is another exceptionally good comment. This may partially explain why my
Python programs are not more buggy than my D code (quite the opposite in truth)
despite I am using D for years, and D has consts, a static type system and I
write equally unit-tests in D and Python, and in D I also use Design By
Contracts, etc (it explains the situation just partially. Surely Python
multi-precision numbers on default avoid several troubles normally present in D
code).

Here we are probably talking about Risk homeostasis or Risk compensation in
programming and language design:
http://en.wikipedia.org/wiki/Risk_homeostasis
http://en.wikipedia.org/wiki/Risk_compensation

The hypothesis of risk homeostasis holds that everyone has his or her own fixed
level of acceptable risk. When the level of risk in one part of the
individual's life changes, there will be a corresponding rise or fall in risk
elsewhere to bring the overall risk back to that individual's equilibrium.
Wilde argues that the same is true of larger human systems, e.g. a population
of drivers.<


The idea here is that D offers more built-in safeties, but programmers often
just program more sloppily, producing at the end about as many bugs. Surely
Python programs are more precise in their code formatting (because indentations
are part of the syntax), the result is that Python code is often formatted
better than D code and it's more uniform across different programmers. This
kills some useless discussions (where to put braces?) and allows people to put
inside their own Python projects code written by other Python programmers
avoiding to produce a program that looks like an Harlequin of different styles.

Bye,
bearophile

Walter Bright <newshound2 digitalmars.com> writes:

bearophile wrote:
 The problem here is that writing code is a creative thinking process.
 Bolting things to an airplane is not.<


 This is an important insight that I think Walter article misses.



Not at all. Most of software engineering work consists of plugging in 
subassemblies. In this case, designing the grammar such that the
"subassemblies" 
of the grammar won't fit together in ways that don't make sense is perfectly 
analogous.

bearophile <bearophileHUGS lycos.com> writes:

Walter:

 Not at all. Most of software engineering work consists of plugging in 
 subassemblies. In this case, designing the grammar such that the
"subassemblies" 
 of the grammar won't fit together in ways that don't make sense is perfectly 
 analogous.


I see and I agree. That "real-software-engineering" video is probably a bit
extreme, the truth is probably more mixed, this means that software engineering
is not 100% design work, there's some bolting too :-)

Bye,
bearophile