On Wed, Sep 11, 2013 at 05:11:38PM -0400, Nick Sabalausky wrote: > On Wed, 11 Sep 2013 13:06:05 -0700 > "H. S. Teoh" <hst...@quickfur.ath.cx> wrote: > > > On Wed, Sep 11, 2013 at 03:17:22PM -0400, Jonathan M Davis wrote: [...] > > > Well, I hate that about python too, but what I _really_ hate about > > > python is that it's dynamic. It shouldn't be possible to do things > > > like change the type of a variable based on whether an if > > > condition was true or not (or change the type of a variable at all > > > for that matter). > > > > Yeah, this is something oft touted as being 'convenient' and 'easy', > > but then in production code, you find yourself writing type checks > > anyway just to make sure what's passed in is what you expect. (And > > things blow up in horrible ways when some stray code passes in > > something with the wrong type.) Which defeats the purpose of having > > a dynamic language in the first place. > > > > My feelings on it exactly. I also found the implicit member declarations > and its inability to match software to the correct runtime (like Java > does) to be major problems, too: > https://semitwist.com/articles/article/view/why-i-hate-python-or-any-dynamic-language-really
Yeah I remember reading that. I haven't had Python blow up on me like that (yet), but I first ran into this problem while writing some JS code. That was when I had to write some complex code to handle client-side dialogues (yeah, *those* ugly things), and, in an effort to prevent the code from becoming one long, winding spaghetti noodle, I decided to factor out common bits into functions -- you know, typical structured programming textbook exercise. Then things stopped working, and I couldn't figure out why. Eventually, after many hours of hair-tearing frustration, I found out that some stray code was passing in the wrong object to one of the functions. But of course, the JS interpreter couldn't care less -- there's no type system for a type mismatch to happen, so it just barged ahead and did who knows what with that object of the wrong type, until it tried to look up a non-existent field, which *conveniently* returns null. This gets assigned to another field in another object, and *then* when that other object is finally used much later on, it gets a null dereference exception. But this is JS we're talking about. What happens, boys and gals, when the JS interpreter encounters an uncaught error? That's right, it logs an error message to the error console (which is hidden by default in most browsers), and silently fails without any warning, and then the rest of the site's scripts (hooked to various event handlers) CONTINUE RUNNING AS IF NOTHING HAPPENED. I'd really like to know which genius came up with this totally dainbramaged idea, because I'd *really* like to slap him upside the head. Can you imagine the kind of field day the blackhats would have if, say, C code running on enterprise servers were to blindly continue running after dereferencing a null pointer? And now they want to put JS on the *server*? Gives me the shudders... Seriously, this is just like writing assembly code in 1975. Screw up a single opcode, and the computer just blindly barges onward interpreting random bytes as instructions, wreaking havoc to your entire system while you stare at the screen believing that it's still computing what you think you told it to. Who knew that JS was an underhanded way of getting people to write assembly code by hand again? :-P > > > > But I've never used YAML, so I can't say whether or not I'd like > > > > it. > > > > > > JSON is a subset of YAML 1.2, so they're very similar. Probably the > > > most obvious differences are that you don't need as many quotes in > > > YAML, and whitespace matters. I've had to deal with it some at work, > > > and I hope to never have to deal with it elsewhere. > > [...] > > > > Wait, how can JSON be a subset of YAML if whitespace in YAML is > > significant, but it isn't in JSON? > > > > Whitespace is only sometimes significant in YAML. On the JSON > constructs, it's not significant. On certain (all?) of the non-JSON > YAML-specific things, then it's significant. Yikes. So whitespace is neither always significant nor always insignificant, but *sometimes* significant? Then I have to agree with Jonathan that YAML is truly evil! T -- All problems are easy in retrospect.