Redundancy in Programming Languages

[janderson]

bearophile wrote:
 > Walter Bright Wrote:
 >> http://reddit.com/info/6ip9w/comments/
 >
 > A possible link:
 > 
http://dobbscodetalk.com/index.php?option=com_myblog&show=Redundancy-in-Programming-Languages.html&Itemid=29
 >
 > I have already answered to some of the points of that article in the 
last days in the newsgroup, I generally like that article, it sums part 
of the discussions seen so far (but I don't agree with everything it says).
 >
 > There's a balance: redundancy may avoid you some bugs, but may slow 
down your programming a bit, or it may make your code a bit less 
readable, so it's always a matter of balance, because such extra 
programming speed may be used to write more unit tests that are able to 
catch bugs (often higher-level bugs than a wrongly spelled variable 
name. I have nearly never fallen in that trap in Python, so it's not 
that common, even if I don't use a Python lint program). That's why 
Python programming is often faster, but you end writing many 
unittests/doctests that burn part of that saved time.
 > Modern IDEs may speed up your programming a lot, so you may end 
writing code quickly even if you use very redundant languages like Java.
 >
 > And such sweet spot may be different for different people: I am sure 
I may enjoy more redundancy if I am a newbie programmer (or even when I 
am a newbie for a specific language but not for programming), Pascal was 
a good example of more constrained and more redundant language useful 
for teaching programming. Today Java is another example.
 >
 > Bye, and thank you for such little articles,
 > bearophile

I think that as programs get more complex, bug hunting time goes way up. 
   Redundancy helps reduce the amount of time you spend int the 
debugger.  That's why I now use lots of invariant checks, static 
Asserts, runtime assets, unitchecks and strongly typed code to reduce 
that amount of time.  I want to catch a bug as early as possible.

Sometimes it just helps to break things down into the obvious and get 
and understanding of what you do.

So my order for catching bugs is :
1) Self Code review (while I compile -> Well D is a bit fast but in 
general I use C++)
2) At compile time (ie strongly typed code (from private values to using 
a class instead of a raw value) and static asserts help a lot).
3) In a unit test. (also unit checked invariant checks)
4) At load time. (asserts / messages / logs)
5) At runtime, erroneous values (invariant checks and asserts)
6) At runtime, crash. (minidump)
7) Peer review.
8) On automated build / tests.
9) On QA's Computer.
10) On Alpha / Beta / Release / Patch candidates.
11) On Clients computer.  This is what you don't want have to do.  You 
don't want to have an error occur on some rare piece of code that was 
never tested simply because it was written in a way that the compiler 
couldn't verify correctness. At least at for something simple.

For a smaller app with less people, I wouldn't worry about this so much.

-Joel