On Mon, Oct 22, 2012 at 7:19 AM, Roy Smith <r...@panix.com> wrote: > Of course, the same can happen in Python. I could do: > > foo = "default value" > if blah == 47: > fooo = "some other value" > print foo > > No syntax error, no NameError, just the wrong thing printing.
Yeah, that's the worst kind of bug. No error, just wrong behaviour. This kind of issue is one of the "balancing downsides" of the freedom of not requiring variable declarations. For small scripts, it's not a problem, and Python and PHP both save you the hassle of explicitly telling the language that you really do know what you're doing, and that's a Good Thing. For large modules, debugging creeps up in significance, and variable declarations are less of a cost. JaCMaScript in "use strict" mode and a good linter can catch a lot of these sorts of bugs, though it has its own weirdnesses (why does a 'var' statement apply to the whole function regardless of where it is?). C-derived languages with proper block scope have a good chance of catching bugs of this nature at compile time, but at the cost of demanding code that's mainly there to satisfy the compiler ("isn't it OBVIOUS that I want this to be an integer? I'm assigning an integer to it!"). > This does > not in any way detract from the fact that PHP is a horrible language. > Trust me, if you continue to use it, your dislike for it will only grow. > It is truly evil. Have you discovered "unexpected > T_PAAMAYIM_NEKUDOTAYIM" yet? The double-double-dot-in-Hebrew token name isn't actually a bad error; the only problem is the token name itself. If it said "unexpected T_SCOPE" or something, it'd be easier to debug. Several of PHP's most annoying issues are solved in version 5.4 (array indexing a function call that returns an array now works), but there's still a huge fundamental that's unsolved: Unicode support. Python FTW there, especially now that PEP 393 means strings are as compact as possible. ChrisA -- http://mail.python.org/mailman/listinfo/python-list