Robert Cummings wrote:
On Thu, 2009-03-19 at 18:05 -0700, Michael A. Peters wrote:
Robert Cummings wrote:
On Thu, 2009-03-19 at 16:27 -0700, Michael A. Peters wrote:
Marc Christopher Hall wrote:
The following comment is not intended to be helpful....
*smacks head on desk repeatedly...*
This comment is..
I would hazard to say that if you are unwilling or unable to grasp OOP, MVCs
and any decent framework that is necessary then maybe stepping back and
tackling only things you can grasp.
To be honest - one of the problems is that documentation that tries to
explain these concepts is often severely lacking, using extremely poor
analogies, and only make sense to people who already have an
understanding of the concept.
For example -
A car is a good real-world example of MVC. With a car you have two
views: the interior and the exterior. Both take input from the
controller: the driver. The brakes, steering wheel and other controls
represent the model: they take input from the controller (driver) and
hand them off to the views (interior/exterior) for presentation.
That's from a web page that is suppose to explain MVC.
I bet if you took 50 people who didn't have a clue as to what MVC is -
maybe 1 or 2 of them would after reading that.
Documentation and howto's, just like code, really need to go through
real world testing to see if they make sense to people not already
familiar with the topic.
Unfortunately that rarely happens.
I think you have it back asswards. People need to go through real world
development or innane examples and then someone needs ot tell them where
they went wrong. That's how it worked in university. We got an example
like the one above, then we were expected to apply the principle. Those
who undertood it right away got great marks on their assignment, those
who took a little longer didn't... but if they kept at it... till they
figured it out... they got a good mark on the exam. I don't understand
defeatism. Suck it up! There's a zillion examples on the web. Study
many, learn the generalism.
The problem is I can make a car analogy out of any type of programming
design method.
And some people can make a programming design method out of a car
analogy. Your point? Analogies are learning aids, not magic.
Most of those who got it right away and got great marks did so NOT
because of what they learned from the example, but because of what they
already knew before they signed up for the class.
You can't generalize that statement though. Many students don't know it
before they enter the class. And for those that did... they probably
learnt it from a trivial unrealistic example also.
Thus, when the teacher sees some of his students understanding the
concept, he becomes smug and arrogant and thinks he did something right
and those who didn't get it have something wrong with them. The reality
is he can't teach worth shit and those who understood it did so before
they took his class, hence he didn't teach them anything.
Once again, you can't generalize that statement. A bad experience with
one teacher can hardly convey a trait to all teachers.
Cheers,
Rob.
I'm not talking about a bad experience with a teacher.
I'm talking about the use of vague analogies that can be applied to
anything and really only get the point across to someone already
familiar with the concept.
It's a real problem in documentation, partly because the review, if any
is done prior to publishing, is by someone else who already has at least
a vague understanding of the concept.
IBM Developer documentation and Apple developer documentation (IMHO)
tend to be better about this than most, but even with them it still is a
real problem.
-=-
Speaking of Car Analogies - in my auto shop class way back when, they
used a horse and buggy analogy to show that front wheel drive was
better, because horses pull a cart, they don't push it.
I then asked where the power in a horse comes from - it's hind legs or
it's front legs. The instructor was silent for a minute, then responded
"I never thought about that, but you are absolutely right"
That's a serious problem with analogies, they always have serious
problems that you can only ignore if you already understand the concept
being portrayed by the analogy, and that's why I personally hate them.
They seem to be quite popular, however, which is a shame.
Just document what the freakin' thing is - analogies just add confusion.
In the case of front wheel drive, the issue actually is engine location
- not any horse and buggy crap. With front engines, power is lost down
the long drive train to the rear wheels.
I bet the "automobile" concept of the a MVC has flaws just as big. A car
isn't a MVC, it's a freakin' car, and other than the on-board computer
that adds complexity and increases repair cost, programming method isn't
part of the design.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
