

Show Me Your Data Structure… - Maro
http://bytepawn.com/2008/09/10/show-me-your-data-structure/

======
visitor4rmindia
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.

