why ; ?

[Michael Neumann]

Don wrote:
 > Michael Neumann wrote:
 >> Don wrote:
 >>  > Walter Bright wrote:
 >>  >> Nick Sabalausky wrote:
 >>  >>> Python's semantically-meaningful indentation was intended to 
fix the
 >>  >>> problem of poorly-indented code by enforcing proper indentation in
 >>  >>> the language and compiler. But the problem is, it *doesn't* 
actually
 >>  >>> enforce it. In fact, it *can't* enforce it because it doesn't have
 >>  >>> enough information to enforce it. All it really does (and all it's
 >>  >>> able to do) is run around *assuming* your code is properly indented
 >>  >>> while silently drawing semantic conclusions from those (obviously
 >> not
 >>  >>> always correct) assumptions.
 >>  >>>
 >>  >>> In fact it's really the same root problem as "no variable
 >>  >>> declarations". In both cases, the compiler does nothing but assume
 >>  >>> that what you wrote is what you meant, thus silently introducing
 >>  >>> hidden bugs 1. Whenever you didn't *really* want the new variables
 >>  >>> "my_reponse" and "my_responce" in additon to "my_response"
 >>  >>> (VB/VBScript coders use "option explicit" *for a reason*), and 2.
 >>  >>> Whenever you didn't *really* want to break out of that
 >> loop/conditional.
 >>  >>
 >>  >> That goes back to the point that a language needs redundancy in 
order
 >>  >> to detect errors. Having semantically-meaningful indentation,
 >> removing
 >>  >> redundant semicolons, and implicitly declaring variables all remove
 >>  >> redundancy at the (high) cost of inability to detect common bugs.
 >>  >>
 >>  >> Those things are fine for scripting language programs that are 
fairly
 >>  >> short (like under a screenful). It gets increasingly bad as the size
 >>  >> of the program increases.
 >>  >
 >>  > Implicitly declared variables are probably the greatest of all false
 >>  > economies in the programming world.
 >>  >
 >>  > bugs(no variable declarations) > 100 * bugs(dangling pointers).
 >>
 >> Is that your own experience? Only practice tells the truth!
 >
 > Yes. And such bugs can be horrible to track down. When I use such
 > languages I seem to spend most of my time hunting for typos which the
 > compiler should have caught.

How can the compiler prevent you from doing any typos? Imagine mixing
two variables "i" and "j". This can happen to you in any language!

And how is the following any better (taken from another post):

   class A {
     int i=0;

     void foo() {
       // Accidentially clobbers "this.i" aka "@i"
       for(i=0; i<77; i++)
         {/* Do stuff */}
     }

     invariant() {
       assert(this.i==0); // Fails after foo() is called
     }
   }

Sure, the compiler will issue a warning.

 >> Would you say that Smalltalk is a scripting language? See where it is
 >> used, and notice the size of the applications written in it.
 >>
 >> I am sure every C program includes more errors than the worst
 >> Ruby/Python program you can ever write. Not so sure about other
 >> scripting language... :)
 >
 > Ignoring the obvious exaggeration (look at the bug lists for Knuth's
 > code, for an example of bug-free C code) -- there are many causes of
 > bugs in C, other than dangling pointers!

Agreed.

 > And I think that many bugs attributed to dangling pointers are actually
 > _uninitialized variable_ bugs.

But in Ruby, to mention a scripting language, instance variables are
*always* initialized! In C, an uninitialized variable will silently
produce wrong results, which are hardest to find bugs (IMHO). On the
other side, in Ruby, it's very likely that you get a method-missing
runtime exception and as such the problem is easy to spot!

 > An uninitialised pointer containing
 > random garbage is horrible thing. In my experience, the problem is
 > almost always in the initialisation, not in the use of pointers.

Lets replace "declarations" with "initialization" in your
original statement, and I agree 100%:

bugs(no variable initialization) > 100 * bugs(dangling pointers).

Regards,

   Michael