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!

Don:
> 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!

I think here there's a difference between Python and PHP, Python creates variables only when you write them, not when you read them.

Bye,
bearophile

Michael Neumann:

> After working a while with the C sources of Ruby they'll become less
> evil, even so they might be evil :). But hey, it's C!
> Just wondering if the sources of the .NET of Java compiler/runtimes are
> any better. For sure they are 10x as much code ;-)

Perl source code looks messy to me, but C too can be written in a good and readable way, you may take a look at Python C sources, for example the deque module, written by a photographer (the good R. Hettinger):

http://svn.python.org/view/python/trunk/Modules/_collectionsmodule.c?rev=60749&view=markup

Bye,
bearophile

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:g01trc$27bs$1@digitalmars.com...
> Don:
>> 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!
>
> I think here there's a difference between Python and PHP, Python creates variables only when you write them, not when you read them.
>

That's certainly an improvement, and does reduce the number of problems, but the problem is still there:

Quoted from http://mail.python.org/pipermail/python-list/2005-January/304959.html

> epsilon=0
> S=0
> while epsilon<10:
>   S=S+epsilon
>   epselon=epsilon+1
> print S
>
> It will print zero, and it is not easy to find such a bug!
>

"Michael Neumann" <mneumann@ntecs.de> wrote in message news:g01mtk$1nvj$1@digitalmars.com...
> Nick Sabalausky wrote:
> > // Note: untested
> > 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
> >   }
> > }
> >
> > I still like the @ thing, though.
>
> Very good example!
>
> A solution could be to force the programmer to use the "this." notation or at least issuing a compiler warning if not done.  The latter could be implemented in the compiler without any changes to the syntax/language.
>

I had been thinking of this feature as a pipe dream (at least for D), just because it would mean changing the language to always require "this." or "@". Implimenting it as an optional warning hadn't occurred to me. That makes it sound much more possible. Good call on that (no pun intended).

> The next step would be to have "@" as a synonym for "this.", as typing "this." all the time is either annoying and as such is ignored or leads to less readable code (IMHO).
>

Agreed. I would love to see this actually happen. Although, I do wonder if maybe we're chasing too rare of a problem to bother, or maybe it would segregate the D scene into "@D" people and "raw D" people (I hope not, 'cause I do like it).

Any comments from Walter? I'm curious what his take is on the original problem.

This answer is mostly off topic in this newsgroup...

Nick Sabalausky:
> > epsilon=0
> > S=0
> > while epsilon<10:
> >   S=S+epsilon
> >   epselon=epsilon+1
> > print S
> >
> > It will print zero, and it is not easy to find such a bug!

No language is perfect, it's always a compromise. For my personal style of programming Python is closer to being the best (I use D a lot because I need to be "closer to the metal", and I like it a lot). I think I have done a similar mistake only twice in more than 60 thousand of lines of Python I have written, and I have found the bug once 30 seconds later, and the other time ten minutes later, using doctests:
http://docs.python.org/lib/module-doctest.html
they are a very good tool to test your code and spot bugs. Dynamic languages allows you to spot and fix those bugs faster, so it's a matter of balance. Usually the worse bugs aren't misspelled variable names.

Bye,
bearophile

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:g02cej$7hb$1@digitalmars.com...
> Dynamic languages allows you to spot and fix those bugs faster

I've seen fans of dynamic languages say this a lot. I'm not challenging it, so please don't take this as an attack, but I'm curious: How are dynamic languages are considered to be easier/faster to spot/fix bugs?

Don wrote:
> 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).

Not neccessarily! The last 45 minutes I hacked up TypoCheck, which
inspects the source code of any Ruby application and will warn about any
potential mispelled local variable. I use the Levensthein distance for
that.

http://www.ntecs.de/projects/TypoCheck/

This will catch most cases, except very short variable names, as here
it's hard to distinguish a typo.

Of course it can never be as good as when manually declaring variables
(due to missing redundance).

>> 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!

So I guess PHP will just return a value if you read an uninitialized
local variable, while Ruby will very likely raise an exception.

Uhm, but I think it's getting very off-topic :)

Regards,

  Michael

On Thu, 08 May 2008 13:00:22 +0100, Janice Caron <caron800@googlemail.com> wrote:

> Z008/5/8 Gilles G. <schaouette@free.fr>:
>>  > As numerous examples have shown, it is perfectly
>>  > possible for the compiler to misinterpret the programmers intent, and
>>  > produce code that does completely the wrong thing.
>>  >
>>  In Python, nearly every time you need a long line, there are already parentheses in the expression, so you don't need to escape the new line.
>
> So if I mistype, and accidently fail to match parenthesis, the
> compiler can't detect it, and instead goes ploughing on, tying to
> compile through the next few statements. When it finally reaches a
> point where it can't parse any more, it will have no idea exactly
> where it got lost in the first place.

I got the T-shirt for that one when learning Python.

On Thu, 08 May 2008 18:20:15 +0100, Janice Caron <caron800@googlemail.com> wrote:

>> Programmer, who got used to one language finds it difficult to switch to another language, because different languages require different styles of thinking. Thus for C programmer it's difficult to understand block statement without braces :) and for basic programmer it's difficult to delimit block statement with braces.
>
> Ah yes - that's probably true.
>
> I wonder if it's possible to write a standalone tool that doesn't know
> or care about language grammar (except maybe some general rules about
> what constitutes a quote or a comment), that can freely convert
> between
>
>     Lorem ipsum (dolor sit amet)
>     {
>         consectetur!(adipisicing)(elit, sed);
>         do
>         {
>             eiusmod tempor incididunt;
>             ut labore;
>             et dolore;
>         }
>         magna(aliqua);
>     }
>
> and
>
>     Lorem ipsum (dolor sit amet):
>         consectetur!(adipisicing)(elit, sed)
>         do:
>             eiusmod tempor incididunt
>             ut labore
>             et dolore
>         magna aliqua
>
> If so, we can have not only D-in-Python-style (which I'd never use),
> but also Python-in-D-style (which I actually might). It sounds like it
> ought to be feasible.

That's actually quite a clever way to enter a code obfuscation contest. My grasp of latin
is just sufficient to want to make me try to interpret what your saying (and fail because
I dropped Latin in favour of Chemistry) and ignore your code.