suggestions for VIN parsing

[Rick Johnson]

[ADDENDUM #3]

I got off on a tangent in that last post, now i intend to re-focus the discussion.

> OPTION 1: Define the keys as ranges and the values as years.
>     
>   From the perspective of the mapping, the semantic order is
>   inversed. The "range" has no semantical meaning UNLESS it
>   is defined by a *year*. From this perspective, the "year"
>   is all that gives *meaning* to the "range", not the
>   inverse!
>   
>   However, from the perspective of the loop (which iterates
>   over keys), the order is correct. The logic of the loop
>   *demands* that "ranges" give meaning to "years", and NOT the
>   inverse!
>     
>     
> OPTION 2: Define the keys as years and the values as ranges.
>          
>   total inverse transformation of of option 1


  "But Rick, your getting all "semantical" about
  "semantics" -- what does all this mean?"
     
My main point is that: the majority of programmers are
inherently better at "engineering their own solution" than
"comprehending someone else's solution". And that fact is a
detriment to evolution of the "collective code" base.

  "And why is that?"

Well the answer is simple, but the solution is not! 

When you are starting a new project, and before you start
writing code, you assemble a "base architecture" of the code
in your mind. And even though this architecture might be
highly abstracted, you still have a good basis from
which to understand the code for which your are about to
write.

However, when you attempt to comprehend some else's code,
not only are you missing the author's "base architecture",
you will inevitably make assumptions about the code that
reflect your own methods of solving problems, which might be
in total conflict to the current authors design!

What the programming community is missing is a concept known
to graphics folks as: "Level Of Detail" (LOD).

LOD can be transformed into CS as "levels of architecture
abstraction". The idea is that as you move further and
further away from a "model" that you should only "see" the
relevant bits. 

For instance, If you have a model of the earth and moon,
and your viewing the earth from the moon, than drawing the
people on the earth does not make any sense, because you
could not see them from such a distance.

Just as you move further and further away from a real object
(say a building), you start to see less and less detail,
HOWEVER, you begin to see the *extents* of the building. You
begin to understand the global architecture of the model. But
more importantly, you understand the whole without
subjecting yourself to "subjective documentations"

    HOW DO WE TRANSFORM LOGIC WITHOUT SUBJECTIVE INTERFERENCE?

Understanding the "concept" is quite simple, however,
transforming the concept into practice is quite difficult.
For instance, opening up a code file and viewing a function,
or viewing an entire class (or other larger structure) is
not going to help you understand the global hierarchy of the
entire program. 

    "That's what documentation is for Rick!"
    
Ha! Well that depends on the writing prowess of the author.
And even *if* the author has honed his skills, he can NEVER
guarantee that every mind which reads his words will
transform the concepts "perfectly". No, i'm guess i'm more
realist on the subject than yourself.

Instead of forcing every programmer to be an award winning
documentation expert, i argue we must move away from the
subjective influence of documentation, and move forcefully
into a world of logical representations, exposed by "levels
of detail" that *concretely* define abstractions in the
purest form.