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 some leave.

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

-Joel