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 We can design away the possibility of some errors, but we can also design in situations which demand diligence. People react in many subtle ways. That gives us a very large design space.< 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
