This might be true when learning, but its definately NOT true in
And the principle reason that the "intricacies" or features are misused or
mis-implemented is due to an erroneous overview of the concept at hand. This
occurs precisely because the coder has focused on the details instead of the
abstract concept.
The intricacies of the language were misused because the coder was too
focused on the details of the language??? This makes no sense
whatsoever! Most software engineering practices advocate separating
out designing and coding. I suggest until you're good enough to
combined the two, keep them separate.
Why use feature X, for example, if you don't know *when* to use X and what
its goals are.
I never suggested using features of the language that you don't
understand. But my initial point was, unless you are detailed
oriented, and patient enough , you'll never understand the intricacies.
Thats much more important than *how* to code X correctly in
your design.
But, if you don't understand the intricacies of the language, how do
you know you've coded X correctly? If you don't know that it's coded
correctly, what good is it? I may as well be thrown in the trash.
To emphasize the forest analogy: Concentrating on the tree only generates a
nice tree. The problem is that the forest is then populated by that tree
only. The first infection then jeopardizes the entire forest.
Yes, this analogy may sound good, but in reality it has no relavence to
software. Software is not a forest. A beautiful forest can be made up
of trees which have flaws ( grouping trees together can hide the
individual flaws of each tree. ) But if a software system is built
upon components that are flawed by a coder not understanding the
language, the flaws don't cancel themselves out, but interact to create
more flaws and you end up with a very ugly system.
-Brian