I really didn't get this rant. The author seems to believe (without any convincing reason) that in order to understand a program you have to understand it's dat

I really didn't get this rant. The author seems to believe (without any convincing reason) that in order to understand a program you have to understand it's data structures which must be typed and set in stone. I read the article he's bashing and I thought the code was nicely written and quite an enjoyable read. It certainly wasn't that hard to understand. Answering his points in brief: >No complete declarations of complete types, even though it would be (kind of) possible with JavaScript. So I can't start by visualizing the data structures. Type declarations are not mandatory to understand code. >No type declarations, but lots of confusing variable names, so I'm constantly going back trying to figure out what's what. The variable names are reasonable (symbol_table, scope, expression, etc). The most confusing were "nud" and "led" but those were explained in detail later ("null denotation" and "left denotation" - used for binding operators during precedence). >Dynamic modification of fields in objects. For example the function advance() adds the field arity to the token object, which was not declared anywhere, so you only find out about this by reading this function. This goes against everything sane in programming. Goes against everything "sane" in programming? It's just something the author isn't used to. It's perfectly valid programming technique and I've used it in python. >Going completely overboard, the field arity is used to store whether a token is a "name", "literal" or "operator" but later, for operators, changes this field to "unary", "binary", etc. (Truly bad programming, but not related to my argument about typing.) I can't make any sense of this rant. >To deliver the final blow to understandability, in functional style, the member functions of the objects are dynamically added and modified. At this point, if I see an object, I don't know its "type", but even if somebody tells me that, I don't know what state that "type" is in: what the data fields are, what they are used for and what the member functions do. I get the feeling this guy just has a mental block about the way programs should be (C++/Java yay! Anthing else - boo!) and is unwilling/underexposed to other programming paradigms. >Given the cognitive difficulties above, how does one look over the code to verify that it's correct? It's hard enough with static languages, here it seems quixotic. How about finding bugs? The same as with typed languages except that the compiler doesn't do one level of verification for you.