A desperate lunge for on-topic-ness

[Chris Angelico]

On Mon, Oct 22, 2012 at 7:19 AM, Roy Smith <roy at 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