why ; ?

[Don]

Michael Neumann wrote:
> 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!

Yes, but when you have declarations, you can reduce that probability 
dramatically by using meaningful identifier names. That doesn't work in 
a language without them.

HaveWeInitializedEverythingYet when elsewhere it is 
HaveWeInitialisedEverythingYet

(I've had examples like that in PHP).

That just doesn't happen when you have variable declarations. Short, 
typo-prone names generally have small enough scope that you can see them 
in a screen or two.

>  > 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). 

Yup. Especially with floating point, where 1% of the time it will be 
initialized to NaN...

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).

Yes, I probably overstated the case for declarations. But my experience 
with PHP is that absence of declarations is the number 1 source of bugs 
in that language. And it manifests itself as an initialization problem 
-- I DID initialise that variable, but because of a typo, I find that 
it's unexpectedly zero!