coderwiki.com is starting and needs you!

R

Richard Bos

Of course Richard, Richard, and Richard,

What a fun thread we're having together, aren't we?
not all Wikis are publicly editable.

That's true, but Wiki enthusiasts usually state it as one of their main
assets that most of them are, whereas I see that as one of Wiki's
greatest liabilities.

Richard
 
C

CBFalconer

Richard said:
.... snip ...

Incidentally, the "Hello World" page /still/ contains this text:

"Standard input and output functions are prototyped [declared] in
an 'include file'"

which is wrong. I also noticed this:

"For example, there are standard functions for reading data, and
outputting the same to the screen/terminal."

which is simply false.

I fail to see anything to get excited about. While not strictly
accurate, it is close enough for an initial introduction.

A few years ago I tried my hand at teaching elementary electronics
to total newbies. I was apprenticed to an experienced teacher, who
managed to make things clear to the students. At the same time I
was appalled by the inaccuracies he used. Yet when I attempted to
teach the same class something, all I got was blank stares. After
a short time we mutually agreed that teaching was not my forte.

Wirths principle of "successive refinement" is at work here.
 
R

Richard Heathfield

CBFalconer said:

A few years ago I tried my hand at teaching elementary electronics
to total newbies. I was apprenticed to an experienced teacher, who
managed to make things clear to the students. At the same time I
was appalled by the inaccuracies he used. Yet when I attempted to
teach the same class something, all I got was blank stares. After
a short time we mutually agreed that teaching was not my forte.

It's possible to be correct /and/ interesting, I promise!
Wirths principle of "successive refinement" is at work here.

Morning, chaps. This morning we're going to learn some lies. Sorry about
that, but it's come in from head office. Apparently we have to lie to you
first day out, so that several weeks from now we can have a good laugh at
your ignorance and teach you the truth. Except that'll be a lie too, either
because we're still not ready to teach you the truth or quite possibly
because we don't actually know it. Hey, where'd everybody go?

Telling students porkies is not the way to earn their trust.
 
G

goose

Richard Heathfield wrote:

Morning, chaps. This morning we're going to learn some lies. Sorry about
that, but it's come in from head office. Apparently we have to lie to you
first day out, so that several weeks from now we can have a good laugh at
your ignorance and teach you the truth. Except that'll be a lie too, either
because we're still not ready to teach you the truth or quite possibly
because we don't actually know it. Hey, where'd everybody go?

Telling students porkies is not the way to earn their trust.

A more accurate example would be the real stuff we learn at school.

As Terry Pratchet said, we have to first tell you small lies before we
can
get to the bigger truth. Without the small lies, comprehension is
almost
impossible, because the mind has to be comfortable with existing
concepts
before we can go on to more advanced concepts;

Example: in order to get the mind used to the concept of infinity
we are given (in primary school) the explanation of infinity as
stretching
out in two directions, without end.

Once our minds are able to grasp the concept of infinity *itself*, then
we can be told (in HS) that infinity does, in fact, come in different
sizes;
infinity, we finally learn, comes in an infinite number of sizes.

There are possibly better examples of where a small lie is needed to
get the student to understand, and once understanding is achieved
then the small lie can be discarded for the truth but I'm afraid I
cannot
think of any right now (press me for details later:). Small lies are
what all *good* teachers are able to use and discard when the time
comes. It is used to great effect all the time ...

We tell kids in PS why the sky is blue; at varsity they learn the real
reason.

We tell kids in HS how the bank calculates repayments on the house;
they
learn at varsity why their calculations in school never matched their
dads
bond repayment down to the last cent.

We tell children that pressing down on the accelerator supplies more
fuel
to the engine making it spin faster and thats how the car accelerates;
when
they become students at an automobile trade school they learn that
that is not the entire story.

Nevertheless, there is no excuse for "void main" :)

goose,
(I agree in principle with you on teaching programming, but I
also realise that other fields have long since used little
lies to temporarily defer the full explanation of a difficult
concept until the student is ready. The type of errors I
find in certain books, though, are not the type that are
usefull in this way)
 
R

Richard Heathfield

goose said:
Richard Heathfield wrote:

Oh deary deary me. My apologies to any chappesses in the group. Or perhaps
chappesses are just too bright to go to this kind of school?

A more accurate example would be the real stuff we learn at school.

As Terry Pratchet said, we have to first tell you small lies
before we can get to the bigger truth. Without the small lies,
comprehension is almost impossible, because the mind has to be
comfortable with existing concepts before we can go on to more
advanced concepts;

Writing to an output stream is actually a /less/ advanced concept than
writing to a screen or monitor, and is easier to explain, and forestalls
other questions based on misinformed ignorance (such as "how do I get it to
printf at the top of the screen instead?" and so on).

I understand your point - about "bootstrapping" a concept - but you have
missed something rather important about Pratchett-Cohen-Stewart "lies to
readers", and it's this: they *tell* you when they're telling you lies, and
they tell you why, and (wherever it's practical) they tell you the truth
later on.

If this coderwiki-page-thing doesn't tell you "this is a simplification, and
we'll sort it out in proper detail further down the line" (and it doesn't),
then it is not unreasonable to deduce that the author did not /realise/
it's a simplification. We can only go on what is actually written down.
 
M

Mark McIntyre

Not wrong at all. There might well be corrections and followups but the
original bad info/posts tends to stay there. Surely you dont refute that?

The difference is, on a Wiki, only one version is visible at any
instant in time - which may be the wrong one. On a usenet forum, all
versions are visible, and a reader can make an intelligent choice as
to which is correct.
If they have malice aforethough this could be a problem.

Or about half of wikipedia - see numerous articles in the press and on
El Reg. Get with the programme there!

(richard bos said)
Popularity often means that people find a use for them :

Big Brother is popular. The Sun newspaper is popular. Heroin is
popular in some parts of the world. Does this make them good too?
I would nearly always cross check a wiki. But it is fast and convenient
and I think you are being a little too distrustful.

With reason. Any wiki that has any possibility to become politicised
in any way, and that includes techy ones eg language versus language,
opsys vs opsys, risks becoming inaccurate.
Certainly with
setting up some Linux systems recently they were invaluable

I've used excellent wikis to set up Samba and Apache on my FC4 box.

I also stumbled on a couple of Linux and Windows wikis which contained
egregious untruths about other platforms.
A wiki might have errors, it is usually concise enough that finding the
errors doesnt take long.

Are there any errors in this wiki page?
http://en.wikipedia.org/wiki/IEEE_802.11
please check all the pages it references, to be sure...
..
This is not the case with millions of usenet
threads : there is invariably NOT a summary post hiliting who was wrong
and who was right.

Nor is there with a wiki. There's merely a post from whoever posted
last. Whether they were right or wrong, you don't know.

Here's the bottom line: wikis are like free pamphlets you get at the
railway station. You can get pamphlets that will tell you anything -
the dollar is strong, we're winning the war, joes burgers are the
best, whatever - but you have to use judgement to tell whether its
correct.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
M

Mark McIntyre

Of course Richard, Richard, and Richard,

What a fun thread we're having together, aren't we?[/QUOTE]

dang sorry, I spoiled it.
I know, lets all change our name to Bruce...

I'll get me coat.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
T

Thad Smith

Richard said:
pemo said:


Sure they are. But printf doesn't output to the screen or terminal. It
writes its data on the standard output stream. What happens to it after
that is Not Its Problem. Yes, it /might/ end up on a screen or terminal,
but it might not. C has no control over this.

In my opinion, this pedantic approach is not helpful to the person
trying to learn the rudiments of C. It is helpful, I think, to start in
concrete terms, such as displays, keyboards, and files, because that it
what the learner is familiar with. You could, if you want, state the
abstract notion of writing to an output stream, then immediately say
"which is typically used for character displays or data files". There
are probably some weaknesses in that statement, but the example helps
the learner relate to familiar material.

A similar principle applies to a standard header, which is typically
implemented as a text file. Some people find that information useful --
I do.

If the user wants the bare truth with no simplification, he can read the
Standard, but that's normally a tough way to learn.
 
R

Richard Heathfield

Thad Smith said:
In my opinion, this pedantic approach is not helpful to the person
trying to learn the rudiments of C.

But we've *seen* what happens with the non-pedantic approach. Given that
"pedant" originally /meant/ "teacher", I think giving the students some
facts instead of guesses might be worth a try.
It is helpful, I think, to start in
concrete terms, such as displays, keyboards, and files,

Why give them all that complexity?

"Stuff comes in over a thing we call an input stream. Stuff that comes into
the program is called input.

"Stuff goes out over a thing we call an output stream. Stuff that the
program produces is called output.

"Some streams can handle input /and/ output. We call those "update streams",
and we'll deal with them later on in the course.

"When your program starts up, you have three streams already opened and
ready to roll. And one of those can be ignored for the time being - we'll
cover it next week. The others are called stdin ("standard input stream")
and stdout ("standard output stream"). We'll be using stdin to capture the
information that the program needs if it is to do its job, and stdout to
record the results."

Why do we need to mention displays and keyboards? They would just complicate
the explanation.

If the user wants the bare truth with no simplification, he can read the
Standard, but that's normally a tough way to learn.

Why not give the user the /adorned/ truth with /suitable/ simplification? It
is possible to simplify without lying, and it is possible to tell the truth
in a way that makes it more palatable than an ISO document.
 
T

Thad Smith

Richard said:
Thad Smith said:


But we've *seen* what happens with the non-pedantic approach. Given that
"pedant" originally /meant/ "teacher", I think giving the students some
facts instead of guesses might be worth a try.

Got me there. ;-)
I was trying to express the tendency to be absolutely correct to the
detriment of comprehensibility. What would you call that?
Why give them all that complexity?

Speaking for myself, the "complexity" helps, because it helps me to
relate new material to something I already know about. New terms that
aren't related to the things I know are abstract, and my simple mind
can only handle a few abstract terms until it short circuits. "Output
stream" is an abstract term. It /is/ useful as a concept, but if that
is not the focus of the lesson, then I would want to relate it quickly
to something I know about, so that I can focus on the issue of the
lesson. Trying to learn 5 new things simultaneously is asking too
much of my simple mind.
"Stuff comes in over a thing we call an input stream. Stuff that comes into
the program is called input.

"Stuff" is OK if the reader understands the nature of stuff in
context. Does it include electricity, keystrokes, mouse clicks,
spreadsheets, display brightness adjustments, realtime video, web
sites, Word documents, CDs, pictures? These are potential stuff that
might go into a computer / computer program for a beginner.
"Some streams can handle input /and/ output. We call those "update streams",
and we'll deal with them later on in the course.

"When your program starts up, you have three streams already opened and
ready to roll. And one of those can be ignored for the time being - we'll
cover it next week. The others are called stdin ("standard input stream")
and stdout ("standard output stream"). We'll be using stdin to capture the
information that the program needs if it is to do its job, and stdout to
record the results."

Why do we need to mention displays and keyboards? They would just complicate
the explanation.

Typical usage helps the learner, I think.
Why not give the user the /adorned/ truth with /suitable/ simplification? It
is possible to simplify without lying, and it is possible to tell the truth
in a way that makes it more palatable than an ISO document.

I agree with your goal. For me, examples that I can easily relate to
help understanding.
 
R

Richard Heathfield

Thad Smith said:
Got me there. ;-)
I was trying to express the tendency to be absolutely correct to the
detriment of comprehensibility. What would you call that?

ISO/IEC 9899. :)

Seriously, clarity is indeed very, very important, but one doesn't improve
clarity magically just by getting things wrong. Nor does one necessarily
degrade clarity by getting things right.
Speaking for myself, the "complexity" helps,

You can't have it both ways!
I agree with your goal. For me, examples that I can easily relate to
help understanding.

And if I had been your C teacher, you'd have got them - but you would not
have got any lies.
 
C

CBFalconer

Thad said:
.... snip ...


Speaking for myself, the "complexity" helps, because it helps me
to relate new material to something I already know about. New
terms that aren't related to the things I know are abstract, and
my simple mind can only handle a few abstract terms until it
short circuits. "Output stream" is an abstract term. It /is/
useful as a concept, but if that is not the focus of the lesson,
then I would want to relate it quickly to something I know about,
so that I can focus on the issue of the lesson. Trying to learn
5 new things simultaneously is asking too much of my simple mind.

Starting from displays, keyboards, and files, all of which are
right under the students nose and therefore somewhat
understandable, we can later say that by generalizing those
communications into streams we can make them much more useful, and
use them in other ways.

OTOH if we start with streams, and their care and feeding, and
later say that we can connect them to displays, keyboards, and
files, there is too much to grasp in one mouthful.
 
M

Malcolm

Richard Heathfield said:
Writing to an output stream is actually a /less/ advanced concept than
writing to a screen or monitor, and is easier to explain, and forestalls
other questions based on misinformed ignorance (such as "how do I get it
to
printf at the top of the screen instead?" and so on).
Most students don't think like that. They know what a screen is, because
they can see it physically in front of them. They know what files are
because they are used to saving work and carrying disks around. They don't
see the connection between putting characters on the screen and creating
files, until the teacher tells them.

Also students like to be able to write real programs, which means little
video games. So it is a good idea to give them some screen control functions
early on, so that they can get the lines of asterisks scrolling down screen
and the up-arrow spaceship avoiding them. A game which is enjoyable to play
and their own work is a real motivation to persist with programming. You can
tell them later that the console functions aren't in the ANSI standard.
 
G

goose

Richard said:
goose said:


Writing to an output stream is actually a /less/ advanced concept than

Although I might be inclined to disagree with this statement ...
writing to a screen or monitor, and is easier to explain, and forestalls
other questions based on misinformed ignorance (such as "how do I get it to
printf at the top of the screen instead?" and so on).

.... this example is an *excellent* justification. So I guess you got me
there :)
My only defence for my inclination is that "output stream" is a more
abstract concept than "screen", but your example does tend to sway me a
little.
I understand your point - about "bootstrapping" a concept - but you have
missed something rather important about Pratchett-Cohen-Stewart "lies to
readers", and it's this: they *tell* you when they're telling you lies, and
they tell you why, and (wherever it's practical) they tell you the truth
later on.

Thats true. Even better, at the beginning of the book they explain
the whole "small lies" thing.
If this coderwiki-page-thing doesn't tell you "this is a simplification, and
we'll sort it out in proper detail further down the line" (and it doesn't),
then it is not unreasonable to deduce that the author did not /realise/
it's a simplification. We can only go on what is actually written down.

I think it is safe assumption that anything you find on a publicly(sp?)
modifiable webpage *must* be only a start. One should treat
something like wikipedia as a "lies to the reader" and not as an
authoritative source.

After all, thats my approach to wikipedia anyway.

cheers
goose
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,479
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top