Tutorial creates confusion about slices

[sjdevnull at yahoo.com]

Antoon Pardon wrote:
> On 2007-04-24, Michael Bentley <michael at jedimindworks.com> wrote:
> >
> > On Apr 24, 2007, at 6:35 AM, Antoon Pardon wrote:
> >
> >> People don't read tutorials in a strictly linear fashion. They can
> >> continue to later subjects and then come back here to see how things
> >> tie together. So the fact that it is only confusing to those who
> >> know more than is already presented doesn't seem a very good reason
> >> to leave it in.
> >
> > Yet they understand that earlier in the document, there is likely to
> > be a less complete coverage of a given topic.  There is in fact, a
> > link on that page that includes a more complete coverage of that
> > topic (which I mentioned to you in an earlier message IIRC).
>
> That there is more complete coverage elsewhere is no good reason
> to come with an explanation that suggests things working in
> a way that will be contradicted by that more complete coverage.

I happen to agree with you, but that's not a completely non-
controversial position.  Many tutorials/manuals will prevent a
simplified (and incorrect for the general case) description of how
something works early on, and then clarify it later for the general
case.  Personally I'd usually rather have the complete description
earlier rather than an incorrect simplification, or at least have a
footnote to the effect of "this is a simple introduction, the full
behavior will be described later".

But there's a good argument to be made for omitting confounding
details early on in a tutorial if there's a pedogogical reason for
doing so--indeed, there's such a widespread belief that early
oversimplification is actually helpful that I'd guess the majority of
language tutorials engage in it to some degree.

See, for instance, the C Tutorial at http://einstein.drexel.edu/courses/CompPhys/General/C_basics/
; it contains all kinds of statements like "The while loop continues
to loop until the conditional expression becomes false." (no mention
of "break", which is mentioned later in the section only as a way to
break out of an infinite loop).  It also consistently uses "void
main()" to declare main, which is simply not correct C (though it's
accepted by many compilers)--but given that _many_ tutorials, and
_many_ published books make similar decisions, it's not quite as
simple as saying "that's just wrong.  Do it right!".  Rather, it seems
that a certain segment of teachers have decided that
oversimplification in early instruction, even when it's erroneous, can
be a better way to get the point across than trying to convey all the
details at once.

What's my point?  This is really in a large part a discussion about
the philosophy of such tutorials--is it a bad idea to present
simplifications that are incorrect in general?  Or does it actually
help people get up to speed so much faster that it's worth it even if
a bit of time has to be taken later to re-teach the full details?  I
think that philisophical debate needs to be had before attacking
individual cases in the docs that use such simplifications.